Things to do before GUI-developers can start their work
Subject: Things to do before GUI-developers can start their work
From: C Y
Date: Wed, 11 Jun 2003 07:42:55 -0700 (PDT)
--- Raymond Toy <toy@rtp.ericsson.se> wrote:
> >>>>> "CY" == C Y <smustudent1@yahoo.com> writes:
>
> CY> this issue. Also, communication mechansims between processes
> are
> CY> different on different platforms - on Linux it's pipes for
> example, but
> CY> IIRC Windows cannot handle them, at least not in the same
> way. I
>
> Sockets. Every system we currently support and probably will support
> has sockets because every system has a web browser. :-)
Um. Hmm. OK, I don't know much about those. How hard is it to
program for them in lisp?
Can someone explain to me why everyone likes the math-kernel/GUI setup?
The only benefits I can see are:
1) Allows the creation of lots of GUIs easily.
This is the most compelling reason I can see to add the ability for
Maxima to function in this way, but does not justify it as the default.
2) Allows restart of the "kernel" without the interface dying.
I'm not convinced as to why this is worth the considerable effort
required to set up communication. If things are designed properly,
surely the advantages of a kernel setup can be implimented in a more
closely tied system. And even if there is no way to avoide taking down
the interface with the kernel in such a system, proper handling of
document saving (which should be implimented in any case should the
front end be the one to crash) could save the document. I suppose one
could want to separate them in order to be able to restart the GUI to
connect to a long running math kernel process that didn't die with the
GUI, but is that really worth the pain of separate parts and
communication between them? How would the GUI know what was going on
in the kernel it connects to, or even connect to it if it's a single
thread process? How could the kernel communicate that it was running
and not hung? (I.e. - how would the GUI know it had connected to a
valid maxima kernel?) In a threaded lisp I think a single process could
allow the math to survive the GUI, though I know only a few of the
lisps we run on support threads.
The reason I like the idea of everything running in one image is it
allows a Lisp based GUI to talk to the Maxima system at basically every
level, since all the information is accessible to it by default. I'm
not sure if such a setup would require threads though - quite possibly
it would to be usable. I suppose that limits the native lisp idea to
CMUCL and SBCL currently, which is not so good.
CY
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com