Re: [fricas-devel] on building the book with pdflatex

[Dima Pasechnik]

On Tue, May 7, 2024 at 2:56 PM Qian Yun  wrote:
>
>
>
> On 5/7/24 21:45, Dima Pasechnik wrote:
> > On Tue, May 7, 2024 at 12:51 PM Qian Yun  wrote:
> >>
> >> Some decisions need to be made in order to build book with pdflatex.
> >>
> >> 1. src/doc/ps/ images.
> >>
> >> These are hyperdoc images. They are in ps format, but actually are
> >> bitmap images.  pdflatex can't handle ps format directly, so I
> >> suggest to convert them into png format.
> >
> > pdflatex/xelatex/lualatex can handle eps images just fine.
> > You can first run ps2eps on the ps files.
> >
> > E.g. I can take knot3.ps - one of the files, (which is not bitmap, but
> > a proper postscript) run
> >
> >  ps2pdf knot3.ps
> >
> > producing knot3.eps, move knot3.ps out of the way, and then
>
> You used both eps and pdf.  I think you meant pdf here?

sorry, typo, I meant

   ps2eps knot3.ps

>
> knot3.ps (and a few other vector images) will be removed very soon,
> because we'll be able to generate them during build.  And yes,
> to build with pdflatex, those ps images will be converted to pdf
> format by epstopdf.

as I said, it's not needed. (eps is smaller than pdf)

>
> The rest ps images are all bitmaps.
>
> > \documentclass{article}
> > \usepackage{graphics}
> > \begin{document}
> > \includegraphics{knot3}
> > \end{document}
> >
> > works just fine.
> > Or, perhaps, you prefer xelatex, then you'd need
> >   \usepackage[xetex]{graphics}
> >
> > Dutto for  lualatex, you'd use
> >   \usepackage[luatex]{graphics}
> >
> > IMHO one should not use pdflatex, which is obsolete, but switch to
> > lualatex or xelatex.
> >
> > Dima
> >
>
> I think it'll be easy to support pdflatex/lualatex/xelatex all
> at current stage, because there's no breaking features that
> are used in tex source files, for example unicode support.
>
> - 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/7ca24f5f-3f3b-4ded-b48a-e85c0cda8689%40gmail.com.

-- 
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/CAAWYfq28aG6KbBdHuqi1Dz4mOVKi2ikAWavoa_vc-7UQpsz6pA%40mail.gmail.com.

Re: [fricas-devel] on building the book with pdflatex

[Dima Pasechnik]

On Tue, May 7, 2024 at 12:51 PM Qian Yun  wrote:
>
> Some decisions need to be made in order to build book with pdflatex.
>
> 1. src/doc/ps/ images.
>
> These are hyperdoc images. They are in ps format, but actually are
> bitmap images.  pdflatex can't handle ps format directly, so I
> suggest to convert them into png format.

pdflatex/xelatex/lualatex can handle eps images just fine.
You can first run ps2eps on the ps files.

E.g. I can take knot3.ps - one of the files, (which is not bitmap, but
a proper postscript) run

ps2pdf knot3.ps

producing knot3.eps, move knot3.ps out of the way, and then

\documentclass{article}
\usepackage{graphics}
\begin{document}
\includegraphics{knot3}
\end{document}

works just fine.
Or, perhaps, you prefer xelatex, then you'd need
 \usepackage[xetex]{graphics}

Dutto for  lualatex, you'd use
 \usepackage[luatex]{graphics}

IMHO one should not use pdflatex, which is obsolete, but switch to
lualatex or xelatex.

Dima




>
> 2. If the answer to previous question is yes, then shall we convert
> from ps format, or shall we do the screenshots again to create
> a higher resolution of those images.
>
> - 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/0768deef-035e-474f-a14f-9cc5e59cf902%40gmail.com.

-- 
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/CAAWYfq0GPOUH_k_UY0ArpKSQdpit8zfEsZOFZ5WNiU22o1ZpRg%40mail.gmail.com.

Re: [fricas-devel] fyi, list of exceptions for Fricas, summer 2024 edition of independent CAS integration tests

[Dima Pasechnik]

On Sat, Apr 20, 2024 at 7:45 PM Dima Pasechnik  wrote:

>
>
> On Sat, Apr 20, 2024 at 7:31 PM 'Nasser M. Abbasi' via FriCAS - computer
> algebra system  wrote:
>
>> Hello Matrin,
>>
>> Sure, will try your version on a large integration test file and see if
>> it is faster than the what I had with 10.3 sage.
>>
>> The problem is that I know nothing about github.  I just know how to
>> login to github and enter bug reports on the CAS systems I use at the
>> issues page. That is all.
>>
>> When I build sagemath, I download the sagemath latest zip file from
>> https://mirrors.mit.edu/sage/devel/index.html
>>
>> I have no idea how to do what you said "try the branch at" . I do not
>> know what this means.
>>
>> I see on the link you gave no zip file for sagemath to download.
>>
>> If you could give me a link to sagemath zip file with your fixes in it,
>> will be happy to download it, build it like I did for 10.3 and try it.
>>
>
> Do you know how to apply patches? If so, you just need to apply the patch
> corresponding to the PR Martin mentioned. It's here:
> https://patch-diff.githubusercontent.com/raw/sagemath/sage/pull/37836.diff
>

Just to mention that this URL is equivalent to

   https://github.com/sagemath/sage/pull/37836.diff

which tells one how to get the patch from a GitHub PR (just add the magical
.diff)
There is also a variation (.patch) which, I think, produces a series of
diffs, one per each commit.






>
>
>
>>
>> One day I want to take course at school how to use github if I can find
>> one.
>>
>
> It doesn't have much to do with GitHub, it's git that you need to know a
> bit about.
> GitHub is just a hosting platform for git repositories.
>
> HTH
> Dima
>
>>
>> --Nasser
>>
>> On Saturday, April 20, 2024 at 8:12:00 AM UTC-5 axio...@yahoo.de wrote:
>>
>>> Hi Nasser,
>>>
>>> could you try the branch at https://github.com/sagemath/sage/pull/37836?
>>> It should give significant performance gains for your testsuite.
>>>
>>> Best wishes,
>>>
>>> Martin
>>>
>>> On Friday 19 April 2024 at 11:49:49 UTC+2 Dima Pasechnik wrote:
>>>
>>>> On Fri, Apr 19, 2024 at 01:26:27AM -0700, 'Martin R' via FriCAS -
>>>> computer algebra system wrote:
>>>> > I don't know how to do it. Note that this should really work with any
>>>> lisp
>>>> > implementation to make sense, because some people (eg., me) will have
>>>> > fricas installed with sbcl (because this is fastest), and the
>>>> interface
>>>> > shouldn't insist on an ECL installation.
>>>> >
>>>> > Do you know how to do it?
>>>>
>>>> There is https://github.com/quil-lang/sbcl-librarian
>>>> which relies on a recent
>>>> https://www.sbcl.org/manual/#Calling-Lisp-From-C
>>>>
>>>> If SBCL is the preferred Lisp then this route can be pursued -
>>>> I don't however know enough about FriCAS to see how to use
>>>> sbcl-librarian to call FriCAS functions from Python.
>>>> (There doesn't even seem to be an example on calling FriCAS from its
>>>> underlyng Lisp available anywhere - from that it should be doable)
>>>>
>>>> I don't think it can be totally Lisp-agnostic:
>>>> SBCL does not allow embedding in the way ECL does (It's Embeddable
>>>> Common Lisp for a reason...)
>>>>
>>>> Dima
>>>>
>>>>
>>>> >
>>>> > Martin
>>>> >
>>>> > On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote:
>>>> >
>>>> >
>>>> >
>>>> > On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer
>>>> algebra
>>>> > system  wrote:
>>>> > >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?
>>>> >
>>>> > In-memory - just how Maxima library interface is operating.
>>>> > No need for pexpect interface then.
>>>> > Create a FAS module loadable into libecl,
>>>> > and, well, you have a huge increase in speed of the interface.
>>>> >
>>>> >
>>>> > >
>>>> > >Martin
>>>> > >On Thursday 18 April 2024 at 21:50:57 UTC+2 Martin R wrote:
>>>> >

Re: [fricas-devel] calling FriCAS functions from Lisp

[Dima Pasechnik]

On Saturday, April 20, 2024 at 12:48:43 PM UTC+1 Waldek Hebisch wrote:

On Sat, Apr 20, 2024 at 02:47:02AM -0700, Dima Pasechnik wrote: 
> How does one do this? 
> (with ECL or SBCL). 
> 
> Presumably if one makes a FriCAS fasl library (how?), it should be 
possible 
> to call FriCAS functions from Lisp without going through files or pipes. 
> 
> That's certainly possible (and used in Sage) with Maxima. 

Look at 'contrib/load-fricas.lisp' and 'contrib/mk_shlib.lisp'. 
'contrib/mk_shlib.lisp' makes ECL .fas (really a C shared library). 
Currently 'contrib/load-fricas.lisp' is broken with sbcl, one needs to 
add an extra line loading GMP support (I will fix this shortly, 
after more testing).


in sbcl build, 
/full_path_to_FriCAS_build_directory/src/interp/
has no src/interp/ - so this seems to be broken too. 
Or probably there is a confusion of terms, as there is a build directory,
build/x86_64-linux-gnu/, containing bin/ and lib/, but no src/

It should be very easy to convert this
file into a template (.in) that is filled in by ./configure with the 
correct values.

 Anyhow, if instead I use the location of the source directory, with 
src/interp present, I get
"Package C does not exist." error.

$ sbcl http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* FOO
* FOO
NIL
NIL
* 
; file: /mnt/opt/fricas/src/interp/../lisp/fricas-package.lisp
; in: DEFMACRO IN-PACKAGE
; (DEFMACRO FRICAS-LISP::IN-PACKAGE (PACKAGE  FRICAS-LISP::OPTIONS)
;   `(IN-PACKAGE ,PACKAGE))
; --> SB-INT:NAMED-DS-BIND SB-INT:BINDING* 
; ==>
;   (LET* ((#:G0
;   (SB-C::CHECK-DS-LIST/ (CDR #:EXPR) 1 1
;  '(# PACKAGE  
FRICAS-LISP::OPTIONS)))
;  (PACKAGE (POP #:G0))
;  (FRICAS-LISP::OPTIONS #:G0))
; (DECLARE (SB-C::CONSTANT-VALUE PACKAGE FRICAS-LISP::OPTIONS))
; (BLOCK FRICAS-LISP::IN-PACKAGE `(IN-PACKAGE ,PACKAGE)))
; 
; caught STYLE-WARNING:
;   The variable OPTIONS is defined but never used.
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition
T
* 
debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread
#:
  Package C does not exist.

Line: 29, Column: 23, File-Position: 848

Stream: #

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE ] Use the current package, COMMON-LISP-USER.
  1: [RETRY] Retry finding the package.
  2: [USE-VALUE] Specify a different package
  3: [UNINTERN ] Read the symbol as uninterned.
  4: [SYMBOL   ] Specify a symbol to return
  5: [ABORT] Exit debugger, returning to top level.

(SB-IMPL::READER-FIND-PACKAGE "C" # T)
0] 

Dima
 

In both cases usage has changed a bit: one 
needs to set FRICAS environment variable to location of build tree. 
Both files contain instructions about use. 

-- 
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/8705732a-8fc6-4f50-a680-e83f5911dd11n%40googlegroups.com.

Re: [fricas-devel] fyi, list of exceptions for Fricas, summer 2024 edition of independent CAS integration tests

[Dima Pasechnik]

On Sat, Apr 20, 2024 at 7:31 PM 'Nasser M. Abbasi' via FriCAS - computer
algebra system  wrote:

> Hello Matrin,
>
> Sure, will try your version on a large integration test file and see if it
> is faster than the what I had with 10.3 sage.
>
> The problem is that I know nothing about github.  I just know how to login
> to github and enter bug reports on the CAS systems I use at the issues
> page. That is all.
>
> When I build sagemath, I download the sagemath latest zip file from
> https://mirrors.mit.edu/sage/devel/index.html
>
> I have no idea how to do what you said "try the branch at" . I do not know
> what this means.
>
> I see on the link you gave no zip file for sagemath to download.
>
> If you could give me a link to sagemath zip file with your fixes in it,
> will be happy to download it, build it like I did for 10.3 and try it.
>

Do you know how to apply patches? If so, you just need to apply the patch
corresponding to the PR Martin mentioned. It's here:
https://patch-diff.githubusercontent.com/raw/sagemath/sage/pull/37836.diff




>
> One day I want to take course at school how to use github if I can find
> one.
>

It doesn't have much to do with GitHub, it's git that you need to know a
bit about.
GitHub is just a hosting platform for git repositories.

HTH
Dima

>
> --Nasser
>
> On Saturday, April 20, 2024 at 8:12:00 AM UTC-5 axio...@yahoo.de wrote:
>
>> Hi Nasser,
>>
>> could you try the branch at https://github.com/sagemath/sage/pull/37836?
>> It should give significant performance gains for your testsuite.
>>
>> Best wishes,
>>
>> Martin
>>
>> On Friday 19 April 2024 at 11:49:49 UTC+2 Dima Pasechnik wrote:
>>
>>> On Fri, Apr 19, 2024 at 01:26:27AM -0700, 'Martin R' via FriCAS -
>>> computer algebra system wrote:
>>> > I don't know how to do it. Note that this should really work with any
>>> lisp
>>> > implementation to make sense, because some people (eg., me) will have
>>> > fricas installed with sbcl (because this is fastest), and the
>>> interface
>>> > shouldn't insist on an ECL installation.
>>> >
>>> > Do you know how to do it?
>>>
>>> There is https://github.com/quil-lang/sbcl-librarian
>>> which relies on a recent
>>> https://www.sbcl.org/manual/#Calling-Lisp-From-C
>>>
>>> If SBCL is the preferred Lisp then this route can be pursued -
>>> I don't however know enough about FriCAS to see how to use
>>> sbcl-librarian to call FriCAS functions from Python.
>>> (There doesn't even seem to be an example on calling FriCAS from its
>>> underlyng Lisp available anywhere - from that it should be doable)
>>>
>>> I don't think it can be totally Lisp-agnostic:
>>> SBCL does not allow embedding in the way ECL does (It's Embeddable
>>> Common Lisp for a reason...)
>>>
>>> Dima
>>>
>>>
>>> >
>>> > Martin
>>> >
>>> > On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote:
>>> >
>>> >
>>> >
>>> > On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer
>>> algebra
>>> > system  wrote:
>>> > >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?
>>> >
>>> > In-memory - just how Maxima library interface is operating.
>>> > No need for pexpect interface then.
>>> > Create a FAS module loadable into libecl,
>>> > and, well, you have a huge increase in speed of the interface.
>>> >
>>> >
>>> > >
>>> > >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 

Re: [fricas-devel] calling FriCAS functions from Lisp

[Dima Pasechnik]

On Sat, Apr 20, 2024 at 10:58 AM Qian Yun  wrote:

> There is https://github.com/oldk1331/fricas0,
> where fricas exists in the form of pure lisp,
> but it is not in the sense of a "traditional lisp library"
> by ASDF or DEFPACKAGE.
>
> I can look into this direction.
>

Thanks. Yes, please, ASDF/DEFPACKAGE.
This would be a step towards a possibility to call SBCL FriCAS from C or
Python or others, via
https://github.com/quil-lang/sbcl-librarian
(something that would speed up interfaces, such as Sage's interface to
FriCAS).

Dima


> - Qian
>
> On 4/20/24 17:47, Dima Pasechnik wrote:
> > How does one do this?
> > (with ECL or SBCL).
> >
> > Presumably if one makes a FriCAS fasl library (how?), it should be
> possible
> > to call FriCAS functions from Lisp without going through files or pipes.
> >
> > That's certainly possible (and used in Sage) with Maxima.
> >
> > Thanks
> > Dima
> >
> >
> >
>
> --
> 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/f325257c-70b5-47a0-8eb7-b7d9411cee3c%40gmail.com
> .
>

-- 
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/CAAWYfq0%3DW20V9YL%2BHjOO%2BXKhinpcj6_CDFg-mbELK-OVu8tYyA%40mail.gmail.com.

[fricas-devel] calling FriCAS functions from Lisp

[Dima Pasechnik]

How does one do this?
(with ECL or SBCL).

Presumably if one makes a FriCAS fasl library (how?), it should be possible 
to call FriCAS functions from Lisp without going through files or pipes.

That's certainly possible (and used in Sage) with Maxima.

Thanks
Dima

 

-- 
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/c0809c45--4b17-bd9f-7183438ab301n%40googlegroups.com.

Re: [fricas-devel] fyi, list of exceptions for Fricas, summer 2024 edition of independent CAS integration tests

[Dima Pasechnik]

On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer algebra system 
 wrote:
>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?

In-memory - just how Maxima library interface is operating.
No need for pexpect interface then.
Create a FAS module loadable into libecl,
and, well, you have a huge increase in speed of the interface.


>
>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. 
>  
> > 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/5EB304E3-B412-4A01-8C84-1FC34C6A5983%40gmail.com.

Re: [fricas-devel] Deprecated operations in scene.spad

[Dima Pasechnik]

On 13 April 2024 02:38:34 CEST, Hill Strong  wrote:
>There is nothing to stop anyone from breaking the requirement of using any
>Lisp as the destination for Boot code. I translated one section of Boot
>code directly into Icon. Of course there is much in Boot than assumes Lisp
>lists. But that is not an impossible task to change.
>
>You could then use the iconc compiler to transform the icon code to C and
>compile to machine code.

But that's what ECL is doing, compiling to C and then calling a C compiler? 
Would it be more useful to figure out why the resulting FriCAS runs 
considerably slower than the one built using SBCL ?

Dima
>
>I have not continued that development as I am much more interested in
>changing the Spad language to be a more consistent block structured
>language, including adding in static  environmental structures ala ALGOL
>and it's descendents.
>
>On Sat, 13 Apr 2024, 6:05 am Ralf Hemmecke,  wrote:
>
>>
>>
>> On 4/12/24 16:20, Martin Baker wrote:
>> > On 12/04/2024 09:23, Ralf Hemmecke wrote:
>> >> I do not understand why you think that not both graphics systems
>> >> can live besides each other (as they do now)?
>> >
>> > Well, I think that the interactive graphics should work seamlessly
>> > with the things that scene.spad can do such as outputting to various
>> > file formats and having much more control over the output. For all
>> > this to work together without duplication it all needs to be written
>> > in SPAD.
>>
>> So, yes. If I were you, I would simply ignore the existing graphics
>> system and provide all the features that *you* think would be great and
>> help you in your work. That would inclulde connecting (or writing from
>> scratch) an interactive graphics system in SPAD. Why would you care what
>> Waldek or anybody else who has write access to the FriCAS repo says? You
>> can put everything into your own repo and try to promote it to users.
>> If your system is superior, it will at some point be seen and more users
>> will ask to properly include it into FriCAS.
>> Clearly, nobody can assume that his/her code will be included into the
>> "official" code base. But with open source it is terribly easy to create
>> your own fork and show that your stuff is better. Yes, with forking
>> comes maintenance and other costs, so one must decide whether to fork,
>> fight with the maintainers for inclusion or simply abandon the project.
>>
>> It's not an easy taskt to make the world a better place.
>>
>> > The problem is interactive graphics require multi-threading and I
>> > can't see anyone agreeing to a limitation that SPAD can only work on
>> > top of some specialised lisp with multi-threading. I suspect that is
>> > the reason for the C code to allow multi-threading.
>>
>> Hmmm... strangely enough we have jFriCAS, it was easier if FriCAS is
>> compiled with a lisp that has a webserver built-in. And, in fact,
>> jFriCAS is only properly working with SBCL (at least I haven't tested
>> with other lisps).
>> What I want to say is that your interactive graphics system can work on
>> a certain type of lisp. It just means that by default FriCAS provides
>> the old graphics system and your features would require the users to
>> compile with a specific lisp. Why should that be a problem. Your
>> graphics system would be optional and whether to compile it or not is
>> only a configure option away. That would reduce maintenance cost for
>> anybody else except you. You then must show that you are interested and
>> prove it by maintaining your code and fixing bugs.
>> Maybe Waldek would still be against, but having a better interactive
>> graphics system would get support from me for its includion as an
>> (optional) add-on.
>>
>> > People usually suggest using their favorite 3rd party graphical
>> > front end but I can't see Waldek making FriCAS totally reliant on
>> > some 3rd party software.
>>
>> Yes, that is dangerous. But allowing users to decide, is another.
>>
>> > Another problem is that graphic interfaces, hardware, file formats
>> > change rapidly and these interfaces need more maintainable code.
>>
>> Yes, of course, some people like old code more since they are used to it
>> and know how it works, the younger generation probably want newer system
>> and newer code. And surely, knowing all the newer graphics systems I
>> would be unwilling to support any weird old stuff and fight for
>> inclusion of newer technology. That's not a bad thing.
>>
>> > For example will FriCAS support X11 to wayland transition?
>>
>> Well, there are only two options. 1) It will. 2) FriCAS will lose it's
>> graphics capabilities. Which one would you choose if you were a
>> maintainer of FriCAS?
>>
>> Ralf
>>
>> --
>> 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 

Re: [fricas-devel] problems with installing FriCAS 1.3.10 on MacOS with ECL

[Dima Pasechnik]

On Tue, Mar 19, 2024 at 12:51 PM Qian Yun  wrote:

>
>
> On 3/19/24 19:17, Dima Pasechnik wrote:
> > On Mon, Mar 18, 2024 at 11:38 PM Qian Yun  wrote:
> >
> >>
> >> Is there an update for this?
> >>
> >
> > we have, hmm, large internal disturbances at @sagemath. Devs blocking
> each
> > other on GitHub, devs quitting, etc etc. Takes a lot of time...
> >
>
> Well, that's unfortunate.  But for the technical side, do you
> still have the FriCAS giving strange output in
> https://github.com/sagemath/sage/pull/37041#issuecomment-1889097696
>
> sage: x = fricas("x::TaylorSeries Fraction Integer")
> sage: y = fricas("y::TaylorSeries Fraction Integer")
> sage: 2*(1+2*x+sqrt(1-4*x)-2*x*y).recip()
>
> 2
> --
>   +-+
> \|- 4 sage0 + 1  - 2 sage0 sage1 + 2 sage0 + 1
>
>
> this and other weird errors reported there are now gone, just checked.



> >>
> >> I'd like to see fricas-1.3.10 get included in sage-10.3 release.
> >> (Also the ECL fix since ECL is already updated.)
> >>
> >
> > ECL update is pending. Have you tested
> > https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/324
> > ?
>
> I have not test this RC version.  What I meant is to add the patch
> https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/303
> to ecl-23.9.9 in sage.
>
> >
> >>
> >> Is that possible since it's already in RC stage?
> >> (When will sage-10.3 be released BTW?)
> >>
> > quite soon, I think.
>
> While, I think it's OK to include fricas-1.3.10 in sage-10.4 as well.
>

By right, FriCAS is better built with sbcl (at least until there is a
faster interface,
via a compiled ECL module, like the one we have for Maxima).
But the overtly rigid Sage packaging system would then require sbcl become
a Sage package too,
(at least if FriCAS becomes a standard package)
etc etc. These sorts of issues are a large part of the reasons for
disturbances I mentioned, people are tired of this (IMHO) nonsense).

Dima

