Ralf Hemmecke wrote:
>
> > OK. A little comment: in the past only sman looked at command
> > line arguments, so the code was reasonable. I hope that in
> > the future we will be able to use sman with frontends.
>
> Well, maybe that works with sman, but I don't really want to work on
> this. Certainly, in the near future, we will not abandon
> sman/graphics/hyperdoc, but I'd rather like to invest my time in making
> the user interface more modern.
>
> For me HyperDoc is only a fallback for things I don't yet have. But
> there is fricas.github.io and the pdf-version of the book. Both is more
> easily searchable than hyperdoc. Thanks to Kurt, fricas in the Jupyter
> notebook is already working quite well. That would probably allow the
> interactive part (examples) to be demonstratable via the notebook format.
>
> Graphics, I don't currently use, but we should certainly bring that also
> into the notebook. Whether it is with the current machinery or a
> complete new graphics stack is not so much an issue, but I think the
> goal must be to remove the need for X in the long run.
>
> Suppose you get a hyperdoc replacement and graphics replacement. What
> else is sman used for than to control the interaction of AXIOMsys with
> these subsystems?
I think you should take a more high-level point of view. There
is a need to coordinate various user interface actions. And
there should be a single point of coordination. Current sman
problems (inablility to use sman in pipe, etc) are because
this principle is violated. More precisely, sman tries to
be such coordination point but has two uncoordianted chanels
to AXIOMsys: sockets and pty. And without apropriate
coordiantion point other interfaces are likely to face
similar problems. Now, you say this is not a problem because
you want to implement everthing in one interface and
designate other things as obsolete. Well, IMO having
"one true" interface without alternatives would limit
usefulness of FriCAS. OTOH reimplementing all interface
stuff for each interface is bute force approach, we can
do it partially but I doubt that we have manpower to
do it well and consistently. To make it clearer:
each interface needs a coordination point. You can
implement a coordination point per interface and then
the interaces are exclusive: one coordination point
must be in charge and the other inactive. Or you
can design a universal coordination point, common to
all interfaces. I think that apprach with universal
coordination point is superior. 'sman' attempts to
be such a universal coordination point, but clearly
is highly deficient in this role. Your reaction to
this is "get rid of sman". My is "we need a better
sman".
Some extra explanation: I write 'sman' above but
really mean desigin involving event loop in
AXIOMsys communicating with 'sman' -- 'sman' and
parts of AXIOMsys like sockets and event loop
should be treated as a whole. Also, possible
implementations can vary, for example whole
could be folded into AXIOMsys. However having a
separate program written in C make sense.
Anyway, whatever happens to 'sman' I hope that
'-nosman' will be obsolete in the future. Either
'sman' will work so well that there will be no
need for '-nosman' or there will be no 'sman' so
again no need for '-nosman'.
--
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.
