Re: [sage-devel] Re: [debian-science] Modularized sagemath packages: proof of concept

[Marc Culler]

On Monday, October 7, 2024 at 12:05:25 AM UTC-5 Kwankyu Lee wrote:

On the other hand, who would be the users of the distribution packages for 
whatever need? I wonder how they overlap with sage developers.


A concrete example of a useful standalone Sage module is CyPari2.  By 
including CyPari within SnapPy we are able to make it possible to compute 
number theoretic invariants of hyperbolic manifolds.  We are unable to use 
Sage's CyPari2 because we need to support Windows. But, as Oscar says, it 
should be easier to port individual modules to Windows than all of Sage.  
That is the case with CyPari.

As another example, it would be great for SnapPy if we could also include 
Sage's interval arithmetic code, packaged as a standalone module.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b5d5eeb2-238f-4520-9715-4b6d3704ba65n%40googlegroups.com.

Re: [sage-devel] Re: [debian-science] Modularized sagemath packages: proof of concept

[Marc Culler]

On Thursday, October 3, 2024 at 8:05:09 PM UTC-5 Kwankyu Lee wrote:

The motivation of the modularization project is to reduce the burden who 
only needs some portion of the sage library,
and wants to use and develop the portion within the python ecosystem.


I would say that the motivation is to make it possible for  a developer to 
include a self-contained portion of sage in a separate project without 
having to make that project as large as a full Sage distribution.
 

An individual mathematician who only needs some portion of the sage library 
may install only his favorite distribution package.


As I have said so many times before, apparently to no avail, I strongly 
disagree with this point of view.  It is not reasonable to expect an 
individual mathematician, or student, to be able to decide which portions 
of Sage are needed, nor even to know which portions can be installed 
separately.  An individual who wants to use Sage should just install Sage.  
All of it.  And that installation should be very easy.  It should certainly 
not require deciding which portions of Sage might be needed in which 
contexts. 

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/03b2caa7-0213-4223-8a88-6ec5878986e0n%40googlegroups.com.

[sage-devel] The e_antic spkg doesn't build with XCode 16 on macOS Sequoia

[Marc Culler]

This was the only other problem package besides gfortran.  The issue seems 
to be that one of the e_antic files includes a boost header which triggers 
a warning about assigning out-of-range values to an enum.  That warning was 
promoted to an error in clang 16.  Boost actually already has a 
workaround,, because other compilers generate errors for this as well.  So 
that workaround just needs to be activated for clang 16.  There is a patch 
in this macports ticket  that does 
this.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0c7751dc-1432-4d81-86eb-faa1178d8753n%40googlegroups.com.

Re: [sage-devel] gfortran 13.3.0 does not build for x86_64 with XCode 16 ...

[Marc Culler]

According to https://formulae.brew.sh/formula/gcc, the homebrew gcc 
supports Sequoia on Arm but not on Intel yet.  The patch referenced in the 
ticket appears to work.  It is not entirely trivial to apply that patch, 
however, because it changes some of the same files as the existing patches.

- Marc

On Thursday, October 3, 2024 at 3:19:13 PM UTC-5 dim...@gmail.com wrote:

> Hi Marc,
> does Homebrew's gfortran work for you?
> Dima
>
>
> On 3 October 2024 19:02:49 BST, Marc Culler  wrote:
>
>> ... as I learned the hard way, after updating my build system to macOS 15.
>>
>> The cause is this bug: 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
>> for which a patch exists.
>>
>> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/60a8d608-2460-4143-891a-657686d47a41n%40googlegroups.com.

[sage-devel] gfortran 13.3.0 does not build for x86_64 with XCode 16 ...

[Marc Culler]

... as I learned the hard way, after updating my build system to macOS 15.

The cause is this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
for which a patch exists.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e716661f-e34d-4553-93f0-bcefa85dae9bn%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

> You can grab one of those objects on the heap and look at its backreference 
> graph

How does one do that?

- Marc

On Sun, Sep 15, 2024 at 11:17 AM Nils Bruin  wrote:
>
> On Sunday 15 September 2024 at 10:08:18 UTC-7 dim...@gmail.com wrote:
>
> For me this code is rather unpredictable, as ipython and prompt_toolkit kick 
> in
> and produce extra objects.
>
> For consistency (at least them the output values are reproducible)
> it looks better to experiment with Sage's python (./sage --python)
> for which the code needs to be adjusted, with "^" replaced by "**", and
> two lines added as the front:
>
> from sage.all import *
> var('x')
>
>
> Generally, to check if there's a leak one would look how object swell on the 
> heap grows with iterations. That drowns out the constant overhead of the 
> shell.
> Or you can just wrap the whole measuring process in a function, so that it 
> gets executed in an enclosed scope. There are generally some objects whose 
> creation does scale with iteration and whose type is rather specific. You can 
> grab one of those objects on the heap and look at its backreference graph. 
> That generally gives a pretty good pointer to where the global references are 
> held. It can actually be a fairly interesting challenge for someone with an 
> interest in learning the nitty gritty details of the sagemath memory setup. 
> It doesn't require brilliance; mostly persistence.
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "sage-devel" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/sage-devel/kbzd2uhTypU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/beacd365-e173-4ab9-a014-bb0fa89e2e54n%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/CALcZXRHpyFVoJBMyca%2BBM5XmZm-xw9RWX8Ejk1nWkBAJF5GXGw%40mail.gmail.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

As I said above this does not happen with either cypari or cypari2 when
using getno.

This is not a cypari issue.  The issue is that Sage creates a "unique"
object for each new number field, where new means that the input parameters
for the NumberField function have not been used before. The number field
objects are stored in a cache indexed by a key generated from the input
parameters.  Those cached objects live for the entire session.  This is by
design. The design did not anticipate creating a billion number fields in
one Sage session.  That was not necessarily a bad choice.

Perhaps there is a way of disabling caching or clearing the cache.

- Marc

On Sun, Sep 8, 2024, 1:02 PM Dima Pasechnik  wrote:

> Can this be reproduced in plain Python with cypari2 installed?
> One would need to replace the call to NumberField with the corresponding
> cypari2 equivalent.
> This would at least tell whether it's  a leak in cypari2, or not.
>
> Dima
>
>
>
>
>
> On 8 September 2024 17:03:54 BST, Nils Bruin  wrote:
>
>> This example is definitely leaving loads of stuff on the python heap, so
>> if there is a leak onto the cython heap then it is not the only one. My
>> guess would be an interaction with the coercion system or
>> UniqueRepresentation, which both keeps global weak references to objects.
>> If the key information ends up containing objects that hold a reference to
>> the values in a weakly valued dictionary, the garbage collector can not
>> remove the cycle. These things are hellish to debug. The code below does
>> find the relevant objects on the heap, though, so you can plot the
>> backwards reference graphs of some of these objects to see what kinds of
>> links are involved. We have resolved some of these bugs in the past.
>>
>> ```
>> import gc
>> from collections import Counter
>>
>> gc.collect()
>> pre={id(a) for a in gc.get_objects()}
>>
>> for A2 in range(1, 1000):
>> Kn=NumberField(x^2+A2,'w')
>> m=Kn.class_group().order()
>> del Kn, m
>>
>> gc.collect()
>> gc.collect()
>> T=Counter(str(type(a)) for a in gc.get_objects() if id(a) not in pre)
>> T
>> ```
>> Notes for the code above:
>>  - if you run it twice you get a nearly empty list from T, which is
>> consistent with UniqueRepresentation objects remaining (they would not be
>> recreated if they already exist).
>>  - this is confirmed by rerunning the loop but now with another name than
>> 'w' for Kn. Now new objects do get created!
>>
>> On Wednesday 4 September 2024 at 06:09:37 UTC-7 Georgi Guninski wrote:
>>
>>> Probably this shares the same bug as [1]
>>>
>>> Calling `NumberField().class_group().order()` in a loop of size N:
>>> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
>>> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>>>
>>> The leak appears to be in the pari heap.
>>>
>>> Code .sage:
>>> 
>>> #Author Georgi Guninski Wed Sep 4 12:58:18 PM UTC 2024
>>> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
>>> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>>>
>>> import psutil,gc,sys
>>>
>>> from sage.all import EllipticCurve
>>> ps = psutil.Process()
>>> num=10**3 #10**5 // 2
>>> x=var('x')
>>> def leaknf5(N=10**3):
>>> gc.collect()
>>> base = ps.memory_info().rss
>>> for A2 in range(1, N):
>>> Kn=NumberField(x^2+A2,'w')
>>> m=Kn.class_group().order()
>>> gc.collect()
>>> mem = ps.memory_info().rss - base
>>> print(f"{mem/1e6 :.2f} MB ",mem," pari=",pari.getheap())
>>>
>>> leaknf5(10**4)
>>> 
>>>
>>> [1]: https://groups.google.com/g/sage-devel/c/fWBls6YbXmw
>>> Memory leak in |EllipticCurve([n,0]).root_number()| and problem in
>>> algebraic geometry
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/kbzd2uhTypU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6658541E-8E9B-446A-906E-1CE7E043E16C%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/CALcZXRGrcVy6g1puui87KR4SJzdbm6nMPhMk9pzYPRvZafy%3DJw%40mail.gmail.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

Below is evidence (again) that the "leak" you are reporting is actually 
caused by caching NumberField objects or related data.  You can see that 
when a calculation using a certain NumberField is repeated it does not 
increase the size of  the PARI heap, although the first time that the 
calculation is done the size does increase.  Moreover the second time that 
the calculation is done it runs much faster.  These two things indicate to 
me that NumberField objects, or at least some of the computed data 
regarding a particular number field, are being cached.  This behavior is 
surely intentional, which means that some caution should be used when 
applying the  the label "bug" to it.   Some bugs are programming errors.  
Others are features with unexpected side effects.  I suspect this is the 
latter case, and that a decision was made that the cost of memory used by 
the caching is worth paying for the increase in speed that it allows.  
(Incidentally, writing loops which create many number fields and then 
immediately destroy each one is probably not the use case that the 
designers of the Sage NumberField had in mind.)

Looking at the code in number_field.py I see that when a number field is 
created a key is generated to uniquely identify that field.  The 
NumberField is not a class, but a function which accesses:
class NumberFieldFactory(UniqueFactory) 
These things support my belief that aspects of number fields are being 
cached and that the caching causes GENs on the PARI heap to be retained for 
the life of the cache, but allows properties of a cached number field to be 
looked up rather than recomputed. 

The file number_field.py does not contain any attribution, so I do not know 
who the author(s) may be.  But the author(s) would be much able to explain 
the rationale behind their design than I would.  Maybe some of them read 
this list ...

- Marc

sage: import cypari2
sage: pari = cypari2.Pari()
sage: pari.getheap()
[1, 9]
sage: for A in range(1, 10):
:   Kn = NumberField(x^2+A,'w')
:   m = Kn.class_group().order()
: 
sage: pari.getheap()
[21, 284]
sage: for A in range(1, 10):
:   Kn = NumberField(x^2+A,'w')
:   m = Kn.class_group().order()
: 
sage: pari.getheap()
[21, 284]
sage: def test(N):
: for A in range(1, N):
: Kn = NumberField(x^2+A,'w')
: m = Kn.class_group().order()
: 
sage: pari.getheap()
[21, 284]
sage: %time test(100)
CPU times: user 217 ms, sys: 5.09 ms, total: 222 ms
Wall time: 222 ms
sage: pari.getheap()
[201, 4265]
sage: %time test(100)
CPU times: user 22.7 ms, sys: 1.48 ms, total: 24.2 ms
Wall time: 23 ms
sage: pari.getheap()
[201, 4265]
sage: 

On Sunday, September 8, 2024 at 9:12:14 AM UTC-6 Marc Culler wrote:

