Re: GUI thoughts

------=_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

<div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Size is not =
the only concern.&nbsp;&nbsp;Even if you only need a few lines of<br>code t=
o do something that Octave already does, it seems likely that
<br>the two implementations will diverge.&nbsp;&nbsp;Octave changes over ti=
me.&nbsp;&nbsp;Bugs<br>are fixed.&nbsp;&nbsp;It seems to me that it would b=
e much better to not<br>duplicate code from Octave in the GUI.</blockquote>=
<div><br>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.
<br></div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But=
 why should you have to do all that?&nbsp;&nbsp;It seems to me you are<br>i=
mplementing your own (limited?) terminal widget, specifically for
<br>this GUI project.&nbsp;&nbsp;Wouldn't it be much better to use an exist=
ing<br>terminal widget that hides all of these details, provides more<br>fe=
atures, lets Octave work as it normally does in an interactive<br>terminal,=
&nbsp;&nbsp;and that you would not have to maintain?
</blockquote><div><br>Well, if you know one for QT4, by all means, point me=
 to it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left=
: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e=
x;">
So you have a history buffer separate from the one that Octave would<br>mai=
ntain using readline (via the comand_editor class)?&nbsp;&nbsp;That means<b=
r>that Octave's history, edit_history, and run_history commands and the<br>=
history_file, history_size, and saving_history variables don't do what
<br>users expect unless you rewrite them to use the GUI history buffer.</bl=
ockquote><div><br>Noted. <br></div><br><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">
But if Octave is off doing some long calculation (say in a Fortran<br>funct=
ion) then nothing is printed and eval_string doesn't return until<br>the ca=
lculation is complete, so the GUI won't respond.&nbsp;&nbsp;Perhaps that's<=
br>the way Matlab works too, but it doesn't seem acceptable to me.
</blockquote><div><br>I think that's what Matlab does too. <br></div><br><b=
lockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 20=
4, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">OK.&nbsp;&nbsp;If p=
eople are working on things that involve Octave internals
<br>(and I don't see how threading could not) then they should be posting</=
blockquote><div><br>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.
<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">| I=
f you want to make Octave thread-safe, that would kick ass, however if I<br=
>
| were tasked with doing it I would be apprehensive.<br><br>Why?&nbsp;&nbsp=
;Is it because you are unfamiliar with Octave internals, or<br></blockquote=
></div><br>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.
<br><br>S=E9bastien Loisel<br>

------=_Part_14459_10747102.1141209313485--