Re: [sage-devel] problem building maxima

[François Bissey]

It looks like maxima.fas has not been built. Last time I saw that happen
in sage-on-gentoo was because the patch to build it was missing.
Not sure how it could happen on your setup, the log needs further inspection.

> On 14/05/2021, at 21:18, John Cremona  wrote:
> 
> I have been installing sage-9.3 from the tarball on a few ubuntu
> machines, just doing ./configure and then make.  On one machine
> running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> the log files.
> 
> This is a machine on which I tried a few weeks ago to help the build
> process by installing as many of the dependencies as possible.  My
> experience so far has been that this has caused so many things to go
> wrong that I prefer the old way -- build everything -- since that just
> takes more computer time, while the new way (so far) uses a lot more
> of my time.
> 
> John
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAD0p0K7VWKz7ActzBjT9FZdW_yo3bkK99bSDEWd0n-zWkQsyNw%40mail.gmail.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7DE9A1AD-82F1-4058-B34A-A02C00E6950D%40gmail.com.

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

On Fri, May 14, 2021 at 11:53 AM Dima Pasechnik  wrote:
>
> On Fri, May 14, 2021 at 11:21 AM Jan Groenewald  wrote:
> >
> > Hi
> >
> > On Fri, 14 May 2021 at 11:26, François Bissey  wrote:
> >>
> >> It looks like maxima.fas has not been built. Last time I saw that happen
> >> in sage-on-gentoo was because the patch to build it was missing.
> >> Not sure how it could happen on your setup, the log needs further 
> >> inspection.
> >>
> >> > On 14/05/2021, at 21:18, John Cremona  wrote:
> >> >
> >> > I have been installing sage-9.3 from the tarball on a few ubuntu
> >> > machines, just doing ./configure and then make.  On one machine
> >> > running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> >> > the log files.
> >> >
> >> > This is a machine on which I tried a few weeks ago to help the build
> >> > process by installing as many of the dependencies as possible.  My
> >> > experience so far has been that this has caused so many things to go
> >> > wrong that I prefer the old way -- build everything -- since that just
> >> > takes more computer time, while the new way (so far) uses a lot more
> >> > of my time.
> >
> >
> > config.log:
> > ## Checking whether SageMath should install SPKG libffi... ##
> > ## --- ##
> > configure:24887: checking for LIBFFI
> > configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
> > configure:24897: $? = 0
> > configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
> > configure:24914: $? = 0
> > configure:25100: result: yes
> > configure:25108: will use system package and not install SPKG libffi
> >
> > maxima log:
> > Condition of type: SIMPLE-ERROR
> > Error code 1 when executing
> > (EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas" 
> > "-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit8GQbdq.o" 
> > "binary-ecl/maxima-package.o" 
> > "-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared" 
> > "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
> > "-L/usr/local/sage/sage-9.3/local/lib" 
> > "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" 
> > "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
> > "-L/usr/local/sage/sage-9.3/local/lib" 
> > "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc" 
> > ...)):
> > /usr/bin/ld: cannot find -lffi
> > collect2: error: ld returned 1 exit status
> > Available restarts:
> >
> > 1. (CONTINUE) Continues anyway.
> > 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
> >
> > Broken at DO-COMPILE-ECL.
> >  File: 
> > #P"/usr/local/sage/sage-9.3/local/var/tmp/sage/build/maxima-5.44.0/src/src/maxima.system"
> >  (Position #1601)
> >
> >
> >
> > Do you perhaps need to sudo apt install libffi-dev?
>
>
> One way I can explain this is a broken system-wide install of libffi-dev
> I don't know how this can be achieved, other than having multiple
> system-wide copies of libffi,
> or stuff manually removed.
>
> The other possibility is that the linker is told not to look for
> system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
>
> On the other hand, it's a bug in maxima, which does not try to check
> for presense of libffi, just assumes it's there.

oops, I meant to say, it's a bug in ECL, as this failing call to gcc
is emitted by ECL.


>
>
> > It is listed as a dependency here: 
> > https://doc.sagemath.org/html/en/installation/source.html
> >
> > (also see https://bugzilla.redhat.com/show_bug.cgi?id=837102 from 2012)
> >
> > Regards,
> > Jan
> >
> > --
> >   .~.
> >   /V\ Jan Groenewald
> >  /( )\www.aims.ac.za
> >  ^^-^^
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sage-devel/CAAg%3Dp_33NMuyuZ_zQn8%2B3oQjDhR%3DCAMAcausjD7TYoi_x9EoXQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq269jhMDPq%3DSweNKAWB9eyxjh0bbh39tdHdpE3hoiLJoA%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

On Fri, May 14, 2021 at 12:17 PM Jan Groenewald  wrote:
>
> Hi
>
> On Fri, 14 May 2021 at 13:12, Dima Pasechnik  wrote:
>>
>> On Fri, May 14, 2021 at 11:53 AM Dima Pasechnik  wrote:
>> >
>> > On Fri, May 14, 2021 at 11:21 AM Jan Groenewald  wrote:
>> > >
>> > > Hi
>> > >
>> > > On Fri, 14 May 2021 at 11:26, François Bissey  
>> > > wrote:
>> > >>
>> > >> It looks like maxima.fas has not been built. Last time I saw that happen
>> > >> in sage-on-gentoo was because the patch to build it was missing.
>> > >> Not sure how it could happen on your setup, the log needs further 
>> > >> inspection.
>> > >>
>> > >> > On 14/05/2021, at 21:18, John Cremona  wrote:
>> > >> >
>> > >> > I have been installing sage-9.3 from the tarball on a few ubuntu
>> > >> > machines, just doing ./configure and then make.  On one machine
>> > >> > running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
>> > >> > the log files.
>> > >> >
>> > >> > This is a machine on which I tried a few weeks ago to help the build
>> > >> > process by installing as many of the dependencies as possible.  My
>> > >> > experience so far has been that this has caused so many things to go
>> > >> > wrong that I prefer the old way -- build everything -- since that just
>> > >> > takes more computer time, while the new way (so far) uses a lot more
>> > >> > of my time.
>> > >
>> > >
>> > > config.log:
>> > > ## Checking whether SageMath should install SPKG libffi... ##
>> > > ## --- ##
>> > > configure:24887: checking for LIBFFI
>> > > configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
>> > > configure:24897: $? = 0
>> > > configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
>> > > configure:24914: $? = 0
>> > > configure:25100: result: yes
>> > > configure:25108: will use system package and not install SPKG libffi
>> > >
>> > > maxima log:
>> > > Condition of type: SIMPLE-ERROR
>> > > Error code 1 when executing
>> > > (EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas" 
>> > > "-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit8GQbdq.o" 
>> > > "binary-ecl/maxima-package.o" 
>> > > "-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared" 
>> > > "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
>> > > "-L/usr/local/sage/sage-9.3/local/lib" 
>> > > "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" 
>> > > "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
>> > > "-L/usr/local/sage/sage-9.3/local/lib" 
>> > > "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc" 
>> > > ...)):
>> > > /usr/bin/ld: cannot find -lffi
>> > > collect2: error: ld returned 1 exit status
>> > > Available restarts:
>> > >
>> > > 1. (CONTINUE) Continues anyway.
>> > > 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
>> > >
>> > > Broken at DO-COMPILE-ECL.
>> > >  File: 
>> > > #P"/usr/local/sage/sage-9.3/local/var/tmp/sage/build/maxima-5.44.0/src/src/maxima.system"
>> > >  (Position #1601)
>> > >
>> > >
>> > >
>> > > Do you perhaps need to sudo apt install libffi-dev?
>> >
>> >
>> > One way I can explain this is a broken system-wide install of libffi-dev
>> > I don't know how this can be achieved, other than having multiple
>> > system-wide copies of libffi,
>> > or stuff manually removed.
>> >
>> > The other possibility is that the linker is told not to look for
>> > system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
>> >
>> > On the other hand, it's a bug in maxima, which does not try to check
>> > for presense of libffi, just assumes it's there.
>>
>> oops, I meant to say, it's a bug in ECL, as this failing call to gcc
>> is emitted by ECL.
>
>
> Why did SageMath say this? Was it checking for runtime libffi or headers?

it's checking with pkg-config first of all.
see build/pkgs/libffi/spkg-configure.m4

If this test succeeds, it's assumed everything is fine.
Note that libffi is a pre-req for ECL, and ECL is built just fine,
as far as one can see.

I gather it must be a bug in ECL, which struggles to create a correct
incantation of C compiler calls
from a unique (Copyright JEC 2021 :-)) concostion of gmp built by Sage
and libffi provided by the system.

ECL checks for libffi carefully in its configure, as far as I know.


John, can you post logs/pkgs/ecl-21.2.1.log ?





>
> config.log:
> ## Checking whether SageMath should install SPKG libffi... ##
> ## --- ##
> configure:24887: checking for LIBFFI
> configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
> configure:24897: $? = 0
> configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
> configure:24914: $? = 0
> configure:25100: result: yes
> configure:25108: will use system package and not install SPKG libffi
>
> Regards,
> Jan
> --
>   .~.
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from 

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

Thanks. Indeed, libffi is alive and well:

...
checking for ffi_closure_alloc in -lffi... yes
checking ffi/ffi.h usability... no
checking ffi/ffi.h presence... no
checking for ffi/ffi.h... no
checking ffi.h usability... yes
checking ffi.h presence... yes
checking for ffi.h... yes
checking whether we can use the existing libffi library ... yes
...

;;;   gcc -o libecl.so
-L/usr/local/sage/sage-9.3/local/var/tmp/sage/build/ecl-21.2.1/src/build/
c/main.o c/all_symbols2.o liblsp.a libeclmin.a
-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/ -shared
-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib
-L/usr/local/sage/sage-9.3/local/lib
-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib
-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib
-L/usr/local/sage/sage-9.3/local/lib
-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib
-Wl,-soname,libecl.so.21.2 -lgmp -lgc -lffi -lgc -ldl -lm

Comparing with the failed call

Error code 1 when executing
(EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas"
"-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit0kBo2G.o"
"binary-ecl/maxima-package.o"
"-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared"
"-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" "-L/usr
/local/sage/sage-9.3/local/lib"
"-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib"
"-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib"
"-L/usr/local/sage/sage-9.3/local/lib"
"-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc"
...)):
/usr/bin/ld: cannot find -lffi