> I agree that this is a bug.  I do not think it is the same issue as the 
> leak you reported involving elliptic curves.  The reason I don't think so 
> is that it is possible to compute class numbers with no memory leak using 
> the PARI getno function in either cypari or cypari 2.  There are many 
> things that can cause the PARI heap to grow (and it happens in cypari2 with 
> just ordinary vectors and matrices as discussed in cypari2 issue #112).  
> One major cause of PARI heap GENs not getting freed is that those GENs are 
> managed by Python Gen objects which are not being deallocated due to 
> references being held by other Python objects.  When a Python Gen is 
> dealloc'ed it should free the PARI GEN which is it managing if that GEN is 
> on the PARI heap.  That was not happening with the t_VEC GEN describiing an 
> elliptic curve, even though the Gen object was calling the PARI gunclone 
> function because the gunclone function was not freeing the "lazy" 
> components of that vector.  (That has been fixed in cypari.)
>
> I think something else is causing Sage NumberField objects to leak memory 
> (i.e. to not be deallocated) in your example.  The fact that both issues 
> involve growth of the PARI heap does not mean that both issues have the 
> same cause.  The statement that they "probably" have the same cause is not 
> supported by any evidence and I do not believe that they do have the same 
> cause.
>
> - Marc
>
> On Friday, September 6, 2024 at 3:26:55 AM UTC-6 Georgi Guninski wrote:
>
>> This is not complaint, it is an observation about bug of type memory 
>> leak. 
>> To leak about one GB, run the testcase `leaknf5` from the top of the 
>> thread with argument N=3*10^4: 
>>
>> #3*10^4 leaks: 1084.55 MB in 1m35.208s 
>>
>

-- 
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/214258af-1c02-4dc4-b898-035420db5e17n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

I agree that this is a bug.  I do not think it is the same issue as the 
leak you reported involving elliptic curves.  The reason I don't think so 
is that it is possible to compute class numbers with no memory leak using 
the PARI getno function in either cypari or cypari 2.  There are many 
things that can cause the PARI heap to grow (and it happens in cypari2 with 
just ordinary vectors and matrices as discussed in cypari2 issue #112).  
One major cause of PARI heap GENs not getting freed is that those GENs are 
managed by Python Gen objects which are not being deallocated due to 
references being held by other Python objects.  When a Python Gen is 
dealloc'ed it should free the PARI GEN which is it managing if that GEN is 
on the PARI heap.  That was not happening with the t_VEC GEN describiing an 
elliptic curve, even though the Gen object was calling the PARI gunclone 
function because the gunclone function was not freeing the "lazy" 
components of that vector.  (That has been fixed in cypari.)

I think something else is causing Sage NumberField objects to leak memory 
(i.e. to not be deallocated) in your example.  The fact that both issues 
involve growth of the PARI heap does not mean that both issues have the 
same cause.  The statement that they "probably" have the same cause is not 
supported by any evidence and I do not believe that they do have the same 
cause.

- Marc

On Friday, September 6, 2024 at 3:26:55 AM UTC-6 Georgi Guninski wrote:

> This is not complaint, it is an observation about bug of type memory leak.
> To leak about one GB, run the testcase `leaknf5` from the top of the
> thread with argument N=3*10^4:
>
> #3*10^4 leaks: 1084.55 MB in 1m35.208s
>

-- 
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/aeb951f9-ba91-4d91-bbb3-2b259a0ff701n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

Caching uses memory intentionally, for the purpose of speeding up 
computations.

Leaks use memory unintentionally, for no purpose.

I don't know where the caching happens. I only deduce that it exists 
because, when running the same computation twice, the second time is faster.

However, the caching does not happen in cypari2 (nor cypari).  This is what 
I see with cypari2 in sage:

sage: import cypari2
sage: pari = cypari2.Pari()
sage: def test(N):
: for a in range(1, N):
: K = pari.bnfinit(pari("x^2 + %s" % a))
: m = K.bnf_get_no()
: 
sage: %time test(10**3)
CPU times: user 543 ms, sys: 29.4 ms, total: 572 ms
Wall time: 630 ms
sage: %time test(10**4)
CPU times: user 7.14 s, sys: 48.4 ms, total: 7.18 s
Wall time: 7.2 s
sage: %time test(10**5)
CPU times: user 2min 1s, sys: 854 ms, total: 2min 2s
Wall time: 2min 2s

That uses 190MB, not "GBs".

The same computation with cypari in ipython is a bit faster but not much:
In [1]: from cypari import pari
In [2]: def test(N):
   ...: for a in range(1, N):
   ...: K = pari.bnfinit(pari("x^2 + %s" % a))
   ...: m = K.bnf_get_no()
In [3]: %time test(10**3)
CPU times: user 410 ms, sys: 4.75 ms, total: 415 ms
Wall time: 415 ms
In [4]: %time test(10**4)
CPU times: user 6.05 s, sys: 36.1 ms, total: 6.08 s
Wall time: 6.09 s
In [5]: %time test(10**5)
CPU times: user 1min 51s, sys: 846 ms, total: 1min 52s
Wall time: 1min 53s

That computation uses 51MB.  Also not "GBs".

There is no question that computations which run entirely on the PARI stack 
are faster than computations which move each PARI GEN to the heap and wrap 
it in a python object.  That is presumably the reason that the cypari2 
project was trying to leave GENs on the stack as long as possible.  
Unfortunately, their implementation of that idea caused huge memory leaks.

I think your complaints about the Sage NumberField class are not directly 
relevant to cypari or cypari2.

Your observation that PARI runs faster than cypari or cypari2 applies to 
the design of Sage's PARI interface, which goes back to the beginning of 
Sage.  I am sure that a better design would be welcomed, if you had one to 
offer.  Any such interface would incur some cost, but maybe it would be 
possible to do better.

- Marc

On Thursday, September 5, 2024 at 2:00:42 AM UTC-6 Georgi Guninski wrote:

On Wed, Sep 4, 2024 at 11:13 PM Marc Culler wrote: 
> 
> I think that here you are seeing caching taking place, rather than a 
memory leak. This is what I tried: 
> 
> 
You call this caching, I call it leak, it can be both ways. 
It is natural to compute the class numbers of QQ[sqrt(-n)] and 
it shouldn't takes GBs of RAM IMHO. 

Default pari is significantly faster with stack 40MB, 
is there drama nfinit vs bnfinit?: 

allocatemem(40*10^6); 
default(timer,1); 
{f(N)= 
for(a=1,N, 
K=bnfinit('x^2+a); 
m=K.clgp.no; 
); 
} 

? f(10^4) 
cpu time = 5,028 ms, real time = 5,057 ms. 
? f(10^5) 
cpu time = 1min, 14,328 ms, real time = 1min, 15,146 ms. 

-- 
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/9c7ff1d6-327a-4f7a-98ea-5e1dfd45c0d1n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

On Monday, September 2, 2024 at 11:13:43 AM UTC-6 dima wrote:

It appears that all these gunclone_deep() etc aren't documented in any 
proper way (and this is a root cause of this; same applies to memleaks we 
have in libsingular interface). Can you post a link to docs you are reading?
I can only find an email exchange from 2018 where 
similar issues are discussed.
It seems that gunclone_deep should be used sparingly.


Just a small addendum to this thread.  The recommended way to deal with 
freeing elements of a "lazy vector" GEN -- recommended in both the email 
exchange in the the PARI documentation  -- is to pass the GEN to obj_free.  
But if you look at the code you find that what obj_free does is to first 
verify that the last element in the GEN is a t_VEC and, if so, pass it to 
gunclone_deep.

So, while the libpari documentation (section 5.6.2) says that gunclone_deep 
is only useful in the context of the GP interpreter, in fact they use it in 
obj_free within libpari itself.. 

"User's Guide to the PARI library 

void gunclone_deep(GEN x) is only useful in the context of the GP 
interpreter which may replace arbitrary components of container types (t_VEC, 
t_COL, t_MAT, t_LIST) by clones. If x is such a container, the function 
recursively deletes all clones among the components of x, then unclones x. 
Useless in library mode: simply use gunclone."

-- 
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/eb10b1b6-dfee-4ab6-a879-f74e87572af3n%40googlegroups.com.

[sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Marc Culler]

I think that here you are seeing caching taking place, rather than a memory 
leak.  This is what I tried:

sage: import cypari2
sage: pari = cypari2.Pari()
sage: def test(N):
: for a in range(1, N):
: K = NumberField(x^2+a, 'w')
: m = K.class_group().order
: print(pari.getheap())
: 
sage: %time test(10**3)
[7950, 1451665]
CPU times: user 2.86 s, sys: 45.5 ms, total: 2.91 s
Wall time: 2.92 s
sage: %time test(10**3)
[7950, 1451665]
CPU times: user 160 ms, sys: 2.65 ms, total: 163 ms
Wall time: 163 ms
sage: %time test(10**4)
[83505, 19297360]
CPU times: user 29.6 s, sys: 336 ms, total: 30 s
Wall time: 30.1 s
sage: %time test(10**4)
[83505, 19297360]
CPU times: user 1.33 s, sys: 4.32 ms, total: 1.33 s
Wall time: 1.33 s

I assume that the huge reduction in time for the second run of the test 
function is due to caching, and that the extra space on the heap is used by 
cached objects.

- Marc


On Wednesday, September 4, 2024 at 7:09:37 AM UTC-6 Georgi Guninski wrote:

> Probably this shares the same bug as [1]
>
> Calling `NumberField().class_group().order()` in a loop of size N:
> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>
> The leak appears to be in the pari heap.
>
> Code .sage:
> 
> #Author Georgi Guninski Wed Sep 4 12:58:18 PM UTC 2024
> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>
> import psutil,gc,sys
>
> from sage.all import EllipticCurve
> ps = psutil.Process()
> num=10**3 #10**5 // 2
> x=var('x')
> def leaknf5(N=10**3):
> gc.collect()
> base = ps.memory_info().rss
> for A2 in range(1, N):
> Kn=NumberField(x^2+A2,'w')
> m=Kn.class_group().order()
> gc.collect()
> mem = ps.memory_info().rss - base
> print(f"{mem/1e6 :.2f} MB ",mem," pari=",pari.getheap())
>
> leaknf5(10**4)
> 
>
> [1]: https://groups.google.com/g/sage-devel/c/fWBls6YbXmw
> Memory leak in |EllipticCurve([n,0]).root_number()| and problem in
> algebraic geometry
>

-- 
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/a98d82bc-313b-4b5a-8f1b-86c105089fa0n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

Georgi, sorry for misspelling your name.

- Marc

On Tuesday, September 3, 2024 at 12:56:49 PM UTC-5 Marc Culler wrote:

> That is a pretty interesting exchange, it indicates that this memory leak 
> has been known to exist for 6 years, and the remedy is also discussed 
> there.  Details and answers to questions asked in this thread follow.
>
> To answer Dima's question first, the Pari documentation that I am 
> referring to is the User's Guide to the PARI library (libpari.pdf).  Now 
> for the details ...
>
> The Pari GEN constructed by pari.ellinit is what Pari calls a "lazy 
> vector".  These are discussed in section 12.3, which begins by saying
> "The functions in this section are used to implement ell structures and 
> analogous objects, which are vectors some of whose components are 
> initialized to dummy values, later computed on demand."
> The only example known to me of a lazy vector is the GEN constructed by the
> ellinit function.
>
> A "Technical Note" in thst section contains more detail:
> "In the current implementation, S is a t_VEC with d + 1 entries. The first 
> d components are ordinary t_GEN entries, which you can read or assign to in 
> the customary way. But the last component gel(S, d + 1), a t_VEC of length 
> n initialized to zerovec(n), must be handled in a special way: you should 
> never access or modify its components directly, only through the API we are 
> about to describe."
>
> You can see an example of this behavior in Sage as follows:
>
>   sage: import cypari2
>   sage: pari = cypari2.Pari()
>   sage: e = pari.ellinit([11, 0]); e
>   [0, 0, 0, 11, 0, 0, 22, 0, -121, -528, 0, -85184, 1728, Vecsmall([1]),
>   [Vecsmall([64, -1])], [0, 0, 0, 0, 0, 0, 0, 0]]
>
> The last entry of e is a t_VEC containing 8 references to the PARI Zero 
> GEN, created by obj_init.  The ellrootno function fills in this vector, 
> replacing the Zero placeholders by pointers to Pari GENS on the heap.  To 
> see this in sage:
>
> sage: pari.ellrootno(e)
> 1
> sage: e
> [0, 0, 0, 11, 0, 0, 22, 0, -121, -528, 0, -85184, 1728, Vecsmall([1]), 
> [Vecsmall([64, -1])], [0, 0, 0, 0, 0, [3872, 4, [2, 5; 11, 2], [[5, 3, 0, 
> 2], [2, 3, 0, 2]]], [1, Vecsmall([-1, 1])], [[2, 11]~]]]
>
> To answer Giorgi's question one can observe that, while ellrootno 
> *usually* fills in the lazy components, sometimes it doesn't need to:
> sage: e = pari.ellinit([2**70, 0]); e
> [0, 0, 0, 1180591620717411303424, 0, 0, 2361183241434822606848, 0, 
> -1393796574908163946345982392040522594123776, -56668397794435742564352, 0, 
> -105312291668557186697918027683670432318895095400549111254310977536, 1728, 
> Vecsmall([1]), [Vecsmall([64, -1])], [0, 0, 0, 0, 0, 0, 0, 0]]
> sage: pari.ellrootno(e)
> 1
> sage: e
> [0, 0, 0, 1180591620717411303424, 0, 0, 2361183241434822606848, 0, 
> -1393796574908163946345982392040522594123776, -56668397794435742564352, 0, 
> -105312291668557186697918027683670432318895095400549111254310977536, 1728, 
> Vecsmall([1]), [Vecsmall([64, -1])], [0, 0, 0, 0, 0, [32, 4, Mat([2, 5]), 
> [[5, -7, 0, 4]]], [1, Vecsmall([-1])], [[2]~, [131072, 0, 0, 0], [0, 0, 0, 
> 4, 0, 0, 8, 0, -16, -192, 0, -4096, 1728, Vecsmall([1]), [Vecsmall([64, 
> -1])], [0, 0, 0, 0, 0, 0, 0, 0]
>
> (Note that the vector in the last entry is still all zeroes.)
>
> In any case, the heap GENs added lazily by ellrootno cause the memory 
> leak.  If the PARI GEN managed by the Python Gen e is passed to gunclone 
> (as happens in the Gen.__dealloc__ method) those added heap GENs are not 
> freed.  However, the documented API addresses this issue via the function 
> obj_free:
> "void obj_free(GEN S) destroys all clones stored in the n tagged 
> components, and replace them by the initial value 0. The regular entries of 
> S are unaffected, and S remains a valid object. This is used to avoid 
> memory leaks."
>
> Thus the fix for this memory leak (now implemented in CyPari) is to track 
> which Python Gen objects are managing "lazy vector" GENs, and to modify the 
> Gen.__dealloc__ method to make it call obj_free before calling gunclone for 
> those objects.  Unfortunately, if obj_free is passed a GEN which is not a 
> lazy vector, i.e. was not initialized by obj_init, then a segfault results. 
>  So the tracking is essential.  In CyPari I added a cdef field to the Gen 
> class which is used to track whether the GEN is a lazy vector.  I had to 
> modify the auto_gen code to allow for setting that flag for all such GENs. 
>  (Currently that means only the GENs produced by calling ellinit.  I 
> couldn't find any others, although obj_init does seem to be called by 
> rnfinit as well.)
>
> - Ma

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

> > On 2018-08-20 18:14, Karim Belabas wrote: 
>
> In libpari code, it's usually easy to explicitly call a destructor [ e.g. 
> obj_free ] any time a function such as 'ellinit' was used 
>
> > It's not easy if the list of functions "such as 'ellinit'" is not known. 
>
> <https://pari.math.u-bordeaux.fr/archives/pari-dev-1808/msg00012.html> 
>
>
> On 2 September 2024 03:30:14 BST, Marc Culler  wrote:
>
>> Unsurprisingly, changing gunclone to gunclone_deep in Gen.__dealloc__ is 
>> not a full fix.  It stops this leak but it also causes a crash when running 
>> the doctests.  On macOS the crash error is "freeing a pointer which was not 
>> allocated".  On linux the error is "corrupted size vs. prev_size in 
>> fastbins".
>>
>> I won't force this list to participate in the full debugging experience. 
>> The basic problem has been identified.  The remedy is far from clear.
>>
>> - Marc
>>
>> On Sun, Sep 1, 2024, 5:37 PM Marc Culler  wrote:
>>
>>> This is now fixed in cypari.  The fix consisted of replacing gunclone by 
>>> gunclone_deep in the Gen.__dealloc__ method.  The same change would 
>>> probably help in cypari2, although I would not expect it to fix the other 
>>> memory leaks reported in issue #112.
>>>
>>> Here is the explanation.  The Pari GEN returned by pari.ellinit is of 
>>> type t_VEC with entries of various types including t_INT and t_VECSMALL.  
>>> The function pari.ellrootno returns a Python int, but it has side effects.  
>>> It also inserts items into the t_VEC GEN representing the elliptic curve.  
>>> That t_VEC GEN is managed by a Python Gen object, and that Python Gen 
>>> object would pass the t_VEC GEN to gunclone in its __dealloc method.  
>>> However, that was not sufficient to cause the new items which were inserted 
>>> into the t_VEC gen by pari.ellrootno to also be uncloned.  Consequently, 
>>> those extra GENs remained on the Pari heap forever.  Once the python object 
>>> was gone, there was no event which would cause them to be destroyed.
>>>
>>> If you read the Pari documentation you will "learn" that gunclone_deep 
>>> is only useful in the context of the peculiar memory model used by gp.  
>>> Well, apparently it is also useful in the context of the peculiar memory 
>>> model used by cypari and cypari2.
>>>
>>> I tested the cypari fix on linux ubuntu using the test function 
>>> described earlier in this thread.  With 10**8 iterations it never used over 
>>> 8.4MB of memory.
>>>
>>> - Marc
>>>
>>> On Sunday, September 1, 2024 at 12:07:26 PM UTC-6 Marc Culler wrote:
>>>
>>>> My experiments with cypari so far indicate the opposite of what I 
>>>> expected.  (This is with one small but significant bug fix that I found 
>>>> along the way.) The main observations are:
>>>>(1) Without the call to pari.ellrootno there is no memory leak.  The 
>>>> call to pari.getheap returns the same value before and after creating many 
>>>> elliptic curves in a for loop.
>>>>   (2) Calling pari.ellrootno(e) in a loop, with the same elliptic curve 
>>>> e,  also does not increase the Pari heap size.
>>>>   (3) With both the call to pari.ellinit and the call to  
>>>> pari.ellrootno in the loop, every Python Gen object created in the loop 
>>>> gets deallocated and its Pari GEN gets uncloned with reference count 1, 
>>>> meaning it is removed from the heap. Nonetheless, the heap grows 
>>>> considerably during the loop.  
>>>>
>>>> I conclude that Pari is creating and cloning its own GENs (i.e. GENs 
>>>> not managed by any Python object) during the call to ellrootno and is not 
>>>> uncloning all of those GENs.  But it only does that with a newly created 
>>>> curve.
>>>>  
>>>>
>>>> - Marc
>>>> On Sunday, September 1, 2024 at 10:24:33 AM UTC-6 Marc Culler wrote:
>>>>
>>>>> I would say that the getheap behavior is a symptom of the same memory 
>>>>> management bug(s).  Also, it is not as simple as you suggest.  It is not 
>>>>> always true that every call to getheap leaves something on the heap:
>>>>>
>>>>> >>> from cypari import pari
>>>>> >>> pari.getheap()
>>>>> [4, 41]
>>>>> >>> pari.getheap()
>>>>> [

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

Unsurprisingly, changing gunclone to gunclone_deep in Gen.__dealloc__ is
not a full fix.  It stops this leak but it also causes a crash when running
the doctests.  On macOS the crash error is "freeing a pointer which was not
allocated".  On linux the error is "corrupted size vs. prev_size in
fastbins".

I won't force this list to participate in the full debugging experience.
The basic problem has been identified.  The remedy is far from clear.

- Marc

On Sun, Sep 1, 2024, 5:37 PM Marc Culler  wrote:

> This is now fixed in cypari.  The fix consisted of replacing gunclone by
> gunclone_deep in the Gen.__dealloc__ method.  The same change would
> probably help in cypari2, although I would not expect it to fix the other
> memory leaks reported in issue #112.
>
> Here is the explanation.  The Pari GEN returned by pari.ellinit is of type
> t_VEC with entries of various types including t_INT and t_VECSMALL.  The
> function pari.ellrootno returns a Python int, but it has side effects.  It
> also inserts items into the t_VEC GEN representing the elliptic curve.
> That t_VEC GEN is managed by a Python Gen object, and that Python Gen
> object would pass the t_VEC GEN to gunclone in its __dealloc method.
> However, that was not sufficient to cause the new items which were inserted
> into the t_VEC gen by pari.ellrootno to also be uncloned.  Consequently,
> those extra GENs remained on the Pari heap forever.  Once the python object
> was gone, there was no event which would cause them to be destroyed.
>
> If you read the Pari documentation you will "learn" that gunclone_deep is
> only useful in the context of the peculiar memory model used by gp.  Well,
> apparently it is also useful in the context of the peculiar memory model
> used by cypari and cypari2.
>
> I tested the cypari fix on linux ubuntu using the test function described
> earlier in this thread.  With 10**8 iterations it never used over 8.4MB of
> memory.
>
> - Marc
>
> On Sunday, September 1, 2024 at 12:07:26 PM UTC-6 Marc Culler wrote:
>
>> My experiments with cypari so far indicate the opposite of what I
>> expected.  (This is with one small but significant bug fix that I found
>> along the way.) The main observations are:
>>(1) Without the call to pari.ellrootno there is no memory leak.  The
>> call to pari.getheap returns the same value before and after creating many
>> elliptic curves in a for loop.
>>   (2) Calling pari.ellrootno(e) in a loop, with the same elliptic curve
>> e,  also does not increase the Pari heap size.
>>   (3) With both the call to pari.ellinit and the call to  pari.ellrootno
>> in the loop, every Python Gen object created in the loop gets deallocated
>> and its Pari GEN gets uncloned with reference count 1, meaning it is
>> removed from the heap. Nonetheless, the heap grows considerably during the
>> loop.
>>
>> I conclude that Pari is creating and cloning its own GENs (i.e. GENs not
>> managed by any Python object) during the call to ellrootno and is not
>> uncloning all of those GENs.  But it only does that with a newly created
>> curve.
>>
>>
>> - Marc
>> On Sunday, September 1, 2024 at 10:24:33 AM UTC-6 Marc Culler wrote:
>>
>>> I would say that the getheap behavior is a symptom of the same memory
>>> management bug(s).  Also, it is not as simple as you suggest.  It is not
>>> always true that every call to getheap leaves something on the heap:
>>>
>>> >>> from cypari import pari
>>> >>> pari.getheap()
>>> [4, 41]
>>> >>> pari.getheap()
>>> [5, 58]
>>> >>> pari.getheap()
>>> [5, 58]
>>> >>> pari.getheap()
>>> [5, 58]
>>>
>>> It is also not true that the cypari and cypari2 behaviors are
>>> equivalent, although they are similar.  (Running the test loop with 10**5
>>> iterations does not use anything close to 28 GB with cypari).  I believe
>>> that some, but definitely not all, of the memory management issues --
>>> namely the most glaring ones described in issue #112 -- were improved in
>>> cypari by removing the code which tries to keep wrapped Pari GENs on the
>>> stack instead of moving them to the heap.
>>>
>>> The behavior where Pari GENs go on the heap and never get removed is
>>> intertwined with python memory management.  Python and the Pari heap use
>>> independent reference counting schemes.  The __dealloc__ method of a Python
>>> Gen object calls gunclone to reduce the reference count of the Pari heap
>>> GEN which is referenced by the python Gen object.  However, as d

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

This is now fixed in cypari.  The fix consisted of replacing gunclone by 
gunclone_deep in the Gen.__dealloc__ method.  The same change would 
probably help in cypari2, although I would not expect it to fix the other 
memory leaks reported in issue #112.

Here is the explanation.  The Pari GEN returned by pari.ellinit is of type 
t_VEC with entries of various types including t_INT and t_VECSMALL.  The 
function pari.ellrootno returns a Python int, but it has side effects.  It 
also inserts items into the t_VEC GEN representing the elliptic curve.  
That t_VEC GEN is managed by a Python Gen object, and that Python Gen 
object would pass the t_VEC GEN to gunclone in its __dealloc method.  
However, that was not sufficient to cause the new items which were inserted 
into the t_VEC gen by pari.ellrootno to also be uncloned.  Consequently, 
those extra GENs remained on the Pari heap forever.  Once the python object 
was gone, there was no event which would cause them to be destroyed.

If you read the Pari documentation you will "learn" that gunclone_deep is 
only useful in the context of the peculiar memory model used by gp.  Well, 
apparently it is also useful in the context of the peculiar memory model 
used by cypari and cypari2.

I tested the cypari fix on linux ubuntu using the test function described 
earlier in this thread.  With 10**8 iterations it never used over 8.4MB of 
memory.

- Marc

On Sunday, September 1, 2024 at 12:07:26 PM UTC-6 Marc Culler wrote:

> My experiments with cypari so far indicate the opposite of what I 
> expected.  (This is with one small but significant bug fix that I found 
> along the way.) The main observations are:
>(1) Without the call to pari.ellrootno there is no memory leak.  The 
> call to pari.getheap returns the same value before and after creating many 
> elliptic curves in a for loop.
>   (2) Calling pari.ellrootno(e) in a loop, with the same elliptic curve 
> e,  also does not increase the Pari heap size.
>   (3) With both the call to pari.ellinit and the call to  pari.ellrootno 
> in the loop, every Python Gen object created in the loop gets deallocated 
> and its Pari GEN gets uncloned with reference count 1, meaning it is 
> removed from the heap. Nonetheless, the heap grows considerably during the 
> loop.  
>
> I conclude that Pari is creating and cloning its own GENs (i.e. GENs not 
> managed by any Python object) during the call to ellrootno and is not 
> uncloning all of those GENs.  But it only does that with a newly created 
> curve.
>  
>
> - Marc
> On Sunday, September 1, 2024 at 10:24:33 AM UTC-6 Marc Culler wrote:
>
>> I would say that the getheap behavior is a symptom of the same memory 
>> management bug(s).  Also, it is not as simple as you suggest.  It is not 
>> always true that every call to getheap leaves something on the heap:
>>
>> >>> from cypari import pari
>> >>> pari.getheap()
>> [4, 41]
>> >>> pari.getheap()
>> [5, 58]
>> >>> pari.getheap()
>> [5, 58]
>> >>> pari.getheap()
>> [5, 58]
>>
>> It is also not true that the cypari and cypari2 behaviors are equivalent, 
>> although they are similar.  (Running the test loop with 10**5 iterations 
>> does not use anything close to 28 GB with cypari).  I believe that some, 
>> but definitely not all, of the memory management issues -- namely the most 
>> glaring ones described in issue #112 -- were improved in cypari by removing 
>> the code which tries to keep wrapped Pari GENs on the stack instead of 
>> moving them to the heap.
>>
>> The behavior where Pari GENs go on the heap and never get removed is 
>> intertwined with python memory management.  Python and the Pari heap use 
>> independent reference counting schemes.  The __dealloc__ method of a Python 
>> Gen object calls gunclone to reduce the reference count of the Pari heap 
>> GEN which is referenced by the python Gen object.  However, as demonstred 
>> in issue #112, cypari2 was creating other internal Python objects which 
>> held references to a Python Gen wrapping a vector or matrix entry.  That 
>> prevented those Python Gens from being destroyed and therefore prevented 
>> the Pari GENs wrapped by those Python Gens from being removed from the Pari 
>> heap.
>>
>> Apart from the initial call to gclone when a Python Gen is created, I 
>> haven't found any code within cypari which could increase the reference 
>> count of a Pari GEN on the Pari heap.  Unless Pari sometimes increases that 
>> reference count, this would suggest that the core issue lies with Python 
>> reference counts.  Evidently Python Gen objects are not being dealloc'ed 
>> because other Python o

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

My experiments with cypari so far indicate the opposite of what I 
expected.  (This is with one small but significant bug fix that I found 
along the way.) The main observations are:
   (1) Without the call to pari.ellrootno there is no memory leak.  The 
call to pari.getheap returns the same value before and after creating many 
elliptic curves in a for loop.
  (2) Calling pari.ellrootno(e) in a loop, with the same elliptic curve e,  
also does not increase the Pari heap size.
  (3) With both the call to pari.ellinit and the call to  pari.ellrootno in 
the loop, every Python Gen object created in the loop gets deallocated and 
its Pari GEN gets uncloned with reference count 1, meaning it is removed 
from the heap. Nonetheless, the heap grows considerably during the loop.  

I conclude that Pari is creating and cloning its own GENs (i.e. GENs not 
managed by any Python object) during the call to ellrootno and is not 
uncloning all of those GENs.  But it only does that with a newly created 
curve.
 

- Marc
On Sunday, September 1, 2024 at 10:24:33 AM UTC-6 Marc Culler wrote:

> I would say that the getheap behavior is a symptom of the same memory 
> management bug(s).  Also, it is not as simple as you suggest.  It is not 
> always true that every call to getheap leaves something on the heap:
>
> >>> from cypari import pari
> >>> pari.getheap()
> [4, 41]
> >>> pari.getheap()
> [5, 58]
> >>> pari.getheap()
> [5, 58]
> >>> pari.getheap()
> [5, 58]
>
> It is also not true that the cypari and cypari2 behaviors are equivalent, 
> although they are similar.  (Running the test loop with 10**5 iterations 
> does not use anything close to 28 GB with cypari).  I believe that some, 
> but definitely not all, of the memory management issues -- namely the most 
> glaring ones described in issue #112 -- were improved in cypari by removing 
> the code which tries to keep wrapped Pari GENs on the stack instead of 
> moving them to the heap.
>
> The behavior where Pari GENs go on the heap and never get removed is 
> intertwined with python memory management.  Python and the Pari heap use 
> independent reference counting schemes.  The __dealloc__ method of a Python 
> Gen object calls gunclone to reduce the reference count of the Pari heap 
> GEN which is referenced by the python Gen object.  However, as demonstred 
> in issue #112, cypari2 was creating other internal Python objects which 
> held references to a Python Gen wrapping a vector or matrix entry.  That 
> prevented those Python Gens from being destroyed and therefore prevented 
> the Pari GENs wrapped by those Python Gens from being removed from the Pari 
> heap.
>
> Apart from the initial call to gclone when a Python Gen is created, I 
> haven't found any code within cypari which could increase the reference 
> count of a Pari GEN on the Pari heap.  Unless Pari sometimes increases that 
> reference count, this would suggest that the core issue lies with Python 
> reference counts.  Evidently Python Gen objects are not being dealloc'ed 
> because other Python objects hold references to them, and this is 
> preventing Pari from removing GENs from its heap.
>
> On Saturday, August 31, 2024 at 1:11:45 PM UTC-5 dim...@gmail.com wrote:
>
>> On Sat, Aug 31, 2024 at 4:35 AM Marc Culler  wrote: 
>> > 
>> > As Dima says, and as the issue he mentions supports, the current 
>> cypari2 code which attempts to keep Pari Gens on the Pari stack as much as 
>> possible is badly broken. There are many situations where Python Gen 
>> objects cannot be garbage-collected after being destroyed. I am sure that 
>> is a big part of this problem. But I don't think it is the whole story. 
>> > 
>> > CyPari has returned to the older design which moves the Pari Gen 
>> wrapped by a Python Gen to the pari heap when the python object is created. 
>> This eliminates the leaks reported in cypari2 issue #112. But in this 
>> context, I am seeing 12 GB of memory (including several gigabytes of swap) 
>> in use after I do the following in ipython: 
>> > 
>> > In [1]: from cypari import * 
>> > In [2]: def test(N): 
>> > ...: for a in range(1, N): 
>> > ...: e = pari.ellinit([a, 0]) 
>> > ...: m = pari.ellrootno(e) 
>> > In [3]: %time test(10**5) 
>> > CPU times: user 699 ms, sys: 38.3 ms, total: 737 ms 
>> > Wall time: 757 ms 
>> > In [4]: %time test(10**6) 
>> > CPU times: user 7.47 s, sys: 392 ms, total: 7.86 s 
>> > Wall time: 7.93 s 
>> > In [5]: %time test(10**7) 
>> > CPU times: user 1min 41s, sys: 6.62 s, total: 1min 47s 
>> > Wall time: 1min 49s 
>>
>> the picture is ver

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

I would say that the getheap behavior is a symptom of the same memory 
management bug(s).  Also, it is not as simple as you suggest.  It is not 
always true that every call to getheap leaves something on the heap:

>>> from cypari import pari
>>> pari.getheap()
[4, 41]
>>> pari.getheap()
[5, 58]
>>> pari.getheap()
[5, 58]
>>> pari.getheap()
[5, 58]

It is also not true that the cypari and cypari2 behaviors are equivalent, 
although they are similar.  (Running the test loop with 10**5 iterations 
does not use anything close to 28 GB with cypari).  I believe that some, 
but definitely not all, of the memory management issues -- namely the most 
glaring ones described in issue #112 -- were improved in cypari by removing 
the code which tries to keep wrapped Pari GENs on the stack instead of 
moving them to the heap.

The behavior where Pari GENs go on the heap and never get removed is 
intertwined with python memory management.  Python and the Pari heap use 
independent reference counting schemes.  The __dealloc__ method of a Python 
Gen object calls gunclone to reduce the reference count of the Pari heap 
GEN which is referenced by the python Gen object.  However, as demonstred 
in issue #112, cypari2 was creating other internal Python objects which 
held references to a Python Gen wrapping a vector or matrix entry.  That 
prevented those Python Gens from being destroyed and therefore prevented 
the Pari GENs wrapped by those Python Gens from being removed from the Pari 
heap.

Apart from the initial call to gclone when a Python Gen is created, I 
haven't found any code within cypari which could increase the reference 
count of a Pari GEN on the Pari heap.  Unless Pari sometimes increases that 
reference count, this would suggest that the core issue lies with Python 
reference counts.  Evidently Python Gen objects are not being dealloc'ed 
because other Python objects hold references to them, and this is 
preventing Pari from removing GENs from its heap.

On Saturday, August 31, 2024 at 1:11:45 PM UTC-5 dim...@gmail.com wrote:

> On Sat, Aug 31, 2024 at 4:35 AM Marc Culler  wrote:
> >
> > As Dima says, and as the issue he mentions supports, the current cypari2 
> code which attempts to keep Pari Gens on the Pari stack as much as possible 
> is badly broken. There are many situations where Python Gen objects cannot 
> be garbage-collected after being destroyed. I am sure that is a big part of 
> this problem. But I don't think it is the whole story.
> >
> > CyPari has returned to the older design which moves the Pari Gen wrapped 
> by a Python Gen to the pari heap when the python object is created. This 
> eliminates the leaks reported in cypari2 issue #112. But in this context, I 
> am seeing 12 GB of memory (including several gigabytes of swap) in use 
> after I do the following in ipython:
> >
> > In [1]: from cypari import *
> > In [2]: def test(N):
> > ...: for a in range(1, N):
> > ...: e = pari.ellinit([a, 0])
> > ...: m = pari.ellrootno(e)
> > In [3]: %time test(10**5)
> > CPU times: user 699 ms, sys: 38.3 ms, total: 737 ms
> > Wall time: 757 ms
> > In [4]: %time test(10**6)
> > CPU times: user 7.47 s, sys: 392 ms, total: 7.86 s
> > Wall time: 7.93 s
> > In [5]: %time test(10**7)
> > CPU times: user 1min 41s, sys: 6.62 s, total: 1min 47s
> > Wall time: 1min 49s
>
> the picture is very similar to cypari2.
> (with cypari2, one has to run
>
> pari=Pari()
>
> after the
>
> from cypari2 import *
>
> but otherwise it's the same code)
>
> You can inspect the Pari heap, by calling
> pari.getheap()
>
> each call to test() gets you about 3 new objects per call on the heap,
> so after 10^5 calls you get around 30
> objects there (and with 10^6 calls, around 3 million are added). The
> following is with cypari
>
> In [4]: %time test(10**5)
> CPU times: user 1.46 s, sys: 85.8 ms, total: 1.55 s
> Wall time: 1.55 s
> In [5]: pari.getheap()
> Out[5]: [31, 14394782]
> In [6]: %time test(10**6)
> CPU times: user 14.9 s, sys: 756 ms, total: 15.7 s
> Wall time: 15.7 s
> In [7]: pari.getheap()
> Out[7]: [329, 163655656]
>
> With cypari2, similar:
>
> In [9]: pari.getheap() # 10^5
> Out[9]: [299969, 14392931]
>
> In [12]: pari.getheap() # 10^6
> Out[12]: [3299662, 163635286]
>
>
> And gc.collect() does not do anything, in either case, Pari heap
> remains this big.
>
> As well, with cypari, a call to pari.getheap() adds 1 object there, a
> bug, I guess.
> (this does not happen with cypari2)
> In [14]: pari.getheap()
> Out[14]: [334, 163655741]
> In [15]: pari.getheap()
> Out[15]: [335, 163655758]
> In [16]: pari.getheap()
> Out[16]: [336, 163

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Marc Culler]

As Dima says, and as the issue he mentions supports, the current cypari2 
code which attempts to keep Pari Gens on the Pari stack as much as possible 
is badly broken.  There are many situations where Python Gen objects cannot 
be garbage-collected after being destroyed.  I am sure that is a big part 
of this problem.  But I don't think it is the whole story.

CyPari has returned to the older design which moves the Pari Gen wrapped by 
a Python Gen to the pari heap when the python object is created.  This 
eliminates the leaks reported in cypari2 issue #112.  But in this context, 
I am seeing 12 GB of memory (including several gigabytes of swap) in use 
after I do the following in ipython:

In [1]: from cypari import *
In [2]: def test(N):
   ...: for a in range(1, N):
   ...: e = pari.ellinit([a, 0])
   ...: m = pari.ellrootno(e)
In [3]: %time test(10**5)
CPU times: user 699 ms, sys: 38.3 ms, total: 737 ms
Wall time: 757 ms
In [4]: %time test(10**6)
CPU times: user 7.47 s, sys: 392 ms, total: 7.86 s
Wall time: 7.93 s
In [5]: %time test(10**7)
CPU times: user 1min 41s, sys: 6.62 s, total: 1min 47s
Wall time: 1min 49s

- Marc

On Thursday, August 29, 2024 at 1:19:05 PM UTC-5 dim...@gmail.com wrote:

> It would be good to reproduce this with cypari2 alone.
> cypari2 is known to have similar kind (?) of problems:
> https://github.com/sagemath/cypari2/issues/112
>
>
> On Thu, Aug 29, 2024 at 6:47 PM Nils Bruin  wrote:
> >
> > On Thursday 29 August 2024 at 09:51:04 UTC-7 Georgi Guninski wrote:
> >
> > I observe that the following does not leak:
> >
> > E=EllipticCurve([5*13,0]) #no leak
> > rn=E.root_number()
> >
> >
> > How do you know that doesn't leak? Do you mean that repeated execution 
> of those commands in the same session does not swell memory use?
> >
> >
> > The size of the leak is suspiciously close to a power of two.
> >
> >
> > I don't think you can draw conclusions from that. Processes generally 
> request memory in large blocks from the operating system, to amortize the 
> high overhead in the operation. It may even be the case that 128 Mb is the 
> chunk size involved here! The memory allocated to a process by the 
> operating system isn't a fully accurate measure of memory allocation use in 
> the process either: a heap manager can decide it's cheaper to request some 
> new pages from the operating system than to reorganize its heap and reuse 
> the fragmented space on it. I think for this loop, memory allocation 
> consistently swells with repeated execution, so there probably really is 
> something leaking. But given that it's not in GC-tracked objects on the 
> python heap, one would probably need valgrind information or a keen look at 
> the code involved to locate where it's coming from.
> >
> > --
> > 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/e63e2ec9-106a-4ddd-ab16-5c6db4fe83b4n%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/8f309f36-5a39-4677-a137-60a724e0d970n%40googlegroups.com.

Re: [sage-devel] Re: (I’m failing to build a working binary) Please provide a snapcraft package/container as now all but one Linux distributions no longer package Sagemath.

[Marc Culler]

Dear Laël,

On Sunday, August 25, 2024 at 2:29:44 AM UTC-5 "Dima" wrote:

CertIainly Sage does build and run on all sorts of Linux systems. But it's 
getting more and more bloated to support macOS, and this gets in the way of 
Linux.


It is true that Sage builds on linux, of course.  It is false that Sage 
bloat (real or perceived) is related in any way to the fact that Sage 
supports the macOS operating system.  The core issue is that parts of the 
Sage community have a very hard time accepting the idea that most Sage 
users are more interested in doing math than in compiling code, and would 
much prefer to be able to easily install a binary package which they can 
just use to having to build their own.  The fact that it is now possible 
for macOS users to do that seems to make macOS the target of belligerent 
attacks from time to time.

I have considered trying to build a binary package for linux, but I am 
currently leaning towards using AppImage rather than Snap.  If you have 
experience relevant to choosing between those I would be interested in 
hearing about it (off-list, of course).

- Marc


On Sunday, August 25, 2024 at 2:29:44 AM UTC-5 "Dima" wrote:

Please post your config.log

CertIainly Sage does build and run on all sorts of Linux systems. But it's 
getting more and more bloated to support macOS, and this gets in the way 
of Linux.

Dima


On 24 August 2024 09:54:53 BST, "Laël" wrote:

Except the latest conda binary version is sage 10.3 not 10.4 which lack the 
optional order= parameter on the log function on pari’s ffelt 
implementation.

In my case, the finite field’s order is very hard to factor so it’s 
impossible to solve my problem in old version of sagemath which is why I 
can’t just install an old package.

Sincerely,

Le vendredi 23 août 2024 à 05:37:22 UTC+2, Nathan Dunfield a écrit :

I recommend you install SageMath via Conda:

https://doc.sagemath.org/html/en/installation/conda.html#install-from-conda-forge

In my experience, this method "just works" even on seriously old and cranky 
Linux distros.

Best,

Nathan

On Thursday, August 22, 2024 at 12:32:08 PM UTC-5 "Laël" wrote:

Even by following this guide 
 on a fresh minimal ᴠᴍ, 
whether it’s on red hat or Debian or Ubuntu, the resulting sagelib doesn’t 
load :
I’m meaning simply typing
from sage import *

on a python prompt triggers a segfault.

Of course this means building docs fails. Here’s the logs attached with lot 
of warnings.

x

-- 
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/edca3931-2730-4388-b4ec-06c14052c129n%40googlegroups.com.

Re: [sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Marc Culler]

On Wed, Aug 21, 2024 at 12:35 PM Dima Pasechnik  wrote:

>  what if you have a version mismatch between the toolchain used to build
> the shipped binary,
> and XCode you installed locally? I'd expect trouble, in particular with
> C++.
>

When I tested the %%cython magic command I was running a beta version of
macOS 15 with XCode 16.1 beta, while the SageMath app was built on macOS 14
with XCode 16.0.  The python function that I used was trivial - it just
multiplied the argument by 2.0 and returned the product.  But it worked
fine.  I don't know if it is possible to force C++ to be used with the
%%cython magic command.

 The C and C++ runtimes are distributed with the operating system, and so
far we have not seen problems arising from users having a different
operating system version from the one used to build the app.

it's only if you are on a bad platform to begin with.


It is not really about which platform(s) I am on, it is about which
platform a Sage user is on.  I don't think that telling users that they
chose to install a bad operating system is likely to encourage people to
use Sage.

-- 
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/CALcZXRGTH2_92HZ-3Q-tbeZNH0viB9eyW_%3DRm%2BWd4jvOKrQc3A%40mail.gmail.com.

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Marc Culler]

I should add that, in truth, "xcode-select --install" is all that is really 
required in order to build Sage.  But you would not get that impression 
from reading about how to  build Sage.  (I consider that to be a great 
strength of Sage's current structure, and I am also aware that many people 
strongly disagree with me about that.)  I think that a user who only does 
that, without installing anything else, will be much more likely to succeed 
at building Sage, even though it will take longer.  But that is beside the 
point,  the point being that for many, probably most, users of Sage, 
building from source is a bad idea.

- Marc

On Wednesday, August 21, 2024 at 12:03:29 PM UTC-5 Marc Culler wrote:

> Using cython within Sage via the %%cython magic command definitely does* 
> not *require building Sage from source.  That magic command works fine in 
> the Sage_macOS binary distribution of SageMath.  The cython pip package is 
> included in that binary distribution, because it gets built and installed 
> as part of the Sage build.  Yes, you do need to have a C toolchain 
> installed on your mac.  But that requires nothing more than opening the 
> Terminal app and typing "xcode-select --install".  That works on a pristine 
> macOS system with no third party packages installed.
>
> I realize that it is a paradigm shift from years of Sage practice, but 
> overcoming the expectation that all of our users are, or secretly want to 
> be, developers and/or system administrators makes Sage much more accessible 
> to users, and that means having many more users.
>
> - Marc  
>
> On Wednesday, August 21, 2024 at 10:41:59 AM UTC-5 Nils Bruin wrote:
>
>> On Wednesday 21 August 2024 at 08:03:03 UTC-7 marc@gmail.com wrote:
>>
>> On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:
>>
>>  it is not a bad idea for a non-developer user to install sage from 
>> source.
>>
>>
>> I disagree.  It *is* a bad idea, for so many reasons:
>> * It requires a lot of time and work which is completely unrelated to 
>> using Sage.
>> * It will almost certainly fail.
>> * Even if it does succeed, it provides no benefit to a user who only 
>> wants to use Sage.  But it does have lots of negative side effects, 
>> including creating a 10GB subdirectory of the user's home which becomes 
>> totally  useless if it is moved, and forcing the installation of many 
>> packages and, possibly, package managers, which are useless to someone who 
>> is not interested in writing code.
>>
>>
>> Using sage may include using cython. Sage and Jupyter have excellent 
>> support for writing little snippets of cython code and have them integrate 
>> with python instructions around them with virtually no overhead, via 
>> "%%cython". I have definitely talked to people who use sage who (wanted to) 
>> use cython for mathematical inner loops that have to be fast and have no 
>> inclination to contribute code changes to sagemath. Those are 
>> (sophisticated) users. 
>>
>> At least building sagelib is a great way of certifying that cython works 
>> correctly. I agree that compiling the other parts of sage has very little 
>> practical benefit even for a developer. Because full functionality of sage 
>> implies a working compiler tool chain, compiling sage from source even for 
>> users is a much more reasonable proposition than for most other software.
>>
>

-- 
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/061ee922-a29d-46de-a0b1-702104e66769n%40googlegroups.com.

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Marc Culler]

Using cython within Sage via the %%cython magic command definitely does* 
not *require building Sage from source.  That magic command works fine in 
the Sage_macOS binary distribution of SageMath.  The cython pip package is 
included in that binary distribution, because it gets built and installed 
as part of the Sage build.  Yes, you do need to have a C toolchain 
installed on your mac.  But that requires nothing more than opening the 
Terminal app and typing "xcode-select --install".  That works on a pristine 
macOS system with no third party packages installed.

I realize that it is a paradigm shift from years of Sage practice, but 
overcoming the expectation that all of our users are, or secretly want to 
be, developers and/or system administrators makes Sage much more accessible 
to users, and that means having many more users.

- Marc  

On Wednesday, August 21, 2024 at 10:41:59 AM UTC-5 Nils Bruin wrote:

> On Wednesday 21 August 2024 at 08:03:03 UTC-7 marc@gmail.com wrote:
>
> On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:
>
>  it is not a bad idea for a non-developer user to install sage from source.
>
>
> I disagree.  It *is* a bad idea, for so many reasons:
> * It requires a lot of time and work which is completely unrelated to 
> using Sage.
> * It will almost certainly fail.
> * Even if it does succeed, it provides no benefit to a user who only wants 
> to use Sage.  But it does have lots of negative side effects, including 
> creating a 10GB subdirectory of the user's home which becomes totally  
> useless if it is moved, and forcing the installation of many packages and, 
> possibly, package managers, which are useless to someone who is not 
> interested in writing code.
>
>
> Using sage may include using cython. Sage and Jupyter have excellent 
> support for writing little snippets of cython code and have them integrate 
> with python instructions around them with virtually no overhead, via 
> "%%cython". I have definitely talked to people who use sage who (wanted to) 
> use cython for mathematical inner loops that have to be fast and have no 
> inclination to contribute code changes to sagemath. Those are 
> (sophisticated) users. 
>
> At least building sagelib is a great way of certifying that cython works 
> correctly. I agree that compiling the other parts of sage has very little 
> practical benefit even for a developer. Because full functionality of sage 
> implies a working compiler tool chain, compiling sage from source even for 
> users is a much more reasonable proposition than for most other software.
>

-- 
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/489471ab-4521-4c50-be01-666cafb0bfa1n%40googlegroups.com.

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Marc Culler]

On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:

 it is not a bad idea for a non-developer user to install sage from source.


I disagree.  It *is* a bad idea, for so many reasons:
* It requires a lot of time and work which is completely unrelated to using 
Sage.
* It will almost certainly fail.
* Even if it does succeed, it provides no benefit to a user who only wants 
to use Sage.  But it does have lots of negative side effects, including 
creating a 10GB subdirectory of the user's home which becomes totally  
useless if it is moved, and forcing the installation of many packages and, 
possibly, package managers, which are useless to someone who is not 
interested in writing code.

Even the suggestion that this is a reasonable thing for a "non-developer 
user" to do adds a huge obstacle to using Sage.

On the other hand, I think that distributing pre-built documentation is a 
good idea.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0ed75f80-f95c-4bbf-a0cf-9f874432eb29n%40googlegroups.com.

Re: [sage-devel] Proposal: Policy for standard packages from binary wheelsall

[Marc Culler]

Oh.  I wasn't paying very close attention when I looked at that file.  I am
familiar with manylinux wheels, of course.  I guess I was too busy being
impressed by the size of the file.

The real driver of the complexity, then, is the number of different
versions of python which Sage is obliged to support, and that in turn is
driven by which Python versions are provided by the various distros that
Sage supports.  Of course the macOS app uses only one version of python,
which it embeds, namely the one built with Sage's spkg.

When I build Sage for the macOS app my current process is to first run
Sage's standard build (disabling all "system" libraries and enabling as
many optional packages as possible) and then, when that is done, I use
Sage's pip to install current versions of pillow, jupyterlab and notebook
from binary wheels.  I use the following arguments to pip:
  install --no-user --force-reinstall --upgrade-strategy eager
That means that several packages that Sage built from source get clobbered
and replaced by packages installed from binary wheels.  But Sage ends up
with current (as of the time of my build)  versions of jupyterlab and
notebook, and those two packages end up having the dependencies against
which they have actually been tested.  (I don't believe that even a project
as large as jupyter has the capacity to test against all combinations of
dependencies which would meet their specifications, but I do believe that
they test pretty thoroughly against the newest allowed version of each
dependency.)  I do a sanity check to see that the installed versions of
jupyterlab and notebook work at a basic level, using the Sage kernel, but I
don't really have any way of testing jupyter or its dependencies more
carefully than the jupyter project itself does.  So, for the macOS app, I
have basically delegated the choice of wheel versions for the jupyterlab
and notebook dependencies to the jupyter project.  I think that few of the
dependencies of those two packages are critical to other parts of Sage,
with notable exceptions being IPython and its dependencies.

- Marc

PS I am also delegating the choice of version for many image processing
libraries to the Pillow project, and trusting them to compile the libraries.

On Sat, Aug 10, 2024 at 10:40 PM Matthias Koeppe 
wrote:

> On Friday, August 9, 2024 at 7:37:34 AM UTC-7 Marc Culler wrote:
>
> I was naively looking at this from the point of view of someone
> maintaining a port of Sage to a single platform, which also happens to
> allow a single binary wheel to work for multiple versions of the OS.
> Looking at that linked file [
> https://github.com/sagemath/sage/blob/fdc545367173f836890b9cddbce0d7c032b10d2b/build/pkgs/rpds_py/checksums.ini]
> reveals that the linux situation is infinitely more complex.  The version
> "pinning" apparently must be done separately for  each release of each
> distro.
>
>
> These are not really tied to "Linux distro releases". Instead the Python
> PA has defined common-denominator platforms called "manylinux" that are
> basically keyed to the GLIBC version. (That's what "2.17" in
> "manylinux_2_17" refers to.) In addition, there are common-denominator
> platforms for a different libc implementation, "musllinux".
>
> Probably there is no way to tame that maintenance headache.  Possibly Sage
> could hope to "delegate" the job of deciding which version of each binary
> wheel is optimal for each release of each distro to the package
> maintainer(s) for that distro and to copy the data for those checksum.ini
> files from some known location within each distro.  However, I don't see
> how that will work for the majority of distros given that they are not
> close to supporting the current version of Sage.
>
>
> That's the upstream projects' burden, not ours; in fact, the upstream
> projects delegate this burden to a large extent to the infrastructure that
> is provided by https://cibuildwheel.pypa.io/en/stable/
>
> I don't know if this scheme will end up being simpler than installing Rust
> in the Sage build directory (which involves very little more than
> downloading and running rustup.sh).  I hope it will.
>
>
> I also don't know for sure, but I'm simply not keen on taking on the work
> of maintaining anything Rust-related just to know with greater certainty.
>
> It's good to have a clear boundary of the project.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/vFsNl87zLxo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@

Re: [sage-devel] Proposal: Policy for standard packages from binary wheelsall

[Marc Culler]

As far as I can tell, that is quite different from what I was suggesting.  
It involves a separate package directory for each binary wheel, not one 
directory for many binary wheels which would all get installed together at 
the end of the build process in one big pip run.

However, I was naively looking at this from the point of view of someone 
maintaining a port of Sage to a single platform, which also happens to 
allow a single binary wheel to work for multiple versions of the OS. 
Looking at that linked file reveals that the linux situation is infinitely 
more complex.  The version "pinning" apparently must be done separately 
for  each release of each distro.  Probably there is no way to tame that 
maintenance headache.  Possibly Sage could hope to "delegate" the job of 
deciding which version of each binary wheel is optimal for each release of 
each distro to the package maintainer(s) for that distro and to copy the 
data for those checksum.ini files from some known location within each 
distro.  However, I don't see how that will work for the majority of 
distros given that they are not close to supporting the current version of 
Sage. 

I don't know if this scheme will end up being simpler than installing Rust 
in the Sage build directory (which involves very little more than 
downloading and running rustup.sh).  I hope it will.

- Marc

On Friday, August 9, 2024 at 8:54:48 AM UTC-5 Nathan Dunfield wrote:

> On Thursday, August 8, 2024 at 7:57:12 AM UTC-5 Marc Culler wrote:
>
> I think it would be possible to use a single spkg for all of the 
> additional binary wheels, where the main content of that spkg is a 
> requirements.txt file listing versions and hashes.  
>
>
> Yes, that is approach Matthias implemented in the accompanying PR (
> https://github.com/sagemath/sage/pull/38219), though the data is in the 
> "checksums.ini" file.  For example:
>
>
> https://github.com/sagemath/sage/blob/fdc545367173f836890b9cddbce0d7c032b10d2b/build/pkgs/rpds_py/checksums.ini
>  
>
> Best,
>
> Nathan
>

-- 
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/329f7a4e-d23f-4e62-903c-80f4e26d5f73n%40googlegroups.com.

Re: [sage-devel] Proposal: Policy for standard packages from binary wheels

[Marc Culler]

I think it would be possible to use a single spkg for all of the additional 
binary wheels, where the main content of that spkg is a requirements.txt 
file listing versions and hashes.  I also think that would be easier to 
maintain than many spkg directories, one for each binary wheel.  The only 
reason I know of for using separate directories is to allow a separate 
documentation file for each wheel.  I don't think that documentation is 
really needed, as it could be replaced by boilerplate which references 
pypi.  And, in practice, those individual documentation files would 
probably be constructed by copying and pasting from pypi anyway.

- Marc

On Tuesday, August 6, 2024 at 8:17:34 PM UTC-5 Bagas Sanjaya wrote:

> On Mon, Aug 05, 2024 at 08:28:12PM +0300, Georgi Guninski wrote:
> > On Sun, Aug 4, 2024 at 9:03 PM Matthias Koeppe  
> wrote:
> > >
> > 
> > > In https://github.com/sagemath/sage/pull/38219 (needs review), I 
> propose the following mild policy change:
> > > - as a third option, a "standard" package is allowed to be a Python 
> package that can be installed from platform-dependent (binary) wheels. In 
> this case, a "configure" option must be provided that disables the package.
> > >
> > > (Again this new option is motivated by avoiding the complexity of new 
> build infrastructure related to another language; in this case, Rust. See 
> the PR for two example Rust-based example packages; previous discussion: 
> https://groups.google.com/g/sage-devel/c/JiSryImYGe0/m/4B8z6F4AEwAJ)
> > >
> > 
> > I would recommend running antivirus just before `make install` and
> > commercial supply chain backdoor scanner. Especially if there is no
> > way to verify the integrity.
>
> In Windows, that's quite common for people to have antivirus installed.
> But for people on Linux, they usually don't install one.
>
> -- 
> An old man doll... just what I always wanted! - Clara
>

-- 
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/3a565bcf-7b90-4071-b620-b58eae41285fn%40googlegroups.com.

Re: [sage-devel] Re: ask.sagemath.org issues - do we need it?

[Marc Culler]

Thank you Sébastien for standing up for users, for distinguishing between 
users and developers, and for recognizing that those two groups have 
different needs.  May your Karma increase exponentially!

- Marc

On Monday, July 1, 2024 at 8:18:36 AM UTC-5 Sébastien Labbé wrote:

> I don't visit ask.sagemath.org much, so others who are regulars there may 
> correct me, but it seems that the whole downvoting/upvoting / karma / 
> accepting answers mechanism of this forum may have little value, as most 
> questions have 0 or 1 answers. So if that's lost in the migration, perhaps 
> not much is lost.
>
>
>  
>
> ask.sagemath.org receives questions and answers on a regular basis and 
> still today. Not later than last week, a user was happy for my answer : 
> https://ask.sagemath.org/question/77821/stanley-reisner-ideal-from-polytope/. 
> Also, I would say it is mainly a community of *users* of SageMath. 
> Questions are asked by users. But, also, the answers are given mostly by 
> users that are no so much developers. For instance Samuel Lelièvre, Karl 
> Crisman, Thierry Monteil, rburing are among those [
> https://ask.sagemath.org/users/] who have answered the most questions and 
> gathered more that 1 points of Karma. I don't agree that this has 
> little value: I dare anyone here to reach this value! But you will not see 
> these top Karma users in the top committers of the git of sagemath. It is 
> just another way of investing the community. By answering questions on a 
> daily basis, Samuel, Karl and Thierry gathered through the years an 
> enormous experience of what a normal user of SageMath needs are, and what 
> improvements should be made to SageMath, etc. I have great respect for them 
> and for the time they and many others have spent on ask trying to provide 
> the best answers. I think moving ask to some website made for developers 
> (e.g. Github Discussion?) is very bad idea, because it will kill this 
> community of users which is still alive today.
>
> Sébastien
>
>
>

-- 
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/39be90ea-1c10-4f98-9940-3bb1b0b41ef9n%40googlegroups.com.

[sage-devel] Misleading message from sage

[Marc Culler]

I think it would be good to replace misleading messages in sage by accurate 
messages. I offer as an example the following message which occurs if I run 
sage after first running:
   export DOT_SAGE="~/Library/Application Support/SageMath-10-4""

The message I got was:

  Your home directory has a space in it.  This
  will probably break some functionality of Sage.  E.g.,
  the GAP interface will not work. A workaround
  is to set the environment variable HOME to a
  directory with no spaces that you have write
  permissions to before you start sage.

It is false that my home directory has a space in it, and consequently 
setting HOME to a different directory will not solve any problems.  So the 
first and third sentences are complete garbage.

I would like to know if the second sentence is true.  I ran sage -gap using 
that value of DOT_SAGE and it seemed to work fine.  Does it really matter 
to GAP whether DOT_SAGE contains a space? If so, where should I be looking 
for this broken functionality?  Is it correct to interpret "GAP interface" 
to mean what you get when you run  "sage -gap"?

- Marc

PS I am asking because I would like to follow the Python convention of 
using the "~/Library/Application Support" directory as the location of 
user-installed pip packages installed with sage -pip.  I would also like to 
arrange for the macOS sage app to organize sage's user-installed pip 
packages by Sage version, not by python version. Multiple versions of sage 
(e.g. 10.2 and 10.3) may use the same python version, but that does not 
mean that the they should share pip packages. 

-- 
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/eb43287d-8c58-42c2-b8f6-36c3c035dbb6n%40googlegroups.com.

[sage-devel] Re: command not found errors from configure

[Marc Culler]

Oh.  And I think the default value should probably  be set with:
PYTHON_FOR_VENV=/usr/bin/false

- Marc

On Saturday, May 4, 2024 at 5:54:55 PM UTC-5 Marc Culler wrote:

> It is disturbing when one sees "command not found" errors in a configure 
> script.  That is what happens with 10.4.beta5.  After tracing it down I 
> found that they are coming from lines like: 
>
> *if "${PYTHON_FOR_VENV}" -c "import sys; 
> sys.exit(sys.version_info.minor < 11)"*
> *then :*
>
> The variable PYTHON_FOR_VENV is set with the command:
>
>
>
>
> *if test x$sage_spkg_install_python3 = xnothen :  
>   PYTHON_FOR_VENV="$ac_cv_path_PYTHON3"*
>
> But I think that if sage_spkg_install_python3 has the value yes then 
> PYTHON_FOR_VENV is not assigned a value, causing the errors when configure 
> is run.
>
> I have not determined what the collateral damage of this is.  But it seems 
> to me that there should be a default value for  PYTHON_FOR_VENV.
>
> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/54e45b0d-1cdf-407d-9cfb-a312397c64e3n%40googlegroups.com.

[sage-devel] command not found errors from configure

[Marc Culler]

It is disturbing when one sees "command not found" errors in a configure 
script.  That is what happens with 10.4.beta5.  After tracing it down I 
found that they are coming from lines like: 

*if "${PYTHON_FOR_VENV}" -c "import sys; 
sys.exit(sys.version_info.minor < 11)"*
*then :*

The variable PYTHON_FOR_VENV is set with the command:




*if test x$sage_spkg_install_python3 = xnothen :  
  PYTHON_FOR_VENV="$ac_cv_path_PYTHON3"*

But I think that if sage_spkg_install_python3 has the value yes then 
PYTHON_FOR_VENV is not assigned a value, causing the errors when configure 
is run.

I have not determined what the collateral damage of this is.  But it seems 
to me that there should be a default value for  PYTHON_FOR_VENV.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/10d58dbe-e88b-4e7b-aa6e-87918b477220n%40googlegroups.com.

[sage-devel] testing optional packages

[Marc Culler]

I don't know what the expectations are for testing optional packages, but 
in 10.4.beta4 when I run:

./sage -t venv/lib/python3.11/site-packages/symengine

I get the exception:

NameError: name 'test_sage_conversions' is not defined

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/be80e761-2047-408d-b45d-98d47369e6aen%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Yes, I was only talking about really just running Sage locally.

- Marc.

On Friday, April 26, 2024 at 7:54:38 PM UTC-5 Nils Bruin wrote:

> On Friday 26 April 2024 at 15:44:22 UTC-7 marc@gmail.com wrote:
>
> I don't see what difference the choice of port makes to a user.  It is not 
> possible to guarantee that the same port will always be used, since ports 
> are assigned on a first-come first-served basis.  Consequently it is not 
> possible to "bookmark" the address of either a jupyter server or a 
> cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
> address is always 127.0.0.1 in either case, by necessity.
>
>
> The port number that jupyter tries to use is configurable and there can be 
> reasons why you'd want to care about it. For instance, if you have a beefy 
> linux server that students in various locations want to use from windows 
> workstations. Ideally you'd run jupyterhub on it, but it's a complete 
> headache to figure out authentication and file system access and probably 
> impossible to find sysadmins capable and willing to make that setup secure.
>
> Instead, one could just assign a port number to each individual so that 
> they can set up a script to start their jupyter server on the right port on 
> localhost. They then just need to learn to use ssh (via PuTTY, for 
> instance) to tunnel the particular port from their desktop to the server 
> and then they can point the browser *on their own machine* to the right 
> address. It gets around the problem of getting people to install jupyter on 
> a windows box and it shows them an environment in which they could graduate 
> to useful work on the server themselves. And mainly, it gets around the 
> very real problem of getting a JupyterHub server set up. The price you pay, 
> of course, is that the port number is now very well-defined and actually 
> quite important. In that setup, it would be nice if the documentation were 
> served through the web server that jupyter is already running, because 
> that's the only port that's tunnelled. Or if the documentation just lives 
> on the internet; that's fine too (because if one weren't in an 
> internet-facing environment, setting up JupyterHub would at least be less 
> problematic from a security point of view).
>
> So, yes, if you're really just running it locally, the port number isn't 
> so important, but if any port forwarding comes into play, it becomes very 
> important to know the port number! 
>

-- 
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/7c9fbecb-6df0-41b4-9c46-5672e4f26149n%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

The jupyter server operates on the loopback interface which has IP address 
127.0.0.1 and IP name localhost.  The cocoserver uses that same interface.  
Jupyter tries to get port  and if that is busy it hunts for a nearby 
port that is not in use.   The cocoserver uses an arbitrary system-assigned 
available port in the public range (above 1000).

I don't see what difference the choice of port makes to a user.  It is not 
possible to guarantee that the same port will always be used, since ports 
are assigned on a first-come first-served basis.  Consequently it is not 
possible to "bookmark" the address of either a jupyter server or a 
cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
address is always 127.0.0.1 in either case, by necessity.

- Marc

On Friday, April 26, 2024 at 4:05:12 PM UTC-5 Nils Bruin wrote:

> On Friday 26 April 2024 at 12:29:14 UTC-7 marc@gmail.com wrote:
>
> There are other issues with viewing local documentation files in a 
> browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is 
> not allowed to read a file:// url which is not in the user's home 
> directory.  As long as sage is installed in the user's home directory this 
> is not an issue.  But if the documentation is elsewhere then Firefox and 
> Chrome will refuse to show it.  Using the cocoserver works around this 
> because it is allowed to use a url with the loopback interface as the host 
> address.  (I think it is safer to use 127.0.0.1 instead of localhost 
> because, in principle, a rogue DNS server would be able to provide any IP 
> address as an A record for localhost). 
>
>
> The most flexible would be to serve it from would be whatever address the 
> jupyter server is serving on. That's why it might be easier to get this to 
> behave properly as a jupyter extension, because it could even serve it on 
> the same port in that case. I guess the OSX app has hardcoded that it 
> serves on 127.0.0.1 then? How do you work around port availability there? 
> Does coco listen on a separate port from the jupyter server?
>
>

-- 
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/a0cc2634-605d-4479-be1b-a7dc4171050an%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Yes, I meant MB.  Thanks.

There are other issues with viewing local documentation files in a
browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is
not allowed to read a file:// url which is not in the user's home
directory.  As long as sage is installed in the user's home directory this
is not an issue.  But if the documentation is elsewhere then Firefox and
Chrome will refuse to show it.  Using the cocoserver works around this
because it is allowed to use a url with the loopback interface as the host
address.  (I think it is safer to use 127.0.0.1 instead of localhost
because, in principle, a rogue DNS server would be able to provide any IP
address as an A record for localhost).  I don't know if there is a jupyter
extension that provides access to local files on the loopback interface.

- Marc

On Fri, Apr 26, 2024 at 2:12 PM Nils Bruin  wrote:

> On Friday 26 April 2024 at 06:53:28 UTC-7 marc@gmail.com wrote:
>
> I have a suggestion to improve the situation, which is to do what the
> Sage_macOS app does.
>
> The app provides access to a local copy of the documentation stored inside
> the application bundle.  The files are reorganized slightly to remove
> duplication and then compressed with gzip.  The app views the files using
> cocoserver , which provides a
> slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior
> of that server is modified so that it adds a gzip header to any file named
> *.gz.  The browser automatically decompresses gzipped files served with
> such a header.  ("Coco" stands for "compressed content".)
>
>
> Yes, I was thinking in that direction too. Is there perhaps already a
> jupyter server extension that can serve files in a local directory? I bet
> we can instruct jupyterlab to point at a "localhost" url rather than at "
> doc.sagemath.org"
>
>
> Compressing the documentation reduces the size (of the English
> documentation) from about 600 GB to about 100 GB.
>
>
> You meant MB probably?
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/kzSWB8ps7VA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4e33bc5d-ba8e-419d-92a3-87977765ad86n%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/CALcZXRGFwTqZWkf%3DDkp6se_Gqo2z-BfwEK_eXiF0_kB1qDM%2BcQ%40mail.gmail.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Here 
<https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/> 
is a blog post which appears to corroborate my hypothesis that the 
duplicate libraries are being generated by XCode 15 and not by Sage's build 
system.

If the warnings are causing test failures it would probably be best to 
suppress them for now and somehow remember to re-enable them once the XCode 
bug gets fixed.

I still do not understand why adding -Wl,-ld_classic to LDFLAGS in sage-env 
does not cause the old linker to be used when building some spkgs.  
Apparently the LDFLAGS environment variable is not used in those cases, but 
I don't know why not.

- Marc

On Thursday, April 25, 2024 at 11:30:52 PM UTC-5 Marc Culler wrote:

> This looks pretty complicated.
>
> I used XCode 15.0.1 to build the macOS SageMath-10-3 app for Arm and XCode 
> 13.4 for Intel.  I got "duplicate rpaths" and "duplicate libraries" 
> warnings with 15.0.1 but not with 13.4. I pasted typical gcc commands (from 
> cvxopt) below.  You can see that:
> (1) Both commands contain duplicate rpath specifications but XCode 13.4 
> does not warn about them
> (2) duplicate libraries and invalid library search paths only occur with 
> XCode 15.01.
> (3) With 15.0.1 the gcc command does not include the linker option 
> -ld_classic, so the code in sage-env is not actually succeeding in using 
> the  old linker.  (But the build works anyway.)
>
> It is not clear to me that Sage is responsible for the duplicates, since 
> it seems to depend on the XCode version, and it is not clear to me that the 
> code in sage-env that aims to use the old linker has any effect, on spkgs 
> anyway.
>  
> - Marc
>
> XCode 15.0.1 on Arm:
> ---
> gcc -bundle -undefined dynamic_lookup 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/macOSX.sdk/usr/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib
>  
> -L. -Wl,-rpath,. -L/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -O2 
> -mmacosx-version-min=11.0 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/base.o 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/dense.o 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/sparse.o 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib 
> -lm -lopenblas -lopenblas -o build/lib.macosx-11.0-arm64-cpython-311/cvxopt/
> base.cpython-311-darwin.so
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: ignoring duplicate libraries: '-lopenblas'
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: duplicate LC_RPATH are deprecated 
> ('/private/var/tmp/sage-10.3-current/local/lib')
>
> XCode 13.4 on Intel:
> 
> gcc -bundle -undefined dynamic_lookup 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-pla

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Fri, Apr 26, 2024 at 8:02 AM Dima Pasechnik  wrote:

> On Thu, Apr 25, 2024 at 4:36 PM  wrote:
>
> you might also like to know that in 2000 I asked whether we can have
> libgap :P
>
> https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html
> It
>

Thank you!  It is a struggle to convince people to make software reusable.
We are still struggling, but I do think there has been progress since the
turn of the century.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CALcZXRGL%3DJdfU4zcvW%3D8Wsez4DB0QVHVG7vNepk0yjOh2zwA%2BQ%40mail.gmail.com.

[sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Another drawback of linking to online documentation is that the online 
documentation is always for the current release version of Sage, not the 
Sage that the user happens to be running,.

I have a suggestion to improve the situation, which is to do what the 
Sage_macOS app does.

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)

Compressing the documentation reduces the size (of the English 
documentation) from about 600 GB to about 100 GB.

The app also makes some small changes to the files __main__.py and 
kernel.py in sage/repl/ipython_kernel to make jupyter add options to  its 
Help menu for viewing the Sage documentation.

- Marc

On Tuesday, April 9, 2024 at 4:52:23 PM UTC-5 Kwankyu Lee wrote:

> On Wednesday, April 10, 2024 at 1:30:21 AM UTC+9 Denis wrote:
>
> At some point the help menu in jupyter notebooks started pointing to 
> doc.sagemath.org instead of the locally built documentation. I wouldn't 
> mind having a configuration option not to build the documentation, in which 
> case, of course, this would be expected. However, because the documentation 
> is still built by default, it looks more like a bug than a feature. Any 
> thoughts?
>
>
> That was done because jupyterlab help menu does not support loading local 
> documentation. 
>
> See https://github.com/sagemath/sage/pull/36246
>
> Any idea to improve the situation? 
>

-- 
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/cee02859-39d1-473d-8ae3-f2c9984b8652n%40googlegroups.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

in.so
  ld: warning: passed two min versions (10.9, 10.9) for platform macOS. 
Using 10.9.
  ld: warning: passed two min versions (10.9, 10.9) for platform macOS. 
Using 10.9.
  ld: warning: passed two min versions (10.9, 10.9) for platform macOS. 
Using 10.9.

 - Marc


On Thursday, April 25, 2024 at 3:19:50 PM UTC-5 John H Palmieri wrote:

> Take a look at the discussion at 
> https://github.com/sagemath/sage/pull/36337, in particular 
> https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I 
> saw both "duplicate rpath" warnings and "duplicate library" warnings. Some 
> (maybe all, at least at that point) of the duplicate rpaths were removed by 
> https://github.com/sagemath/sage/pull/36364, but I don't know how to 
> prevent the duplicate libary warnings.
>
> -- 
> John
>
>
> On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:
>
>> Hi John,
>>
>> I have noticed that .dylib files generated by Sage often have as many as 
>> 3 identical rpaths.  (When building the macOS app I remove all rpaths and 
>> replace them with a single rpath which is relative, meaning it starts with 
>> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>>
>> I wonder if the "duplicate libraries" warnings are caused by duplicate 
>> rpath entries in the mach files.  I will try to test that hypothesis.
>>
>> Do you have any idea what could cause those duplicate rpaths?  Are there 
>> multiple -rpath options being passed to the compiler?
>>
>> - Marc
>>
>> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
>> wrote:
>>
>>> Hi Marc,
>>>
>>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>>> warnings about "ignoring duplicate libraries", and those cause doctest 
>>> failures. The lines could be modified to test whether xcode-select is 
>>> present and executable first, or since Sage now does indeed build without 
>>> `-ld-classic`, we could filter out the warnings when doctesting.
>>>
>>> -- 
>>> John
>>>
>>>
>>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>>> wrote:
>>>
>>>> Well, it almost solved the problem.
>>>>
>>>> It turns out that calling /usr/bin/gcc was not the only issue in 
>>>> sage-env.  That script also calls xcode-select.  On a system with no XCode 
>>>> app and no command line tools, calling gcc causes an error message to be 
>>>> printed to stderr and a dialog to open asking whether to install the 
>>>> command line tools.  Calling xcode-select on such a system prints the same 
>>>> error message but does not open the dialog. The error message appears in 
>>>> the terminal when running sage in a command line, which is annoying and/or 
>>>> alarming to someone with no plans to do anything involving compilation of 
>>>> C 
>>>> code.
>>>>
>>>> The calls to xcode-select were added in PR#36599 
>>>> <https://github.com/sagemath/sage/pull/36599> in order to force XCode 
>>>> to use Apple's ld-classic linker instead of ld when their new version of 
>>>> ld 
>>>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>>>
>>>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
>>>> think Apple's new linker is working now, so it is probably no longer 
>>>> necessary and not a good idea to force use of ld_classic.
>>>>
>>>> - Marc
>>>>
>>>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 Marc Culler wrote:
>>>>
>>>> That was it!
>>>>
>>>> Thank you Gonzalo; indeed, it helps a lot.  And your workaround is 
>>>> fine, since we don't support the -i option,  Even if we did, the default 
>>>> names for as, ld and ar are correct whenever the command line tools are 
>>>> installed.  So that block of code is completely irrelevant for the macOS 
>>>> platform.  This solves the problem.
>>>>
>>>> - Marc
>>>>
>>>>
>>>>
>>>> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>>>>
>>>> https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 
>>>> and L494
>>>>
>>>> See: https://github.com/sagemath/sage/issues/14296 and 
>>>> https://github.com/sagemath/sage/commit/69213d74ead4e936

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Thanks.

The xcode-select command always exists.
What works is to run the command with stderr redirected to /dev/null and 
then check $?.
I will open a PR.

- Marc
On Thursday, April 25, 2024 at 4:05:34 PM UTC-5 John H Palmieri wrote:

> I also don't know when the linker was fixed and whether we need to support 
> systems on which it is still broken. Anyway, if you want to open up a PR to 
> avoid the call to xcode-select, I'd be happy to take a look. We could also 
> revive some version of the branch at #36337 to filter out the warnings when 
> doctesting.
>
> -- 
> John
>
> On Thursday, April 25, 2024 at 1:19:50 PM UTC-7 John H Palmieri wrote:
>
>> Take a look at the discussion at 
>> https://github.com/sagemath/sage/pull/36337, in particular 
>> https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I 
>> saw both "duplicate rpath" warnings and "duplicate library" warnings. Some 
>> (maybe all, at least at that point) of the duplicate rpaths were removed by 
>> https://github.com/sagemath/sage/pull/36364, but I don't know how to 
>> prevent the duplicate libary warnings.
>>
>> -- 
>> John
>>
>>
>> On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:
>>
>>> Hi John,
>>>
>>> I have noticed that .dylib files generated by Sage often have as many as 
>>> 3 identical rpaths.  (When building the macOS app I remove all rpaths and 
>>> replace them with a single rpath which is relative, meaning it starts with 
>>> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>>>
>>> I wonder if the "duplicate libraries" warnings are caused by duplicate 
>>> rpath entries in the mach files.  I will try to test that hypothesis.
>>>
>>> Do you have any idea what could cause those duplicate rpaths?  Are there 
>>> multiple -rpath options being passed to the compiler?
>>>
>>> - Marc
>>>
>>> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
>>> wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>>>> warnings about "ignoring duplicate libraries", and those cause doctest 
>>>> failures. The lines could be modified to test whether xcode-select is 
>>>> present and executable first, or since Sage now does indeed build without 
>>>> `-ld-classic`, we could filter out the warnings when doctesting.
>>>>
>>>> -- 
>>>> John
>>>>
>>>>
>>>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>>>> wrote:
>>>>
>>>>> Well, it almost solved the problem.
>>>>>
>>>>> It turns out that calling /usr/bin/gcc was not the only issue in 
>>>>> sage-env.  That script also calls xcode-select.  On a system with no 
>>>>> XCode 
>>>>> app and no command line tools, calling gcc causes an error message to be 
>>>>> printed to stderr and a dialog to open asking whether to install the 
>>>>> command line tools.  Calling xcode-select on such a system prints the 
>>>>> same 
>>>>> error message but does not open the dialog. The error message appears in 
>>>>> the terminal when running sage in a command line, which is annoying 
>>>>> and/or 
>>>>> alarming to someone with no plans to do anything involving compilation of 
>>>>> C 
>>>>> code.
>>>>>
>>>>> The calls to xcode-select were added in PR#36599 
>>>>> <https://github.com/sagemath/sage/pull/36599> in order to force XCode 
>>>>> to use Apple's ld-classic linker instead of ld when their new version of 
>>>>> ld 
>>>>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>>>>
>>>>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): 
>>>>> I think Apple's new linker is working now, so it is probably no longer 
>>>>> necessary and not a good idea to force use of ld_classic.
>>>>>
>>>>> - Marc
>>>>>
>>>>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 Marc Culler wrote:
>>>>>
>>>>> That was it!
>>>>>
>>>>> Thank you Gonzalo; indeed, it helps a lot.  And your workaround is 
>>>>> fine, since we don't support the -i opti

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Hi John,

I have noticed that .dylib files generated by Sage often have as many as 3
identical rpaths.  (When building the macOS app I remove all rpaths and
replace them with a single rpath which is relative, meaning it starts with
@loader_path.  Apple will not notarize app bundles with absolute rpaths.)

I wonder if the "duplicate libraries" warnings are caused by duplicate
rpath entries in the mach files.  I will try to test that hypothesis.

Do you have any idea what could cause those duplicate rpaths?  Are there
multiple -rpath options being passed to the compiler?

- Marc

On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri 
wrote:

> Hi Marc,
>
> I just tried building Sage without `-ld-classic`. It builds, but I get
> warnings about "ignoring duplicate libraries", and those cause doctest
> failures. The lines could be modified to test whether xcode-select is
> present and executable first, or since Sage now does indeed build without
> `-ld-classic`, we could filter out the warnings when doctesting.
>
> --
> John
>
>
> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com wrote:
>
>> Well, it almost solved the problem.
>>
>> It turns out that calling /usr/bin/gcc was not the only issue in
>> sage-env.  That script also calls xcode-select.  On a system with no XCode
>> app and no command line tools, calling gcc causes an error message to be
>> printed to stderr and a dialog to open asking whether to install the
>> command line tools.  Calling xcode-select on such a system prints the same
>> error message but does not open the dialog. The error message appears in
>> the terminal when running sage in a command line, which is annoying and/or
>> alarming to someone with no plans to do anything involving compilation of C
>> code.
>>
>> The calls to xcode-select were added in PR#36599
>> <https://github.com/sagemath/sage/pull/36599> in order to force XCode to
>> use Apple's ld-classic linker instead of ld when their new version of ld
>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>
>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I
>> think Apple's new linker is working now, so it is probably no longer
>> necessary and not a good idea to force use of ld_classic.
>>
>> - Marc
>>
>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 Marc Culler wrote:
>>
>> That was it!
>>
>> Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine,
>> since we don't support the -i option,  Even if we did, the default names
>> for as, ld and ar are correct whenever the command line tools are
>> installed.  So that block of code is completely irrelevant for the macOS
>> platform.  This solves the problem.
>>
>> - Marc
>>
>>
>>
>> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>>
>> https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and
>> L494
>>
>> See: https://github.com/sagemath/sage/issues/14296 and
>> https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a
>>
>> Maybe you can workaround this by setting AS=as and LD=ld in
>> sage-env-config.
>>
>> HTH,
>> Gonzalo
>>
>>
>> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:
>>
>> I discovered, by installing the Sage_macOS app on a pristine macOS
>> system, that somehow, somewhere, in Sage's startup sequence there is a call
>> to gcc.  This is true whether Sage is being started from a command line or
>> a notebook.
>>
>> On such a macOS system /usr/bin/gcc exists, but calling it causes a
>> dialog to be posted which asks whether to download and install the Xcode
>> "command line tools".
>>
>> There is no need for a user to install, or be prompted to install, a C
>> compiler in order to run Sage.  If we want to verify whether a C compiler
>> is installed on the host system then we should check the return value of 
>> xcode-select
>> -p rather than calling /usr/bin/gcc.
>>
>> I am unable to find where this call occurs.  Do any of the Sage
>> developers know which component of Sage could be calling /usr/bin/gcc on
>> start up?
>>
>> - Marc
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/4s_5HmznHZM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubsc

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

The GAP project provides a native Windows installer 
<https://github.com/gap-system/gap/releases/download/v4.13.0/gap-4.13.0-x86_64.exe>.
  
So, evidently, it is possible to build GAP for Windows.  They do not seem 
to provide build instructions for Windows, however.

- Marc
 
On Thursday, April 25, 2024 at 9:17:35 AM UTC-5 Marc Culler wrote:

> Another amusing quote, this time from the sbrk man page on macOS:
>
> > The brk and sbrk functions are historical curiosities left over from
>  > earlier days before the advent of virtual memory management.
>
> That seems to be a paraphrase of the FreeBSD man page, which says:
>
> > The brk() and sbrk() functions are legacy interfaces from before the 
> advent of modern virtual
> > memory management. They are deprecated and not present on the arm64 or 
> riscv architectures.
> > The mmap(2) interface should be used to allocate pages instead.
>
> Given that GAP runs on arm64, I suspect that it doesn't use sbrk in an 
> essential way anymore.  Of course fork is a different story.  But there are 
> surely lots of examples of programs that use fork which have been ported to 
> Windows.  I would guess that emacs is among them.  (It has been ported to 
> Windows - I assume it uses fork on posix systems).
>
> - Marc
> On Thursday, April 25, 2024 at 9:03:30 AM UTC-5 Marc Culler wrote:
>
>> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
>>
>> Essential components of sagelib such as GAP, Singular, don't run on 
>> native Windows 
>>
>>
>> I was amused to find the following statement on the GAP forum 
>> <https://www.gap-system.org/ForumArchive2/2005/000999.html> from 2005:
>>
>>   >  While porting GAP to use native Win32 calls is doable, basically 
>> src/system.c is the only place
>>> that needs lots of changes, it is certainly a nontrivial and 
>> time-consuming task. (and one needs
>>> to be a bit of an expert in programming to do this, IMHO)
>>
>> The author was someone from the Netherlands by the name of *Dima 
>> Pasechnik.  :^)*
>>
>> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7e83fead-ed81-4536-9a64-0f7b1f391d72n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

Another amusing quote, this time from the sbrk man page on macOS:

> The brk and sbrk functions are historical curiosities left over from
 > earlier days before the advent of virtual memory management.

That seems to be a paraphrase of the FreeBSD man page, which says:

> The brk() and sbrk() functions are legacy interfaces from before the 
advent of modern virtual
> memory management. They are deprecated and not present on the arm64 or 
riscv architectures.
> The mmap(2) interface should be used to allocate pages instead.

Given that GAP runs on arm64, I suspect that it doesn't use sbrk in an 
essential way anymore.  Of course fork is a different story.  But there are 
surely lots of examples of programs that use fork which have been ported to 
Windows.  I would guess that emacs is among them.  (It has been ported to 
Windows - I assume it uses fork on posix systems).

- Marc
On Thursday, April 25, 2024 at 9:03:30 AM UTC-5 Marc Culler wrote:

> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
>
> Essential components of sagelib such as GAP, Singular, don't run on 
> native Windows 
>
>
> I was amused to find the following statement on the GAP forum 
> <https://www.gap-system.org/ForumArchive2/2005/000999.html> from 2005:
>
>   >  While porting GAP to use native Win32 calls is doable, basically 
> src/system.c is the only place
>> that needs lots of changes, it is certainly a nontrivial and 
> time-consuming task. (and one needs
>> to be a bit of an expert in programming to do this, IMHO)
>
> The author was someone from the Netherlands by the name of *Dima 
> Pasechnik.  :^)*
>
> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0fad0dee-9a92-40f3-854a-412acca934e1n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:

Essential components of sagelib such as GAP, Singular, don't run on 
native Windows 


I was amused to find the following statement on the GAP forum 
 from 2005:

  >  While porting GAP to use native Win32 calls is doable, basically 
src/system.c is the only place
   > that needs lots of changes, it is certainly a nontrivial and 
time-consuming task. (and one needs
   > to be a bit of an expert in programming to do this, IMHO)

The author was someone from the Netherlands by the name of *Dima 
Pasechnik.  :^)*

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik  wrote:

> On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield 
> wrote:
> >
> > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
> >
> > Yes, native Windows would clearly be a very important target.
> >
> >
> > As a data point, downloads of our stand-alone SnapPy app, which is about
> as high level pure math as it gets, are 60% higher for Windows than macOS.
>
> That's not for native Windows, that's for WSL, right?
>

Wrong!  SnapPy runs as a native Windows app.

We build Pari with msys2 and mingw on a CI runner.

Essential components of sagelib such as GAP, Singular, don't run on
> native Windows (on Cygwin, yes, but
> we know by now, Cygwin is too flaky for Sage to work) and I don't
> think anyone is keen on
> doing the hard work to port it.
>

Msys2 and mingw are not so flaky, and use more or less the same toolchain
as Cygwin.  There are many ports of gnu libraries to msys2 which can be
installed with their package manage (pacman).  I am not convinced that GAP,
Singuler, etc. could not be built with mingw.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CALcZXRFLMGZN4Sd6A_VwXzPRnSg%3DRtsT5Am1gEsJtELS5ez9Vg%40mail.gmail.com.

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Well, it almost solved the problem.

It turns out that calling /usr/bin/gcc was not the only issue in sage-env.  
That script also calls xcode-select.  On a system with no XCode app and no 
command line tools, calling gcc causes an error message to be printed to 
stderr and a dialog to open asking whether to install the command line 
tools.  Calling xcode-select on such a system prints the same error message 
but does not open the dialog. The error message appears in the terminal 
when running sage in a command line, which is annoying and/or alarming to 
someone with no plans to do anything involving compilation of C code.

The calls to xcode-select were added in PR#36599 
<https://github.com/sagemath/sage/pull/36599> in order to force XCode to 
use Apple's ld-classic linker instead of ld when their new version of ld 
was totally broken.  This is done by adding -ld_classic to LDFLAGS.

*Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
think Apple's new linker is working now, so it is probably no longer 
necessary and not a good idea to force use of ld_classic.

- Marc

On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 Marc Culler wrote:

That was it!

Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine, 
since we don't support the -i option,  Even if we did, the default names 
for as, ld and ar are correct whenever the command line tools are 
installed.  So that block of code is completely irrelevant for the macOS 
platform.  This solves the problem.

- Marc



On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:

https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and L494

See: https://github.com/sagemath/sage/issues/14296 and 
https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a

Maybe you can workaround this by setting AS=as and LD=ld in sage-env-config.

HTH,
Gonzalo


On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:

I discovered, by installing the Sage_macOS app on a pristine macOS system, 
that somehow, somewhere, in Sage's startup sequence there is a call to 
gcc.  This is true whether Sage is being started from a command line or a 
notebook.

On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
to be posted which asks whether to download and install the Xcode "command 
line tools".

There is no need for a user to install, or be prompted to install, a C 
compiler in order to run Sage.  If we want to verify whether a C compiler 
is installed on the host system then we should check the return value of 
xcode-select 
-p rather than calling /usr/bin/gcc.

I am unable to find where this call occurs.  Do any of the Sage developers 
know which component of Sage could be calling /usr/bin/gcc on start up?

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e76f6487-ddd9-46a6-a08e-0218e2b45850n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Wed, Apr 24, 2024 at 2:26 PM Oscar Benjamin 
wrote:

> Presumably though a hypothetical person who wants CyPari2 but not all of
> Sage can already just use CyPari so that person is already well served.
>

That hypothetical person could also use CyPari2 if they didn't care about
memory leaks and they were not running Windows.

I am wondering how representative the CyPari case is compared to other parts
> of Sage.


That is a good question.  Dima says it is not representative.

I think there are different types of hypothetical people: users and
developers.  Users should just install all of sage.  But one copy of a
software package that size should be enough.  Developers producing smaller
more specialized packages would benefit from being able to embed or require
as dependencies some parts of Sage, without having to turn a modestly sized
package into a monster.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CALcZXRHtqYAfxyBss_wR7Mzipch9EQfNWuUESip5nCuQ%2BSb3XA%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

I think that CyPari ;and CyPari2 provide a relevant example.

Some background ... CyPari is a PyPi package with binary wheels which
predates and was the starting point for Sage's cypari2 (hence the 2 in the
name).   The basis for CyPari was Sage's pari module.  That module was
modified to make it independent from the rest of Sage so that Sage's Pari
support could be provided as a component of SnapPy. Binary wheels for
CyPari are available for Windows, macOS and manylinux.  The current
versions of those wheels are statically linked against Pari 2.15.4

The binary wheel for CyPari weighs in at 7MB.  Sage's CyPari2 is available
as a binay wheel for macOS and manylinux and the size is of the same order
of magnitude.  When they are unpacked and installed the sizes of these
python packages are respectively 19MB and 7.5MB (cypari2 is linked against
the dynamic libraries libgmp and libpari, which together are about 12MB and
which are external to the python package).  A full Sage installation is
about 5 gigabytes.  With some significant omissions and compression of the
documentation, the macOS app squeezes that down to 3.4GB.

So the size of this one significant self-contained component of sage is
about 200 times smaller than the full sage installation and it could be
made installable on Windows with some additional work which has already
been done for a very closely related package.

- Marc


On Wed, Apr 24, 2024 at 8:48 AM Oscar Benjamin 
wrote:

> On Tue, 23 Apr 2024 at 15:27, Marc Culler  wrote:
> >
> > The projects that will really benefit from modularization will be those
> that provide their own limited mathematical context.  Developers of such
> projects will be able to choose which parts of Sage are relevant to their
> specific context.  Those parts of Sage can be provided for their users
> without having to embed a huge monolithic environment into a relatively
> small project.
>
> Is the benefit in this case mainly about reduced disk/network usage?
>
> I could imagine other theoretical benefits like maybe some parts could
> be installed natively on Windows or some parts might be easier to
> provide binaries for etc.
>
> Are there any indicative numbers for what the size would be when
> installing some useful portion of Sage vs installing the whole of
> Sage?
>
> --
> Oscar
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/mqgtkLr2gXY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAHVvXxQUanPY%3D1svhf7Q8xDFD5BroD9wTLRc1-wmFC3vQhBMRg%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/CALcZXREFctqVF8Hr1B%2Bmz9WfhV9Dspop5EmWN7Q%2BsYdJLvnh4w%40mail.gmail.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote:

running Cython in sage prompt or in Sage Jupyter notebook has nothing 
to do with -i option.


I realize that.  But it looked to me like those variables are being set in 
the sage-env script *primarily* to support sage -i.  Perhaps you are right 
that it is *primarily* to support compiling cython, but it doesn't look 
like it to me.  In any case, on macOS the default vaues work fine.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9d670ddb-ba2d-4c60-9fc2-5b0c1c209e3cn%40googlegroups.com.

Re: [sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

On Tuesday, April 23, 2024 at 11:17:49 PM UTC-5 Marc Culler wrote:


I wonder if the Sage community would be willing to reconsider the idea of 
having one entry point for every function provided by SageMath,


I won't speak for the community, but I reconsidered this and I decided that 
it would be better to leave the structure of the sage script as it is.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/464598cc-71b7-4df8-abd1-22afaa56dd65n%40googlegroups.com.

Re: [sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

On Tuesday, April 23, 2024 at 8:58:58 PM UTC-5 Dima Pasechnik wrot

It's not quite correct to say that a C, or other, compiler is not required 
to run Sage. Sage allows you to define, build, load, and run Cython 
extensions without leaving Sage, thus, it needs to call a compiler after 
cythonisation step. 

It's another question why it's called on startup.


Yes. If a user were trying to compile cython code on a machine with no 
compiler it would make sense to post a warning and offer to install a 
compiler.  But it does not make sense to impose that warning and offer on a 
user who is not doing anything that needs a compiler.
 

Might be macOS - only ?


The xcode-select behavior is macOS only, of course.  But the code block 
that Gonzalo pointed us to is run for *every* invocation of Sage on every 
platform.  Its purpose is to determine whether the platform has 
non-standard names for the gcc assembler, linker or archiver, which 
evidently can occur in some rare cases.  It does this by calling $CC with a 
gcc-specific option which returns the name of one of these utiltiies (if 
$CC happens to be gcc).  While this is done for every invocation of sage, 
it is seems to be intended primarily for the sage -i command.

I wonder if the Sage community would be willing to reconsider the idea of 
having one entry point for every function provided by SageMath, with 
options determining which function is actually invoked.  This was a popular 
way of doing things at one time, but has been unfashionable for years as 
one can see, for example, by running man mkfs on linux.

Instead of having a single executable named sage with options like sage 
-python, sage -pip, sage -i, sage -gap, sage -singular etc. there could be 
separate executables: .sage, sage-python, sage-pip, sage-install sage-gap, 
sage-singular.  I think this would be clearer and simpler to implement.  It 
would be easier to make sure that only needed initializations are done - 
avoiding asking gcc for the name of its linker just because someone wants 
to run pip, for example.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c713bdb5-6112-4d7c-91cf-a56d01aaa2f4n%40googlegroups.com.

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

That was it!

Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine, 
since we don't support the -i option,  Even if we did, the default names 
for as, ld and ar are correct whenever the command line tools are 
installed.  So that block of code is completely irrelevant for the macOS 
platform.  This solves the problem.

- Marc



On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:

> https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and 
> L494
>
> See: https://github.com/sagemath/sage/issues/14296 and 
> https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a
>
> Maybe you can workaround this by setting AS=as and LD=ld in 
> sage-env-config.
>
> HTH,
> Gonzalo
>
>
> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:
>
>> I discovered, by installing the Sage_macOS app on a pristine macOS 
>> system, that somehow, somewhere, in Sage's startup sequence there is a call 
>> to gcc.  This is true whether Sage is being started from a command line or 
>> a notebook.
>>
>> On such a macOS system /usr/bin/gcc exists, but calling it causes a 
>> dialog to be posted which asks whether to download and install the Xcode 
>> "command line tools".
>>
>> There is no need for a user to install, or be prompted to install, a C 
>> compiler in order to run Sage.  If we want to verify whether a C compiler 
>> is installed on the host system then we should check the return value of 
>> xcode-select 
>> -p rather than calling /usr/bin/gcc.
>>
>> I am unable to find where this call occurs.  Do any of the Sage 
>> developers know which component of Sage could be calling /usr/bin/gcc on 
>> start up?
>>
>> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1fe1fca2-f228-45eb-9f43-a1d1be5d5895n%40googlegroups.com.

[sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

I discovered, by installing the Sage_macOS app on a pristine macOS system, 
that somehow, somewhere, in Sage's startup sequence there is a call to 
gcc.  This is true whether Sage is being started from a command line or a 
notebook.

On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
to be posted which asks whether to download and install the Xcode "command 
line tools".

There is no need for a user to install, or be prompted to install, a C 
compiler in order to run Sage.  If we want to verify whether a C compiler 
is installed on the host system then we should check the return value of 
xcode-select 
-p rather than calling /usr/bin/gcc.

I am unable to find where this call occurs.  Do any of the Sage developers 
know which component of Sage could be calling /usr/bin/gcc on start up?

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a3a6a0e5-a49a-4b90-b9d0-e9515093c745n%40googlegroups.com.

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Tuesday, April 23, 2024 at 4:07:37 AM UTC-5 Tobias wrote:

In reply to the comment (
https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677)

 once the modularization is in place, it will impose wide-ranging 
constraints on what functions from other modules you are able to use. 
Currently, you can use `sage.x` in `sage.y` for an arbitrary combination of 
`x` and `y`. The modularization project restricts this severely and you 
will only be able to use modules `x` that are declared as a dependency of 
`y` (the arrows in the picture in 
https://github.com/sagemath/sage/pull/35095).


This comment seems to me to reflect a basic misunderstanding of the goal of 
modularization.  The author is assuming that Sage users will have to make 
choices about which parts of Sage to install and find many things missing.  
But Sage users should, as they do now, install all of Sage -- everything 
should be available to a user who does a normal install of Sage.  The 
projects that will really benefit from modularization will be those that 
provide their own limited mathematical context.  Developers of such 
projects will be able to choose which parts of Sage are relevant to their 
specific context.  Those parts of Sage can be provided for their users 
without having to embed a huge monolithic environment into a relatively 
small project.  For example, people studying 3-manifolds mainly need to 
work with simplicial complexes, groups, polynomials, number fields and 
interval arithmetic.  They do not need many other large parts of Sage, such 
as abstract manifolds (since all 3-manifolds can be triangulated).

This is basically a tautological argument, saying that modularization will 
cause modularization.  It does not reflect the reality for *users*.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/085048b3-a1f4-45db-8513-12516794d24an%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Sunday, April 21, 2024 at 9:42:24 AM UTC-5 Nathan Dunfield wrote:

For the statements in this thread, I don't see any contradictions about the 
definition of the "normal Python way of doing things".  My understanding of 
that term is to post *self-contained* binary wheels to PyPI for all 
supported platforms that install in a minute or two with no compilation (as 
Dima wrote), as well as a source-code only package that serves as a 
rarely-used backup if no suitable binary is available.  (The self-contained 
bit is important; for example, on Linux here are the only external libraries 
 a binary wheel is 
allowed to link to.)


I  hope it will help to acknowledge what might be regarded as the elephant 
in this room.  That elephant consists of two facts:

1) *Users*, as opposed to *developers*, are very unlikely to be either 
willing to or capable of building a complex source-code only package which 
depends on external libraries, because doing that requires finding and 
installing (or building from source), all of the external libraries needed 
by the python package.

2) The use of a *self-contained *binary wheel on linux violates a core 
principle of linux packaging, namely that any library which is a runtime 
dependency of a package should be installed from the appropriate distro 
package.

Note that 2) also means that a pypi package developer must support the full 
range of different versions of these libraries which are provided by 
different linux distributions.  Sage initially used the same principle in 
its design, but avoided the maintenance burden caused by trying to support 
all of these different library versions by providing its own libraries in 
SAGE_LOCAL.  It has since gradually accepted more and more of the burden by 
allowing "system versions" of libraries wherever it seemed feasible.

In the "Python ecosystem" these issues have been worked around in a 
different way in order to make *self-contained* binary wheels a 
possibility, and thereby accommodate *users*.  This is usually done with 
delocate on macOS or with auditwheel on linux.  Those tools embed all of 
the required libraries inside the python package and adjust the rpaths in 
the python extension modules to make them use the embedded libraries 
instead of libraries which might or might not be installed on the host 
system.  In the case of linux this also means compiling the libraries 
against a version of glibc which is older than the version found on any of 
the linux distributions supported by the package.  The job of building 
libraries against old versions of glibc is done by building them on a 
manylinux docker image, which can be done on a CI runner.  (On macOS one 
can specify a minimum target version of macOS, usually 10.12 these days.)

As a typical example (which recently created issues for Sage related to the 
jpeg library) you can look at the binary wheel for Pillow.  If you unzip 
that wheel you will find a subdirectory named pillow.libs which contains: 
libbrotlicommon-3ecfe81c.so.1,  libpng16-58efbb84.so.16.43.0, 
libbrotlidec-ba690955.so.1, libsharpyuv-20f78091.so.0.0.1, 
libfreetype-1f2cdfbb.so.6.20.1, libtiff-4da6744b.so.6.0.2, 
libharfbuzz-8b0b6641.so.0.60840.0,libwebp-850e2bec.so.7.1.8, 
libjpeg-f391b078.so.62.4.0, libwebpdemux-df9b36c7.so.2.0.14, 
liblcms2-e69eef39.so.2.0.16,libwebpmux-9fe05867.so.3.0.13, 
liblzma-13fa198c.so.5.4.5,libXau-154567c4.so.6.0.0, libopenjp2-05423b53.so 
, and libxcb-80c5a837.so.1.1.0.  A linux packager would provide all of 
these by adding as dependencies all of the distro packages needed to 
provide these libraries.  In the "Python ecosystem" these libraries are all 
built on manylinux docker images and then embedded in the binary wheel.

I don't see how Sage will be able to join the Python ecosystem without 
addressing this.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e96d4c08-25d7-466b-b9fd-6e76b6b740e5n%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Revert merged PR with unreviewed dependencies

[Marc Culler]

On Thursday, April 18, 2024 at 12:47:36 PM UTC-5 David Roe wrote:

On Thu, Apr 18, 2024 at 1:43 PM Matthias Koeppe wrote:

I will first note that the title of this post is misleading.
Everything that was merged has been reviewed -- as noted, many months ago.


I agree that everything was reviewed. 


And that is why I vote -1 on reverting the merge.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b14df2d2-bfea-4cbb-afd4-706ad925e739n%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Marc Culler]

+1 on making python_build a standard package.

- Marc

On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:

> We added python_build as an optional "pip" package (see 
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>  for 
> the terminology),
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>  (added 
> in 2022).
>
> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
> making source distributions and wheels from a Python source tree. It has 
> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
> bdist_wheel" directly. We already use it for building the modularized 
> distribution packages. Making it a standard package will allow us to 
> modernize the build infrastructure (front-end) for the Sage library in the 
> Sage distribution.
>
> I'm proposing to make it a standard package according to the procedures in 
> our developer guide. Per our policy, that's a "normal" package, so its 
> dependency pyproject_hooks will also be added. The PR is prepared in 
> https://github.com/sagemath/sage/pull/37300 
>
> This is a re-do of my proposal 
> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
> discussion was stalled by commenters bundling it with political demands. 
>
>

-- 
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/6bb5958c-04a7-4f8f-bf94-79b9dc7139a5n%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Marc Culler]

On Monday, April 15, 2024 at 7:03:27 AM UTC-5 Michael Orlitzky wrote:

The solution for users is pretty simple. You should be able to install 
a sage that works and will remain working with one command using 
homebrew, conda, guix, etc. The reason you can't is ...


I would just mention that macOS users who have homebrew can install Sage by 
typing one command:
$ brew install sage
and macOS users who do not have homebrew can install Sage by downloading a 
disk image and dragging the SageMath app into their Application folder.  
Both operations install the identical software and both produce a sage that 
works and will remain working and that is the most recently released 
version of sage.

This is true with the current configuration of Sage.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c88f75df-9ff5-44e6-b6e5-6c8aacb495ban%40googlegroups.com.

Re: [sage-devel] Mysterious .sage behavior

[Marc Culler]

The problem that it *causes* is that people think that Sage has somehow 
managed to install an ancient ipython-5.0.0 in their ~/.sage directory.  
The user that reported this was indeed having problems because of an out of 
date ipython thet they had installed with %pip.  The python package was 
installed as a --user package  in  ~/.sage.   That is where the macOS app 
installs all pip packages, being disallowed from putting them into the app 
bundle itself because that would break the signature and macOS would then 
refuse to run the app..

The old version of ipython caused the new app to crash with the rather 
amazing error message "object of type List is not iterable".  When the user 
removed their ~/.sage directory everything worked as expected.  But then, 
after starting Sage,  they checked to see what was actually in the 
directory, and were alarmed to ",find" that Sage had re-installed 
ipython-5.0.0.

As I said, this idea confuses users, and understandably so.  It was not a 
great idea. There were so many other, better, ways of naming the directory.

Maybe for the next Sage release I will move the pip packages to 
~/Library/SageMath-X.Y.  That won't stop Sage from creating 
~/.sage/ipython-5.0.0 but it will remove the motivation for users to look 
in the .sage directory and get confused.

- Marc

On Monday, April 1, 2024 at 3:31:06 PM UTC-5 Nils Bruin wrote:

> One scenario where I could see this being beneficial:
> These configurations are written into `$HOME/.sage` (normally), so that is 
> not a location that is predicated by a venv or a localized subdir. If a 
> user is using two different sagemath installs (e.g., one system, the other 
> for development) that have incompatible ipython configs, they need to live 
> in places that allow peaceful co-existence. This would do it. I agree the 
> version number can look confusing, It seems like a historic artifact that 
> we didn't need to change our ipython configs since version 5.0.0, probably. 
> It looks to me like a fairly arbitrary choice how to mark that directory 
> name. Not changing it would be the easiest solution, but if someone wants 
> to make an argument that another naming convention has benefits (following 
> common practices that have since evolved?) it could be changed, at the 
> expense of everyone with an install needing to change locations of files 
> they already customized. So based on that, I think the best time to change 
> it (if at all) would be when an incompatible change in config is happening 
> anyway.
>
>
> On Monday 1 April 2024 at 12:20:16 UTC-7 Dima Pasechnik wrote:
>
>
> I must say I don't know what kind of problems these versioned names are 
> meant to solve. 
>
>  
>
> >On 31 March 2024 15:23:24 CEST, Marc Culler  <https://groups.google.com/>> wrote :  
>
> >if [ -z "$IPYTHONDIR" ]; then 
> > # We hardcode a version number in the directory name. The idea is 
> > # that we keep using the same version number as long as that is 
> > # possible. Only when some future IPython version really requires 
> > # a new structure for the $IPYTHONDIR should this version number be 
> > # changed to the new IPython version. 
> > export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0" 
> >fi 
>
>

-- 
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/fe00c9f6-0b3f-4adb-92e8-817c022873b2n%40googlegroups.com.

[sage-devel] Mysterious .sage behavior

[Marc Culler]

This is a follow-up to a user's query in a Sage_macOS issue. 

The current sage-env script contains the excerpt below.  It seems pretty 
confusing that  Sage would create a directory named .sage/ipython-5.0.0 
when Sage is shipping IPython 8.18.1.  What would be wrong with calling the 
directory .sage/profiles/ipython--v1, and moving to ipython--v2 when 
necessary?  Similarly for jupyter and matplotlib.

- Marc

if [ -z "$IPYTHONDIR" ]; then
# We hardcode a version number in the directory name. The idea is
# that we keep using the same version number as long as that is
# possible. Only when some future IPython version really requires
# a new structure for the $IPYTHONDIR should this version number be
# changed to the new IPython version.
export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0"
fi

if [ -z "$JUPYTER_CONFIG_DIR" ]; then
# We hardcode a version number in the directory name. The idea is
# that we keep using the same version number as long as that is
# possible. Only when some future Jupyter version really requires
# a new structure for the $JUPYTER_CONFIG_DIR should this version
# number be changed to the new jupyter_core version.
export JUPYTER_CONFIG_DIR="$DOT_SAGE/jupyter-4.1"
fi

if [ -z "$MPLCONFIGDIR" ]; then
# We hardcode a version number in the directory name. The idea is
# that we keep using the same version number as long as that is
# possible. Only when some future Matplotlib version really requires
# a new structure for the $MPLCONFIGDIR should this version
# number be changed to the new matplotlib version.
export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"
fi

-- 
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/81f74c4a-1ff3-406f-a9c3-36330d014514n%40googlegroups.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Marc Culler]

According to  Hacker News <https://news.ycombinator.com/item?id=39866076>:
> openssh does not directly use liblzma. However debian and several other 
distributions patch openssh to support systemd notification, and libsystemd 
does depend on lzma.

So this hack was not targeting ssh in general, just ssh on certain linux 
distros.

I would NOT suggest that "for your security" Sage should stop supporting 
linux.

- Marc
On Saturday, March 30, 2024 at 9:08:45 AM UTC-5 Marc Culler wrote:

> > Potentially, any tarfile we host may contain an exploit. 
>
> Potentially, any file may contain an exploit.
>
> This hack specifically targeted ssh.  When used by ssh to verify keys, the 
> hacked liblzma would validate certain invalid keys, allowing a "back door" 
> for a particular bad actor to login to the system.
>
> I don't think that the Sage liblzma  could ever end up being the one used 
> by ssh.
>
> We all know how many things are justified as being "for your security" 
> when in fact they do nothing to increase anyone's security and are really 
> just advancing someone's private agenda.
>
> - Marc
>
> On Saturday, March 30, 2024 at 7:35:20 AM UTC-5 Dima Pasechnik wrote:
>
>> On Fri, Mar 29, 2024 at 7:42 PM Dima Pasechnik  wrote: 
>> > 
>> > On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe 
>> >  wrote: 
>> > > 
>> > > Workaround with the Sage distribution: "./configure 
>> --without-system-liblzma --without-system-xz" 
>> > > (Our xz package dates back from before the attackers were born;) 
>> > > 
>> > > Incidentally, the cryptographic protection of the Sage distribution 
>> is wildly insufficient. 
>> > > I've opened https://github.com/sagemath/sage/issues/37691 for this 
>> -- any takers? 
>> > 
>> > I'd switch to sha256. 
>> > And require PGP-signed commits, etc. 
>> > 
>> > well, I can't even comment on that issue :-) 
>>
>> By the way, the essential part of xz backdoor was sneaked in as a 
>> modified copy of a gnulib m4 macros file. 
>> As this is "the" way to use gnulib - just vendor what they provide in 
>> your source code - one may wonder again 
>> about the virtues of vendoring a lot of code. 
>> Potentially, any tarfile we host may contain an exploit. 
>>
>> As well as anything produced on CI, VM, or, real, hosts running 
>> compromised OS (latest unstable versions of Debian and Fedora were 
>> compromised with this xz hack, Homebrew was, as well). So this is 
>> something to review urgently, too. 
>>
>> Dima 
>>
>>
>>
>>
>> > 
>> > 
>> > > 
>> > > 
>> > > On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote: 
>> > >> 
>> > >> https://www.openwall.com/lists/oss-security/2024/03/29/4 
>> > >> 
>> > >> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian 
>> testing/unstable) 
>> > >> you have a backdoored xz. 
>> > > 
>> > > -- 
>> > > 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/d75e7cc9-9743-4c20-b502-431d400dc5f2n%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/18a03aef-1d90-4e7f-9520-ddb2c17ef18fn%40googlegroups.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Marc Culler]

