Greetings!  Thanks so much -- it was the replacement of (|restart|) with
(|spad|) that confused me.

Any other insights or suggestions on how to quickly pin down the error I
report below?

Take care,

Qian Yun <[email protected]> writes:

> (1) -> )help fin
> ====================================================================
> A.10.  )fin
> ====================================================================
>
> User Level Required:  development
>
> Command Syntax:
>
>   -  )fin
>
> Command Description:
>
> This command is used by FriCAS developers to leave the FriCAS system and
> return to the underlying Lisp system. To return to FriCAS, issue the
> ``(|spad|)'' function call to Lisp.
>
>
>
>
> This works for SBCL.  Not sure about GCL.
>
> - Qian
>
> On 3/6/24 00:40, Camm Maguire wrote:
>> Greetings!  Has fricas removed axiom's )fin (restart) pair?  How does
>> one escape to/from lisp at the fricas prompt?
>> Take care,
>> Camm Maguire <[email protected]> writes:
>> 
>>> Greetings, and thanks so much for the suggestion!
>>>
>>> This works.  I now have a 2.7.0 and fricas tree with minor modifications
>>> ready for commit but for (I think) one remaining problem.  2.6.14
>>> compiles my fricas tree just fine, but 2.7.0 gives two identical errors
>>> compiling the algebra:
>>>
>>> )compile GUESSINT.spad
>>>       Compiling FriCAS source code from file
>>>        /mnt/sda4/debian/fricas/src/algebra/GUESSINT.spad using old
>>>        system compiler.
>>>     GUESSINT abbreviates package GuessInteger
>>> ****** comp fails at level 2 with expression: ******
>>> (|Sel| (|Expression| (|Integer|)) |retract|)
>>> ****** level 2  ******
>>> $x:= ((Sel (Expression (Integer)) retract) G1)
>>> $m:= (Fraction (Integer))
>>> $f:=
>>> ((((#:G1 #) (* #) (+ #) (- #) ...)))
>>>       >> Apparent user error:
>>>     not known that (Expression (Integer)) has (OR (AND (has (Integer) 
>>> (IntegralDomain)) (has (Integer) (RetractableTo (Integer)))) (has (Integer) 
>>> (RetractableTo (Fraction (Integer)))))
>>>
>>> I'm digging into this and will find it eventually, but if you have any
>>> debugging suggestions I'm sure that would speed things up.
>>>
>>> Take are,
>>>
>>>
>>> Waldek Hebisch <[email protected]> writes:
>>>
>>>> On Sat, Mar 02, 2024 at 08:56:14AM -0500, Camm Maguire wrote:
>>>>> Greetings!  Grégory, will reply to your post in separate email.  But in
>>>>> general there are several places where fricas creates calls to 'list
>>>>> which exceed GCL's call-arguments-limit when translating boot files to
>>>>> .clisp.  2.6.x was not rigorous about enforcing this, but 2.7.0 is.
>>>>> Where should I look in the boot parser source to suggest a patch
>>>>> breaking this into an nconc of several compliant list calls, or better
>>>>> yet just writing a quoted list (since apparently all contents are
>>>>> strings) which the reader can handle just fine?
>>>>
>>>> AFAICS this is handled in 'src/boot/tytree1.boot'.  Note that in
>>>> FriCAS lists are mutable and Boot code makes significant use of
>>>> of mutation.  So translating _all_ list construction to quoted
>>>> lists would be wrong.  Boot really does not look at control/data
>>>> flow so finding out possibilties to use quoted lists is probably
>>>> not practical.
>>>>
>>>> The simplest solution may be shadowing Lisp LIST and using a macro
>>>> instead.
>>>
>>> -- Camm Maguire
>>> [email protected]
>>> ==========================================================================
>>> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>> 

-- 
Camm Maguire                                        [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/87sf132y62.fsf%40maguirefamily.org.

Reply via email to