On Wed, May 22, 2024 at 10:03:32PM +0200, Grégory Vanuxem wrote:
> Le mar. 21 mai 2024 à 20:32, Waldek Hebisch <de...@fricas.org> a écrit :
> >
> > On Tue, May 21, 2024 at 01:57:45PM +0200, Grégory Vanuxem wrote:
> >
> > The function to start FriCAS is 'fricas_restart'.  'fricas_restart'
> > is doing some initialization which may be unnecessary when executed
> > second time.  OTOH re-doing initalization should be harmless and
> > some probably is needed.
> 
> I see that, and in fact only propog CL use (|spad|) directly in other
> piece(s ?) of code. Using it is handy though, not everything is
> reinitialized.

With 'spad' Ctrl-C has no chance of working as expected: there is
no handler to handle it.

> So now, my solution to my problem. A proposed diff is attached, it
> uniformizes/simplifies the Clozure CL boot I think.
> 
> Looking at the attached transcript in my previous email I was
> surprised to see that the banner was displayed at that time, and
> experimenting more with the pure CL interpreter after ')fin' I first
> saw that calling Julia was not possible. When you embed Julia using
> libjulia, Julia does not support multithreaded code from the host
> process, I encountered this with SBCL, and it leads to segfault, bad
> stack etc. Only the thread that initialized Julia is able to use
> commands using the C interface. Experimenting some interruptions and
> backtraces I saw a thread started after ')fin'. Apparently the "main"
> process (not exactly in fact, the actual boot process of FriCAS bypass
> the CCL read-eval-print loop main thread) was at that time in a idle
> state or not started or sleeping, I don't really know, and the
> ccl::terminate method is then called on reclaimed CL objects. It's
> another thread in fact. FriCAS on CCL is then a multithreaded app :-)
> 
> Diggering more in 'save-core-restart' I saw that only FriCAS on top of
> CCL is using a fricas-application class, which is just a
> ccl::application class:
> 
> (defclass fricas-application (ccl::application) ())
> 
> and uses it for the ccl::toplevel-function at startup. My main problem
> is that with this class 'ccl::terminate' is not executed and the
> "main" process/thread is needed to execute it. To speak frankly I do
> not really understand why, SBCL, for example, can populate a threaded
> compatible FIFO queue in a garbage collector thread.
> 
> I so cleaned/uniformized the FriCAS on CCL startup not to use this
> class which apparently runs in another thread than the "main" thread.
> Uniformized in the sense that the other CL implementations do not need
> a particular class for FriCAS. The modification is very simple (also
> attached):
> 
> =======================================================
> diff --git a/src/lisp/fricas-lisp.lisp b/src/lisp/fricas-lisp.lisp
> index bf46a61..4e7a222 100644
> --- a/src/lisp/fricas-lisp.lisp
> +++ b/src/lisp/fricas-lisp.lisp
> @@ -64,24 +64,10 @@ with this hack and will try to convince the GCL
> crowd to fix this.
>  ;;
>  #+:openmcl
>  (progn
> -
> -(defclass fricas-application (ccl::application) ())
> -
> -(defvar *my-toplevel-function* nil)
> -
>  (defvar *ccl-default-directory* nil)
> -
> -(defmethod ccl::toplevel-function ((app fricas-application) init-file)
> -    (declare (ignore init-file))
> -        (call-next-method) ; this is critical, but shouldn't be.
> -        (funcall *my-toplevel-function*)
> -        (let ((ap (make-instance 'ccl::lisp-development-system)))
> -            (ccl::toplevel-function ap init-file)))
> -
>  ;;; Disable default argument processing
>  (defmethod ccl::process-application-arguments
> -           ((app fricas-application) error-flag opts args) nil)
> -
> +    ((app ccl::application) error-flag opts args) nil)
>  )
> 
>  ;;; Disable argument processing in GCL
> @@ -143,12 +129,11 @@ with this hack and will try to convince the GCL
> crowd to fix this.
>                     #'(lambda () nil)))
>           (top-fun #'(lambda ()
>                         (set-initial-parameters)
> -                       (funcall restart-fun))))
> +                       (funcall restart-fun)
> +                       (ccl::toplevel-loop))))
>          (setf *ccl-default-directory* ccl-dir)
> -        (setf *my-toplevel-function* top-fun)
> -        (CCL::save-application core-image
> -                                       :PREPEND-KERNEL t
> -                                       :application-class 
> 'fricas-application)
> +        (CCL::save-application core-image :toplevel-function top-fun
> +                                       :PREPEND-KERNEL t)
>          (QUIT))
>  #+:lispworks
>    (progn
> =======================================================
> 
> And as you can see with '(ccl::toplevel-loop)' in 'top-fun', this
> allows the user to enter in the Clozure CL REPL with ')fin' in a
> relatively clean manner. I tested this code with SBCL and Clozure CL,
> tests passed. That also solves my issues and, how I view this, this is
> cleaner.
> 
> Thoughts?

When this code was written Clozure CL documentation about building
text mode applications was rather poor.  I just followed one of
examples that worked OK.  And Clozure CL folks did not mention
'ccl::toplevel-loop'.  IIUC they later simplified and improved
creation of applications.

Your code seem to be working fine.  There is a question with which
version of Clozure CL it works, but AFAICS is works with all
Clozure CL versions that work on may machine.  Clozure CL 1.9 and
older seem to be broken on my machine, the patch works with Clozure
CL 1.10 and later.  I will commit the patch, unless you want to
update it.

-- 
                              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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ZlEfmd4XS6K7EEH8%40fricas.org.

Reply via email to