> Potentially, any tarfile we host may contain an exploit. 

Potentially, any file may contain an exploit.

This hack specifically targeted ssh.  When used by ssh to verify keys, the 
hacked liblzma would validate certain invalid keys, allowing a "back door" 
for a particular bad actor to login to the system.

I don't think that the Sage liblzma  could ever end up being the one used 
by ssh.

We all know how many things are justified as being "for your security" when 
in fact they do nothing to increase anyone's security and are really just 
advancing someone's private agenda.

- Marc

On Saturday, March 30, 2024 at 7:35:20 AM UTC-5 Dima Pasechnik wrote:

> On Fri, Mar 29, 2024 at 7:42 PM Dima Pasechnik  wrote:
> >
> > On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
> >  wrote:
> > >
> > > Workaround with the Sage distribution: "./configure 
> --without-system-liblzma --without-system-xz"
> > > (Our xz package dates back from before the attackers were born;)
> > >
> > > Incidentally, the cryptographic protection of the Sage distribution is 
> wildly insufficient.
> > > I've opened https://github.com/sagemath/sage/issues/37691 for this -- 
> any takers?
> >
> > I'd switch to sha256.
> > And require PGP-signed commits, etc.
> >
> > well, I can't even comment on that issue :-)
>
> By the way, the essential part of xz backdoor was sneaked in as a
> modified copy of a gnulib m4 macros file.
> As this is "the" way to use gnulib - just vendor what they provide in
> your source code - one may wonder again
> about the virtues of vendoring a lot of code.
> Potentially, any tarfile we host may contain an exploit.
>
> As well as anything produced on CI, VM, or, real, hosts running
> compromised OS (latest unstable versions of Debian and Fedora were
> compromised with this xz hack, Homebrew was, as well). So this is
> something to review urgently, too.
>
> Dima
>
>
>
>
> >
> >
> > >
> > >
> > > On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
> > >>
> > >> https://www.openwall.com/lists/oss-security/2024/03/29/4
> > >>
> > >> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian 
> testing/unstable)
> > >> you have a backdoored xz.
> > >
> > > --
> > > 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/d75e7cc9-9743-4c20-b502-431d400dc5f2n%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/032d5e0b-815b-4504-9eb5-7fd598a5e2d8n%40googlegroups.com.

