Closed Kreijstal closed 8 months ago
Are you sure it keeps going indefinitely?
One of the final steps when installing a package is creating the doc cache. That step takes pretty long when I try to install the package here. But it eventually succeeds.
You can see it chucking along by monitoring the perl
processes that are being spawned (for makeinfo
), e.g., by watching the Windows Resource Manager.
Are you sure it keeps going indefinitely?
One of the final steps when installing a package is creating the doc cache. That step takes pretty long when I try to install the package here. But it eventually succeeds. You can see it chucking along by monitoring the
perl
processes that are being spawned (formakeinfo
), e.g., by watching the Windows Resource Manager.
it has been going on for around 3 days, should I keep waiting?
also in windows manager there are no perl.exe processes left. Okay, maybe something I forgot to say it is that I am running it from mintty (I've noticed that tends to change behaviour of programs sometimes) Not sure if relevant octave gui is taking a whole core to itself. Are we sure it is not an infinite loop?
Well, it might take a while. But it shouldn't take days. 😂
Does the package show up as being installed after that when you restart Octave? What does pkg list
return?
It might be that the Windows Terminal died underneath Octave's command window (and you just didn't see the final message nor were able to write any more commands).
If that is the case, see, e.g., here for a possible work-around:
https://octave.discourse.group/t/workaround-for-weird-behavior-of-command-window-widget-in-windows/4981
just did ctrl+c, and it killed it, I still have a DMP file for what is worth, not sure how to read it. Also pkg list also seems to hang forever... or at least it has been at least 3 minutes, and pkg list is not returning, taskmanager says octave-gui is using a whole core.
Does applying the work-around from the above link make a difference?
Does applying the work-around from the above link make a difference?
Workaround should not apply to me, because this windows version does not come with winpty, so it uses conhost, by default, something I noticed already, doing it with mintty make it cause problems, even pkg list
hangs forever, using on cmd.exe, it works, at least pkg list
returns, now I am going to try pkg install from cmd.exe there, I hope it will not take long, I guess I'll see you in 3 days
😕 Afaict, the workaround has nothing to do with winpty. Which Windows version are you using? For the third time: Does applying the work-around make a difference? Does it work if you don't use the GUI?
😕 Afaict, the workaround has nothing to do with winpty. Which Windows version are you using? For the third time: Does applying the work-around make a difference? Does it work if you don't use the GUI?
Windows 8, workaround makes no sense, since there is no windows terminal there, only conhost exists. I never used the gui, always started from the terminal.
Ok with cmd.exe it already started doing something (screenshots because I cannot seem to select the text right now)
It seems it threw me into a shell but it kept processing in the background, so I guess it works? I mean at least there are warnings
Are you sure there is no Windows Terminal on Windows 8? ISTR to have read different reports from users on the Octave forum. (Must have misremembered)
I don't have access to Windows 8 to be able to test it.
Afaict, Windows 8 is no longer supported by MSYS2:
https://www.msys2.org/news/#2023-01-15-dropping-support-for-windows-7-and-80
Maybe, that's the reason for the strange behavior of the pty?
I just tested here (Windows 11) with mintty and Windows Terminal using Octave's CLI. I can't reproduce the issue. I'm sorry. But I probably can't help you with that (apart from the advice to update to a supported OS).
the problem was that you should not use mintty when there is no conpty, I think that is the workaround, thank you.
I think cygwin/msys2 switches to normal pty behavior when conpty is absent. The conpty feature can be disabled with MSYS=disable_pcon
environment variable.
Description / Steps to reproduce the issue
pkg install -forge statistics
Expected behavior
Eventually it should return error or give back control, however it seems it does not return from this function.
Actual behavior
It keeps going indefinitely.
Verification
Windows Version
MINGW64_NT-6.3-9600 Rainb 3.4.10.x86_64 2023-12-22 10:06 UTC x86_64 Msys
MINGW environments affected
Are you willing to submit a PR?
No response