I recently installed Maxima (5.45.0-Windows) on my 64bit, windows 7 machine, following the guide here.
However, when I try to use the GUI, wxMaxima I get an error on launch, saying that the maxima.bat file could not be detected, and it suggests that Maxima was not properly installed. The error message in full is;
"Can not start Maxima. The most probable cause is that Maxima isn't installed (it can be downloaded from https://maxima.sourceforge.io) or in wxMaxima's config dialogue the setting for Maxima's location is wrong."
However, in the Edit-Configure-Maxima menu, under Maxima program I have the path C:\maxima-5.45.0\bin\maxima.bat which should be correct. In fact, when trying to run maxima commands through the command-line promp or through xmaxima, it works just fine.
The GUI however, fails to recognize my maxima.bat file, even when moving it to a different place and 'user specifying' the path, the GUI console is stuck on
Maxima Excited...
Restart Maxima with 'Maxima-Restart Maxima'
But trying to restart Maxima has no effect. Restarting the entire GUI program, or running it as administrator doesn't help either.
I've searched the web for this, but all the search results seem to concern Linux installations or a connection error wrt. internet, which doesn't seem to be my problem here.
i have encountered the same issue (previous versions, now also 5.45.1 on windows 10). in my case this is resolved by manually deleting the "user config files" under %USERPROFILE%\maxima. these files are left over from the previous version & not removed by the un-installer.
try one of the following, then start wxmaxima again.
[command line] del %USERPROFILE%\maxima*.*
[explorer] C:\Users<your user ID>\maxima
Related
Trying to update my 32-bit Cygwin install on a Windows 10 64-bit fresh install and every setup-x86 I have tried fails with errors.
I had it all working on my old system, which was a Windows 7 upgrade to Windows 10. My 3rd party SDK with Cygwin plus an upgrade was installed a good few years ago while on Windows 7 then did the Windows 10 upgrade thing. I could still compile my code for an embedded processor device with no errors after that.
But Microsoft corrupted my system with the last update (December 2022) so my system was unbootable and irreparable by any of their troubleshooting Advanced methods.
So I put a new hard drive in and installed windows 10 from scratch.
Two weeks later I have reinstalled much software but now I am at my SDK re-install and cannot get any Cygwin version to download.
I have a 3rd party SDK which instructs me to install their Cygwin first (version 1.5.18) then remove some environment variables, then go to http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html and Follow the “Dead Simple Instructions" and go for "any version 2017 +".
After downloading the files I must copy the directory to my original install directory, thus upgrading the install.
I just cannot download anything though.
I went to that time machine page and was totally confused. I noticed they said "this is the last 32 bit install" on several places, so I tried clicking on all those setup-x86 links.
I tried running the downloaded setup-x86 files from the download directory but each one failed.
On most of the more recent setup-x86 files,(like 2.924) it shows a small blue square telling me Windows protected me etc. I click Run anyway and then it says "Cygwin is not supported on 32-bit windows".
So I tried earlier versions like 2.909 and they show the interface; I choose download, then choose the download directory ( a folder on my desktop) then I have tried both direct connection and use system proxy; then I select a mirror (tried all of them, I think) and it begins some action then stops with errors like:
"https:\cygwin.mirror.constant.com\x86\setup.ini line 12: The current ini file requires at least version 2.924 of setup. Please download a newer version from https://cygwin.com/setup-x86.exe"
But I have already tried 2.924 and it gives the "Cygwin is not supported on 32-bit windows" error!
With setup-x86-2.874.exe, it shows the interface etc. but in the mirror list all I see is http://update.setup.invalid.
With 2.774 it does the interface then "Unable to get setup.ini from 'my selected mirror url'.
Then I tried that page https://cygwin.com/install.html#unsupported, where I tried the circa urls and did these from an Administrator command line, as they say. No good- errors.
Under "Dead Simple Instructions"(no they are not) I followed the link to the machine top level snapshot index, but each link their only gives a plain text list of files- nothing downloadable!
Anyway, copied a url link and then at step 4 it says click for setup-x86. So I did but that blue windows protection square appears. I say run anyway but then it says "Cygwin is not supported on 32-bit windows"!
I am at my wits end! It all worked fine on my old system until Microsoft ruined it with their updates.
How can I get a newer cygwin update for my v1.5, s the 3rd party instructions say???
Aha! I believe I have finally got this to work.
I just found a new release of the instructions for the 3rd party software SDK. They mention version 2.9.0 as the new version they are moving to.
I cannot access their download but I went back and read the Cygwin Time Machine page carefully again (http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html).
Under "Dead Simple Instructions", I looked through the list of dates and versions (http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/index.html) and found 2.9.0-1; surely close enough, eh?
So I copied the URL shown there.
Step 4 Run setup-x86.exe downloaded the setup file and Itried it from an Admin CMD prompt, adding the -X and -D switches. It failed with the 32 bit error, as before.
OK so I read again and near the bottom of the page I spotted "Cygwin Setup Archive".
Ah... I went to the link provided there (http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/setup/setup.html) and found setup-x86-2.901.exe.
After it downloaded, I again used the command prompt to run this and an interface appeared.
I was able to choose the existing install directory, the temporary download directory and add the URL I had copied earlier.
It proceeded to get the list of packages correctly.
I then selected to view files that were installed but may need updating and clicked Next.
It all went correctly. Thanks to Doug who offered help already.
So there is a way to do this.
If anyone was looking for the solution, I found the answer in the Cygwin mailing list. You must launch the setup-x86.exe (setup-x86-2.924.exe) with the --allow-unsupported-windows option --site circa_URL arguments, much like the -X switch was used on prior legacy installers to disable signature checking. circa_URL here is a mirror of legacy repos for Cygwin, where http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 is the suggested url in the mailing listing post.
Apparently, if you are on a true x86, non-64-bit, Windows OS, this flag is not necessary, though I think the repo mirror may be required.
We use Erlang OTP because it is bundled with a business application my company uses (as part of a RabbitMQ installation). On our development and test servers, the entire installation went smoothly without any issues. On the production system, however, Erlang OTP installs but fails to launch afterwards. When I doubleclick erl.exe I get an error popup:
The entry point “llround” was not found in the DLL “C:\Program Files (x86)\…\Erlang-21.3\erts-10.3\bin\beam.smp.dll”. (Translated from German, path clipped)
I am completely new to Erlang, so I do not even know whether there are any logs that I should provide. In the Erlang directory, I cannot find anything that looks like a log. The Windows event log shows basically the abovementioned error message plus a message saying that the Erlang VM crashed instantly (wrong distribution name?) – but that seems to be just a follow-up to the root cause of the problem with the DLL.
As I said, erl.exe opens without problems and displays a command prompt when launched on the test or development system. The setup there is almost identical to our production server. We tried removing Erlang and reinstalling it but to no avail. We even restored the VM to an earlier point an did a fresh install of the entire application. Short of setting up another pristine VM, is there any way of getting Erlang to work on the existing system?
I'm getting an error when installing a more recent version of the Windows Software Development Kit on my computer.
Each time I'm trying to install it (wherever it's, my B:\ drive or C:\PROGRA~X) I get that error (at 33% of the "installation"):
An error occurred while installing Windows Performance Toolkit. Log.
The folder path 'Windows Toolkit' contains an invalid character.
Review the setup log files, or contact your system administrator.
So I then decided to login in an other user (and install in it's program folder), and it didn't worked.
I checked the logs and it simply says that there's an invalid character somewhere but there's no more details.
Here is the log files given by the installation program to check the reason of the error (pastebin).
(Also note that in the logs you'll be able to see references to D:\Windows Kits\10\ which is weird as I actually don't have any storage devices associated to D, but I had one before).
I also tried to simply uncheck Windows Performance Toolkit in the installation settings (it's the 1st one) but it didn't worked as it will simply display the same error with the next Toolkit to be installed (and the error still displays at exactly 33% of installation).
Is there any known solutions to solve that problem ?
There's probably a registry key which contains an invalid character due to some reasons but I don't know which one it could be if it was the case...
I really need to install the Windows SDK and then install the WDK, and I don't really want to reset my OS for that.
If you need more information or details about something concerning my system I'll provide them.
I also encountered this problem.
By checking the log, I found that this problem is caused by the string in the registry.
Search in the registry and delete this field.
That's how I solved it. enter image description here
I have a very old application which I've moved from computer to computer over the years. I was probably running NT or maybe even Windows 95 when I got it. It still runs fine, but I recently tried to back up some of the files I created using it and I find that they are hidden. When I run the app I can read them or write them, but when I try to access them either via the command line or Windows Explorer they are not found. I can see them from the cygwin command line, but I would really prefer explorer.
My theory is that this is because my app is so old that it is putting user data in c:\ProgramFiles(x86)\MyApp\data rather than in some User\AppData directory which is what more recent versions of Windows are happier with.
What I've tried:
Using attrib to remove hidden attributes (failed with permission issue)
Same, but running attrib in cmd window with admin privileges (no permission error message, but the files do not subsequently show up)
Copying using cygwin command line (got unhelpful message "omitting directory `data'")
Any suggestions what I could try next? I am running Windows 7.
I would happy with a fix that I could do once and would fix it for good (setting permissions somehow?); I would be satisfied with a workaround like "run the following command every time you want to back files up").
Edit: I noticed something strange which may be a clue for someone more knowledgeable than I am: for files which have been modified recently, as opposed to created, doing a dir shows the file information for the old version, even though cygwin shows the new information and that's what I see when I read the file using the app.
Have been running Python 2.7.2 for several months, was using the 32-bit version on my 64-bit computer.
Today ran the installer for 2.7.3, 64-bit. Now I cannot get idle to start. I see answers here for Python in program files, I am running Win7, and I believe the correct location for this machine is in C:\, not in program files. At least that is where I had 2.7.2 and it worked.
So trying
C:\Python27\Lib\idlelib\idle.py
or
C:\Python27\Lib\idlelib\idle.pyw
neither of those would open Idle. With the .py one a console window flashes open for a split second and disappears. On the .pyw one, nothing at all happens as far as I can see. And the pyw one says right on the screen in File Type: "no console"
The old shortcut in the Start menu, under properties says 'target: python 2.7.2', but I don't see a way to change the target.
Also tried opening from Powershell, command line, Python command line, run. None of those worked.
When I downloaded 2.7.3, it said it was overwriting the files in Python27.
Now uninstall offers two programs to uninstall: 2.7.3 and 2.7.2 , but as far as I can tell there is a single Python program on disk and that one thinks it is 2.7.3. I started to uninstall and try a fresh install, but thought I'd ask first rather than risk further screwing up my machine. Thanks in advance for any help. I did read and try to use all the answers in similar questions here on the site.
I ran in to this today. Basically there was already an older version installed and installing over it (I think it was 2.7.2) with 2.7.3 64 bit broke it bad.
At first the CLI python would work but IDLE refused to launch without even an error. Uninstalling/reinstalling did nothing several times, and the problems got weirder as it couldn't find the msi's it had just downloaded, etc. Then I noticed that it wasn't deleting everything in the Python27 folder.
Manually deleting the folder wasn't enough and I found that it was storing another folder under App Data\Roaming (Windows 7). Removing this one finally allowed the re-installation to work (and show up as a newly installed program instead of acting like it had always been there by not highlighting it).
I was about to give up on the 64 bit version and try the 32 but it seems like the Python uninstaller/installer aren't cleaning everything up properly file wise (if it were registry entries I'd still be digging).