[sage-devel] Downloads

[Marc Culler]

In case anyone is interested ...
The SageMath 10.3 app for macOS has been downloaded 684 times since it was 
released on Sunday.  The SageMath 10.2 app was downloaded 8685 times since 
its release about 4 months ago.  For both versions, Arm downloads outnumber 
Intel by about 2 to 1.

Source: https://api.github.com/repos/3-manifolds/Sage_macOS/releases

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2ace005a-5ed0-49b4-b4ea-8f542ea057can%40googlegroups.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Marc Culler]

By looking at the pari-jupyter page on PYPI I learned that it was written 
by Jeroen Demeyer and is maintained by the SageMath Developers.  So I guess 
I don't understand what the relation is between SageMath and pari-jupyter.  
Will pari-jupyter be competing with the kernel that Bill Allombert is 
writing?  Is there a reason why he is writing a kernel when one already 
exists?  Obviously I have no idea what I am talking about and am publicly 
revealing my ignorance.

- Marc


On Friday, March 22, 2024 at 12:29:56 PM UTC-5 Marc Culler wrote:

> I wasn't advocating anything like that.  Certainly I don't think that 
> pari-jupyter should be "killed".  I am assuming that pari-jupyter is or 
> will be a package that can be installed with pip.  And I am also assuming 
> that it has no direct interaction with Sage.  Are those assumptions wrong?  
> If not, what benefit does the pari-jupyter project get from having it 
> available as a sage spkg?
>
> A question of more relevance to me is: do I need to add pari-jupyter to 
> the Sage_macOS binary package, even though it could be installed separately 
> by just running pip?  (We try to add all optional packages the we can 
> build.). If installing pari-jupyter creates a kernel specification 
> directory in /usr/local/share (as we do for the Sage kernel), then it will 
> appear as an available kernel when jupyter is launched from the SageMath 
> app, whether or not the location of the kernel is inside the app bundle.  
> How does it improve our user's experience to have the package installed 
> inside of the app bundle, as opposed to in the user's Library/Python 
> directory or inside the python.org framework?  While this question is 
> specific to me, I think the same question applies to SageMath.
>
> - Marc
>
>
> On Friday, March 22, 2024 at 12:13:34 PM UTC-5 Matthias Koeppe wrote:
>
>> Let me just point out that the idea that "grant has ended, so we can kill 
>> its deliverables" is fundamentally flawed, and certainly is not and cannot 
>> be the position of our project.
>>
>> Infrastructure grants are exactly set up for their longer-term and 
>> broader impacts. 
>>
>> Matthias
>>
>> On Friday, March 22, 2024 at 5:58:47 AM UTC-7 Dima Pasechnik wrote:
>>
>>> I don't see any reason for pari-jupyter being a sage package. It has 
>>> nothing in common with sagelib, it's a standalone jupyter kernel for 
>>> Pari-GP.
>>> It has ended up in sage in OpenDreamKit times, to make granting agency 
>>> happy.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  
>>> wrote:
>>>
>>>> Bill Allombert has been working on a kernel via xeus:
>>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>>> Which addresses many of the issues with the current one.
>>>> While we for its first stable release, I recommend mine: 
>>>> https://github.com/edgarcosta/gp_kernel/
>>>> where I have addressed many of the issues, by going through the route 
>>>> that every cell is a temporary file, which is loaded in gp.
>>>>
>>>>
>>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe  
>>>> wrote:
>>>>
>>>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just 
>>>>> point to the main sagemath repository
>>>>> - using WIP sage-project-cookiecutter to simplify maintenance 
>>>>> https://github.com/sagemath/sage/pull/37541
>>>>>
>>>>> -- 
>>>>> 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/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>>> 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/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
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/c319f93a-7d6a-4876-9066-b1566a9a6c95n%40googlegroups.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Marc Culler]