>>
> >> On 3/5/24 03:07, Dima Pasechnik wrote:
> >>> On Mon, Mar 4, 2024 at 12:33 AM Qian Yun  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Can you confirm that restarting the build fails at different
> >>>> places?
> >>>>
> >>>> In the mean time, I think this is the same upstream issue:
> >>>>
> >>>> https://gitlab.com/embeddable-common-lisp/ecl/-/issues/718
> >>>>
> >>>> It is a long thread, but I believe this is the fix:
> >>>>
> >>>> https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/303
> >>>
> >>>
> >>> yes, I can confirm that I can build a seemingly working fricas with the
> >>> latest ECL master branch,
> >>> which has this merge request merged.
> >>>
> >>> I'll report more on this as I see tests.
> >>>
> >>>
> >>>>
> >>>>
> >>>> It should also help with
> https://github.com/sagemath/sage/issues/37511
> >>>>
> >>>> - Best,
> >>>> - Qian
> >>>>
> >>>> On 3/4/24 04:30, Dima Pasechnik wrote:
> >>>>> In case, I never tried building ECL on M1, I always used the
> Homebrew's
> >>>> version.
> >>>>>
> >>>>> On 3 March 2024 09:59:32 GMT, Qian Yun  wrote:
> >>>>>> Hi Dima,
> >>>>>>
> >>>>>> For the build on ARM Macs, I uses ECL-23.9.9 from homebrew.
> >>>>>>
> >>>>>> First time it fails at compiling EVALAB-.fas (same Error code 6).
> >>>>>>
> >>>>>> Second time it builds successfully.
> >>>>>>
> >>>>>> So can you try again to see if the failure is random?
> >>>>>> (revert commit 5b7d3163 if you compile master branch.)
> >>>>>>
> >>>>>> - Best,
> >>>>>> - Qian
> >>>>>>
> >>>>>> On 2/12/24 23:02, 'Martin R' via FriCAS - computer algebra system
> >> wrote:
> >>>>>>> Dima reports the following on
> >>>>>>>
> https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
> >>>>>>>
> >>>>>>> Apparently, this is using ecl (using the standard 

Re: [fricas-devel] update autoconf stuff

[Dima Pasechnik]

On Mon, Mar 18, 2024 at 11:08 PM Waldek Hebisch  wrote:

> On Mon, Mar 18, 2024 at 10:39:05PM +0800, Qian Yun wrote:
> > I see that "configure" is updated in branch r1.3.10 by
> > autoconf 2.71.  I suggest we do the same for master branch.
> > (Using 2.71 or 2.72 is debatable.)
>
> Well, 'configure' is supposed to be portable.  We update it
> when there is a need.  Since for release 'configure' contains
> version number each release needs its own 'configure'.  ATM
> I see no reason to regenerate 'configure' in the trunk.
>

after ./configure et al. are generated, it's all portable.
One immediate reason to use 2.72 is correct year 2038 support (something
which
boils down to how time_t behaves on 32-bit systems).
E.g. recently I had some fun with porting nauty to modern autoconf:
https://bugs.gentoo.org/921138

>
> > Also, we can update various files under "config/".  Although
> > it is not required for the arm64 mac build.  But they have
> > not been updated for a very very long time.
>

this is not true. E.g. the log for config/configure.sub and config.guess
shows a number of updates in last year, this year, and more since 2020
(after a gap in 2017-2019)
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=history;f=build-aux/config.sub;h=2c6a07ab3c34eabed8318ec0a37c0cc23b77a63f;hb=HEAD

http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=history;f=build-aux/config.guess;h=f6d217a49f8f4a664e1437306f3c4196793dcb35;hb=HEAD

(yes, a lot of it  are just dates bumps, but there a very meaningful
changes too)


>
> This is slowly changing stuff.  AFAICS upstream changes are
> mostly churn.  In the future we probably will need RISC-V stuff,
> but it does not look urgent.
>

Well, it is urgent.
I know people already running Risc-V boads, and I'm getting one soon, too.


>
> >
> > It can be updated by:
> >
> >
> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
> >
> > wget -O config.guess '
> https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
> '
> > wget -O config.sub '
> https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
> '
> >
> >
> > And "install-sh  missing  mkinstalldirs" is provided by automake.
>
> Note that we _do not_ use automake and I very much prefer to avoid it
> (and related bloat).
>

sure - but there are things, such as config.rpath, which ended up in
automake at some point;
the right way to get them into the code, but avoid automake, is by using
gnulib.
Does fricas use gnulib?
(yes, Sage used to "manually" copy files from automake, but we switched to
using gnulib,
which basically means to run it once every few years, check files it
generates into the git repo, and update what it produces, if needed)

Dima

-- 
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/CAAWYfq3tGmAAV91y-7L_3S0O9-1%3DwM3GwFBZDeX%3DErW9jBGWcg%40mail.gmail.com.

Re: [fricas-devel] problems with installing FriCAS 1.3.10 on MacOS with ECL

[Dima Pasechnik]

On Mon, Mar 18, 2024 at 11:38 PM Qian Yun  wrote:

>
> Is there an update for this?
>

we have, hmm, large internal disturbances at @sagemath. Devs blocking each
other on GitHub, devs quitting, etc etc. Takes a lot of time...


>
> I'd like to see fricas-1.3.10 get included in sage-10.3 release.
> (Also the ECL fix since ECL is already updated.)
>

ECL update is pending. Have you tested
https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/324
?


>
> Is that possible since it's already in RC stage?
> (When will sage-10.3 be released BTW?)
>
quite soon, I think.


>
> - Qian
>
> On 3/5/24 03:07, Dima Pasechnik wrote:
> > On Mon, Mar 4, 2024 at 12:33 AM Qian Yun  wrote:
> >
> >> Hi,
> >>
> >> Can you confirm that restarting the build fails at different
> >> places?
> >>
> >> In the mean time, I think this is the same upstream issue:
> >>
> >> https://gitlab.com/embeddable-common-lisp/ecl/-/issues/718
> >>
> >> It is a long thread, but I believe this is the fix:
> >>
> >> https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/303
> >
> >
> > yes, I can confirm that I can build a seemingly working fricas with the
> > latest ECL master branch,
> > which has this merge request merged.
> >
> > I'll report more on this as I see tests.
> >
> >
> >>
> >>
> >> It should also help with https://github.com/sagemath/sage/issues/37511
> >>
> >> - Best,
> >> - Qian
> >>
> >> On 3/4/24 04:30, Dima Pasechnik wrote:
> >>> In case, I never tried building ECL on M1, I always used the Homebrew's
> >> version.
> >>>
> >>> On 3 March 2024 09:59:32 GMT, Qian Yun  wrote:
> >>>> Hi Dima,
> >>>>
> >>>> For the build on ARM Macs, I uses ECL-23.9.9 from homebrew.
> >>>>
> >>>> First time it fails at compiling EVALAB-.fas (same Error code 6).
> >>>>
> >>>> Second time it builds successfully.
> >>>>
> >>>> So can you try again to see if the failure is random?
> >>>> (revert commit 5b7d3163 if you compile master branch.)
> >>>>
> >>>> - Best,
> >>>> - Qian
> >>>>
> >>>> On 2/12/24 23:02, 'Martin R' via FriCAS - computer algebra system
> wrote:
> >>>>> Dima reports the following on
> >>>>> https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
> >>>>>
> >>>>> Apparently, this is using ecl (using the standard SageMath setup).
> >>>>> Unfortunately, I cannot help except for reporting, because I do not
> >> have
> >>>>> access to a  mac.
> >>>>>
> >>>>> It would be wonderful if you could help!  Best wishes,
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> message by Dima 
> >>>>>
> >>>>> at the moment, with a recent bunch of macOS tools on M1, fricas in
> Sage
> >>>>> just doesn't build:
> >>>>> ;;; Style warning:
> >>>>> ;;;   in file define.clisp, position 165810
> >>>>> ;;;   at (DEFUN DomainSubstitutionFunction,Subst ...)
> >>>>> ;;;   ! Variable $extraParms was undefined. Compiler assumes it is a
> >>>>> global.thread_suspend failed
> >>>>>
> >>>>> ;;; Internal error:
> >>>>> ;;;   ** Error code 6 when executing
> >>>>> ;;; (EXT:RUN-PROGRAM "clang" ("-I."
> >>>>> "-I/opt/homebrew/Cellar/ecl/23.9.9/include/"
> >>>>> "-I/opt/homebrew/opt/gmp/include"
> >>>>> "-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/include"
> >>>>> "-I/opt/homebrew/opt/bdw-gc/include" "-g" "-O2" "-fPIC" "-fno-common"
> >>>>> "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-c" "define.c" "-o" "define.o")):
> >>>>> ;;; make[5]: *** [define.o] Error 1
> >>>>> make[4]: *** [all-interpsys] Error 2
> >>>>> make[3]: *** [all-src] Error 2
> >>>>>
> >>
> 
> >>>>> Error building fricas-1.3.10
> >>>>>
> >>>>
> >>>
> >>
> >> --
> >> 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/3cb49c6c-4fd3-40ec-8f9f-3bfa4b1b0d63%40gmail.com
> >> .
> >>
> >
>
> --
> 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/941ab891-b408-4cca-948e-dab16b806ab5%40gmail.com
> .
>

-- 
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/CAAWYfq0JGTDqJt0hkGCmg8wF1uUG0xDnehSE4yH0SrcEOFfA0Q%40mail.gmail.com.

Re: [fricas-devel] update autoconf stuff

[Dima Pasechnik]

On Mon, Mar 18, 2024 at 2:39 PM Qian Yun  wrote:

> I see that "configure" is updated in branch r1.3.10 by
> autoconf 2.71.  I suggest we do the same for master branch.
> (Using 2.71 or 2.72 is debatable.)
>

2.72 is a bugfix release, so it's better to use it


>
> Also, we can update various files under "config/".  Although
> it is not required for the arm64 mac build.  But they have
> not been updated for a very very long time.
>
> It can be updated by:
>
> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
>
> wget -O config.guess
> '
> https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
> '
> wget -O config.sub
> '
> https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
> '
>
>
> And "install-sh  missing  mkinstalldirs" is provided by automake.
>
> - 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/485e0839-b320-4a6a-aca8-1979fb7ee72a%40gmail.com
> .
>

-- 
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/CAAWYfq23hvLRDD4JtKUQV5CuW%2BAPvscjRgi%3DrTur_0aHYwXg_w%40mail.gmail.com.

Re: [fricas-devel] all of a sudden fricas does not longer start: change to MacOS Sonoma 14.3.1

[Dima Pasechnik]

Probably an OS upgrade requires a rebuild of sbcl.


On 8 March 2024 15:34:02 GMT, "Prof. Dr. Johannes Grabmeier" 
 wrote:
>Hi all,
>
>all of a sudden (I have moved to MacOS version Sonoma 14.3.1) FriCAS does no 
>longer start:
>
>/usr/local/bin$ fricas
>mmap: Operation not permitted
>fatal error encountered in SBCL pid 1525 pthread 0x1d86b5c40:
>load_core_bytes(3,6,0x3,1) failed
>
>Bad frame pointer 0x1d86b5cec [valid range=0x3..0x1]
>
>
>Any hints what to do: New version of SBCL required? New compilation od FriCAS, 
>anything else?
>
>

-- 
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/9A041C5B-C430-49DE-AF94-58EE428FA2AD%40gmail.com.

Re: [fricas-devel] arm64 macOS build is available!

[Dima Pasechnik]

There are many reasons for macOS to not like an unsigned dmg. E.g. it might 
require a special permission from the admin.
I have this setup on an x86_64 macOS machine from my employer
There can also be an antivirus soft blocing suchdmgs


On 6 March 2024 12:14:54 GMT, Qian Yun  wrote:
>Hi Dr. Johannes,
>
>Can you check that the file you downloaded has the following md5sum:
>8ead8361582d5ecfde87240e909dcfd2
>
>Also I wonder if other people have the same problem...
>
>- Qian
>
>On 3/5/24 23:59, Dima Pasechnik wrote:
>> On Tue, Mar 5, 2024 at 10:39 AM Qian Yun  wrote:
>> 
>>> Thanks for your testing.  Although this message is not what I expected:
>>> I was expecting something like "app not signed".
>>> 
>>> The only (unlikely) explanation for this is the downloading process
>>> is corrupted.
>>> 
>> 
>> you can make sure this is not the case by computing and publishing md5 or
>> sha256 of the image,
>> then the image may be verified  for corruption during download.
>> 
>> 
>>> 
>>> - Best,
>>> - Qian
>>> 
>>> On 3/5/24 16:17, Prof. Dr. Johannes Grabmeier wrote:
>>>> Hi Quin,
>>>> 
>>>> not much info: double click on FriCAS symbol resulted in the pop up
>>>> window: Translation of German error message is:
>>>> 
>>>> FriCAS is corrupted and cannot be opened. Recommendation is to throw out
>>>> the image
>>>> 
>>>> 
>>>> Am 04.03.24 um 01:19 schrieb Qian Yun:
>>>>> Hi,
>>>>> 
>>>>> Can you give a more detailed description of the error?
>>>>> Very likely it is caused by the fact that this dmg is unsigned.
>>>>> 
>>>>> I hear that it is very verbose to install unsigned apps on macos-14,
>>>>> especially so on ARM machines.
>>>>> 
>>>>> - Qian
>>>>> 
>>>>> On 3/3/24 19:33, Prof. Dr. Johannes Grabmeier wrote:
>>>>>> Hi Qian,
>>>>>> 
>>>>>> Thanks for your effords. But it does not run on my machine. Double
>>>>>> Click (DiskImageMounter) first created an app with FriCAS-logo, but
>>>>>> this then gave an error. Now double click of the dmg file seems to do
>>>>>> nothing at all any longer.
>>>>>> 
>>>>>> Johannes
>>>>>> 
>>>>>> 
>>>>>> Am 03.03.24 um 05:22 schrieb Qian Yun:
>>>>>>> I just found out that github CI enabled arm64 macOS runner
>>>>>>> one month ago:
>>>>>>> 
>>>>>>> 
>>> https://github.blog/changelog/2024-01-30-github-actions-macos-14-sonoma-is-now-available/
>>>>>>> 
>>>>>>> So after some minor tweaking, the arm64 macOS build of FriCAS
>>>>>>> is available now:
>>>>>>> 
>>>>>>> 
>>> https://github.com/fricas/fricas-nightly-builds/releases/download/nightly/FriCAS-2024-03-03T03.49-macOS-arm64-52126cc2.dmg
>>>>>>> 
>>>>>>> I can't test it myself, so I invite arm Mac users to give it a test.
>>>>>>> Note that this file is not signed.
>>>>>>> 
>>>>>>> But if everything is fine, I can get my friend to sign the x86-64
>>>>>>> and arm64 version of 1.3.10 release dmg file.
>>>>>>> 
>>>>>>> P.S the new arm64 macOS runner is very fast: it can compile FriCAS
>>>>>>> and run tests in 3.5 minutes, twice the speed of Linux runner.
>>>>>>> 
>>>>>>> - 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/3d02e912-6d92-42bd-83fe-3d4b36391890%40gmail.com
>>> .
>>> 
>> 
>

-- 
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/7B9A16FB-FF42-485E-944C-9C2BC524C3F8%40gmail.com.

Re: [fricas-devel] arm64 macOS build is available!

[Dima Pasechnik]

On Tue, Mar 5, 2024 at 10:39 AM Qian Yun  wrote:

> Thanks for your testing.  Although this message is not what I expected:
> I was expecting something like "app not signed".
>
> The only (unlikely) explanation for this is the downloading process
> is corrupted.
>

you can make sure this is not the case by computing and publishing md5 or
sha256 of the image,
then the image may be verified  for corruption during download.


>
> - Best,
> - Qian
>
> On 3/5/24 16:17, Prof. Dr. Johannes Grabmeier wrote:
> > Hi Quin,
> >
> > not much info: double click on FriCAS symbol resulted in the pop up
> > window: Translation of German error message is:
> >
> > FriCAS is corrupted and cannot be opened. Recommendation is to throw out
> > the image
> >
> >
> > Am 04.03.24 um 01:19 schrieb Qian Yun:
> >> Hi,
> >>
> >> Can you give a more detailed description of the error?
> >> Very likely it is caused by the fact that this dmg is unsigned.
> >>
> >> I hear that it is very verbose to install unsigned apps on macos-14,
> >> especially so on ARM machines.
> >>
> >> - Qian
> >>
> >> On 3/3/24 19:33, Prof. Dr. Johannes Grabmeier wrote:
> >>> Hi Qian,
> >>>
> >>> Thanks for your effords. But it does not run on my machine. Double
> >>> Click (DiskImageMounter) first created an app with FriCAS-logo, but
> >>> this then gave an error. Now double click of the dmg file seems to do
> >>> nothing at all any longer.
> >>>
> >>> Johannes
> >>>
> >>>
> >>> Am 03.03.24 um 05:22 schrieb Qian Yun:
>  I just found out that github CI enabled arm64 macOS runner
>  one month ago:
> 
> 
> https://github.blog/changelog/2024-01-30-github-actions-macos-14-sonoma-is-now-available/
> 
>  So after some minor tweaking, the arm64 macOS build of FriCAS
>  is available now:
> 
> 
> https://github.com/fricas/fricas-nightly-builds/releases/download/nightly/FriCAS-2024-03-03T03.49-macOS-arm64-52126cc2.dmg
> 
>  I can't test it myself, so I invite arm Mac users to give it a test.
>  Note that this file is not signed.
> 
>  But if everything is fine, I can get my friend to sign the x86-64
>  and arm64 version of 1.3.10 release dmg file.
> 
>  P.S the new arm64 macOS runner is very fast: it can compile FriCAS
>  and run tests in 3.5 minutes, twice the speed of Linux runner.
> 
>  - 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/3d02e912-6d92-42bd-83fe-3d4b36391890%40gmail.com
> .
>

-- 
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/CAAWYfq1f1o1pE3LmijdOd%3DBU1tPpS%2BpZaGMg3DNC_Xe4Ce759g%40mail.gmail.com.

Re: [fricas-devel] problems with installing FriCAS 1.3.10 on MacOS with ECL

[Dima Pasechnik]

On Mon, Mar 4, 2024 at 12:33 AM Qian Yun  wrote:

> Hi,
>
> Can you confirm that restarting the build fails at different
> places?
>
> In the mean time, I think this is the same upstream issue:
>
> https://gitlab.com/embeddable-common-lisp/ecl/-/issues/718
>
> It is a long thread, but I believe this is the fix:
>
> https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/303


yes, I can confirm that I can build a seemingly working fricas with the
latest ECL master branch,
which has this merge request merged.

I'll report more on this as I see tests.


>
>
> It should also help with https://github.com/sagemath/sage/issues/37511
>
> - Best,
> - Qian
>
> On 3/4/24 04:30, Dima Pasechnik wrote:
> > In case, I never tried building ECL on M1, I always used the Homebrew's
> version.
> >
> > On 3 March 2024 09:59:32 GMT, Qian Yun  wrote:
> >> Hi Dima,
> >>
> >> For the build on ARM Macs, I uses ECL-23.9.9 from homebrew.
> >>
> >> First time it fails at compiling EVALAB-.fas (same Error code 6).
> >>
> >> Second time it builds successfully.
> >>
> >> So can you try again to see if the failure is random?
> >> (revert commit 5b7d3163 if you compile master branch.)
> >>
> >> - Best,
> >> - Qian
> >>
> >> On 2/12/24 23:02, 'Martin R' via FriCAS - computer algebra system wrote:
> >>> Dima reports the following on
> >>> https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
> >>>
> >>> Apparently, this is using ecl (using the standard SageMath setup).
> >>> Unfortunately, I cannot help except for reporting, because I do not
> have
> >>> access to a  mac.
> >>>
> >>> It would be wonderful if you could help!  Best wishes,
> >>>
> >>> Martin
> >>>
> >>> message by Dima 
> >>>
> >>> at the moment, with a recent bunch of macOS tools on M1, fricas in Sage
> >>> just doesn't build:
> >>> ;;; Style warning:
> >>> ;;;   in file define.clisp, position 165810
> >>> ;;;   at (DEFUN DomainSubstitutionFunction,Subst ...)
> >>> ;;;   ! Variable $extraParms was undefined. Compiler assumes it is a
> >>> global.thread_suspend failed
> >>>
> >>> ;;; Internal error:
> >>> ;;;   ** Error code 6 when executing
> >>> ;;; (EXT:RUN-PROGRAM "clang" ("-I."
> >>> "-I/opt/homebrew/Cellar/ecl/23.9.9/include/"
> >>> "-I/opt/homebrew/opt/gmp/include"
> >>> "-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/include"
> >>> "-I/opt/homebrew/opt/bdw-gc/include" "-g" "-O2" "-fPIC" "-fno-common"
> >>> "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-c" "define.c" "-o" "define.o")):
> >>> ;;; make[5]: *** [define.o] Error 1
> >>> make[4]: *** [all-interpsys] Error 2
> >>> make[3]: *** [all-src] Error 2
> >>>
> 
> >>> Error building fricas-1.3.10
> >>>
> >>
> >
>
> --
> 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/3cb49c6c-4fd3-40ec-8f9f-3bfa4b1b0d63%40gmail.com
> .
>

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

Re: [fricas-devel] problems with installing FriCAS 1.3.10 on MacOS with ECL

[Dima Pasechnik]

In case, I never tried building ECL on M1, I always used the Homebrew's version.

On 3 March 2024 09:59:32 GMT, Qian Yun  wrote:
>Hi Dima,
>
>For the build on ARM Macs, I uses ECL-23.9.9 from homebrew.
>
>First time it fails at compiling EVALAB-.fas (same Error code 6).
>
>Second time it builds successfully.
>
>So can you try again to see if the failure is random?
>(revert commit 5b7d3163 if you compile master branch.)
>
>- Best,
>- Qian
>
>On 2/12/24 23:02, 'Martin R' via FriCAS - computer algebra system wrote:
>> Dima reports the following on
>> https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
>> 
>> Apparently, this is using ecl (using the standard SageMath setup).
>> Unfortunately, I cannot help except for reporting, because I do not have
>> access to a  mac.
>> 
>> It would be wonderful if you could help!  Best wishes,
>> 
>> Martin
>> 
>> message by Dima 
>> 
>> at the moment, with a recent bunch of macOS tools on M1, fricas in Sage
>> just doesn't build:
>> ;;; Style warning:
>> ;;;   in file define.clisp, position 165810
>> ;;;   at (DEFUN DomainSubstitutionFunction,Subst ...)
>> ;;;   ! Variable $extraParms was undefined. Compiler assumes it is a
>> global.thread_suspend failed
>> 
>> ;;; Internal error:
>> ;;;   ** Error code 6 when executing
>> ;;; (EXT:RUN-PROGRAM "clang" ("-I."
>> "-I/opt/homebrew/Cellar/ecl/23.9.9/include/"
>> "-I/opt/homebrew/opt/gmp/include"
>> "-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/include"
>> "-I/opt/homebrew/opt/bdw-gc/include" "-g" "-O2" "-fPIC" "-fno-common"
>> "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-c" "define.c" "-o" "define.o")):
>> ;;; make[5]: *** [define.o] Error 1
>> make[4]: *** [all-interpsys] Error 2
>> make[3]: *** [all-src] Error 2
>> 
>> Error building fricas-1.3.10
>> 
>

-- 
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/70934F91-B05A-489C-B581-1196726625E8%40gmail.com.

Re: [fricas-devel] Re: Google Gemini response about FriCAS

[Dima Pasechnik]

Oh, wow, Bernard Parisse develops FriCAS while taking a break from developing 
giac...

On 15 February 2024 20:44:05 GMT, Ralf Hemmecke  wrote:
>Hi Tim,
>
>I didn't know that you forked your own project. ;-)
>
>Anyway, it is so obvious that Gemini is just uttering something without ever 
>taking any action to verify what came out from his/her/their neurons. :-(
>
>Ralf
>
>=
>
>who are the developers of fricas
>
>Show drafts
>
>FriCAS doesn't have a single main developer or a small, closed team. It's an 
>open-source project with a diverse group of contributors. Here's what I found:
>
>Origin:
>
>Tim Daly forked Axiom, a computer algebra system, to create FriCAS in 
> 2007. He made significant contributions to FriCAS' early development.
>
>Current Developers:
>
>FriCAS is an active project with a community of contributors on GitHub. 
> While there's no single leader, some active contributors include:
>Michel Granger
>Claude Legrand
>Marc Ryba
>Bernard Parisse
>And many others
>
>Additional resources:
>
>FriCAS Github repository: https://github.com/fricas/fricas
>Discussion about FriCAS development: 
> https://news.ycombinator.com/item?id=16941306
>FriCAS official website: https://github.com/fricas/fricas
>
>Remember, FriCAS is an ongoing project, and the developer community can evolve 
>over time. If you're interested in the latest information, the resources above 
>are a good starting point.
>

-- 
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/4836A184-F010-4C08-8C1B-93BCFED9A152%40gmail.com.

Re: [fricas-devel] problems with installing FriCAS 1.3.10 on MacOS with ECL

[Dima Pasechnik]

We can arrange ssh access to an M1 box.
Ping me (and/or William Stein) if you like one.

On Mon, Feb 12, 2024 at 6:40 PM Waldek Hebisch  wrote:

> On Mon, Feb 12, 2024 at 07:02:39AM -0800, 'Martin R' via FriCAS - computer
> algebra system wrote:
> > Dima reports the following on
> > https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
> >
> > Apparently, this is using ecl (using the standard SageMath setup).
> > Unfortunately, I cannot help except for reporting, because I do not have
> > access to a  mac.
> >
> > It would be wonderful if you could help!  Best wishes,
> >
> > Martin
> >
> > message by Dima 
> >
> > at the moment, with a recent bunch of macOS tools on M1, fricas in Sage
> > just doesn't build:
> > ;;; Style warning:
> > ;;;   in file define.clisp, position 165810
> > ;;;   at (DEFUN DomainSubstitutionFunction,Subst ...)
> > ;;;   ! Variable $extraParms was undefined. Compiler assumes it is a
> > global.thread_suspend failed
>  ^
>
> This message is printed by function 'GC_stop_world' in
> 'src/bdwgc/darwin_stop_world.c' in ECL sources.  That is clearly
> internal thing to ECL and ECL folks (or maybe whoever is maintaining
> Boehm-Demers-Weiser garbage collector) are right people to ask.
>
> >
> > ;;; Internal error:
> > ;;;   ** Error code 6 when executing
> > ;;; (EXT:RUN-PROGRAM "clang" ("-I."
> > "-I/opt/homebrew/Cellar/ecl/23.9.9/include/"
> > "-I/opt/homebrew/opt/gmp/include"
> > "-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/include"
> > "-I/opt/homebrew/opt/bdw-gc/include" "-g" "-O2" "-fPIC" "-fno-common"
> > "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-c" "define.c" "-o" "define.o")):
>
> Again, this looks like error message from ECL.
>
> > ;;; make[5]: *** [define.o] Error 1
> > make[4]: *** [all-interpsys] Error 2
> > make[3]: *** [all-src] Error 2
> >
> 
> > Error building fricas-1.3.10
>
> This looks like ECL problem.  Of course, it is possible that
> something is not kosher in FriCAS code and this causes failure.
> But ATM the only lead is to ECL internals.  I affraid that the
> best I could in principle do is to find smaller testcase than whole
> FriCAS sources.  But event that is not possible without a way
> to reproduce the problem.
>
> Anyway, smaller testcase should be possible using script for
> build from Lisp files (posted by Qian) and .lisp/.clisp files
> from build say on x86_64.  If this is problem with garbage
> collector (as it looks), then it is likely that to reproduce
> it one must load exactly the same things into running Lisp image.
> But basically, one has to try, either result would give extra
> info.  It is possible that merely recompiling 'define.clisp'
> in appropriate environment is already enough to trigger the
> problem.  But without access to failing build environment
> it is pure speculation...
>
> --
>   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/ZcpmNKJb5IUy2Xrx%40fricas.org
> .
>

-- 
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/CAAWYfq2%2BWQHvXmDY6sAqUjU4W1_%2BUdNrN-uCwVDBm9K0Sq2cPw%40mail.gmail.com.

Re: [fricas-devel] make build with sbcl-2.4.0 work out of box

[Dima Pasechnik]

On Tue, Jan 16, 2024 at 12:23 PM Qian Yun  wrote:
>
> With sbcl-2.4.0, we need to use
>
>  ./configure --with-lisp="sbcl --dynamic-space-size 2048"
>
> which is inconvenient and caused problems/confusion for a few
> people already.
>
> I wonder if there's a way to make "./configure" work again.
>
> If we add "--dynamic-space-size 2048" to fricas_quiet_flags,
> then we can't overwrite the dynamic-space-size anymore.
>
> (Because we use
>  LISP_CMD = $(FRICAS_LISP) $(fricas_quiet_flags)
> the options in fricas_quiet_flags will overwrite options in FRICAS_LISP)
>
>
> The only way I can think of is to add a new configure option:
> --with-lisp-option.
>
> Any ideas?

it should be easy to basically let ./configure convert --with-lisp=sbcl into
--with-lisp="sbcl --dynamic-space-size 2048"

>
> - 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/6a77b463-e750-40f5-bc67-f7237eddee4c%40gmail.com.

-- 
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/CAAWYfq3oNk-bHohde%3DuekHjxX6cfNtE%2BYr3k_30Effa3zO70EQ%40mail.gmail.com.

Re: [fricas-devel] GPT4 and computer algebra

[Dima Pasechnik]

On Mon, Jan 15, 2024 at 10:45 PM Hill Strong  wrote:
>
> No artificial stupidity (AI) will ever or should ever be considered as [a 
> trustworthy co-author in mathematical research]. At best, these systems could 
> be a possibly useful tool in the hands of those who know their subject field. 
> In the hands of everyone else they will be like young children using power 
> tools - a dangerous proposition at best and an utter disaster at worse.
>
> There is far too much unthinking hype about the subject even by the 
> researchers in the field.

Well, we all know Doron Zeilberger's co-author:
https://sites.math.rutgers.edu/~zeilberg/ekhad.html

In this sense it's not new at all. More powerful, yes, but still...

>
> On Tue, 16 Jan 2024, 12:10 am Tim Daly,  wrote:
>>
>> "When integrated with tools such as formal proof verifiers,
>> internet search, and symbolic math packages, I expect, say,
>> 2026-level AI, when used properly, will be a trustworthy
>> co-author in mathematical research, and in many other fields
>> as well" -- Terrance Tao
>> https://youtu.be/3pb_-oLfWJ4?t=358
>>
>> I might add that it would be important that the computer algebra
>> algorithms be proven correct.
>>
>> --
>> 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/11e29cc8-7c91-4ad2-a56b-d380db9a33e3n%40googlegroups.com.
>
> --
> 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/CAEnaMTGr_Vk3qa-7X%3DVcPpmwuhEdcKySsngh1UaTmsTRgX9Lwg%40mail.gmail.com.

-- 
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/CAAWYfq36fDxKgk_wsx1g_Rx%3DaWWwv0uyKQHEpO5yBTbcEaNE9Q%40mail.gmail.com.

Re: [fricas-devel] FriCAS-1.3.10 on MacBook armv8-5a M2

[Dima Pasechnik]

I successfully built fricas 1.3.10 on macOS M1 (aarch64) machine, with
ECL 23.9.9 and the dependencies such as libgc and gmp supplied by
Homebrew.

I've run

./configure --with-lisp=ecl
--enable-case-insensitive-file-system-check=no && make && make install

I'll try sbcl too, and report.

On Thu, Jan 11, 2024 at 9:28 AM Qian Yun  wrote:
>
>
>
> On 1/11/24 17:17, Prof. Dr. Johannes Grabmeier wrote:
> > Hi Quian,
> >
> > thanks for your answer. Actually, 1.3.8 is running on my ARM Macs since
> > March last year. There were a lot of trouble because Mac still provides
> > emulation (?) to x86-64 architecture and there were some confusion
> > because of this, e.g.
> >
> > on iTerm2 I get
> >
> > uname -a
> > Darwin MBPvonJohannes.fritz.box 22.6.0 Darwin Kernel Version 22.6.0: Wed
> > Jul  5 22:21:53 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 x86_64
> >
> > while on a terminal I get
> >
> > uname -a
> > Darwin MBPvonJohannes.fritz.box 22.6.0 Darwin Kernel Version 22.6.0: Wed
> > Jul  5 22:21:53 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 arm64
> >
> > The problem now seems to be, that with all the corrections/work-arounds
> > and settings I managed to compile 1.3.8 last March, but this procedure
> > fails with the problem I reported yesterday.
>
> The config.log looks normal.
>
> Can you show me the workarounds you applied to 1.3.10?
> In theory no such workarounds are required.
>
> Also please attach a log of the make process like:
>make > make.log
> (Compress it if too huge.)
>
> - Qian
>
> > It seems that during the compilation process libspad.o is produced, "but
> > is an incompatible architecture (have 'x86_64', need 'arm64'))." Somehow
> > the wrong compiler is used again. That is the core of my question. Where
> > and how is this produced to find an idea to give right flags or so at
> > this step.
> >
> > I send my config.log. There is one reference in line 68 onf x86:
> >
> > PATH: /Users/jgrabmeier/adt-bundle-mac-x86_64-20140702/sdk/platform-tools/
> >
> > Thanks for all your help.
> >
> > Johannes
> >
> >
> >
> > Am 11.01.24 um 01:33 schrieb Qian Yun:
> >> Hi,
> >>
> >> First of all, you are the first ARM Mac user reporting build issues.
> >>
> >> The original plan is to wait one or two month so that Github Actions
> >> can provide ARM Mac runners, then I can add support for ARM Macs.
> >>
> >> Since I don't have access to this platform yet, here are my educated
> >> guesses:
> >>
> >> 1. Did you do something extra to the source files?
> >>
> >> AFAICS, the config/config.guess is outdated and it can't recognize
> >> a "arm-apple-darwin" system.  Can you post your config.log?
> >>
> >> 2. FriCAS doesn't propagate CFLAGS in Makefiles very well.
> >>
> >> So please post your full modifications to the source tarball.
> >>
> >> - Qian
> >>
> >> On 1/10/24 23:25, Prof. Dr. Johannes Grabmeier wrote:
> >>> Hi all,
> >>>
> >>> had a lot of trouble with wrong x86-64 when I installed 1.3.8 in
> >>> March last year. However, I finally managed to set everything
> >>> properly, e.g.
> >>>
> >>> in Makefile:  CC = gcc -march=armv8.5-a
> >>>
> >>> But now, compilation fails:
> >>>
> >>> gmake, stops with folllowing error, complaining that libspad.so
> >>> (which is newly compiled with the command set for CC in Makefile) has
> >>> x86_64 architecture.
> >>>
> >>> How can this happen? What is to do to get proper file für arm64?
> >>>
> >>> Thanks for any help!
> >>>
> >>>
> >>> Checking for foreign routines
> >>> FRICAS="/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0"
> >>> spad-lib="/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so"
> >>> foreign routines found
> >>>
> >>> debugger invoked on a SIMPLE-ERROR in thread
> >>> #:
> >>>Error opening shared object
> >>> "/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so":
> >>> dlopen(/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so,
> >>>  0x000A): tried: 
> >>> '/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so'
> >>>  (mach-o file, but is an incompatible architecture (have 'x86_64', need 
> >>> 'arm64')), 
> >>> '/System/Volumes/Preboot/Cryptexes/OS/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so'
> >>>  (no such file), 
> >>> '/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so'
> >>>  (mach-o file, but is an incompatible architecture (have 'x86_64', need 
> >>> 'arm64')).
> >>>
> >>> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
> >>>
> >>> restarts (invokable by number or by possibly-abbreviated name):
> >>>0: [ABORT] Exit from the current thread.
> >>>
> >>> (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME
> >>> #P"/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so"
> >>>  :NAMESTRING 
> >>> "/Users/jgrabmeier/fricas-1.3.10/target/arm-apple-darwin22.6.0/lib/libspad.so"
> >>>  :HANDLE NIL :DONT-SAVE NIL))
> >>>

