|
On 09/23/2012 02:42 PM, Daniel J Sebald
wrote:
On
09/23/2012 11:19 AM, Michael D. Godfrey wrote:
On 09/23/2012
11:33 AM, Philip Nienhuis wrote:
Still, Octave
refused to properly startup, which could be fixed by
removing the qt-settings file from an earlier version. So,
somehow
Qt's mechanism as it is implemented in Octave is unreliable.
Were you running the latest from the repository? There was a bug
when the Qt settings contained file names for the editor to open.
The file_edit_tab was failing to delete a lexer when loading a new
file so there was a lexer object hanging around attached to
something that no longer existed.
An obvious guess
at the cause would be a setting (or some settings)
that confuse(s) Octave's GUI. Maybe they contained mutually
exclusive
info or so; or -as you seem to suggest- a setting name was
reused for
another setting type (such a mix-up would be sloppy at best).
GUIDE+O should be able to make some sense of an old settings file.
Right now, the old settings isn't so much the problem as is the
presence of some bugs in the code. There are several I'm aware of
because, as Michael noted, I've temporarily routed the STDERR to
somewhere I can observe what is happening.
A more robust
system is needed to keep track across Octave versions of
which settings file entries are used for what settings, and to
help
Octave avoid stumbling across inconsistencies there.
Philip
I just had similar experience:
1. Started octave (current devel system on Fedora 17 x86_64). It
failed
to start properly.
2. Removed the qt_settings file.
3. Started octave, which came up in full screen mode. Not an
appropriate
choice, in my view.
4. I tried left clicking on one of the previous commands in the
command
history
panel on the left. Octave shut down without any indication of
cause.
I think this is where there might be a bug, i.e., the input and
output of the command window. That is, stdin, stdout, stderr
might not be coordinated just right yet.
It
would
help debugging if some indication of the cause could be written
somewhere
when the system crashes.
One of the first things we should work out is not redirecting
STDERR to the GUIDE+O command window. Instead leave that to go to
the console window. That will do two things: one, keep innocuous
Qt warnings (missing fonts, etc.) from showing up in the command
window; two, put errors to the console so that when GUIDE+O
crashes we have some form of a trace of what might have happened.
Unfortunately, it isn't so simple because the pager seems to need
STDERR in some way. If STDERR is not redirected, when the pager
comes up in the command window, keyboard hits must be done in the
console window...
Oh, as I say this just now, that may be a lead on the strange
behavior (bug?) of the command window. Although the GUI is
redirecting STDIN/STDOUT/STDERR for Octave core, that might not
necessarily mean the pager is configured that way in a coordinated
manner. Perhaps Octave core needs to set up the pager I/O the way
Octave's I/O is currently set up. Just a thought.
Anyway, GUIDE behavior is going to be dodgy for a couple weeks as
overlapping bugs are stripped away.
Dan
It is good
to work on the outstanding bugs, but it would help a lot if we
knew what the intended
behavior is. This means, it would help a lot if there were
documentation which specified what
is intended. Then, we could understand the intend and arrange
tests to see if the results match
the intent. After that we could have a useful discussion about
how this should best work. Since
right now I have no idea what is intended I have no real idea
whether what I see is a bug or not.
Michael
|