Dear Waldek,

many thanks for your comments.  Unfortunately, I need to finish this today, or,
at the very latest, tomorrow, because then I need to tell the sysadmin what to
install.  As always, I'm too late.

Waldek Hebisch <[EMAIL PROTECTED]> writes:

> > Below a patch implementing some more markers and putting one in a better
> > place.  I'm currently revising Francois Maltey's new axiom-mode, which 
> > relies
> > on the markers.
> > 
> > I noticed a few things:
> > 
> > 1) currently, iohook is called unconditionally.  It might be nice to be 
> > able to
> >    turn it off for HyperDoc examples.
> 

> Hmm, the idea is to have _all_ conditional logic inside iohook.  I am not
> sure if it is hard to detect when code is run from HyperDoc, but hook should
> be able to use the same method as other parts of code.

Ah, yes!

> BTW. I just noticed that setting output format to say TeX also affect
> HyperDoc examples.

This suggests that it is not easy..., do you have *any* idea how I could detect
who is running me :-)

> > 3) Is it possible to display a HyperDoc page with a FriCAS command?  If so,
> > I'd try to make the type information clickable in emacs, and make HyperDoc
> > show the page when the user clicks on it.  That would be a very useful
> > feature, I think.
> >
> 
> Currently HyperDoc is the active party: HyperDoc requests a page and AXIOMsys
> delivers.  Doing things the other way (which currently happens in few places)
> leads to nasty race conditions.

Where is this done? I'd like at least to try it.  What sort of race condition
do you expect? (I'm not familiar with "race conditions", actually)
 
> >      #a=0 =>
> > +             ioHook("startPrompt")
> >               PRINC(MKPROMPT())
> > +             ioHook("endOfPrompt")
> >               intloopReadConsole('"", n)
> >      $DALYMODE and intloopPrefix?('"(",a) =>
> >              intnplisp(a)
> > +            ioHook("startPrompt")
> >              PRINC(MKPROMPT())
> > +            ioHook("endOfPrompt")
> >              intloopReadConsole('"",n)
> 
> We should probably make a function:
> 
> printPrompt() ==
>     ioHook("startPrompt")
>     PRINC(MKPROMPT())
>     ioHook("endOfPrompt")
> 
> and call it in all apropriate places

I thought that this might be appropriate, but there are places where I'm not
sure whether the ioHook should be called.


> > -    ioHook("endOfOutput") 
> >      intSetNeedToSignalSessionManager()
 
> Why do you remove this hook?  IIRC this hook is the only way to be sure that
> output is complete -- you may get error almost everywhere during evaluation
> and printing and errror handler will skip rest of printout and return to
> toplevel.

It did not work reliably.  In particular, it did not cover system commands.
Decorating the prompt seems to work always.

What I really need / would like to have:

* number one priority: markers that tell me whether FriCAS is expecting input.
  (using this patch: QueryUser and ReadLine.  Actually, maybe it would be
  better to make both carry the same name, but I don't know.  Not so
  important.) Without this, it is nearly impossible to do reliable
  communication with emacs.

* markers that decorate output and, specially, the prompt.  (The prompt should
  definitively appear in a different color than other output in emacs.)

* markers that separately decorate algebra output.  Another nice thing would be
  to decorate the line number appearing before the output.

* markers that decorate Time and Type.  It would be extremely nice if we could
  spit out a separate marker for Type, but looking at the code suggests that
  this is not trivial.  I'll try this after having completed the basic stuff.

* markers that decorate messages and error messages.

  Maybe I decorate sayKeyedMsg directly (in msgdb.boot)?  Yes, I like this
  best: I could give ioHook as optional arguments the arguments of sayKeyedMsg,
  that might also solve the Time and Type problem (although not as nice as
  could be, since I will still have to reparse the output to look for the
  Type...)!


> > Index: src/interp/msgdb.boot
> > ===================================================================
> > --- src/interp/msgdb.boot   (Revision 364)
> > +++ src/interp/msgdb.boot   (Arbeitskopie)
> > @@ -458,13 +458,13 @@
> >    spadThrow()
> >  
> >  queryUserKeyedMsg(key,args) ==
> > -  ioHook("startQueryUser")
> >    -- display message and return reply
> >    conStream := DEFIOSTREAM ('((DEVICE . CONSOLE) (MODE . INPUT)))
> >    sayKeyedMsg(key,args)
> > +  ioHook("startQueryUser")
> >    ans := read_-line conStream
> > +  ioHook("endOfQueryUser")
> >    SHUT conStream
> > -  ioHook("endOfQueryUser")
> >    ans
> 
> I am affraid both placements of hooks make sense here: you clearly
> indicate when AXIOMsys waits for user input, but previous placement
> indicated which part of AXIOMsys output deals with the question.
> 
> In particular an interface may wish to automatically answer a
> question or possibly present questions in separate querry box.
> Do do this the inteface need to know what is the question.

Well, any interface needs to know whether FriCAS is expecting input...

Maybe we should decorate read_line directly, depending only whether we are
reading from standard input or not, or giving the stream as an optional second
argument to ioHook?

Martin


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to