I wasn't advocating anything like that.  Certainly I don't think that 
pari-jupyter should be "killed".  I am assuming that pari-jupyter is or 
will be a package that can be installed with pip.  And I am also assuming 
that it has no direct interaction with Sage.  Are those assumptions wrong?  
If not, what benefit does the pari-jupyter project get from having it 
available as a sage spkg?

A question of more relevance to me is: do I need to add pari-jupyter to the 
Sage_macOS binary package, even though it could be installed separately by 
just running pip?  (We try to add all optional packages the we can build.). 
If installing pari-jupyter creates a kernel specification directory in 
/usr/local/share (as we do for the Sage kernel), then it will appear as an 
available kernel when jupyter is launched from the SageMath app, whether or 
not the location of the kernel is inside the app bundle.  How does it 
improve our user's experience to have the package installed inside of the 
app bundle, as opposed to in the user's Library/Python directory or inside 
the python.org framework?  While this question is specific to me, I think 
the same question applies to SageMath.

- Marc


On Friday, March 22, 2024 at 12:13:34 PM UTC-5 Matthias Koeppe wrote:

> Let me just point out that the idea that "grant has ended, so we can kill 
> its deliverables" is fundamentally flawed, and certainly is not and cannot 
> be the position of our project.
>
> Infrastructure grants are exactly set up for their longer-term and broader 
> impacts. 
>
> Matthias
>
> On Friday, March 22, 2024 at 5:58:47 AM UTC-7 Dima Pasechnik wrote:
>
>> I don't see any reason for pari-jupyter being a sage package. It has 
>> nothing in common with sagelib, it's a standalone jupyter kernel for 
>> Pari-GP.
>> It has ended up in sage in OpenDreamKit times, to make granting agency 
>> happy.
>>
>>
>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>>
>>> Bill Allombert has been working on a kernel via xeus:
>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>> Which addresses many of the issues with the current one.
>>> While we for its first stable release, I recommend mine: 
>>> https://github.com/edgarcosta/gp_kernel/
>>> where I have addressed many of the issues, by going through the route 
>>> that every cell is a temporary file, which is loaded in gp.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe  
>>> wrote:
>>>
 - https://pypi.org/project/pari-jupyter/1.4.3rc1/
 - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just 
 point to the main sagemath repository
 - using WIP sage-project-cookiecutter to simplify maintenance 
 https://github.com/sagemath/sage/pull/37541

 -- 
 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/e822f186-6504-4516-9940-d03398f270b9n%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/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%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/5337b5c3-49a7-4f35-9429-8d8351dc6115n%40googlegroups.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Marc Culler]

