I want to install FEATool on Octave 4.2.2. Therefore, I went through these steps:
Downloading it.
Trying pkg install FEATool-Multiphysic.tar.gz in Octave command-line interface.
Octave returns this error:
COPYING file missing.
Neither GitHub nor FEATool provides any installation file for Octave or instructions about doing it.
Therefore, the question is:
How to install FEATool on Octave (Ubuntu 18.04)?
Following a quick preliminary check, it seems that the FEATool is no longer available or compatible with Octave since FEATool v1.10.
While there was no explicit announcement for this either on their blog or changelogs, according to the main author of the software (as elicited below), this seems to relate to overhead involved in supporting Octave on top of Matlab. Furthermore, as the company seems to have effectively chosen (for their own good reasons, I'm sure) to intentionally follow a direction that explicitly breaks Octave functionality, it cannot be expected to work on this platform even as unsupported software. Therefore the answer to your question is that "no you can no longer install this tool on octave (ubuntu or otherwise)".
Evidence that this software is no longer available for, or compatible with Octave:
Mentions to Octave in the documentation from v1.8 have now disappeared and are exclusive to Matlab (with extra effort towards Matlab backwards compatibily)
The .tar.gz package is no longer an Octave-compatible package.
The main code relies on .p files, which obfuscate the code and are unsupported in Octave
Past releases and source code have disappeared and are no longer available for download, both from sourceforge, official website, and github. Therefore it is not possible to download the octave-compatible v1.8 of the tool either.
Related
I'm using NixOS as the distro on WSL (via the excellent setup provided by Trundle: https://github.com/Trundle/NixOS-WSL) and I'd like to install the racket package. If I run nix-shell -p racket, it dutifully downloads (or uses the previously downloaded) the pre-built binary and I can use it just fine. But if I add racket to the environment.systemPackages list in configuration.nix and try to nixos-rebuild test, it starts trying to build things from source. It fails when it gets to gtk (presumably because WSL2 doesn't yet support graphical applications).
Why the difference in behavior? Is there a way I can convince NixOS to use the pre-built racket when filling out the systemPackages? Happy to post my configuration.nix if it would help the diagnosis, though it's really not much of a departure from Trundle's.
Question
Due to the issue in Fix for Octave urlread causing Peer certificate cannot be authenticated with given CA certificates, I cannot install Octave packages on Windows.
Please suggest other ways to install. Particularly I would like to go through Gradients, Gradient Plots and Tangent Planes which requires Symbolic package.
EDIT: this bug is no longer present in Octave v4.2.1, and the issue described in the Question should no longer occur.
Yes, there appears to be a known issue logged on the bug tracker with the current release version of Octave (4.2.0) on windows being unable to connect to https due to the curl issue you identified in the linked discussions/questions. That bug report and the original help list discussion summarize the certificate issue and problem verification. It should be fixed in the next Octave release.
This, however, does not prevent you from installing packages. It only prevents you from using the program to go fetch packages to be installed. You are still able to go to the Octave Forge package site, manually download a package file, and then as described in the Octave manual and help for pkg run the install command.
E.g., you could download symbolic-2.4.0.tar.gz and save it to your current working directory. Then within octave, issue the following from the command line:
pkg install symbolic-2.4.0.tar.gz
NOTE: symbolic currently requires Python and Sympy installed. If you don't already have this on your Windows machine, the package maintainer has a separate self-contained package for Windows that can be obtained from the author's github repository. In this case you would download the package and run the command:
pkg install symbolic-win-py-bundle-2.4.0.zip
Another more tedious option would be for you to compile your own copy from development sources, as the fix has supposedly been pushed to the mxe-octave repository.
When I tried to run a CUDA example (from /usr/local/cuda/samples/) many errors appeared from missing libraries, including libGLU.so, libX11.so, libXi.so and many others. There where installed, but re installing didn't have any effect. Of course compilation couldn't continue.
Some libraries where shown as optional during CUDA installation (by manual installation after finished CUDA installation) and I did not care about them. I didn't keep any log so I lost that information.
I searched for missing symbolic links and also wrong versions of the libraries, but nothing happened.
After a lot of research I found that the libraries are in their devel packages. So I had to install the following (with yum):
libXi-devel
mesa-libGLU-devel
libXmu-devel
libX11-devel
freeglut-devel
Now, this brought a new problem with libGLU at compilation time because of the installation of mesa-libGLU-devel (I was trying with the examples) because the reference to libGL.so is no longer there, so I had to reinstall the NVIDIA drivers, which corrected the broken link.
After that the compilation of examples worked. I found the second part of the solution here
After googling a bit, I did not find anything that stroke as really useful.
I was wondering if there was any ZMQ interface implemented for Octave, I know there is something in Matlab, but I have not tried it yet.
I just put together a port of the matlab version which works great in octave (under ubuntu). So far it's working great for what I need:
https://github.com/esromneb/zeromq-octave
The library has a few limitations (for instance publish always connects out and subscribe always binds to a port) but if you can live with that it's great!
There is a zeromq package available from octave forge which works in octave under linux and windows.
You should be able to install it in octave by running:
pkg install -forge zeromq
(assuming you also have the zeromq library installed)
It supports most of the socket types, including pub/sub, req/rep, push/pull.
Details of the package can be found here: http://octave.sourceforge.net/zeromq/
I use ActiveStates TCL version 8.6.0.0 for Windows x64.
In a script I call:
package require tcom
Tcom is included in the installation but I get the following error:
couldn't load libary "C:/TCL/lib/tcom/tcom.dll": Invalid argument while executing
"load C:/TCL/lib/tcom/tcom.dll"
("package ifneeded tcom 3.9" script)
invoked from within
"package require tcom"
Does anyone understand whats actually missing? C:/TCL/lib/tcom/tcom.dll is installed on my system, so what is the "invalid argument" ?
This appears to be a 32-bit/64-bit issue. You can't mix different bit-sizes within the same process† and you may well have installed a 64-bit build of ActiveTcl 8.6.0.0 under the belief that matching the size of the build and the system architecture is a good idea. Alas, this is not the case. ActiveTcl 8.6.0.0 for 64-bit Windows, for commercial reasons‡, requires an extra product key to access their 64-bit builds of external packages. But you've got the package installed anyway (perhaps from a previous installation of ActiveTcl?) and that appears to be a 32-bit build.
The misleading error from using the wrong size of binary library build is unfortunate (a relatively minor bug stemming from the subtle differences between Windows and POSIX and how Tcl handles the mapping between the two) but I'd bet that's it.
The easiest fix is to:
Uninstall all copies of ActiveTcl that you've got installed, then
Ensure that your C:\Tcl directory really is deleted, and then
Install the 32-bit build of ActiveTcl 8.6.0.0 (which works just fine on Win64-based systems like 64-bit Windows 7 and Windows 8). Once you've done that, you
Use teacup update to get a full set of packages installed and you should get Tcom working.
†Except on ARM with extra trickiness, which doesn't apply here.
‡I'm not going to try to justify them; it's their decision, not mine.