Thu 23 Jan 2014 05:17:56 PM UTC, comment #16:
That (invoking octave-gui.exe directly and placing it in /bin rather than libexec) is exactly what John D. patched in the MXE builds.
Works well.
|
Thu 23 Jan 2014 05:00:12 PM UTC, comment #15:
Is there any resolution here? It seems like we can/want to run octave-gui.exe directly on Windows platforms instead of the wrapper.
|
Sun 24 Nov 2013 10:42:50 PM UTC, comment #14:
There are solutions, or workarounds if you like, that do work well.
I don't see a problem in using --force-gui flags on Linux, or calling octave-gui.exe on Windows. It just has to be outlined somewhere in a word or two.
So in any case we have the first tip/hint for Linux packagers :-)
|
Sun 24 Nov 2013 09:44:34 PM UTC, comment #13:
Sorry, you are right about requiring --force-gui. I remember this problem now, and Mike is correct that it is because we want Octave to still be able to execute scripts from stdin. I must have misinterpreted one of my tests.
In any case, I don't see that we can fix this problem without redesigning how we want Octave to start.
|
Sun 24 Nov 2013 09:38:26 PM UTC, comment #12:
On Linux I get the same thing as Philip. I think it is because if Octave is not reading from a terminal, it assumes a script on stdin. Then because there is no stdin when running from a launcher, it sees EOF and exits.
I cannot run from a launcher or from Alt-F2 (run program in gnome-shell) without --force-gui. Both octave and octave-gui launch nothing visible to me.
|
Sun 24 Nov 2013 09:31:46 PM UTC, comment #11:
I just checked again, but from the KDE menu and using a launcher I only get Octave-GUI to run using "..../octave --force-gui"
My system is Mageia-2
Using the launcher to start octave-cli does need a terminal.
In the output of "ps ax" I see
28274 ? Rl kdeinit4: konsole [kdeinit] --workdir ~ --caption=GNU
28277 pts/1 Ssl+/usr/local/bin/octave-cli
|
Sun 24 Nov 2013 09:16:22 PM UTC, comment #10:
It should work to start "octave" without the --force-gui option.
That works for me from a launcher. You don't see two processes in that case because the launcher is executing the octave process without a controlling terminal so the wrapper program can exec instead of having to fork, give up the controlling terminal, and then exec.
Using a launcher to run octave-gui directly (not in a terminal) should work. Running octave-gui with a terminal will not work properly because you'll have a controlling terminal and less won't work properly (it will be looking to the controlling terminal for keyboard input).
However, running octave-gui directly from a launcher is not working properly for me. I'll see if I can figure out why.
|
Sun 24 Nov 2013 08:37:01 PM UTC, comment #9:
Of course I'll help. But mostly for MinGW as I have experience on mainly that platform as regards Octave.
As to the MinGW binary (through mxe-octave) I suppose there's little hints and tips needed on this specific subject; adapting the shortcuts in the makeinst-script.sh is about all that is needed (I suppose the majority wants an ".exe" installer rather than a zip file).
On Linux I simply don't see the extra octave invocation, not even with "ps ax".
FYI, I start Octave through the KDE Menu, or a desktop launcher, invoking:
"/usr/local/bin/octave --force-gui".
Any other command line option (/usr/local/bin/octave; /usr/local/bin/octave-gui) doesn't work; unless I select "run in terminal".
|
Sun 24 Nov 2013 07:48:45 PM UTC, comment #8:
It seems to me we need some way to fully emulate execv. Then the new process (octave-gui or octave-cli) would completely replace the original octave process and we wouldn't have the two programs running.
Or, we could just redesign the way we invoke Octave on Windows (or maybe all systems). It's complicated by having to deal with the controlling terminal problem on Unixy systems and wanting Octave to not completely detach itself from the terminal if it is started from a command line shell. I think this is something we could look at again after the release, especially if users seem confused by the existence of octave-cli, octave-gui, and octave with the --no-gui and --no-gui-libs options.
My guess is they will be confused and we will be looking at this again.
And yes, we should have some tips in the NEWS file, or in a separate file that gives hints for packagers. Would you like to help write those tips?
|
Sun 24 Nov 2013 07:39:03 PM UTC, comment #7:
What you say is essentially this:
The octave-3.7.7+ (& shortcut octave) executables are only required for batch file processing.
It is only when starting the gui through octave that this issue arises.
I do think that packagers should be (made) aware of this.
Would you mind if I set status to "postponed" & severity "minor"?
My reasoning:
I think it is preferrable to not have unneeded windows and processes around the place. But as there is a workaround the priority is probably low.
If you don't agree I'll close this bug (or you can do it as well)
Thanks for the explanation
|
Sun 24 Nov 2013 05:33:30 PM UTC, comment #6:
I don't think the changeset would have any impact on startup time of the GUI.
If you agree with the necessity of the changeset and the possible workaround in Windows (it's easy enough to associate a shortcut with octave-gui.exe instead of octave.exe), please close this bug report.
|
Sun 24 Nov 2013 05:20:18 PM UTC, comment #5:
Ok that is different from what I'm seeing on Linux, I'll open another bug about that.
|
Sun 24 Nov 2013 05:19:04 PM UTC, comment #4:
Sorry, I now understand the cs in question makes sure Octave can be called in a batch script.
Makes sense as for e.g., create the html for OF packages I always had to do it in Octave itself; calling it from MinGW as outlined in the OF developers section didn't work for me.
On a perhaps related note, since a few days my mxe cross-builds take considerably longer to show the GUI. Is there a connection with that changeset?
|
Sun 24 Nov 2013 05:14:45 PM UTC, comment #3:
Do I understand correctly that the cs is required only for being able to run ./run-octave from a build dir?
Starting octave-gui(.exe) of octave-gui-3.7.7+(.exe) indeed avoids the extra cmd32.exe window.
Starting octave.exe with the --force-gui option only shows the taskbar button for the cmd32.exe window for a while, but the GUI never starts.
|
Sun 24 Nov 2013 04:57:03 PM UTC, comment #2:
I think this is a result of this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/1329866151be
The problem this changeset is solving is to keep the octave "wrapper" process active while the child process (CLI of GUI) is running. And this is exactly what you're seeing. The wrapper process is the one executing in the cmd32.exe window.
I believe this changeset is still required. Without it, the wrapper will exit as soon as the child process starts (the child process running in a "detached" mode). This makes it impossible to use run-octave with the expected bevahior. Or calling "octave" in a shell/batch script: something like "octave -q --eval 'my_long_function()'" will exit before my_long_function is actually executed.
I think a simple workaround to avoid having the pending cmd32.exe window is to call octave-gui directly, instead of using the octave wrapper executable.
|
Sun 24 Nov 2013 04:52:42 PM UTC, comment #1:
I actually see similar behavior with a Linux build today. If I start the GUI from a terminal (octave, octave --force-gui, or octave-gui) the command never returns to the shell even after the GUI exits. Ctrl-C does not kill this process, I have to use Ctrl-\ (sends a QUIT signal) to get it to exit.
|
Sun 24 Nov 2013 11:36:56 AM UTC, original submission:
(Probably a mere cosmetic flaw)
When starting Octave GUI, I now see two Octave windows/processes in the taskbar:
1. A (minimized) cmd32.exe window (the process is called octave-3.7.7+.exe in Task Manager)
2. Octave GUI (octave-gui.exe in TM).
Manually closing windows 1. doesn't affect 2; nor does repeatedly typing Ctrl-C in (a restored) window 1.
Closing Octave ends both windows as it should.
So no problems AFAICS (unless needlessly occupying 1324 KB RAM is a problem).
IIRC until a few days ago (but could be earlier) I always saw window 1 after starting Octave, but that disappeared as soon as the GUI appeared.
(build details: MXE-cross build (cs 17989:4465699450c2 configure.ac: Don't use internal macro variable ax_blas_f77_func_ok) made Nov. 23)
|