Re: [fricas-devel] FriCAS 1.3.10 is released

[Dima Pasechnik]

On Wednesday, January 10, 2024 at 12:40:08 AM UTC oldk1331 wrote:

Hi Waldek, 

I see that you have not pushed 1.3.10 tag to Github and not created 
release page. 


there is still an incosistency wrt tags. There is no 1.3.10 tag,
only an r1.3.10 branch.



I suggest you to cherry-pick this commit to branch r1.3.10 first, 
then do the tagging, so that binary builds from tag 1.3.10 will be 
uploaded to the nig


 

htly builds page. And then you can download them 
and upload them to 1.3.10 release page. 

https://github.com/fricas/fricas/commit/8ba0305330ea6001bbf92d182f75054cef8c49eb
 

BTW, the linux amd64 binary seems fine to me. 

- Qian 

On 1/10/24 03:09, Waldek Hebisch wrote: 
> I have put sources and binaries of FriCAS 1.3.10 on Sourceforge. 
> 

-- 
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/1010ad68-093f-4d9e-88b1-91d034101542n%40googlegroups.com.

Re: [fricas-devel] FriCAS 1.3.10 is released

[Dima Pasechnik]

On Wed, Jan 10, 2024 at 2:50 PM oldk1331  wrote:
>
> Looks like a bash quoting problem. You may need to escape the quotes.