does not seem to reveal anything interesting.

On Fri, May 14, 2021 at 1:46 PM John Cremona  wrote:
>
> Here is the ECL log.
>
> John
>
> On Fri, 14 May 2021 at 13:20, Michael Orlitzky  wrote:
> >
> > On Fri, 2021-05-14 at 12:12 +0100, Dima Pasechnik wrote:
> > > >
> > > > The other possibility is that the linker is told not to look for
> > > > system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
> > > >
> > > > On the other hand, it's a bug in maxima, which does not try to check
> > > > for presense of libffi, just assumes it's there.
> > >
> > > oops, I meant to say, it's a bug in ECL, as this failing call to gcc
> > > is emitted by ECL.
> > >
> >
> > I ran into a problem recently that sounds relevant:
> >
> >   https://sourceforge.net/p/maxima/bugs/3759/
> >
> > I wonder how hard it would be at this point to teach Sage to use the
> > system copy of Maxima. That will be the long-term solution anyway.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sage-devel/e53fd6c259f8bd2284938c2627f8902c07af455e.camel%40orlitzky.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAD0p0K5B2t%3DLiwJ0j%2Bm_RtrTyy%2BNvpD414ACYkOrNr3dxk7qww%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0YkNC4aPkqHaUui%2BYzG1aDNVoFYou%3DWu7Vr3uWG98xVg%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

On Fri, May 14, 2021 at 11:21 AM Jan Groenewald  wrote:
>
> Hi
>
> On Fri, 14 May 2021 at 11:26, François Bissey  wrote:
>>
>> It looks like maxima.fas has not been built. Last time I saw that happen
>> in sage-on-gentoo was because the patch to build it was missing.
>> Not sure how it could happen on your setup, the log needs further inspection.
>>
>> > On 14/05/2021, at 21:18, John Cremona  wrote:
>> >
>> > I have been installing sage-9.3 from the tarball on a few ubuntu
>> > machines, just doing ./configure and then make.  On one machine
>> > running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
>> > the log files.
>> >
>> > This is a machine on which I tried a few weeks ago to help the build
>> > process by installing as many of the dependencies as possible.  My
>> > experience so far has been that this has caused so many things to go
>> > wrong that I prefer the old way -- build everything -- since that just
>> > takes more computer time, while the new way (so far) uses a lot more
>> > of my time.
>
>
> config.log:
> ## Checking whether SageMath should install SPKG libffi... ##
> ## --- ##
> configure:24887: checking for LIBFFI
> configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
> configure:24897: $? = 0
> configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
> configure:24914: $? = 0
> configure:25100: result: yes
> configure:25108: will use system package and not install SPKG libffi
>
> maxima log:
> Condition of type: SIMPLE-ERROR
> Error code 1 when executing
> (EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas" 
> "-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit8GQbdq.o" 
> "binary-ecl/maxima-package.o" 
> "-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared" 
> "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
> "-L/usr/local/sage/sage-9.3/local/lib" 
> "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" 
> "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib" 
> "-L/usr/local/sage/sage-9.3/local/lib" 
> "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc" ...)):
> /usr/bin/ld: cannot find -lffi
> collect2: error: ld returned 1 exit status
> Available restarts:
>
> 1. (CONTINUE) Continues anyway.
> 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
>
> Broken at DO-COMPILE-ECL.
>  File: 
> #P"/usr/local/sage/sage-9.3/local/var/tmp/sage/build/maxima-5.44.0/src/src/maxima.system"
>  (Position #1601)
>
>
>
> Do you perhaps need to sudo apt install libffi-dev?


One way I can explain this is a broken system-wide install of libffi-dev
I don't know how this can be achieved, other than having multiple
system-wide copies of libffi,
or stuff manually removed.

The other possibility is that the linker is told not to look for
system-wide libffi - can this be achieved with -L and -Wl,-rpath ?

On the other hand, it's a bug in maxima, which does not try to check
for presense of libffi, just assumes it's there.


> It is listed as a dependency here: 
> https://doc.sagemath.org/html/en/installation/source.html
>
> (also see https://bugzilla.redhat.com/show_bug.cgi?id=837102 from 2012)
>
> Regards,
> Jan
>
> --
>   .~.
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAg%3Dp_33NMuyuZ_zQn8%2B3oQjDhR%3DCAMAcausjD7TYoi_x9EoXQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2gFHukombrSGYFc61uLPXyyDM-SoSYdUrx-KuGA%2BeD7w%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

On Fri, May 14, 2021 at 1:20 PM Michael Orlitzky  wrote:
>
> On Fri, 2021-05-14 at 12:12 +0100, Dima Pasechnik wrote:
> > >
> > > The other possibility is that the linker is told not to look for
> > > system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
> > >
> > > On the other hand, it's a bug in maxima, which does not try to check
> > > for presense of libffi, just assumes it's there.
> >
> > oops, I meant to say, it's a bug in ECL, as this failing call to gcc
> > is emitted by ECL.
> >
>
> I ran into a problem recently that sounds relevant:
>
>   https://sourceforge.net/p/maxima/bugs/3759/
>
the ECL issue mentioned there sounds relevant:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/636 - I've left
a comment there.


> I wonder how hard it would be at this point to teach Sage to use the
> system copy of Maxima. That will be the long-term solution anyway.

Well, we know from the system ECL trac ticket that it's not going to
be very easy.

>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/e53fd6c259f8bd2284938c2627f8902c07af455e.camel%40orlitzky.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0HXO4KMPgr6y_GNfg-HCXtcGeJq2hnDS%3DxEJy83GwfPQ%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Jan Groenewald]

Hi

On Fri, 14 May 2021 at 11:26, François Bissey  wrote:

> It looks like maxima.fas has not been built. Last time I saw that happen
> in sage-on-gentoo was because the patch to build it was missing.
> Not sure how it could happen on your setup, the log needs further
> inspection.
>
> > On 14/05/2021, at 21:18, John Cremona  wrote:
> >
> > I have been installing sage-9.3 from the tarball on a few ubuntu
> > machines, just doing ./configure and then make.  On one machine
> > running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> > the log files.
> >
> > This is a machine on which I tried a few weeks ago to help the build
> > process by installing as many of the dependencies as possible.  My
> > experience so far has been that this has caused so many things to go
> > wrong that I prefer the old way -- build everything -- since that just
> > takes more computer time, while the new way (so far) uses a lot more
> > of my time.
>

config.log:
## Checking whether SageMath should install SPKG libffi... ##
## --- ##
configure:24887: checking for LIBFFI
configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
configure:24897: $? = 0
configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
configure:24914: $? = 0
configure:25100: result: yes
*configure:25108: will use system package and not install SPKG libffi*

maxima log:
Condition of type: SIMPLE-ERROR
Error code 1 when executing
(EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas"
"-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit8GQbdq.o"
"binary-ecl/maxima-package.o"
"-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared"
"-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib"
"-L/usr/local/sage/sage-9.3/local/lib"
"-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib"
"-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib"
"-L/usr/local/sage/sage-9.3/local/lib"
"-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc"
...)):
*/usr/bin/ld: cannot find -lffi*
collect2: error: ld returned 1 exit status
Available restarts:

