OK, I think I have to give up. The InputForm consists of 23 964 324 atoms. I guess that there is no sensible way to transmit this, right?
Martin On Thursday 18 April 2024 at 21:50:57 UTC+2 Martin R wrote: > I have now FriCAS with ECL, but I now realize that I am doing very silly > things in the interface between FriCAS to sage: > * I do an unnecessary unparse of the InputForm (this runs forever on ECL, > and crashes sbcl) > * I throw the result away > * I convert the InputForm into a string using a customized printer > * I parse the result > > Oh dear, what did I do! > > I guess that I was scared of creating a very long history in the FriCAS > process if I transmit the InputForm atom by atom. I guess I should cook up > a simple protocol to transmit an ordered tree, maybe as a Stream. > > Martin > On Thursday 18 April 2024 at 21:03:34 UTC+2 Nasser M. Abbasi wrote: > >> These are useful lisp commands, I did not know about them. This is what I >> get for my Fricas installation >> >> FriCAS Computer Algebra System >> Version: FriCAS 1.3.10 built with sbcl 2.3.11 >> Timestamp: Wed Jan 10 09:37:52 PM CST 2024 >> >> (1) -> )lisp (lisp-implementation-version) >> Value = "2.3.11" >> (1) -> )lisp (sb-ext:dynamic-space-size) >> >> Value = 4294967296 >> >> I am also running Fricas and sagemath on VBox under windows 10. The OS is >> Linux Manjaro >> >> >fricas --version >> FriCAS 1.3.10 >> based on sbcl 2.3.11 >> >sage --version >> SageMath version 10.3, Release Date: 2024-03-19 >> > >> On Thursday, April 18, 2024 at 12:01:19 PM UTC-5 axio...@yahoo.de wrote: >> >>> Hi Waldek! >>> >>> Thanks for the rapid answer! >>> >>> I have: >>> )lisp (lisp-implementation-version) >>> 2.1.11.debian >>> )lisp (sb-ext:dynamic-space-size) >>> 1073741824 >>> )version >>> FriCAS 2022-07-16 compiled at Fr 12 Aug 2022 15:17:27 CEST >>> >>> I'm currently compiling the ECL version. >>> >>> Unfortunately, because of the MacOS problem ( >>> https://github.com/sagemath/sage/pull/37041) most sage users won't use >>> the newest FriCAS. So I'll first check whether that makes a difference. >>> >>> Martin >>> >>> On Thursday 18 April 2024 at 18:11:21 UTC+2 Waldek Hebisch wrote: >>> >>>> On Thu, Apr 18, 2024 at 08:45:53AM -0700, 'Martin R' via FriCAS - >>>> computer algebra system wrote: >>>> > I started to look into one of the problems >>>> > (https://github.com/sagemath/sage/issues/37813): >>>> > >>>> > res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x); >>>> > >>>> > works nicely, but converting to InputForm (which I use to do the >>>> > translation to sage) fails. Is there a good reason for that - i.e., >>>> is >>>> > this a bug, or just a problem with memory? >>>> > >>>> > Best wishes, >>>> > >>>> > Martin >>>> > >>>> > (2) -> inform := res :: INFORM >>>> > >>>> > Heap exhausted during garbage collection: 0 bytes available, 16 >>>> requested. >>>> <snip> >>>> > Total bytes allocated = 1072734880 >>>> > Dynamic-space-size bytes = 1073741824 >>>> >>>> For me it works. The result is big for humans, but should be no >>>> problem for modern computers. I am using FriCAS trunk build >>>> using sbcl-1.2.4 (currently with 3Gb limit). Tried also version >>>> with 2Gb limit and sbcl-2.2.9 with 1Gb limit. Note >>>> I did: >>>> >>>> res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x); >>>> ii := res::InputForm; >>>> >>>> that is I am _not_ printing resulting InputForm. But I also >>>> separately printed the InputForm, it works, just is slow when >>>> printing to terminal and useless because the result is much >>>> bigger than terminal scrollback buffer. >>>> >>>> -- >>>> 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/c7adaf30-5396-4bf1-ab3c-b29a1a9b2b30n%40googlegroups.com.