I guess it was using pairs of single quotes (') rather than single
double quotes (")
Otherwise I don't know how to reproduce this error.

>
> BTW, the default is 1GB. I usually test with 4GB. Not sure what the minimal 
> is.
>
> - Qian
>
> On Wed, Jan 10, 2024, 10:41 PM Andrey G. Grozin  wrote:
>>
>> On Wed, 10 Jan 2024, Qian Yun wrote:
>> > You can build with
>> >./configure --with-lisp="sbcl --dynamic-space-size 4096"
>>
>> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
>> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>> --localstatedir=/var/lib --datarootdir=/usr/share
>> --docdir=/usr/share/doc/fricas-1.3.10
>> --htmldir=/usr/share/doc/fricas-1.3.10/html --libdir=/usr/lib64
>> --disable-aldor --with-lisp="sbcl --dynamic-space-size 4096" --with-x
>> --with-gmp
>> configure: error: unrecognized option: `--dynamic-space-size'
>> Try `./configure --help' for more information
>>
>> Andrey
>>
>> --
>> 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/aa5cc496-fc3d-b77a-a66c-da597a81512e%40starnew.inp.nsk.su.
>
> --
> 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/CAGBJN92vgLc4JufmEP%2BENNw%3DR7RpF1ww%2BhLfGRKri3WL-0hYrA%40mail.gmail.com.

-- 
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/CAAWYfq3M-0tgXTv5wE08O7XENDxVVv%2B9enMcBo_E7pVr0LXFpg%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.10 is released

[Dima Pasechnik]

Perhaps something should be put into ~/.sbclrc to set this default bigger?

On Wed, Jan 10, 2024 at 2:50 PM oldk1331  wrote:
>
> Looks like a bash quoting problem. You may need to escape the quotes.
>
> BTW, the default is 1GB. I usually test with 4GB. Not sure what the minimal 
> is.
>
> - Qian
>
> On Wed, Jan 10, 2024, 10:41 PM Andrey G. Grozin  wrote:
>>
>> On Wed, 10 Jan 2024, Qian Yun wrote:
>> > You can build with
>> >./configure --with-lisp="sbcl --dynamic-space-size 4096"
>>
>> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
>> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>> --localstatedir=/var/lib --datarootdir=/usr/share
>> --docdir=/usr/share/doc/fricas-1.3.10
>> --htmldir=/usr/share/doc/fricas-1.3.10/html --libdir=/usr/lib64
>> --disable-aldor --with-lisp="sbcl --dynamic-space-size 4096" --with-x
>> --with-gmp
>> configure: error: unrecognized option: `--dynamic-space-size'
>> Try `./configure --help' for more information
>>
>> Andrey
>>
>> --
>> 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/aa5cc496-fc3d-b77a-a66c-da597a81512e%40starnew.inp.nsk.su.
>
> --
> 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/CAGBJN92vgLc4JufmEP%2BENNw%3DR7RpF1ww%2BhLfGRKri3WL-0hYrA%40mail.gmail.com.

-- 
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/CAAWYfq0fP7coS3qTDaCMpPN1yoOX450_usqEHV_YCh7rz8pRAQ%40mail.gmail.com.

Re: [fricas-devel] [PATCH] cleanup macos build

[Dima Pasechnik]

On Fri, Jan 5, 2024 at 9:33 PM Waldek Hebisch  wrote:
>
> On Fri, Jan 05, 2024 at 08:03:28PM +0800, Qian Yun wrote:
> > contrib/macos/mk_app is hopelessly outdated.
>
> I am not sure what you mean here.  Do you mean that it does not
> work and fixes are nontrivial?

Nowadays a functioning maOS app requires notarization and signing
(otherwise OS will keep nagging you, and probably won't even let you
install it) - which is not there,
and it's a bit tricky task to set up.

And it seems to me x86_64 only, whereas it's increasingly aarch64
(arm64) as far as
Apple's machines go.

Here is a Sage's macOS app: https://github.com/3-manifolds/Sage_macOS



> Or that everthing that 'mk_app'
> is doing is done better elsewhere?
>
> AFAIK 'mk_app' used to work and created "fully featured"
> application bundle for Mac OSX.  "fully featured" meaning including
> working HyperDoc and graphics.
>
> > I move the only useful line "sed FRICASVER" to Makefile.in.
> >
> > contrib/macos/README is also outdated, the TODOs in it are done.
> >
> > BTW, I think contrib/cygwin/ is outdated.
>
> Well, for several years using clisp on Cygwin does not work.
> IIUC it should work using ECL.
>
> > Is contrib/sbcl/,
> > contrib/omcl.diff also outdated?
>
> Well, they are "eternal" because they refer to specific past versions
> of sbcl/Clozure CL which are not going to change.  And AFAICS FriCAS
> still can run using those versions.
>
> BTW: most things in contrib are not part of normal FriCAS testing.
> So they may get broken.  Still, updating something that used to
> work is much easier than re-creating the whole thing.  So it
> makes sense to keep even non-working contribs.
>
> --
>   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/ZZh1wKZJHpj7pBms%40fricas.org.

-- 
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/CAAWYfq3viyOR1Jd5XZMsHt%3DJ_M0F1nsHZBNhgaBFKKWZzNGESA%40mail.gmail.com.

Re: [fricas-devel] [PATCH] 'fricas_has_remove_directory', again

[Dima Pasechnik]

On 3 January 2024 12:42:23 WET, Waldek Hebisch  wrote:
>On Wed, Jan 03, 2024 at 07:07:47PM +0800, Qian Yun wrote:
>> I suggest to check for symbol instead of "#+" feature testing.
>> 
>> This will allow FFI-free pure-lisp build.
>
>IMO pure-lisp build is futile.  We want to use GMP, blas, lapack
>and possibly our own routines.  Currently ECL and GCL use
>GMP for bignums, so that covers important part.  But we also
>would like to use GMP for polynomial multiplication and for
>that purpose bypassing Lisp bignums is very desirable.  Currently
>we have proof-of-concept lapack and blas interface.  Main issue
>blocking its inclusion is configure machinery to detect blas
>and lapack, 

you may want to use what we have in SageMath for 
blas/lapack detection.

We actually only use OpenBLAS (which is  the most 
popular optimised open-source BLAS/LAPACK implementation, available on almost 
all Linux, macOS, and *BSDs)

It's very easy if pkg-config for OpenBLAS is available.
(we do some tricky things to generate pkg-config files if they are not there, 
but perhaps you may just skip this, and assume it's available)


> FFI part is easy to resolve.
>
>> To quote the FriCAS development goals:
>> 
>> "make it easier for external programs to interface with FriCAS"
>> 
>> I think that FFI-free pure-lisp build is one step toward this goal.
>> 
>> fricas0 is one example that utilizes pure-lisp build.
>> 
>> In Sagemath, there's a pexpect (IO) based interface for FriCAS and
>> Maxima, but there's an additional ECL based interface for Maxima.
>> So using FriCAS as a pure-lisp library can have its advantages.
>
>Big point about ECL is ease of calling C code.  And it seems that
>to get good performance using ECL we need to call C: "native"
>ECL is too slow.  So really library use should include FFI.
>

-- 
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/5F92EA30-B76C-49A0-8AC8-1A5BFA119419%40gmail.com.

Re: [fricas-devel] [PATCH] 'fricas_has_remove_directory', again

[Dima Pasechnik]

I don't see why an embedded ECL-based FriCAS must be pure lisp. ECL has its FFI 
just fine.

In fact, one might consider developing a plain C library allowing calling 
FriCAS via libecl.so



On 3 January 2024 11:07:47 WET, Qian Yun  wrote:
>I suggest to check for symbol instead of "#+" feature testing.
>
>This will allow FFI-free pure-lisp build.
>
>To quote the FriCAS development goals:
>
>"make it easier for external programs to interface with FriCAS"
>
>I think that FFI-free pure-lisp build is one step toward this goal.
>
>fricas0 is one example that utilizes pure-lisp build.
>
>In Sagemath, there's a pexpect (IO) based interface for FriCAS and
>Maxima, but there's an additional ECL based interface for Maxima.
>So using FriCAS as a pure-lisp library can have its advantages.
>
>- Qian
>
>
>diff --git a/src/interp/nlib.lisp b/src/interp/nlib.lisp
>index 8c844fa7..ffdacae6 100644
>--- a/src/interp/nlib.lisp
>+++ b/src/interp/nlib.lisp
>@@ -304,10 +304,10 @@
> ;; ($ERASE filearg) -> 0 if succeeds else 1
> (defun |erase_lib|(filearg)
>   (if (|fricas_probe_file| filearg)
>-  #+:fricas_has_remove_directory
>-  (|remove_directory| filearg)
>-  #-:fricas_has_remove_directory
>-  (delete-directory filearg)
>+  (let ((sym (find-symbol "remove_directory" "FRICAS-LISP")))
>+(if sym
>+(funcall sym filearg)
>+(delete-directory filearg)))
>   1))
>
> (defun |erase_lib0|(fn ft) (|erase_lib| (|make_filename0| fn ft)))
>

-- 
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/7A691421-848F-454F-995B-EFDF991A4465%40gmail.com.

Re: [fricas-devel] Re: About the license file

[Dima Pasechnik]

On Tue, Dec 12, 2023 at 1:58 PM Tim Daly  wrote:
>
> This link raises the issue of developer liability, especially in the E.U.
> https://blog.hansenpartnership.com/solving-the-looming-developer-liability-problem/

It's about a UK court case. UK has left EU a while ago :-)

And the court case is by someone with very deep pockets suing people
they allege have control over Bitcoin wallets or something.

IMHO UK courts are willing to take any silly business case, you'd just
have to pay, a lot...

>
> If the software provides a method of attacking some business
> the developers might be liable for damages.

it's like a robbed bank suing a gun manufacturer, demanding it
provided a feature disabling its guns
in the bank's buildings...


>
> One route, for example, might be to exploit the X11 or other socket-based
> code to allow network attacks. The defensive measure would be to have a
> cryptographic handshake between the interpreter and the X11 code. There
> are many other exploit paths available.
>
> This is only one of the rising legal problems. Another one is that the E.U.
> is debating the question of whether software requires a "bill of materials"
> which tracks what software was / is used as part of the delivery.

Once the legal system is broken, you are never safe, full stop.


>
> Tim
>
>
> On Friday, December 8, 2023 at 2:40:05 PM UTC-5 Tim Daly wrote:
>>
>> I am not a lawyer either but as far as I understand it copyright law
>> varies from country to country and is covered by treaty. All of that
>> is "way above my pay grade".
>>
>> Despite having authored a reasonable bit of the code I claim no
>> copyright. In the U.S. I believe authored works are "born copyrighted".
>>
>> I tried to be very careful about including any and all copyright text
>> for any piece of software ever used. Most of the law is intended to
>> allow people to sue. I don't want to play that game. Axiom trademark
>> protection requirements are painful enough and make me look like
>> "the bad guy" because I'm required to take action. Sigh.
>>
>> Lawyers have spent lifetimes arguing over a single copyright like
>> GNU. I'm pretty sure I don't understand any of it.
>>
>> Ralf writes:
>> "I would like that the years are specified clearly. For example, the
>> last line in src/etc/copyright just says
>>
>> Portions Copyright (c) Renaud Rioboo and the University Paris 6.
>>
>> but give no starting and end year and no license part."
>>
>> Perhaps Renaud used some resources from his University
>> such as a University computer. If so then the University Paris 6
>> probably requires their copyright to be stated. Check with your
>> University legal department if you use their servers to host or
>> develop code at the University. Using their resources makes
>> them liable.
>>
>> In a copyright dispute the goal is to get money so the University
>> is likely to be a party to a suit. When I worked at City College of
>> New York I explicitly included language in my job description
>> saying that the University had no claim to Axiom. I developed
>> on my own equipment and time. I hosted axiom-developer.org
>> on a server under my desk at home. I kept the same setup
>> when I worked at CMU.
>>
>> I have no idea what French copyright law allows or requires.
>> In the U.S. I believe there is no requirement for year notation.
>> Also copyright in the U.S. extends from creation until
>> 70 years beyond the death of the author.
>>
>> It seems to me the safest course of action is to treat any
>> legal text anywhere as "binary code" and not try to interpret it,
>> delete it, modify it, or bury it.  I added the )copyright command.
>>
>> Just to see how bad things can get:
>> https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes
>>
>> Tim
>>
>>
>> On Friday, December 8, 2023 at 9:09:35 AM UTC-5 ra...@hemmecke.org wrote:
>>>
>>> On 12/8/23 14:39, Qian Yun wrote:
>>> > I just realized that there is also this file: "src/etc/copyright".
>>>
>>> P...
>>>
>>> As always, IANAL. Additionally I can only guess what "copyright"
>>> actually means. German law distiguishes between "Urheberrecht" and
>>> "Nutzungsrecht". The Urheberrecht basically says something about the
>>> creator of some work, the Nutzungsrecht says something about what can be
>>> done with the work. That looks like a relatively clear distinction.
>>> So basically all contributors to FriCAS can count as "Urheber" (creator)
>>> of the work (FriCAS) and by German law one cannot give the fact that
>>> he/she is the "Urheber" (in other words no German can put something into
>>> "public domain"). As the creator of some work one has the exclusive
>>> "Nutzungsrecht" (right to use the work). By a license one can allow
>>> others certain rights to use, distribute, copy (or whatever) the work.
>>>
>>> As far as I understand the american copyright is somewhat incompatible
>>> with the above view. What one usually sees is a copyright note and at
>>> the same time some text (list the BSD clauses) that say 

Re: [fricas-devel] About the license file

[Dima Pasechnik]

Windows can be told to be case-sensitive in a given folder:
https://www.howtogeek.com/354220/how-to-enable-case-sensitive-folders-on-windows-10/

On Thu, Nov 30, 2023 at 4:22 PM Ralf Hemmecke  wrote:
>
> Waldek,
>
> now that you suggest that LICENSE.AXIOM can be downloaded from github,
> I think we can savely remove "license/" completely and write a note to
> the end of the LICENSE file that the orginal NAG license file is in the
> very first commit of the git repository.
>
> It would be safe to check this out even on case insensitive file systems.
>
> Ralf
>
> On 11/30/23 17:07, Waldek Hebisch wrote:
> > On Thu, Nov 30, 2023 at 06:01:41PM +0800, Qian Yun wrote:
> >> Now that "LICENSE" is committed, there's a minor problem:
> >>
> >> On case-insensitive filesystems, "LICENSE" file is colliding
> >> with "license/" directory.
> >>
> >> I have confirmed that unpacking fricas-master.zip (from GitHub)
> >> on Windows causes problem: "LICENSE" is created while "LICENSE.AXIOM"
> >> is not.  (Similar problem might happen for git checkout.)
> >>
> >> So considering rename the "license/" directory? (e.g. "licence")
> >
> > Well, I am not sure if that is really a problem.  One reason to
> > keep license/LICENSE.AXIOM is because people where told that
> > orignal NAG license is there.  Renaming would defeat this.
> > OTOH Windows and Mac folks can fetch LICENSE.AXIOM from Github,
> > I think that is enough.  So as long as download do not produce
> > errors I think that we can live with this.
> >
>
> --
> 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/0e045f4b-09c9-4e00-9cd0-db82c57ad470%40hemmecke.org.

-- 
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/CAAWYfq00iBs8qAXrR_3gOO63gLEpH_R8Zx_1kC%3Dy9z9sFiPnbQ%40mail.gmail.com.

Re: [fricas-devel] FriCAS on Android with SBCL (on termux)

[Dima Pasechnik]

On 28 November 2023 23:16:02 GMT, Waldek Hebisch  wrote:
>On Tue, Nov 28, 2023 at 11:20:20PM +0700, Andrey G. Grozin wrote:
>> On Sun, 26 Nov 2023, Qian Yun wrote:
>> > I can confirm your error.  I was building successfully with
>> > 1.3.9 tarball.
>> Thanks. Indeed, 1.3.9 with your 1-line fix builds successfully:
>> 
>> ./comfigure --prefix=$PREFIX --with-lisp=sbcl
>> make
>> make install
>> 
>> succeeds. Then
>> 
>> ~ $ fricas
>> ...
>> sh: can't create /tmp/socks.11257: No such file or directory
>> ...
>> Fatal error opening I/O socket
>> 
>> Indeed, there is no /tmp. Is it possible to convince fricas to use
>> $PREFIX/tmp instead of /tmp?
>
>ATM no way, '/tmp' is hardcoded.  IIUC standard way is to use
>value of $TMPDIR as directory for temporary files.  We can implement
>this.  Does Android set TMPDIR to sensible value?  Or can you set it?
>
maybe calling mkdtemp(3) to get a unique temporary directory is better?
Probably some lisps have it implemented.


-- 
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/4723F879-F320-47F5-9554-6B1F4A6E667A%40gmail.com.

Re: [fricas-devel] real? sqrt (-sqrt 2)

[Dima Pasechnik]

On Mon, Nov 20, 2023 at 12:48 PM Waldek Hebisch  wrote:
>
> On Mon, Nov 20, 2023 at 06:20:45PM +0800, Qian Yun wrote:
> > Answer to myself: some real algebraic number need sqrt(-1) to
> > represent them (e.g. some root of degree 3 polynomial).
> > So RealClosure can't handle them I guess.
>
> No, this is not a problem.  RealClosure can handle real roots of
> polynomials without going into complex domain.  sqrt(-1) appears
> when one wants expression in radicals, but RealClosure represent
> roots in more general way.
>
> > - Qian
> >
> > On 11/20/23 07:45, Qian Yun wrote:
> > > Does RealClosure work with Expression? (e.g doing integration)
> > > Currently we can't do so in FriCAS.  Is that possible in theory?
>
> Currently you can have Expression(RealClosure(Fraction(Integer))):
>
> (8) -> sqrt(2)$eR
>
>  +-+
>(8)  \|2
>  Type: Expression(RealClosure(Fraction(Integer)))
> (9) -> kernels(sqrt(2)$eR)
>
>(9)  []
>Type: List(Kernel(Expression(RealClosure(Fraction(Integer)
> (10) -> sqrt(-1)$eR
>
>   +---+
>(10)  \|- 1
>  Type: Expression(RealClosure(Fraction(Integer)))
> (11) -> kernels(sqrt(-1)$eR)
>
>+---+
>(11)  [\|- 1 ]
>Type: List(Kernel(Expression(RealClosure(Fraction(Integer)
> (12) -> kernels(sqrt(2 + sqrt(-1)$eR))
>
>+--+
>| +---+
>(12)  [\|\|- 1  + 2 ]
>Type: List(Kernel(Expression(RealClosure(Fraction(Integer)
>
> (12) indicate possible confusion, mathematically the same thing may be
> expressed in different ways leading to troubles with unrecoginized
> zeros.
>
> For integration we need PolynomialFactorizationExplicit and that
> is absent for RealClosure.  To say the truth, it is not entirely
> clear what PolynomialFactorizationExplicit should do for
> RealClosure.  Interpreting it literally would mean splitting
> univariate polynomials into quadratic and linear factors, which
> is likely to be quite expensive.  After that we would have to
> implement multivariate factorization on top of this.  I guess
> that for multivariate factorization we probably should do
> absolute factorization first and then only one variable
> splitting.
>
> Note that methods used by RealClosure in principle could
> be generalized to elementary constants.  But they will
> fail in presence of parameters, that is for general
> expressions.
>
> Extra remark: it should be possible to get much of effect
> of RealClosure by considering pairs of AlgebraicNumber
> and floating point approximation.  Namely, we can compute
> minimal polynomial of algebraic number and moderately
> accurate floating point approximation uniquely determines
> corresponding exact root.  In case when we get reducible
> polynomials we could use floating point approximations to
> find right factor.

the corresponding exact root will also be uniquely determined by the
signs of k-th order derivatives,
for all k, of the minimal polynomial at the root.
This is called Thom encoding (cf e.g. https://arxiv.org/pdf/1609.02879.pdf).
The advantage is that it still works in a parametrised setting, and that
it does not need any approximations.

Dima
>
> --
>   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/ZVtVlGr6rtdJqSSX%40fricas.org.

-- 
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/CAAWYfq0TTzKBrmHFDgWxefOKeg0Prcn1unD-hfwji7_kvAYHZg%40mail.gmail.com.

Re: [fricas-devel] Make an Integral Work

[Dima Pasechnik]

On Mon, Oct 23, 2023 at 12:35 AM Mild Shock  wrote:
>
> >  There is 'romberg' in NumericalQuadrature package.
>
> Is this something under the heading "FriCAS API"?
>
> I have no clue how to load a package, and I even
> don't understand how I get into a ")" prompt?

")" is not a prompt, it's part of a command you type at "->" prompt,

>
> All I see when I start FriCAS is a "->" prompt:
>
> (1) ->
>
>
> Waldek Hebisch schrieb am Sonntag, 22. Oktober 2023 um 23:20:17 UTC+2:
>>
>> On Sat, Oct 21, 2023 at 03:49:08PM -0700, Mild Shock wrote:
>> > The slope multiplied by the distance would be,
>> > using real-valued root (the Wolfram Alpha assumption):
>> >
>> > integral_0^(2 π) 1/100 (2 + cos(t)) cos(t)^(1/3) dt = 0.0364298
>> > https://www.wolframalpha.com/input?i=integ_0%5E%282*pi%29+cos%28t%29%5E%281%2F3%29+%282%2Bcos%28t%29%29+%2F100+dt=%22%5E%22+-%3E+%22Real%22
>> >
>> > But I am not sure whether the interval - π/2 to π/2,
>> > as you suggest, would give me the slope.
>>
>> I suggested splitting interval into two parts: one where cos is
>> positive and one where it is negative. You then need to add
>> both parts, taking only one would be wrong.
>>
>> > The factor
>> > cos(t)^(1/3) is indeed positive in this interval, but
>> >
>> > the integrand itself is not symmetric, for example the
>> > range π/2 to π is not a mirror of the range 0 to π/2. Also
>> > the smaller interval doesn't improve integrability:
>> >
>> > (1) -> integrate(cos(t)^(1/3)*(2+cos(t))/100, t = -%pi/2..%pi/2, "noPole")
>> >
>> > (1) "failed"
>>
>> Yes, I was illustrating general principle. Above the approach
>> breaks down because FriCAS can not compute indefinite integral.
>> However, in cases when FriCAS can compute indefinite integral
>> you may have trouble due to singularities and choice of
>> brnaches. Splitting is a fairly general method to limit
>> troubles caused by singularities.
>>
>> > Maybe there is a function in FriCAS for some
>> > numerical integral algorithm? Have to check the FriCAS
>> > manual, maybe I find something.
>>
>> There is 'romberg' in NumericalQuadrature package.
>>
>> --
>> 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/5ae78271-f75f-45b0-99dc-0ec802fc572an%40googlegroups.com.

-- 
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/CAAWYfq2wpph%3Dtk9_1%2BYmJ7kT%2BpNtoKVDQ6UbaSctirqXECnsuA%40mail.gmail.com.

Re: [fricas-devel] FriCAS WWW

[Dima Pasechnik]

On Mon, 25 Sept 2023, 00:57 Waldek Hebisch,  wrote:

> On Sat, Sep 23, 2023 at 02:23:04PM +0200, Ralf Hemmecke wrote:
> > Since I currently put up the stuff at fricas.github.io, it actually
> needn't
> > be me.
> >
> > On 23.09.23 09:47, Qian Yun wrote:
> > > Most importantly, documentation should be put there.
> >
> > Definitely, my suggestion would be that we simply serve the pages from
> >
> >   https://fricas.github.io
> >
> > from https://fricas.org. And that would be completely easy to do.
>
> That would be easy, but I am affraid rather unsatisfactory.  I mean,
> API pages and PDF of FriCAS book are good things.  But there are
> only handful of other pages at fricas.github.io, I hope that we can
> create more.  Part of my question is to find out what is desirable
> and possibly if there are persons willing to add something
>
> > The pages at fricas.github.io are generated from our official fricas git
> > repository. Since sphinx-doc is involved the result is basically pure
> html,
>
> Well, html and Javascript.  IIUC search does not work without
> Javascript.
>
> > no fancy content management system needed.
> > OK, the generation of the book requires latex, and imagemagick and a few
> > other things, but that's easy to setup. Otherwise only python3 and
> sphinxdoc
> > must be installed.
>
> sphinxdoc and python3 are somewhat problematic dependencies.  Namely,
> much of Python world is unstable, that is changes in incompatible
> ways in rather short timeframe.  We already had problems that
> version of sphinxdoc that you use was incompatible with my
> system and version I had did not work with your sources.
>

you can always pin down versions of python3 and its packages such as sphinx
etc, by no means you must be on the latest versions



> Also, batch regeneration may be OK for slowly changing things
> or things tied to specific release.  But I defintely do not want
> to delay updates to FriCAS website waiting for release.
> When page is really pure html I can update it using text editor
> and immediately see results, not so with batch update.
>
> To put it differently, batch update is fine for "official"
> documentaion.  But it would be useful to have less
> "official", more informal documentation.
>
> In ideal world we would first think about logical organization
> of material that we want to present, and then think about
> technology needed to do this.  But I am affraid part of
> problem is that there are different technologies and
> they do not cooperate very nicely.  And people get attached
> to specific technology they use, so effort gets fragmented.
>
> > First we must decide whether we want the website fricas.org to be in
> sync
> > with the latest release or whether it should be in sync with the git
> > repository. Other ideas?
>
> Official documentation should be with sync with latest release.
> But other parts not, we should update them independently.
>
> --
>   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/ZRDM9hC4mVYjICgk%40fricas.org
> .
>

-- 
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/CAAWYfq14-D%2BPKYSXje%3DsFO3Aq1wqgxmQWoQhea9cjb_W-2MnyQ%40mail.gmail.com.

Re: [fricas-devel] Output of fricas startup script: version

[Dima Pasechnik]

On Mon, 4 Sept 2023, 09:29 Ralf Hemmecke,  wrote:

> > So, what is the variable in configure.ac to use
> > to get the version?
>
> For FriCAS itself, it is set through AC_INIT.
>
> https://github.com/fricas/fricas/blob/master/configure.ac#L2
>
> AC_INIT([FriCAS], [2023-06-17],
>  [fricas-devel@googlegroups.com],
>  [fricas],
>  [https://fricas.github.io])
>
> https://github.com/fricas/fricas/blob/r1.3.9/configure.ac#L2
>
> AC_INIT([FriCAS], [1.3.9],
>  [fricas-devel@googlegroups.com],
>  [fricas],
>  [https://fricas.github.io])
>
> The Lisp, version is another thing. That is computed at configure time
> and naturally depends on the options an what is available on the system.
>
> It is put at configure time into
>
>$fricas_lisp_flavor
>$fricas_lisp_version
>

I am asking as, unlike any other autoconfed project, FriCAS does not seem
to have a dedicated version variable.

Should one use PACKAGE_VERSION (this is what the documentation of AC_INIT
says - it writes there the value of the 2nd parameter) ?

Something else?


> In the Makefile it is available in variables with all capital letters.
>
> https://github.com/fricas/fricas/blob/master/config/var-def.mk
>
> Ralf
>
> --
> 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/ac0f2bd0-181b-60c2-566b-5f43914a0132%40hemmecke.org
> .
>

-- 
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/CAAWYfq2OCwm9X3qnBTxnxpfA%2Bvy38hNA-0vfvjfsFp7FoNAg4g%40mail.gmail.com.

Re: [fricas-devel] Output of fricas startup script: version

[Dima Pasechnik]

On Sat, 2 Sept 2023, 15:11 Waldek Hebisch, 
wrote:

> Dnia Sat, Sep 02, 2023 at 12:39:40AM +0300, Dima Pasechnik napisał(a):
> > On Fri, Sep 1, 2023 at 11:51=E2=80=AFPM Ralf Hemmecke 
> w=
> > rote:
> >
> > > > I'd propose to add the version support via pkg-config. If this is
> OK, I=
> > 'd
> > > > provide a PR for this.
> > > >
> > > > pkg-config would output the version in an easily parceable format,
> so t=
> > hat
> > > > one would not need to call sed to santitize the output of
> > > >
> > > > fricas --version
> > >
> > > I cannot say whether the pkg-config stuff will make it into frica, but
> I
> > > would love to see how it works. Would it cost you too much effort to
> > > create such a PR?
> >
> > it's not clear to me what the FriCAS version is meant to be. Is it
> > PACKAGE_VERSION=3D'2023-06-17' (in the current git master)
>
> In git repo this is date of last modification of configure.ac.
> Releases get three part version number with parts separated
> by dots.  So it is easy to distinguish releases from git
> snapshots, but meaning is different.  OTOH it _not_ expected
> that anybody will depend on version numbers from git...
>

So, what is the variable in configure.ac to use
to get the version?

As you check in ./configure (is it always unmodified output of autoconf?)
in the repo, it's impossible to be sure.


> > >
> > > How is the underlying LISP recognized by pkg-config.
> >
> > it's all very easy - one creates a template file fricas.pc.in with the
> > values filled in by ./configure, which writes fricas.pc
> > The latter is then installed by "make install" (does FriCAS have
> > install target in the main
> > Makefile?) into $prefix/lib/pkgconfig/
>
> There is 'install' target.
>
> > Then pkg-config reads fricas.pc when called, and prints the values it
> > is asked for. E.g. using GMP as
> > an example:
> >
> > $ pkg-config --modversion gmp # GMP version
> > 6.2.1
> > $ pkg-config --libs gmp # GMP libraries/flags fotr the linker
> > -lgmp
> >
> > etc.
> >
> > it allows custom fields to be added to fricas.pc, so it's easy to
> > fill/queue these, too, e.g. for the LIsp
> > name and Lisp version in the case of FriCAS.
> >
> > $ pkg-config --print-variables gmp # show all the variable defined for
> GMP
> > exec_prefix
> > includedir
> > libdir
> > pcfiledir
> > prefix
> > $ pkg-config --variable=3Dlibdir gmp # print the value of libdir variable
> > /usr/lib/x86_64-linux-gnu
> >
> > etc.
>
> Looks OK.  But AFAICS 'pkg-config' support is really additional to
> '--version'.  So change to '--version' should go on.
>
> --
>   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/ZPMmeWm9m0I13zOl%40mail.math.uni.wroc.pl
> .
>

-- 
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/CAAWYfq2GAcCkfPsfT%3DS6eX9NNoxUkHhtjX405hnWe3GyD9TEEQ%40mail.gmail.com.

Re: [fricas-devel] Output of fricas startup script: version

[Dima Pasechnik]

On Mon, 4 Sept 2023, 09:12 Grégory Vanuxem,  wrote:

> Hello Dima,
>
> I agree with you, Dima, about the usefulness of pkg-config and I am
> not surprised the SAGE Team uses it; they incorporate tons of external
> libraries.
>
> 
> In fact I discovered this utility some time ago, at the beginning of
> Gnome 2 development. I thought this utility was developed by this team
> since from my point of view at that time this is the team who really
> popularised this utility. I used it because I needed a quick image
> visualisator, 'eog' was becoming too library dependent, too large and
> too long to start to just see a pic. I have been doing photography for
> many years and to visualise pics I do not need a lot of functionality.
> The Evas library from DR16 (Enlightenment window manager)  started to
> use this utility and was useful to me to have linker arguments,
> cflags, say -DSOMETHING=1, and eventually the include path.
> 
>
> But I see this application as an utility to know
> *settings/configuration* about a library, and now some applications,
> more than to know the version or (quick) help of an application. For
> example on my computer I have in /usr/share/pkg-config/ 'fontutil.pc'
> which contains:
>
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${prefix}/lib/x86_64-linux-gnu
> datarootdir=${prefix}/share
> datadir=${datarootdir}
> fontrootdir=${datadir}/fonts/X11
> mapdir=${prefix}/share/fonts/X11/util
>
> Name: FontUtil
> Description: Font utilities dirs
> Version: 1.3.1
>
> I agree that the Name, Description and Version information could be
> useful, particularly for my needs, but its primary purpose is to
> display informations above in this file for me. To add to this, I do
> not even have the pkg-config or pkgconf package installed. I do not
> need them as of now. I totally agree with the package description:
> ===
> Description: manage compile and link flags for libraries (transitional
> package)
>  pkgconf is an implementation of the pkg-config system, which helps to
> configure
>  compiler and linker flags for development frameworks.
>  .
>  pkgconf is a replacement for pkg-config, providing additional
> functionality
>  while also maintaining compatibility.
>  .
>  This package only provides a dependency link to the pkgconf package to
> help
>  with package upgrades. It can be safely removed.
> Description-md5: df0bd7e16369ac7330df23f92a214b3a
> Multi-Arch: same
> Homepage: http://pkgconf.org/
> Tag: admin::configuring, devel::buildtools, interface::commandline,
>  role::program, scope::utility
> Section: devel
> 
>

applications/systems which have ability to call external command line
executables have interfaces to pkg-config.
E.g. there is a Python pkgconfig module.

There are also autoconf macros to call pkg-config. And cmake, too.

So it's, by far, not limited to libraries.




> So, yes, why not use this utility to display some information about
> FriCAS, even if I do not see a lot of information to write in it, I
> would prefer to keep version information available from the 'fricas'
> executable as you suggest I guess (but add a pkg-config file).
> Personally I would also prefer to add to the fricas script the ability
> to execute code and return to the shell. As of now 'fricas -eval'
> executes code at startup but does not leave the fricas REPL. What
> could also be useful is something like:
> └─$ perl -e 'print 2+2'
> 4
> ┌──(greg㉿ellipse)-[~]
> └─$ python3 -c 'print(2+2)'
> 4
>
> ┌──(greg㉿ellipse)-[~]
> └─$ julia -e 'print(2+2)'
> 4
> etc. (read a file also, why not)
>
> That way I could use, say, 'fricas -c ')lisp
> (lisp-implementation-type)' or other things. This information is
> already in the fricas startup script though, it is just an example.
>
> By the way I attached the primary patch, as an illustration, that just
> moves the code related to HyperDoc and Graphics availability.
>
> __
> Greg
>
>
> Le ven. 1 sept. 2023 à 23:39, Dima Pasechnik  a écrit :
> >
> > On Fri, Sep 1, 2023 at 11:51 PM Ralf Hemmecke  wrote:
> >
> > > > I'd propose to add the version support via pkg-config. If this is
> OK, I'd
> > > > provide a PR for this.
> > > >
> > > > pkg-config would output the version in an easily parceable format,
> so that
> > > > one would not need to call sed to santitize the output of
> > > >
> > > > fricas --version
> > >
> > > I cannot say whether the pkg-config stuff will make it into frica, but
> I
> > > would love to see how it wor

Re: [fricas-devel] Output of fricas startup script: version

[Dima Pasechnik]

On Fri, Sep 1, 2023 at 11:51 PM Ralf Hemmecke  wrote:

> > I'd propose to add the version support via pkg-config. If this is OK, I'd
> > provide a PR for this.
> >
> > pkg-config would output the version in an easily parceable format, so that
> > one would not need to call sed to santitize the output of
> >
> > fricas --version
>
> I cannot say whether the pkg-config stuff will make it into frica, but I
> would love to see how it works. Would it cost you too much effort to
> create such a PR?

it's not clear to me what the FriCAS version is meant to be. Is it
PACKAGE_VERSION='2023-06-17' (in the current git master)

>
> How is the underlying LISP recognized by pkg-config.

it's all very easy - one creates a template file fricas.pc.in with the
values filled in by ./configure, which writes fricas.pc
The latter is then installed by "make install" (does FriCAS have
install target in the main
Makefile?) into $prefix/lib/pkgconfig/

Then pkg-config reads fricas.pc when called, and prints the values it
is asked for. E.g. using GMP as
an example:

$ pkg-config --modversion gmp # GMP version
6.2.1
$ pkg-config --libs gmp # GMP libraries/flags fotr the linker
-lgmp

etc.

it allows custom fields to be added to fricas.pc, so it's easy to
fill/queue these, too, e.g. for the LIsp
name and Lisp version in the case of FriCAS.

$ pkg-config --print-variables gmp # show all the variable defined for GMP
exec_prefix
includedir
libdir
pcfiledir
prefix
$ pkg-config --variable=libdir gmp # print the value of libdir variable
/usr/lib/x86_64-linux-gnu

etc.



HTH
Dima






>
> Otherwise, I do as Waldek proposed and single out the --version option
> to simply output the fricas and lisp version and exit when it appears on
> the command line of the fricas script.
>
> Ralf
>
> --
> 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/931beec1-a2c4-3be2-7198-87d9fc86136c%40hemmecke.org.

-- 
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/CAAWYfq07TtLc4%3DPB0orTjZT3eRiU0e_Fvqw8ziWyN9PpfVP0rg%40mail.gmail.com.

Re: [fricas-devel] Output of fricas startup script: version

[Dima Pasechnik]

What's important is to provide a painless for the user way to get the
version, and possibly more (e.g. the underlying Lisp).

That's because what upstreams, such as SageMath, often need to know.

I'd propose to add the version support via pkg-config. If this is OK, I'd
provide a PR for this.

pkg-config would output the version in an easily parceable format, so that
one would not need to call sed to santitize the output of

fricas --version



Dima


On Fri, 1 Sept 2023, 22:14 Grégory Vanuxem,  wrote:

> Yes I agree. Not a necessary addition.
> And to add, not a Git specialist. Too a lot of errors with me. But that's
> the way.
>
> __
> Greg
>
> Le jeu. 31 août 2023, 13:09, Waldek Hebisch 
> a écrit :
>
>> Dnia Tue, Aug 22, 2023 at 08:03:50AM +0200, Grégory Vanuxem napisał(a):
>> > Hello, Ralf, Waldek, *,
>> >
>> > Thanks Ralf for supporting this proposal.
>> >
>> > I'm used to run different FriCAS versions at the same time and since I
>> > plan to support this in a FriCAS personal plugin for VSCode (not
>> > published yet), I need version informations to populate my
>> > 'FriCASExecutable' computational "structure". For now 'fricas
>> > --version' is inconsistent to me. But this is usual apparently even
>> > with Common Lisp implementations. For example, 'gcl --version' gives:
>> >
>> > $gcl --version
>> > GCL 2.6.14 ...
>> >
>> > whereas in GCL
>> > >(lisp-implementation-type)
>> > "GNU Common Lisp (GCL)"
>> >
>> > Clozure CL is more consistent from my point of view:
>> > =E2=94=94=E2=94=80$
>> /home/greg/.roswell/impls/x86-64/linux/ccl-bin/1.12.2/l=
>> > x86cl64 --version
>> > Clozure Common Lisp Version 1.12.2 (v1.12.2) LinuxX8664
>> >
>> > and in it:
>> > CCL is free software.  It is distributed under the terms of the Apache
>> > Licence, Version 2.0.
>> > ? (lisp-implementation-type)
>> > "Clozure Common Lisp"
>> > ?
>> >
>> > After, that is just a matter of opinion I guess.
>> > By the way, if there is some interest I filed a pull request,
>> > https://github.com/fricas/fricas/pull/134
>> >
>> > The original code is in
>> https://github.com/gvanuxem/fricas/tree/fricas-vers=
>> > ion
>> > (the fricas-version branch) for an eventual 'diff'. I will keep one
>> > since I will delete this branch in the near future.
>>
>> Moving tests so that '--version' is handled before possible error
>> messages is fine.  However, other changes look like regression to
>> me: current tests in 'config.lisp' deliberately match feature
>> tests in Lisp code.  Since "features" are used by programs they
>> should be more stable than other things.  Basing test on output
>> that is normally _not_ handled by programs is less robust.
>> And there is added uglyness due to embedded spaces in messages.
>>
>> --
>>   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/ZPB02N9%2BKileYdrU%40mail.math.uni.wroc.pl
>> .
>>
> --
> 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/CAHnU2daHSrLZY9Wz61r_XuM7%3DmJzRB_k8uo-u4HK5UUPvJvYOw%40mail.gmail.com
> 
> .
>

-- 
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/CAAWYfq2L8eQ_WG-gsDopSU%3DHY_kV-k%3DPMTZshoiibcXUq%2BuY3A%40mail.gmail.com.

Re: [fricas-devel] 'make dist'

[Dima Pasechnik]

On Tue, Jul 11, 2023 at 10:31 PM Waldek Hebisch
 wrote:
>
> I consider removing 'dist' target from the Makefile.  For creating
> release I use 'src/scripts/mkdist.sh' and it seems that other
> folks do not use 'dist' target.  'dist' target contains comparable
> number of lines as 'src/scripts/mkdist.sh' and adds extra work
> to maintain Makefiles.

'dist' target normally is provided by packages which use automake, and
in this case it's no extra work, at all.
Without automake, you can just set up the target to invoke
'src/scripts/mkdist.sh'

Just in case,
Dima

>
>
> --
>   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/ZK3KNjfJpjQ%2B19xr%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq0hpjq_ujf10kVd1e3fyDS5pZqXEUXbdZ_Um1gjVwVUkg%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.9 is released

[Dima Pasechnik]

please make sure the tarball in github releases  is consistent in this
sense, too.

On Mon, Jul 10, 2023 at 4:00 PM Waldek Hebisch
 wrote:
>
> On Mon, Jul 10, 2023 at 03:24:24PM +0200, Ralf Hemmecke wrote:
> > Hi Waldek,
> >
> > > I am not sure what to do, any way there will be some confusion.  ATM
> > > I have put on Sourceforge also identical tarball with name using dash.
> > > ATM there is also file with dot, it is not clear to me if having
> > > it helps or causes trouble.
> >
> > I think, it is early enough after the release.
> > I would simply *rename* the file
> > fricas-1.3.9.full.tar.bz2 to
> > fricas-1.3.8-full.tar.bz2 and only put an identical copy into the release
> > area on sourceforge and github, if someone insists that he would otherwise
> > be in trouble.
> >
> > I think, not pleasing one or two people instead of changing the naming
> > scheme is worth it to correct an obvious mistake.
> >
> > Putting identical copies with dash/dot should be avoided IMHO.
>
> Well, there is no way to please everyone.  After a little thought
> I have removed versions with dot in name.
>
> --
>   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/ZKwdEgD8nCVJ4R%2BC%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq2ZLVfQu3p4XoDt%2BFV21RTz0_RwYqGroWo5b2H%3D%2BStxqg%40mail.gmail.com.

Re: [fricas-devel] FriCAS status

[Dima Pasechnik]

On Sat, Jul 1, 2023 at 7:55 PM Waldek Hebisch
 wrote:
>
> On Fri, Jun 30, 2023 at 03:03:27PM +0200, Ralf Hemmecke wrote:
> > So... download.rst and install.rst and order minor docfixes have to be done.
>
> Are you working on this?  Concerning download.rst, my idea of download
> page was to put there links to appropriate binaries.  This is somewhat
> fragile info, fully known only after release, so poor fit to be part
> of release.  I think minimal change would add link to Sourceforge
> download page, that is
>
> http://fricas.sf.net/download.html
>
> (which I intend to keep up to date), delete 1.3.6
> "up to version  1.3.6" phrase about Sourceforge (or maybe delete
> the whole 'files' link to Surceforge, as this is subsumed by
> 'http://fricas.sf.net/download.html').  Also, there should be
> visible link to release at Github, either
>
> https://github.com/fricas/fricas/releases
>
> or
>
> https://github.com/fricas/fricas/releases/tag/1.3.9
>
> (assuming that Github will not change its naming scheme).

Tag names for GitHub releases are fully within the user control.
They are actually git tags.


>
>
> Concerning decumentation build in install.rst
> I would write something like this:
>
> Building documentation
> ^^
>
> After a build of FriCAS, (suppose your build directory is under
> ``$BUILD``), you can build extra documentation.
>
> To build extra documention you need working 'convert' program
> from ImageMagick.  Note that several Linux distribution currently
> disable ability to create .ps files via 'convert'.  If your
> distribution is doing this build of extra documention  will fail.
>
> Currently building .html pages only works with Sphinx 4.4.0.
> Use this version or only build FriCAS book via
> ::
>cd $BUILD/src/doc
>make book.pdf
>
> The |home page| can be built via
> ::
>
> ...
>
> --
>   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/ZKB2dRGH2SEKRYya%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq1%3DbeMhzn6AYZceUCPjAH6tqNinun5Hnm9ioLP97tQ4Uw%40mail.gmail.com.

Re: [fricas-devel] fricas citation page

[Dima Pasechnik]

On Fri, Jun 30, 2023 at 9:36 AM Ralf Hemmecke  wrote:
>
> On 30.06.23 10:27, Dima Pasechnik wrote:
> > It needs a version. Chances are that the same computation on different
> > versions gives different (hopefully equivalent) results.
>
> Oh, thank you. At least the year should be updated. Any yes, maybe it
> should read:
>
>  @Misc{FriCAS,
>key =  {FriCAS},
>author =   {{FriCAS team}},
>year = {2023},
>title ={{FriCAS} 1.3.9---an advanced computer algebra
> system},
>note = {Available at \url{http://fricas.github.io}}
>  }
>
> > By the way, with releases done on GitHub it is easy to get an official DOI
> > for each release.
>
> Thanks, I must learn how to actually get it.
you need to register the repository on https://zenodo.org/
(this is for any digital assets, not specific to GutHub or anything)

And then on GitHub in the top directory of the repository you put a file
with metadata named CITATION.cff,
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files
e.g. that's what we have for SageMath:
https://github.com/sagemath/sage/blob/develop/CITATION.cff

HTH
Dima

>
> Ralf
>
> --
> 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/377f4169-cc7e-b51d-28c9-48b64626a945%40hemmecke.org.

-- 
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/CAAWYfq3khR%3DSZgQ2fO28Pi5C4Xzzske%2B%3D55wfi4z8f5m3Z3xfQ%40mail.gmail.com.

Re: [fricas-devel] fricas citation page

[Dima Pasechnik]

It needs a version. Chances are that the same computation on different
versions gives different
(hopefully equivalent) results.

By the way, with releases done on GitHub it is easy to get an official DOI
for each release.


On Fri, 30 Jun 2023, 09:15 Ralf Hemmecke,  wrote:

> Does anyone have more that can be put here:
>
> http://fricas.github.io/citation.html
>
> ?
>
> Thank you
> Ralf
>
> --
> 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/d25fdc93-cc4a-1ede-7ea0-526c17eaaa30%40hemmecke.org
> .
>

-- 
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/CAAWYfq1JwyXf46E%3DFfSZOF8oCaNPbOViwhjnDbi8JuRw_i-UiA%40mail.gmail.com.

Re: [fricas-devel] FriCAS status

[Dima Pasechnik]

On Mon, Jun 26, 2023 at 7:20 AM 'Nasser M. Abbasi' via FriCAS -
computer algebra system  wrote:
>
> I setup new VBox with new Linux, and installed sagemath.
>
> There is an option with sage to ask it to install Fricas if you want 
> afterwords, and I used that option, it is
>
> sage -i fricas

it's better to run, before the build,

./configure --enable-fricas=yes


Then it will be built automatically during the run of make
After https://github.com/sagemath/sage/issues/35837 is done, to use
external fricas,
there will be --with-system-fricas= option to ./configure, as well.


>
> And then it will download and install it all automatically (but local to 
> sagemath, not on the system).
>
> I normally do not do that, but since I was lazy and instead of me going and 
> downloading the tar file
> and etc..., I just let sagemath install it.
>
> There is no difference in connection mechanism if one installs Fricas outside 
> sage or let it
> install using the above command.
>
> I just thought that when I installed Fricas pre 1.3.9 outside and set the 
> path to it, that sage will now use the external one.
>
> --Nasser
>
>
> On Monday, June 26, 2023 at 12:36:18 AM UTC-5 ra...@hemmecke.org wrote:
>>
>> On 26.06.23 01:11, 'Nasser M. Abbasi' via FriCAS - computer algebra
>> system wrote:
>> > Any way, I just rebuild sagemath again now from scratch and made
>> > sure now to not make it build Fricas 1.3.8 as I did before,
>> > and re-run the tests.
>>
>> I run a standard sage (with no particular options used when I built it).
>> It automatically picks my installed sbcl-fricas.
>>
>> I have no idea what additional features come in the sage-fricas
>> connection when you let sage build fricas on ecl.
>>
>> Ralf
>
> --
> 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/d379863a-8e8a-48d8-8f16-286a2363613an%40googlegroups.com.

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

Fwd: [fricas-devel] FriCAS status and jFriCAS

[Dima Pasechnik]

I've opened an issue to create a configure option for system-wide
fricas to be usable with Sage.
https://github.com/sagemath/sage/issues/35837

Please post there details on what you do to use Sage with system-wide
fricas now - this might help.

-- Forwarded message -
From: 'Nasser M. Abbasi' via FriCAS - computer algebra system

Date: Mon, Jun 26, 2023 at 12:11 AM
Subject: Re: [fricas-devel] FriCAS status and jFriCAS
To: FriCAS - computer algebra system 


opps, very sorry. I had to re-run this Fricas small test
again on sagemath 10.

Please ignore the above post. Here is the correct one:

It turned out sagemath had its own internal fricas buildin,
and I forgot about that and thought because I changed the
PATH, sagemath will now use the new Fricas.

But Sagemath was still using 1.3.8 internally and did not
use the one I had setup as it ignores the PATH/LD_LIBRARY_PATH
used in my .bashrc (it has its own internal /local tree it looks at
first).

No wonder I was getting same result as before. I was suspicious
at first that same exact result was generated, as I expected Fricas
score to improve, even if by little but then I thought it was
may be due to no code changes in Fricas for these type of
integrals. My mistake, I should have looked more into this to
verify. it was late and I was sleepy.

I spend all this morning looking into this to make sure and found
the problem.

(It is always a struggle for me to tell sagemath after I install it
to use the correct versions of external CAS programs instead of
ones it builds or it wants to use). Same with Maxima.

For giac, sagemath does have this  configuration option
to tell it use system installed giac,

   ./configure --with-system-giac=force

But no one for fricas and no one for Maxima.

Maxima is even worst than Fricas, as sagemath always builds Maxima
regadless and then I have to go delete the one it build and add
symlinks to point to the system Maxima as that is more recent.

Any way, I just rebuild sagemath again now from scratch and made
sure now to not make it build Fricas 1.3.8 as I did before,
and re-run the tests.

Here is the result.

First made sure sage is using correct Fricas:

>sage
┌─
│ SageMath version 10.0, Release Date: 2023-05-20
│ Using Python 3.10.9. Type "help()" for help.
└─
sage: print(fricas.eval(")lisp |$build_version|"))

Value = "FriCAS 2023-06-17"

sage: integrate(sin(x),x, algorithm="fricas")
-cos(x)
-

>which fricas
/usr/local/bin/fricas
>fricas --version
FriCAS 2023-06-17
based on sbcl 1.4.16


The results:


Using sagemath 10.0 on Linux on first 12 files
(1,892 integrals) from CAS integration tests database
(these integrals are obtained from Rubi's test suite
maintained by Albert Rich) and compared the result
with ones obtained using 1.3.8 using ecl 21.2.1
on same Linux virtual box.  Both using same sagemath 10.0.

The good news is that there were no problems found and no regression.
Also Fricas pre 1.3.9 performed better than 1.3.8 in this small
test (As one would expect).

FriCAS 2023-06-17:
% pass: 95.455 (better than before)

vs.

FriCAS 1.3.8 :
% pass: 95.243

For specific stats on one file, here are stats for file #10
(Timofeev integration Problems) which contains 705 problems.

FriCAS 2023-06-17:
passed:   93.90%  (43 failed) (better than before)
A grade:  67.66% (same as before)
average time used: 0.48 sec (better than before)
average leaf size: 234.57 (better than before)

FriCAS 1.3.8:
passed:   93.62%  (45 failed)
A grade:  67.66%
average time used: 1.55 sec
average leaf size: 267.73

The following is link to the PDF file report for just file #10 above
if you like to see it. This is for the FriCAS 2023-06-17 version.

report.pdf


Full tests will run when official 1.3.9 is released which will
take few weeks to complete.

--Nasser

On Sunday, June 25, 2023 at 12:58:47 PM UTC-5 Waldek Hebisch wrote:
>
> On Sun, Jun 25, 2023 at 04:13:46PM +0200, Ralf Hemmecke wrote:
> > > I am trying to use sbcl-1.4.6. ATM it seems that it works.
> > > However, since the process uses different, newer environment
> > > (Gentoo) there are possible glitches. I have now put test
> > > tarball at
> > >
> > > http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2
> >
> > > binary works. In particular hunchentoot is included, so it
> > > should work with jfricas.
> >
> > I installed this binary. In fact, I roughly followed the steps at
> >
> > https://hemmecke.github.io/qeta/fricasinstall.html#recommended-installation
> >
> > I had, of course, no problem with libssl. So that section from the above
> > site can safely be ignored.
> >
> > The jfricas installation in a virtual environment ran smoothly and obviously
> > seems to work nicely.
> >
> > I have not installed JupyText, but these things do not depend on FriCAS or
> > hunchentoot, but are more connected to 

Re: [fricas-devel] FriCAS status

[Dima Pasechnik]

On Mon, Jun 19, 2023 at 3:05 PM Waldek Hebisch
 wrote:
>
> On Mon, Jun 19, 2023 at 10:29:44AM +0100, Dima Pasechnik wrote:
> > On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke  wrote:
> > >
> > > On 19.06.23 09:22, Grégory Vanuxem wrote:
> > > > I wonder why you're using such an old LISP?
> > >
> > > Waldek wants to make sure that jfricas also works with the sbcl that he
> > > puts into the binary fricas release. In fricas-1.3.8 this was
> > > sbcl-1.1.1. So I presume that I should test 1.1.1.
> >
> > it's wishful thinking that SBCL 1.1.1.1, released in 2012, will
> > correctly work on all modern OSs.
> > Waste of time, if you ask me...
>
> Well, download binary 1.3.8 (based on sbcl 1.1.1) and try it.  It
> works on all systems available to me and up to now I had no report
> of failure due to incompatibility with the system.

A system not certified by its makers to work on an OS/hardware,
because it's way too old,
should be avoided, full stop.

As well, I imagine that code compiled, for a modern CPU, with an up to
date sbcl, will be considerably
faster than the one built with sbcl 1.1.1, as the latter has no idea
about modern CPUs.


>  Of course,
> at some time we will have to move to newer version.  But using
> newest version is essentially warranted to fail on some systems,
> so we need to choose correctly.
>
> More generaly, if you declare everything more than 3.5 years as
> obsolete and decide to break it, that is your right.  But not all
> folks adapt such point of view and it is possible to create
> binaries compatible with wide range of system versions.

Why do you want to encourage these folks to stay on obsolete OSs, which
have reached their EOL, are insecure and buggy?
You want them to get hacked? :-)

> Of
> course, I need to avoid unstable dependencies (or at least have
> some way to tame them), otherwise I would be hostage to other
> folks breaking my binaries.
>
> --
>   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/ZJBguyweZz/7VXcd%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq3BdUEiC4VJNykGNvwDZ2KzMo5V5RP%2BY%2BwOk7Zym79sEQ%40mail.gmail.com.

Re: [fricas-devel] FriCAS status

[Dima Pasechnik]

On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke  wrote:
>
> On 19.06.23 09:22, Grégory Vanuxem wrote:
> > I wonder why you're using such an old LISP?
>
> Waldek wants to make sure that jfricas also works with the sbcl that he
> puts into the binary fricas release. In fricas-1.3.8 this was
> sbcl-1.1.1. So I presume that I should test 1.1.1.

it's wishful thinking that SBCL 1.1.1.1, released in 2012, will
correctly work on all modern OSs.
Waste of time, if you ask me...

>
> > It seems you have a x64 system, why are you not trying roswell for
> > your LISP implementation? https://roswell.github.io/
>
> Also a good suggestion.
>
> Look like quicklisp functionality with which I described the jfricas
> installation here:
>
> https://hemmecke.github.io/qeta/fricasinstall.html#optional-jfricas-installation
>
> But Waldek wants as a prerequisite an sbcl image that already contains
> hunchentoot. I somehow support that since hunchentoot is not really
> needed for the fricas functionality, only to make the interface to the
> jupyter notebook (jfricas) work. Then ./configure --with-lisp=hsbcl
> would compile the right FRICASsys image.
>
> But we can have several scenarios for building from the git repo.
>
> A) user provides hsbcl and uses --with-lisp=hsbcl.
> B) like on the above website a few additions to FriCAS makefiles and
> a little patch to vmlisp.lisp by using quicklisp to bring
> hunchentoot into FRICASsys while compiling it (uses pure sbcl)
> C) like (B) replacing quicklisp by roswel.
>
> It seems we will be going the (A) direction.
>
> > Using configure parameter --with-lisp='ros run' all will
> > be done automagically.
>
> Are you sure that this would include hunchentoot into the FRICASsys
> image? Kurt and me struggled quite a bit, because FRICASsys would not
> know SBCL_HOME and thus not find any otherwise installed hunchentoot if
> not explicitly told. That is why hunchentoot should be inside the
> FRICASys image.
>
> Ralf
>
> --
> 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/20e52895-082e-555a-24f4-13f1d3dff3f7%40hemmecke.org.

-- 
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/CAAWYfq0Wjt9idietzY%3D8wyH5tCPYvO67KWYpbWQKLesPyO9jdg%40mail.gmail.com.

Re: [fricas-devel] FriCAS status

[Dima Pasechnik]

On Sun, 18 Jun 2023, 17:51 Ralf Hemmecke,  wrote:

> On 16.06.23 02:14, Waldek Hebisch wrote:
> > Well, I wrote "binary".  The question is if sbcl version I use for
> > creation of binaries has all features needed by jfricas.  It should,
> > but testing is better than bling faith.
>
> OK, but building SBCL 1.1.1 from the git repo does not work on my
> computer. Certainly someprerequisite missing. I am building with the
> default SBCL 2.1.11.debian on Ubuntu 22.04.2 LTS.
>
> Is there an easier way to get the sbcl version you wil be using?
>
>
> > As I wrote my current thinking is that hunchentoot is dependence
> > like other dependencies: it is responsibility of person doing build
> > to make sure that it is available.  For convenience we can add
> > hsbcl tarball to the release area.  And of course instruction
> > in INSTALL.
>
> If we go that way, then it seems as simple as asking the user to provide
> an sbcl image with hunchentoot included such that
>
> (require :asdf)(require :hunchentoot)
>
> can be called and we do not have to change anything in FriCAS. Oh wait,
> there was this thing with stdout.
>
>
> https://github.com/fricas/fricas/commit/7c1d3e8ea7ced544ecb57156415e7b8af64e098b#diff-953a91d70c9e61cba8f0e8f2f97d7141601a66d5d12985e181c9abbb4b8da7d2
>
> (see into the vmlisp.lisp part of the attached patch).
>
> When I jfricas starts webspad.lisp, then *OBEY-STDOUT* will be set to T
> and output goes the way it should go for jfricas in order to capture
> output that would normally go to stdout and otherwise be invisible in
> the notebook.
>
> >> In fact, may I ask you a favour? If you do changes that affects quite a
> big
> >> piece of code and could potentially break things, like the "$ --> %"
> change,
> >> please open a pull request at github so that others have the chance to
> check
> >> things they care about, before the patches become officially committed
> to
> >> the repo.
> >
> > Well, long time ago I tried to provide patches so that people can
> > test various changes.  Feedback I received was almost empty,
> > so I rarely do this.
>
> Well, at least for me it feels troublesome to extract the patch from the
> mail, call patch and record it in my local git tree so that I know where
> I am. It would be much easier, if I could simply "git fetch hebisch" and
> look at your branches. Also for you it would be a simple "git push" to
> your github repository.
>

It need not be GitHub. Any way to fetch git branches (from a git server) or
patches which can be applied with "git apply" is infinity less error-prone
that mailing patches without any metadata which specifies a  place in the
git tree.

>
> But true, for some things I do not have to say much, but the
> FriCAS-Aldor interface is something I care about.
>
> Ralf
>
> =
> ; wrote
> /home/hemmecke/v/git/sbcl/obj/from-host/src/code/early-type.fasl-tmp
> ; compilation finished in 0:00:00.236
> Unhandled SIMPLE-ERROR in thread #  {1001834363}>:
>FAILURE-P was set when creating
> "obj/from-host/src/code/early-type.fasl".
>
> Backtrace for: #
> 0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK # when creating ~S." {10040CEC63}> # :QUIT T)
> 1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* # "FAILURE-P was set when creating ~S." {10040CEC63}>)
> 2: (INVOKE-DEBUGGER # {10040CEC63}>)
> 3: (ERROR # {10040CEC63}>)
> 4: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS ERROR NIL "FAILURE-P was
> set when creating ~S." "obj/from-host/src/code/early-type.fasl")
> 5: (COMPILE-STEM "src/code/early-type" NIL :HOST-COMPILE)
> 6: (IN-HOST-COMPILATION-MODE # {10054D5F2B}>)
> 7: (HOST-CLOAD-STEM "src/code/early-type" NIL)
> 8: (LOAD-OR-CLOAD-XCOMPILER #)
> 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LOAD-OR-CLOAD-XCOMPILER (FUNCTION
> HOST-CLOAD-STEM)) #)
> 10: (EVAL (LOAD-OR-CLOAD-XCOMPILER (FUNCTION HOST-CLOAD-STEM)))
> 11: (SB-EXT:INTERACTIVE-EVAL (LOAD-OR-CLOAD-XCOMPILER (FUNCTION
> HOST-CLOAD-STEM)) :EVAL NIL)
> 12: (SB-IMPL::REPL-FUN NIL)
> 13: ((LAMBDA NIL :IN SB-IMPL::TOPLEVEL-REPL))
> 14: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX # SB-IMPL::TOPLEVEL-REPL) {10009BC53B}>)
> 15: (SB-IMPL::TOPLEVEL-REPL NIL)
> 16: (SB-IMPL::TOPLEVEL-INIT)
> 17: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
> 18: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
> 19: (SB-IMPL::START-LISP)
>
> unhandled condition in --disable-debugger mode, quitting
> deleted
> #P"/home/hemmecke/v/git/sbcl/obj/from-host/src/code/early-type.fasl-tmp"
> Command exited with non-zero status 1
> 4.02user 0.24system 0:06.83elapsed 62%CPU (0avgtext+0avgdata
> 118296maxresident)k
> 67240inputs+4336outputs (370major+69633minor)pagefaults 0swaps
>
>
> --
> 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 

Re: [fricas-devel] run external command and capture output without temporary files

[Dima Pasechnik]

On Sun, Apr 16, 2023 at 12:28 PM Ralf Hemmecke  wrote:
>
> On 16.04.23 12:18, Dima Pasechnik wrote:
> >> I generic interface is anyway never needed. I guess also Sage just picks
> >> out a couple of useful features from other systems
>
> > no, not really. E.g. with libgap (library interface to GAP) you can really
> > write anything you can do in GAP in Python syntax in Sage,
> > the interface is not requiring you to write boilerplate interface code.
>
> OK, maybe I do not know enough of how that works, but we clearly have to
> distinguish two types of interfaces.
> A) control an external program P by the host program and allow output
> from P to be shown in your system
> B) same as A) plus allow your system to use the computed values from P
> in your system.
>
> Maybe what you describe is interface type (B), but I guess, that still
> needs quite some effort to translate the data or at least write some
> routines to interpret the ASCII output of P.

No, there is, ideally, no ASCII involved! E.g. Sage and GAP use the same machine
precision integers (int), and the same long integers (GMP integers).
So they copy this data in memory (or even not copy, just modify in place).

The main issue here becomes memory management of such objects,
especially as GAP has its won garbade collector.
(Same with the Lisp interface).





 And what I meant is that in
> this part Sage covers only a part of FriCAS.
>
> Just calling P from my system and only showing its output in my system
> is not so hard. The problem is to use the data that is computed
> externally. I wonder why OpenMath is not yet generally accepted as an
> interface communication language.
>
> Ralf
>
> --
> 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/1f97d3e5-071f-d315-40dc-64667dd7e2f9%40hemmecke.de.

-- 
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/CAAWYfq2YY52BwoVrvu2sLBtNatpYLkCN6hoP70NpyZADFoZQqQ%40mail.gmail.com.

Re: [fricas-devel] run external command and capture output without temporary files

[Dima Pasechnik]

On Sat, 15 Apr 2023, 15:39 Ralf Hemmecke,  wrote:

> On 15.04.23 13:04, Dima Pasechnik wrote:
> > A proper interface to FriCAS in Sage ought to be like the one we have for
> > Maxima - via embedded libECL, where Maxima is loaded as an precompiled
> Lisp
> > code.
>
> Not my goal currently. Anyway, it is restricted to ECL


any Lisp with a library wrapper should be easily adapted here, I suppose.

 and even though
> the "temporary file" problem would be solve, one still needs a lot of
> machinery to translate the actual objects from one system into the other
> if one needs the actual value.
>
> I generic interface is anyway never needed. I guess also Sage just picks
> out a couple of useful features from other systems


no, not really. E.g. with libgap (library interface to GAP) you can really
write anything you can do in GAP in Python syntax in Sage,
the interface is not requiring you to write boilerplate interface code.

I don't know much about ECL  Lisp interface in Sage, but I gather you can
easily call Lisp functions and get the results back.
I don't know anything about how FriCAS translates its calls to Lisp and
back, so I can't say how easily it would be to achieve a similar feat for
FriCAS.

Dima

and then optimizes an
> interface to such functions. And maybe this means to use a different
> machinery to interface two different parts of the other system.
>
> Ralf
>
> --
> 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/5e577230-7cb6-d0fc-4a2a-9e45807a600f%40hemmecke.de
> .
>

-- 
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/CAAWYfq1ODYk6a_cBUemK8DUO08GwiAKkB_Xj73Kzj0oM7KQGyw%40mail.gmail.com.

Re: [fricas-devel] run external command and capture output without temporary files

[Dima Pasechnik]

A proper interface to FriCAS in Sage ought to be like the one we have for
Maxima - via embedded libECL, where Maxima is loaded as an precompiled Lisp
code.
There is no overhead and flakiness associated with files or pipes, all the
communication is in memory.

See
https://github.com/sagemath/sage/blob/develop/src/sage/interfaces/maxima_lib.py

Dima


On Sat, 15 Apr 2023, 10:37 Ralf Hemmecke,  wrote:

> On 13.04.23 16:18, Waldek Hebisch wrote:
> > Of course, all needed redirections and buffering could be hidden in
> > an utility function.  AFAICS need to run external programs and
> > capture output is rare enough that nobody bothered to write a
> > special function.
>
> I have written a simple stupid interface that can call any external
> program.
>
> I can call Sage via
>
> )compile runextcmd.spad
> RUN ==> run $ RunExternalCommand
> out := RUN("/bin/sh sage.sh", "[x^2 for x in range(40)]")
>
> or
>
> setExecutable("sage", "/bin/sh sage.sh")
> out := RUN("sage", "[x^2 for x in range(40)]")
>
> This will give the value:
>
>  (5)
>  ["[0,", " 1,", " 4,", " 9,", " 16,", " 25,", " 36,", " 49,", " 64,",
> " 81,",
>   " 100,", " 121,", " 144,", " 169,", " 196,", " 225,", " 256,", "
> 289,",
>   " 324,", " 361,", " 400,", " 441,", " 484,", " 529,", " 576,", "
> 625,",
>   " 676,", " 729,", " 784,", " 841,", " 900,", " 961,", " 1024,", "
> 1089,",
>   " 1156,", " 1225,", " 1296,", " 1369,", " 1444,", " 1521]"]
> Type: List(String)
>
> Of course, that needs to be brought back into proper FriCAS objects like
>
> str := concat out
>
>  (6)
> "[0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225,
> 256, 289,
>  324, 361, 400, 441, 484, 529, 576, 625, 676, 729, 784, 841, 900,
> 961, 1024,
> 1089, 1156, 1225, 1296, 1369, 1444, 1521]"
>
> (7) -> inf := parse(str)$InputForm
>
>  (7)
>  (construct  0  1  4  9  16  25  36  49  64  81  100  121  144  169
> 196
>   225  256  289  324  361  400  441  484  529  576  625  676  729 784
>   841
>   900  961  1024  1089  1156  1225  1296  1369  1444  1521)
>   Type: InputForm
>
>
> (8) -> interpret(inf)
>
>  (8)
>  [0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225,
> 256, 289,
>   324, 361, 400, 441, 484, 529, 576, 625, 676, 729, 784, 841, 900,
> 961, 1024,
>   1089, 1156, 1225, 1296, 1369, 1444, 1521]
>   Type: List(NonNegativeInteger)
>
>
> sage.sh is:
> ==
> #!/bin/sh
> base=$(basename $1 .tmp)
> cat $1 | sage -q | sed 's/^sage: //' > $base.out
> ==
>
> The first parameter that script gets is a filename of the form
> rxcX.tmp where the X is a random number (random(2^32)).
>
> Clearly, this enables me not only to call Sage, but also Maple,
> Mathematica, etc. The question is only whether I do the massaging of the
> output of the respective programs (sage, mathematica, maple) in the
> respective shell script or via string transformations in FriCAS. For
> Sage I have chosen the script, because string handling in FriCAS is
> rather limited without having an equivalent to regular expression
> handling like in sed/awl/perl.
>
> If I could eliminate the need of accessing the file system that would be
> great. I guess, it should be diable if I use specific features from
> SBCL, but I would like to have something that works for any lisp that
> FriCAS supports.
>
> > You do not say what you want from Sage.  IMO "proper" way of using
> > external programs involves appropriate communitation protocol and
> > ways to translate data.
>
> Proper way is more involved. What I want is just to give our users
> something at hand that enables them to build on top of a simple
> communication protocol (like my RunExternalCommand) and do the remaining
> "interpret(parse make_output_fricas_like(external_output)" in an ad hoc
> fashion.
>
> This might or might not be the start of a true interface to external CAS
> (not really my goal), but I just wanted to call two functions from Sage
> and use their output for comparison/testing of my code.
>
> > OTOH I am not sure if there are good ways to get information out of
> > Sage.
>
> In general, you are right. But I do not want to write an interface to
> everything in Sage. That would be equally difficult as the interface to
> FriCAS in Sage. It also only covers a part of FriCAS.
>
> Recently, Kurt told me about his experiments.
>
> https://github.com/nilqed/spadlib/blob/master/pipe/src/pipe.spad
>
> I haven't yet experimented with it, but it looks interesting.
> I might probably use that for myself, but this code seems to be bound to
> SBCL and not easily doable if the underlying lisp can be any other of
> the FriCAS supported lisps.
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra 

Re: [fricas-devel] Problems with FriCAS on Apple M2 Pro Ventura 13.2.1

[Dima Pasechnik]

On Wed, 29 Mar 2023, 10:01 Валерий Заподовников, 
wrote:

> "armv9-a" That is not what M2 is. It is only ARMv8.5-A (actually ARMv8.6
> just without SM4). Indeed, see https://reviews.llvm.org/D134351
>
> "(thanks Apple for stealing the name)" They did not steal anything, llvm
> has permissive license.
>

GPL, what GNU Compiler Collection, a.k.a. gcc, is using, is not a very
permissive licence, unlike MIT one. But this is beside my point.

When I say "they stole the name gcc" I mean that they caused an endless
amount of, unnecessary otherwise, coding in installation scripts, to try to
sort out whether this gcc is real gcc, or clang.

Because they are not  100% compatible, this is needed, unfortunately.

Apple caused more grief to the GCC project and developers of maths soft on
Apple  than just this, but, again, it's beside my point.


Intel compiler also nowadays uses it.
>
> "any standard way to find that out by some command or whatever for a later
> documentation" march=native with clang
>
> --
> 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/6371feb0-aa5a-4f9f-a911-abbd7a75f681n%40googlegroups.com
> 
> .
>

-- 
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/CAAWYfq3jsmDrLXvBorUScGJkrkeEOx%3DKodQd%3DXnjmRis2to4sg%40mail.gmail.com.

Re: [fricas-devel] Problems with FriCAS on Apple M2 Pro Ventura 13.2.1

[Dima Pasechnik]

On Tue, 28 Mar 2023, 20:10 Prof. Dr. Johannes Grabmeier, <
j.l.grabme...@gmail.com> wrote:

> it seems that this looks ok:
>
> ~$ uname -a
> Darwin MBPvonJohannes.fritz.box 22.3.0 Darwin Kernel Version 22.3.0: Mon
> Jan 30 20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020 arm64
> ~$
> ~$ gcc -v
> Apple clang version 13.1.6 (clang-1316.0.21.2.5)
> Target: arm64-apple-darwin22.3.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
>
it  seems that you don't have Command Line Tools installed, and also your
version of XCode might be not up to date.
My advice would be to rectify these.

HTH
Dima

>
> Am 27.03.23 um 14:43 schrieb Dima Pasechnik:
>
> On Mon, 27 Mar 2023, 11:42 Prof. Dr. Johannes Grabmeier, <
> johan...@grabmeier.net> wrote:
>
>> High,
>>
>> that was a very useful remark, how could one have the idea that default
>> of gcc is x86_64 on an arm64 machine. It was also hard to find out that my
>> version is
>>
>> armv8.5-a
>>
>>
> normally speaking this is not the case - you have a weird gcc installation
> somewhere. Note that gcc might actually be Apple's clang compiler
> (thanks Apple for stealing the name)
>
> % gcc -v
> Apple clang version 14.0.0 (clang-1400.0.29.202)
> Target: arm64-apple-darwin22.3.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> this is on an M1 mac:
>
> % uname -a
> Darwin studio.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30
> 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000 arm64
>
> Unless really necessary, I'd use Apple's "gcc", it's certainly better
> supported.
>
> HTH
> Dima
>
>
> (any standard way to find that out by some command or whatever for a later
>> documentation of my trial and errors?)
>>
>> I proceeded as Gregory has suggested, not know what concrete things one
>> has to do for
>>
>> But you have also configure target options for that:
>> ./configure --help
>> |snip]
>> System types:
>>   --build=BUILD configure for building on BUILD [guessed]
>>   --host=HOST   cross-compile to build programs to run on HOST [BUILD]
>>   --target=TARGET   configure for building compilers for TARGET [HOST]
>>
>> I checked the configure log file, and for me this seems ok, e.g.
>>
>> ac_cv_target=arm-apple-darwin22.3.0
>>
>> FRICAS='/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0'
>>
>>
>> fricas_targetdir='/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0'
>>
>>  host='arm-apple-darwin22.3.0'
>>
>>
>> But the gmake failed, as the directory is not created  (again referring
>> to x86):
>>
>> ~/fricas-1.3.8$ make
>> cd ./src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
>> BUILD_DATE="`date`" all-src
>> gcc -march=armv8.5-a -g -dynamiclib -single_module bsdsignal.o cfuns-c.o
>> sockio-c.o  -o
>> /Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so
>> ld: warning: ignoring file bsdsignal.o, building for macOS-arm64 but
>> attempting to link with file built for unknown-x86_64
>> ld: warning: ignoring file cfuns-c.o, building for macOS-arm64 but
>> attempting to link with file built for unknown-x86_64
>> ld: warning: ignoring file sockio-c.o, building for macOS-arm64 but
>> attempting to link with file built for unknown-x86_64
>> ld: can't open output file for writing:
>> /Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so,
>> errno=2 for architecture arm64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> make[2]: ***
>> [/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so]
>> Error 1
>> make[1]: *** [all-lib] Error 2
>> make: *** [all-src] Error 2
>>
>> Regards Johannes
>>
>>
>> Am 25.03.23 um 19:48 schrieb Grégory Vanuxem:
>>
>> Hello,
>>
>> It seems the C code files are compiled for the x86_64 target arch. Do
>> you have a compatible gcc for your arch?
>>
>> You can try to export something like (in bash) before configure step.:
>>
>> export CC='gcc -march=armv9-a’
>>
>> Or something like that.
>> For example on my machine:
>>
>> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
>> └─$ export CC='gcc -march=x86-64'
>>
>> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
>> └─$ ./configure  --enable-gmp
>> checking build system type... x86_64-linux-gnu
&

Re: [fricas-devel] Problems with FriCAS on Apple M2 Pro Ventura 13.2.1

[Dima Pasechnik]

On Mon, 27 Mar 2023, 11:42 Prof. Dr. Johannes Grabmeier, <
johan...@grabmeier.net> wrote:

> High,
>
> that was a very useful remark, how could one have the idea that default of
> gcc is x86_64 on an arm64 machine. It was also hard to find out that my
> version is
>
> armv8.5-a
>
>
normally speaking this is not the case - you have a weird gcc installation
somewhere. Note that gcc might actually be Apple's clang compiler
(thanks Apple for stealing the name)

% gcc -v
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

this is on an M1 mac:

% uname -a
Darwin studio.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30
20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000 arm64

Unless really necessary, I'd use Apple's "gcc", it's certainly better
supported.

HTH
Dima


(any standard way to find that out by some command or whatever for a later
> documentation of my trial and errors?)
>
> I proceeded as Gregory has suggested, not know what concrete things one
> has to do for
>
> But you have also configure target options for that:
> ./configure --help
> |snip]
> System types:
>   --build=BUILD configure for building on BUILD [guessed]
>   --host=HOST   cross-compile to build programs to run on HOST [BUILD]
>   --target=TARGET   configure for building compilers for TARGET [HOST]
>
> I checked the configure log file, and for me this seems ok, e.g.
>
> ac_cv_target=arm-apple-darwin22.3.0
>
> FRICAS='/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0'
>
>
> fricas_targetdir='/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0'
>
>  host='arm-apple-darwin22.3.0'
>
>
> But the gmake failed, as the directory is not created  (again referring to
> x86):
>
> ~/fricas-1.3.8$ make
> cd ./src && /Applications/Xcode.app/Contents/Developer/usr/bin/make
> BUILD_DATE="`date`" all-src
> gcc -march=armv8.5-a -g -dynamiclib -single_module bsdsignal.o cfuns-c.o
> sockio-c.o  -o
> /Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so
> ld: warning: ignoring file bsdsignal.o, building for macOS-arm64 but
> attempting to link with file built for unknown-x86_64
> ld: warning: ignoring file cfuns-c.o, building for macOS-arm64 but
> attempting to link with file built for unknown-x86_64
> ld: warning: ignoring file sockio-c.o, building for macOS-arm64 but
> attempting to link with file built for unknown-x86_64
> ld: can't open output file for writing:
> /Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so,
> errno=2 for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[2]: ***
> [/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so]
> Error 1
> make[1]: *** [all-lib] Error 2
> make: *** [all-src] Error 2
>
> Regards Johannes
>
>
> Am 25.03.23 um 19:48 schrieb Grégory Vanuxem:
>
> Hello,
>
> It seems the C code files are compiled for the x86_64 target arch. Do
> you have a compatible gcc for your arch?
>
> You can try to export something like (in bash) before configure step.:
>
> export CC='gcc -march=armv9-a’
>
> Or something like that.
> For example on my machine:
>
> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
> └─$ export CC='gcc -march=x86-64'
>
> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
> └─$ ./configure  --enable-gmp
> checking build system type... x86_64-linux-gnu
> checking host system type... x86_64-linux-gnu
> checking target system type... x86_64-linux-gnu
> checking for in-tree build on case insensitive file system... no
> checking for make... make
> checking for gcc... gcc -march=x86-64
> checking whether the C compiler works... yes
>
> From the doc:
> =
> march=name[+extension…]
>
> This specifies the name of the target ARM architecture. GCC uses this
> name to determine what kind of instructions it can emit when
> generating assembly code. This option can be used in conjunction with
> or instead of the -mcpu= option.
>
> Permissible names are: ‘armv4t’, ‘armv5t’, ‘armv5te’, ‘armv6’,
> ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’,
> ‘armv7’, ‘armv7-a’, ‘armv7ve’, ‘armv8-a’, ‘armv8.1-a’, ‘armv8.2-a’,
> ‘armv8.3-a’, ‘armv8.4-a’, ‘armv8.5-a’, ‘armv8.6-a’, ‘armv9-a’,
> ‘armv7-r’, ‘armv8-r’, ‘armv6-m’, ‘armv6s-m’, ‘armv7-m’, ‘armv7e-m’,
> ‘armv8-m.base’, ‘armv8-m.main’, ‘armv8.1-m.main’, ‘armv9-a’, ‘iwmmxt’
> and ‘iwmmxt2’.
> =
>
> But you have also configure target options for that:
> ./configure --help
> |snip]
> System types:
>   --build=BUILD configure for building on BUILD [guessed]
>   --host=HOST   cross-compile to build programs to run on HOST [BUILD]
>   --target=TARGET   configure for building compilers for TARGET [HOST]
>
> Hope that helps. Otherwise, you'll have to install a C compiler that
> can produce arm binaries.
>
> __
> Greg
>
> Le sam. 25 

Re: [fricas-devel] Problems with FriCAS on Apple M2 Pro Ventura 13.2.1

[Dima Pasechnik]

We are able to build Fricas with ECL supplied by macOS Homebrew on an
M1 machine,  native arm64,
no x86_64 stuff involved.

It's Fricas 1.3.8 patched with ECL-specific patches (SageMath patches,
see https://github.com/sagemath/sage/tree/develop/build/pkgs/fricas/patches)
discussed in https://github.com/fricas/fricas/issues/59
(which happened after 1.3.8 was released)% otool -L
./local/lib/fricas/target/aarch64-apple-darwin22.3.0/bin/FRICASsys
./local/lib/fricas/target/aarch64-apple-darwin22.3.0/bin/FRICASsys:
/opt/homebrew/opt/ecl/lib/libecl.21.2.dylib (compatibility
version 21.2.1, current version 0.0.0)
/opt/homebrew/opt/gmp/lib/libgmp.10.dylib (compatibility
version 15.0.0, current version 15.1.0)
/opt/homebrew/opt/bdw-gc/lib/libgc.1.dylib (compatibility
version 7.0.0, current version 7.1.0)
/usr/lib/libffi.dylib (compatibility version 1.0.0, current
version 30.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1319.0.0)

(Note that arm64 Homebrew is installed in /opt)

% file ./local/lib/fricas/target/aarch64-apple-darwin22.3.0/bin/FRICASsys
./local/lib/fricas/target/aarch64-apple-darwin22.3.0/bin/FRICASsys:
Mach-O 64-bit executable arm64

HTH
Dima

On Sat, Mar 25, 2023 at 6:48 PM Grégory Vanuxem  wrote:
>
> Hello,
>
> It seems the C code files are compiled for the x86_64 target arch. Do
> you have a compatible gcc for your arch?
>
> You can try to export something like (in bash) before configure step.:
>
> export CC='gcc -march=armv9-a’
>
> Or something like that.
> For example on my machine:
>
> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
> └─$ export CC='gcc -march=x86-64'
>
> ┌──(greg㉿ellipse)-[~/Git/jlfricas]
> └─$ ./configure  --enable-gmp
> checking build system type... x86_64-linux-gnu
> checking host system type... x86_64-linux-gnu
> checking target system type... x86_64-linux-gnu
> checking for in-tree build on case insensitive file system... no
> checking for make... make
> checking for gcc... gcc -march=x86-64
> checking whether the C compiler works... yes
>
> From the doc:
> =
> march=name[+extension…]
>
> This specifies the name of the target ARM architecture. GCC uses this
> name to determine what kind of instructions it can emit when
> generating assembly code. This option can be used in conjunction with
> or instead of the -mcpu= option.
>
> Permissible names are: ‘armv4t’, ‘armv5t’, ‘armv5te’, ‘armv6’,
> ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’,
> ‘armv7’, ‘armv7-a’, ‘armv7ve’, ‘armv8-a’, ‘armv8.1-a’, ‘armv8.2-a’,
> ‘armv8.3-a’, ‘armv8.4-a’, ‘armv8.5-a’, ‘armv8.6-a’, ‘armv9-a’,
> ‘armv7-r’, ‘armv8-r’, ‘armv6-m’, ‘armv6s-m’, ‘armv7-m’, ‘armv7e-m’,
> ‘armv8-m.base’, ‘armv8-m.main’, ‘armv8.1-m.main’, ‘armv9-a’, ‘iwmmxt’
> and ‘iwmmxt2’.
> =
>
> But you have also configure target options for that:
> ./configure --help
> |snip]
> System types:
>   --build=BUILD configure for building on BUILD [guessed]
>   --host=HOST   cross-compile to build programs to run on HOST [BUILD]
>   --target=TARGET   configure for building compilers for TARGET [HOST]
>
> Hope that helps. Otherwise, you'll have to install a C compiler that
> can produce arm binaries.
>
> __
> Greg
>
> Le sam. 25 mars 2023 à 15:23, Johannes Prof. Dr. Grabmeier, TH DEG
>  a écrit :
> >
> > Thanks for all the hints, which helped me to proceed:
> >
> > 1. Downloaded and installed binary of sbcl-2.1.2 for Darwin on ARM64 
> > successful!
> > 2. configure: still problem with the case sensitive file system check, I 
> > commented this check out in configure
> > 3. Then configure runs successful in a terminal (next mistake I made, I 
> > userd iterm, probably some how with x86 background/emulation so uname -m 
> > gave x_86 and not arm 64, this is ok in terminal
> > 4. but make fails, somehow it will again is confused with x86_64.
> >
> > Any ideas?
> >
> >
> >
> > DAASE=/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0 
> > FRICAS=/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0 
> > FRICAS_INITFILE='' 
> > /Users/jgrabmeier/fricas-1.3.8/build/arm-apple-darwin22.3.0/bin/interpsys
> > Checking for foreign routines
> > FRICAS="/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0"
> > spad-lib="/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so"
> > foreign routines found
> >
> > debugger invoked on a SIMPLE-ERROR in thread
> > #:
> >   Error opening shared object 
> > "/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so":
> >   
> > dlopen(/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so,
> >  0x000A): tried: 
> > '/Users/jgrabmeier/fricas-1.3.8/target/arm-apple-darwin22.3.0/lib/libspad.so'
> >  (mach-o file, but is an incompatible architecture (have 'x86_64', need 
> > 'arm64')), 
> > 

Re: [fricas-devel] broken FriCAS 1.3.8 install with ecl on Fedora 34

[Dima Pasechnik]

Thanks for the reply.
It turns out that on this machine there were a number of aliases set,
e.g. "rm" was aliased to "rm -i".
And this broke the build in this quite unpleasant way.

Perhaps one should check that hand-written build scripts (autoconf etc
are clever enough to explicitly put "rm -f"
everywhere) in FriCAS don't use "rm" without "-f".
(there is at least one such place in configure.ac - but it doesn't
look like the one that caused all this havoc)

Cheers
Dima


On Wed, Jan 25, 2023 at 7:17 PM Waldek Hebisch
 wrote:
>
> On Wed, Jan 25, 2023 at 10:10:23AM -0800, Dima Pasechnik wrote:
> > basically, no floating point support, no polynomials - due to fas files
> > SMP.fas and FLOAT.fas absent.
> >
> > Indeed, there is no FLOAT.fas:
> >
> > $ ls /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLO*.fas
> > /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLOATCP.fas
> >  /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLOATRP.fas
> >
> > and no SMP.fas:
> >
> >  ls /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMP*.fas
> > /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMPCOER.fas
> >  /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMPEXPR.fas
> >
> > Here is what I get at the FriCAS prompt:
> >
> > 1) -> x^2
> >
> >>> System error:
> >Filesystem error with pathname
> > #P"/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMP.fas".
> > Either
> >  1) the file does not exist, or
> >  2) we are not allowed to access the file, or
> >  3) the pathname points to a broken symbolic link.
> 
> > Any idea what it could be?
>
> Looks like undetected build/instal failure.  Startup log is rather
> uninteresting here: when those files are missing those are
> exactly expected error message.  To diagnose one should look
> at build log.  First, I would suggest to get float.spad and
> multpoly.spad from source tarball and try:
>
> )compile float.spad
> )compile multpoly.spad
>
> This should produce bunch of directories including FLOAT.NRLIB
> and SMP.NRLIB.  Inside FLOAT.NRLIB there should be FLOAT.fas,
> inside SMP.NRLIB there should be SMP.fas.  In correctly
> working FriCAS newly compiled files will be used in preference
> to files from installation, so if the above compile commands
> worked float/poly things should work.  More likely you will
> see some failure message.  Anyway, this should localize where
> the problem is (install or compile).
>
> --
>   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/20230125200115.vwofjk5q65tcbpw2%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq0KWjRddgGkrUaEVPV67yk0Lv_9CUNDMKS7HAy94wURnA%40mail.gmail.com.

[fricas-devel] broken FriCAS 1.3.8 install with ecl on Fedora 34

[Dima Pasechnik]

basically, no floating point support, no polynomials - due to fas files
SMP.fas and FLOAT.fas absent.

Indeed, there is no FLOAT.fas:

$ ls /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLO*.fas
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLOATCP.fas 
 /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLOATRP.fas

and no SMP.fas:

 ls /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMP*.fas
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMPCOER.fas 
 /tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMPEXPR.fas

Here is what I get at the FriCAS prompt:

1) -> x^2
 
   >> System error:
   Filesystem error with pathname 
#P"/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMP.fas".
Either
 1) the file does not exist, or
 2) we are not allowed to access the file, or
 3) the pathname points to a broken symbolic link.

(1) -> 0.5*2
 
   >> System error:
   Filesystem error with pathname 
#P"/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLOAT.fas".
Either
 1) the file does not exist, or
 2) we are not allowed to access the file, or
 3) the pathname points to a broken symbolic link.

