Ralf Hemmecke wrote:
>
> > Anyway, whatever happens to 'sman' I hope that
> > '-nosman' will be obsolete in the future.
>
> That's fine with me.
>
> My point partially is that I am not programming anything new. There are
> already nice interfaces. Jupyter is one of them. It's just that one has
> to connect them to FriCAS.
>
> The problem with these interfaces is that when they need to terminate
> the underlying program they usually expect just one process and kill
> them, that does not always reliably terminate subprocesses, that's at
> least what happened to me. In a previous ifricas version the jupyter
> notebook started a script that called "fricas -nox". And already having
> that and not "exec fricas -nox" left lots of sman and AXIOMsys processes
> running while I was experimenting with the interface. I'm not sure
> whether sman will ever be able to work with such frontends if these
> frontends have a certain (incompatible) idea of how they kill and
> restart an underlying backend.
>
> If you think that sman can be made working reliably with such frontends,
> I certainly don't insist on starting AXIOMsys directly.
It is all matter of programming. AFAICS the worst offender
is AXIOMsys (it seems to be caused by Lisp). Sometimes other
processes continue running, but this was rare enough so that
up to now I spent time on something else. But this is curable,
apparently original authors ignored some priciples of good
programming.
> However, my previous mail was asking whether there is some more things
> except AXIOMsys, HyperDoc, and the Graphics that managed by sman.
> Reading sman.c it looks like CLEF and some session manager program is
> started and spadclient.
In the past there was 'nagman'... 'clef' is only needed
for command line interface, other interfaces disable it.
'spadclient' should go away (it is part current problem).
Session manager is 'sman': 'sman' forks into two processes.
> Would you miss it if it weren't there and we had only AXIOMsys?
> I (for my taste) probably wouldn't miss anything if I just start
> AXIOMsys in "jupyter notebook".
Well, if someone implements graphics and hyperdoc replacement
inside "jupyter notebook", then I probably would not miss
anything when using "jupyter notebook". But I like text
interface and I would miss graphics and hyperdoc there.
Other folks like Emacs and Texmacs interfaces, it would
be nice to allow graphics and hyperdoc with them.
> If you want to keep sman and its subprocess structure, fine. It's open
> source development and FriCAS is your child.
You can not really avoid subprocess structure or some equivalent.
Namely moder UI-s work exchanging messages, there is constant
chatter. The computational engine may be busy for long time,
so something else must take care of messages. Now, we could
use threads instead of processes, but this has its own
pitfals. Also, ATM AXIOMsys is a Lisp process which makes
some restrictions on non-Lisp code, so it make sense to put
some activity in other processes. Of course, in priciple
this subprocess structure can be simpler and handled
entirely by the frontend. But then it is much harder to
share code between frontends. Anyway, I do not see
subprocess structure as a big deal.
> My direction would be to concentrate on algebra and let frontend be
> maintained by somebody else (the jupyter people for example). We just
> need the glueing code.
That is mostly what I am doing now. However, I am concerned
with long term survival. Hyperdoc and graphics are 1990
technology which works now -- that is 25 years of working.
And likely to work for long time. If we get some cutting
edge technology frontend, it may be easily obsoleted in 5
years. So we need to think how to manage updating and
evolution.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