If one has Sage installed with the pari-jupyter package installed in Sage 
and one wants to run pari-jupyter, what does one do?  Is it equivalent to 
just installing pari-jupyter with pip and starting it up in the normal 
way?  Does pari-jupyter use any components of Sage?  If the answers are 
"yes" and "no", then I agree that it is hard to see any reason why it 
should be a Sage package.

- Marc

On Friday, March 22, 2024 at 7:58:47 AM UTC-5 Dima Pasechnik wrote:

> I don't see any reason for pari-jupyter being a sage package. It has 
> nothing in common with sagelib, it's a standalone jupyter kernel for 
> Pari-GP.
> It has ended up in sage in OpenDreamKit times, to make granting agency 
> happy.
>
>
> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>
>> Bill Allombert has been working on a kernel via xeus:
>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>> Which addresses many of the issues with the current one.
>> While we for its first stable release, I recommend mine: 
>> https://github.com/edgarcosta/gp_kernel/
>> where I have addressed many of the issues, by going through the route 
>> that every cell is a temporary file, which is loaded in gp.
>>
>>
>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe  
>> wrote:
>>
>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just 
>>> point to the main sagemath repository
>>> - using WIP sage-project-cookiecutter to simplify maintenance 
>>> https://github.com/sagemath/sage/pull/37541
>>>
>>> -- 
>>> 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/e822f186-6504-4516-9940-d03398f270b9n%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/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%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/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com.

[sage-devel] Re: Vote: changes to Sage's Code of Conduct

[Marc Culler]

+1

On Thursday, March 21, 2024 at 11:51:40 AM UTC-5 John H Palmieri wrote:

> Dear Sage community,
>
> As announced at 
> https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I 
> propose some changes to the Code of Conduct. Those changes have been 
> discussed and modified based on feedback from several developers: visit 
> https://github.com/sagemath/sage/pull/37501 for details. Those changes 
> are now ready for a vote here on sage-devel. 
>
> Please vote: do you approve the changes to the Code of Conduct proposed at 
> https://github.com/sagemath/sage/pull/37501? Please vote on or before 
> March 31.
>
> In case you want a summary: the old code of conduct was pretty short, so 
> some details were added, and whole new sections were added. The proposed 
> changes were greatly inspired by similar documents from the SciPy and 
> NumFOCUS projects, and the proposed code now includes sections on 
> diversity, how to report potential violations,  names of the committee 
> members, and what is necessary to amend the document. There is also a new 
> document, a manual for the Code of Conduct Committee, which describes what 
> that committee does and what actions it might take to respond to reports. 
> That document is a modified version of SciPy's corresponding document.
>
> -- 
> 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/d7c29f58-9e0a-4c09-8c5c-4afd5c44ffc3n%40googlegroups.com.

[sage-devel] Re: Jupyter Lab Sage menu

[Marc Culler]

It would also be a good idea to open the javascript console and see if 
there are errors being reported around the time when the menu disappears.

- Marc

On Wednesday, March 6, 2024 at 8:20:00 PM UTC-6 Marc Culler wrote:

> Viviane,
>
> If you do a shift-reload (or whatever makes your browser clear its cache) 
> does that make the menu come back?
>
> - Marc
>
> On Wednesday, March 6, 2024 at 8:11:45 AM UTC-6 Viviane Pons wrote:
>
>> Dear all,
>>
>> I am working on a conda distribution of sage with jupyter lab. My conda 
>> environnement is only:
>>
>> name: jupyter-sage
>>
>> channels:
>> - conda-forge
>>
>> dependencies:
>> - jupyterlab
>> - sage
>>
>>
>> It works fine. I can launch it with "jupyter lab" or "sage 
>> --notebook=jupyterlab". I noticed that I had access to a bunch of tutorial 
>> links in the help menu (which is great!) but somehow this menu appears and 
>> disappears in ways that I don't understand at all. Do you know how / when 
>> this menu appears? 
>>
>> I have attached two screenshots. The same worksheet with Sage kernel is 
>> opened in both. In one case, I have the menu, in the other not
>>
>> (it looks like the menu appears when I first open the notebook but then, 
>> at some point, it just disappears and never comes back unless I restart 
>> jupyter lab entirely)
>>
>> Best
>>
>> Viviane
>>
>

-- 
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/0adb0579-fc20-4674-b388-cb822bef69cdn%40googlegroups.com.

[sage-devel] Re: Jupyter Lab Sage menu

[Marc Culler]

Viviane,

If you do a shift-reload (or whatever makes your browser clear its cache) 
does that make the menu come back?

- Marc

On Wednesday, March 6, 2024 at 8:11:45 AM UTC-6 Viviane Pons wrote:

> Dear all,
>
> I am working on a conda distribution of sage with jupyter lab. My conda 
> environnement is only:
>
> name: jupyter-sage
>
> channels:
> - conda-forge
>
> dependencies:
> - jupyterlab
> - sage
>
>
> It works fine. I can launch it with "jupyter lab" or "sage 
> --notebook=jupyterlab". I noticed that I had access to a bunch of tutorial 
> links in the help menu (which is great!) but somehow this menu appears and 
> disappears in ways that I don't understand at all. Do you know how / when 
> this menu appears? 
>
> I have attached two screenshots. The same worksheet with Sage kernel is 
> opened in both. In one case, I have the menu, in the other not
>
> (it looks like the menu appears when I first open the notebook but then, 
> at some point, it just disappears and never comes back unless I restart 
> jupyter lab entirely)
>
> Best
>
> Viviane
>

-- 
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/83d29836-9ca3-429c-9223-55b11451ce27n%40googlegroups.com.