(1) -> 2+2

   (1)  4
Type: 
PositiveInteger

This is vanilla FriCAS 1.3.8 built with ecl 21 and the standard gcc, 11-3.1
The full startup message:

$ ./bin/fricas 
(HyperDoc) Cannot connect to the X11 server!
;;; Loading #P"/usr/lib64/ecl-21.2.1/cmp.fas"
Starting interpsys
spad = "/tmp/lib/fricas/target/x86_64-linux-gnu"
   Re-reading compress.daase   Re-reading interp.daase
   FriCAS initialization: interpreter 
   FriCAS initialization: database 
   FriCAS initialization: constructors 
   FriCAS initialization: history 
   FriCAS Computer Algebra System 
Version: FriCAS 1.3.8
   Timestamp: Wed 25 Jan 14:06:13 GMT 2023
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading browse.daase
   Re-reading category.daase
Initial getdatabase
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FR.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SUP2.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/TBAGG-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/RETRACT-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/RCAGG-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/UDPO.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/NONE.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/UPOLYC2.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/PRIMES.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SETCAT-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/INDE.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/QFCAT-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/POLY.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/ELTAGG-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/PDRING-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SET.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/UPOLYC-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FARRAY.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/SMP.fas..skipped.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/POLYCAT-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/DIFEXT-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/IFARRAY.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/AMR-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FAMR-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/DIVRING-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FLINEXP-.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/IVECTOR.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/IARRAY1.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/LA.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/LO.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/BOOLEAN.fas..loaded.
   preloading 
