Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Matthias Koeppe]

Or we just let pillow use a system libjpeg if it finds one.

On Thursday, November 16, 2023 at 2:38:07 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 16 November 2023 19:33:45 GMT, Michael Orlitzky  
> wrote:
> >On Thu, 2023-11-16 at 06:48 -0800, Eric Gourgoulhon wrote:
> >> 
> >> If we agree to restore jpeg support in Pillow, I have prepared a branch 
> >> that does this for Sage 10.2 (simply suppressing the option 
> "jpeg=disable"):
> >> https://github.com/egourgoulhon/sage/tree/pillow_jpeg
> >> and I am happy to submit a PR for this.
> >> 
> >
> >That makes pillow link to libjpeg, so we'd also need to package some
> >incarnation of libjpeg, make it a standard package, write the spkg-
> >configure script, etc.
> >
> >AFAIK the "best" libjpeg is https://libjpeg-turbo.org/, but then we
> >would also need to package an assembler (nasm or yasm) to build it...
>
> let's not make libjpeg a real package.
> Make it a dummy package, so that libjpeg may be advertised as something to 
> be installed.
>
> IIRC the difficulty in packaging jpeg was one of yhe reasons it never made 
> it to a package.
>
> >
>

-- 
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/46cb6ffb-4c85-424e-bf25-45a5a35ffe40n%40googlegroups.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Dima Pasechnik]

On 16 November 2023 19:33:45 GMT, Michael Orlitzky  wrote:
>On Thu, 2023-11-16 at 06:48 -0800, Eric Gourgoulhon wrote:
>> 
>> If we agree to restore jpeg support in Pillow, I have prepared a branch 
>> that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
>> https://github.com/egourgoulhon/sage/tree/pillow_jpeg
>> and I am happy to submit a PR for this.
>> 
>
>That makes pillow link to libjpeg, so we'd also need to package some
>incarnation of libjpeg, make it a standard package, write the spkg-
>configure script, etc.
>
>AFAIK the "best" libjpeg is https://libjpeg-turbo.org/, but then we
>would also need to package an assembler (nasm or yasm) to build it...

let's not make libjpeg a real package.
Make it a dummy package, so that libjpeg may be advertised as something to be 
installed.

IIRC the difficulty in packaging jpeg was one of yhe reasons it never made it 
to a package.

>

-- 
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/91D80886-1163-45B6-9427-69E16081CF63%40gmail.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Michael Orlitzky]

On Thu, 2023-11-16 at 06:48 -0800, Eric Gourgoulhon wrote:
> 
> If we agree to restore jpeg support in Pillow, I have prepared a branch 
> that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
> https://github.com/egourgoulhon/sage/tree/pillow_jpeg
> and I am happy to submit a PR for this.
> 

That makes pillow link to libjpeg, so we'd also need to package some
incarnation of libjpeg, make it a standard package, write the spkg-
configure script, etc.

AFAIK the "best" libjpeg is https://libjpeg-turbo.org/, but then we
would also need to package an assembler (nasm or yasm) to build it...

-- 
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/a5f2d0a90ca2521d0882ac4c1b42f33b2ea36c19.camel%40orlitzky.com.

Re: [sage-devel] Cython errors when building p_group_cohomology

[Marc Culler]

Thank you, Edgar!  That worked.

- Marc

On Wednesday, November 15, 2023 at 7:15:45 PM UTC-6 Edgar Costa wrote:

> Marc, you should try something like this: 
> https://github.com/edgarcosta/pyfib/commit/f30cd702f5b8610a284b1b1f425ef22b2a2a11fa
>
> On Wed, Nov 15, 2023 at 6:49 PM Marc Culler  wrote:
>
>> I am not able to build the optional package p_group_cohomology in 
>> 10.2.rc2 due to cython errors.
>>
>> The first error looks like:
>>
>> [p_group_cohomology-3.3.3.p1]   Error compiling Cython file:
>> [p_group_cohomology-3.3.3.p1]   
>> ---
>> -
>> [p_group_cohomology-3.3.3.p1]   ...
>> [p_group_cohomology-3.3.3.p1]   from sage.structure.element cimport 
>> Element
>> [p_group_cohomology-3.3.3.p1]   from .map cimport Map
>> [p_group_cohomology-3.3.3.p1]   ^
>> [p_group_cohomology-3.3.3.p1]   
>> ---
>> -
>> [p_group_cohomology-3.3.3.p1] 
>> [p_group_cohomology-3.3.3.p1]   
>> /XXX/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sage/categories/morphism.pxd:2:0:
>>  
>> 'sage/categories/map.pxd' not found
>>
>> In fact, the file map.pxd does exist in the same directory as 
>> morphism.pxd, which is the file containing the failing cimport line.  But 
>> the missing path reported by cython is not an absolute path: 
>> sage/categories/map.pxd.  I don't know to which base directory that 
>> relative path is meant to be applied, but evidently it is wrong.
>>
>> I will attach the log file.
>>
>> - Marc
>>
>> -- 
>> 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/b0293496-5e25-49d5-bd11-78928bb3ecb6n%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/8a811b7a-f530-4121-8e86-72db2c1ef758n%40googlegroups.com.