Re: [sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

[Marc Culler]

I see.  Thanks.

- Marc

On Wed, Feb 28, 2024 at 6:49 PM Kwankyu Lee  wrote:

>
>
> On Thursday, February 29, 2024 at 8:35:24 AM UTC+9 Marc Culler wrote:
>
> I have a proposal: It should be forbidden to call for a vote on a proposal
> before there has been a discussion.
>
>
> Sorry if it was not clear to you, but the discussion before this vote is
> here:
>
> https://groups.google.com/g/sage-devel/c/uWHaWK7b6H4
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/E0qfJTMETDk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/8e59075f-e7fa-403b-bf71-eb12fc57663en%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/8e59075f-e7fa-403b-bf71-eb12fc57663en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CALcZXREN27F4ngLLsULv9qR4%3Dwj7mhTWJDZ%2B9RsnU1AaiHPdvQ%40mail.gmail.com.

[sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

[Marc Culler]

I have a proposal: It should be forbidden to call for a vote on a proposal 
before there has been a discussion.

Without a chair, it would be impossible for this group to follow Robert's 
Rules of Order, even approximately.  But the basic process should still be 
the same. The rules are designed to allow a deliberative body to make 
progress. The steps are:
1. Somebody makes a proposal (motion).
2. Somebody else seconds the motion.  This prevents the group from wasting 
its time on a proposal supported by only one person.
3. The group discusses the proposal, perhaps amending it, usually with 
"friendly" amendments that the proposer agrees to.  The discussion makes it 
possible for the group to make an informed decision.
4. Then there is a vote.

- Marc

On Wednesday, February 28, 2024 at 12:45:03 AM UTC-6 Kwankyu Lee wrote:

> Hi, 
>
> Here I withdraw the early premature "giving up" on my recent proposal, 
> since afterwards there were some positive comments. Hence I open a voting 
> for 
>
> Proposal: 
>
> 1. Do not use "blocker" label for Issues, as "blocker" means to delay the 
> release.
> 2. Instead use "critical" label for a very serious and urgent Issue.
> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
> 4. Old Issues converted from trac with "critical" label will get the 
> "major" label instead. 
>
> Voting will end when there is no new vote for a week.
>
> This is a simple majority voting (following the standard on sage-devel 
> proposal)!
>
> A positive vote is for all parts of the Proposal. So if you do not like 
> any of (1) -- (4), cast a negative vote (-1).
>
>
> Happy voting! 
>

-- 
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/aef07a1c-70fa-488a-aa7e-6e1831eb2743n%40googlegroups.com.

[sage-devel] Re: Question about the sage venv.

[Marc Culler]

On Thursday, December 7, 2023 at 5:04:25 PM UTC-6 Matthias Koeppe wrote:

Sure, but that would preclude using the same SAGE_LOCAL for an installation 
with venv over a system python and an installation of SPKG python.


 
I don't understand.  The bash script sage/venv/bin/sage calls 
sage/venv/bin/python which is a symlink to a python executable.  It doesn't 
matter where that python executable is located.  It could be in 
sage/local/bin or it could be somewhere else.  (Of course, for a notarized 
macOS application it must be inside the application bundle, but that is a 
different story.)

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f731dd4f-dd40-46bb-b6d3-9edceb9e1dc2n%40googlegroups.com.

[sage-devel] Re: Question about the sage venv.

[Marc Culler]

On Thursday, December 7, 2023 at 2:31:24 PM UTC-6 Matthias Koeppe wrote:

> The venv would always contain a pyvenv.cfg file.

Could you explain why this matters for what you have in mind?


It is not essential.  It is just cleaner and more uniform.  I think it is 
misleading to have something called a venv which is missing one of the key 
required features of a venv.  And in the past I was misled by that.

 Also, it suggests something which I think would be an organizational 
improvement.  It could stop being the case that sage/local *never* contains 
any python.  Instead sage/local would be the prefix for Sage's installation 
of Python in the case where a system python is not being used.  The rule 
could be that if sage/local/lib/pythonX.Y exists then its site-packages 
subdirectory should be empty, with all Python packages being installed in 
the venv.  The venv would be a true venv and its symbolic link to an 
installed python would either be to the python installation in sage/local 
or to a python installation elsewhere on the system.

I would also suggest putting the venv at the top level, adjacent to local, 
rather than have a symlink adjacent to local which points into 
sage/local/var/sage.  I would find that to be a much more transparent 
layout.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/29c7ac41-3505-42f1-a53b-6b883b39957en%40googlegroups.com.

[sage-devel] Re: Question about the sage venv.

[Marc Culler]

Thank you, Matthias.

Now I have a followup question, which is the tip of an iceberg.  The 
iceberg consists of my thoughts about how to simplify and improve the 
organization of files in Sage.  I am not asking for a yes or no answer, or 
a list of possible problems. I am just trying to find out whether people 
would be willing to consider an idea.

Would it be possible for the sage build process to use sage/local as the 
unique "system location"?

The sage/local directory would be built by one stage of the sage build 
process, preceding the stage that builds the venv.  Inside sage/local one 
would find either files built by the sage build system, or symlinks to 
files in other locations on the host system, such as /usr/local, or 
/opt/local, or a conda directory.  The question of whether to use a symlink 
for X would be the same as the question of whether to use "a system-X".  
The venv would always contain a pyvenv.cfg file.  Within the venv every 
python extension module which uses other libraries would have its rpath 
pointing inside of sage/local, possibly to a real library or possibly to a 
symlink. Binary packages assembled by delocate would be exceptions because 
they already set the rpaths, to a subdirectory of the python package named 
.dylibs.

- Marc
On Thursday, December 7, 2023 at 12:17:00 PM UTC-6 Matthias Koeppe wrote:

> On Thursday, December 7, 2023 at 10:04:14 AM UTC-8 Marc Culler wrote:
>
> I have a very narrow techical question.  I am hoping for a narrow 
> technical answer, preferably from someone who was involved in designing the 
> Sage venv.
>
> QUESTION: Why doesn't the Sage venv contain a pyvenv.cfg file?
>
>
> It does whenever it's actually a venv in the technical sense (which you 
> explain correctly).
>
> If system python gets used, then the Sage distribution creates an actual 
> venv over it. So there's a pyvenv.cfg.
>
> But if a python is built by the Sage distribution, then it is merely an 
> installation tree of that python. In this case, there's no pyvenv.cfg.
>
>
>
>  
>

-- 
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/d06625de-e242-430e-a9d8-980a73bedf17n%40googlegroups.com.

[sage-devel] Question about the sage venv.

[Marc Culler]

I have a very narrow techical question.  I am hoping for a narrow technical 
answer, preferably from someone who was involved in designing the Sage venv.

QUESTION: Why doesn't the Sage venv contain a pyvenv.cfg file?

When you read PEP 405  you learn that 
the pyvenv.cfg file is what makes a directory be a venv.  For example:

"Thus, a Python virtual environment in its simplest form would consist of 
nothing more than a copy or symlink of the Python binary accompanied by a 
pyvenv.cfg file and a site-packages directory."

In addition to identifying the directory as being a venv, the pyvenv.cfg 
file controls how the sys.prefix is configured when the python binary in 
the venv starts up.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/38d53fe1-8db3-4aa5-8ae7-b7803cbe96f8n%40googlegroups.com.

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

[Marc Culler]

I should also have mentioned that macOS is an example of a system which
does not come with libjpeg.

On Fri, Nov 17, 2023 at 12:53 PM Marc Culler  wrote:

> No, I meant both "normal" and "standard".  I am sure I will master this
> terminology sooner or later.
>
> On Friday, November 17, 2023 at 12:51:48 PM UTC-6 Marc Culler wrote:
>
>> I meant "normal" when I said "standard".
>>
>> On Friday, November 17, 2023 at 12:49:18 PM UTC-6 Marc Culler wrote:
>>
>>> I expect to receive lots of flak for saying this, but I support making
>>> libjpeg be a standard spkg using the source code from
>>> https://libjpeg.sourceforge.net.  I just built version jpeg-9e on
>>> Ubuntu 18.04 and macOS 10.13.  The standard ./configure ; make install
>>> method works flawlessly - not even any warnings.  The build is fast and the
>>> package is small.  Installing it in sage/local/lib will be simpler, faster
>>> and more reliable than guessing where it might be found on any of the
>>> zillion systems that Sage runs on.  Also, unlike  the turbo alternatives,
>>> it does not depend on fancy features of Intel hardware which will not be
>>> available on old Intel CPUs or recent Arm CPUs.
>>>
>>> - Marc
>>>
>>> On Friday, November 17, 2023 at 12:20:41 PM UTC-6 Matthias Koeppe wrote:
>>>
>>>> On Friday, November 17, 2023 at 10:11:43 AM UTC-8 Dima Pasechnik wrote:
>>>>
>>>> We have at least one open issue/PR,
>>>> adding spkg-configure.m4 for FriCAS,
>>>> stuck due to the fact it's an insanely complicated job to provide
>>>> Feature for it, and totally meaningless, if you ask me.
>>>>
>>>>
>>>> I'll interpret this declaration as you asking for help with this PR,
>>>> https://github.com/sagemath/sage/pull/35838, so I have put it on my
>>>> list of things to do.
>>>>
>>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/A4nY3bh1oPI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ca9fc171-9f04-4437-bc4a-0471e95dfef4n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/ca9fc171-9f04-4437-bc4a-0471e95dfef4n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

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

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

[Marc Culler]

No, I meant both "normal" and "standard".  I am sure I will master this 
terminology sooner or later.

On Friday, November 17, 2023 at 12:51:48 PM UTC-6 Marc Culler wrote:

> I meant "normal" when I said "standard".
>
> On Friday, November 17, 2023 at 12:49:18 PM UTC-6 Marc Culler wrote:
>
>> I expect to receive lots of flak for saying this, but I support making 
>> libjpeg be a standard spkg using the source code from 
>> https://libjpeg.sourceforge.net.  I just built version jpeg-9e on Ubuntu 
>> 18.04 and macOS 10.13.  The standard ./configure ; make install method 
>> works flawlessly - not even any warnings.  The build is fast and the 
>> package is small.  Installing it in sage/local/lib will be simpler, faster 
>> and more reliable than guessing where it might be found on any of the 
>> zillion systems that Sage runs on.  Also, unlike  the turbo alternatives, 
>> it does not depend on fancy features of Intel hardware which will not be 
>> available on old Intel CPUs or recent Arm CPUs.
>>
>> - Marc
>>
>> On Friday, November 17, 2023 at 12:20:41 PM UTC-6 Matthias Koeppe wrote:
>>
>>> On Friday, November 17, 2023 at 10:11:43 AM UTC-8 Dima Pasechnik wrote:
>>>
>>> We have at least one open issue/PR, 
>>> adding spkg-configure.m4 for FriCAS, 
>>> stuck due to the fact it's an insanely complicated job to provide 
>>> Feature for it, and totally meaningless, if you ask me.
>>>
>>>
>>> I'll interpret this declaration as you asking for help with this PR, 
>>> https://github.com/sagemath/sage/pull/35838, so I have put it on my 
>>> list of things to do.
>>>
>>>

-- 
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/ca9fc171-9f04-4437-bc4a-0471e95dfef4n%40googlegroups.com.

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

[Marc Culler]

I meant "normal" when I said "standard".

On Friday, November 17, 2023 at 12:49:18 PM UTC-6 Marc Culler wrote:

> I expect to receive lots of flak for saying this, but I support making 
> libjpeg be a standard spkg using the source code from 
> https://libjpeg.sourceforge.net.  I just built version jpeg-9e on Ubuntu 
> 18.04 and macOS 10.13.  The standard ./configure ; make install method 
> works flawlessly - not even any warnings.  The build is fast and the 
> package is small.  Installing it in sage/local/lib will be simpler, faster 
> and more reliable than guessing where it might be found on any of the 
> zillion systems that Sage runs on.  Also, unlike  the turbo alternatives, 
> it does not depend on fancy features of Intel hardware which will not be 
> available on old Intel CPUs or recent Arm CPUs.
>
> - Marc
>
> On Friday, November 17, 2023 at 12:20:41 PM UTC-6 Matthias Koeppe wrote:
>
>> On Friday, November 17, 2023 at 10:11:43 AM UTC-8 Dima Pasechnik wrote:
>>
>> We have at least one open issue/PR, 
>> adding spkg-configure.m4 for FriCAS, 
>> stuck due to the fact it's an insanely complicated job to provide 
>> Feature for it, and totally meaningless, if you ask me.
>>
>>
>> I'll interpret this declaration as you asking for help with this PR, 
>> https://github.com/sagemath/sage/pull/35838, so I have put it on my list 
>> of things to do.
>>
>>

-- 
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/9920407f-4a17-4429-8394-bb5c6818bc99n%40googlegroups.com.

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

[Marc Culler]

I expect to receive lots of flak for saying this, but I support making 
libjpeg be a standard spkg using the source code from 
https://libjpeg.sourceforge.net.  I just built version jpeg-9e on Ubuntu 
18.04 and macOS 10.13.  The standard ./configure ; make install method 
works flawlessly - not even any warnings.  The build is fast and the 
package is small.  Installing it in sage/local/lib will be simpler, faster 
and more reliable than guessing where it might be found on any of the 
zillion systems that Sage runs on.  Also, unlike  the turbo alternatives, 
it does not depend on fancy features of Intel hardware which will not be 
available on old Intel CPUs or recent Arm CPUs.

- Marc

On Friday, November 17, 2023 at 12:20:41 PM UTC-6 Matthias Koeppe wrote:

> On Friday, November 17, 2023 at 10:11:43 AM UTC-8 Dima Pasechnik wrote:
>
> We have at least one open issue/PR, 
> adding spkg-configure.m4 for FriCAS, 
> stuck due to the fact it's an insanely complicated job to provide 
> Feature for it, and totally meaningless, if you ask me.
>
>
> I'll interpret this declaration as you asking for help with this PR, 
> https://github.com/sagemath/sage/pull/35838, so I have put it on my list 
> of things to do.
>
>

-- 
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/35485354-3569-432b-8fea-e54ac60ca62an%40googlegroups.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
>>  
>> <https://groups.google.com/d/msgid/sage-devel/b0293496-5e25-49d5-bd11-78928bb3ecb6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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] Cython errors when building p_group_cohomology

[Marc Culler]

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+unsubscr...@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.
Using cached file 
/private/var/tmp/sage-10.2-current/upstream/p_group_cohomology-3.3.3.tar.xz
p_group_cohomology-3.3.3.p1

Setting up build directory for p_group_cohomology-3.3.3.p1
Finished extraction
Applying patches from ../patches...
Applying ../patches/7.patch
patching file pGroupCohomology-3.3.3/pGroupCohomology/cohomology.pyx

Host system:
Darwin abner.cable.rcn.com 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 
20:51:50 PDT 2023; root:xnu-8796.121.2~5/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: 
/Applications/Xcode_13.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Package 'p_group_cohomology' is currently not installed
No legacy uninstaller found for 'p_group_cohomology'; nothing to do
Installing p_group_cohomology-3.3.3.p1
Looking in links: 
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/lib/sage/wheels
Processing 
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/p_group_cohomology-3.3.3.p1/src/pGroupCohomology-3.3.3
  Preparing metadata (setup.py): started
  Running command python setup.py egg_info

  Error compiling Cython file:
  
  ...
  from sage.structure.element cimport Element
  from .map cimport Map
  ^
  

  
/private/var/tmp/sage-10.2-current/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

  Error compiling Cython file:
  
  ...
  from sage.structure.element cimport Element
  from .map cimport Map
  ^
  

  
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sage/categories/morphism.pxd:2:0:
 'sage/categories/map/Map.pxd' not found

  Error compiling Cython file:
  
  ...
  from sage.structure.element cimport Element
  from .map cimport Map


  cdef class Morphism(Map):
  ^
  

  
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sage/categories/morphism.pxd:5:20:
 First base of 'Morphism' is not an extension type

  Error compiling Cython file:
  
  ...
  cdef class RingMap(Morphism):
  pass

  cdef class RingMap_lift(RingMap):
  cdef Parent S
  cdef Map to_S
   ^
  

  
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sage/rings/morphism.pxd:13:9:
 'Map' is not a type identifier

  Error compiling Cython file:
  
  ...
  raise TypeError("key must be an integer, not 
{}".format(type(key)))


  #
  ## ==, <, >
  cpd

Re: [sage-devel] Symengine package fails to build in 10.2rc2

[Marc Culler]

I see your unanswered message "ping" on issue #456 from 5 days ago.

But in the Releases section I see that v0.11.0 was released 2 days ago.

- Marc   


On Tuesday, November 14, 2023 at 11:50:55 AM UTC-6 Dima Pasechnik wrote:

> On Tue, Nov 14, 2023 at 5:18 PM Marc Culler  wrote:
> >
> > The symengine package has apparently not been updated to be compatible 
> with cython 3.
>
> https://github.com/symengine/symengine.py/issues/456
>
>
> >
> > This is what I see in the log (full log attached):
> >
> > performance hint: 
> /private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/symengine_py-0.10.0/src/symengine/lib/symengine_wrapper.pyx:4992:5:
>  
> Exception check on '_ctypes_callback_lambda_real' will always require the 
> GIL to be acquired.
> > Possible solutions:
> > 1. Declare the function as 'noexcept' if you control the definition and 
> you're sure you don't want the function to raise exceptions.
> > 2. Use an 'int' return type on the function to allow an error code to be 
> returned.
> >
> > Error compiling Cython file:
> > 
> > ...
> > cdef Basic X = sympify((o1).diff(c2py(symbol)._sympy_()))
> > return X.thisptr
> >
> > def create_sympy_module():
> > cdef PyModule s = PyModule.__new__(PyModule)
> > s.thisptr = symengine.make_rcp_PyModule(&symengine_to_sympy, 
> &pynumber_to_symengine, &sympy_eval,
> > ^
> > 
> >
> > 
> /private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/symengine_py-0.10.0/src/symengine/lib/symengine_wrapper.pyx:2805:44:
>  
> Cannot assign type 'PyObject *(*)(rcp_const_basic) except? NULL' to 
> 'PyObject *(*)(rcp_const_basic) noexcept'. Exception values are 
> incompatible. Suggest adding 'noexcept' to type 'PyObject 
> *(rcp_const_basic) except? NULL'.
> > make[7]: *** [symengine/lib/symengine_wrapper.cpp] Error 1
> > make[6]: *** [symengine/lib/CMakeFiles/symengine_wrapper.dir/all] Error 2
> > make[5]: *** [all] Error 2
> > error: error building project
> > error: subprocess-exited-with-error
> >
> > --
> > 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/4fd16cfa-59fc-4571-b7a8-1ac5caeda95dn%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/6db1f1d2-b942-4e1b-9cfe-fa9cc9e792d5n%40googlegroups.com.

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

[Marc Culler]

Thanks, Matthias.  I will try to remember to check the timestamps next time.

- Marc

On Tue, Nov 14, 2023 at 12:56 PM Matthias Koeppe 
wrote:

> I don't think this happens in normal development. When this happens in
> your setup, check the mtime of the timestamps in
> local/var/lib/sage/installed.
>
> On Tuesday, November 14, 2023 at 9:37:09 AM UTC-8 Marc Culler wrote:
>
>> For me, one of the most frustrating parts of building sage is that,
>> whenever a build fails, the make system decides that gmp is out of date and
>> hence I have to wait for it to recompile gmp and all of its dependencies.
>>
>> Is this intentional?
>>
>> Does anyone know why it happens?
>>
>> Is it avoidable?
>>
>> Or am I the only one who sees this?
>>
>> - Marc
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/rBvXdVKC4nw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/96d12845-208c-46cb-966b-8a991ef4a68cn%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/96d12845-208c-46cb-966b-8a991ef4a68cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CALcZXRE3M%2BuV-Hd69%2BJdt3aAEZJcW8JhzFi0%3DpcdB%2BgFGndBrA%40mail.gmail.com.

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

[Marc Culler]

I was hesitant to send that message because I didn't want to have to go
through this again.

On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik  wrote:

> > Does ./configure say why the system copy is unsuitable?
>

There is no system copy.

I imagine it might be an artifact of the design of Sage on Mac app
> Marc is releasing:
>

Very likely.

vendor everything.
>

Vendor is a noun, not a verb.

Is Apple's software distribution system so dumb that this is the only way?
>

If you think that Apple's requirement that apps be notarized is dumb, then
I encourage you to take it up with Apple.  Maybe Don Quixote will join you
in the effort.

I am serving people who use macOS; more than 8.800 of them in the case of
Sage 10.1.  I am fairly confident in claiming that the vast majority of
Sage 10.1 users are using it on macOS from the Sage_macOS app.  Even
homebrew users are using that app, since it is what gets installed when you
run "brew install sage" , which works
fine by the way.

When I started this project you were griping about how many sage-support
problems were related to macOS installation.  I don't think you can claim
that to be a problem any more.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CALcZXREOLVXQemMvTbVZDgf%3DWT3zOi-tmokJV_3%3DX%3D0zDO-cXw%40mail.gmail.com.

[sage-devel] Re: Question about make dependencies

[Marc Culler]

Of course I meant that I have to wait for everything that *depends on* gmp 
to be recompiled.  Also, this happens when there is nothing wrong with the 
gmp build.  The make system decides that it is out of date even though the 
build was successful and the package was installed.

- Marc

On Tuesday, November 14, 2023 at 11:37:09 AM UTC-6 Marc Culler wrote:

> For me, one of the most frustrating parts of building sage is that, 
> whenever a build fails, the make system decides that gmp is out of date and 
> hence I have to wait for it to recompile gmp and all of its dependencies.
>
> Is this intentional?
>
> Does anyone know why it happens?
>
> Is it avoidable?
>
> Or am I the only one who sees this?
>
> - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ab50a937-2ac2-4610-86c3-b954451dd84an%40googlegroups.com.

[sage-devel] Question about make dependencies

[Marc Culler]

For me, one of the most frustrating parts of building sage is that, 
whenever a build fails, the make system decides that gmp is out of date and 
hence I have to wait for it to recompile gmp and all of its dependencies.

Is this intentional?

Does anyone know why it happens?

Is it avoidable?

Or am I the only one who sees this?

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/233fc79f-0564-4a90-aade-3c7882cec5b2n%40googlegroups.com.

[sage-devel] Symengine package fails to build in 10.2rc2

[Marc Culler]

The symengine package has apparently not been updated to be compatible with 
cython 3.

This is what I see in the log (full log attached):

  performance hint: 
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/symengine_py-0.10.0/src/symengine/lib/symengine_wrapper.pyx:4992:5:
 
Exception check on '_ctypes_callback_lambda_real' will always require the 
GIL to be acquired.
  Possible solutions:
1. Declare the function as 'noexcept' if you control the definition 
and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on the function to allow an error code 
to be returned.

  Error compiling Cython file:
  
  ...
  cdef Basic X = sympify((o1).diff(c2py(symbol)._sympy_()))
  return X.thisptr

  def create_sympy_module():
  cdef PyModule s = PyModule.__new__(PyModule)
  s.thisptr = symengine.make_rcp_PyModule(&symengine_to_sympy, 
&pynumber_to_symengine, &sympy_eval,
  ^
  

  
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/symengine_py-0.10.0/src/symengine/lib/symengine_wrapper.pyx:2805:44:
 
Cannot assign type 'PyObject *(*)(rcp_const_basic) except? NULL' to 
'PyObject *(*)(rcp_const_basic) noexcept'. Exception values are 
incompatible. Suggest adding 'noexcept' to type 'PyObject 
*(rcp_const_basic) except? NULL'.
  make[7]: *** [symengine/lib/symengine_wrapper.cpp] Error 1
  make[6]: *** [symengine/lib/CMakeFiles/symengine_wrapper.dir/all] Error 2
  make[5]: *** [all] Error 2
  error: error building project
  error: subprocess-exited-with-error

-- 
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/4fd16cfa-59fc-4571-b7a8-1ac5caeda95dn%40googlegroups.com.
Using cached file 
/private/var/tmp/sage-10.2-current/upstream/symengine.py-0.10.0.tar.gz
symengine_py-0.10.0

Setting up build directory for symengine_py-0.10.0
Finished extraction
No patch files found in ../patches

Host system:
Darwin abner.local 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:51:50 PDT 
2023; root:xnu-8796.121.2~5/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: 
/Applications/Xcode_13.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Package 'symengine_py' is currently not installed
No legacy uninstaller found for 'symengine_py'; nothing to do
Installing symengine_py-0.10.0
Looking in links: 
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/lib/sage/wheels
Processing 
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/var/tmp/sage/build/symengine_py-0.10.0/src
  Preparing metadata (setup.py): started
  Running command python setup.py egg_info
  
/private/var/tmp/sage-10.2-current/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/setuptools/__init__.py:80:
 _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
  !!

  

  Requirements should be satisfied by a PEP 517 installer.
  If you are using pip, you can try `pip install --use-pep517`.
  


  !!
dist.fetch_build_eggs(dist.setup_requires)
  running egg_info
  creating 
/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info
  writing 
/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info/PKG-INFO
  writing dependency_links to 
/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info/dependency_links.txt
  writing top-level names to 
/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info/top_level.txt
  writing manifest file 
'/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info/SOURCES.txt'
  reading manifest file 
'/private/var/folders/sl/wck1hwwx6pv2mcl04pv2092wgn/T/pip-pip-egg-info-2xeqdjam/symengine.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  warning: no files found matching '*.hpp' under directory 'symengine'
  warning: no f

Re: [sage-devel] Question about reading Sage documentation

[Marc Culler]

I was asking a very specific question about SageMath on Ubuntu 22.04: Are
Ubuntu 22.04 users who install the sagemath-doc package able to read those
(Sage 9.5) docs with Firefox?

https://askubuntu.com/questions/1441339/how-can-i-use-file-urls-from-my-firefox-snap-version
suggests the answer is no, or not easily.

I thought that topic might be pertinent here.

- Marc

On Thu, Jun 29, 2023 at 6:48 PM Michael Orlitzky 
wrote:

> On 2023-06-29 14:46:00, Marc Culler wrote:
> > During our recent release of SnapPy we ran across an issue which is
> likely
> > relevant to whether Sage's documentation is viewable on newer Ubuntu
> > systems (such as 22.04).  The issue is that these newer Ubuntu systems
> ship
> > Firefox as a snap.  A snap runs in a sandbox which restricts which files
> > the snap can read.  Specifically, the Firefox snap can only read files
> in
> > the user's home directory.
> >
> > ...
> >
> > Have people run into this?
> >
>
> Alternate headline: multi-millionaire does stupid thing with
> billionaire's product; how can math teachers fix it for free?
>
> This is a combination of two problems,
>
>   1. Mozilla has been going out of their way for a long time to make
>  traditional firefox/thunderbird packages hard to maintain.
>
>   2. Snaps are stupid (but low effort).
>
> Despite a long-standing and fully independent hatred of Snaps, I can't
> really blame Ubuntu for saying fuck it and taking the easy way out;
> the firefox experience was going to be degraded in one way or another.
>
> There aren't any great solutions because the only other mainstream
> browser is managed by a spyware company and is also increasingly
> difficult to package (for slightly different reasons). For second-tier
> browsers, there's Falkon (Qt) and Epiphany (Gtk), which can still be
> sanely packaged, but that are also missing features that most users
> won't give up. Everything else is basically a Chrome theme these days
> and inherits Chrome problems.
>
> To summarize where I'm at personally,
>
>   * Man/info pages are the standard and still work great
>   * A fallback browser is nice to have around
>   * There's always LaTeX/PDF
>   * Not everything can be my problem
>
> This is more of an answer to "have people run into this?" than an
> actual answer, but there it is.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/01jkwYwRU_M/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ZJ4YTZcllgov1v6m%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/CALcZXRFQfr0zRc45a5xM7R819G7Dx_yY%2B2f3xxUz7c5rWttLBA%40mail.gmail.com.

[sage-devel] Re: Voting: Block-scoped optional tag and the keyword

[Marc Culler]

I vote for (C).

On Wednesday, June 28, 2023 at 9:40:07 PM UTC-5 Kwankyu Lee wrote:

> Hi,
>
> We spent six days for the preliminary discussion in the sage-devel thread
>
> https://groups.google.com/g/sage-devel/c/OUnoroIf0qc
>
> about choosing the keyword triggering block-scoped optional tag needed in 
>
> https://github.com/sagemath/sage/issues/35750
>
> We now start the voting with the four candidates (A), (B), (C), (D). The 
> voting will end 7th July 23:59 KST (Korea Standard Time). During the 
> voting, discussions can continue in the linked places but please only your 
> vote (and, if you will, short comment) to this thread.
>
> (A) "needs"
>
> sage: # needs sage.rings.number_field
> sage: QQbar(I)^2
> -1
> sage: QQbar(I)^10 # long time
> 1
>
> sage: # needs sage.rings.finite_rings
> sage: F = GF(7)
> sage: F(1) + QQbar(1)  # needs sage.rings.number_field
> ...
>
> (B) "requires"
>
> sage: # requires sage.rings.number_field
> sage: QQbar(I)^2
> -1
> sage: QQbar(I)^10  # long time
> 1
>
> sage: # requires sage.rings.finite_rings
> sage: F = GF(7)
> sage: F(1) + QQbar(1)  # requires sage.rings.number_field
> ...
>
> (C) "uses"
>
> sage: # uses sage.rings.number_field
> sage: QQbar(I)^2
> -1
> sage: QQbar(I)^10  # long time
> 1
>
> sage: # uses sage.rings.finite_rings
> sage: F = GF(7)
> sage: F(1) + QQbar(1)  # uses sage.rings.number_field
> ...
>
> (D) "standard"
>
> sage: # use standard feature - sage.rings.number_field
> sage: QQbar(I)^2
> -1
> sage: QQbar(I)^10  # long time
> 1
>
> sage: # use standard feature - sage.rings.finite_rings
> sage: F = GF(7)
> sage: F(1) + QQbar(1)  # standard - sage.rings.number_field
> ...
>
> Please just focus on the keyword. Don't worry about minor details or 
> punctuations: the keyword would be recognized, the rest would be ignored 
> noise, in the implementation.
>
> Thanks for your attention. Happy voting :-)
>
>
>
>  
>
>

-- 
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/6d732a20-6a69-46b7-ac32-063b8170a8efn%40googlegroups.com.

[sage-devel] Question about reading Sage documentation

[Marc Culler]

During our recent release of SnapPy we ran across an issue which is likely 
relevant to whether Sage's documentation is viewable on newer Ubuntu 
systems (such as 22.04).  The issue is that these newer Ubuntu systems ship 
Firefox as a snap.  A snap runs in a sandbox which restricts which files 
the snap can read.  Specifically, the Firefox snap can only read files in 
the user's home directory.

This would suggest that a user who builds Sage in their home directory can 
use Firefox to view the documentation by using a URL with the file: scheme, 
but that if Sage is installed for all users on a multi-user system or if it 
is installed with apt then it will not be possible for users to read the 
locally installed documentation with Firefox.  (Of course they can use 
Firefox to read the online documentation for the current SageMath version 
but, on Ubuntu, that is essentially guaranteed not to be the version that 
is actually installed.)

Have people run into this?

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ca8f5dbe-8b50-43e1-afaa-f2073a1e70e8n%40googlegroups.com.

Re: [sage-devel] Graphics files in Sage documentation

[Marc Culler]

Right. That is what I will be doing.

- Marc

On Wed, Jun 28, 2023, 5:27 PM Dima Pasechnik  wrote:

> One can always start a web server on localhost, instead of using file:///
> :P
>
> On Wed, Jun 28, 2023 at 11:16 PM Michael Orlitzky 
> wrote:
> >
> > On Wed, 2023-06-28 at 13:50 -0400, Michael Orlitzky wrote:
> > >
> > >   * gzipped SVG doesn't work over the file:/// protocol in my firefox.
> > > This hasn't been a big enough problem for me yet to diagnose it,
> > > so I can't say how serious a problem it is. (I'll play around later
> > > today.)
> >
> > Firefox bug opened 23 years ago:
> >
> >   https://bugzilla.mozilla.org/show_bug.cgi?id=52282
> >
> >
> >
> > If they were going to fix it, it'd be fixed, so I'd suggest doing the
> > comparison uncompressed. A lot of people (statistics all made up) read
> > the docs locally with firefox.
> >
> > --
> > 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/28b1bd234f8a344062c0bd103dd53760ff24c693.camel%40orlitzky.com
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/a5t3mFJNMDI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAAWYfq1Y5_EK0NhjmuzDkC8hvNC5Rg7zchiYAB7kMi2r2i_RkA%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/CALcZXRErT3wwEHkjM21N_8gKyfUuOg7G4%3DhZFbVnSSwJT1h%2BtA%40mail.gmail.com.

Re: [sage-devel] Graphics files in Sage documentation

[Marc Culler]

Thank you!  Probably it is my bug, or it is somehow triggered by my wierd
setup.  That would probably mean some environment difference in the sage or
sage-env scripts, since those are basically the only things I have tinkered
with.

Can you verify that you do not see any image files in the top level of, say:
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds ?

- Marc

On Wed, Jun 28, 2023 at 3:23 PM John H Palmieri 
wrote:

> By the way, on my machine, local/share/doc/sage are almost identical sizes
> in 10.1.beta3 and 10.1.beta4. I don't know what explains the difference
> you're seeing.
>
> On Wednesday, June 28, 2023 at 12:51:38 PM UTC-7 John H Palmieri wrote:
>
>> This change should produce only the .svg files:
>>
>> diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
>> index 9b6b37480b..b5d6815c76 100644
>> --- a/src/sage_docbuild/conf.py
>> +++ b/src/sage_docbuild/conf.py
>> @@ -128,7 +128,7 @@ from sage.all_cmdline import *
>>  """
>>
>>  plot_html_show_formats = False
>> -plot_formats = ['svg', 'pdf', 'png']
>> +plot_formats = ['svg']
>>
>>  # We do *not* fully initialize intersphinx since we call it by hand
>>  # in find_sage_dangling_links.
>>
>>
>> (I'm not suggesting this as a general change, just for your particular
>> situation.)
>>
>>
>> On Wednesday, June 28, 2023 at 12:07:46 PM UTC-7 Marc Culler wrote:
>>
>>> Note: I had already compressed the .svg files, hence the .gz extension.
>>>
>>> Before compression I get:
>>>
>>> % find local/share/doc/sage/html/en -name 'chart-12*'
>>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>>
>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>>
>>> - Marc
>>>
>>> On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:
>>>
>>>> I think I may have found a resolution of this problem, that involves
>>>> doing almost nothing.  It appears that sage_docbuild oftern builds image in
>>>> all three formats - svg, png and pdf.  All three types get stored in the
>>>> html directory and the svg is duplicated:
>>>>
>>>> find local/share/doc/sage/html/en -name 'chart-12*'
>>>> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>>>>
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>>>>
>>>> The actual html code seems to only uses the svg files stored in
>>>> _images.  Hopefully I can just remove the others without affecting the html
>>>> documentation.
>>>>
>>>> grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
>>>> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:>>> alt="../../_images/chart-12.svg" class="plot-directive"
>>>> src="../../_images/chart-12.svg" />
>>>>
>>>> Since this seems to be a change between 10.1beta3 and 10.1beta4, I
>>>> would have to guess that it might be considered a bug.  So maybe I should
>>>> move this back to sage-release?
>>>>
>>>> - Marc
>>>>
>>>>
>>>>
>>>> On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 Marc Culler wrote:
>>>>
>>>>> I am not proposing using gzipped svg for a normal sage build.  I only
>>>>> want to do it for the Sage_macOS app, which will have a simple
>>>>> self-contained server running on the loopback interface that provides
>>>>> gzipped content (with the Content-Encoding header set to "gzip").  Of
>>>>> course I would be happy to work on incorporating the same mechanism in a
>>>>> standard build of Sage, and that would reduce the footprint of the
>>>>> documentation considerably.  But in the short term, for the macOS binary, 
>>>>> I
>>>>> need to be able to find the magic switch which makes sage_docbuild use svg
>>>>&g

Re: [sage-devel] Graphics files in Sage documentation

[Marc Culler]

Note: I had already compressed the .svg files, hence the .gz extension.

Before compression I get:

% find local/share/doc/sage/html/en -name 'chart-12*'
local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf

- Marc

On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:

> I think I may have found a resolution of this problem, that involves doing 
> almost nothing.  It appears that sage_docbuild oftern builds image in all 
> three formats - svg, png and pdf.  All three types get stored in the html 
> directory and the svg is duplicated:
>
> find local/share/doc/sage/html/en -name 'chart-12*'
> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf
>
> The actual html code seems to only uses the svg files stored in _images.  
> Hopefully I can just remove the others without affecting the html 
> documentation.
>
> grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:  
> alt="../../_images/chart-12.svg" class="plot-directive" 
> src="../../_images/chart-12.svg" />
>
> Since this seems to be a change between 10.1beta3 and 10.1beta4, I would 
> have to guess that it might be considered a bug.  So maybe I should move 
> this back to sage-release?
>
> - Marc
>
>
>
> On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 Marc Culler wrote:
>
>> I am not proposing using gzipped svg for a normal sage build.  I only 
>> want to do it for the Sage_macOS app, which will have a simple 
>> self-contained server running on the loopback interface that provides 
>> gzipped content (with the Content-Encoding header set to "gzip").  Of 
>> course I would be happy to work on incorporating the same mechanism in a 
>> standard build of Sage, and that would reduce the footprint of the 
>> documentation considerably.  But in the short term, for the macOS binary, I 
>> need to be able to find the magic switch which makes sage_docbuild use svg 
>> instead of png.
>>
>> I don't know how much of a problem the image size will pose.  There are 
>> some svg images already in the documentation, which seem to work, but I 
>> hadn't gotten to the stage of worrying about that yet.
>>
>> - Marc
>> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>>
>>> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: 
>>> > 
>>> > BOTTOM LINE: we get more than a 90% reduction in size simply by 
>>> choosing to 
>>> > use the .svg extension when saving the plot instead of the .png 
>>> extension. 
>>> > 
>>>
>>> SVG is the right choice for most graphics, but there are some practical 
>>> problems: 
>>>
>>> * The documentation needs to know how big to display an SVG graphic. 
>>> With a PNG, the default is to use the image's height/width in  
>>> pixels, but with SVG, there's no such obvious default. 
>>>
>>> * gzipped SVG doesn't work over the file:/// protocol in my firefox. 
>>> This hasn't been a big enough problem for me yet to diagnose it, 
>>> so I can't say how serious a problem it is. (I'll play around later 
>>> today.) 
>>>
>>> * Browser support in firefox/chrome alternatives still isn't great, 
>>> although I think webkit is getting a new SVG renderer "soon." This 
>>> is actually relevant more today than it was ten years ago, because  
>>> adding rust to firefox made it less portable, meaning you're 
>>> more likely to be stuck with one of those alternatives. 
>>>
>>> * Somebody's got to go through and look at 100MB of images to make  
>>> sure they still look right if we change 'em. 
>>>
>>>

-- 
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/9c26290e-f162-4c21-8ff2-f7143d4293cen%40googlegroups.com.

Re: [sage-devel] Graphics files in Sage documentation

[Marc Culler]

I think I may have found a resolution of this problem, that involves doing 
almost nothing.  It appears that sage_docbuild oftern builds image in all 
three formats - svg, png and pdf.  All three types get stored in the html 
directory and the svg is duplicated:

find local/share/doc/sage/html/en -name 'chart-12*'
local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf

The actual html code seems to only uses the svg files stored in _images.  
Hopefully I can just remove the others without affecting the html 
documentation.

grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds
local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:

Since this seems to be a change between 10.1beta3 and 10.1beta4, I would 
have to guess that it might be considered a bug.  So maybe I should move 
this back to sage-release?

- Marc



On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 Marc Culler wrote:

> I am not proposing using gzipped svg for a normal sage build.  I only want 
> to do it for the Sage_macOS app, which will have a simple self-contained 
> server running on the loopback interface that provides gzipped content 
> (with the Content-Encoding header set to "gzip").  Of course I would be 
> happy to work on incorporating the same mechanism in a standard build of 
> Sage, and that would reduce the footprint of the documentation 
> considerably.  But in the short term, for the macOS binary, I need to be 
> able to find the magic switch which makes sage_docbuild use svg instead of 
> png.
>
> I don't know how much of a problem the image size will pose.  There are 
> some svg images already in the documentation, which seem to work, but I 
> hadn't gotten to the stage of worrying about that yet.
>
> - Marc
> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>
>> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: 
>> > 
>> > BOTTOM LINE: we get more than a 90% reduction in size simply by 
>> choosing to 
>> > use the .svg extension when saving the plot instead of the .png 
>> extension. 
>> > 
>>
>> SVG is the right choice for most graphics, but there are some practical 
>> problems: 
>>
>> * The documentation needs to know how big to display an SVG graphic. 
>> With a PNG, the default is to use the image's height/width in  
>> pixels, but with SVG, there's no such obvious default. 
>>
>> * gzipped SVG doesn't work over the file:/// protocol in my firefox. 
>> This hasn't been a big enough problem for me yet to diagnose it, 
>> so I can't say how serious a problem it is. (I'll play around later 
>> today.) 
>>
>> * Browser support in firefox/chrome alternatives still isn't great, 
>> although I think webkit is getting a new SVG renderer "soon." This 
>> is actually relevant more today than it was ten years ago, because  
>> adding rust to firefox made it less portable, meaning you're 
>> more likely to be stuck with one of those alternatives. 
>>
>> * Somebody's got to go through and look at 100MB of images to make  
>> sure they still look right if we change 'em. 
>>
>>

-- 
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/2c979ad1-3d6e-450c-bf46-7963031790d0n%40googlegroups.com.

Re: [sage-devel] Graphics files in Sage documentation

[Marc Culler]

I am not proposing using gzipped svg for a normal sage build.  I only want 
to do it for the Sage_macOS app, which will have a simple self-contained 
server running on the loopback interface that provides gzipped content 
(with the Content-Encoding header set to "gzip").  Of course I would be 
happy to work on incorporating the same mechanism in a standard build of 
Sage, and that would reduce the footprint of the documentation 
considerably.  But in the short term, for the macOS binary, I need to be 
able to find the magic switch which makes sage_docbuild use svg instead of 
png.

I don't know how much of a problem the image size will pose.  There are 
some svg images already in the documentation, which seem to work, but I 
hadn't gotten to the stage of worrying about that yet.

- Marc
On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:

> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote:
> > 
> > BOTTOM LINE: we get more than a 90% reduction in size simply by choosing 
> to 
> > use the .svg extension when saving the plot instead of the .png 
> extension.
> > 
>
> SVG is the right choice for most graphics, but there are some practical
> problems:
>
> * The documentation needs to know how big to display an SVG graphic.
> With a PNG, the default is to use the image's height/width in 
> pixels, but with SVG, there's no such obvious default.
>
> * gzipped SVG doesn't work over the file:/// protocol in my firefox.
> This hasn't been a big enough problem for me yet to diagnose it,
> so I can't say how serious a problem it is. (I'll play around later
> today.)
>
> * Browser support in firefox/chrome alternatives still isn't great,
> although I think webkit is getting a new SVG renderer "soon." This
> is actually relevant more today than it was ten years ago, because 
> adding rust to firefox made it less portable, meaning you're
> more likely to be stuck with one of those alternatives.
>
> * Somebody's got to go through and look at 100MB of images to make 
> sure they still look right if we change 'em.
>
>

-- 
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/f94addf4-4bce-4f97-b79d-34a003eee1f9n%40googlegroups.com.

[sage-devel] Graphics files in Sage documentation

[Marc Culler]

At John Palmieri's suggestion, I am duplicating this message that I posted 
on sage-release on this list:

Details really do matter.  The devil is in them.  Here is one which makes a 
major difference to my efforts to distribute Sage.  I hope that I can 
convince people to pay attention to it.

DETAIL: An svg image can be compressed very efficiently and will look good 
at all resolutions.  A png image can not be compressed, being already 
compressed, and pixelates at high resolutions.

BACK STORY: I am working on adding documentation to the Sage_macOS 
distribution.  Size is important.  For 10.1beta3 the English documentation 
occupied 631MB, and compressed down to 104MB.  For 10.1beta4 the 
uncompressed size increased by over 100MB due to the addition of 100MB of 
png images.  Now it only compresses to 207MB, doubling the compressed size.

There is no need for this wastefulness.  Here is an example:

sage: D = graphs.DodecahedralGraph()
sage: p = D.plot()
sage: p.save_image('/tmp/dodec.svg')
sage: p.save_image('/tmp/dodec.png')

The result:
% ls -l /tmp/dodec*
-rw-r--r--@ 1 culler  wheel  42735 Jun 28 08:48 /tmp/dodec.png
-rw-r--r--  1 culler  wheel  18524 Jun 28 08:48 /tmp/dodec.svg
% gzip /tmp/dodec*
% ls -l /tmp/dodec*
-rw-r--r--@ 1 culler  wheel  39473 Jun 28 08:48 /tmp/dodec.png.gz
-rw-r--r--  1 culler  wheel   3815 Jun 28 08:48 /tmp/dodec.svg.gz

BOTTOM LINE: we get more than a 90% reduction in size simply by choosing to 
use the .svg extension when saving the plot instead of the .png extension.

I am not allowed to upload an svg file to google groups, so you will have 
to verify for yourself that the svg looks better than the png, but it does.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a8663715-5fd2-4eaf-98c5-b66298364049n%40googlegroups.com.

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Marc Culler]

On Tuesday, May 30, 2023 at 9:17:17 AM UTC-5 Dima Pasechnik wrote:

Well, have you notiiced that while casting his vote, Matthias wrote a 
full screenful of questionable explanations of why he voted "no",


That is what always happens when people try to force a vote before there 
has been a discussion of sufficient depth to allow a consensus to form.  
That has been understood for a long time.  Robert's Rules of Order were 
written in 1876.  Our great new technology  has made us forget useful 
things that we used to know.

- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3b03a5e5-7327-4dfb-b27a-2bc8b1675ad4n%40googlegroups.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

[Marc Culler]

If I am allowed to vote, my vote is hybrid > copy files > pseudo package.

- Marc

On Tuesday, August 23, 2022 at 6:38:40 PM UTC-5 François Bissey wrote:

> Hi all,
>
> https://trac.sagemath.org/ticket/34152 needs help to decide what solution 
> we implement going forward.
>
> The ticket is concerned with updating the bootstrap process by removing 
> the current need for gettext and replacing it with gnulib (
> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
> library but a collection of bits and pieces to help portability across 
> platforms.
>
> The issue at hand is how do we include and use gnulib in sagemath.
> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and 
> across most of the ~250 comments of the ticket about the way to proceed. At 
> some point it became clear that they would not agree and would need 
> arbitration. This is what this post is about, I am inviting the sagemath 
> community to weigh in and decide the issue.
>
> The ticket summary has been updated with summaries of the problem and of 
> both options along with links to branches implementing them. I would not 
> recommend diving in the comment section.
>
> There are 3 (three) options to choose from, one from Matthias, one from 
> Dima and a hybrid approach they tried to create.
>
> -- copy files --
>
>- Follows approach 3 of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>.
>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>using `gnulib-tool import iconv` 
> 
> and 
>committed to the branch.
>- Matches our practice with imported files `m4/ax_*.m4` 
> from 
>autoconf-archive 
>. 
>Different from our practice with SPKGs because the files are needed to 
>generate the configure script.
>- Introduces no new dependency.
>- Burden on a developer who authors an update ticket for these files: 
>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>remove unneeded files (that's where #29549 
> went wrong), commit the 
>changes. (Updates are expected to be necessary only very rarely.)
>- Burden on users and other developers: None.
>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>code, it has no place in Sage git tree; this way, updating the imported 
>gnulib files is tricky and error-prone by design".
>
> -- sage pseudo package --
>
>- Follows approach 2(C) of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>, 
>but instead of using Gnulib's Programs for developing in Git checkouts 
>
> , 
>implements its own script (making checkout much faster, as full gnulib 
> checkout 
>is 250 MB).
>- Introduces a new (although one can't really do Sage development 
>without git installed) dependency on git and on availability of 
>internet connection at the first run of ./bootstrap in a tree, to pull 
>83 MB (fair to say that internet is needed for Sage development a lot, 
>anyway).
>- Burden on a developer who authors an update ticket for these files: 
>Edit the bootstrap file to change the commit hash, verify that the 
>list of files removed by make bootstrap-clean is still correct, commit 
>this change
>- Burden on other users: a pseudo-package needs to be installed once 
>(and updated, automatically)
>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>multi-megabyte git clone (on the 1st install and when there's a change of 
>the gnulib commit hash) in the upstream/ directory increases 
>complexity for no benefit."
>
> -- hybrid --
>
>- Resolves the criticism on the "copy files" approach: "updating the 
>imported gnulib files" is now assisted by the spkg-src script (adapted 
>from dimpase's branch)
>- Resolves the criticism on the "Sage pseudo-package" approach: 
>"operate a multi-megabyte git clone (on the 1st install and when there's a 
>change of the gnulib commit hash)" is only done by authors of tickets that 
>update gnulib, not by general users of bootstrap.
>
> Vote is open now and will close - tentatively - on the 29th of August at 
> 12pm New Zealand time [my time zone] when I will do the tally. If no option 
> gets a majority, the voting period may be extended by a few days.
> Please vote!
> [ ] copy files
> [ ] sage pseudo package
> [ ] hybrid
>
>
>

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

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Marc Culler]

Incidentally, the patch for p_group_cohomology that I uploaded above also 
appeared in #30787 <https://trac.sagemath.org/ticket/30787> . 
<https://trac.sagemath.org/query?status=needs_work>

- Marc

On Sunday, August 7, 2022 at 7:49:41 AM UTC-5 Marc Culler wrote:

> The p_group_cohomology package is included in the macOS binary release.  
> it requires a patch to its spkg-install,sh.  Symengine_py is also included 
> in the macOS binary and also needs a patch.  I am attaching a tarball of 
> the build/pkg directories for those two packages.
>
> - Marc
>
> On Sunday, August 7, 2022 at 2:03:41 AM UTC-5 Travis Scrimshaw wrote:
>
>> I would like to see the p_group_cohomology fixed. Progress got stalled on 
>> that, but I am happy to work on that (while I have time for August).
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:
>>
>>> The sage_numerical_backends_* packages are on their way out anyway.
>>> Coin support will switch to go through CVXPy in 
>>> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
>>> follow up ticket
>>>
>>> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>>>
>>>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>>>> still fail because I don't have gurobi and cplex installed. It would be 
>>>> nice if that was detected earlier in the process and the build failed 
>>>> right 
>>>> away. Actually, it is detected early in the process:
>>>>
>>>>   /bin/sh: gurobi.sh: No such file or directory
>>>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>>>> Gurobi installation.  Trying to link against -lgurobi
>>>>
>>>> but the installation proceeds anyway. But this is a separate issue.
>>>>
>>>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>>>
>>>>> This one is https://trac.sagemath.org/ticket/34221
>>>>>
>>>>> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>>>>>
>>>>>> Also, the various sage_numerical_backend_* packages fail to build, 
>>>>>> with errors like
>>>>>>
>>>>>>
>>>>>>   Error compiling Cython file:
>>>>>>   
>>>>>>   ...
>>>>>>   from sage.numerical.backends.generic_backend cimport GenericBackend
>>>>>>   ^
>>>>>>   
>>>>>>
>>>>>>   check_add_col_untyped_args.pyx:1:0: 
>>>>>> 'sage/numerical/backends/generic_backend.pxd' not found
>>>>>>
>>>>>>
>>>>>> Also downgrade? Is there a ticket for this?
>>>>>>
>>>>>> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>>>>>>
>>>>>>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>>>>>>
>>>>>>>> The following packages do not build for me on OS X 12.5 
>>>>>>>> (Monterrey), Intel chip:
>>>>>>>>
>>>>>>>>- polylib (#33758)
>>>>>>>>- symengine_py (#34141)
>>>>>>>>- p_group_cohomology (#30787)
>>>>>>>>- r_jupyter
>>>>>>>>- rubiks
>>>>>>>>
>>>>>>>> I propose that these be downgraded from optional to experimental 
>>>>>>>> until the issues are fixed. What do people think?
>>>>>>>>
>>>>>>>>
>>>>>>> Also on various Linux platforms (
>>>>>>> https://github.com/sagemath/sage/actions/runs/204587) I see 
>>>>>>> failures for
>>>>>>> symengine_py, 
>>>>>>> p_group_cohomology, 
>>>>>>> r_jupyter
>>>>>>>
>>>>>>> So these 3 definitely need to be changed to "experimental".
>>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>

-- 
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/1f063ec0-6018-4bf0-b08b-795f2e935f1cn%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Marc Culler]

Yes, there is a ticket for this.  It is #34221 
.  The current version of Cython 
ignores .pxd files in directories with no __init__.py.  The ticket 
backports a cython fix for that problem which will appear in a future 
Cython release.

- Marc

On Saturday, August 6, 2022 at 1:55:36 PM UTC-5 John H Palmieri wrote:

> Also, the various sage_numerical_backend_* packages fail to build, with 
> errors like
>
>
>   Error compiling Cython file:
>   
>   ...
>   from sage.numerical.backends.generic_backend cimport GenericBackend
>   ^
>   
>
>   check_add_col_untyped_args.pyx:1:0: 
> 'sage/numerical/backends/generic_backend.pxd' not found
>
>
> Also downgrade? Is there a ticket for this?
>
> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>
>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>
>>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>>> Intel chip:
>>>
>>>- polylib (#33758)
>>>- symengine_py (#34141)
>>>- p_group_cohomology (#30787)
>>>- r_jupyter
>>>- rubiks
>>>
>>> I propose that these be downgraded from optional to experimental until 
>>> the issues are fixed. What do people think?
>>>
>>>
>> Also on various Linux platforms (
>> https://github.com/sagemath/sage/actions/runs/204587) I see failures 
>> for
>> symengine_py, 
>> p_group_cohomology, 
>> r_jupyter
>>
>> So these 3 definitely need to be changed to "experimental".
>>
>>
>>  
>>
>

-- 
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/04dd20f0-eda0-4065-ac91-b140675bbabcn%40googlegroups.com.