/tmp/lib/fricas/target/x86_64-linux-gnu/algebra/FIELD-.fas..loaded.
   preloading 

Re: [fricas-devel] Linear output representation of polynomials

[Dima Pasechnik]

As far as I know, an up to date Flint supports multivariate polynomial
rings, so this should go much faster if you just create one ring.
(assuming it is already used in Nemo).


On Tue, 27 Dec 2022, 10:38 Grégory Vanuxem,  wrote:

> Le lun. 26 déc. 2022 à 23:54, Grégory Vanuxem  a
> écrit :
>
> [snippet]]
>
> > FLINT 2 via the Nemo library in Julia
> > ===
> > julia> R, x = PolynomialRing(ZZ, "x");
> > julia> S, y = PolynomialRing(R, "y");
> > julia> T, z = PolynomialRing(S, "z");
> > julia> U, t = PolynomialRing(T, "t");
> > julia> f = x + y + z + t + 1
> > t + z + y + x + 1
> > julia> p = f^30;
> > julia> @time q = p*(p+1);
> >  32.041742 seconds (8.72 M allocations: 337.483 MiB, 3.31% gc time,
> > 0.02% compilation time)
> > julia> @time q = p*(p+1);
> >  30.781938 seconds (5.67 M allocations: 277.926 MiB, 0.29% gc time)
>
> In fact, I just wrote to flint-devel and nemo-devel google groups
> about the regression shown by this bench I ran around march 2020, the
> beginning of the 1st World COVID 19 containment. I was highly
> surprised yesterday.
>
> March 2020:
> R, x = PolynomialRing(ZZ, "x");
> S, y = PolynomialRing(R, "y");
> T, z = PolynomialRing(S, "z");
> U, t = PolynomialRing(T, "t");
> f = x + y + z + t + 1
> p = f^30;
> @time q = p*(p+1);
>  20.099625 seconds (2.32 M allocations: 102.120 MiB, 0.78% gc time)
>
>  Regards,
> __
> 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/CAHnU2db%2BsWgeg47Q3eoTsJYOCZJ96hCLJiopmz1DwwtB8zB5Rw%40mail.gmail.com
> .
>

-- 
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/CAAWYfq3522qaq_sm4Ypx3fcUmf2LfPsuRW7Hy2rRaj3jRjSe7Q%40mail.gmail.com.

Re: [fricas-devel] Re: FriCas

[Dima Pasechnik]

On Tue, 27 Sep 2022, 04:49 Andrey G. Grozin,  wrote:

> On Mon, 26 Sep 2022, Dima Pasechnik wrote:
> > brew install ecl
> > ./configure --with-lisp=ecl
> > make
> Why ecl? It is very slow. sbcl is much faster.
>

we use ecl in Sage - because it can produce dynamic libraries callable from
other environments. (we call it from Python).

although fricas interface is not done this way (more work? - I guess it
should be done one day)
we use such an interface for Maxima.


> Andrey
>
> --
> 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/c658f84a-c13-b751-65f9-2f7c7949a71b%40starnew.inp.nsk.su
> .
>

-- 
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/CAAWYfq3E1t5GVeCJy%2BT-6g2zMeeYnZ-xRsf6wqD3E6KaTkKQbQ%40mail.gmail.com.

Re: [fricas-devel] Re: FriCas

[Dima Pasechnik]

On Mon, Sep 26, 2022 at 10:55 PM Dima Pasechnik  wrote:
>
>
>
> On Mon, 26 Sep 2022, 22:27 Ralf Hemmecke,  wrote:
>>
>> http://fricas.github.io/install.html
>
>
> that's a seriously Debian/Ubuntu-centric guide.
>
> On macOS one ought to recommend installing Homebrew and necessary pre-reqs.
>
> Once Homebrew is installed, you'd need to run something like
>
> brew install ecl
> ./configure --with-lisp=ecl
actually on macOS it's better be

./configure --with-lisp=ecl --enable-case-insensitive-file-system-check=no

We also have patches for FriCAS 1.3.8 , see
https://github.com/sagemath/sage/tree/develop/build/pkgs/fricas/patches
- one of them macOS-specific.
(to be applied before running configure, naturally)

Not sure whether they (or some of it) is in the development version
(perhaps if you use another lisp, e.g. sbcl,
they are not needed)


> make
>
>
>
>
>>
>>
>> On 26.09.22 22:29, Gennaro Ferrelli wrote:
>> > How can i install It?
>>
>> --
>> 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/af0791f8-901e-fba3-7b78-81dbb8082292%40hemmecke.org.

-- 
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/CAAWYfq2-RSc1U4ZZMVMOzBa1MK%2BozWiPkFzCxcoNJ5GhTDUmHw%40mail.gmail.com.

Re: [fricas-devel] Re: FriCas

[Dima Pasechnik]

On Mon, 26 Sep 2022, 22:27 Ralf Hemmecke,  wrote:

> http://fricas.github.io/install.html


that's a seriously Debian/Ubuntu-centric guide.

On macOS one ought to recommend installing Homebrew and necessary pre-reqs.

Once Homebrew is installed, you'd need to run something like

brew install ecl
./configure --with-lisp=ecl
make





>
> On 26.09.22 22:29, Gennaro Ferrelli wrote:
> > How can i install It?
>
> --
> 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/af0791f8-901e-fba3-7b78-81dbb8082292%40hemmecke.org
> .
>

-- 
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/CAAWYfq0Z9pv_Ou-Y_ShQEFm6N98TnV9tTjskw2Sd7%3DkkTMk%2Bnw%40mail.gmail.com.

Re: [fricas-devel] Re: FriCas

[Dima Pasechnik]

On Mon, Sep 26, 2022 at 1:47 PM Gennaro Ferrelli  wrote:
>
> Thanks for all the replies. I downloaded sagemath from the GitHub site and 
> it's a dmg file. I can open either the terminal from sage app (web) or the 
> console at launch of the program. I don't know well the to do list to install 
> Fricas but I found this on the site:
>
> ''The -i option is not supported by the sage executable in this app, but many 
> optional Sage packages are included. Note that GAP packages which are not 
> included in the gap_packages spkg can be installed from within sage by using 
> the PackageManager GAP package. These will be installed in the user's ~/.gap 
> directory.''

then installing FriCAS standalone might be the easiest way out.

As soon as FriCAS can be found in PATH, it can be used from Sage.


>
> On Monday, September 26, 2022 at 12:16:47 PM UTC+2 Dima Pasechnik wrote:
>>
>> On Mon, Sep 26, 2022 at 11:14 AM 'Nasser M. Abbasi' via FriCAS -
>> computer algebra system  wrote:
>> >
>> > If you downloaded sagemath source tar file, you can just do, after 
>> > extracting it
>> >
>> > ./configure --enable-fricas
>> > make
>> > make install
>> >
>> > Since sagemath does not automatically build fricas (it does for giac and 
>> > maxima)
>> >
>> > And it will now build sage with fricas automatically.
>> An explicit
>>
>> make fricas
>>
>> (or sage -i fricas) will attempt to build fricas regardless of
>> ./configure --enable-fricas
>>
>>
>> >
>> > Otherwise you'd have to download fricas separately and install it. Either 
>> > from source or download binary
>> >
>> > http://fricas.sourceforge.net/download.html
>> >
>> >
>> >
>> >
>> > On Monday, September 26, 2022 at 5:06:42 AM UTC-5 axio...@yahoo.de wrote:
>> >>
>> >> Very likely,
>> >> $ sage -i fricas
>> >> on the console works. If it doesn't, it may be easier to install fricas 
>> >> separately, sage will then know how to use it.
>> >> On Monday, 26 September 2022 at 10:44:56 UTC+2 gex.fe...@gmail.com wrote:
>> >>>
>> >>> Hi, I'm a Mac user. I have arm64 architecture, so the MacBook with m1 
>> >>> chip. how can I install fracas for SageMath ? thanks all
>> >
>> > --
>> > 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/fricas-devel/07f6ce97-d2de-4c9c-9d14-561122bf4ddbn%40googlegroups.com.
>
> --
> 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/d971983b-6990-49a4-af9f-a44cca0c2295n%40googlegroups.com.

-- 
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/CAAWYfq35YiAZvNfQHfPta%3DVifsLq202xajiGJRqiJ_vB_mEdww%40mail.gmail.com.

Re: [fricas-devel] Re: FriCas

[Dima Pasechnik]

On Mon, Sep 26, 2022 at 11:14 AM 'Nasser M. Abbasi' via FriCAS -
computer algebra system  wrote:
>
> If you downloaded sagemath source tar file, you can just do, after extracting 
> it
>
> ./configure --enable-fricas
> make
> make install
>
> Since sagemath does not automatically build fricas (it does for giac and 
> maxima)
>
> And it will now build sage with fricas automatically.
An explicit

  make fricas

(or sage -i fricas) will attempt to build fricas regardless of
./configure --enable-fricas


>
> Otherwise you'd have to download fricas separately and install it. Either 
> from source or download binary
>
> http://fricas.sourceforge.net/download.html
>
>
>
>
> On Monday, September 26, 2022 at 5:06:42 AM UTC-5 axio...@yahoo.de wrote:
>>
>> Very likely,
>> $ sage -i fricas
>> on the console works.  If it doesn't, it may be easier to install fricas 
>> separately, sage will then know how to use it.
>> On Monday, 26 September 2022 at 10:44:56 UTC+2 gex.fe...@gmail.com wrote:
>>>
>>> Hi, I'm a Mac user. I have arm64 architecture, so the MacBook with m1 chip. 
>>> how can I install fracas for SageMath ? thanks all
>
> --
> 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/07f6ce97-d2de-4c9c-9d14-561122bf4ddbn%40googlegroups.com.

-- 
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/CAAWYfq0p3ewBKuzBTSm9dFJ8jh%2BB7oXeCzwUQJ3VbL6ug%3Dta_g%40mail.gmail.com.

Re: [fricas-devel] FYI, CAS independent integration tests, summer 2022 edition completed

[Dima Pasechnik]

On Tue, Aug 23, 2022 at 11:34 PM 'Martin R' via FriCAS - computer
algebra system  wrote:
>
> Dima, could you open a ticket for this?  I didn't know about 
> `explicit_solutions` when I wrote that code.

done, see https://trac.sagemath.org/ticket/34420

