re: front & back end communication / was GUI ...

--- Martin RUBEY <rubey@labri.fr> wrote:
> On Thu, 12 Jun 2003, C Y wrote:
> 
> > 
> > Maybe you can help me straighten this out in my head...
> > 
> > I'd like to have a lisp based GUI for Maxima which is aware of what
> is
> > going on in the kernel, but the consensus is that we want to use a
> > kernel-GUI connection so that implies a certain disconnection
> between
> > the two.  
> 
> I think I was misunderstood here (although it might still be
> consensus)
> 
> When I seed that I'd like to see kernel and user interface seperated,
> I  did *not* mean that the shouldn't be in the same lisp image. What
I
> meant to say is that there should be a *very* well defined interface
> between the two packages. As you know I'm very much encouraging the 
> possibility of using maxima directly from lisp, I don't think any 
> different for the user interface. 

Ah.  But this probably cannot be made fully robust within a single lisp
image without the use of threads - for one thing, the entire interface
will be unresponsive while a math command is being completed, which is
undesirable.  And neither clisp nor gcl has threads.

I'm rather liking the idea of parity between a separate GUI and kernel
process now that I think about it - it adds a certain robustness to the
system.  Given the power of modern computers, keeping what amounts to
two copies of the system state shouldn't be a big deal.  For non lisp
GUIs the kernel process will be useful as well - it can operate the
same way as normal, only with more minimal communication between the
two processes.   The problem is I don't know if it is possible to
impliment full disclosure between the two lisp environments.  What
you'd want is something like each time a variable or function or what
have you is defined or changed in one place as part of a command, the
system records that in a temp array.  Then, once the comand is ready to
return to top level, it sends the changes that have been made to the
other process as well via sockets.  Doing this for all changes is the
easiest way to make it work, since predicting what one process or the
other would want to know would be difficult and possibly not static
with time.

> So, my dream setup is as follows: (this is directly from the top of
> my head, beware!)
> 
> maxima math
> 
> maxima parser
> 
> maxima user interface 
> 
> and each of the packages has clearly defined entry points. This
> should not  rule out the possibility that the user interface accesses

> variables of the math stuff, it only favors lisp (probably).

Something like this would work quite well in single or multiple
processes, actually.  The problem is I have no idea how to define the
entry points in a sensible way.

> I hope I was able to get the idea across, however I think it is still
> too fuzzy in my head. Please ask me for clarification.

I guess my main concern is how to define "entry points" and what they
would be.

CY

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