Re: MinGW version binary gobbledygook error messages?

[John W. Eaton]

On 28-Feb-2006, Sebastien Loisel wrote:

| You've pointed out to me several times that eval_string() isn't the right
| way of doing things. I've been wanting to change to command_editor, but the
| class is large and I don't understand it. Where do I start?

I'm not sure that the command_editor class is really what you want
either.  It just provides some of the machinery to make the code in
src/input.cc work.

The terminal/readline-based Octave calls yyparse in the main loop.
That calls yylex to get a stream of tokens.  That uses the YY_INPUT
macro, which is redefined in lex.l to call octave_read, which is
defined in src/input.cc.  That eventually uses the command_editor
class to decode the prompt, get input, etc.  Mostly, command_editor is
just a wrapper around readline, so we can avoid calling it directly,
which allows us to localize the calls to readline, avoiding the need
to have a lot of

  #ifdef HAVE_READLINE
  #else
  #endif

The idea is that if you wanted to replace readline with something
else, you would just need to provide a new concrete implementation of
the command_editor and command_history classes (via derived classes).
You would not have to change any code in the rest of Octave, so no
hunting for ifdefs.  We currently have two concrete derived classes
for command_editor, both defined in cmd-edit.cc.  One is gnu_readline,
which provides readline, the other is default_command_editor, which
just gets input without any command editing.  The
default_command_editor class is a proof-of-concept and is used when
the --disable-readline configure option is used.  For command history,
we only provide gnu_history because the base command_history class can
handle the case of no history library available (simply don't save or
provide access to any command history).

This is a bit of a diversion, but I thought it would be helpful if you
or someone else needs some background for the design.

I have some other thoughts about possible ways of integrating Octave
with a GUI that do not require you to reimplement what is in input.cc,
pager.cc, etc., which seems to be where you are headed if you continue
to use eval_string as the way to call Octave from your GUI.  I will
try to post some of these ideas in a new thread later today.

If you are persistent, you could probably make things work with
eval_string, but I think you will end up duplicating a fair amount of
Octave in one way or another.  I think it would be best to avoid doing
that, as the parts you will duplicate are not necessarily static, so
eventually the GUI will behave differently from the
terminal/readline-based version of Octave.

jwe