[sage-devel] Re: Pillow built without jpeg support in Sage 10.2.rc3

[Matthias Koeppe]

On Thursday, November 16, 2023 at 6:48:47 AM UTC-8 Eric Gourgoulhon wrote:

[...] the file
SAGE_ROOT/build/pkgs/pillow/spkg-install.in
contains the line:

PILLOW_CONFIG_SETTINGS="-C debug=true -C jpeg=disable 
$PILLOW_CONFIG_SETTINGS"

Is there any reason for "jpeg=disable" ? 


This was done in 2016, see 
https://github.com/sagemath/sage/issues/20021#issuecomment-1417764945, 
apparently for platform support reasons

Providing PIL without jpeg support seems quite weird...


I agree
 

This issue is not new and was already noticed already 5 years ago:
https://ask.sagemath.org/question/43298

A side effect of this is that the IPyhon  rendering of PIL Images via the 
rich output mechanism is broken in Sage 10.2.rc3 (but, for some reasons, 
not in Sage 10.1)


This temporarily worked accidentally because Pillow had made an 
incompatible change to the format of its configuration settings. I repaired 
that as part of the Pillow 10 upgrade 
in https://github.com/sagemath/sage/pull/36320
 

If we agree to restore jpeg support in Pillow, I have prepared a branch 
that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
https://github.com/egourgoulhon/sage/tree/pillow_jpeg
and I am happy to submit a PR for this.


Yes, please. 

 

-- 
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/3ff29e9e-3e10-4630-94b4-5d061e99f82fn%40googlegroups.com.

Re: [sage-devel] Re: Question about make dependencies

[kcrisman]

To John C's point, and perhaps with the humor that John P intended: 
https://daily.jstor.org/in-which-we-science-why-nouns-become-verbs-because-language/

-- 
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/5d59e7dd-4691-4977-b736-185da225a7b4n%40googlegroups.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[David Roe]

I'm not aware of why we were suppressing jpeg support before, but this
sounds like a good idea to me.
David

On Thu, Nov 16, 2023 at 9:48 AM Eric Gourgoulhon 
wrote:

> Hi All,
>
> Pillow provides the Python Imaging Library (PIL)
> https://pillow.readthedocs.io/en/stable/
> and is a standard package in Sage.
>
> Now, in Sage 10.2.rc3, the following code
>
> g = plot(sin(x)) # to generate a png figure
> g.save("fig.png")  #
> from PIL import Image
> img = Image.open("fig.png")
> img_rgb = img.convert("RGB")
> img_rgb.save("fig.jpg")
>
> returns
>
> OSError: encoder jpeg not available
>
> This is actually not surprising since the file
> SAGE_ROOT/build/pkgs/pillow/spkg-install.in
> contains the line:
>
> PILLOW_CONFIG_SETTINGS="-C debug=true -C jpeg=disable
> $PILLOW_CONFIG_SETTINGS"
>
> Is there any reason for "jpeg=disable" ?
> Providing PIL without jpeg support seems quite weird...
> This issue is not new and was already noticed already 5 years ago:
> https://ask.sagemath.org/question/43298
>
> A side effect of this is that the IPyhon  rendering of PIL Images via the
> rich output mechanism is broken in Sage 10.2.rc3 (but, for some reasons,
> not in Sage 10.1):
> in a Jupyter notebook, typing
>
> img = Image.open("fig.png")
> img
>
> does display the image but after an error message terminating by
> ValueError: Could not save to JPEG for display
> There is no such error message in Sage 10.1
>
> If we agree to restore jpeg support in Pillow, I have prepared a branch
> that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
> https://github.com/egourgoulhon/sage/tree/pillow_jpeg
> and I am happy to submit a PR for this.
>
> Eric.
>
>
> --
> 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/e1a2bf34-d3e5-492b-942c-33b1fc8c3254n%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/CAChs6_%3DqnJhUOK1ND3A7vuLgo_bTP-8kEHGEKojBWoQJQBZsKA%40mail.gmail.com.

[sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Eric Gourgoulhon]

Hi All,

Pillow provides the Python Imaging Library (PIL)
https://pillow.readthedocs.io/en/stable/
and is a standard package in Sage. 

Now, in Sage 10.2.rc3, the following code

g = plot(sin(x)) # to generate a png figure
g.save("fig.png")  #
from PIL import Image
img = Image.open("fig.png")
img_rgb = img.convert("RGB")
img_rgb.save("fig.jpg")

