From graphics-request at octave dot org Wed Mar 1 04:37:02 2006 Subject: Re: GUI thoughts From: "Sebastien Loisel" To: "John W. Eaton" Cc: "octave graphics and gui mailing list" Date: Wed, 1 Mar 2006 11:35:13 +0100 ------=_Part_14459_10747102.1141209313485 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > Size is not the only concern. Even if you only need a few lines of > code to do something that Octave already does, it seems likely that > the two implementations will diverge. Octave changes over time. Bugs > are fixed. It seems to me that it would be much better to not > duplicate code from Octave in the GUI. I'll give dup2 and pty's a shot, because I want to get rid of the cmd.exewindow that I need to have around just in case Octave calls an external shell command like ls. I'll let you know how much that helps. I'll look at the code you sent the previous time for inspiration. It might take a while though. But why should you have to do all that? It seems to me you are > implementing your own (limited?) terminal widget, specifically for > this GUI project. Wouldn't it be much better to use an existing > terminal widget that hides all of these details, provides more > features, lets Octave work as it normally does in an interactive > terminal, and that you would not have to maintain? Well, if you know one for QT4, by all means, point me to it. So you have a history buffer separate from the one that Octave would > maintain using readline (via the comand_editor class)? That means > that Octave's history, edit_history, and run_history commands and the > history_file, history_size, and saving_history variables don't do what > users expect unless you rewrite them to use the GUI history buffer. Noted. But if Octave is off doing some long calculation (say in a Fortran > function) then nothing is printed and eval_string doesn't return until > the calculation is complete, so the GUI won't respond. Perhaps that's > the way Matlab works too, but it doesn't seem acceptable to me. I think that's what Matlab does too. OK. If people are working on things that involve Octave internals > (and I don't see how threading could not) then they should be posting Well, the first stab for Workshop at least does not involve Octave internals. It involves starting a thread for Octave and only calling into Octave from that one thread. So Octave isn't threaded. | If you want to make Octave thread-safe, that would kick ass, however if I > | were tasked with doing it I would be apprehensive. > > Why? Is it because you are unfamiliar with Octave internals, or > I'm apprehensive of threading large applications, especially programming languages, but maybe there's a good reason why threading Octave is simpler than I think. I mean, not knowing anything, I can imagine that you'd end up sticking a mutex into every variable or something, and there's certainly a performance cost. But from your reaction, this must not be the case. S=E9bastien Loisel ------=_Part_14459_10747102.1141209313485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Size is not = the only concern.  Even if you only need a few lines of
code t= o do something that Octave already does, it seems likely that
the two implementations will diverge.  Octave changes over ti= me.  Bugs
are fixed.  It seems to me that it would b= e much better to not
duplicate code from Octave in the GUI.
=

I'll give dup2 and pty's a shot, because I want to get rid of the= =20 cmd.exe window that I need to have around just in case Octave calls an exte= rnal shell command like ls. I'll let you know how much that helps. I'll loo= k at the code you sent the previous time for inspiration. It might take a w= hile though.

But= why should you have to do all that?  It seems to me you are
i= mplementing your own (limited?) terminal widget, specifically for
this GUI project.  Wouldn't it be much better to use an exist= ing
terminal widget that hides all of these details, provides more
fe= atures, lets Octave work as it normally does in an interactive
terminal,=   and that you would not have to maintain?

Well, if you know one for QT4, by all means, point me= to it.

So you have a history buffer separate from the one that Octave would
mai= ntain using readline (via the comand_editor class)?  That meansthat Octave's history, edit_history, and run_history commands and the
= history_file, history_size, and saving_history variables don't do what
users expect unless you rewrite them to use the GUI history buffer.

Noted.

But if Octave is off doing some long calculation (say in a Fortran
funct= ion) then nothing is printed and eval_string doesn't return until
the ca= lculation is complete, so the GUI won't respond.  Perhaps that's<= br>the way Matlab works too, but it doesn't seem acceptable to me.

I think that's what Matlab does too.

OK.  If p= eople are working on things that involve Octave internals
(and I don't see how threading could not) then they should be posting

Well, the first stab for Workshop at least does not inv= olve Octave internals. It involves starting a thread for Octave and only ca= lling into Octave from that one thread. So Octave isn't threaded.

| I= f you want to make Octave thread-safe, that would kick ass, however if I | were tasked with doing it I would be apprehensive.

Why?  = ;Is it because you are unfamiliar with Octave internals, or

I'm apprehensive of threading large applications, especially pro= gramming languages, but maybe there's a good reason why threading Octave is= simpler than I think. I mean, not knowing anything, I can imagine that you= 'd end up sticking a mutex into every variable or something, and there's ce= rtainly a performance cost. But from your reaction, this must not be the ca= se.

S=E9bastien Loisel
------=_Part_14459_10747102.1141209313485--