1. (CONTINUE) Continues anyway.
2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at DO-COMPILE-ECL.
 File:
#P"/usr/local/sage/sage-9.3/local/var/tmp/sage/build/maxima-5.44.0/src/src/maxima.system"
(Position #1601)



Do you perhaps need to sudo apt install libffi-dev?
It is listed as a dependency here:
https://doc.sagemath.org/html/en/installation/source.html

(also see https://bugzilla.redhat.com/show_bug.cgi?id=837102 from 2012)

Regards,
Jan

-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAg%3Dp_33NMuyuZ_zQn8%2B3oQjDhR%3DCAMAcausjD7TYoi_x9EoXQ%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Jan Groenewald]

Hi

On Fri, 14 May 2021 at 13:12, Dima Pasechnik  wrote:

> On Fri, May 14, 2021 at 11:53 AM Dima Pasechnik  wrote:
> >
> > On Fri, May 14, 2021 at 11:21 AM Jan Groenewald  wrote:
> > >
> > > Hi
> > >
> > > On Fri, 14 May 2021 at 11:26, François Bissey 
> wrote:
> > >>
> > >> It looks like maxima.fas has not been built. Last time I saw that
> happen
> > >> in sage-on-gentoo was because the patch to build it was missing.
> > >> Not sure how it could happen on your setup, the log needs further
> inspection.
> > >>
> > >> > On 14/05/2021, at 21:18, John Cremona 
> wrote:
> > >> >
> > >> > I have been installing sage-9.3 from the tarball on a few ubuntu
> > >> > machines, just doing ./configure and then make.  On one machine
> > >> > running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> > >> > the log files.
> > >> >
> > >> > This is a machine on which I tried a few weeks ago to help the build
> > >> > process by installing as many of the dependencies as possible.  My
> > >> > experience so far has been that this has caused so many things to go
> > >> > wrong that I prefer the old way -- build everything -- since that
> just
> > >> > takes more computer time, while the new way (so far) uses a lot more
> > >> > of my time.
> > >
> > >
> > > config.log:
> > > ## Checking whether SageMath should install SPKG libffi... ##
> > > ## --- ##
> > > configure:24887: checking for LIBFFI
> > > configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
> > > configure:24897: $? = 0
> > > configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
> > > configure:24914: $? = 0
> > > configure:25100: result: yes
> > > configure:25108: will use system package and not install SPKG libffi
> > >
> > > maxima log:
> > > Condition of type: SIMPLE-ERROR
> > > Error code 1 when executing
> > > (EXT:RUN-PROGRAM "gcc" ("-o" "binary-ecl/maxima-package.fas"
> "-L/usr/local/sage/sage-9.3/local/lib/" "/tmp/eclinit8GQbdq.o"
> "binary-ecl/maxima-package.o"
> "-Wl,--rpath,/usr/local/sage/sage-9.3/local/lib/" "-shared"
> "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib"
> "-L/usr/local/sage/sage-9.3/local/lib"
> "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib"
> "-Wl,-rpath-link,/usr/local/sage/sage-9.3/local/lib"
> "-L/usr/local/sage/sage-9.3/local/lib"
> "-Wl,-rpath,/usr/local/sage/sage-9.3/local/lib" "-lecl" "-lgmp" "-lgc"
> ...)):
> > > /usr/bin/ld: cannot find -lffi
> > > collect2: error: ld returned 1 exit status
> > > Available restarts:
> > >
> > > 1. (CONTINUE) Continues anyway.
> > > 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
> > >
> > > Broken at DO-COMPILE-ECL.
> > >  File:
> #P"/usr/local/sage/sage-9.3/local/var/tmp/sage/build/maxima-5.44.0/src/src/maxima.system"
> (Position #1601)
> > >
> > >
> > >
> > > Do you perhaps need to sudo apt install libffi-dev?
> >
> >
> > One way I can explain this is a broken system-wide install of libffi-dev
> > I don't know how this can be achieved, other than having multiple
> > system-wide copies of libffi,
> > or stuff manually removed.
> >
> > The other possibility is that the linker is told not to look for
> > system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
> >
> > On the other hand, it's a bug in maxima, which does not try to check
> > for presense of libffi, just assumes it's there.
>
> oops, I meant to say, it's a bug in ECL, as this failing call to gcc
> is emitted by ECL.
>

Why did SageMath say this? Was it checking for runtime libffi or headers?

config.log:
## Checking whether SageMath should install SPKG libffi... ##
## --- ##
configure:24887: checking for LIBFFI
configure:24894: $PKG_CONFIG --exists --print-errors "libffi"
configure:24897: $? = 0
configure:24911: $PKG_CONFIG --exists --print-errors "libffi"
configure:24914: $? = 0
configure:25100: result: yes
*configure:25108: will use system package and not install SPKG libffi*

Regards,
Jan
-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAg%3Dp_3J7QyF7yTjYY3ecPz5U5uA6E2bw_iBiHYcXw4b0siBEA%40mail.gmail.com.

Re: [sage-devel] problem building maxima

[Michael Orlitzky]

On Fri, 2021-05-14 at 12:12 +0100, Dima Pasechnik wrote:
> > 
> > The other possibility is that the linker is told not to look for
> > system-wide libffi - can this be achieved with -L and -Wl,-rpath ?
> > 
> > On the other hand, it's a bug in maxima, which does not try to check
> > for presense of libffi, just assumes it's there.
> 
> oops, I meant to say, it's a bug in ECL, as this failing call to gcc
> is emitted by ECL.
> 

I ran into a problem recently that sounds relevant:

  https://sourceforge.net/p/maxima/bugs/3759/

I wonder how hard it would be at this point to teach Sage to use the
system copy of Maxima. That will be the long-term solution anyway.


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e53fd6c259f8bd2284938c2627f8902c07af455e.camel%40orlitzky.com.

Re: [sage-devel] problem building maxima

[Dima Pasechnik]

On Fri, May 14, 2021 at 10:19 AM John Cremona  wrote:
>
> I have been installing sage-9.3 from the tarball on a few ubuntu
> machines, just doing ./configure and then make.  On one machine
> running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> the log files.
>
> This is a machine on which I tried a few weeks ago to help the build
> process by installing as many of the dependencies as possible.  My
> experience so far has been that this has caused so many things to go
> wrong that I prefer the old way -- build everything -- since that just

without your feedback one cannot improve things going wrong...

> takes more computer time, while the new way (so far) uses a lot more
> of my time.

Do you have a system-wide install of ecl?
This is something that potentially might interfere.

>
> John
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAD0p0K7VWKz7ActzBjT9FZdW_yo3bkK99bSDEWd0n-zWkQsyNw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1n-dmFsQsXjFjXAuC1Zm4JGrrAZ9M4ZGxkQxUTBtVdig%40mail.gmail.com.

Re: [sage-devel] Re: test failures with buckygen (optional package)

[Dima Pasechnik]

On Fri, May 14, 2021 at 8:23 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
> 1. sage-9.3 claims that it supports Python 3.6. My system Python
> was by the way accepted by sage configure script.
>
> 2. the part of sage source code that I mentioned in my initial e-mail
> does not support Python 3.6
>
> Hence this is a bug. Did I miss something?
no, you're right, it's a bug in 9.3.
I've argued for dropping Python 3.6 for last 6 months, but
it only made it up to here https://trac.sagemath.org/ticket/30551
- it will be dropped in 9.4.

We've been going back and forth on the support of Python 3.6, which is a pain.


>
> Le 14/05/2021 à 20:21, Dima Pasechnik a écrit :
> > we are dropping Python 3.6,  it will reach eol in Dec.
> >
> > On Fri, 14 May 2021, 18:43 Vincent Delecroix, <20100.delecr...@gmail.com>
> > wrote:
> >
> >> Indeed, the method reconfigure was introduced in Python 3.7 (and I do
> >> have Python 3.6 on my system). The proper way to go is to use the
> >> codecs library.
> >>
> >> Vincent
> >>
> >> Le 14/05/2021 à 19:19, Vincent Delecroix a écrit :
> >>> Dear all,
> >>>
> >>> On sage 9.3 and buckygen installed I got a lot of test failures
> >>> in graphs/graph_generators.py of the type
> >>>
> >>> sage -t --long --random-seed=0 src/sage/graphs/graph_generators.py
> >>> **
> >>> File "src/sage/graphs/graph_generators.py", line 1233, in
> >>> sage.graphs.graph_generators.GraphGenerators.fullerenes
> >>> Failed example:
> >>>  len(list(gen))  # optional buckygen
> >>> Exception raised:
> >>>  Traceback (most recent call last):
> >>>File
> >>>
> >> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",
> >>
> >>> line 714, in _run
> >>>  self.compile_and_execute(example, compiler, test.globs)
> >>>File
> >>>
> >> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",
> >>
> >>> line 1133, in compile_and_execute
> >>>  exec(compiled, globs)
> >>>File " >>> sage.graphs.graph_generators.GraphGenerators.fullerenes[1]>", line 1, in
> >>> 
> >>>  len(list(gen))  # optional buckygen
> >>>File
> >>>
> >> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/graphs/graph_generators.py",
> >>
> >>> line 1301, in fullerenes
> >>>  sp.stdout.reconfigure(newline='')
> >>>  AttributeError: '_io.TextIOWrapper' object has no attribute
> >>> 'reconfigure'
> >>> **
> >>>
> >>> Best
> >>> Vincent
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to sage-devel+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/sage-devel/b7508205-ed86-8444-6e72-d4ae429d58e7%40gmail.com
> >> .
> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/886a0c10-b126-ddf9-04d4-ed03905113e2%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq32AP5DoVzKaF-Q1hgO9-u3tj-oUCvMShS%3DuxFuF-vDNg%40mail.gmail.com.

Re: [sage-devel] Re: Memory leak with matrices and finite fields

['Freddie Manners' via sage-devel]

Awesome, many thanks for running this down.

`sage --standard | grep gmp`
>> gmp.6.1.2 (not_installed)
`equery --quiet list gmp`
>> dev-libs/gmp-6.2.1-r1

`sage --standard | grep flint`
>> flint...2.5.2.p5 (2.5.2.p5)

So yes, that checks out, I am using system GMP 6.2 with Sage's flint 2.5.2.

Not sure if something should have complained somewhere or whatever, but I 
look forward to seeing the problem disappear at the next upgrade.

Best
Freddie
On Friday, May 14, 2021 at 8:03:13 AM UTC-7 jonatha...@googlemail.com wrote:

> I think I tracked it down.
>
> https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h
>
> In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2 
> I'm assuming this one is picked up from your system?
>
> `sage --standard | grep gmp`
>
> This code is not present yet in flint 2.5.2, which is installed from sage 
> in your case, I guess:
>
> `sage --standard | grep flint`
>
> Hopefully this should resolve itself if you update to sage 9.3 (flint 
> 2.6.3), because this flint does account for the changes made in GMP 6.2
>
> Jonathan
> Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2:
>
>> Dear all,
>>
>> Sorry for the delay getting back to you -- this was waiting in the 
>> moderation queue for a bit (me being new) and then I dropped the ball.
>>
>> > run the underlying functions
>> > 
>> > M = identity_matrix(n)
>> > L = M.list()
>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
>> sparse=False)
>> > mat = MS(L, coerce=True, copy=False)
>> > 
>> > Maybe repeatedly running the first line causes leakage already?
>>
>> It appears that the first *two* lines cause the leak, whereas the first 
>> line by itself does not.  Not sure if that narrows it down, but possibly 
>> strengthens the 31340 hypothesis below.
>>
>> > This might be a bug with flint. What flint are you using?
>>
>> To the best of my knowledge I don't have a system copy of flint, so 
>> presumably I am using whatever is bundled in sage-9.2/upstream which seems 
>> to be 2.5.2.
>>
>> > https://trac.sagemath.org/ticket/31340
>>
>> I can confirm that the original code on that trac also memory leaks for 
>> my system (31MB) so it could very plausibly be the same issue.  I have not 
>> yet read that bug in detail.
>>
>> Thanks for the feedback.
>>
>> Best
>> Freddie
>> On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com wrote:
>>
>>> we've fixed a memory leak in matrices recently (this fix will be in 
>>> 9.3), not sure if this is related 
>>> https://trac.sagemath.org/ticket/31340 
>>>
>>> On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via 
>>> sage-devel  wrote: 
>>> > 
>>> > Dear Freddie, 
>>> > 
>>> > thank you for the report. 
>>> > 
>>> > Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on 
>>> the develop branch (on ubuntu focal with libflint-2.5.2 and debian buster 
>>> with sage's flint 2.6.3). 
>>> > 
>>> > This might be a bug with flint. What flint are you using? 
>>> > 
>>> > You can go into detail, to see, what exactly is causing the problem 
>>> and instead of 
>>> > 
>>> > _ = identity_matrix(n).change_ring(GF(101)) 
>>> > 
>>> > run the underlying functions 
>>> > 
>>> > M = identity_matrix(n) 
>>> > L = M.list() 
>>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
>>> sparse=False) 
>>> > mat = MS(L, coerce=True, copy=False) 
>>> > 
>>> > Maybe repeatedly running the first line causes leakage already? 
>>> > 
>>> > Jonathan 
>>> > 
>>> > Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2: 
>>> >> 
>>> >> Dear all 
>>> >> 
>>> >> [I attempted to post this a few days ago but seemingly failed, so 
>>> this is a repost; apologies if duplicate.] 
>>> >> 
>>> >> The following program appears to consume all the memory on my 
>>> machine: 
>>> >> 
>>> >> n = 1000 
>>> >> for i in range(0, 100): 
>>> >> _ = identity_matrix(n).change_ring(GF(101)) 
>>> >> print(get_memory_usage()) 
>>> >> 
>>> >> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 
>>> 5.4.97-gentoo, gcc version 10.2.0). 
>>> >> 
>>> >> I couldn't find any related open bugs. I have worked around the issue 
>>> (solution: don't create intermediate integer matrices and then coerce them 
>>> to finite fields; obviously it's less explicit in my original code) but 
>>> either way this seems to be a new bug. 
>>> >> 
>>> >> Best 
>>> >> Freddie 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to sage-devel+...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/6fd93c63-3fad-4d20-b624-3d3208d4ec4fn%40googlegroups.com.
>>>  
>>>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" 

Re: [sage-devel] Re: Memory leak with matrices and finite fields

[Dima Pasechnik]

On Fri, May 14, 2021 at 4:03 PM 'jonatha...@googlemail.com' via
sage-devel  wrote:
>
> I think I tracked it down.
>
> https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h

this is a fork, dealing with Windows support of Flint.
We should  be working with
https://github.com/wbhart/flint2
which is the mainline of Flint.

>
> In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2 I'm 
> assuming this one is picked up from your system?
>
> `sage --standard | grep gmp`
>
> This code is not present yet in flint 2.5.2, which is installed from sage in 
> your case, I guess:
>
> `sage --standard | grep flint`
>
> Hopefully this should resolve itself if you update to sage 9.3 (flint 2.6.3), 
> because this flint does account for the changes made in GMP 6.2
>
> Jonathan
> Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2:
>>
>> Dear all,
>>
>> Sorry for the delay getting back to you -- this was waiting in the 
>> moderation queue for a bit (me being new) and then I dropped the ball.
>>
>> > run the underlying functions
>> >
>> > M = identity_matrix(n)
>> > L = M.list()
>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
>> > sparse=False)
>> > mat = MS(L, coerce=True, copy=False)
>> >
>> > Maybe repeatedly running the first line causes leakage already?
>>
>> It appears that the first *two* lines cause the leak, whereas the first line 
>> by itself does not.  Not sure if that narrows it down, but possibly 
>> strengthens the 31340 hypothesis below.
>>
>> > This might be a bug with flint. What flint are you using?
>>
>> To the best of my knowledge I don't have a system copy of flint, so 
>> presumably I am using whatever is bundled in sage-9.2/upstream which seems 
>> to be 2.5.2.
>>
>> > https://trac.sagemath.org/ticket/31340
>>
>> I can confirm that the original code on that trac also memory leaks for my 
>> system (31MB) so it could very plausibly be the same issue.  I have not yet 
>> read that bug in detail.
>>
>> Thanks for the feedback.
>>
>> Best
>> Freddie
>> On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com wrote:
>>>
>>> we've fixed a memory leak in matrices recently (this fix will be in
>>> 9.3), not sure if this is related
>>> https://trac.sagemath.org/ticket/31340
>>>
>>> On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via
>>> sage-devel  wrote:
>>> >
>>> > Dear Freddie,
>>> >
>>> > thank you for the report.
>>> >
>>> > Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on the 
>>> > develop branch (on ubuntu focal with libflint-2.5.2 and debian buster 
>>> > with sage's flint 2.6.3).
>>> >
>>> > This might be a bug with flint. What flint are you using?
>>> >
>>> > You can go into detail, to see, what exactly is causing the problem and 
>>> > instead of
>>> >
>>> > _ = identity_matrix(n).change_ring(GF(101))
>>> >
>>> > run the underlying functions
>>> >
>>> > M = identity_matrix(n)
>>> > L = M.list()
>>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
>>> > sparse=False)
>>> > mat = MS(L, coerce=True, copy=False)
>>> >
>>> > Maybe repeatedly running the first line causes leakage already?
>>> >
>>> > Jonathan
>>> >
>>> > Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2:
>>> >>
>>> >> Dear all
>>> >>
>>> >> [I attempted to post this a few days ago but seemingly failed, so this 
>>> >> is a repost; apologies if duplicate.]
>>> >>
>>> >> The following program appears to consume all the memory on my machine:
>>> >>
>>> >> n = 1000
>>> >> for i in range(0, 100):
>>> >> _ = identity_matrix(n).change_ring(GF(101))
>>> >> print(get_memory_usage())
>>> >>
>>> >> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 
>>> >> 5.4.97-gentoo, gcc version 10.2.0).
>>> >>
>>> >> I couldn't find any related open bugs. I have worked around the issue 
>>> >> (solution: don't create intermediate integer matrices and then coerce 
>>> >> them to finite fields; obviously it's less explicit in my original code) 
>>> >> but either way this seems to be a new bug.
>>> >>
>>> >> Best
>>> >> Freddie
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "sage-devel" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an 
>>> > email to sage-devel+...@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/msgid/sage-devel/6fd93c63-3fad-4d20-b624-3d3208d4ec4fn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/94fd8faa-9f94-4300-968c-2801a885528en%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe 

Re: [sage-devel] Re: test failures with buckygen (optional package)

[Matthias Koeppe]

On Friday, May 14, 2021 at 12:23:49 PM UTC-7 vdelecroix wrote:

> 1. sage-9.3 claims that it supports Python 3.6. My system Python 
> was by the way accepted by sage configure script.


It did also warn you that using system python 3.6 is deprecated.
 

> 2. the part of sage source code that I mentioned in my initial e-mail 
> does not support Python 3.6
>

Yes, this is a bug in Sage 9.3. We have no real infrastructure for 
systematically testing doctests depending on optional packages. There are 
tests on GH Actions that test that all  optional packages can be built; but 
it does not run the Sage testsuite with optional packages installed.
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ab519a2c-fd77-488e-8a3b-1082b1de7420n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak with matrices and finite fields

['Jonathan Kliem' via sage-devel]

Its the same code in the Main line. Sorry for the confusion.

I googled it and that is how I found the exact place where this is defined.

What I linked is how it looks now accounting for changes in gmp 6.2. Flint 
2.6.3 has it but not 2.5.2.On May 14, 2021 10:31 PM, Dima Pasechnik 
 wrote:
>
> On Fri, May 14, 2021 at 4:03 PM 'jonatha...@googlemail.com' via 
> sage-devel  wrote: 
> > 
> > I think I tracked it down. 
> > 
> > https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h 
>
> this is a fork, dealing with Windows support of Flint. 
> We should  be working with 
> https://github.com/wbhart/flint2 
> which is the mainline of Flint. 
>
> > 
> > In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2 
> > I'm assuming this one is picked up from your system? 
> > 
> > `sage --standard | grep gmp` 
> > 
> > This code is not present yet in flint 2.5.2, which is installed from sage 
> > in your case, I guess: 
> > 
> > `sage --standard | grep flint` 
> > 
> > Hopefully this should resolve itself if you update to sage 9.3 (flint 
> > 2.6.3), because this flint does account for the changes made in GMP 6.2 
> > 
> > Jonathan 
> > Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2: 
> >> 
> >> Dear all, 
> >> 
> >> Sorry for the delay getting back to you -- this was waiting in the 
> >> moderation queue for a bit (me being new) and then I dropped the ball. 
> >> 
> >> > run the underlying functions 
> >> > 
> >> > M = identity_matrix(n) 
> >> > L = M.list() 
> >> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
> >> > sparse=False) 
> >> > mat = MS(L, coerce=True, copy=False) 
> >> > 
> >> > Maybe repeatedly running the first line causes leakage already? 
> >> 
> >> It appears that the first *two* lines cause the leak, whereas the first 
> >> line by itself does not.  Not sure if that narrows it down, but possibly 
> >> strengthens the 31340 hypothesis below. 
> >> 
> >> > This might be a bug with flint. What flint are you using? 
> >> 
> >> To the best of my knowledge I don't have a system copy of flint, so 
> >> presumably I am using whatever is bundled in sage-9.2/upstream which seems 
> >> to be 2.5.2. 
> >> 
> >> > https://trac.sagemath.org/ticket/31340 
> >> 
> >> I can confirm that the original code on that trac also memory leaks for my 
> >> system (31MB) so it could very plausibly be the same issue.  I have not 
> >> yet read that bug in detail. 
> >> 
> >> Thanks for the feedback. 
> >> 
> >> Best 
> >> Freddie 
> >> On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com wrote: 
> >>> 
> >>> we've fixed a memory leak in matrices recently (this fix will be in 
> >>> 9.3), not sure if this is related 
> >>> https://trac.sagemath.org/ticket/31340 
> >>> 
> >>> On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via 
> >>> sage-devel  wrote: 
> >>> > 
> >>> > Dear Freddie, 
> >>> > 
> >>> > thank you for the report. 
> >>> > 
> >>> > Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on 
> >>> > the develop branch (on ubuntu focal with libflint-2.5.2 and debian 
> >>> > buster with sage's flint 2.6.3). 
> >>> > 
> >>> > This might be a bug with flint. What flint are you using? 
> >>> > 
> >>> > You can go into detail, to see, what exactly is causing the problem and 
> >>> > instead of 
> >>> > 
> >>> > _ = identity_matrix(n).change_ring(GF(101)) 
> >>> > 
> >>> > run the underlying functions 
> >>> > 
> >>> > M = identity_matrix(n) 
> >>> > L = M.list() 
> >>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
> >>> > sparse=False) 
> >>> > mat = MS(L, coerce=True, copy=False) 
> >>> > 
> >>> > Maybe repeatedly running the first line causes leakage already? 
> >>> > 
> >>> > Jonathan 
> >>> > 
> >>> > Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2: 
> >>> >> 
> >>> >> Dear all 
> >>> >> 
> >>> >> [I attempted to post this a few days ago but seemingly failed, so this 
> >>> >> is a repost; apologies if duplicate.] 
> >>> >> 
> >>> >> The following program appears to consume all the memory on my machine: 
> >>> >> 
> >>> >> n = 1000 
> >>> >> for i in range(0, 100): 
> >>> >> _ = identity_matrix(n).change_ring(GF(101)) 
> >>> >> print(get_memory_usage()) 
> >>> >> 
> >>> >> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 
> >>> >> 5.4.97-gentoo, gcc version 10.2.0). 
> >>> >> 
> >>> >> I couldn't find any related open bugs. I have worked around the issue 
> >>> >> (solution: don't create intermediate integer matrices and then coerce 
> >>> >> them to finite fields; obviously it's less explicit in my original 
> >>> >> code) but either way this seems to be a new bug. 
> >>> >> 
> >>> >> Best 
> >>> >> Freddie 
> >>> > 
> >>> > -- 
> >>> > You received this message because you are subscribed to the Google 
> >>> > Groups "sage-devel" group. 
> >>> > To unsubscribe from this group and stop receiving emails from it, send 
> >>> > an email to sage-devel+...@googlegroups.com. 