returns

OSError: encoder jpeg not available

This is actually not surprising since the file
SAGE_ROOT/build/pkgs/pillow/spkg-install.in
contains the line:

PILLOW_CONFIG_SETTINGS="-C debug=true -C jpeg=disable 
$PILLOW_CONFIG_SETTINGS"

Is there any reason for "jpeg=disable" ? 
Providing PIL without jpeg support seems quite weird...
This issue is not new and was already noticed already 5 years ago:
https://ask.sagemath.org/question/43298

A side effect of this is that the IPyhon  rendering of PIL Images via the 
rich output mechanism is broken in Sage 10.2.rc3 (but, for some reasons, 
not in Sage 10.1): 
in a Jupyter notebook, typing

img = Image.open("fig.png")
img

does display the image but after an error message terminating by 
ValueError: Could not save to JPEG for display
There is no such error message in Sage 10.1

If we agree to restore jpeg support in Pillow, I have prepared a branch 
that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
https://github.com/egourgoulhon/sage/tree/pillow_jpeg
and I am happy to submit a PR for this.

Eric.


-- 
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/e1a2bf34-d3e5-492b-942c-33b1fc8c3254n%40googlegroups.com.

Re: [sage-devel] eclib dependencies

[John Cremona]

On Thu, 16 Nov 2023 at 12:15, Michael Orlitzky  wrote:

> On 2023-11-16 09:23:15, John Cremona wrote:
> >
> > If no-one has any reason to keep things as they are I will make a PR with
> > the relevant changes to build/pkgs/eclib.
>
> From a packaging standpoint, fewer dependencies is better. For
> example, upgrading flint would become a tiny bit easier if we didn't
> have to worry about it breaking eclib. And on Gentoo we have a lot of
> people who simply prefer to turn every optional feature off. So I
> think it's a nice idea.
>

Thanks Michael.  AFter more thought I think I will leave flint as a
dependency, as there are quite a few features of flint (especially in
flint3) which could be used in eclib, and which improve it, if I find the
time.  It's just that right now, if you omit "--with-flint" on eclib's
configure then you still get a 100% wworking eclib.