Dima
>
> Martin
>
> On Tuesday, 23 August 2022 at 17:07:37 UTC+2 Dima Pasechnik wrote:
>>
>> Behind the scene, Sage uses pynac (a clone of ginac) for its handling of 
>> symbolics. Implicit roots are supported. Docs say:
>>
>> 
>>
>> "By default, all the roots are required to be explicit rather than implicit. 
>> To get implicit roots, pass explicit_solutions=False to .roots()
>>
>> --
>>
>> I am not sure how well fricas interface is handling these,
>> though.
>>
>> Dima
>>
>>
>> On Tue, 23 Aug 2022, 15:22 Waldek Hebisch,  
>> wrote:
>>>
>>> On Tue, Aug 23, 2022 at 05:55:29AM -0700, 'Martin R' via FriCAS - computer 
>>> algebra system wrote:
>>> > If I understand correctly, FriCAS' result of integrate(1/(b*x^5+a), x)
>>> > contains some algebraic numbers with placeholders like %%G0.  To convert
>>> > the result into a sage expression, these are substituted back.
>>> > Unfortunately, these expressions may be extremely large, and this effect
>>> > multiplies when the constants appear multiple times.
>>>
>>> Those are not placeholders, they are roots of polynomials in
>>> implict form.  MMas call them RootOf.
>>>
>>> > If you have any suggestions on how to improve the situation, I'd be happy
>>> > to hear it.  Leaving them out is not really an option, because one may 
>>> > want
>>> > to do further computations with the integral.
>>>
>>> Represent them faithfully as implicit roots.  AFAICS Sage expands
>>> them to explicit form and this is _much_ larger than necessary.
>>> Worse, explicit form is problematic for later computations.
>>>
>>> BTW: Could you try the the attached patch?  The patch is not
>>> ready to be included now, but once problems are worked out
>>> many integrals will produce result like below.  In this example
>>> with the patch I get:
>>>
>>> (1) -> integrate(1/(b*x^5+a), x)
>>>
>>> --+
>>>(1)  > %E log(x + 5 %E a)
>>> --+
>>>   45
>>> 3125 a b %E  - 1 = 0
>>>  Type: 
>>> Union(Expression(Integer),...)
>>> (2) -> %::EXPR(INT)::InputForm
>>>
>>>(2)
>>>(%root_sum  (* %E (log (+ x (* (* 5 %E) a  %E
>>> (/ (+ (* (* (* 3125 (^ %E 5)) (^ a 4)) b) - 1) (* (* 3125 (^ a 4)) b)))
>>>   Type: 
>>> InputForm
>>>
>>>
>>> --
>>>   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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/fricas-devel/20220823142241.GA29641%40fricas.math.uni.wroc.pl.
>
> --
> 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/4c7fc330-c2a7-4824-9d67-085ad948ccb7n%40googlegroups.com.

-- 
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/CAAWYfq2PvyW2LyjETW-z3Z%2BQ_JO%3DhE_2bF_MdCrZnkBBLm640g%40mail.gmail.com.

Re: [fricas-devel] FYI, CAS independent integration tests, summer 2022 edition completed

[Dima Pasechnik]

Behind the scene, Sage uses pynac (a clone of ginac) for its handling of
symbolics. Implicit roots are supported. Docs say:



"By default, all the roots are required to be explicit rather than
implicit. To get implicit roots, pass explicit_solutions=False to .roots()

--

I am not sure how well fricas interface is handling these,
though.

Dima


On Tue, 23 Aug 2022, 15:22 Waldek Hebisch, 
wrote:

> On Tue, Aug 23, 2022 at 05:55:29AM -0700, 'Martin R' via FriCAS - computer
> algebra system wrote:
> > If I understand correctly, FriCAS' result of integrate(1/(b*x^5+a), x)
> > contains some algebraic numbers with placeholders like %%G0.  To convert
> > the result into a sage expression, these are substituted back.
> > Unfortunately, these expressions may be extremely large, and this effect
> > multiplies when the constants appear multiple times.
>
> Those are not placeholders, they are roots of polynomials in
> implict form.  MMas call them RootOf.
>
> > If you have any suggestions on how to improve the situation, I'd be
> happy
> > to hear it.  Leaving them out is not really an option, because one may
> want
> > to do further computations with the integral.
>
> Represent them faithfully as implicit roots.  AFAICS Sage expands
> them to explicit form and this is _much_ larger than necessary.
> Worse, explicit form is problematic for later computations.
>
> BTW: Could you try the the attached patch?  The patch is not
> ready to be included now, but once problems are worked out
> many integrals will produce result like below.  In this example
> with the patch I get:
>
> (1) -> integrate(1/(b*x^5+a), x)
>
> --+
>(1)  > %E log(x + 5 %E a)
> --+
>   45
> 3125 a b %E  - 1 = 0
>  Type:
> Union(Expression(Integer),...)
> (2) -> %::EXPR(INT)::InputForm
>
>(2)
>(%root_sum  (* %E (log (+ x (* (* 5 %E) a  %E
> (/ (+ (* (* (* 3125 (^ %E 5)) (^ a 4)) b) - 1) (* (* 3125 (^ a 4)) b)))
>   Type:
> InputForm
>
>
> --
>   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/20220823142241.GA29641%40fricas.math.uni.wroc.pl
> .
>

-- 
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/CAAWYfq0x6eimq6GDw%3DnjvTo4zFV5-STcj_7_fSkYe1dkn%3DtNzQ%40mail.gmail.com.

Re: [fricas-devel] GitHub access

[Dima Pasechnik]

On Thu, Aug 4, 2022 at 8:04 PM Ralf Hemmecke  wrote:
>
> Hi Waldek,
>
> The following is similar to what Qian suggested, but using ssh.
>
> Create an ssh key and upload the ~/.ssh/github.pub to your github account.
>
>ssh-keygen -t ecdsa -f $HOME/.ssh/github -C YOURNAME@github

IMHO the today advice is: don't use ecdsa, use ed25519

>
> Put the following into your ~/.ssh/config file
>
> 
> # Access my github repositories.
> Host github
>IdentityFile ~/.ssh/github
>HostName github.com
>User git
> 
>
> Get you personal FriCAS repository (that "remote" is called "origin" by
> default.)
>
>git clone github:hemmecke/fricas.git
>
> Add the official FriCAS repo as "upstream"
>
>git remote add upstream github:fricas/fricas.git
>
> Both "origin" and "upstream" are writable, because you use ssh.
>
> Get the pull request branch.
> For example, to get https://github.com/fricas/fricas/pull/73 into your
> local repository do the following.
>
>git fetch upstream pull/73/head:pr-73
>
> Now merge the pull request if you want
>
>git merge pr-73
>
> Push it to your own repo (if you like).
>
>git push origin master
>
> Push the new master to the official fricas repo.
>
>git push upstream master
>
>
>
> Ralf
>
> --
> 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/f2374990-c398-197c-d69d-5fa9148c1724%40hemmecke.org.

-- 
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/CAAWYfq3_%2BP1n3cXc045wSqZBu%2BpXLrhBL1%3D_aV1upbBh6wqz_A%40mail.gmail.com.

Re: [fricas-devel] GitHub access

[Dima Pasechnik]

On Tue, Jul 26, 2022 at 2:11 AM Qian Yun  wrote:
>
> I think the correct way for GitHub access is to use PAT:
>
> https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
>
> You have to login to web pages and generate a PAT, then
> use it instead of password for the https address.

well, yes, that's a way to circumvent 2FA, but certainly this is an
overkill for merely using git

(it's needed for operations beyond that, i.e. for using GitHub's APIs)

>
> - Qian
>
> On 7/26/22 07:42, Waldek Hebisch wrote:
> > On Tue, Jul 26, 2022 at 12:54:33AM +0200, Dima Pasechnik wrote:
> >>
> >> Do you mean to say that you cannot have ssh authentication with
> >> GitHub's git server?
> >> (well, yes, if you don't have a GitHub account then you can't upload
> >> an ssh key, indeed...)
> >
> > I have.  But doing
> >
> > git clone https://github.com/fricas/fricas
> >
> > gives read-only copy.  IIRC has to do use
> >
> > g...@github.com:fricas/fricas
> >
> > At least for some operations using https address
> > leads to password prompt that does not work.
> > For best "security" error messages are non-informative,
> > so it was not clear what is wrong.  My first suspicion
> > was that instruction was wrong (there is a _lot_ of
> > wrong stuff on the net).  But later I realised
> > another thing did not work with https address, so
> > probably I used https address and merge did not
> > work due to https address.
> >
>
> --
> 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/62a05153-3326-f881-c879-480051deb8c7%40gmail.com.

-- 
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/CAAWYfq3_ttUshU%3D32-RQB70zeuVOxevBipKSYuzDPLXYSTVLKg%40mail.gmail.com.

Re: [fricas-devel] GitHub access

[Dima Pasechnik]

On Tue, Jul 26, 2022 at 1:42 AM Waldek Hebisch
 wrote:
>
> On Tue, Jul 26, 2022 at 12:54:33AM +0200, Dima Pasechnik wrote:
> > On Mon, Jul 25, 2022 at 8:34 PM Waldek Hebisch
> >  wrote:
> > >
> > > On Sat, Jul 23, 2022 at 04:02:42PM +0200, Dima Pasechnik wrote:
> > > > On Sat, 23 Jul 2022, 15:46 Waldek Hebisch, 
> > > > 
> > > > wrote:
> > > >
> > > > > I must admit that my prefered information flow would be
> > > > > as follows:
> > > > > - issues in Github issue tracker.  But if there is need
> > > > >   for discussion it should be in mailing list
> > > > > - in general discussions (including proposed changes)
> > > > >   in mailing list
> > > > > - changes as patches (diff files)
> > > > >
> > > > > I understand that third point (patches) is disliked by
> > > > > other people here, but up to now I did not figure out
> > > > > how to merge Github pull request using _only_ git commands.
> > > > >
> > > >
> > > > what exactly is not working here for you?
> > > > GitHub PRs git branches are just, well, git branches, so producing and
> > > > pushing a merged branch is possible with git commands only.
> > >
> > > First problem is to have good address for this branch.  IIRC
> > > I found info how to fetch this branch, but I was not able to
> > > do what I needed apparently due to permission problems.
> > >
> > > Part of problem seem to be that Github associates permissions
> > > with address that one uses and that they disabled password
> > > authentication.  That breaks old instructions.  And I did
> > > not find up-to date instructions (actually since old
> > > instructions that I found did not work I did not copy them
> > > so I have no instruction  new or old).
> >
> > Do you mean to say that you cannot have ssh authentication with
> > GitHub's git server?
> > (well, yes, if you don't have a GitHub account then you can't upload
> > an ssh key, indeed...)
>
> I have.  But doing
>
> git clone https://github.com/fricas/fricas
>
> gives read-only copy.  IIRC has to do use
>
> g...@github.com:fricas/fricas

Are you saying that

 git clone g...@github.com:fricas/fricas

does not work for you, despite having an ssh key uploaded?
This is most probably due to the key being too short, or in an
outdated compromosed format.
An ed25519 key, or a suffiecienly long rsa key (at least 3000 bit?) should work.


>
> At least for some operations using https address
> leads to password prompt that does not work.

For a password-besed access you nowdays need a 2FA set up.

> For best "security" error messages are non-informative,
> so it was not clear what is wrong.  My first suspicion
> was that instruction was wrong (there is a _lot_ of
> wrong stuff on the net).  But later I realised
> another thing did not work with https address, so
> probably I used https address and merge did not
> work due to https address.
>
> --
>   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/20220725234253.GA30085%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq18bcMbaijAE8Ln_TEie2wz2QdGH-Q4vPrzq5uNTwJL5g%40mail.gmail.com.

Re: [fricas-devel] About GitHub issues (not always showing email replies)

[Dima Pasechnik]

On Mon, Jul 25, 2022 at 8:34 PM Waldek Hebisch
 wrote:
>
> On Sat, Jul 23, 2022 at 04:02:42PM +0200, Dima Pasechnik wrote:
> > On Sat, 23 Jul 2022, 15:46 Waldek Hebisch, 
> > wrote:
> >
> > > I must admit that my prefered information flow would be
> > > as follows:
> > > - issues in Github issue tracker.  But if there is need
> > >   for discussion it should be in mailing list
> > > - in general discussions (including proposed changes)
> > >   in mailing list
> > > - changes as patches (diff files)
> > >
> > > I understand that third point (patches) is disliked by
> > > other people here, but up to now I did not figure out
> > > how to merge Github pull request using _only_ git commands.
> > >
> >
> > what exactly is not working here for you?
> > GitHub PRs git branches are just, well, git branches, so producing and
> > pushing a merged branch is possible with git commands only.
>
> First problem is to have good address for this branch.  IIRC
> I found info how to fetch this branch, but I was not able to
> do what I needed apparently due to permission problems.
>
> Part of problem seem to be that Github associates permissions
> with address that one uses and that they disabled password
> authentication.  That breaks old instructions.  And I did
> not find up-to date instructions (actually since old
> instructions that I found did not work I did not copy them
> so I have no instruction  new or old).

Do you mean to say that you cannot have ssh authentication with
GitHub's git server?
(well, yes, if you don't have a GitHub account then you can't upload
an ssh key, indeed...)

>
> --
>   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/20220725175007.GA24189%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq3VQc0Gd0aRw%3DjH7KPodVq%3DrY5-uUf30cz6Dau-7Z03dQ%40mail.gmail.com.

Re: [fricas-devel] About GitHub issues (not always showing email replies)

[Dima Pasechnik]

On Sat, 23 Jul 2022, 15:46 Waldek Hebisch, 
wrote:

> On Sat, Jul 23, 2022 at 09:17:06AM +0800, Qian Yun wrote:
> > There were several times that GitHub does not display email replies
> > from Waldek.  This is already causing headaches for me and I think
> > this situation is bad for the collaboration of the FriCAS project.
> >
> > First, I understand that, for privacy reasons or other reasons,
> > an email based workflow can be preferred over a web based one.
> >
> > I can think of 2 solutions right now:
> >
> > 1. It seems that Waldek is using one email account for googlegroups
> > and another email account for GitHub replies.  I guess you are
> > managing the 2 email accounts in a single email client locally.
> > If so,  I wonder if it is possible/convenient to send the reply
> > to googlegroups/GitHub issues through 2 email accounts simultaneously.
>
> ATM the accounts are on two different machines.  As popular
> saying goes doing what you propose is SMOP (small matter of
> programming), but I would prefer to spent my programming time
> on FriCAS and not on mail software.  And also see below...
>
> > 2. Setup some GitHub Actions script to forward every GitHub issue
> > comments to fricas-devel.  Then when the issue is resolved, we can
> > sync the status back to GitHub.
>
> Primary reason that I directed Github messages to separate
> address is that Github can be quite spammy, there is a lot
> of trivial messsages.  Duplicating messages would add to
> the problem.
>
> I must admit that my prefered information flow would be
> as follows:
> - issues in Github issue tracker.  But if there is need
>   for discussion it should be in mailing list
> - in general discussions (including proposed changes)
>   in mailing list
> - changes as patches (diff files)
>
> I understand that third point (patches) is disliked by
> other people here, but up to now I did not figure out
> how to merge Github pull request using _only_ git commands.
>

what exactly is not working here for you?
GitHub PRs git branches are just, well, git branches, so producing and
pushing a merged branch is possible with git commands only.

Marking the PR as resolved, on the other hand, seems tricky, if at all
possible. There are command line tools for this, so a browser is not
needed, ( e.g. tig, see  https://jonas.github.io/tig/ )
but one would need to authenticate to GitHub once.



Since I unable to use git commands ATM handling merging
> pull requests is extremally inconvenient for me.
>
> --
>   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/20220723134615.GB30366%40fricas.math.uni.wroc.pl
> .
>

-- 
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/CAAWYfq20a_vkC7-O402krS52DwL9McT78ruOW%2BZAiTJy1vswKA%40mail.gmail.com.

Re: [fricas-devel] GCL and ECL build status regarding to recent patches

[Dima Pasechnik]

On Sat, 23 Jul 2022, 14:46 Waldek Hebisch, 
wrote:

> On Sat, Jul 23, 2022 at 12:51:41PM +0800, Qian Yun wrote:
> > There are patches for GCL and ECL recently, and I wonder
> > if there are more coming?
>
> Currently no.  The patches fix things that I know about
> and know how to fix.
>
> > I didn't take a deeper look into the failures, but this is
> > build status from my side:
> >
> > GCL-2.6.13_pre fails to build on Linux with git HEAD.
>
> I commited GCL patches should make porting to newere GCL-s
> easier, but does not solve main problems.  Also, I commited
> only parts compatible with older versions.
>
> > ECL fails to build on macOS with git HEAD.
>
> Could you say more about this?  Main change is that
> FriCAS now generates extern declarations for C
> functions that we call via FFI.  That is supposed
> to replace Sage patch (which IMO is problematic).
>
> Anyway, with the patches FriCAS build for me
> using gcl-2.6.12, ecl-16.1.2 and ecl-21.2.1.
> So with ECL any problem most likely is OS or
> C compiler.  Of course, C compiler can emit
> warnings whenever it wants and if one inserts
> '-Werror' to default C options  it may easily
> lead to spurious failures.
>
> BTW: ATM I find Github CI reports kind of useless,
> they does not tell me more than what I already
> know due to Murphy: there is failure somewhere.
> Up to now I was unable to see build logs to get
> more info.  One answer to stackoverflow question
> claimed that one has to authenticate as project
> admin to see logs but I saw no docs how this is
> supposed to work.
>

well, yes, one has to log in to GitHub to see full logs of the Actions (CI)
runs.

although with a bit of extra effort one can upload them (from Actions runs)
somewhere outside of GitHub.



> --
>   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/20220723124649.GA30366%40fricas.math.uni.wroc.pl
> .
>

-- 
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/CAAWYfq0_r4oPGaW6kDuN-%3DJG7pdngY4V-hiet1DVfjcn_VFW3g%40mail.gmail.com.

Re: [fricas-devel] GCL and ECL build status regarding to recent patches

[Dima Pasechnik]

On Sat, Jul 23, 2022 at 6:52 AM Qian Yun  wrote:
>
> There are patches for GCL and ECL recently, and I wonder
> if there are more coming?
>
> I didn't take a deeper look into the failures, but this is
> build status from my side:
>
> GCL-2.6.13_pre fails to build on Linux with git HEAD.
>
> ECL fails to build on macOS with git HEAD.
>
We use 2 patches for ECL/fricas:
https://github.com/sagemath/sage/tree/develop/build/pkgs/fricas/patches



> - 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/3e7ef019-1507-c015-b061-eaaa6116ea24%40gmail.com.

-- 
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/CAAWYfq36aZU9PyCF%3DGOU11u7C_Qj19WONO9Xws%3D3Xgz-EN3t6w%40mail.gmail.com.

Re: [fricas-devel] Is there a time frame for the next version of Fricas?

[Dima Pasechnik]

On Fri, May 13, 2022 at 9:18 PM Ralf Hemmecke  wrote:
>
> On 13.05.22 09:06, Qian Yun wrote:
>
> > Also, IIRC, the Sage compiles FriCAS with ecl instead of sbcl.
>
> Well, Sage seems to be smart. I have installed sage via apt-get in
> ubuntu 18.04 and no sage package for fricas is installed.
>
> When I type
>
> integrate(sin(x),x,algorithm='fricas')
>
> it gives an error if the fricas script was not in the PATH when I
> started sage. Otherwise after calling "integrate" there is then a fricas
> process running which points to the path where I installed an sbcl fricas.

yes, this is as expected - Sage's fricas package builds fricas using
ecl, and installs it somewhere.
The interface is already there, regardless of fricas package being
installed, or not.

Dima
>
> Ralf
>
> --
> 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/f4f7f6d6-f07c-a9ed-d247-acc431656ad8%40hemmecke.org.

-- 
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/CAAWYfq2odExwm-_jdbNUDLzoYeJ3_GuETvv_A5gERxuoEY21uw%40mail.gmail.com.

Re: [fricas-devel] Creation of FriCAS binary distribution

[Dima Pasechnik]

On Fri, May 6, 2022 at 3:22 PM Waldek Hebisch
 wrote:
>
> On Fri, May 06, 2022 at 03:16:32PM +0200, Ralf Hemmecke wrote:
> > Dear Waldek,
> >
> > is there any description (or better even: a script) of how to create exactly
> > the binary distribution
> >
> > https://github.com/fricas/fricas/releases/tag/1.3.7
> >
>
> OK, again: process is manual using documented commands.  First
> you need source tarball.  Unpack it in work directory.  Then
> (for amd64):
>
> mkdir fr-build
> cd fr-build
> ../fricas-1.3.7/confiure --enable--gmp
> make -j 7 > mlogg 2>&1
> make DESTDIR=/temporary/install/dir instal
> cd /temporary/install/dir
> tar -cjf ../fricas-1.3.7.amd64.tar.bz2 usr
>
> After that in /temporary/install there is binary tarball.
>
> > In particular, I tried to install debian etch in a virtual machine.
> > That worked, but since it showed me every now and then some weired message
> > about some interrupt in the terminal, I removed that Vbox again.

such building (and uploading of results)
can be carried out using GitHub Actions.

> >
> > Do you happen to have a VM (that you could share) to build the fricas
> > binaries?
>
> I use chroot, did not try VM.  64-bit system (Mandrake 9.2) was installed
> on real hardware, later partition image was copied to newer disc.
> 32-bit install was a bit tricky, because I wanted to do it in chroot
> and Debian installer wants to run only from Debian.  I had to do first
> installation stage by hand, to get minimal Debian, than rest of install
> went fine in chroot.  For 32-bit builds I had to replace ''bin/arch'
> by a shell script (standard 'arch' was able to figure out that it
> run on 64-bit kernel and reported 54-bit architecture).
>
> Concerning VM, I use it for FriCAS wiki and it works well enough.
> But it seems that you need to match version of virtualbox with
> kernel version (earlier version of virtualbox caused troubles
> on my machine).  Also, virtualbox may warn you that some interactive
> features are problematic, but FriCAS build need no those features.
> Probably Bill and Qian can say more about virtualbox then myself,
> Wiki VM was created by Bill and modifed by Krystian.  I got it to
> run in virtualbox, but that is all, normally for other uses I
> prefer chroot.
>
> BTW: AFAIK Debian developers use chroot to be able to develop
> oldstable, stable and testing on the same hardware.
>
> --
>   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/20220506151519.GB28396%40fricas.math.uni.wroc.pl.

-- 
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/CAAWYfq1DYrpukyh3Ea3N2LBP7mhtymc88Gx48tCbxKt8q8caVg%40mail.gmail.com.

Re: [fricas-devel] future community collaboration tool (deprecating fricas-devel maillist)

[Dima Pasechnik]

On Mon, Apr 25, 2022 at 7:04 PM Bill Page  wrote:
>
> On Sun, 24 Apr 2022 at 23:48, Qian Yun  wrote:
> >
> > Hello everyone on fricas-devel:
> >
> > You may have noticed that Waldek has not posted on fricas-devel
> > for a while now.  He has replied to GitHub issues in the mean
> > time however.
> >
> > So I asked him privately via email, and he replied that he can't
> > reply/receive to fricas-devel, because Google wants cell number.
> >
>
> This seems extremely odd to me. Perhaps there is just some confusion
> on how to use Google Groups. I never (well, almost never) use Google
> Groups directly. All postings on the FriCAS group are sent to me by
> simple email (such as this one) and my replies (such as this one) are
> sent to the FriCAS group as an email. I have used the FriCAS group
> this way since the beginning. So I am seriously confused if someone
> claims "Google wants cell number". I never gave Google my cell number.
> So far as I know this isn't even necessary if you actually have a
> gmail account. Rather, it is perhaps an option in this case if you
> want to use 2-factor authentication.

One absolutey does not need a cell phone (or a special hardware token) for 2FA.
You can use a very fine console program called "pass" and its "otp"
extension. It uses gpg to encypt your keys. You an also use git to
share your enrypted keys
accross different machines.
E.g. on Debian one would install package pass-extension-otp for this.

> > And with his permission, I'm asking community members for opinions
> > that which tool share we use instead.
> >
>
> Although of course I want Waldek to participate in the FriCAS group
> but it seems strange to me if Waldek is the only user experiencing
> this problem. Perhaps it can be resolved just by accessing the group
> in a different way, i.e. by email.
>
> > To quote Waldek's opinion:
> >
> >  > ATM I am not sure what is better.  One possiblity is to
> >  > set up our own mail server.  I could do this on the
> >  > same machine as wiki.  Of course we could use GitHub
> >  > mail.  However, it is not clear what folks on the list
> >  > want.  For me old plain e-mail is preferable and also
> >  > I would like sensible publicaly visible archive.
> >
> > Personally I prefer GitHub.  Waldek replies with:
> >
> >  > Well, GitHub web interface mangles code which is IMO serious problem.
> >  > That is why I wrote "sensible publicaly visible archive", AFAICS
> >  > GitHub does not qualify as "sensible" here.
> >
> > But I think GitHub uses markdown, and  code block should solve it.
> >
>
> GitHub would be fine with me if this is really necessary. But I think
> it is also very common to use GitHub with the 2-factor authentication
> option (at least I do) in which case a cell phone will usually also be
> involved.

No, no need for a phone for 2FA, see above.

HTH
Dima


>
> > So, members of fricas community, let your opinions be heard,
> > and hopefully a satisfying decision will be made based on that.
> >
>
> Thank you for your effort to resolve the problem!
>
> > - Best,
> > - 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/25f37615-32ea-1ca5-5204-83a81ee3e0b2%40gmail.com.
>
> You can notice above the postscript that Google Groups adds when
> sending group postings by email. I never use the link to "view this
> discussion on the web".
>
> Regards,
> Bill Page.
>
> --
> 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/CAC6x94RPA%2BB9ML_SWCt6gtyDrw0HAi0rnEp-fVqTbkhrj1QaZg%40mail.gmail.com.

-- 
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/CAAWYfq3yoh%2BLd3sBUN0R_42HLS1AzCdM_fQ6pHeWui4RMfQa-Q%40mail.gmail.com.

Re: [fricas-devel] future community collaboration tool (deprecating fricas-devel maillist)

[Dima Pasechnik]

On Mon, 25 Apr 2022, 04:48 Qian Yun,  wrote:

> Hello everyone on fricas-devel:
>
> You may have noticed that Waldek has not posted on fricas-devel
> for a while now.  He has replied to GitHub issues in the mean
> time however.
>
> So I asked him privately via email, and he replied that he can't
> reply/receive to fricas-devel, because Google wants cell number.
>

one can use Google Groups without a Google account, using an email, or a
web interface.



> And with his permission, I'm asking community members for opinions
> that which tool share we use instead.
>
> To quote Waldek's opinion:
>
>  > ATM I am not sure what is better.  One possiblity is to
>  > set up our own mail server.  I could do this on the
>  > same machine as wiki.


please don't. This is much work nowadays to keep it running smoothly, and
it needs a central archive, too.

Of course we could use GitHub
>  > mail.  However, it is not clear what folks on the list
>  > want.  For me old plain e-mail is preferable and also
>  > I would like sensible publicaly visible archive.
>
> Personally I prefer GitHub.  Waldek replies with:
>
>  > Well, GitHub web interface mangles code which is IMO serious problem.
>  > That is why I wrote "sensible publicaly visible archive", AFAICS
>  > GitHub does not qualify as "sensible" here.
>
> But I think GitHub uses markdown, and  code block should solve it.
>

indeed, GitHub's Discussions are good, and allow all the formatting allowed
in its Issues.


https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/about-discussions


> So, members of fricas community, let your opinions be heard,
> and hopefully a satisfying decision will be made based on that.
>
> - Best,
> - 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/25f37615-32ea-1ca5-5204-83a81ee3e0b2%40gmail.com
> .
>

-- 
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/CAAWYfq2P2ETwhwHpa6ODF-5a8pNZgcZnU5uPT2WaHQNLOqTf4w%40mail.gmail.com.

Re: [fricas-devel] hyperdoc fonts

[Dima Pasechnik]

On Fri, 22 Apr 2022, 17:28 Ralf Hemmecke,  wrote:

> In Xubuntu 22.04 I see
>
> (HyperDoc) Cannot load font
> -adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1 ; using defaul.
>
> Any hint of what debian package I should install?
>

xfonts-100dpi-transcoded
or

xfonts-100dpi


>
> Ralf
>
> --
> 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/05fb2678-7792-95b5-0a86-df62958e5788%40hemmecke.org
> .
>

-- 
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/CAAWYfq2UVZpXMB1As0i8b_8ZcjdF3uOjO4J3s_7cpsntaVzj3Q%40mail.gmail.com.

Re: [fricas-devel] cause of faster Fricas 1.3.7 compared to 1.3.6 using integrate command.

[Dima Pasechnik]

On Thu, Jul 8, 2021 at 6:06 AM 'Nasser M. Abbasi' via FriCAS -
computer algebra system  wrote:
>
> I noticed that Fricas 1.3.7 intergate (called via sagemath 9.3), is more than 
> twice as fast in the independent CAS integration test than integrate in 1.3.6 
> (via sagemath 9.0), all on the same PC. Using Linux on a VBox with same 
> memory.
>
> I do not know if this speed up came from improvement in the sagemath to 
> Fricas interface, or improvement in Fricas 1.3.7 integration code itself or 
> some other parts of Fricas.

On top of possible Fricas code improvements,
since Sage 9.0, ECL, the Lisp compiler used to build Fricas got
updated. This might be a reason,
as well as options used to build the software (e.g. in Sage 9.3 more
capabilities of your CPU might be used).


>
> Any one noticed this also and could may shed some light on this?  And why is 
> it much faster now? I was just wondering what the cause could be. (It is 
> ofcourse, very good that integrate command is much faster now).
>
> I am sure it will be even faster, if I run Fricas directly on Linux, without 
> using sagemath interface, but I do not know how to do this, and it is easier 
> to run it via sagemath so far.

You can start Sage shell in terminal by running

sage -sh

and then you can start Fricas:

$ ./sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/mnt/opt/Sage/sage-dev
(sage-sh) dima@hilbert:sage-dev$ fri
fribidi  fricas
(sage-sh) dima@hilbert:sage-dev$ fricas
;;; Loading #P"/usr/lib64/ecl-21.2.1/cmp.fas"
Starting interpsys
spad = "/mnt/opt/Sage/sage-dev/local/lib/fricas/target/x86_64-pc-linux-gnu"
   Re-reading compress.daase   Re-reading interp.daase
   FriCAS initialization: interpreter
   FriCAS initialization: database
   FriCAS initialization: constructors
   FriCAS initialization: history
   FriCAS Computer Algebra System
Version: FriCAS 1.3.7
   Timestamp: Wed Jul  7 09:55:44 BST 2021
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading browse.daase
   Re-reading category.daase
Initial getdatabase
   preloading 
/mnt/opt/Sage/sage-dev/local/lib/fricas/target/x86_64-pc-linux-gnu/algebra/FR.fas..loaded.
...
...
   preloading 
/mnt/opt/Sage/sage-dev/local/lib/fricas/target/x86_64-pc-linux-gnu/algebra/OUTFORM.fas..loaded.

before fricas-restart
openServer result 0
   FriCAS Computer Algebra System
Version: FriCAS 1.3.7
   Timestamp: Wed Jul  7 09:55:44 BST 2021
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-


(1) ->

>
> This is the current version information for Fricas I am using
>
> >fricas
> Checking for foreign routines
> FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"
> spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"
> foreign routines found
> openServer result 0
> FriCAS Computer Algebra System
> Version: FriCAS 1.3.7
>
> with 1.3.6, average time to do an integral was 2.84 seconds. With 1.3.7 it is 
> now 1.38 seconds.
>
> --
> 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/96af17be-3162-4568-b805-2d241b6dd75cn%40googlegroups.com.

-- 
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/CAAWYfq2Rd0vno6O8H%2Bzbj%3D9_AkEehy47Q6P_xiRr9pe6H9NJNQ%40mail.gmail.com.

Re: [fricas-devel] FriCAS banner

[Dima Pasechnik]

Imagine you just want the result of the computation by a fricas script.

Then you'll want to suppress the banner.

On Fri, 30 Apr 2021, 15:06 Ralf Hemmecke,  wrote:

> On 30.04.21 15:32, Grégory Vanuxem wrote:
> > A quick question, is there a way to suppress the banner at startup?
>
> Looking at
>
> https://github.com/fricas/fricas/blob/master/src/interp/util.lisp#L279
>
> with my limited lisp knowledge tells me that you would have to convince
>
>   (format t "Checking for foreign routines~%")
>
> not to write into your terminal.
>
> Maybe there should be a commandline switch -nobanner to suppress the
> banner.
>
> May I ask you why do you need that?
>
> Ralf
>
> --
> 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/001225d0-9b27-b519-d0b7-a9ed9defad97%40hemmecke.org
> .
>

-- 
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/CAAWYfq03hPRV87uqG7XNenNy7C-0WUYjFJ40CXdxD_MAmJdU_Q%40mail.gmail.com.

Re: [fricas-devel] INSTALL

[Dima Pasechnik]

there is
https://github.com/fricas/fricas/pull/45 - not sure whether this is
what one discusses here.

Needless to say, 99% of people would read INSTALL in the browser,
keeping it plaintext in 2021 is
out of touch with the reality.


On Mon, Apr 19, 2021 at 7:33 AM Ralf Hemmecke  wrote:
>
> > After more careful look at 'install.rst' I think that for now we
> > should go with plain text version.  Namely, unlike README,
> > .rst version looks significantly worse than plain text version.
>
> What do you mean by "worse"?
> That you have to write verbose inline stuff inside ``...``?
> That verbose code has to be put indented after a :: ?
> That different title lines have to be followed by some underlining?
>
> That is basically all of the markup I used.
>
> What you basically say is, that my conversion was work-done-for-nothing.
>
> My concern is now that you change the current INSTALL file.
> Synchronization with my install.rst will be hard since I restructured a
> bit. Are you afraid of writing .rst stuff or do you think that my
> install.rst is not nicely readable as plain text? I definitely want
> install.rst on the web and showing a plain text file on an otherwise
> sphinx-generated site would look very unprofessional.
>
> Can we make a compromise that you modify install.rst content-wise and I
> add/correct the respective rst markup?
>
> Ralf
>
> --
> 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/18c57d99-083d-6276-b9fe-3ef5b8f189ef%40hemmecke.org.

-- 
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/CAAWYfq3SASc1O%3Dhw9PM6rfK0%2BXK7JDcOOz%3D%2B5S%2BA_npVkXOwvw%40mail.gmail.com.

Re: [fricas-devel] Airy, Bessel and hypergeometric functions

[Dima Pasechnik]

On Tue, Apr 13, 2021 at 6:36 PM Tobias Neumann  wrote:
>>
>> There is Closure CL, AFAIK it works fine. I do not know how
>> many FriCAS users buid it on top of Closure CL, but it is
>> quite good Lisp implementation. One higlight is precise
>> garbage collector: with sbcl (and probably ecl too) it can

ECL is using the well-known Boehm–Demers–Weiser GC - which is very
widely used, and is  rather robust and fast, it's multithreaded etc -
if used correctly.

In SageMath (which embeds ECL to run Maxima, FriCAS, etc) we rarely notice
any ECL's GC problems.

>> happen that there is free memory but garbage collector can
>> not reclaim it and consequently one get "out of memory"
>> error. In practice when one get "out of memory" erorr
>> it is hard to tell exactly what is the reason. Theoretically
>> Closure CL should behave better in this case.
>
>
> The precise garbage collection sounds good indeed.
> I recently tried FriCAS compiled with Clozure CL to compare SBCL/ECL/CCL 
> performance,
> but for me it started failing with some very basic things:
>
>  test := 1.1
>>> System error:
>The value NIL is not of the expected type CCL::UVECTOR.
>
> --
> 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/7576ed80-58ec-4d1c-aab9-7ad713eb1300n%40googlegroups.com.

-- 
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/CAAWYfq0thvq72ywciMcdhans-1537kCmDZsLYgY61NU8m7yHrQ%40mail.gmail.com.

Re: [fricas-devel] Re: HyperDoc and API

[Dima Pasechnik]

On Wed, Mar 24, 2021 at 9:50 AM Ralf Hemmecke  wrote:
>
> Tobias sent a link via IRC. Seems that MathJax3 will bring quite some
> progress.
>
> https://www.intmath.com/cg5/katex-mathjax-comparison.php?processor=MathJax3

it looks as if katex loads faster, but runs slower

MathJax can be installed locally, and then the question of slow
loading is largerly gone.

>
> Ralf
>
> --
> 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/78e82015-76ae-ca2d-b54e-f00ada3358e1%40hemmecke.de.

-- 
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/CAAWYfq08wGckN5AKFjOswYfBe2SS56eFSa8_DOeamKH8e_M7zQ%40mail.gmail.com.

Re: [fricas-devel] Re: HyperDoc and API

[Dima Pasechnik]

On Wed, Mar 24, 2021 at 4:14 AM Kurt Pagani  wrote:
>
> I'm gatecrashing the party as I have unfortunately missed most of the latest
> conversation. I had a discussion with Ralf recently and we agree that the
> current X11 graphics ought to be enough for illustrative purposes (it also 
> works
> in jfricas and one can - in principle - include the graphics with ease into 
> the
> notebook as described in the **deprecated** doc draft:
>   https://nilqed.github.io/jfricas.pip/sphinx/_build/html/usage.html#draw
>
> Since "graphics" is not may favourite subject either, enthusiasm has to be
> fueled. Nevertheless I have been trying out various approaches with the
> objective of "publication quality figures" in mind. I'd summarize the current
> situation as follows:
>
> - X11 draw works fine (but some people find it ugly)
> - Bill's gnuDraw (works, requires gnuplot)
> - Martin's Scene Graph (works, sophisticated)
>   (https://www.euclideanspace.com/prog/scratchpad/mycode/graph/index.htm)
> - Sixel graphics (requires xterm or similar sixel capable terminal (few) +
>   non-X gnuplot. I like it.
>
> Since (AFAIK) there is no graphics library for CL, I see no alternative other
> than resorting to an external tool - nobody will write a lib from scratch ;)

there is no graphics in CL standard, but you certainly have plenty of
choices to pick
CL bindings to various graphics libraries
https://www.cliki.net/graphics%20library

> There a hundreds (maybe exaggerated) of such plotting libraries written in JS,
> Java, Python etc. and some few written in C/C++. To narrow down the search it
> should be at least BSD licensed, mature and provide pub quality:
>
> Asymptote is LGPL, so not first choice.
> https://en.wikipedia.org/wiki/Asymptote_(vector_graphics_language)
>
> PGF/Tikz is GPL or LaTeX PPL
> https://en.wikipedia.org/wiki/PGF/TikZ
> The top-level PGF and TikZ commands are invoked as TeX macros, but in contrast
> with PSTricks, the PGF/TikZ graphics themselves are described in a language 
> that
> resembles MetaPost. This would be my second choice.
>
> GLE - my favourite, BSD with a QT frontend lic. LGPL
> https://en.wikipedia.org/wiki/Graphics_Layout_Engine
>
> GLE satisfies all requirements.
> https://glx.sourceforge.io/
> https://glx.sourceforge.io/examples/index.html
>
> It's essentially a command line tool which can produce a lot of formats e.g.
> EPS, PS, PDF, JPEG, and PNG. The frontend (QGLE) is relatively new, yet very
> handy in that one can manipulate the sources on the fly with automated update 
> of
> what you see ...
>
> kfp@euler:~$ gle --help
> GLE version 4.2.5
> Usage: gle [options] filename.gle
> More information: gle -help
>
> Options:
>  -help   Shows help about command line options
>  -info   Outputs software version, build date, GLE_TOP, GLE_BIN, etc.
>  -verbosity  Sets the verbosity level of GLE console output
>  -device Selects output device(s)
>  -cairo  Use cairo output device
>  -resolution Sets the resolution for bitmap and PDF output
>  -fullpage   Selects full page output
>  -landscape  Selects full page landscape output
>  -output Specifies the name of the output file
>  -nosave Don't write output file to disk (dry-run)
>  -previewPreviews the output with QGLE
>  -versionSelects a GLE version to run
>  -compatibility  Selects a GLE compatibility mode
>  -calc   Runs GLE in "calculator" mode
>  -catcsv Pretty print a CSV file to standard output
>  -texIndicates that the script includes LaTeX expressions
>  -incCreates an .inc file with LaTeX code
>  -texincprefix   Adds the given subdirectory to the path in the .inc file
>  -mkinittex  Creates "inittex.ini" from "init.tex"
>  -finddeps   Automatically finds dependencies
>  -nocolorForces grayscale output
>  -inverseRender black as white for using on dark backgrounds
>  -transparentCreates transparent output (with -d png)
>  -noctrl-d   Excludes CTRL-D from the PostScript output
>  -nomaxpath  Disables the upper-bound on the drawing path complexity
>  -noligaturesDisable the use of ligatures for 'fl' and 'fi'
>  -gsoptions  Specify additional options for GhostScript
>  -safemode   Disables reading/writing to the file system
>  -allowread  Allows reading from the given path
>  -allowwrite Allows writing to the given path
>  -keep   Don't delete temporary files
>
> Show expert options: -help expert
> Give more help about a given option: -help option
>
> ---
>
> For the sake of completeness I mention that we (Ralf and me) tried Gnuplot 5+
> (http://www.gnuplot.info/) - the new HTML canvas) and matplotlib
> (https://matplotlib.org/). The results can be seen in the attached
> ipysh_and_mplot.html and in the **deprecated**
> https://nilqed.github.io/jfricas.pip/sphinx/_build/html/gnuplot.html. These
> seems to me, however, not a long-term perspective because 

Re: [fricas-devel] Re: HyperDoc and API

[Dima Pasechnik]

On Mon, Mar 22, 2021 at 11:12 PM Waldek Hebisch
 wrote:
>
> On Mon, Mar 22, 2021 at 09:56:27PM +, Dima Pasechnik wrote:
> > On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch  
> > wrote:
> > >
> > > On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote:
> > > > > Our graphics routines can create Postscript.
> > > >
> > > > I actually thought so, but never looked deeper to find out how this can
> > > > be done.
> > >
> > > Click PS button in graphics menu.  Draw has options giving output
> > > format.  To avoid explicit options in drawing commands we would
> > > have to include Postscript in default output format.  Crude
> > > way is to modify .spad file defining default.  I am not sure
> > > if there is nicer way.  When generationg .pht files HyperDoc
> > > sends some inital setup commands, it would be natural to
> > > change output format there.
> > >
> > > > > ATM you need access to X server for this, but you also need access
> > > > > to X server to create .xpm, so this really is not extra requirement.
> > > >
> > > > Hmmm... in fact, I don't know what .xpm is really used for other than
> > > > being converted into .ps. Maybe HyperDoc pics it up, but I never looked
> > > > at what HyperDoc wants.
> > >
> > > Well, 'draw' sends data to C side.  This is used for display.
> > > When you store image C program save requested data formats
> > > (which in case of viewport includes .data which is essentially
> > > copy of data sent from FRICASsys to C side).  However, when
> > > you clik on image in HyperDoc, then viewer uses .xpm (presumably
> > > the idea was to save time needed to render data).
> >
> > I don't know who would code such things in C in 2021, though. This is
> > 25 years too late.
>
> People implementing new hot languages?

E.g. Common Lisp, yes, very new and hot. :-)

Or send stuff to plot to gnuplot (that's what Maxima does)



> At some place you need
> to call OS or existing libraries and currently portable
> interface is in C (C++ is much more problematic to interface).
>
> And "code in C" is only partly accurate: for real work you need
> to call library function which is close to 1 line of code
> (replicated in few places as we have few similar but not
> identical binaries).  You need few more lines to decide if
> call is required.  Rest is configure/Makefile to make sure
> program links to the library.
>
> Real work is to find right place to put library call and the
> few other lines.  That does not differ much from work
> needed in any other language, except for fact that
> some people like C and would code in C things better done
> in other languages, other hate C do not want to touch it
> even when it makes sense.
>
> BTW: There are folks who are not satisfied with mainstream
> GUI toolkits and code new substantial things in C (both
> alternative toolkits and applications based on them).
>
> BTW2: It would be nice to have some GUI capabilites in Spad.
> However, I feel that it is wiser to put my effort in other
> tasks.
>
> > >
> > > BTW1: 2D Postscript output ATM is black and white.  So
> > > you may prefer .xpm due to color.  OTOH, .xpm is just pixel
> > > data, so Web-friendly convertion would go to .png
> >
> > Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at 
> > all,
> > as they are raster image/bitmap formats.
> > And it is ideologically closer to postscript images, also very small in 
> > size.
>
> Well, if you start with .xpm then converting it to .svg have
> limited sense...  And Postscript produced from .xpm is not
> better than .png.  IIRC 'scene' (that I mention below) can
> produce .svg
>
> > > BTW3: 'scene' framework can generate other formats, but it
> > > is not clear how to connect it to 'draw' so that the
> > > whole thing operate as a whole (ATM you need completely
> > > different commands to get output from 'scene' framework).
>
> --
>   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/20210322231215.GB7130%40math.uni.wroc.pl.

-- 
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/CAAWYfq3hZv36RTM%3Dy86se3wOE2g0Tb85wi0ih%2BNAO8ASJ%2BuJQA%40mail.gmail.com.

Re: [fricas-devel] Re: HyperDoc and API

[Dima Pasechnik]

On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch  wrote:
>
> On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote:
> > > Our graphics routines can create Postscript.
> >
> > I actually thought so, but never looked deeper to find out how this can
> > be done.
>
> Click PS button in graphics menu.  Draw has options giving output
> format.  To avoid explicit options in drawing commands we would
> have to include Postscript in default output format.  Crude
> way is to modify .spad file defining default.  I am not sure
> if there is nicer way.  When generationg .pht files HyperDoc
> sends some inital setup commands, it would be natural to
> change output format there.
>
> > > ATM you need access to X server for this, but you also need access
> > > to X server to create .xpm, so this really is not extra requirement.
> >
> > Hmmm... in fact, I don't know what .xpm is really used for other than
> > being converted into .ps. Maybe HyperDoc pics it up, but I never looked
> > at what HyperDoc wants.
>
> Well, 'draw' sends data to C side.  This is used for display.
> When you store image C program save requested data formats
> (which in case of viewport includes .data which is essentially
> copy of data sent from FRICASsys to C side).  However, when
> you clik on image in HyperDoc, then viewer uses .xpm (presumably
> the idea was to save time needed to render data).

I don't know who would code such things in C in 2021, though. This is
25 years too late.
>
> BTW1: 2D Postscript output ATM is black and white.  So
> you may prefer .xpm due to color.  OTOH, .xpm is just pixel
> data, so Web-friendly convertion would go to .png

Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at all,
as they are raster image/bitmap formats.
And it is ideologically closer to postscript images, also very small in size.


>
> BTW2: Long ago I was thinking about replacing use of .xpm
> by .png.  However, to my surprize compressed .xpm was
> smaller than corresponding .png.  So with .png our
> compressed tarball would be slightly bigger.  So it looked
> that .png gave us no advantage and I did not look how
> much effort would be needed to generate .png
>
> BTW3: 'scene' framework can generate other formats, but it
> is not clear how to connect it to 'draw' so that the
> whole thing operate as a whole (ATM you need completely
> different commands to get output from 'scene' framework).
>
> --
>   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/20210322214330.GA7130%40math.uni.wroc.pl.

-- 
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/CAAWYfq0VG1Nqu7s9iAMdOrV7oD9BtPG-L7cGx-uDNBrg2Wzy0A%40mail.gmail.com.

Re: [fricas-devel] Re: changes to allow macOS packaging work again

[Dima Pasechnik]

wow,

https://www.xquartz.org/ just had a (pre)release, first in 5 years.

I thought it is just gone.




On Fri, 19 Mar 2021, 14:37 Waldek Hebisch,  wrote:

> On Fri, Mar 19, 2021 at 02:22:10PM +0000, Dima Pasechnik wrote:
> > On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch 
> wrote:
> > >
> > > On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote:
> > > > This is all the changes I need in order to get a working
> > > > macOS dmg package.
> > >
> > > Just asking: apparently you replace "xterm" by "Terminal.app",
> > > what is the reason?
> >
> > macOS typically has no X11 nowdays, thus no xterm.
>
> AFAIK X11 was an optional component which could be installed.
> I we want it installed for graphics and HyperDoc.
>
> --
>   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/20210319143752.GB32840%40math.uni.wroc.pl
> .
>

-- 
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/CAAWYfq0zqwkN%2BtxtG7Fdaj7fmXn3d2mj902OUAYLVayNFB5v%2BQ%40mail.gmail.com.

Re: [fricas-devel] Re: changes to allow macOS packaging work again

[Dima Pasechnik]

On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch  wrote:
>
> On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote:
> > This is all the changes I need in order to get a working
> > macOS dmg package.
>
> Just asking: apparently you replace "xterm" by "Terminal.app",
> what is the reason?

macOS typically has no X11 nowdays, thus no xterm.

>
> --
>   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/20210319142118.GA32840%40math.uni.wroc.pl.

-- 
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/CAAWYfq0DuLuv7CS-bbtS6Re4jqZh_-8JXJob-D%3DFyHxPqbK9tA%40mail.gmail.com.

Re: [fricas-devel] A radical idea for a (future) FriCAS GUI

[Dima Pasechnik]

On Fri, Mar 19, 2021 at 11:02 AM Qian Yun  wrote:
>
> Recently there is news about the release of Flutter 2.0, and Ubuntu
> using it to build the future Ubuntu installer.
>
> I'm a little interested in it and take a deeper look.
>
> Short introduction, "Flutter is Google’s UI toolkit for building
> beautiful, natively compiled applications for mobile, web, and
> desktop from a single codebase."
>
> It is based on the Dart language.  Frankly speaking, I like it somewhat.
> Some of its language features are similar to SPAD, I would say.
> Strong static typing with type deduction, its "abstract class" is a bit
> like our "Category".  It fits to my taste much better than JS.
>
> About Flutter, its design philosophy appeals to me as well.
> The underlying operating systems only provide a canvas and
> Flutter provides all the widgets to do the rendering.

I'd stay away from Google's offerings, given how often they break/remove their
stuff, etc (it probably also has a big Google "platform" bias, too).

I'd choose something like elm (https://elm-lang.org/) instead. Yes, it
compiles to JS
and runs in a browser, but that's a plus, not a minus. Messing around
with a gazillion
different windowing enviroments is better left to other projects.

Or just conentrate on jupyter kernel for fricas, and showing docs there.

>
> I'd say I would prefer to use Flutter than Qt (C++ or Python/JS binding)
> to build the replacement of HyperDoc.  Maybe I can make up my
> mind and get a working demo before the end of this year (or next year),
> for Linux/Windows/macOS/Web/Android/iOS.
>
> - 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/f526fcf6-48b4-926d-a487-dbae1901ea1b%40gmail.com.

-- 
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/CAAWYfq03dG5zj8x2mv1SVqq4wi0nksUAro_mxUNSCxqBCnq4dg%40mail.gmail.com.

Re: [fricas-devel] Re: INSTALL.CYGWIN

[Dima Pasechnik]

On Thu, 11 Mar 2021, 03:16 Qian Yun,  wrote:

> Thanks for everyone's reply, I'll give Cygwin another try.
>
> I don't have much experience of Common Lisp on Windows, so
> please correct me if I'm wrong or missed something.
>
> Current status:
>
> Clisp : can't save core with ":executable t".  Seems Maxima
> on Windows uses with ":executable nil" though.
>
> SBCL: SBCL actually runs in Cygwin, but it uses windows style
> path like "c:\sbcl" and doesn't recognize Cygwin style path like
> "/cygdrive/c/sbcl", which is confusing for me and unable to
> compile FriCAS.
>
> ECL: easy to compile ecl from source.  Don't know why upstream
> doesn't provide binaries or why Cygwin doesn't include it.
> Currently I'm building FriCAS with it, but compile time is
> much longer than SBCL on msys2/mingw64.  It took me 70 minutes
> on a 8 core windows VM, over 10 times longer than SBCL.
>

part of the slowdown you see is due to Cygwin slowness (compared to native
Windows or Linux), as it does POSIX emulation, part due to ECL doing a
2-stage compilation (to C first, with the resulting C code compiled by gcc).



> The compile process is smooth, and result binary can run
> HyperDoc without problems.
>
> ==
>
> Have not tried other lisps yet.
>
> I didn't try to build docs or graphic example files, so I
> decide to remove relevant sections in doc.
>
> - 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/657a301b-338a-cc6f-f95f-b3e6a1fe7699%40gmail.com
> .
>

-- 
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/CAAWYfq0YeZqW4C44b45PwqsbedV99122ajz9zjiT6gL9Z39QxA%40mail.gmail.com.

Re: [fricas-devel] INSTALL.CYGWIN

[Dima Pasechnik]

On Wed, Mar 10, 2021 at 4:09 PM Qian Yun  wrote:
>
> I was trying to make INSTALL.CYGWIN up to date.
>
> One serious problem occurs:
>
> The cygwin version of clisp contains a patch from March 2015
> that says "Don't allow saving executable memory images on Cygwin".
>
> Don't know why cygwin developer choose to apply this,
> but it effectively makes building FriCAS on Cygwin more
> difficult.
>
> The problem is, shall we still support Cygwin at all?
>
> (Clearly, no one have built FriCAS successful on Cygwin
> with Clisp for the past 6 years.)
>
> Advantages:
>
> 1. Cygwin can have HyperDoc with X11.
> 2. Clisp is packaged by Cygwin.  But this advantage is gone now.
>
> Disadvantages:
>
> 1. Clisp on Cygwin is slow, and not have a release for years.
> 2. Cygwin is not as portable as msys2/mingw64.
>
>
> So, if we choose to support Cygwin, we may need to use ecl, ccl,
> or a unmodified clisp.

ecl is actively developed, and works on Cygwin (as well as on "native" Windows)

>
> - 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/8765c74e-7b93-b05d-4b76-73e869d653dd%40gmail.com.

-- 
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/CAAWYfq0nAnX%2BYVJMH8j8BB6FOeu-UWtGW9SDm8KHDUoFTryDxg%40mail.gmail.com.

Re: [fricas-devel] Symbolics.jl "A Modern Computer Algebra System for a Modern Language"

[Dima Pasechnik]

On Mon, Mar 8, 2021 at 8:40 PM Neven Sajko  wrote:
>
> Regarding arrays and lists in Julia: the Array type is like C arrays in that 
> it is backed by contiguous storage in memory, and like std::vector from C++ 
> in that it can be dynamically resized.
>
> Linked lists, on the other hand, are implemented in some third party modules.
>
> BTW., Julia is a quite interesting language from some perspectives: it's 
> translated into machine code by LLVM, making tight loops very fast; but on 
> the other hand Julia also takes some aspects from Lisp, a Julia program can 
> transform it's own syntax tree, see here: 
> https://docs.julialang.org/en/v1/manual/metaprogramming/
>
> Also, Julia is unlike, e.g., Python in that Julia codebases are largely 
> written in pure Julia. I think this speaks in its favor.
>
> Regarding Symbolics.jl, it seems like something that will probably just 
> contribute to fragmentation of effort, but still, Julia seems like it could 
> be a nice language to have an excellent CAS in.

there is a largish project, Oscar,  in development for the past 6
year, which is basically an "algebraic" CAS in
Julia, with interfaces to GAP, SIngular,  Flint, etc
https://oscar.computeralgebra.de/

>
> Regards,
> Neven
>
> --
> 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/CAL%2BbK4P2quDQj1X3rCOARnvXQWK1f8h6AjpB_h7%2BGEMGPEqSkQ%40mail.gmail.com.

-- 
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/CAAWYfq1ngn%3DoSvMAKd-BZzQ9WzHwjcgNodUTbHRx1PVBELDC5w%40mail.gmail.com.

Re: [fricas-devel] Symbolics.jl "A Modern Computer Algebra System for a Modern Language"

[Dima Pasechnik]

On Sun, Mar 7, 2021 at 5:20 AM Qian Yun  wrote:
>
> I saw this post [1] reaches #1 at hackernews [2], so I take a deeper look.
>
> Disclaimer: I didn't run the code, but I read all the docs, which
> is very short, and grep through some of the source code.

A much more serious Julia-based CAS effort is https://oscar.computeralgebra.de/
- although IIRC they don't do symbolic integration, and not even plan,
at least in the immediate future.
It's algbera/group theory/number theory, and that's what keeps
nowadays several developers
of GAP, Singular and Flint busy.

>
> First, I'm very glad that there are multiple mentions of FriCAS
> in the comments. That shows there are more people know about FriCAS.
> Sadly, there are not much deeper discussion about FriCAS, and seems
> there is also very small interest of FriCAS from Symbolics.jl
> developers.
>
> Second, about the source code.  I looked into the repos of Symbolics.jl
> and SymbolicUtils.jl, which has 2500 and 3000 lines of code, and
> less that 800 commits combined. I'm surprised by their bold PR claims.
> (Maybe we should publicize more, but not like this.)
> This is their own list of missing features (missing polynomials and
> calculus!):
> https://github.com/JuliaSymbolics/Symbolics.jl/issues/59
>
> Third, I looked into the type system.  There are very few types.
> It's like a thin layer of types glued over sympy/maxima.
> It uses rules (pattern matching) heavily, and plans to use RUBI
> to solve integrals.  Which I consider is similar to mathematica
> and a step back from FriCAS's algorithmic/strong-type approach.
>
> Finally, a thing has puzzled me for a very long time.  It seems
> that there is not a linked list type/data structure.  It's unthinkable
> that a language doesn't have this type, its library doesn't use
> this type.  Maybe Julia is hyper focused on numeric computation
> and uses vector extensively, but to build a CAS without linked
> list is impossible.
>
> [1]
> https://discourse.julialang.org/t/ann-symbolics-jl-a-modern-computer-algebra-system-for-a-modern-language/56251
>
> [2] https://news.ycombinator.com/item?id=26356854
>
> --
> 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/126e5c1b-400c-ea1b-7750-36406d7ca48e%40gmail.com.

-- 
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/CAAWYfq2aphwigYq%3Dq7na2ROfO1Uw216xfyL5yRb%2BCpq4CERboA%40mail.gmail.com.

Re: [fricas-devel] [windows] no sman on msys2/mingw64

[Dima Pasechnik]

On Thu, Mar 4, 2021 at 4:26 PM Qian Yun  wrote:
>
> Wait a second, there are numerous packages on msys2/mingw64
> that uses fork and pty, how does that happen?
Could you point at any such package, with an URL?

you probably mix it up with cygwin (which does support fork() etc)

>
> On 3/4/21 11:51 PM, Waldek Hebisch wrote:
> > On Thu, Mar 04, 2021 at 06:53:52PM +0800, Qian Yun wrote:
> >> On msys2/mingw64, there is no sman, because there is no fork.
> >
> > Real problem is pty-s, we depend on them to get output from
> > FRICASsys.
> >
> >> So, first, we should tweak 'fricas' script a little so that
> >> it can work out of box when 'sman' is not presented.
> >
> > Yes, we could do this.  OTOH this is really install time
> > thing, we probaby should install different version of
> > 'fricas' (or none at all).  AFAICS currently 'fricas'
> > on Windows buys nothing compared to just using
> > FRICASsys.
> >
>
> --
> 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/96de2689-efa0-ee03-1ad7-0f06341c78ff%40gmail.com.

-- 
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/CAAWYfq2bjFScSHzqwgYiaDuCVaJ5BZMZ5pS67dufYoaNZjJ%3D7Q%40mail.gmail.com.

Re: [fricas-devel] autoconf and AM_MAINTAINER_MODE

[Dima Pasechnik]

What is your reason for not using AM_MAINTAINER_MODE macro?

all the reasoning against it is hopelessly outdated, and just irregular for
projects using git.

On Thu, 4 Mar 2021, 15:45 Ralf Hemmecke,  wrote:

> I actually never saw this, but anyhow.
>
> I would actually like that generated files like configure do not live in
> the source repository, because these are no primary sources. Since
> opinions may differ on this view, I accept it in the repo.
>
> That reduces the number of tools needed to build FriCAS by a few items
> (autotools), but otherwise the FriCAS source code repo is intended to be
> compiled on the users site. Since we explicitly distribute configure, it
> should never be build on a users site (except for us developers and we
> certainly know how to regenerate it).
>
> Your issue can easily be worked around in the CI action script by adding
> a "touch configure". However, your issue might also apply for an
> ordinary user who cloned the repo and wants to build FriCAS.
>
> I would not like to introduce a "AM_MAINTAINER_MODE" dependency.
>
> Simply adding the line "touch configure" to the documentation "How to
> build FriCAS" should do. I am not sure whether I would generally like to
> add some code so that "./configure && make" never tries to rebuild the
> "configure" script.
>
> Ralf
>
>
> On 04.03.21 16:23, Qian Yun wrote:
> > I found this problem during windows CI:
> >
> > When you clone from a git repo, configure.ac can be newer
> > than configure, thus "make" will try to run "autoconf"
> > to update it.
> >
> > I found this not very nice.
> >
> > I found 2 ways to improve this:
> >
> > 1. manually "touch configure" before everything.
> > 2. use "AM_MAINTAINER_MODE".
> >
> > What's your opinion?
> >
> > - 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/7074d46c-c34d-9b65-85d2-138b2a0bbf70%40hemmecke.org
> .
>

-- 
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/CAAWYfq3FcKB5AVCVLYCfmpn_brC_tKQhNoK0TP%2BzXcU84r%3DD8A%40mail.gmail.com.

Re: [fricas-devel] [windows] about obey.bat

[Dima Pasechnik]

On Thu, Mar 4, 2021 at 10:37 AM Qian Yun  wrote:
>
> I don't know the history of obey.bat, or if it ever worked.
>
> My current hack is:
>
>  #+:win32 (sb-ext::process-exit-code
> - (sb-ext::run-program (make-absolute-filename "/lib/obey.bat")
> -(list S) :input t :output t :error t))
> + (sb-ext::run-program "C:/msys64/usr/bin/sh.exe"
> +(list "-c" S) :input t :output t :error t))
>
>
> This works for msys2/mingw64 at least.
>
> Not familiar with SBCL on windows, I wonder if there are better ways
> to achieve this.  (Because here I hard coded msys2 default path.)
>
> Now, what about cygwin?  Shall we try to make it able to compile
> trunk version as well?  Or are we satisfied with the status quo?

I am under impression that on Cygwin Sagemath can build FriCAS (using ECL).

>
> - 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/2b65c70e-f085-ebc1-f0c2-84d18deb2751%40gmail.com.

-- 
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/CAAWYfq1xjZLAKCmUYxnTSN9C7bchxmFiDbpgxOwyfB_G01C_QQ%40mail.gmail.com.

Re: [fricas-devel] slow factorization in finite field

[Dima Pasechnik]

On Mon, Feb 22, 2021 at 1:00 PM Grégory Vanuxem  wrote:
>
> Hi Waldek, all,
>
> If that matters, I know that Victor Shoup maintains a set of
> benchmarks that compares NTL vs Flint. He even spotted a recently
> introduced bug in Flint via his set (fixed since). If you want here is
> a link of some of his results : https://libntl.org/benchmarks.pdf.

flint nowadays does  multivariate polynomial operations (no Groebner
bases though), something
what NTL does not do at all.

>
> Cheers,
>
>
> Le sam. 20 févr. 2021 à 17:47, Waldek Hebisch
>  a écrit :
> >
> > On Wed, Oct 21, 2020 at 11:47:19PM +0200, Waldek Hebisch wrote:
> > > On Tue, Oct 20, 2020 at 08:50:27PM +0200, Waldek Hebisch wrote:
> > > > On Tue, Oct 20, 2020 at 02:40:32PM +0200, Ralf Hemmecke wrote:
> > > > > Hello,
> > > > >
> > > > > The attached file is code comes from the problem of creating  the
> > > > > algebraic closure of PrimeField(p) by dynamically extending with a 
> > > > > field
> > > > > with a new polynomial that does not completely factor. It basically
> > > > > works, but when I tried with the polynomials over GF(43) I realized 
> > > > > very
> > > > > long running times.
> > > > >
> > > > > The following maps this to FiniteField(43,84) (the splitting field of
> > > > > the 3 polynomials
> > > > >
> > > > > p3 := x^3 - 29
> > > > > p5 := x^5 - 29
> > > > > p7 := x^7 - 29
> > > > >
> > > > > When I factor them on my lapto I get:
> > > > >
> > > > > Time: 8.57 (EV) + 0.00 (OT) = 8.57 sec
> > > > > Time: 23.81 (EV) + 0.00 (OT) = 23.82 sec
> > > > > Time: 35.38 (EV) = 35.38 sec
> > > > >
> > > > > After analyzing where the time is spent I found that there is an
> > > > > exptMod(t1, (p1 quo 2)::NNI, fprod) call in ddfact.spad
> > > > > where t1 and fprod are polynomials of degree 1 and 7 (for the last 
> > > > > case)
> > > > > and (p1 quo 2)::NNI is
> > > > >
> > > > > 81343016389104495051429314429892710283748121052067002779751599748804821941
> > > > > 461709990823638183537929646810274525597886525946443695227097400
> > > > >
> > > > > Clearly, that is a huge number and the coefficients of the polynomials
> > > > > are (as elements of FF(43,84)) univariate polynomials of degree 83).
> > > > > So it is expected to take a while.
> > > > >
> > > > > However, I did the same computation with Magma in a fraction of a
> > > > > second. Is FriCAS so bad here? :-(
> > > >
> > > > One possible way is to create variant of FiniteField
> > > > which uses U32Vector as representation.  To say how
> > > > much speedup one would get one needs to implement it
> > > > and measure.
> > >
> > > I have implemented toy domain like this (just operations
> > > needed for test above).  On my machine it runs 3 times
> > > faster with default build.  With sbcl at highest
> > > optimization level it runs 4 times faster.  There
> > > is significant room for easy improvement as polynomial
> > > remainder U32VectorPolynomialOperations is rather slow.
> >
> > Just little more about possible speed.  I tried toy
> > problem as a benchmark:
> >
> > pF := PrimeField(nextPrime(10^7)) -- 1019
> > uP := UnivariatePolynomial(x, pF)
> > pol := reduce(*, [x - (20 + 5*i)::pF for i in 1..84])
> >
> > On my computer (rather slow one) I get the following times
> > (in seconds):
> >
> > regular FriCAS factor   1.03
> > mfractor from MODFACT   0.018
> > flint   0.009
> > NTL 0.038
> >
> > Note: it is possible that I am using NTL incorrectly.  Namely,
> > NTL have a type for machine sized integers modulo prime, but
> > ATM I found no way to use polynomials of machine sized integers
> > modulo prime.  Also, for the test I compiled critical FriCAS
> > routines at safety 0 (most of the time extra safety checks
> > are cheap, but in low level code involved here they make
> > significant difference).
> >
> > As you can see there is possibility for 50 times speedup and
> > that brings us within factor of 2 to flint and is better than
> > my current NTL result.
> >
> > Concerning your original problem, degree 3 case in flint
> > took 0.08s, and in NTL about 1.2s.  Current regular FriCAS
> > factorizer needs 15.88s on my machine.  AFAICS using
> > similar methods like in MODFACT it should be possible
> > to have speed within factor 2-4 to flint.  Let me add
> > that there are other possiblities for faster arithmetic
> > over finite fields, but my impression is that flint
> > does not use them: basically it seems that flint
> > advantage is mainly due to better machine optimization
> > in gcc compared to sbcl.
> >
> > Looking again at the problem it is not clear what is the
> > intent.  Is the intent to benchmark finite field factorizer?
> > Then the example is somewhat atypical because polynomials
> > split into linear factors.  If the intend is to embed
> > smaller field into bigger one, then there are better
> > methods.  For example, factorizer spends some thime to
> > find out that polynomials split, this can be skipped
> > if 

Re: [fricas-devel] CI failure, missing src/input/fftst.input

[Dima Pasechnik]

On Tue, Feb 2, 2021 at 12:24 AM Waldek Hebisch  wrote:
>
> On Fri, Jan 29, 2021 at 07:03:35PM +0800, oldk1331 wrote:
> > Hi Waldek,
> >
> > The reason that your commit didn't trigger CI is that, you didn't verify
> > your github's linked email.
> >
> > If you are doing this for privacy or other reasons, I fully understand.  If
> > not, would you mind to verify your github's email?
>
> Yes privacy.  Various services love to track users and I do not want
> to help them in this.

it is not about tracking. Everybody knows your email, cf e.g.
https://github.com/fricas/fricas/commit/10cbce6925a9b6329fab4e617a1c4b9a0e852203
or http://math.uni.wroc.pl/users/hebisch

They merely want a confirmation that you read it. The test is designed
for the cases where people do not want to give a working email
address.

Dima



>
> --
>   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/20210202002414.GA3461%40math.uni.wroc.pl.

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

Re: [fricas-devel] the issue of %iint generated by Fricas

[Dima Pasechnik]

we can fix Sage interface only if we know what %iint stands for. Is it
a kind of polylogarithm?

On Sat, Jan 9, 2021 at 10:22 AM oldk1331  wrote:
>
> Hi, my thoughts are:
>
> 1. Maybe Sage should be able to automatically escape '%' in its 'latex'
> command.
>
> When using FriCAS to generate latex, it returns '\%' directly.
>
> 2. As Waldek said, '%iint" should be used only internally.  But the
> following workaround prints '%iint' as 'iint':
>
> diff --git a/src/algebra/liouv.spad b/src/algebra/liouv.spad
> index 420845b9..c070ca28 100644
> --- a/src/algebra/liouv.spad
> +++ b/src/algebra/liouv.spad
> @@ -221,6 +221,7 @@
>  derivative(opli2, (z1 : F) : F +-> log(z1) / (1 - z1))
>  derivative(opfis, (z1 : F) : F +-> sin(pi()*z1^2/(2::F)))
>  derivative(opfic, (z1 : F) : F +-> cos(pi()*z1^2/(2::F)))
> +display(opiint, (z1 : List O) : O +-> prefix('iint::O, z1))
>  setProperty(opint, SPECIALEQUAL, eqint@((K, K) -> Boolean) pretend
> None)
>  setProperty(opint, SPECIALDIFF, dvint@((List F, SE) -> F) pretend None)
>  setProperty(opiint, SPECIALDIFF, dviint@((List F, SE) -> F) pretend
> None)
>
>
> On 1/9/21 5:11 AM, 'Nasser M. Abbasi' via FriCAS - computer algebra
> system wrote:
> > Hello. I use sagemath to call fricas integrate as part of build the
> > independent CAS integration tests.
> >
> > I am not running the tests using sagemath 9.2 against Fricas 1.3.6
> >
> > There are antiderivatives generated by Fricas which uses %iint.
> >
> > This cause a problem when converted to Latex for the report.
> >
> > Here is a bug report on this against sagemath
> >
> > https://ask.sagemath.org/question/48409/possible-invalid-latex-translation-from-fricas-result/
> >
> > https://trac.sagemath.org/ticket/28630
> >
> > But not fixed yet and do not know when it will be fixed.
> >
> > Is it possible that fricas not use %iint as that causes problem
> > converting to Latex.
> >
> > Here is an example
> >
> > sage: x,a,b,n=var('x a b n')
> > sage: integrate(x^2*(a+b*log(c*x^n))*polylog(3,e*x),x, algorithm="fricas")
> > -1/972*(4*(4*b*n - 3*a)*x^3*e^3 + 9*(3*b*n - 2*a)*x^2*e^2 + 36*(2*b*n -
> > a)*x*e + 36*(3*b*n*x^3*e^3*log(x) + 3*b*x^3*e^3*log(c) - (2*b*n -
> > 3*a)*x^3*e^3 - b*n)*%iint(x, -log(-x*e + 1)/x) - 36*((b*n - a)*x^3*e^3 -
> > b*n + a)*log(-x*e + 1) - 6*(2*b*x^3*e^3 + 3*b*x^2*e^2 + 6*b*x*e -
> > 6*(b*x^3*e^3 - b)*log(-x*e + 1))*log(c) - 6*(2*b*n*x^3*e^3 +
> > 3*b*n*x^2*e^2 + 6*b*n*x*e - 6*(b*n*x^3*e^3 - b*n)*log(-x*e + 1))*log(x)
> > - 108*(3*b*n*x^3*e^3*log(x) + 3*b*x^3*e^3*log(c) - (b*n -
> > 3*a)*x^3*e^3)*polylog(3, x*e))*e^(-3)
> >
> > After converting to Latex it gives (using sagemath latex command)
> >
> > -\frac{4 \, {\left(4 \, b e^{3} n - 3 \, a e^{3}\right)} x^{3} + 9 \,
> > {\left(3 \, b e^{2} n - 2 \, a e^{2}\right)} x^{2} + 36 \, {\left(2 \, b
> > e n - a e\right)} x + 36 \, {\left(3 \, b e^{3} n x^{3}
> > \log\left(x\right) + 3 \, b e^{3} x^{3} \log\left(c\right) - {\left(2 \,
> > b e^{3} n - 3 \, a e^{3}\right)} x^{3} - b n\right)} {\rm %iint}\left(e,
> > x, -\frac{\log\left(-e x + 1\right)}{e}, -\frac{\log\left(-e x +
> > 1\right)}{x}\right) - 36 \, {\left({\left(b e^{3} n - a e^{3}\right)}
> > x^{3} - b n + a\right)} \log\left(-e x + 1\right) - 6 \, {\left(2 \, b
> > e^{3} x^{3} + 3 \, b e^{2} x^{2} + 6 \, b e x - 6 \, {\left(b e^{3}
> > x^{3} - b\right)} \log\left(-e x + 1\right)\right)} \log\left(c\right) -
> > 6 \, {\left(2 \, b e^{3} n x^{3} + 3 \, b e^{2} n x^{2} + 6 \, b e n x -
> > 6 \, {\left(b e^{3} n x^{3} - b n\right)} \log\left(-e x +
> > 1\right)\right)} \log\left(x\right) - 108 \, {\left(3 \, b e^{3} n x^{3}
> > \log\left(x\right) + 3 \, b e^{3} x^{3} \log\left(c\right) - {\left(b
> > e^{3} n - 3 \, a e^{3}\right)} x^{3}\right)} {\rm polylog}\left(3, e
> > x\right)}{972 \, e^{3}}
> >
> > And the above do not compile due to %iint, as % is treated as comment
> > and all the latex after that is lost giving latex error.
> >
> > Is there a way for FriCAS not to use %  in the output it generates?
> > Each time I have to edit the latex by hand and add \% everywhere they show
> >
> > May be this is not possible, But I thought to just ask.
> >
> > Thanks
> > --Nasser
>
> --
> 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/2266c422-5328-3c65-44f1-437fe7b22bca%40gmail.com.

-- 
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