Hello Waldek, hello all,

First, thanks for your response, it was very instructive it leads me
to solve this long outstanding issue with my FriCAS copy.

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:
> > Hello,
> >
> > I try to understand why a Clozure CL 'terminate' method is not called
> > from the interpreter. I have a CL class jlref, when a jlref object is
> > no longer referenced the CL garbage collector reclaims it. It is
> > possible in different CL implementations to add a 'hook' to do some
> > job at that time. Personally I then unreference the real Julia object
> > in such a way it can be GC reclaimed in Julia, jlref is just a class
> > that holds information about it.
> >
> > For SBCL I have no problem, but 'ccl:terminate' which should be
> > automatically called is never called. But, and this is the main point,
> > following an advice in a Clozure mailing list, I tried to use/define
> > this method directly at execution time using ')fin', and surprisingly,
> > using ')fin' automatically triggers 'terminate' on every objects that
> > are/(were ?) reclaimed.
> >
> > So my question, what does ')fin' do? And do you happen to know where I
> > need to look in the FriCAS source code to better understand its
> > effect?
>
> AFAIK ')fin' is doing "nothing", is just returns back to whatever Lisp
> was doing befor calling FriCAS.  To understand relation with Lisp,
> look at 'src/lisp/fricas-lisp.lisp', in particular 'save-core-restart'.

Yes!!! This is what helped me. I looked more carefully at this function and..

>
> > Furthermore, in src/interp/int-top.boot, the documentation says that
> > to return to the interpreterafer after ')fin'  '(restart)' should be
> > used. In fact, before some change in the FriCAS source I think, so I
> > used (|spad|). Again following an advice. And, again, with Clozure CL,
> > contrary to SBCL, that leads to strange things after returning to the
> > interpreter and executing foreign code (principally bad addresses and
> > therefore segfault).
>
> 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.

> Note that ')fin' is really unsuppored by FriCAS, basically
> it is "pray that Lisp will do what you want".  In particular IIRC
> it simply quits FriCAS when using ECL and I think it never fully
> worked with Clozure CL.
>
> > So maybe I first need to know a better CL command, to return to the
> > interpreter? But also, of course, to know why the ccl:terminate is not
> > called in the interpreter. R. Munyer in the CCL mailing list found a
> > way, see the attached transcript file, but he uses ')fin' and no
> > Clozure CL FFI. I tried to use different (eva-when) to define the
> > ccl:terminate method without success since the code is build/compiled
> > (src/lisp).
>
> I think that ')fin' is irrelevant, you should get the same effect
> using ')lisp' or if that is inconvenient you can put code in the
> file and use ')read'.  The main difference is that FriCAS needs
> specific settings of several global variables and FriCAS catches
> errors (there are several use of 'CATCH' and there is 'handler-bind').
> This _should_ make no difference.  What _may_ matter is order of
> initialization.  In particular FriCAS performs some initializations
> before dumping image.  But several thing do not survive to
> restarted image, so need to be done later, after start of new image.

I guessed after your email that the behavior of ')fin' is somewhat undefined.

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?

- Greg

-- 
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/CAHnU2daHV72eFZZGpNcF9Bi6vUEhu0O5bWNPwoQ%2BKxRN2C4XAQ%40mail.gmail.com.

Attachment: fricas-lisp.diff
Description: Binary data

Reply via email to