Re: [sage-devel] Re: Memory leak with matrices and finite fields

['Jonathan Kliem' via sage-devel]

Thanks Freddie for reporting this.

I'm glad it resolves so easily. Yes, that is a mistake in our 9.2 
configure. One can fix this by passing `--with-system-gmp=no` to 
configure, but it should have rejected gmp 6.2 as long as flint 2.5.2 is 
the install candidate.


So you can update sage or rebuilt (large) parts of it by reconfiguring. 
Either way the issue goes hopefully away.


Jonathan

On 14.05.21 22:05, 'Freddie Manners' via sage-devel wrote:

Awesome, many thanks for running this down.

`sage --standard | grep gmp`
>> gmp.6.1.2 (not_installed)
`equery --quiet list gmp`
>> dev-libs/gmp-6.2.1-r1

`sage --standard | grep flint`
>> flint...2.5.2.p5 (2.5.2.p5)

So yes, that checks out, I am using system GMP 6.2 with Sage's flint 
2.5.2.


Not sure if something should have complained somewhere or whatever, 
but I look forward to seeing the problem disappear at the next upgrade.


Best
Freddie
On Friday, May 14, 2021 at 8:03:13 AM UTC-7 jonatha...@googlemail.com 
wrote:


I think I tracked it down.

https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h