>
>
> > Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> > in a check for an exact eclib version (currently 20230424), which seems
> > unnecessarily restrictive.  I would welcome suggestions for how to either
> > check for a certain version *or later*, and/or check that the library has
> > certain functions which we know that Sage wil need.
>
> The version restrictions are usually about the tests passing and not
> about what works. For example if foo-1.0 prints "1 + 2" and foo-2.0
> prints "2 + 1", that can cause the tests to fail until we update them
> to accept both outputs. In the meantime we would probably reject
> foo-2.0 even though it too gives correct answers. (This will get
> better as fewer people rely on sage-the-distribution for exact
> versions.)
>
> Anyway, in this case, there are two autoconf tests that need to be
> changed from equality to greater-than-or-equality:
>
>   PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],...
>   AX_COMPARE_VERSION([$mwrank_version], [eq], [SAGE_ECLIB_VER],..
>

I'll try that out when I next upgrade eclib in Sage.  My latest version
detects whether it has Flint version 2 or 3 and does slightly different
things in those cases, both working correctly, but there is nothing to make
it worth a new release of eclib.  I'll probably do that once the work of
getting flint3 into Sage is finished.

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/ZVYH-QiUAXLbkkx-%40stitch.
>

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

Re: [sage-devel] eclib dependencies

[Michael Orlitzky]

On 2023-11-16 09:23:15, John Cremona wrote:
> 
> If no-one has any reason to keep things as they are I will make a PR with
> the relevant changes to build/pkgs/eclib.

>From a packaging standpoint, fewer dependencies is better. For
example, upgrading flint would become a tiny bit easier if we didn't
have to worry about it breaking eclib. And on Gentoo we have a lot of
people who simply prefer to turn every optional feature off. So I
think it's a nice idea.


> Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> in a check for an exact eclib version (currently 20230424), which seems
> unnecessarily restrictive.  I would welcome suggestions for how to either
> check for a certain version *or later*, and/or check that the library has
> certain functions which we know that Sage wil need.

The version restrictions are usually about the tests passing and not
about what works. For example if foo-1.0 prints "1 + 2" and foo-2.0
prints "2 + 1", that can cause the tests to fail until we update them
to accept both outputs. In the meantime we would probably reject
foo-2.0 even though it too gives correct answers. (This will get
better as fewer people rely on sage-the-distribution for exact
versions.)

Anyway, in this case, there are two autoconf tests that need to be
changed from equality to greater-than-or-equality:

  PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],...
  AX_COMPARE_VERSION([$mwrank_version], [eq], [SAGE_ECLIB_VER],..

-- 
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/ZVYH-QiUAXLbkkx-%40stitch.

Re: [sage-devel] eclib dependencies

[John Cremona]

On Thu, 16 Nov 2023 at 09:44, Dima Pasechnik  wrote:

>
>
> On 16 November 2023 09:23:15 GMT, John Cremona 
> wrote:
> >Currently the eclib spkg has pari, ntl and flint as dependencies.  The
> >first two are essential, but flint is currently hardly used and everything
> >works without it.  (It is only used at all to compute the ref of a matrix
> >(with entries int or long int) mod p and if flint is not available it just
> >uses ntl instead.)
> >
> >It strikes me that there would be a small advantage within Sage to build
> >eclib without flint: it would only affect the function
> >CremonaModularSymbols() (and related) which are of very limited interest;
> >it would not affect any of the elliptic curve functionality in eclib.
>
> I don't think this is really worthwhile: only if there were flint-less
> versions of eclib abound on systems where Sage is installed,  these would
> be acceptable.
> But it's not the case, and flint is here anyway, so there is very little
> point in doing this.
>

OK.   What triggered this for me was having installed flint3 on my machine,
as Sage doesn't (yet) work with that, and it therefore prevents Sage using
my own installed eclib.

The install script does have a now-redundant few lines of code relating to
flint configuration, which can be simplified now anyway.

>
>
>
> >
> >If no-one has any reason to keep things as they are I will make a PR with
> >the relevant changes to build/pkgs/eclib.
> >
> >Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> >in a check for an exact eclib version (currently 20230424), which seems
> >unnecessarily restrictive.  I would welcome suggestions for how to either
> >check for a certain version *or later*, and/or check that the library has
> >certain functions which we know that Sage wil need.
>
> indeed, we can relax to "or later". I suppose you're not  going to break
> upward  compatibility of functions used in Sage.
>

Not intentionally


>
> Dima
> >
> >Not until after 10.2 is realeased, certainly.
> >
> >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/DA83A1E2-A69D-4C75-9793-F890F21E5403%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/CAD0p0K6YxJLr4JP92Z6FRotoU-9Q8BNp5B08ioEZfLj7PLjNNw%40mail.gmail.com.

Re: [sage-devel] eclib dependencies

[Dima Pasechnik]

On 16 November 2023 09:23:15 GMT, John Cremona  wrote:
>Currently the eclib spkg has pari, ntl and flint as dependencies.  The
>first two are essential, but flint is currently hardly used and everything
>works without it.  (It is only used at all to compute the ref of a matrix
>(with entries int or long int) mod p and if flint is not available it just
>uses ntl instead.)
>
>It strikes me that there would be a small advantage within Sage to build
>eclib without flint: it would only affect the function
>CremonaModularSymbols() (and related) which are of very limited interest;
>it would not affect any of the elliptic curve functionality in eclib.

I don't think this is really worthwhile: only if there were flint-less versions 
of eclib abound on systems where Sage is installed,  these would be acceptable.
But it's not the case, and flint is here anyway, so there is very little point 
in doing this.



>
>If no-one has any reason to keep things as they are I will make a PR with
>the relevant changes to build/pkgs/eclib.
>
>Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
>in a check for an exact eclib version (currently 20230424), which seems
>unnecessarily restrictive.  I would welcome suggestions for how to either
>check for a certain version *or later*, and/or check that the library has
>certain functions which we know that Sage wil need.

indeed, we can relax to "or later". I suppose you're not  going to break upward 
 compatibility of functions used in Sage.

Dima 
>
>Not until after 10.2 is realeased, certainly.
>
>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/DA83A1E2-A69D-4C75-9793-F890F21E5403%40gmail.com.

[sage-devel] eclib dependencies

[John Cremona]

Currently the eclib spkg has pari, ntl and flint as dependencies.  The
first two are essential, but flint is currently hardly used and everything
works without it.  (It is only used at all to compute the ref of a matrix
(with entries int or long int) mod p and if flint is not available it just
uses ntl instead.)

It strikes me that there would be a small advantage within Sage to build
eclib without flint: it would only affect the function
CremonaModularSymbols() (and related) which are of very limited interest;
it would not affect any of the elliptic curve functionality in eclib.

If no-one has any reason to keep things as they are I will make a PR with
the relevant changes to build/pkgs/eclib.

Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
in a check for an exact eclib version (currently 20230424), which seems
unnecessarily restrictive.  I would welcome suggestions for how to either
check for a certain version *or later*, and/or check that the library has
certain functions which we know that Sage wil need.

Not until after 10.2 is realeased, certainly.

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/CAD0p0K5gP4B%2BAcAdgBT3US4rt3%2Bxaiw_GFRVH2dBjPj%3DhukyCg%40mail.gmail.com.