Re: [fricas-devel] )fin, restart, (|spad|) with Clozure CL based FriCAS
Hello Waldek, > 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. I see no update, it is simple as it is, I would be glad if you commit it. For CCLversions I have only tested the actual versions, I followed the documentation, but it is better I agree to test previous ones, I did not know about the recent improvement. For ccl::toplevel-loop, I found it digging the CCL source code. - 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/CAHnU2dYPWpd85a5dN95zJWjsHR__erAZ7jkTZ3yLyULLZ45gkA%40mail.gmail.com.
Re: [fricas-devel] )fin, restart, (|spad|) with Clozure CL based FriCAS
On Wed, May 22, 2024 at 10:03:32PM +0200, Grégory Vanuxem wrote: > Le mar. 21 mai 2024 à 20:32, Waldek Hebisch 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
Re: [fricas-devel] [PATCH] fix title related memory issues
On Fri, May 24, 2024 at 05:04:08PM +0800, Qian Yun wrote: > I wanted to avoid pulling in "fricas_sprintf_to_buf". > > Turns out I can use > > const char *errorStr = "read from viewport manager\n"; > > Are you OK with this? OK if we really need to remove uses of "fricas_sprintf_to_buf". But why do you want to remove such uses? -- 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/ZlC02EwL7F1F86km%40fricas.org.
Re: [fricas-devel] Serial part of build
On Fri, May 24, 2024 at 05:13:10PM +0800, Qian Yun wrote: > > > On 5/24/24 06:32, Waldek Hebisch wrote: > > > > I am not sure. At least we world need proper dependencies. Most of > > those files are categories. We compile categories because compiling > > may need to load compiled categories. And compiling a category need > > categories that it uses. Our list of categories to compile is sorted > > so that dependencies are compiled first. > > > > I was not aware that there's order in CATLIST. > > Can you update this information to doc/algebra_build.txt? Well, 'doc/algebra_build.txt' clearly say that there are dependencies, in particular there is: : FriCAS types are represented by : executable code and sometimes FriCAS needs to load actual compiled : code. FriCAS needs to load categories given as arguments to 'Join', : because 'Join' is implemented as a runtime operation. Also : FriCAS needs to load a category given as an argument to a constructor : if this category itself has arguments. There is also: : The first four stages are purely sequential. Maybe we should add after that: In stage 3 and 4 categories and core domains are compiled in order, so that dependencies came before constructors needing them. > Also does other parts of that file need update? That really is question to potential readers. For me 'purely sequential' means that we care order and by inference order is chosen to satisfy dependencies. But it may help to be more explicit here. -- 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/ZlCkQBPKwQ3RXwDl%40fricas.org.
Re: [fricas-devel] Serial part of build
On 5/24/24 06:32, Waldek Hebisch wrote: I am not sure. At least we world need proper dependencies. Most of those files are categories. We compile categories because compiling may need to load compiled categories. And compiling a category need categories that it uses. Our list of categories to compile is sorted so that dependencies are compiled first. I was not aware that there's order in CATLIST. Can you update this information to doc/algebra_build.txt? Also does other parts of that file need update? - Qian -- 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/0e8f306b-7a9d-4c2e-98b3-bab553ccd780%40gmail.com.
Re: [fricas-devel] [PATCH] fix title related memory issues
I wanted to avoid pulling in "fricas_sprintf_to_buf". Turns out I can use const char *errorStr = "read from viewport manager\n"; Are you OK with this? - Qian On 5/24/24 07:19, Waldek Hebisch wrote: It is good to fix buffer overflow. But you also remove error checking (use of 'check'). Admited, this is minimal error checking, just printing error message, but this is better than nothing. -- 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/2ee6714f-170e-49ca-810a-2c43ef1bcb94%40gmail.com.