In there you see that `flint_mpz_set_si` is modified to work with
GMP 6.2 I'm assuming this one is picked up from your system?

`sage --standard | grep gmp`

This code is not present yet in flint 2.5.2, which is installed
from sage in your case, I guess:

`sage --standard | grep flint`

Hopefully this should resolve itself if you update to sage 9.3
(flint 2.6.3), because this flint does account for the changes
made in GMP 6.2

Jonathan
Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2:

Dear all,

Sorry for the delay getting back to you -- this was waiting in
the moderation queue for a bit (me being new) and then I
dropped the ball.

> run the underlying functions
>
> M = identity_matrix(n)
> L = M.list()
> MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000,
1000, sparse=False)
> mat = MS(L, coerce=True, copy=False)
>
> Maybe repeatedly running the first line causes leakage already?

It appears that the first *two* lines cause the leak, whereas
the first line by itself does not.  Not sure if that narrows
it down, but possibly strengthens the 31340 hypothesis below.

> This might be a bug with flint. What flint are you using?

To the best of my knowledge I don't have a system copy of
flint, so presumably I am using whatever is bundled in
sage-9.2/upstream which seems to be 2.5.2.

> https://trac.sagemath.org/ticket/31340


I can confirm that the original code on that trac also memory
leaks for my system (31MB) so it could very plausibly be the
same issue.  I have not yet read that bug in detail.

