[Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_31-base-183-gf44d669
Subject: [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_31-base-183-gf44d669
From: Rupert Swarbrick
Date: Thu, 05 Dec 2013 22:51:55 +0000
Leo Butler <l_butler at users.sourceforge.net> writes:
> Yes, I re-read the git diffs and re-built Maxima with the commits and
> I don't see a problem with the first commit.
>
> My original message is partly down to haste and confusion on my part,
> and partly down to a genuine interest in keeping this part of Maxima
> stable and backwards-compatible.
Great! I should say that I was being quite careful to keep things
backwards compatible. Indeed, that's what motivated the design - more
notes below.
Sorry that the git commit logs were less clear than they could have
been: I'm aware that when I'm not concentrating, I sometimes have a
habit of writing things that make perfect sense, but only if you were
the person that wrote them...
> If I understand your first commit, you have centralized all references
> to *prompt-suffix* and *prompt-prefix* into format-prompt.
Yep (or at least, that was the plan!)
> If this is the case, then you could do a replacement like
>
> *prompt-prefix* --> (funcall-or-eval *prompt-prefix*)
>
> where
>
> (defun funcall-or-eval (x)
> (cond ((stringp x) x)
> ((functionp x) (funcall x))
> ;; other cases
> (t (error ...))))
>
> and similarly for the suffix. I am not sure about the wisdom of such a
> change, but it would a relatively unobtrusive way to add more hooks...
I'm a little confused. Firstly, note that funcall-or-eval is going to
need some unwind protection machinery to avoid nasty infinite loops
(otherwise if something goes belly-up, Maxima throws and displays a new
prompt and the error happens again...).
>> Also, I'm not convinced about the "complexity of the display machinery"
>> argument. Perhaps Leo refers to the complicated-looking UNWIND-PROTECT
>> form in my PROMPT-NOTES function? But the point is that, if you want the
>> user to be able to supply something that does a computation before a
>> prompt, you need to make sure that it doesn't end up in an infinite
>> loop... I'm pretty certain that logic would need to appear somewhere
>> whatever the proposed mechanism.
>
> No, the whole prompt-notes business seems unnecessarily complicated
> and unneeded in src code when it can be accomplished with the existing
> *alt-display.d* hooks or something like that above.
My second point of confusion is, given the funcall-or-eval mechanism you
suggest, how can a user add something to the prompt display and be
reasonably sure he/she won't completely break an existing
*prompt-suffix* (or *prompt-prefix*). The obvious solution is to stick a
list of stuff to display in front of the string of an existing
suffix... which is what last night's patch does! Is there really a
simpler option?
Note that, once you've written something that prepends lists and
something else that adds unwind protection, you've just rewritten last
night's patch.
>> >> The third (f44d66) (revised to make use of existing
>> >> machinery) seems like it would be suitable for a collection of
>> >> solved problems or how-to cookbook -- not sure if it should be in
>> >> share.
>>
>> Fair enough: I don't have any strong feelings about this. Can you
>> suggest a good place for it to go?
>
> http://sourceforge.net/apps/phpbb/maxima/viewforum.php?f=3
> github
Wow, I didn't know this existed! Cool! I'm not convinced that PHP-BB is
really the ideal way to share snippets of code, but I guess that's
firmly off-topic for this mail thread.
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20131205/87e195d2/attachment.pgp>