Things to do before GUI-developers can start their work

--- Raymond Toy <toy@rtp.ericsson.se> wrote:

> I don't think so.  It allows maxima to send over it's internal
> structures without having to massage it.

True.
 

> Yes.  But "can" is probably too small to contain the worms. :-)

That figures.

> These all seem very complicated to get right.

Yes, unfortunately.  Although some of it hopefully can be reduced to a
few conditionals.  Basically:

1) case 1 - lisp has threads, kernel local.
 
   When sending maxima statement, execute it in new thread. GUI stays
responsive while evaluation proceeds. Everything else operates
hopefully as normal.  

2) case 2 - lisp doesn't have threads, kernel local.

   Things operate in series - execute command, then return control to
the GUI.  Hopefully figure out some way to allow the user to end the
evaulation at need.  This is not optimal.

3) case 3 - kernel not local - either threaded or not threaded case.

   When changing any setting using the interface, socket call is made
to send the update to the math kernel.

I guess if the calling were handled properly it could be relatively
transparent, but the problem is:  what if the maxima-kernel defines or
changes something in the course of an operation that is not
automatically sent back to the interface?  Let's say, for example, I
load my physconst package and I want the interface to change the color
of any variables I have defined in my graphical button grouping for
greek letters.  The interface doesn't know the variables have been set
because Maxima hasn't told it, and Maxima doesn't have any knowledge
that the interface wants to do anything about the newly defined
constants.  Some check has to occur.  I suppose a way to handle it
would be to write the package in such a way as to have it call the
interface and make the updates, but that puts a lot of burden on the
package maintainer.  Is there any way to have Maxima report all changes
it has made after performing an operation, so the interface can recieve
that report and make any updates it thinks it needs to?  That would be
the way to make a socket interface work properly - have a full report
of state changes that can be made on a per command basis.  Given that,
I think I would be OK with the socket communication between processes
since each process would know everything going on in the other one, and
the communication could be in normal lisp internals which wouldn't need
any fancy communication protocals.

> In any case, he who has working code wins.  Talk is just talk.
> 
> Ray, who's just talking....

That makes two of us.  If/when I do actually write something, I'd like
to be doing it the "right way."  What the "right way" is turns out to
be a tad fuzzy...  although I like the idea of a "communicate all
changes" policy between the processes over a socket connection.  I
think that might give us the native lisp benefits and still allow the
GUI/kernel separation people seem to like, by in effect creating two
lisp environments that always have all the same information and provide
the same running conditions.  It might also allow the following really
cool feature:  if either the kernel or the GUI go down, in theory the
other could retain full information about the state of that part of the
program - if the GUI went down, when a new one connected the kernel
could supply it with the exact state of the interface before it went
down, and a kernel restart could reproduce the complete internal state
of the kernel without having to reevaluate all the mathematical
expressions.  Might be really good for debugging too.

It's supposedly a good policy of software development that coding is
the last thing that happens - you figure out what to code before you
code it.  It's especially useful in a case like this, where there is so
much to consider that could impact design decisions.

CY

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com