Thanks for the feedback.

Best
Freddie
On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com
wrote:

we've fixed a memory leak in matrices recently (this fix
will be in
9.3), not sure if this is related
https://trac.sagemath.org/ticket/31340


On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com'
via
sage-devel  wrote:
>
> Dear Freddie,
>
> thank you for the report.
>
> Fortunatly or unfortunately, I can't reproduce this on
sage 9.2 or on the develop branch (on ubuntu focal with
libflint-2.5.2 and debian buster with sage's flint 2.6.3).
>
> This might be a bug with flint. What flint are you using?
>
> You can go into detail, to see, what exactly is causing
the problem and instead of
>
> _ = identity_matrix(n).change_ring(GF(101))
>
> run the underlying functions
>
> M = identity_matrix(n)
> L = M.list()
> MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000,
1000, sparse=False)
> mat = MS(L, coerce=True, copy=False)
>
> Maybe repeatedly running the first line causes leakage
already?
>
> Jonathan
>
> Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um
03:02:04 UTC+2:
>>
>> Dear all
>>
>> [I attempted to post this a few days ago but seemingly
failed, so this is a repost; apologies if duplicate.]
>>
>> The following program appears to consume all the memory
on my machine:

Re: [sage-devel] Re: Minimum Python version to 3.8

['Travis Scrimshaw' via sage-devel]

Thank you for the pointer for how to add the optional marker. Adding a 
dummy spkg for when the Python version is sufficiently large feels like a 
much more invasive hack around by going into the build system. ;)

Jonathan, yes, that is how we can fix the code. The problem as I recall is 
the doctests for the code that explicitly tests the parallel code (e.g. the 
shm_managers). Perhaps those can all be avoided in the same way as a 
workaround without modifying the actual doctesting framework. This could be 
a good solution as well. I will think about it and discuss it with the 
authors.

Best,
Travis


On Friday, May 14, 2021 at 2:06:55 AM UTC+10 dim...@gmail.com wrote:

> On Thu, May 13, 2021 at 4:52 PM David Roe  wrote:
> >
> >
> >
> > On Thu, May 13, 2021 at 6:09 AM Dima Pasechnik  wrote:
> >>
> >> On Thu, May 13, 2021 at 1:34 AM 'Travis Scrimshaw' via sage-devel
> >>  wrote:
> >> >
> >> > Own tag might be a goood way forward as the code itself can run on 
> Python 3.7 by avoiding the multiprocessing. It would be purely to state 
> that we don't want to test the mp parts of the code. How do I make an 
> optional tag? I am worried that since this is not simply an optional 
> package to test but against a Python version, it would require a slightly 
> invasive change to the doctesting framework.
> >>
> >> I always thought that it's trivial:
> >>
> >> sage: bar() # optional:foo
> >>
> >> would stop bar() being tested, unless "--optional=...,foo,..."
> >> is given to ./sage -t
> >>
> >> Am I wrong?
> >
> >
> > You're right. I was just suggesting a mechanism where the python version 
> could be detected in the doctest code and you wouldn't need to include 
> "--optional=py38".
>
> As a hack we can have an optional empty package "py38", which is
> installed whenever Sage's Python is newer than python 3.7.* :-)
>
>
>
> > David
> >
> >>
> >>
> >> Dima
> >>
> >>
> >>
> >> > There also is an option of testing for a more specific import from 
> Python too.
> >> >
> >> > Best,
> >> > Travis
> >> >
> >> > On Wednesday, May 12, 2021 at 7:10:53 AM UTC+10 Volker Braun wrote:
> >> >>
> >> >> Yet another possibility is to look for a backport that implements 
> sufficient functionality for your needs for now.
> >> >>
> >> >> On Tuesday, May 11, 2021 at 2:40:04 AM UTC+2 Matthias Koeppe wrote:
> >> >>>
> >> >>> -1. Even NEP 29 (
> https://numpy.org/neps/nep-0029-deprecation_policy.html) does not drop 
> Python 3.7 support before end of the year.
> >> >>>
> >> >>>
> >> >>> On Monday, May 10, 2021 at 4:12:48 PM UTC-7 Travis Scrimshaw wrote:
> >> 
> >>  On #30423, which is getting close to completion, we will be using 
> multiprocessing.shared_memory, which is only available on Python 3.8+. 
> However, right now we are at least allowing Python 3.7 (as per the 
> patchbot). So my main proposal would be to bump the minimum required Python 
> version to 3.8, which was released Oct. 14, 2019.
> >> 
> >>  On that ticket, we can make it so that the main entry point runs 
> things in serial if the Python version is sufficiently small and that the 
> doc builds, but the doctests for the parallel code will fail. So the first 
> alternative option would be to mark certain doctests (or the file) as 
> needing a large Python version.
> >> 
> >>  A second alternative is that this can be split off as a separate 
> package (either an optional Sage package or pip installable). Yet, it is 
> somewhat tightly coupled with the FusionRing code (and root systems) in 
> Sage, so this is not so desirable. A less invasive way would be to just 
> split the parallel part off, but this would take some work to do I think.
> >> 
> >>  What do people think?
> >> 
> >>  Best,
> >>  Travis
> >> 
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-devel+...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/ae100fbf-8b77-4c9c-b92a-cde41e6d17f8n%40googlegroups.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq1z28PNZeR%3Dn5n4cNX4crBqYcNEnV9EvThH_Oa-cSiaeA%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAChs6_nt-0xWF6--k-%2BZerRn90xficz14aXU_zm3iVJ2kQwY7A%40mail.gmail.com
> .
>

-- 
You received this 

Re: [sage-devel] Re: Memory leak with matrices and finite fields

['jonatha...@googlemail.com' via sage-devel]

I think I tracked it down.

https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h

In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2 
I'm assuming this one is picked up from your system?

`sage --standard | grep gmp`

This code is not present yet in flint 2.5.2, which is installed from sage 
in your case, I guess:

`sage --standard | grep flint`

Hopefully this should resolve itself if you update to sage 9.3 (flint 
2.6.3), because this flint does account for the changes made in GMP 6.2

Jonathan
Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2:

> Dear all,
>
> Sorry for the delay getting back to you -- this was waiting in the 
> moderation queue for a bit (me being new) and then I dropped the ball.
>
> > run the underlying functions
> > 
> > M = identity_matrix(n)
> > L = M.list()
> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
> sparse=False)
> > mat = MS(L, coerce=True, copy=False)
> > 
> > Maybe repeatedly running the first line causes leakage already?
>
> It appears that the first *two* lines cause the leak, whereas the first 
> line by itself does not.  Not sure if that narrows it down, but possibly 
> strengthens the 31340 hypothesis below.
>
> > This might be a bug with flint. What flint are you using?
>
> To the best of my knowledge I don't have a system copy of flint, so 
> presumably I am using whatever is bundled in sage-9.2/upstream which seems 
> to be 2.5.2.
>
> > https://trac.sagemath.org/ticket/31340
>
> I can confirm that the original code on that trac also memory leaks for my 
> system (31MB) so it could very plausibly be the same issue.  I have not yet 
> read that bug in detail.
>
> Thanks for the feedback.
>
> Best
> Freddie
> On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com wrote:
>
>> we've fixed a memory leak in matrices recently (this fix will be in 
>> 9.3), not sure if this is related 
>> https://trac.sagemath.org/ticket/31340 
>>
>> On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via 
>> sage-devel  wrote: 
>> > 
>> > Dear Freddie, 
>> > 
>> > thank you for the report. 
>> > 
>> > Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on 
>> the develop branch (on ubuntu focal with libflint-2.5.2 and debian buster 
>> with sage's flint 2.6.3). 
>> > 
>> > This might be a bug with flint. What flint are you using? 
>> > 
>> > You can go into detail, to see, what exactly is causing the problem and 
>> instead of 
>> > 
>> > _ = identity_matrix(n).change_ring(GF(101)) 
>> > 
>> > run the underlying functions 
>> > 
>> > M = identity_matrix(n) 
>> > L = M.list() 
>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
>> sparse=False) 
>> > mat = MS(L, coerce=True, copy=False) 
>> > 
>> > Maybe repeatedly running the first line causes leakage already? 
>> > 
>> > Jonathan 
>> > 
>> > Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2: 
>> >> 
>> >> Dear all 
>> >> 
>> >> [I attempted to post this a few days ago but seemingly failed, so this 
>> is a repost; apologies if duplicate.] 
>> >> 
>> >> The following program appears to consume all the memory on my machine: 
>> >> 
>> >> n = 1000 
>> >> for i in range(0, 100): 
>> >> _ = identity_matrix(n).change_ring(GF(101)) 
>> >> print(get_memory_usage()) 
>> >> 
>> >> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 
>> 5.4.97-gentoo, gcc version 10.2.0). 
>> >> 
>> >> I couldn't find any related open bugs. I have worked around the issue 
>> (solution: don't create intermediate integer matrices and then coerce them 
>> to finite fields; obviously it's less explicit in my original code) but 
>> either way this seems to be a new bug. 
>> >> 
>> >> Best 
>> >> Freddie 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "sage-devel" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to sage-devel+...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/6fd93c63-3fad-4d20-b624-3d3208d4ec4fn%40googlegroups.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/94fd8faa-9f94-4300-968c-2801a885528en%40googlegroups.com.

Re: [sage-devel] Re: test failures with buckygen (optional package)

[Dima Pasechnik]

we are dropping Python 3.6,  it will reach eol in Dec.

On Fri, 14 May 2021, 18:43 Vincent Delecroix, <20100.delecr...@gmail.com>
wrote:

> Indeed, the method reconfigure was introduced in Python 3.7 (and I do
> have Python 3.6 on my system). The proper way to go is to use the
> codecs library.
>
> Vincent
>
> Le 14/05/2021 à 19:19, Vincent Delecroix a écrit :
> > Dear all,
> >
> > On sage 9.3 and buckygen installed I got a lot of test failures
> > in graphs/graph_generators.py of the type
> >
> > sage -t --long --random-seed=0 src/sage/graphs/graph_generators.py
> > **
> > File "src/sage/graphs/graph_generators.py", line 1233, in
> > sage.graphs.graph_generators.GraphGenerators.fullerenes
> > Failed example:
> > len(list(gen))  # optional buckygen
> > Exception raised:
> > Traceback (most recent call last):
> >   File
> >
> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",
>
> > line 714, in _run
> > self.compile_and_execute(example, compiler, test.globs)
> >   File
> >
> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",
>
> > line 1133, in compile_and_execute
> > exec(compiled, globs)
> >   File " > sage.graphs.graph_generators.GraphGenerators.fullerenes[1]>", line 1, in
> > 
> > len(list(gen))  # optional buckygen
> >   File
> >
> "/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/graphs/graph_generators.py",
>
> > line 1301, in fullerenes
> > sp.stdout.reconfigure(newline='')
> > AttributeError: '_io.TextIOWrapper' object has no attribute
> > 'reconfigure'
> > **
> >
> > Best
> > Vincent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/b7508205-ed86-8444-6e72-d4ae429d58e7%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq28O7YCa9-8VXPhPDfphkTGZrT7daGX1Gs9eT3kMNXNWw%40mail.gmail.com.

Re: [sage-devel] Re: test failures with buckygen (optional package)

[Vincent Delecroix]

1. sage-9.3 claims that it supports Python 3.6. My system Python
   was by the way accepted by sage configure script.

2. the part of sage source code that I mentioned in my initial e-mail
   does not support Python 3.6

Hence this is a bug. Did I miss something?

Le 14/05/2021 à 20:21, Dima Pasechnik a écrit :

we are dropping Python 3.6,  it will reach eol in Dec.

On Fri, 14 May 2021, 18:43 Vincent Delecroix, <20100.delecr...@gmail.com>
wrote:


Indeed, the method reconfigure was introduced in Python 3.7 (and I do
have Python 3.6 on my system). The proper way to go is to use the
codecs library.

Vincent

Le 14/05/2021 à 19:19, Vincent Delecroix a écrit :

Dear all,

On sage 9.3 and buckygen installed I got a lot of test failures
in graphs/graph_generators.py of the type

sage -t --long --random-seed=0 src/sage/graphs/graph_generators.py
**
File "src/sage/graphs/graph_generators.py", line 1233, in
sage.graphs.graph_generators.GraphGenerators.fullerenes
Failed example:
 len(list(gen))  # optional buckygen
Exception raised:
 Traceback (most recent call last):
   File


"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",


line 714, in _run
 self.compile_and_execute(example, compiler, test.globs)
   File


"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py",


line 1133, in compile_and_execute
 exec(compiled, globs)
   File "", line 1, in

 len(list(gen))  # optional buckygen
   File


"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/graphs/graph_generators.py",


line 1301, in fullerenes
 sp.stdout.reconfigure(newline='')
 AttributeError: '_io.TextIOWrapper' object has no attribute
'reconfigure'
**

Best
Vincent


--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/b7508205-ed86-8444-6e72-d4ae429d58e7%40gmail.com
.





--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/886a0c10-b126-ddf9-04d4-ed03905113e2%40gmail.com.

[sage-devel] test failures with buckygen (optional package)

[Vincent Delecroix]

Dear all,

On sage 9.3 and buckygen installed I got a lot of test failures
in graphs/graph_generators.py of the type

sage -t --long --random-seed=0 src/sage/graphs/graph_generators.py
**
File "src/sage/graphs/graph_generators.py", line 1233, in 
sage.graphs.graph_generators.GraphGenerators.fullerenes

Failed example:
len(list(gen))  # optional buckygen
Exception raised:
Traceback (most recent call last):
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py", 
line 714, in _run

self.compile_and_execute(example, compiler, test.globs)
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py", 
line 1133, in compile_and_execute

exec(compiled, globs)
  File "sage.graphs.graph_generators.GraphGenerators.fullerenes[1]>", line 1, in 


len(list(gen))  # optional buckygen
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/graphs/graph_generators.py", 
line 1301, in fullerenes

sp.stdout.reconfigure(newline='')
AttributeError: '_io.TextIOWrapper' object has no attribute 
'reconfigure'

**

Best
Vincent

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/05788001-ed47-dbd3-723f-dd286eaee46b%40gmail.com.

[sage-devel] Re: test failure in tests/cmdline.py

[Vincent Delecroix]

I can at least confirm that

- sqlite3 shell is not installed on my system

quasar:~$ sqlite3

Command 'sqlite3' not found, but can be installed with:

apt install sqlite3
Please ask your administrator.

- Python sqlite3 library is

$ python3 -c 'import sqlite3; print(sqlite3.version)'
2.6.0

Vincent

Le 14/05/2021 à 19:25, Vincent Delecroix a écrit :

Dear all,

There are 3 test failures in tests/cmdline.py that I do not quite
understand. If anybody has a clue...

sage -t --long --random-seed=0 src/sage/tests/cmdline.py
**
File "src/sage/tests/cmdline.py", line 587, in 
sage.tests.cmdline.test_executable

Failed example:
     out.startswith("3.")
Expected:
     True
Got:
     False
**
File "src/sage/tests/cmdline.py", line 589, in 
sage.tests.cmdline.test_executable

Failed example:
     err
Expected:
     ''
Got:
     '/home/vdelecro/sage_patchbot/src/bin/sage: line 668: exec: 
sqlite3: not found\n'

**
File "src/sage/tests/cmdline.py", line 591, in 
sage.tests.cmdline.test_executable

Failed example:
     ret
Expected:
     0
Got:
     127
**
1 item had failures:
    3 of 228 in sage.tests.cmdline.test_executable

Best
Vincent


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/084d4445-df51-0231-aa14-f55bb7e60e15%40gmail.com.

[sage-devel] Re: test failures with buckygen (optional package)

[Vincent Delecroix]

Indeed, the method reconfigure was introduced in Python 3.7 (and I do
have Python 3.6 on my system). The proper way to go is to use the
codecs library.

Vincent

Le 14/05/2021 à 19:19, Vincent Delecroix a écrit :

Dear all,

On sage 9.3 and buckygen installed I got a lot of test failures
in graphs/graph_generators.py of the type

sage -t --long --random-seed=0 src/sage/graphs/graph_generators.py
**
File "src/sage/graphs/graph_generators.py", line 1233, in 
sage.graphs.graph_generators.GraphGenerators.fullerenes

Failed example:
    len(list(gen))  # optional buckygen
Exception raised:
    Traceback (most recent call last):
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py", 
line 714, in _run

    self.compile_and_execute(example, compiler, test.globs)
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/doctest/forker.py", 
line 1133, in compile_and_execute

    exec(compiled, globs)
  File "sage.graphs.graph_generators.GraphGenerators.fullerenes[1]>", line 1, in 


    len(list(gen))  # optional buckygen
  File 
"/home/vdelecro/sage_patchbot/local/lib/python3.6/site-packages/sage/graphs/graph_generators.py", 
line 1301, in fullerenes

    sp.stdout.reconfigure(newline='')
    AttributeError: '_io.TextIOWrapper' object has no attribute 
'reconfigure'

**

Best
Vincent


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b7508205-ed86-8444-6e72-d4ae429d58e7%40gmail.com.