[sage-devel] cysignals/sig_on...sig_off

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

Hi,

it's been over a year since the last activity on 
https://github.com/sagemath/cysignals.

This could well be, because it is a good shape, but looking at the issues, 
I'm not too sure about that. Here are some issues, I know of:

- sig_on/sig_off is poorly maintained and not thread safe
- cysignals is not pip installable and highly platform dependent (and on a 
platform even depends very much on the compiler).
- Memory: Interrupting sig_on...sig_off will not clean up the heap.

I would argue:

-  To my knowledge, `sig_check` is pretty much equivalent to `
PyErr_CheckSignals` (https://github.com/sagemath/cysignals/issues/145)
- Instead of using `sig_on...sig_off` for our own functions, we should 
check for signals at reasonable places.
- External calls should be interrupted with standard tools and not our own 
custom tool.

While the action on the first item is quite obvious (I didn't even check if 
anything needs to be done here), I have not done my research on the second 
point and what the alternatives are.

Before I dig into possible options of replacing `sig_on...sig_off`, I would 
like to gather your opinions:

Does cysignals get enough support to keep going or do we want to try a 
different approach? This different approach will for sure not be as 
efficient, but will probably need less effort to maintain.

-- 
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/a8883260-2b4b-4cd4-8980-f1fea2070c10n%40googlegroups.com.

[sage-devel] Re: Parallelization of Boruvka's Algorithm

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

Sure. Since this is written in cython, using 
https://cython.readthedocs.io/en/latest/src/userguide/parallelism.html 
might be a good choice.

This is also used in 
`src/sage/geometry/polyhedron/combinatorial_polyhedron/face_iterator.pyx`. 
Note the first two lines of the file. With those lines, you can just do 
`from cython.parallel cimport ...` and use it.
If your computer has `OpenMP`, this should parallelize.

But depends a bit on the details. You can just cc me (gh-kliem) on the 
ticket and we can discuss the details from there.

And make sure to mention the ticket number here, so anyone interested can 
just take a look.

adarsh.k...@gmail.com schrieb am Dienstag, 12. April 2022 um 15:55:16 UTC+2:

> I think I might get how to do it. Can I open a ticket for this?
>
> On Tuesday, April 12, 2022 at 12:11:05 PM UTC+5:30 Adarsh Kishore wrote:
>
>> Hi everyone, 
>>
>> I was going through the file 
>> `SAGE_ROOT/src/sage/graphs/spanning_tree.pyx` and I found this in the TODO 
>> section
>> [image: Screenshot from 2022-04-12 12-06-18.png]
>>
>> I read up on Boruvka's algorithm for finding the minimum spanning tree of 
>> a graph and have implemented a serialized version of it in Python. Can 
>> someone link me to resources on how to parallelize this algorithm?
>>
>

-- 
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/6b5305f1-adf7-4cf5-979d-145ca125063en%40googlegroups.com.

[sage-devel] Re: patchbot owners, please update to 3.0.3

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

Hi Frédéric,

due to https://trac.sagemath.org/ticket/33027 I have given up on running my 
patchbot.

Jonathan

Frédéric Chapoton schrieb am Montag, 17. Januar 2022 um 21:31:31 UTC+1:

> and to fix the remaining doc-cleaning issue, please upgrade again to the 
> master branch of github (aka tag 3.0.4)
>
> (I would appreciate answers, rather than full silence)
>
> Frédéric
> Le vendredi 14 janvier 2022 à 21:25:11 UTC+1, Frédéric Chapoton a écrit :
>
>> also patchbots have persistent problems with building docs. Can the 
>> people that changed something to doc-building please repair the patchbot 
>> accordingly ? pull request on github, please
>>
>> https://patchbot.sagemath.org/ticket/33157/
>>
>> Le vendredi 14 janvier 2022 à 17:40:27 UTC+1, Frédéric Chapoton a écrit :
>>
>>> Hello,
>>> github has removed the git: protocol. So patchbots need to be updated.
>>> please update your patchbot to the latest available tag
>>> Frédéric
>>>
>>>

-- 
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/997e9f75-8e92-4a67-b43a-1777074cbe45n%40googlegroups.com.

Re: [sage-devel] Whats the plan for random doctests with floating point numbers?

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

Sorry for being late to the party.

To save Volker the headache, I would propose setting the environment 
variable SAGE_DOCTEST_RANDOM_SEED to zero for buildbots (see 
https://trac.sagemath.org/ticket/32761).
It's not the job of buildbots to discover random test failures (patchbots 
on the other hand should check on this).

+1 to the approach of Kwankyu Lee (mark failures, open ticket, cc the 
person that wrote the offending test).

I think, doctests that fail for some values should be removed or fixed. 
E.g. claiming that matrix inversion can be done with fixed absolute error 
is just wrong.
Relative error will probably work for many purposes.
I had some instances, were I used maximum of some absolute error and some 
relative error, e.g.:

sage: x = random_value()
sage: abs(x) * abs(floating_point_computation(x) - exact_value(x)) < 
tolerance * max(1, abs(x), abs(x)^2)
True

This might need to be altered, depending on where the calculation is not 
stable.

In general, I would wrap this in a loop and experiment how large the error 
can get and if it stabilizes.
Sorry this creates work, but on the other hand as mentioned above, our 
doctests shouldn't claim some stability that just cannot be achieved.

Jonathan
David Roe schrieb am Donnerstag, 30. Dezember 2021 um 20:49:33 UTC+1:

> We already have a relative tolerance check available:
>
> sage: print("0.")# rel tol 1e-4
> 1.0
> sage: print("1.1")   # abs tol 1e-5
> 1.0
> David
>
> On Thu, Dec 30, 2021 at 2:42 PM tobia...@gmx.de  wrote:
>
>> It would also be an idea to replace these absolute tolerance tests, i.e. 
>> abs(x - y) < something, by a relative tests abs(x-y)/x < something. In 
>> general, this should be more stable. Such an approach is used by pytest, 
>> see https://docs.pytest.org/en/6.2.x/reference.html#pytest-approx. Maybe 
>> this helper function could be directly re-used, which would also simplify 
>> comparing lists etc.
>>
>> On Thursday, December 30, 2021 at 7:18:11 AM UTC+1 Kwankyu Lee wrote:
>>
>>> On Thursday, December 30, 2021 at 8:40:35 AM UTC+9 
>>> dmo...@deductivepress.ca wrote:
>>>
 In the long run, we want to fix the doctests so they always pass (as 
 described in the previous comment).

 However, in the short run, I think it is fine to add

 set_random_seed(0)  # failed doctest - see  trac ticket n

>>>
>>> +1. So this is (B). The ticket n is cc'ed to the writer of the 
>>> failed doctests.
>>>
>> -- 
>> 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/8717e8ca-820a-460f-aff6-299dfe97dca1n%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/fb434cc3-5211-4b2d-9c68-c5a5b79eaeadn%40googlegroups.com.

[sage-devel] Re: random doctest failure in BinaryQF.solve_integer

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

Dear Vincent,

this has been resolved in https://trac.sagemath.org/ticket/33026 (positive 
review, but not closed).

Jonathan

vdelecroix schrieb am Mittwoch, 5. Januar 2022 um 09:04:13 UTC+1:

> Dear all,
>
> In the following patchbot report
>
>
> https://patchbot.sagemath.org/log/32553/Linux/1_SMP_Debian_5.10.84-1_(2021-12-08)/x86_64/5.10.0-10-amd64/tmonteil-lxc3/2022-01-04%2017:18:22
>
> one can see
>
> sage -t --long --random-seed=147150541496621216702880946653671608515 
> src/sage/quadratic_forms/binary_qf.py
> **
> File "src/sage/quadratic_forms/binary_qf.py", line 1498, in 
> sage.quadratic_forms.binary_qf.BinaryQF.solve_integer
> Failed example:
> xy is None or Q(*xy) == 0
> Expected:
> True
> Got:
> False
> **
> 1 item had failures:
> 1 of 12 in sage.quadratic_forms.binary_qf.BinaryQF.solve_integer
> [282 tests, 1 failure, 0.41 s]
>
> However this is not reproducible on my machine.
>
> Best
> Vincent
>

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

[sage-devel] patchbots open maxima threads and don't close them

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

Hi there,

I run a patchbot (panke), which completely slowed down because of maxima 
threads that ate away my memory. There were like 10 of them. Is this a bug?

Killing those threads the patchbot keeps on running just fine. So 
apparently, they were really lost.

Jonathan

-- 
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/1d7f0333-0da5-40f6-be75-f6507e5b271fn%40googlegroups.com.

Re: [sage-devel] Constructor of a very large matrix doesn't copy entries correctly

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

FF = GF(next_prime(100))
M = Matrix(FF, [[1, 2], [3, 4]])
M.__init__??

reveals that the indices are casted into a long. This might be the problem.

Using Py_ssize_t or size_t might have been a better choice.

Jonathan
dim...@gmail.com schrieb am Mittwoch, 1. Dezember 2021 um 20:56:16 UTC+1:

>
>
> On Wed, Dec 1, 2021 at 4:39 PM Anton Mellit  wrote:
> >
> > When I create a very large matrix (the threshold may be 2^32 entries) 
> from a list of vectors, the elements are not copied over correctly.
> > Here is a "small" example:
> >
> > FF = GF(next_prime(100))
> > M = 7
> > N = 8
> > v1 = vector(FF, [FF(k) for k in range(N)])
> > v2 = vector(FF, [N] * N)
> > vecs = [v1 + v2*FF(i) for i in range(M)]
> > mat = matrix(FF, M, N, vecs)
> > mat[0] == vecs[0]
> >
> > the last line returns "false".
> > I understand the bug is not so easy to reproduce: the code above runs 
> for about 40 minutes and needs about 50G of RAM. In fact, it is also 
> strange that it takes so long: all the lines until "mat = matrix(FF, M, N, 
> vecs)" take only about a minute. It shouldn't take so much more time to 
> simply copy a bunch of vectors than it took to compute them.
> >
> Matrices in Sage are not just array, they come with parents - vector 
> spaces of matrices of this size.
> Perhaps it's where the time bottleneck is - in creating the parent, that 
> code wasn't obviously optimised for these kinds of dimensions.
>
> As to the error... Hard to say, one needs to look at the code (and find a 
> machine to reproduce the example). 
>
> Dima
>
>
> > Sage version: 9.3 running on a 64 bit linux system
> >
> >
> > --
> > 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/d06f39c6-f066-4e83-a2c1-2bbcba345f36n%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/9c38f81a-f471-41e1-a36f-07b618232f47n%40googlegroups.com.

Re: [sage-devel] Failed to build cysignals-1.10.3 and pyzmq-22.2.1 on a Fedora 35 (x86_64)

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

Thanks for the report. For cysignals we have the ticket 
https://trac.sagemath.org/ticket/32576 and github issue 
https://github.com/sagemath/cysignals/issues/150.

furutaka@gmail.com schrieb am Montag, 22. November 2021 um 04:17:55 
UTC+1:

> Forgot to attach this...
>
> 2021年11月22日(月) 11:31 Kazuyoshi Furutaka :
>
>> Hi,
>>
>> My build of sage-9.5.beta7 on a Fedora 35 system (x86_64) failed:
>> * package: cysignals-1.10.3
>>   last build time: Nov 22 11:13
>>
>> * package: pyzmq-22.2.1
>>   last build time: Nov 22 11:13
>>
>> Logs attached to this message.
>>
>> By the way, they've been installed as Fedora packages:
>> [root@peart-furu-or-jp furutaka]# dnf list installed \*zmq\* \*cysignals\*
>> Installed Packages
>> czmq.x86_64  4.2.1-6.fc34
>> @fedora
>> czmq-devel.x86_644.2.1-6.fc34
>> @fedora
>> python3-cysignals.x86_64 1.10.3-2.fc35   
>> @fedora
>> python3-cysignals-devel.x86_64   1.10.3-2.fc35   
>> @fedora
>> python3-zmq.x86_64   22.2.1-1.fc35   
>> @fedora
>> python3-zmq-tests.x86_64 22.2.1-1.fc35   
>> @fedora
>>
>> -- 
>> 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/392b7480-e729-48cb-ab98-8cb9af2ce7b0n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kazuyoshi Furutaka
>

-- 
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/cb500286-5d5f-4ae2-bd0e-8eacda0958c2n%40googlegroups.com.

[sage-devel] Re: Flint 2.8.4 Released

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

See https://trac.sagemath.org/ticket/32211 for package upgrade.
Bill Hart schrieb am Mittwoch, 17. November 2021 um 19:44:30 UTC+1:

> Hi all,
>
> I just tagged Flint-2.8.4. This is a critical bug fix release and so
> we strongly recommend upgrading.
>
> * Fix a serious bug in fmpz_mod_poly_xgcd for polynomials of large length
> * Fix an assertion failure in fmpz_mat_solve_fflu (only relevant if
> asserts enabled)
> * Fix some bugs on 32 bit machines
> * Work around a compiler bug on Apple M1
> * Fix bug in nmod_mpoly_factor (returned 0 for some factorisations)
> * Fix some documentation build errors and some doc formatting issues
>
> Please note that the C++ wrapper is now considered unmaintained. We
> will keep it compiling in its current state, but will not be wrapping
> additional flint functions.
>
> If any C++ developers would like to take over maintenance, we estimate
> it would be about 3-4 months of effort full time to wrap the remaining
> flint functions in C++ for a VERY experienced C++ developer. Replacing
> the old metaprogramming wrapper with a new one using more modern C++
> features would be about 4-6 months full time work for an experienced
> C++ developer.
>
> If you would like to volunteer, but not be paid for your effort,
> please let us know [1].
>
> Bill.
>
> [1] Application forms are available at Flint Headquarters, Abandoned
> House, Pfälzerwald.
>

-- 
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/80a2afb8-14ed-438a-875b-cc1896e6fc97n%40googlegroups.com.

[sage-devel] Re: Error compiling cysignals-1.10.3 / gcc 11.2.0

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

I have have found a fix elsewhere and copy/pasted it in 
https://github.com/sagemath/cysignals/pull/151, this might already solve 
the issue.

Fixes this and possibly upgrading cysignals is now
https://trac.sagemath.org/ticket/32576.

Manuel González schrieb am Samstag, 25. September 2021 um 23:52:48 UTC+2:

> Unfortunatelly it doesn't compile, exact same error
>
> Being this an error caused by a change in glibc 2.34 I don't think there 
> is much
> to do whilst we wait for the cysignals fix, but I may be wrong,.
> so any other idea is welcome
>
> Thanks 
> Manuel
>
> On Saturday, September 25, 2021 at 3:04:21 AM UTC-5 
> jonatha...@googlemail.com wrote:
>
>>
>> https://github.com/openbsd/src/commit/ea0d1f1fdbdc98dc215aafd8869e67812566a636#diff-abef93fb3c734d17f027b68052e70aac7e9949432392fb4910c1578ca087534a
>>
>> MINSIGSTKSZ is no longer a constant, which causes this problem.
>>
>> Does it compile, when you add `--std=c11` to your `CFLAGS`.
>>
>> E.g. do `sage -sh` and then `echo $CFLAGS` and then
>>
>> run
>>
>> make cysignals CFLAGS=" --std=c11"
>>
>> Jonathan
>> Manuel González schrieb am Samstag, 25. September 2021 um 03:52:15 UTC+2:
>>
>>>

-- 
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/007a87c3-4011-44c2-bcb6-2e012577d02bn%40googlegroups.com.

[sage-devel] Re: Error compiling cysignals-1.10.3 / gcc 11.2.0

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

Sorry for the wrong reference, I guess the following reference is better:

https://lists.gnu.org/archive/html/info-gnu/2021-08/msg1.html

Maybe compiling cysignals without march native is also and option until 
this problem is resolved for cysignals.
jonatha...@googlemail.com schrieb am Samstag, 25. September 2021 um 
10:04:21 UTC+2:

>
> https://github.com/openbsd/src/commit/ea0d1f1fdbdc98dc215aafd8869e67812566a636#diff-abef93fb3c734d17f027b68052e70aac7e9949432392fb4910c1578ca087534a
>
> MINSIGSTKSZ is no longer a constant, which causes this problem.
>
> Does it compile, when you add `--std=c11` to your `CFLAGS`.
>
> E.g. do `sage -sh` and then `echo $CFLAGS` and then
>
> run
>
> make cysignals CFLAGS=" --std=c11"
>
> Jonathan
> Manuel González schrieb am Samstag, 25. September 2021 um 03:52:15 UTC+2:
>
>>

-- 
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/65ff12b9-06b6-48dd-ac48-d620f3b0bef3n%40googlegroups.com.

[sage-devel] Re: Error compiling cysignals-1.10.3 / gcc 11.2.0

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

https://github.com/openbsd/src/commit/ea0d1f1fdbdc98dc215aafd8869e67812566a636#diff-abef93fb3c734d17f027b68052e70aac7e9949432392fb4910c1578ca087534a

MINSIGSTKSZ is no longer a constant, which causes this problem.

Does it compile, when you add `--std=c11` to your `CFLAGS`.

E.g. do `sage -sh` and then `echo $CFLAGS` and then

run

make cysignals CFLAGS=" --std=c11"

Jonathan
Manuel González schrieb am Samstag, 25. September 2021 um 03:52:15 UTC+2:

>

-- 
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/21e70645-ceb2-4d53-830c-ef873a4a3569n%40googlegroups.com.

Re: [sage-devel] Re: Registering NumberField as numbers.Number

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

Thanks for the answers.

I didn't realize this whole issue was this involved. It's certainly 
interesting.

For now I think there is nothing wrong with registering 
`NumberFieldElement` as `numbers.Numbers`, see 
https://trac.sagemath.org/ticket/32206.

Jonathan


mathzeta2 schrieb am Donnerstag, 15. Juli 2021 um 23:58:45 UTC+2:

> On 15/07/2021 22:11, William Stein wrote:
> > On Thu, Jul 15, 2021 at 11:05 AM William Stein  wrote:
> >>
> >> On Thu, Jul 15, 2021 at 9:13 AM Nils Bruin  wrote:
> >>>
> >>> Following up: while sage's "RationalNumber" is indeed a 
> numbers.Rational according to "isinstance", it does not actually adhere to 
> the stated API: "numerator" and "denominator" are supposed to be 
> properties, but in sage they are methods. So even in places where we are 
> trying to fit into "Number" we are already failing. Changing the way that 
> "numerator" and "denominator" behave would break a *LOT* of sage code.
> >>
> >> It's 100% my fault that numerator and denominator are function calls
> >> instead of properties. Here's why I made that choice, both for
> >> rational numbers and for a lot of other things. The reason is that I
> >> watched lots of grad students struggling to use Sage/Python around
> >> 2006 (e.g., at Arizona Winter School, in classes, etc.), and having
> >> two different concepts -- methods *and* attributes -- with no easy way
> >> to know which is which, just made things much more difficult for
> >> people. People would do things like:
> >>
> >> sage: A = matrix(...)
> >> sage: A.det
> >>  >> sage.matrix.matrix_integer_dense.Matrix_integer_dense object at
> >> 0x7f7fca0c2ca0>
> >>
> >> and be like "WTF?", and I would explain "A.det is a function. You
> >> have to call it.", and they woud then do
> >>
> >> sage: A.det()
> >> number
> >>
> >> and think "OK, sage makes sense." If basically at random half of the
> >> things listed in tab completion needed parens after them and half
> >> didn't, that would confuse the hell out of my poor potential users.
> >> And with Sage there is really no clear way to decide whether or not
> >> something should be a property or a method, since it's really a
> >> function of "how hard is it to compute? are there different inputs to
> >> computing it?" The answer to the second question is unknown when you
> >> write the thing, e.g., an input could be the algorithm or whether
> >> proof is True. The thing that really convinced me was that
> >> "A.det?" would give help on a number (not the det function) in IPython
> >> back then at least -- well definitely "help(A.det)" would "not work"
> >> at all in a helpful way.
> >>
> >> Please keep in mind that I made this choice over 15 years ago when
> >> Sage had only a few users, and it would today have no users if I
> >> hadn't made many design choices based on "what will confuse new users
> >> less in 2005"...
> >>
> >> -- William
>
> For one more attempt by Jeroen Demeyer at solving this issue, please see
>
> https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037
> I find the history of this topic quiet interesting.
>
> Using methods for all public API of Sage still seems to me as the better 
> choice. The reasons given above for this (no need to guess if 
> parentheses are required and the expectation that properties are very 
> efficient) are still relevant today.
>
> In addition, it is possible that in the future numerator/denominator 
> might get new arguments (e.g. reduce, canonicalize, or normalize as in 
> SR). One more reason is that the numerator/denominator methods are used 
> for more complicated mathematical objects in Sage, where calling them 
> with arguments is sensible. In the python-ideas discussion Vincent 
> Delecroix mentions that also real and imag methods/properties have the 
> same problem, like calling `1j.real` in Sage compared to Python.
>
> Regards,
> TB
>

-- 
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/bb4d13d1-4607-4bf2-b779-c1a75741224fn%40googlegroups.com.

[sage-devel] Registering NumberField as numbers.Number

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

Hi, I was looking into typing a bit and realized that our number field 
elements are not registered as numbers. So the following will not evaluate 
to true:

sage: import numbers
sage: K. = QuadraticField(2)
sage: isinstance(a, numbers.Number)

Is there a reason, we do not register number fields in 
`rings/numbers_abc.py`? Can I just change this?

E.g. I want to specify an iterable over numbers via 
`Iterable[numbers.Number]`, which would not include our number field 
elements currently.

Jonathan

-- 
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/07d0e686-c77c-460a-b874-5de682a3cb31n%40googlegroups.com.

[sage-devel] implicitly fuzz RNG-dependent doctests

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

Dear all,

most of sage's doctest are independent of random seeds by now. It would be 
nice if you could not add new doctests that depend on the random seed of 
the doctester.

Usually one needs to be carefull when adding doctests with `random_element` 
and `some_elements`. If you not sure on how to resolve this, you can also 
CC me (gh-kliem).
This would help a lot with
https://trac.sagemath.org/ticket/29935

During this project I have discovered about 20 more or less serious bugs. 
Also lots of smaller documentation bugs, e.g. doing an operation on a 
random element that assumes it not being zero. In addition, we have now 
doctests that verify basic properties of distribution of our random 
elements.

Once our doctests are run on random seeds, we can somewhat verify basic 
properties on many elements. In the past a test on a random element would 
verify this on exactly one element. In the future these tests should be run 
on many elements, hopefully catching many bugs.

Jonathan

-- 
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/542fb020-2976-411d-b773-0aaaee0d3518n%40googlegroups.com.

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

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

I never worked with conda, but it looks like it's doable also for an 
inexperienced person.

At the moment we have a somewhat working setup for those poorly maintained 
systems. I don't want to remove it without a proper alternative. If the 
alternative is to document that one should/can use conda instead, then this 
is fine with me. There is no need to reinvent the wheel.

This is what it looks like from my point of view for poorly mainained 
systems without root priviliges:

Current situation: Some sort of support.
What I wouldn't like: No support.
What would be a nice resolution: Get conda running (if not already 
installed). There is plenty of help out there for this. Once you got conda 
running, we can help you.
dim...@gmail.com schrieb am Freitag, 25. Juni 2021 um 08:29:51 UTC+2:

> On Fri, 25 Jun 2021 at 07:12, 'jonatha...@googlemail.com' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> I did a large computation on a redhat application server 1 1/2 years ago 
>> and I was very happy that I could just compile gcc to replace the version 
>> 4.x. There where a couple of problems though, but all of them could be 
>> resolved. I can't reproduce this however, as those people have thankfully 
>> provided gcc 10.2.0 in the meantime.
>>
>
> I do not see an effort to maintain the ability (sometimes broken?) to 
> build/install gcc and python 
> as a core task for Sagemath. It is a burden on bots, on GH Actions we run, 
> on people who actually maintain it, on users who try going this route 
> without thinking.
>
> Spin it out into an alternative to Conda if you so inclined.
> Such a separation would make it clean for the user that it is not 
> necessary in 99% of the cases, that it can be updated independently, etc.
>
> I should have added the rest of Sage “toolchain” to the list.
>
>
>> It's -1 from my side unless:
>> - there is a tool that allows installling gcc (or a tested compiler) 
>> without root privileges,
>> - it's well-documented and whatever the instructions, also a non-advanced 
>> person can follow it,
>> - there is still support for the issues with that (it doesn't have to be 
>> from our community)
>>
>> In general, I think it is a good idea to join forces. If there is a 
>> community/tool that deals with these kind of issues already, we could 
>> invest our resources in other things.
>>
>> Sidenote: I also think that administrators in universities etc. should 
>> provide a decent compiler, but I don't think we are going to change this. 
>> Our university network provides you a bunch of gcc versions and this makes 
>> life a lot easier for everyone.
>> Matthias Koeppe schrieb am Freitag, 25. Juni 2021 um 03:59:20 UTC+2:
>>
>>> On Thursday, June 24, 2021 at 4:24:10 PM UTC-7 Michael Orlitzky wrote:
>>>
>>>> On Thu, 2021-06-24 at 15:54 -0700, Volker Braun wrote:
>>>>
>>>>
>>>> > What about replacing gcc with a script that installs the conda 
>>>> toolchain 
>>>>
>>>>
>>>> > automatically. The distro gcc currently does not work for me, so its 
>>>> not 
>>>>
>>>>
>>>> > THAT rare to get into problems. On the other hard, installing conda 
>>>> is more 
>>>>
>>>>
>>>> > likely to work than compiling gcc from scratch.
>>>>
>>>>
>>>>
>>>> What does Conda do that a gcc-10 deb/rpm can't do?
>>>>
>>>
>>> It can be installed by unprivileged users. 
>>>
>>>  
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>>
>>
>> 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/fcb07cc1-4a0c-422b-a7df-05e87215693dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/fcb07cc1-4a0c-422b-a7df-05e87215693dn%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/acfe0292-43ea-4a24-93d0-4917d8c869d2n%40googlegroups.com.

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

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

I did a large computation on a redhat application server 1 1/2 years ago 
and I was very happy that I could just compile gcc to replace the version 
4.x. There where a couple of problems though, but all of them could be 
resolved. I can't reproduce this however, as those people have thankfully 
provided gcc 10.2.0 in the meantime.

It's -1 from my side unless:
- there is a tool that allows installling gcc (or a tested compiler) 
without root privileges,
- it's well-documented and whatever the instructions, also a non-advanced 
person can follow it,
- there is still support for the issues with that (it doesn't have to be 
from our community)

In general, I think it is a good idea to join forces. If there is a 
community/tool that deals with these kind of issues already, we could 
invest our resources in other things.

Sidenote: I also think that administrators in universities etc. should 
provide a decent compiler, but I don't think we are going to change this. 
Our university network provides you a bunch of gcc versions and this makes 
life a lot easier for everyone.
Matthias Koeppe schrieb am Freitag, 25. Juni 2021 um 03:59:20 UTC+2:

> On Thursday, June 24, 2021 at 4:24:10 PM UTC-7 Michael Orlitzky wrote:
>
>> On Thu, 2021-06-24 at 15:54 -0700, Volker Braun wrote: 
>> > What about replacing gcc with a script that installs the conda 
>> toolchain 
>> > automatically. The distro gcc currently does not work for me, so its 
>> not 
>> > THAT rare to get into problems. On the other hard, installing conda is 
>> more 
>> > likely to work than compiling gcc from scratch. 
>>
>> What does Conda do that a gcc-10 deb/rpm can't do?
>>
>
> It can be installed by unprivileged users. 
>
>  
>

-- 
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/fcb07cc1-4a0c-422b-a7df-05e87215693dn%40googlegroups.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

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

Are there objections of adding this new standard package, which consists of 
the code from `ext/memory_allocator.*`?

This is now https://trac.sagemath.org/ticket/31591.

I would like to put it on `github.com/sagemath` but need either help or 
permissions to do so.

The new package does not depend on cysignals anymore for the following 
reasons:
- Cysignals is not installable on windows without cygwin.
- Cysignals is used in case of  `sig_on`/`sig_off` around `MemoryAllocator` 
allocation methods. However this is unsafe and incorrect usage of 
`sig_on`/`sig_off` as only pure C/C++ code may be executed within and 
extension class cdef methods that involve `self` are not pure C/C++ (they 
also do not allow to be declared `nogil`). Currently, such usage is not the 
case in sage.

If you have objections, concerns or other comments, please put them here or 
directly on #31591.

Thank you,

Jonathan
jonatha...@googlemail.com schrieb am Montag, 29. März 2021 um 23:43:34 
UTC+2:

> On 29.03.21 21:53, Matthias Koeppe wrote:
>
> On Monday, March 29, 2021 at 12:08:36 PM UTC-7 jonatha...@googlemail.com 
> wrote:
>
>> I think in case of a pxd files things are a bit different. If someone 
>> uses cysignals and memory_allocator in the same place, e.g.
>>
>> cdef MemoryAllocator mem = MemoryAllocator()
>> sig_on()
>> foo = mem.malloc(1000)
>> sig_off()
>>
>> this would have to recompile the corresponding pxd file. So one could 
>> check in that pxd file, whether cysignals is present or not. So I think 
>> this could be set up, such that any project cimporting from 
>> memory_allocator that requires cysignals has memory_allocator with 
>> cysignals support. 
>>
> Right. If an importing project declares both memory_allocator and 
> cysignals as "build-system requires" in pyproject.toml, then it can make 
> use of both; so conditionalization memoryallocator.pxd based on 
> cython_compile_time_env does make sense.
>
> I didn't figure this out until after you showed me the reference.
>
> conditionalization based on cython_compile_time_env might be hard though. 
> There is no such thing as
>
> try:
> from cysignals.signals cimport sig_on, sig_off
> except:
> from .signals_backup cimport sig_on, sig_off
>
> One thing that one may try is basically the following:
>
> cdef void (*sig_block_pt)()
> cdef void (*sig_unblock_pt)()
>
> if has_cysignals:
> # replace sig_block, sig_unblock properly
> else:
> # replace by pass-functions
>
> However, this probably needs an update of cysignals, as we need a way to 
> access the addresses of sig_block/sig_unblock on runtime (which is the 
> cython_compile_time_env).
>
>
> The question remains, is it worth it? Do we need/want 
> sig_block/sig_unblock for MemoryAllocator?
>
>
> -- 
> 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/6u1VuXJE7wE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f619d534-43b8-4fc9-aaaf-91d2db52a4b6n%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/eca09c24-6d63-494f-8f4f-0529d5db7974n%40googlegroups.com.

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

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

I think I tracked it down.

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

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

`sage --standard | grep gmp`

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

`sage --standard | grep flint`

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

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

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

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

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

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

It looks to me as if all of this ticket can be "fixed" to work with python 
3.7 by just trying to import shared_memory.

`start_worker_pool` should probably raise a proper error message, if the 
import of shared_memory failed previosly.

The few doctests that explicitly call `start_worker_pool` can do something 
as:

sage: if sys.version_info[:2] != (3, 7): f.start_worker_pool()  #  requires 
python 3.8+

Also `use_mp=True` could be ignored on python 3.7 (and this should be 
documented).

Jonathan
David Roe schrieb am Donnerstag, 13. Mai 2021 um 08:16:54 UTC+2:

> One way to do it is to modify the auto_optional_tags variable in 
> sage.doctest.control lines 47-54 to add a more specific python version 
> tag.  This doesn't get you inequalities in versions though.
>
> You could also just add an if statement around your test if there are few 
> enough of them (e.g. int(sys.version.split('.')[1]) >= 8).
> David
>
> On Wed, May 12, 2021 at 8:34 PM 'Travis Scrimshaw' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> Own tag might be a goood way forward as the code itself can run on Python 
>> 3.7 by avoiding the multiprocessing. It would be purely to state that we 
>> don't want to test the mp parts of the code. How do I make an optional tag? 
>> I am worried that since this is not simply an optional package to test but 
>> against a Python version, it would require a slightly invasive change to 
>> the doctesting framework. There also is an option of testing for a more 
>> specific import from Python too.
>>
>> Best,
>> Travis
>>
>> On Wednesday, May 12, 2021 at 7:10:53 AM UTC+10 Volker Braun wrote:
>>
>>> Yet another possibility is to look for a backport that implements 
>>> sufficient functionality for your needs for now.
>>>
>>> On Tuesday, May 11, 2021 at 2:40:04 AM UTC+2 Matthias Koeppe wrote:
>>>
 -1. Even NEP 29 (
 https://numpy.org/neps/nep-0029-deprecation_policy.html) does not drop 
 Python 3.7 support before end of the year.


 On Monday, May 10, 2021 at 4:12:48 PM UTC-7 Travis Scrimshaw wrote:

> On #30423 , which is getting 
> close to completion, we will be using multiprocessing.shared_memory, 
> which 
> is only available on Python 3.8+. However, right now we are at least 
> allowing Python 3.7 (as per the patchbot). So my main proposal would be 
> to 
> bump the minimum required Python version to 3.8, which was released Oct. 
> 14, 2019.
>
> On that ticket, we can make it so that the main entry point runs 
> things in serial if the Python version is sufficiently small and that the 
> doc builds, but the doctests for the parallel code will fail. So the 
> first 
> alternative option would be to mark certain doctests (or the file) as 
> needing a large Python version.
>
> A second alternative is that this can be split off as a separate 
> package (either an optional Sage package or pip installable). Yet, it is 
> somewhat tightly coupled with the FusionRing code (and root systems) in 
> Sage, so this is not so desirable. A less invasive way would be to just 
> split the parallel part off, but this would take some work to do I think.
>
> What do people think?
>
> Best,
> Travis
>
> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/ae100fbf-8b77-4c9c-b92a-cde41e6d17f8n%40googlegroups.com
>>  
>> 
>> .
>>
>

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

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

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

Dear Freddie,

thank you for the report.

Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on the 
develop branch (on ubuntu focal with libflint-2.5.2 and debian buster with 
sage's flint 2.6.3).

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

You can go into detail, to see, what exactly is causing the problem and 
instead of

_ = identity_matrix(n).change_ring(GF(101))

run the underlying functions

M = identity_matrix(n)
L = M.list()
MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, sparse=False)
mat = MS(L, coerce=True, copy=False)

Maybe repeatedly running the first line causes leakage already?

Jonathan

Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2:

> Dear all
>
> [I attempted to post this a few days ago but seemingly failed, so this is 
> a repost; apologies if duplicate.]
>
> The following program appears to consume all the memory on my machine:
>
> n = 1000
> for i in range(0, 100):
> _ = identity_matrix(n).change_ring(GF(101))
> print(get_memory_usage())
>
> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 5.4.97-gentoo, 
> gcc version 10.2.0).
>
> I couldn't find any related open bugs.  I have worked around the issue 
> (solution: don't create intermediate integer matrices and then coerce them 
> to finite fields; obviously it's less explicit in my original code) but 
> either way this seems to be a new bug.
>
> Best
> Freddie
>

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

[sage-devel] Re: tab-completions crashes sage 9.3.rc2

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

+1

In addition to the above arguments, there are two other advantages (but 
which do not justify deactivating jedi tab completion for sage-9.3):

- It's noticably faster without jedi.
- Keywords of functions appear first in the list, where they belong and not 
somewhere hidden. (Deactivating jedi as above, I can tab complete 
`polytopes.cube(` and immediatily see the two available keywords).

Jonathan

vdelecroix schrieb am Samstag, 10. April 2021 um 22:30:13 UTC+2:

> Dear all,
>
> This message is an emergency call to deactivate jedi before sage-9.3.
>
> I had a recent post about tab-completion crashing sage. It involved
> external libraries and could be somehow considered as minor. Here are
> two more serious issues
>
> 1. If you tab-complete "s" with in Sage twice it will crash Sage
> (see details in https://trac.sagemath.org/ticket/31632#comment:22)
>
> 2. If you tab-complete then all lazy import that starts with the
> prefix are resolved
> (see for example https://trac.sagemath.org/ticket/31632#comment:16)
>
> Actually, number 1 is a consequence of number 2 and the underlying
> problem is tracked at https://trac.sagemath.org/ticket/31643.
>
> There is an easy way to go which consists in turning off jedi (and
> fall back to the internal IPython completer). All problems above
> will be avoided. You can test it yourself with
>
> sage: from IPython import get_ipython
> sage: ip = get_ipython()
> sage: ip.Completer.use_jedi = False
>
> Could that be done? I am welcoming any other suggestion.
>
> Best
> Vincent
>

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

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

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

https://github.com/kliem/memory_allocator

I started MemoryAllocator as a seperate project. I think it is almost ready 
to push to PyPI. Any opinions? Do I need permission to publish it like 
this? Should this be moved into a different repository? (E.g. 
https://github.com/sagemath/memory_allocator).

It symlinks `cysignals/src/cysignals/memory.pxd`. Thus it only depends on 
`sig_block`/`sig_unblock` from cysignals. This will be used, if cysignals 
is found at time of setup. Otherwise, `sig_block`/`sig_unblock` will be 
replaced by functions doing nothing. Using `sig_block`/`sig_unblock` only 
seems to make sense, if you have cysignals anyway.

Disadvantage of this approach is of course, that you need to make sure that 
you install cysignals before memory_allocator manually.

jonatha...@googlemail.com schrieb am Donnerstag, 11. März 2021 um 10:33:35 
UTC+1:

> This approach might not be pretty, but it seems to work fine.
>
> I can use cysignals on cygwin, linux, mac and not use it on windows 
> without cygwin.
>
> However, it would be much nicer to allow pip installing cysignals on 
> windows without cygwin in the first place. This would simplify this a lot.
>
> jonatha...@googlemail.com schrieb am Mittwoch, 10. März 2021 um 17:44:05 
> UTC+1:
>
>> Here is my project (I just made the repository public): 
>> https://github.com/kliem/PyKPartiteKClique/tree/main/ 
>>
>> The source folder is kpkc 
>>
>> As you can see, I completely copied memory_allocator* 
>>
>> This should be moved to its own project eventually. 
>>
>> Instead of cimporting directly from cysignals (which may fail, if not 
>> present), I cimport from kpkc.cysignals 
>>
>> There are two files for this. kpkc/cysignals.pyx which is a plain 
>> wrapper about the cysignals functions (just cimporting did not work). 
>>
>> If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx 
>> as module kpkc.cysignals. 
>>
>> Of course, you need to reinstall the project, if you install cysignals 
>> afterwards. 
>>
>> On 10.03.21 16:07, E. Madison Bray wrote: 
>> > On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel 
>> >  wrote: 
>> >> What I'm struggling with is the following: 
>> >> 
>> >> How do I cimport from different sources (runtime dependent probably 
>> >> won't work, but compile time dependent would already be nice). At the 
>> >> moment my package just pulls in cysignals during pip install and if 
>> this 
>> >> does not work it replaces those functions by standard allocation 
>> functions. 
>> >> 
>> >> Is there a better solution to do this? 
>> > What do you mean by "cimport from different sources"? If you are 
>> > already working on this could you link to the source? 
>> > 
>> > If this is about my idea to make the memory allocation functions 
>> > "pluggable" that would be done by setting some function pointers to 
>> > them, which would be done by third-party Cython code using 
>> > MemoryAllocator (there would need to be a C method for setting them). 
>> > 
>> >> On 10.03.21 15:27, E. Madison Bray wrote: 
>> >>> On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe 
>> >>>  wrote: 
>>  On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote: 
>> > Why make it part of cysignals? The purpose of the memory allocator 
>> > is quite distinct from cysignals. Merging them look artificial to 
>> me. 
>>  Really? MemoryAllocator is just a wrapper class around 
>> cysignals.memory 
>> >>> Was there ever any action on this? MemoryAllocator does seem like a 
>> >>> useful thing to have as an independent package. It's basically a more 
>> >>> sophisticated version of the SomeMemory recipe given in the Cython 
>> >>> docs: 
>> https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html 
>> >>> 
>> >>> I agree that it's distinct from cysignals. It doesn't necessarily 
>> >>> have to depend on cysignals, and could have a hook interface to allow 
>> >>> different memory allocation functions. It just happens to use the 
>> >>> ones from cysignals since Sage already uses cysignals, and its memory 
>> >>> functions have the advantage of being interrupt-safe. 
>> >>> 
>> >>> I would continue using cysignals by default for an initial 
>> >>> implementation, but if anyone had a need for it, it would be possible 
>> >>> to make this work with cysignals as an optional dependency as well. 
>> >>> 
>> >> -- 
>> >> 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/58a5c332-7331-8433-941e-b73f7090d608%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...@googlegrou

Re: [sage-devel] Linking libraries with spkg-install.in

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

Actually, the code I wrote for latte is better than I remembered. At some 
point I wanted to hardcode the location of the libraries.

But I guess, I abandoned this (maybe because someone told me, this was a 
bad idea).
jonatha...@googlemail.com schrieb am Freitag, 19. März 2021 um 11:38:46 
UTC+1:

> On 19.03.21 11:13, François Bissey wrote:
>
> >
> >> On 19/03/2021, at 23:05, 'jonatha...@googlemail.com' via sage-devel <
> sage-...@googlegroups.com> wrote:
> >>
> >> We configure libaries with e.g. `--with-zlib="$SAGE_LOCAL"` 
> unconditionally. Why would this succeed, if we use the systems `zlib`?
> >>
> > It depends a bit on whether you use a properly written configure script 
> or not.
> > Autotools tests and finds things by trying to compile things. If there 
> is no
> > lib in SAGE_LOCAL it will not prevent a compilation against a system 
> zlib to fail.
> > gcc -o test -I$SAGE_LOCAL/include -L$SAGE_LOCAL/lib test.c -lz
> > will look first in the SAGE_LOCAL locations but will still use the 
> standard location
> > if nothing is found in the custom ones.
> >
> > Where it will fail, is with custom scripts that work by trying to find a 
> file explicitly.
> > Like checking whether $SAGE_LOCAL/lib/libz.so exists. Those are bad 
> tests in the first
> > place.
> >
> > François
> >
> I see. What we do is definitely against the instructions of libgd's 
> configure ("where to find the zlib library"). But checking the actual 
> code, $SAGE_LOCAL is completely ignored in this specific case.
>
> So this really is a cdd specific problem (because I want to set the 
> preference according to the path and not according to which of 
> `setoper.h`, `cdd/setoper.h`, `cddlib/setoper.h` works).
>
> And I guess we usually just wait until this leads to problems somewhere 
> (e.g. for iml we specify `-with-gmp-include="$SAGE_GMP_INCLUDE").
>

-- 
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/4eadab4f-e717-4b66-a23d-ddb21c6d595bn%40googlegroups.com.

[sage-devel] Linking libraries with spkg-install.in

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

Hi, I think I made a mistake in https://trac.sagemath.org/ticket/31482, 
which might cause latte_int to fail building, if you use your systems cdd 
(which almost no one does, because the headers in cdd/ and cddlib/ are 
rejected currently).

However, it appears that we make this mistake all over spkg-install.in's?
We configure libaries with e.g. `--with-zlib="$SAGE_LOCAL"` 
unconditionally. Why would this succeed, if we use the systems `zlib`?

It appears to me that this only works, because people either use all the 
system packages possible or no packages at all. The above example seems to 
not come up, because people usually have libgd installed if they have zlib 
installed.

Jonathan

-- 
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/40139c6b-d765-4e75-9739-30f8079ab599n%40googlegroups.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

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

This approach might not be pretty, but it seems to work fine.

I can use cysignals on cygwin, linux, mac and not use it on windows without 
cygwin.

However, it would be much nicer to allow pip installing cysignals on 
windows without cygwin in the first place. This would simplify this a lot.

jonatha...@googlemail.com schrieb am Mittwoch, 10. März 2021 um 17:44:05 
UTC+1:

> Here is my project (I just made the repository public): 
> https://github.com/kliem/PyKPartiteKClique/tree/main/
>
> The source folder is kpkc
>
> As you can see, I completely copied memory_allocator*
>
> This should be moved to its own project eventually.
>
> Instead of cimporting directly from cysignals (which may fail, if not 
> present), I cimport from kpkc.cysignals
>
> There are two files for this. kpkc/cysignals.pyx which is a plain 
> wrapper about the cysignals functions (just cimporting did not work).
>
> If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx 
> as module kpkc.cysignals.
>
> Of course, you need to reinstall the project, if you install cysignals 
> afterwards.
>
> On 10.03.21 16:07, E. Madison Bray wrote:
> > On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel
> >  wrote:
> >> What I'm struggling with is the following:
> >>
> >> How do I cimport from different sources (runtime dependent probably
> >> won't work, but compile time dependent would already be nice). At the
> >> moment my package just pulls in cysignals during pip install and if this
> >> does not work it replaces those functions by standard allocation 
> functions.
> >>
> >> Is there a better solution to do this?
> > What do you mean by "cimport from different sources"? If you are
> > already working on this could you link to the source?
> >
> > If this is about my idea to make the memory allocation functions
> > "pluggable" that would be done by setting some function pointers to
> > them, which would be done by third-party Cython code using
> > MemoryAllocator (there would need to be a C method for setting them).
> >
> >> On 10.03.21 15:27, E. Madison Bray wrote:
> >>> On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
> >>>  wrote:
>  On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:
> > Why make it part of cysignals? The purpose of the memory allocator
> > is quite distinct from cysignals. Merging them look artificial to me.
>  Really? MemoryAllocator is just a wrapper class around 
> cysignals.memory
> >>> Was there ever any action on this? MemoryAllocator does seem like a
> >>> useful thing to have as an independent package. It's basically a more
> >>> sophisticated version of the SomeMemory recipe given in the Cython
> >>> docs: 
> https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html
> >>>
> >>> I agree that it's distinct from cysignals. It doesn't necessarily
> >>> have to depend on cysignals, and could have a hook interface to allow
> >>> different memory allocation functions. It just happens to use the
> >>> ones from cysignals since Sage already uses cysignals, and its memory
> >>> functions have the advantage of being interrupt-safe.
> >>>
> >>> I would continue using cysignals by default for an initial
> >>> implementation, but if anyone had a need for it, it would be possible
> >>> to make this work with cysignals as an optional dependency as well.
> >>>
> >> --
> >> 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/58a5c332-7331-8433-941e-b73f7090d608%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/c97629a6-d418-4ebc-99f6-e6305778abbdn%40googlegroups.com.

[sage-devel] Move MemoryAllocator to PyPI?

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

Dear all, I have two little projects that I want to put onto PyPI soon. 
Both of them use MemoryAllocator, because I find it very nice to just 
allocate memory and let pythons garbage collector take care of it. 
MemoryAllocator only depends on cysignals, so it would make sense to make 
it pip installable by itself (or as part of cysignals).

Any opinions on this?

Of course it takes almost no effort just rewrite MemoryAllocator. However, 
it also makes sense to avoid code duplications.

-- 
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/27836ec2-c5ce-412d-95e5-73363be65c71n%40googlegroups.com.

Re: [sage-devel] AttributeError: module 'sage.sandpiles.all' has no attribute 'absolute_import'

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

Downgrading to jedi 0.15, I instead get the error (after long wait time)

/usr/lib/python3.7/inspect.py:718: DeprecationWarning: 
sage.interacts.debugger is deprecated because it is meant for the 
deprecated Sage Notebook
See https://trac.sagemath.org/27531 for details.
  if hasattr(object, '__module__'):

All rather strange to me. To be clear. I'm not using jupyter, I'm just on 
the shell.

jonatha...@googlemail.com schrieb am Dienstag, 9. Februar 2021 um 21:10:49 
UTC+1:

> The jedi upgrade (to 0.18.0) does not fix the error, but does change the 
> log:
>
>
>
> jonatha...@googlemail.com schrieb am Dienstag, 9. Februar 2021 um 
> 21:05:20 UTC+1:
>
>> Actually the error is reproducible:
>>
>> def foo(): return 2
>> foo()
>> foo()
>>
>> What makes it crash is hitting TAB after opening the parenthesis and then 
>> completing it and hitting enter.
>>
>> Matthias Koeppe schrieb am Dienstag, 9. Februar 2021 um 17:56:31 UTC+1:
>>
>>> A Jupyter upgrade is in https://trac.sagemath.org/ticket/31280 - which 
>>> needs some help
>>>
>>> On Tuesday, February 9, 2021 at 6:52:51 AM UTC-8 Dima Pasechnik wrote:
>>>
>>>> it looks like https://github.com/davidhalter/jedi/issues/1615 
>>>> and our version of jedi is older than the fix there. 
>>>> Upgrade jedi (if this is possible without a full ipython/jupyter 
>>>> upgrade, don't know) ? 
>>>>
>>>> On Tue, Feb 9, 2021 at 1:56 PM 'jonatha...@googlemail.com' via 
>>>> sage-devel  wrote: 
>>>> > 
>>>> > 
>>>> > Dear all, 
>>>> > 
>>>> > sage crashes once in a while hard with some strange error. 
>>>> > 
>>>> > Does anyone know what is going on? This is somewhat new. Not 
>>>> reproducible. 
>>>> > 
>>>> > Happened to me maybe 3 or 4 times now at various occasions. 
>>>> > 
>>>> > Jonathan 
>>>> > 
>>>> > -- 
>>>> > 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/53367a09-45ff-4ebf-bcca-88766b0b77e9n%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/d4e347a9-ead5-401e-906b-7159ebd2679fn%40googlegroups.com.

Re: [sage-devel] AttributeError: module 'sage.sandpiles.all' has no attribute 'absolute_import'

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

The jedi upgrade (to 0.18.0) does not fix the error, but does change the 
log:



jonatha...@googlemail.com schrieb am Dienstag, 9. Februar 2021 um 21:05:20 
UTC+1:

> Actually the error is reproducible:
>
> def foo(): return 2
> foo()
> foo()
>
> What makes it crash is hitting TAB after opening the parenthesis and then 
> completing it and hitting enter.
>
> Matthias Koeppe schrieb am Dienstag, 9. Februar 2021 um 17:56:31 UTC+1:
>
>> A Jupyter upgrade is in https://trac.sagemath.org/ticket/31280 - which 
>> needs some help
>>
>> On Tuesday, February 9, 2021 at 6:52:51 AM UTC-8 Dima Pasechnik wrote:
>>
>>> it looks like https://github.com/davidhalter/jedi/issues/1615 
>>> and our version of jedi is older than the fix there. 
>>> Upgrade jedi (if this is possible without a full ipython/jupyter 
>>> upgrade, don't know) ? 
>>>
>>> On Tue, Feb 9, 2021 at 1:56 PM 'jonatha...@googlemail.com' via 
>>> sage-devel  wrote: 
>>> > 
>>> > 
>>> > Dear all, 
>>> > 
>>> > sage crashes once in a while hard with some strange error. 
>>> > 
>>> > Does anyone know what is going on? This is somewhat new. Not 
>>> reproducible. 
>>> > 
>>> > Happened to me maybe 3 or 4 times now at various occasions. 
>>> > 
>>> > Jonathan 
>>> > 
>>> > -- 
>>> > 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/53367a09-45ff-4ebf-bcca-88766b0b77e9n%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/703602b5-2699-4a57-a71d-bfb7de676db0n%40googlegroups.com.
***

IPython post-mortem report

{'commit_hash': 'd0b255042',
 'commit_source': 'installation',
 'default_encoding': 'UTF-8',
 'ipython_path': 
'/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython',
 'ipython_version': '7.13.0',
 'os_name': 'posix',
 'platform': 'Linux-4.19.0-10-amd64-x86_64-with-debian-10.8',
 'sys_executable': '/srv/public/kliem/sage/local/bin/python3',
 'sys_platform': 'linux',
 'sys_version': '3.7.3 (default, Jul 25 2020, 13:03:44) \n[GCC 8.3.0]'}

***



***

Crash traceback:

---
---
TypeErrorPython 3.7.3: /srv/public/kliem/sage/local/bin/python3
   Tue Feb  9 21:09:23 2021
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/srv/public/kliem/sage/src/bin/sage-ipython in 
  1 #!/usr/bin/env sage-python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 # Display startup banner. Do this before anything else to give the user
  8 # early feedback that Sage is starting.
  9 from sage.misc.banner import banner
 10 banner()
 11 
 12 from sage.repl.interpreter import SageTerminalApp
 13 
 14 app = SageTerminalApp.instance()
 15 app.initialize()
---> 16 app.start()
global app.start = >

/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/terminal/ipapp.py
 in start(self=)
341 if self.log_level <= logging.INFO: print()
342 
343 def _pylab_changed(self, name, old, new):
344 """Replace --pylab='inline' with --pylab='auto'"""
345 if new == 'inline':
346 warnings.warn("'inline' not available as pylab backend, "
347   "using 'auto' inste

Re: [sage-devel] AttributeError: module 'sage.sandpiles.all' has no attribute 'absolute_import'

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

Actually the error is reproducible:

def foo(): return 2
foo()
foo()

What makes it crash is hitting TAB after opening the parenthesis and then 
completing it and hitting enter.

Matthias Koeppe schrieb am Dienstag, 9. Februar 2021 um 17:56:31 UTC+1:

> A Jupyter upgrade is in https://trac.sagemath.org/ticket/31280 - which 
> needs some help
>
> On Tuesday, February 9, 2021 at 6:52:51 AM UTC-8 Dima Pasechnik wrote:
>
>> it looks like https://github.com/davidhalter/jedi/issues/1615
>> and our version of jedi is older than the fix there.
>> Upgrade jedi (if this is possible without a full ipython/jupyter
>> upgrade, don't know) ?
>>
>> On Tue, Feb 9, 2021 at 1:56 PM 'jonatha...@googlemail.com' via
>> sage-devel  wrote:
>> >
>> >
>> > Dear all,
>> >
>> > sage crashes once in a while hard with some strange error.
>> >
>> > Does anyone know what is going on? This is somewhat new. Not 
>> reproducible.
>> >
>> > Happened to me maybe 3 or 4 times now at various occasions.
>> >
>> > Jonathan
>> >
>> > --
>> > 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/53367a09-45ff-4ebf-bcca-88766b0b77e9n%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/e2745da7-79f0-461b-bd99-29ae299002b8n%40googlegroups.com.

[sage-devel] AttributeError: module 'sage.sandpiles.all' has no attribute 'absolute_import'

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

Dear all,

sage crashes once in a while hard with some strange error.

Does anyone know what is going on? This is somewhat new. Not reproducible.

Happened to me maybe 3 or 4 times now at various occasions.

Jonathan

-- 
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/53367a09-45ff-4ebf-bcca-88766b0b77e9n%40googlegroups.com.
***

IPython post-mortem report

{'commit_hash': 'd0b255042',
 'commit_source': 'installation',
 'default_encoding': 'utf-8',
 'ipython_path': 
'/home/jonathan/Applications/sage/local/lib/python3.8/site-packages/IPython',
 'ipython_version': '7.13.0',
 'os_name': 'posix',
 'platform': 'Linux-5.4.0-65-generic-x86_64-with-glibc2.29',
 'sys_executable': '/home/jonathan/Applications/sage/local/bin/python3',
 'sys_platform': 'linux',
 'sys_version': '3.8.5 (default, Jul 28 2020, 12:59:40) \n[GCC 9.3.0]'}

***



***

Crash traceback:

---
---
KeyError   Python 3.8.5: /home/jonathan/Applications/sage/local/bin/python3
   Tue Feb  9 14:50:23 2021
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
~/Applications/sage/local/lib/python3.8/site-packages/jedi/cache.py in 
wrapper(self=, *args=(), **kwargs={})
108 try:
--> 109 return dct[key]
dct = {}
key = ((), frozenset())
110 except KeyError:

KeyError: ((), frozenset())

During handling of the above exception, another exception occurred:

---
KeyError   Python 3.8.5: /home/jonathan/Applications/sage/local/bin/python3
   Tue Feb  9 14:50:23 2021
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
~/Applications/sage/local/lib/python3.8/site-packages/jedi/cache.py in 
wrapper(self=, 
*args=('get_signature_params',), **kwargs={})
108 try:
--> 109 return dct[key]
dct = {(('get_api_type',), frozenset()): 'function', (('is_instance',), 
frozenset()): True, (('getattr_paths', '__class__'), frozenset()): 
[, )>], (('py__class__',), frozenset()): 
, 
(('py__doc__',), frozenset()): '', (('get_repr',), frozenset()): 
'
  1 #!/usr/bin/env sage-python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 # Display startup banner. Do this before anything else to give the user
  8 # early feedback that Sage is starting.
  9 from sage.misc.banner import banner
 10 banner()
 11 
 12 from sage.repl.interpreter import SageTerminalApp
 13 
 14 app = SageTerminalApp.instance()
 15 app.initialize()
---> 16 app.start()
global app.start = >

~/Applications/sage/local/lib/python3.8/site-packages/IPython/terminal/ipapp.py 
in start(self=)
341 if self.log_level <= logging.INFO: print()
342 
343 def _pylab_changed(self, name, old, new):
344 """Replace --pylab='inline' with --pylab='auto'"""
345 if new == 'inline':
346 warnings.warn("'inline' not available as pylab backend, "
347   "using 'auto' instead.")
348 self.pylab = 'auto'
349 
350 def start(self):
351 if self.subapp is not None:
352 return self.subapp.start()
353 # perform any prexec steps:
354 if self.interact:
355 self.log.debug("Starting IPython's mainloop...")
--> 356 self.shell.mainloop()
self.shell.mainloop = >
357 else:
358 self.log.debug("IPython not interactive...")
359 if not self.shell.last_execution_succeeded:
360 sys.exit(1)
361 
362 def load_default_config(ipython_dir=None):
363 """Load the default config file from the default ipython_dir.
364 
365 This is useful for embedded shells.
366 """
367 if ipython_dir is None:
368 ipython_dir = get_ipython_dir()
369 
370 profile_dir = os.path.join(ipython_dir, 'profile_default')
371 app = TerminalIPythonApp()

~/Applications/sage/local/lib/python3.8/site-packages/IPython/t

[sage-devel] Re: Unable to build develop branch

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

For `sage -b` not working see https://trac.sagemath.org/ticket/31263 (on 
positive review).

Sorry about that (I positively review the ticket that broke it).

dwb...@gmail.com schrieb am Samstag, 23. Januar 2021 um 14:28:00 UTC+1:

> I cannot build the documentation. It actually crashes python. I'm 
> attaching my
> docbuild log.
>
> I have another problem which is that 'sage -b' does not work. It gives me 
> the error
> "This Makefile needs to be invoked by 'build/make/install'". If I set the 
> parameter
> SAGEPKGCONFIG then it works, but I shouldn't need to do that.
>
> Dan
>
> On Friday, January 22, 2021 at 5:16:28 PM UTC-8 John H Palmieri wrote:
>
>> Great, I'm glad to hear it!
>>
>> Have you run doctests? If so, are there many failures?
>>
>>
>> On Friday, January 22, 2021 at 4:45:59 PM UTC-8 dwb...@gmail.com wrote:
>>
>>>
>>> Contrary to my previous message, Ticket 31183 does fix the problem and I 
>>> can now build sage.
>>>
>>> Thanks,
>>> Dan
>>> On Friday, January 22, 2021 at 3:21:10 PM UTC-8 John H Palmieri wrote:
>>>
 I literally meant "merge that [the branch from #31183] into the develop 
 branch" (or vice versa), not just use the branch from #31183. The develop 
 branch has some crucial pieces for building Sage in Big Sur.

   John

 On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com 
 wrote:

> Thanks!
>
> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
> 
>  fails 
> in numpy and
> doesn't get to scipy. So I merged the change in #31166 (addressing 
> numpy) into
> the scipy-big-sur branch and that fails to build in scipy again.
>
> Dan
>
> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri 
> wrote:
>
>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix 
>> that. Merging that into the develop branch works for me.
>>
>> -- 
>> John
>>
>>
>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com 
>> wrote:
>>
>>> I'm unable to build the develop branch since upgrading my iMac to 
>>> Big Sur. I have python3 and scipy installed through homebrew. In 
>>> /usr/local/bin I have a symbolic link from python to python3.
>>>
>>> Although I have scipy through homebrew, Sage insists on installing 
>>> the spkg. In previous build attempts (in late December) the build 
>>> failed in 
>>> numpy.
>>>
>>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>>
>>> Thank you,
>>> Daniel Bump
>>>
>>>
>>>

-- 
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/8c0e2bad-5ef4-4c1a-9ae6-cb658c0b2082n%40googlegroups.com.

[sage-devel] 31036 needs review

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

Hi, could someone please review https://trac.sagemath.org/ticket/31036

I appreciate `sage --fixdoctests` and it made my life easier in the past. 
However, it does not work for multiline tests or testing error raising. 
This ticket is an attempt to fix this. And it's not a big ticket:

1 files changed, 17 insertions, 1 deletions

I didn't need this recently, still, it would be nice to have it, once 
needed.

Putting this `Traceback (most recent error last)` etc is still a pain, I 
think. I usually hope to find it somewhere else in the corresponding file 
and copy/paste it.

Thank you,

Jonathan

-- 
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/122f96af-a334-4e3e-8695-60ad26d8f1b8n%40googlegroups.com.

Re: [sage-devel] How to review a ticket?

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

You need to login somehow.

You have previously logged in with your github account `gh-bollu`. This 
works as well. After you log in, the edit options will appear.

Of course you can also create a sage account, which also lets you edit 
https://wiki.sagemath.org/ and maybe you prefer not to link your activities 
with your github account.

Anyway, for reviewing tickets etc, both options work. However, most people 
decide on one account, so that people don't get confused.

Thierry (sage-googlesucks@xxx) schrieb am Dienstag, 19. Januar 2021 um 
16:46:52 UTC+1:

> Hi,
>
> you could ask for a trac acount as explained in the developer guide:
>
> https://doc.sagemath.org/html/en/developer/trac.html#obtaining-an-account
>
> Ciao,
> Thierry
>
>
> On Tue, Jan 19, 2021 at 06:55:33AM -0800, Siddharth Bhat wrote:
> > Hey all,
> > 
> > I'm trying to learn how to review Trac tickets,and am unfortunately 
> failing 
> > at it. 
> > 
> > I want to leave some comments on this file: 
> > 
> https://git.sagemath.org/sage.git/diff/src/sage/homology/finite_topological_spaces.py?id=fc4c726665c7bf25c83a7fae6f04420e19086d69
> > 
> > which corresponds to this trac ticket:
> > https://trac.sagemath.org/ticket/30400#no3
> > 
> > but I can't find anything in the interface that lets me do so. I see 
> that 
> > the others have posted comments, such as this:
> > 
> > https://trac.sagemath.org/ticket/30400#comment:15
> > 
> > How do I post such a comment? 
> > 
> > Best,
> > ~Siddharth
> > 
> > -- 
> > 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/65051530-b717-44eb-bd6d-10b1793f9141n%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/3d49e559-447c-4d8d-89bc-fb97b95577bcn%40googlegroups.com.

[sage-devel] Re: How to compile sparse graph backend with c++

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

I tried to compile more things with C++ and things just got worse. But 
maybe I did it wrong, that is also possible.

Anyway, using sets as an alternative wasn't really sucessfull. It is a bit 
slower. Turns out the data structure is pretty good.

David Coudert schrieb am Dienstag, 12. Januar 2021 um 09:56:19 UTC+1:

> I have not tried yet, but isn't it due to the fact that some parts are 
> compiled with C and others with C++ ?
>
> Le lundi 11 janvier 2021 à 11:28:47 UTC+1, jonatha...@googlemail.com a 
> écrit :
>
>> Super weird. I think it is a cython bug, but I'm not sure.
>>
>> The problem seems to be that the parent class has the same method. I need 
>> to enforce the correct method
>> by
>>
>> self.foo(u) -> SparseGraph.foo(self, u)
>>
>> This seems to work (compiles and the doctests pass).
>>
>> jonatha...@googlemail.com schrieb am Freitag, 8. Januar 2021 um 16:31:48 
>> UTC+1:
>>
>>> Prepending 
>>> # distutils: language = c++
>>> to src/sage/graphs/base/sparse_graph.pyx makes my compilation crash.
>>>
>>> Does anyone know, how to fix it. I'm on develop and I'm getting the 
>>> following compilation error. Does anyone know how to resolve this? Thank 
>>> you.
>>>
>>> Jonathan
>>>
>>> (I want to see whether cpp set would be a reasonable alternative to our 
>>> private tree implementation.)
>>>
>>> [sagelib-9.3.beta5] [3/3] gcc -Wno-unused-result -Wsign-compare -DNDEBUG 
>>> -g -fwrapv -O3 -Wall -Wno-unused -march=native -O2 -g -march=native -O3 -g 
>>> -fPIC -I./sage/data_structures 
>>> -I/srv/public/kliem/sage/local/lib/python3.8/site-packages/cysignals 
>>> -I./sage/cpython -Isage/data_structures 
>>> -I/srv/public/kliem/sage/build/pkgs/sagelib/src 
>>> -I/srv/public/kliem/sage/local/include/python3.8 
>>> -I/srv/public/kliem/sage/local/lib/python3.8/site-packages/numpy/core/include
>>>  
>>> -Ibuild/cythonized -I/srv/public/kliem/sage/local/include/python3.8 -c 
>>> build/cythonized/sage/graphs/base/sparse_graph.cpp -o 
>>> build/temp.linux-x86_64-3.8/build/cythonized/sage/graphs/base/sparse_graph.o
>>>  
>>> -fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c++11
>>> [sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: 
>>> In function ‘PyObject* 
>>> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
>>>  
>>> int, int, int, 
>>> __pyx_opt_args_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label*)’:
>>> [sagelib-9.3.beta5] 
>>> build/cythonized/sage/graphs/base/sparse_graph.cpp:6543:94: error: cannot 
>>> convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraph*’ to 
>>> ‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*’
>>> [sagelib-9.3.beta5]__pyx_t_6 = 
>>> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(((struct
>>>  
>>> __pyx_obj_4sage_6graphs_4base_7c_graph_CGraph *)__pyx_v_self), __pyx_v_u, 
>>> __pyx_v_v, __pyx_v_l); if (unlikely(__pyx_t_6 == ((int)-1))) __PYX_ERR(0, 
>>> 917, __pyx_L1_error)
>>> [sagelib-9.3.beta5] 
>>>  
>>> ~^
>>> [sagelib-9.3.beta5] 
>>> build/cythonized/sage/graphs/base/sparse_graph.cpp:6280:155: note:   
>>> initializing argument 1 of ‘int 
>>> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
>>>  
>>> int, int, int)’
>>> [sagelib-9.3.beta5]  static int 
>>> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(struct
>>>  
>>> __pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph *__pyx_v_self, int 
>>> __pyx_v_u, int __pyx_v_v, int __pyx_v_l) {
>>> [sagelib-9.3.beta5] 
>>>   
>>> ~^~~~
>>> [sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: 
>>> In function ‘PyObject* 
>>> __pyx_pf_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend_4has_edge(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
>>>  
>>> PyObject*, PyObject*, PyObject*)’:
>>> [sagelib-9.3.beta5] 
>>> build/cythonized/sage/graphs/base/sparse_graph.cpp:10771:105: error: cannot 
>>> convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend*’ to 
>>> ‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*’
>>> [sagelib-9.3.beta5]__pyx_t_2 = 
>>> __pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(((struct
>>>  
>>> __pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend *)__pyx_v_self), 
>>> __pyx_v_u_int, __pyx_v_v_int, __pyx_v_l); if (unlikely(__pyx_t_2 == 
>>> ((int)-1))) __PYX_ERR(0, 1348, __pyx_L1_error)
>>> [sagelib-9.3.beta5] 
>>>   

[sage-devel] Re: How to compile sparse graph backend with c++

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

Super weird. I think it is a cython bug, but I'm not sure.

The problem seems to be that the parent class has the same method. I need 
to enforce the correct method
by

self.foo(u) -> SparseGraph.foo(self, u)

This seems to work (compiles and the doctests pass).

jonatha...@googlemail.com schrieb am Freitag, 8. Januar 2021 um 16:31:48 
UTC+1:

> Prepending 
> # distutils: language = c++
> to src/sage/graphs/base/sparse_graph.pyx makes my compilation crash.
>
> Does anyone know, how to fix it. I'm on develop and I'm getting the 
> following compilation error. Does anyone know how to resolve this? Thank 
> you.
>
> Jonathan
>
> (I want to see whether cpp set would be a reasonable alternative to our 
> private tree implementation.)
>
> [sagelib-9.3.beta5] [3/3] gcc -Wno-unused-result -Wsign-compare -DNDEBUG 
> -g -fwrapv -O3 -Wall -Wno-unused -march=native -O2 -g -march=native -O3 -g 
> -fPIC -I./sage/data_structures 
> -I/srv/public/kliem/sage/local/lib/python3.8/site-packages/cysignals 
> -I./sage/cpython -Isage/data_structures 
> -I/srv/public/kliem/sage/build/pkgs/sagelib/src 
> -I/srv/public/kliem/sage/local/include/python3.8 
> -I/srv/public/kliem/sage/local/lib/python3.8/site-packages/numpy/core/include 
> -Ibuild/cythonized -I/srv/public/kliem/sage/local/include/python3.8 -c 
> build/cythonized/sage/graphs/base/sparse_graph.cpp -o 
> build/temp.linux-x86_64-3.8/build/cythonized/sage/graphs/base/sparse_graph.o 
> -fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c++11
> [sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: In 
> function ‘PyObject* 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
>  
> int, int, int, 
> __pyx_opt_args_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label*)’:
> [sagelib-9.3.beta5] 
> build/cythonized/sage/graphs/base/sparse_graph.cpp:6543:94: error: cannot 
> convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraph*’ to 
> ‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*’
> [sagelib-9.3.beta5]__pyx_t_6 = 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(((struct
>  
> __pyx_obj_4sage_6graphs_4base_7c_graph_CGraph *)__pyx_v_self), __pyx_v_u, 
> __pyx_v_v, __pyx_v_l); if (unlikely(__pyx_t_6 == ((int)-1))) __PYX_ERR(0, 
> 917, __pyx_L1_error)
> [sagelib-9.3.beta5]   
>
> ~^
> [sagelib-9.3.beta5] 
> build/cythonized/sage/graphs/base/sparse_graph.cpp:6280:155: note:   
> initializing argument 1 of ‘int 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
>  
> int, int, int)’
> [sagelib-9.3.beta5]  static int 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(struct
>  
> __pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph *__pyx_v_self, int 
> __pyx_v_u, int __pyx_v_v, int __pyx_v_l) {
> [sagelib-9.3.beta5]   
> 
> ~^~~~
> [sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: In 
> function ‘PyObject* 
> __pyx_pf_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend_4has_edge(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
>  
> PyObject*, PyObject*, PyObject*)’:
> [sagelib-9.3.beta5] 
> build/cythonized/sage/graphs/base/sparse_graph.cpp:10771:105: error: cannot 
> convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend*’ to 
> ‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*’
> [sagelib-9.3.beta5]__pyx_t_2 = 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(((struct
>  
> __pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend *)__pyx_v_self), 
> __pyx_v_u_int, __pyx_v_v_int, __pyx_v_l); if (unlikely(__pyx_t_2 == 
> ((int)-1))) __PYX_ERR(0, 1348, __pyx_L1_error)
> [sagelib-9.3.beta5]   
>   
> ~^~~~
> [sagelib-9.3.beta5] 
> build/cythonized/sage/graphs/base/sparse_graph.cpp:2013:173: note:   
> initializing argument 1 of ‘int 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
>  
> int, int, PyObject*)’
> [sagelib-9.3.beta5]  static int 
> __pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(struct
>  
> __pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend 
> *__pyx_v_self, int __pyx_v_u_int, int __pyx_v_v_int, PyObject *__pyx_v_l); 
> /* proto*/
> [sagelib-9.3

[sage-devel] How to compile sparse graph backend with c++

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

Prepending 
# distutils: language = c++
to src/sage/graphs/base/sparse_graph.pyx makes my compilation crash.

Does anyone know, how to fix it. I'm on develop and I'm getting the 
following compilation error. Does anyone know how to resolve this? Thank 
you.

Jonathan

(I want to see whether cpp set would be a reasonable alternative to our 
private tree implementation.)

[sagelib-9.3.beta5] [3/3] gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O3 -Wall -Wno-unused -march=native -O2 -g -march=native -O3 -g 
-fPIC -I./sage/data_structures 
-I/srv/public/kliem/sage/local/lib/python3.8/site-packages/cysignals 
-I./sage/cpython -Isage/data_structures 
-I/srv/public/kliem/sage/build/pkgs/sagelib/src 
-I/srv/public/kliem/sage/local/include/python3.8 
-I/srv/public/kliem/sage/local/lib/python3.8/site-packages/numpy/core/include 
-Ibuild/cythonized -I/srv/public/kliem/sage/local/include/python3.8 -c 
build/cythonized/sage/graphs/base/sparse_graph.cpp -o 
build/temp.linux-x86_64-3.8/build/cythonized/sage/graphs/base/sparse_graph.o 
-fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c++11
[sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: In 
function ‘PyObject* 
__pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
 
int, int, int, 
__pyx_opt_args_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label*)’:
[sagelib-9.3.beta5] 
build/cythonized/sage/graphs/base/sparse_graph.cpp:6543:94: error: cannot 
convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraph*’ to 
‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*’
[sagelib-9.3.beta5]__pyx_t_6 = 
__pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(((struct
 
__pyx_obj_4sage_6graphs_4base_7c_graph_CGraph *)__pyx_v_self), __pyx_v_u, 
__pyx_v_v, __pyx_v_l); if (unlikely(__pyx_t_6 == ((int)-1))) __PYX_ERR(0, 
917, __pyx_L1_error)
[sagelib-9.3.beta5] 
 
~^
[sagelib-9.3.beta5] 
build/cythonized/sage/graphs/base/sparse_graph.cpp:6280:155: note:   
initializing argument 1 of ‘int 
__pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph*,
 
int, int, int)’
[sagelib-9.3.beta5]  static int 
__pyx_f_4sage_6graphs_4base_12sparse_graph_11SparseGraph_add_arc_label_unsafe(struct
 
__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraph *__pyx_v_self, int 
__pyx_v_u, int __pyx_v_v, int __pyx_v_l) {
[sagelib-9.3.beta5] 
  
~^~~~
[sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: In 
function ‘PyObject* 
__pyx_pf_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend_4has_edge(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
 
PyObject*, PyObject*, PyObject*)’:
[sagelib-9.3.beta5] 
build/cythonized/sage/graphs/base/sparse_graph.cpp:10771:105: error: cannot 
convert ‘__pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend*’ to 
‘__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*’
[sagelib-9.3.beta5]__pyx_t_2 = 
__pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(((struct
 
__pyx_obj_4sage_6graphs_4base_7c_graph_CGraphBackend *)__pyx_v_self), 
__pyx_v_u_int, __pyx_v_v_int, __pyx_v_l); if (unlikely(__pyx_t_2 == 
((int)-1))) __PYX_ERR(0, 1348, __pyx_L1_error)
[sagelib-9.3.beta5] 

~^~~~
[sagelib-9.3.beta5] 
build/cythonized/sage/graphs/base/sparse_graph.cpp:2013:173: note:   
initializing argument 1 of ‘int 
__pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
 
int, int, PyObject*)’
[sagelib-9.3.beta5]  static int 
__pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(struct
 
__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend 
*__pyx_v_self, int __pyx_v_u_int, int __pyx_v_v_int, PyObject *__pyx_v_l); 
/* proto*/
[sagelib-9.3.beta5] 
 
^~~~
[sagelib-9.3.beta5] build/cythonized/sage/graphs/base/sparse_graph.cpp: In 
function ‘int 
__pyx_f_4sage_6graphs_4base_12sparse_graph_18SparseGraphBackend__has_labeled_edge_unsafe(__pyx_obj_4sage_6graphs_4base_12sparse_graph_SparseGraphBackend*,
 
int, int, PyObject*)’:
[sagelib-9.3.beta5] 
build/cythonized/sage/graphs/bas

Re: [sage-devel] Jupyter notebook crashes with multiusers

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

I only ran it once and it solved it permanently, also for the other 
installations of the same version on different computers, but with same 
home-directory. But it appears every user has to call it once.

dim...@gmail.com schrieb am Freitag, 13. November 2020 um 14:08:52 UTC+1:

> On Fri, Nov 13, 2020 at 11:55 AM 'jonatha...@googlemail.com' via
> sage-devel  wrote:
> >
> > Thank you François.
> >
> > I was doubtful that your answer would help, but it did finally after 
> some googling.
> >
> > I had to run
> >
> > import matplotlib.font_manager
> > matplotlib.font_manager._rebuild()
> >
> > At least on the 9.2 install that did help and once my user had those 
> fonts installed in home (believe this is what happened) then it also fixed 
> it on other machines with the same install, but not with the 9.1beta5. Must 
> be a different problem there.
> >
> > I hope my solution also works for the students (maybe the fix can also 
> be applied in the jupyter notebook from the start, which would be super 
> nice).
>
> Calling this every time Sage starts would be a big slowdown, no?
> Perhaps only when ~/.sage/ is created, or something like that.
>
> >
> > Jonathan
> >
> > François Bissey schrieb am Freitag, 13. November 2020 um 10:34:05 UTC+1:
> >>
> >> The top of your crash log is interesting, especially with the context 
> you give it.
> >>
> >> [I 08:54:47.064 NotebookApp] 302 GET 
> /?token=9646f700a842467835ef92b578ebef632e86a326a85e828b (127.0.0.1) 1.53ms
> >> [I 08:54:56.520 NotebookApp] Kernel started: 
> d273c9d9-80cb-45a6-a336-b3562f294b26, name: sagemath
> >> 
> >> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0x8bb8)[0x7faa181e6bb8]
> >> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0x8c58)[0x7faa181e6c58]
> >> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0xc89d)[0x7faa181ea89d]
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7faa1cb3b730]
> >> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7faa1c8107bb]
> >> /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7faa1c7fb535]
> >> /lib/x86_64-linux-gnu/libgcc_s.so.1(+0x3358)[0x7faa1a2f8358]
> >> 
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so(+0x7a62)[0x7fa87edd6a62]
> >> 
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so
> (_ZN7FT2FontC1ER13FT_Open_Args_l+0x22b)[0x7fa87edda23b]
> >> 
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so(+0xd35f)[0x7fa87eddc35f]
> >>
> >>
> >> I’d say it is trying to open a font file to which it has no right.
> >>
> >> François
> >>
> >> > On 13/11/2020, at 9:54 PM, 'jonatha...@googlemail.com' via 
> sage-devel  wrote:
> >> >
> >> > Dear all,
> >> >
> >> > the jupyter notebook crashes when trying to plot unbounded polyhedra, 
> e.g.:
> >> >
> >> > P = Polyhedron(ieqs=[(0,1,0)])
> >> > P.show()
> >> >
> >> > Bounded polyhedra seem to work fine, but also plotting of the face 
> lattice, a FiniteLatticePoset, fails (even for the cube).
> >> >
> >> > The crash appears to be deterministic, but only users other than the 
> owner. (I changed the permissions to 777 inbetween, this does not seem to 
> be the issue.)
> >> >
> >> > This happens on a 9.2. install, but also on a 9.1beta5 install on a 
> different machine (both debian buster).
> >> >
> >> > It does work for prebuilt binaries (9.2 and 9.1).
> >> >
> >> > Here are the system packages picked up: (* are those that also are 
> picked up for the 9.1beta5 with the same problem).
> >> >
> >> > boost-1_66_0: using system package; SPKG will not be installed
> >> > boost_cropped-1.66.0.p0: using system package; SPKG will not be 
> installed
> >> > *bzip2-1.0.6-20150304.p0: using system package; SPKG will not be 
> installed
> >> > *cmake-3.18.2: using system package; SPKG will not be installed
> >> > *curl-7.62.0.p0: using system package; SPKG will not be installed
> >> > *gcc-9.2.0: us

Re: [sage-devel] Jupyter notebook crashes with multiusers

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

Thank you François.

I was doubtful that your answer would help, but it did finally after some 
googling.

I had to run 

import matplotlib.font_manager
matplotlib.font_manager._rebuild()

At least on the 9.2 install that did help and once my user had those fonts 
installed in home (believe this is what happened) then it also fixed it on 
other machines with the same install, but not with the 9.1beta5. Must be a 
different problem there.

I hope my solution also works for the students (maybe the fix can also be 
applied in the jupyter notebook from the start, which would be super nice).

Jonathan

François Bissey schrieb am Freitag, 13. November 2020 um 10:34:05 UTC+1:

> The top of your crash log is interesting, especially with the context you 
> give it.
>
> [I 08:54:47.064 NotebookApp] 302 GET 
> /?token=9646f700a842467835ef92b578ebef632e86a326a85e828b (127.0.0.1) 1.53ms
> [I 08:54:56.520 NotebookApp] Kernel started: 
> d273c9d9-80cb-45a6-a336-b3562f294b26, name: sagemath
> 
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0x8bb8)[0x7faa181e6bb8]
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0x8c58)[0x7faa181e6c58]
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/
> signals.cpython-38-x86_64-linux-gnu.so(+0xc89d)[0x7faa181ea89d]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7faa1cb3b730]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7faa1c8107bb]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7faa1c7fb535]
> /lib/x86_64-linux-gnu/libgcc_s.so.1(+0x3358)[0x7faa1a2f8358]
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so(+0x7a62)[0x7fa87edd6a62]
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so
> (_ZN7FT2FontC1ER13FT_Open_Args_l+0x22b)[0x7fa87edda23b]
> /srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/
> ft2font.cpython-38-x86_64-linux-gnu.so(+0xd35f)[0x7fa87eddc35f]
>
>
> I’d say it is trying to open a font file to which it has no right.
>
> François
>
> > On 13/11/2020, at 9:54 PM, 'jonatha...@googlemail.com' via sage-devel <
> sage-...@googlegroups.com> wrote:
> > 
> > Dear all,
> > 
> > the jupyter notebook crashes when trying to plot unbounded polyhedra, 
> e.g.:
> > 
> > P = Polyhedron(ieqs=[(0,1,0)])
> > P.show()
> > 
> > Bounded polyhedra seem to work fine, but also plotting of the face 
> lattice, a FiniteLatticePoset, fails (even for the cube).
> > 
> > The crash appears to be deterministic, but only users other than the 
> owner. (I changed the permissions to 777 inbetween, this does not seem to 
> be the issue.)
> > 
> > This happens on a 9.2. install, but also on a 9.1beta5 install on a 
> different machine (both debian buster).
> > 
> > It does work for prebuilt binaries (9.2 and 9.1).
> > 
> > Here are the system packages picked up: (* are those that also are 
> picked up for the 9.1beta5 with the same problem).
> > 
> > boost-1_66_0: using system package; SPKG will not be installed
> > boost_cropped-1.66.0.p0: using system package; SPKG will not be installed
> > *bzip2-1.0.6-20150304.p0: using system package; SPKG will not be 
> installed
> > *cmake-3.18.2: using system package; SPKG will not be installed
> > *curl-7.62.0.p0: using system package; SPKG will not be installed
> > *gcc-9.2.0: using system package; SPKG will not be installed
> > gfan-0.6.2.p1: using system package; SPKG will not be installed
> > *gfortran-9.2.0: using system package; SPKG will not be installed
> > *git-2.11.0: using system package; SPKG will not be installed
> > *gmp-6.1.2: using system package; SPKG will not be installed
> > *iconv-1.15: using system package; SPKG will not be installed
> > *mpfr-4.0.1.p0: using system package; SPKG will not be installed
> > *mpir-3.0.0-644faf502c56f97d9accd301965fc57d6ec70868.p0:using system 
> package; SPKG will not be installed
> > *ncurses-6.0.p0: using system package; SPKG will not be installed
> > *ninja_build-1.8.2: using system package; SPKG will not be installed
> > pandoc-none: using system package; SPKG will not be installed
> > *patch-2.7.5: using system package; SPKG will not be installed
> > *pcre-8.40.p2: using system package; SPKG will not be installed
> > *perl_term_readline_gnu-1.35: using system package; SPKG will not be 
> installed
> > *pkgconf-0.9.7.p2: using system package; SPKG

Re: [sage-devel] Obtain a lattice basis of a linear rational subspace

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

Thank you David,

this is exactly what I was looking for. I can even skip the denominator 
part, as I'm starting with a ZZ-matrix.

Jonathan

David Roe schrieb am Mittwoch, 11. November 2020 um 20:18:50 UTC+1:

> I think this should do what you need:
>
> sage: A = matrix([ 
> : (1, 0, 0, 0, 1/10), 
> : (0, 1, 0, 0, 1/10), 
> : (0, 0, 1, 0, 1/10), 
> : (0, 0, 0, 1, 1/10) 
> : ])   
> 
> 
>  
> sage: A = (A * A.denominator()).change_ring(ZZ)   
> 
> 
>   
> sage: A.saturation()   
> 
> 
>  
> [10  0  0  0  1]
> [-1  1  0  0  0]
> [-1  0  1  0  0]
> [-1  0  0  1  0]
>
> David
>
> On Wed, Nov 11, 2020 at 7:19 AM 'jonatha...@googlemail.com' via 
> sage-devel  wrote:
>
>>
>> Given rational vectors and consider their linear span.
>> How do I obtain a basis of the ZZ^d-submodule (a basis for the contained 
>> lattice points).
>>
>> E.g. given
>>
>> [
>> (1, 0, 0, 0, 1/10),
>> (0, 1, 0, 0, 1/10),
>> (0, 0, 1, 0, 1/10),
>> (0, 0, 0, 1, 1/10)
>> ]
>>
>> How do I obtain this or something equivalent:
>>
>> [[1, 0, 0, -1, 0], [0, 1, 0, -1, 0], [0, 0, 1, -1, 0], [0, 0, 0, 10, 1]]
>>
>> I believe this would fix https://trac.sagemath.org/ticket/30891.
>>
>> Thank you,
>>
>> Jonathan
>>
>> -- 
>> 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/5f95c556-694c-4161-8539-bb15acc48a86n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/5f95c556-694c-4161-8539-bb15acc48a86n%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/0b6eda81-26d8-46b0-8ad5-66d6b6eec9f3n%40googlegroups.com.

[sage-devel] Obtain a lattice basis of a linear rational subspace

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

Given rational vectors and consider their linear span.
How do I obtain a basis of the ZZ^d-submodule (a basis for the contained 
lattice points).

E.g. given

[
(1, 0, 0, 0, 1/10),
(0, 1, 0, 0, 1/10),
(0, 0, 1, 0, 1/10),
(0, 0, 0, 1, 1/10)
]

How do I obtain this or something equivalent:

[[1, 0, 0, -1, 0], [0, 1, 0, -1, 0], [0, 0, 1, -1, 0], [0, 0, 0, 10, 1]]

I believe this would fix https://trac.sagemath.org/ticket/30891.

Thank you,

Jonathan

-- 
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/5f95c556-694c-4161-8539-bb15acc48a86n%40googlegroups.com.

Re: [sage-devel] Error installing sage on ubuntu focal

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

Thank you Dima. This worked. (I had to run make distclean yet, but it 
finally resolved the issue.).

dim...@gmail.com schrieb am Montag, 26. Oktober 2020 um 10:35:35 UTC+1:

> looks like a badly broken configuration
>
> please apply the patch from https://trac.sagemath.org/ticket/30795 :
>
> --- a/Makefile
> +++ b/Makefile
> @@ -111,6 +111,7 @@ bootstrap-clean:
> rm -f src/doc/en/installation/*.txt
> rm -rf src/doc/en/reference/spkg/*.rst
> rm -f src/doc/en/reference/repl/*.txt
> + rm -f src/bin/sage-env-config
>
> and run
>
> make bootstrap-clean
> ./bootstrap
> ./configure
> make
>
>
>
>
>
>
> On Mon, Oct 26, 2020 at 9:16 AM 'jonatha...@googlemail.com' via 
> sage-devel  wrote:
>
>> I freshly updated to ubuntu focal and wanted to remake sage and failed. 
>> See attached log.
>>
>> I ran `make dist-clean` and `make clean` and `./configure` various times 
>> and I have no clue why it tries to uninstall gmpy and why it fails.
>>
>> The claim is that it could not find python, but I'm using system python 
>> 3.8.5.
>>
>> Thank you,
>>
>> Jonathan
>>
>> -- 
>> 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/acf2dfc3-eaf6-408c-9d32-169070d177d9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/acf2dfc3-eaf6-408c-9d32-169070d177d9n%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/18af4dfe-2fc0-4c66-af65-36a50e3ef69dn%40googlegroups.com.

[sage-devel] Error installing sage on ubuntu focal

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

I freshly updated to ubuntu focal and wanted to remake sage and failed. See 
attached log.

I ran `make dist-clean` and `make clean` and `./configure` various times 
and I have no clue why it tries to uninstall gmpy and why it fails.

The claim is that it could not find python, but I'm using system python 
3.8.5.

Thank you,

Jonathan

-- 
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/acf2dfc3-eaf6-408c-9d32-169070d177d9n%40googlegroups.com.
Found local metadata for gmpy2-2.1.0b5
Using cached file /home/jonathan/Applications/sage/upstream/gmpy2-2.1.0b5.tar.gz
gmpy2-2.1.0b5

Setting up build directory for gmpy2-2.1.0b5
Finished extraction
No patch files found in ../patches

Host system:
Linux kliem-ThinkPad-L570 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) 

Package 'gmpy2' is currently not installed
No legacy uninstaller found for 'gmpy2'; nothing to do
Installing gmpy2-2.1.0b5
Error: Tried to use Sage's Python which was not yet installed.
If this was called from an spkg-install script for another 
package you should add $(PYTHON) as a dependency in 
build/pkgs//dependencies
Error: could not determine package name

Error uninstalling a previous version of gmpy2-2.1.0b5


real	0m0.020s
user	0m0.022s
sys	0m0.001s

Error installing package gmpy2-2.1.0b5

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the log file
  /home/jonathan/Applications/sage/logs/pkgs/gmpy2-2.1.0b5.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/jonathan/Applications/sage/local/var/tmp/sage/build/gmpy2-2.1.0b5 and type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd '/home/jonathan/Applications/sage/local/var/tmp/sage/build/gmpy2-2.1.0b5' && '/home/jonathan/Applications/sage/sage' --buildsh)
When you are done debugging, you can type "exit" to leave the subshell.

[sage-devel] Trouble creating a branch on trac

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

We are not able to create a branch on 
https://trac.sagemath.org/ticket/30402:

$ git push --set-upstream trac public/30402 perl: warning: Setting locale 
failed. perl: warning: Please check that your locale settings: LANGUAGE = 
(unset), LC_ALL = (unset), LC_PAPER = "de_DE.UTF-8", LC_ADDRESS = 
"de_DE.UTF-8", LC_MONETARY = "de_DE.UTF-8", LC_NUMERIC = "de_DE.UTF-8", 
LC_TELEPHONE = "de_DE.UTF-8", LC_IDENTIFICATION = "de_DE.UTF-8", 
LC_MEASUREMENT = "de_DE.UTF-8", LC_TIME = "de_DE.UTF-8", LC_NAME = 
"de_DE.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your 
system. perl: warning: Falling back to the standard locale ("C"). 
Enumerating objects: 35, done. Counting objects: 100% (35/35), done. Delta 
compression using up to 8 threads Compressing objects: 100% (30/30), done. 
Writing objects: 100% (30/30), 3.57 KiB | 3.57 MiB/s, done. Total 30 (delta 
25), reused 0 (delta 0) remote: error: insufficient permission for adding 
an object to repository database ./objects remote: fatal: failed to write 
object error: remote unpack failed: unpack-objects abnormal exit To 
trac.sagemath.org:sage.git ! [remote rejected] public/30402 -> public/30402 
(unpacker error) error: failed to push some refs to 
'g...@trac.sagemath.org:sage.git'

Btw, with the google update on google groups, I don't know how to format 
code as code anymore. Help is welcome.

-- 
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/11d5a7f7-83a9-465d-9197-952eafb10f3fn%40googlegroups.com.

Re: [sage-devel] Changes to bitset.pxi

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

Thanks. I still can only guess, if people care about large bitsets like 
this.

I can try to make it available with the same syntax and then however likes 
it, can just use it.

Sébastien Labbé schrieb am Dienstag, 22. September 2020 um 16:07:15 UTC+2:

> Am I the only one using larger bitsets?
>>
>
> Doing the following from SAGE_ROOT:
>
> git grep --name-only bitset
>
> shows that modules in sage using bitset are mostly graphs but also 
> matroid, groups, combinat, data_structures, but also crypto, coding, misc 
> and quivers. I don't know if those usage are for larger bitsets or not.
>

-- 
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/aaf7169e-0db6-43b9-88b6-9ae6380c593an%40googlegroups.com.

Re: [sage-devel] Changes to bitset.pxi

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

Actually  roaring performs pretty well, I just used an awful test case. 
Roaring bitmaps has container size 64k, so it performs awful for anything 
far below that. My test case had size 768.

Roaring is interesting however as a bitset implementation for anything 
beyond 64k and seems to perform much better than my private implementation.

I still think the approach with the fuzed types is good. This allows us to 
have a common approach and the application could switch types without 
changing the code.

So I would propose having different bitset implementations that all look 
the same regarding the interface. Something like:

- bitset_t: As before but maybe still using intrinsics (interesting for 
bitsets with up to ~50k bits).
- bitset_sparse_t: Behaving better for sparse bitsets than bitset_t
- bitset_roaring_t: A type exposing the roaring stuff (interesting for 
bitsets from ~50k bits).

I don't know yet, if having bitset_sparse_t is really worth it. But there 
are lots of non-trivial calculations with bitsets of size far less than 50k

One could think of using a different standard library for other cases, but 
I didn't find anything optimized with CPU-specific instructions for this.

Am I the only one using larger bitsets?

Jonathan
jonatha...@googlemail.com schrieb am Freitag, 18. September 2020 um 
11:30:34 UTC+2:

> To sum up this "discussion": There are no general objections to the 
> suggested changes. I should however move away from `pxi` files.
>
> In particular it is fine to overalign bitsets at some point, which will 
> make realloc less efficient (?)!
>
> At some point it would be nice to use some external library for the 
> bitsets. It is not clear yet, which to use for this and if there exists one 
> that fits our needs (not to mention that our needs might differ.)
> But at least I shouldn't burn bridges towards this. Note that some files 
> heavily rely on implementation details by calling attributes directly. IMO 
> one should be able to replace attributes in `bitset_s` by others without 
> breaking any top-level usage.
> If we don't find an external library that fits our needs, we could make 
> one out of bitset.pxi.
>
> IMO the current state of bitsets is fine. With little effort, we can use 
> better CPU-instructions. The largest part of the effort is to merge my own 
> code duplication.
> jonatha...@googlemail.com schrieb am Donnerstag, 17. September 2020 um 
> 22:45:12 UTC+2:
>
>> Ok. I don't think CRoaring serves well for my purpose. I'm getting 
>> multiples of my benchmarks (something like a factor of 10).
>>
>> Things are ok for small instances, but it seems that the bookkeeping 
>> explodes. I thought about it this afternoon and I don't think anything 
>> optimized for memory would work for me. I'm constantly creating and 
>> throwing away bitsets, so it's not worth optimizing for that. If you want 
>> some extra bookkeeping, it must pay of it speed, not in memory.
>>
>> I guess for data science people those bitsets have a different meaning 
>> than for me.
>>
>> jonatha...@googlemail.com schrieb am Donnerstag, 17. September 2020 um 
>> 13:50:00 UTC+2:
>>
>>> CRoaring definitely uses advanced CPU-instructions. It might not be used 
>>> everywhere possible (e.g. I don't see a distinction between AVX and AVX2, 
>>> which means that in one of those cases  something is missing). I got a 
>>> prompt reply regarding my pull request (that the pull request needs work). 
>>> So PyRoaringBitmap is maintained, I guess.  I guess it would be useful, if 
>>> there was only one python wrapper for croaring. I don't know how suitable 
>>> it would be as a base class for our bitset class. First I would like to 
>>> see, if CRoaring is suitable at all. The problem with compiling pyroaring 
>>> for me is that it hides the cython stuff away.
>>>
>>> At the moment I'm replacing bitsets by croaring to see how it behaves. 
>>>
>>> What is extremely annoying is that many parts touch the bitset data 
>>> structure. They need some special method and instead of implemnting it in 
>>> bitset.pxi, they rely on implementation details.
>>> vdelecroix schrieb am Donnerstag, 17. September 2020 um 12:48:52 UTC+2:
>>>
>>>> About 2: the C library CRoaring seems a good match but does not 
>>>> seem to contain any assembler or advanced CPU instructions. Does it? 
>>>> It is hard to figure out how well is implemented and maintained the 
>>>> Python interface PyRoaringBitMap. 
>>>>
>>>> Le 16/09/2020 à 17:18, 'jonatha...@googlemail.com' via sage-devel a 
>&

Re: [sage-devel] Changes to bitset.pxi

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

To sum up this "discussion": There are no general objections to the 
suggested changes. I should however move away from `pxi` files.

In particular it is fine to overalign bitsets at some point, which will 
make realloc less efficient (?)!

At some point it would be nice to use some external library for the 
bitsets. It is not clear yet, which to use for this and if there exists one 
that fits our needs (not to mention that our needs might differ.)
But at least I shouldn't burn bridges towards this. Note that some files 
heavily rely on implementation details by calling attributes directly. IMO 
one should be able to replace attributes in `bitset_s` by others without 
breaking any top-level usage.
If we don't find an external library that fits our needs, we could make one 
out of bitset.pxi.

IMO the current state of bitsets is fine. With little effort, we can use 
better CPU-instructions. The largest part of the effort is to merge my own 
code duplication.
jonatha...@googlemail.com schrieb am Donnerstag, 17. September 2020 um 
22:45:12 UTC+2:

> Ok. I don't think CRoaring serves well for my purpose. I'm getting 
> multiples of my benchmarks (something like a factor of 10).
>
> Things are ok for small instances, but it seems that the bookkeeping 
> explodes. I thought about it this afternoon and I don't think anything 
> optimized for memory would work for me. I'm constantly creating and 
> throwing away bitsets, so it's not worth optimizing for that. If you want 
> some extra bookkeeping, it must pay of it speed, not in memory.
>
> I guess for data science people those bitsets have a different meaning 
> than for me.
>
> jonatha...@googlemail.com schrieb am Donnerstag, 17. September 2020 um 
> 13:50:00 UTC+2:
>
>> CRoaring definitely uses advanced CPU-instructions. It might not be used 
>> everywhere possible (e.g. I don't see a distinction between AVX and AVX2, 
>> which means that in one of those cases  something is missing). I got a 
>> prompt reply regarding my pull request (that the pull request needs work). 
>> So PyRoaringBitmap is maintained, I guess.  I guess it would be useful, if 
>> there was only one python wrapper for croaring. I don't know how suitable 
>> it would be as a base class for our bitset class. First I would like to 
>> see, if CRoaring is suitable at all. The problem with compiling pyroaring 
>> for me is that it hides the cython stuff away.
>>
>> At the moment I'm replacing bitsets by croaring to see how it behaves. 
>>
>> What is extremely annoying is that many parts touch the bitset data 
>> structure. They need some special method and instead of implemnting it in 
>> bitset.pxi, they rely on implementation details.
>> vdelecroix schrieb am Donnerstag, 17. September 2020 um 12:48:52 UTC+2:
>>
>>> About 2: the C library CRoaring seems a good match but does not 
>>> seem to contain any assembler or advanced CPU instructions. Does it? 
>>> It is hard to figure out how well is implemented and maintained the 
>>> Python interface PyRoaringBitMap. 
>>>
>>> Le 16/09/2020 à 17:18, 'jonatha...@googlemail.com' via sage-devel a 
>>> écrit : 
>>> > Dear Vincent, thanks for your reply. 
>>> > 
>>> > To sum up my reply: Should I try to replace bitsets completely by 
>>> > RaoringBitmap and see how it performs? (I need some help with the 
>>> > benchmarking, as I don't know good benchmarks for other use cases.) 
>>> > 
>>> > 
>>> > to 1. Okay. I wasn't aware of that. I just copied the behaviour of 
>>> > bitset.pxi/pyx/pxd. I didn't know that this kind of usage is 
>>> deprecated. 
>>> > 
>>> > to 2. I was looking at roaring bitmaps for a while now 
>>> > https://github.com/Ezibenroc/PyRoaringBitMap 
>>> > They claim it's a simple pip install. So it might be suitable as a 
>>> standard 
>>> > package in sage. 
>>> > 
>>> > It only supports values up to 2**32. But seriously, our current 
>>> > implementation requests 512 MB continous memory in this case. So this 
>>> > performs awful anyway. 
>>> > 
>>> > I was reluctant to use it, because I thought, you cannot avoid 
>>> allocating 
>>> > memory over and over. 
>>> > Only after you and Travis insisted to give up our private 
>>> implemtation, I 
>>> > looked up, if they have all the features I want. 
>>> > In fact the only thing I need is this pull request 
>>> > https://github.com/Ezibenroc/PyRoaringBitMap/pull/59 

Re: [sage-devel] Changes to bitset.pxi

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

Ok. I don't think CRoaring serves well for my purpose. I'm getting 
multiples of my benchmarks (something like a factor of 10).

Things are ok for small instances, but it seems that the bookkeeping 
explodes. I thought about it this afternoon and I don't think anything 
optimized for memory would work for me. I'm constantly creating and 
throwing away bitsets, so it's not worth optimizing for that. If you want 
some extra bookkeeping, it must pay of it speed, not in memory.

I guess for data science people those bitsets have a different meaning than 
for me.

jonatha...@googlemail.com schrieb am Donnerstag, 17. September 2020 um 
13:50:00 UTC+2:

> CRoaring definitely uses advanced CPU-instructions. It might not be used 
> everywhere possible (e.g. I don't see a distinction between AVX and AVX2, 
> which means that in one of those cases  something is missing). I got a 
> prompt reply regarding my pull request (that the pull request needs work). 
> So PyRoaringBitmap is maintained, I guess.  I guess it would be useful, if 
> there was only one python wrapper for croaring. I don't know how suitable 
> it would be as a base class for our bitset class. First I would like to 
> see, if CRoaring is suitable at all. The problem with compiling pyroaring 
> for me is that it hides the cython stuff away.
>
> At the moment I'm replacing bitsets by croaring to see how it behaves. 
>
> What is extremely annoying is that many parts touch the bitset data 
> structure. They need some special method and instead of implemnting it in 
> bitset.pxi, they rely on implementation details.
> vdelecroix schrieb am Donnerstag, 17. September 2020 um 12:48:52 UTC+2:
>
>> About 2: the C library CRoaring seems a good match but does not 
>> seem to contain any assembler or advanced CPU instructions. Does it? 
>> It is hard to figure out how well is implemented and maintained the 
>> Python interface PyRoaringBitMap. 
>>
>> Le 16/09/2020 à 17:18, 'jonatha...@googlemail.com' via sage-devel a 
>> écrit : 
>> > Dear Vincent, thanks for your reply. 
>> > 
>> > To sum up my reply: Should I try to replace bitsets completely by 
>> > RaoringBitmap and see how it performs? (I need some help with the 
>> > benchmarking, as I don't know good benchmarks for other use cases.) 
>> > 
>> > 
>> > to 1. Okay. I wasn't aware of that. I just copied the behaviour of 
>> > bitset.pxi/pyx/pxd. I didn't know that this kind of usage is 
>> deprecated. 
>> > 
>> > to 2. I was looking at roaring bitmaps for a while now 
>> > https://github.com/Ezibenroc/PyRoaringBitMap 
>> > They claim it's a simple pip install. So it might be suitable as a 
>> standard 
>> > package in sage. 
>> > 
>> > It only supports values up to 2**32. But seriously, our current 
>> > implementation requests 512 MB continous memory in this case. So this 
>> > performs awful anyway. 
>> > 
>> > I was reluctant to use it, because I thought, you cannot avoid 
>> allocating 
>> > memory over and over. 
>> > Only after you and Travis insisted to give up our private implemtation, 
>> I 
>> > looked up, if they have all the features I want. 
>> > In fact the only thing I need is this pull request 
>> > https://github.com/Ezibenroc/PyRoaringBitMap/pull/59 for exposing a 
>> > definition. 
>> > (And we can always include this definition ourselves from the header.) 
>> > 
>> > With this to perform `dest = A & B`, I need to copy `A` first and to do 
>> the 
>> > operation inplace then. This is a bit slower than optimal, but avoids 
>> > allocation, if possible. 
>> > So after a couple of initial reallocs there shouldn't be any more 
>> memory 
>> > allocations. 
>> > The optimized subset check is much more important to me, which appears 
>> to 
>> > be at least as good as my implementation. 
>> > 
>> > Depending on what you and other people think of, I can try to make use 
>> of 
>> > RoaringBitMap or any other library that likely performs well. 
>> > https://trac.sagemath.org/ticket/30549 is still a good step towards 
>> this, 
>> > as it makes it a lot easier to just replace `bitset_t` by something 
>> else. 
>> > 
>> > I could try to create a branch that completely rips out bitset.pxi and 
>> > replaces it by a different implementation (with same names as to not 
>> change 
>> > anything else). Then many people could try to come up with benchmarks 
>> in 
>> >

Re: [sage-devel] Changes to bitset.pxi

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

CRoaring definitely uses advanced CPU-instructions. It might not be used 
everywhere possible (e.g. I don't see a distinction between AVX and AVX2, 
which means that in one of those cases  something is missing). I got a 
prompt reply regarding my pull request (that the pull request needs work). 
So PyRoaringBitmap is maintained, I guess.  I guess it would be useful, if 
there was only one python wrapper for croaring. I don't know how suitable 
it would be as a base class for our bitset class. First I would like to 
see, if CRoaring is suitable at all. The problem with compiling pyroaring 
for me is that it hides the cython stuff away.

At the moment I'm replacing bitsets by croaring to see how it behaves. 

What is extremely annoying is that many parts touch the bitset data 
structure. They need some special method and instead of implemnting it in 
bitset.pxi, they rely on implementation details.
vdelecroix schrieb am Donnerstag, 17. September 2020 um 12:48:52 UTC+2:

> About 2: the C library CRoaring seems a good match but does not
> seem to contain any assembler or advanced CPU instructions. Does it?
> It is hard to figure out how well is implemented and maintained the
> Python interface PyRoaringBitMap.
>
> Le 16/09/2020 à 17:18, 'jonatha...@googlemail.com' via sage-devel a 
> écrit :
> > Dear Vincent, thanks for your reply.
> > 
> > To sum up my reply: Should I try to replace bitsets completely by
> > RaoringBitmap and see how it performs? (I need some help with the
> > benchmarking, as I don't know good benchmarks for other use cases.)
> > 
> > 
> > to 1. Okay. I wasn't aware of that. I just copied the behaviour of
> > bitset.pxi/pyx/pxd. I didn't know that this kind of usage is deprecated.
> > 
> > to 2. I was looking at roaring bitmaps for a while now
> > https://github.com/Ezibenroc/PyRoaringBitMap
> > They claim it's a simple pip install. So it might be suitable as a 
> standard
> > package in sage.
> > 
> > It only supports values up to 2**32. But seriously, our current
> > implementation requests 512 MB continous memory in this case. So this
> > performs awful anyway.
> > 
> > I was reluctant to use it, because I thought, you cannot avoid allocating
> > memory over and over.
> > Only after you and Travis insisted to give up our private implemtation, I
> > looked up, if they have all the features I want.
> > In fact the only thing I need is this pull request
> > https://github.com/Ezibenroc/PyRoaringBitMap/pull/59 for exposing a
> > definition.
> > (And we can always include this definition ourselves from the header.)
> > 
> > With this to perform `dest = A & B`, I need to copy `A` first and to do 
> the
> > operation inplace then. This is a bit slower than optimal, but avoids
> > allocation, if possible.
> > So after a couple of initial reallocs there shouldn't be any more memory
> > allocations.
> > The optimized subset check is much more important to me, which appears to
> > be at least as good as my implementation.
> > 
> > Depending on what you and other people think of, I can try to make use of
> > RoaringBitMap or any other library that likely performs well.
> > https://trac.sagemath.org/ticket/30549 is still a good step towards 
> this,
> > as it makes it a lot easier to just replace `bitset_t` by something else.
> > 
> > I could try to create a branch that completely rips out bitset.pxi and
> > replaces it by a different implementation (with same names as to not 
> change
> > anything else). Then many people could try to come up with benchmarks in
> > different parts of sage.
> > 
> > E.g. this might make dense graphs much better in comparison.
> > 
> > to 3. I didn't try many things yet. For my use case the only thing I need
> > (at the moment) is fast intersection and fast subset check. Dense bitsets
> > perform pretty good with that as it is hard to beat 256 bits per CPU-step
> > (whatever this means). I could perform a bit better however,
> > by keeping an array of the significant chunks. I wanted to try different
> > things. This is the main reason for 
> https://trac.sagemath.org/ticket/30549,
> > because my design choice is awful, if you want to change one implemtation
> > detail. With this ticket I can pretty much tell the face-structure that 
> it
> > consists of a roaring bitmap of atoms and coatoms and adapt a few basic
> > functions to the name scheme of that (I also need to take care of freeing
> > the memory, but hey, that's just writing a couple of __dealloc__ 
> methods).
> > 
> > 
> > 
> > v

Re: [sage-devel] Changes to bitset.pxi

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

Dear Vincent, thanks for your reply.

To sum up my reply: Should I try to replace bitsets completely by 
RaoringBitmap and see how it performs? (I need some help with the 
benchmarking, as I don't know good benchmarks for other use cases.)


to 1. Okay. I wasn't aware of that. I just copied the behaviour of 
bitset.pxi/pyx/pxd. I didn't know that this kind of usage is deprecated.

to 2. I was looking at roaring bitmaps for a while now 
https://github.com/Ezibenroc/PyRoaringBitMap
They claim it's a simple pip install. So it might be suitable as a standard 
package in sage.

It only supports values up to 2**32. But seriously, our current 
implementation requests 512 MB continous memory in this case. So this 
performs awful anyway.

I was reluctant to use it, because I thought, you cannot avoid allocating 
memory over and over.
Only after you and Travis insisted to give up our private implemtation, I 
looked up, if they have all the features I want.
In fact the only thing I need is this pull request 
https://github.com/Ezibenroc/PyRoaringBitMap/pull/59 for exposing a 
definition.
(And we can always include this definition ourselves from the header.)

With this to perform `dest = A & B`, I need to copy `A` first and to do the 
operation inplace then. This is a bit slower than optimal, but avoids 
allocation, if possible.
So after a couple of initial reallocs there shouldn't be any more memory 
allocations.
The optimized subset check is much more important to me, which appears to 
be at least as good as my implementation.

Depending on what you and other people think of, I can try to make use of 
RoaringBitMap or any other library that likely performs well.
https://trac.sagemath.org/ticket/30549 is still a good step towards this, 
as it makes it a lot easier to just replace `bitset_t` by something else.

I could try to create a branch that completely rips out bitset.pxi and 
replaces it by a different implementation (with same names as to not change 
anything else). Then many people could try to come up with benchmarks in 
different parts of sage.

E.g. this might make dense graphs much better in comparison.

to 3. I didn't try many things yet. For my use case the only thing I need 
(at the moment) is fast intersection and fast subset check. Dense bitsets 
perform pretty good with that as it is hard to beat 256 bits per CPU-step 
(whatever this means). I could perform a bit better however,
by keeping an array of the significant chunks. I wanted to try different 
things. This is the main reason for https://trac.sagemath.org/ticket/30549, 
because my design choice is awful, if you want to change one implemtation 
detail. With this ticket I can pretty much tell the face-structure that it 
consists of a roaring bitmap of atoms and coatoms and adapt a few basic 
functions to the name scheme of that (I also need to take care of freeing 
the memory, but hey, that's just writing a couple of __dealloc__ methods).



vdelecroix schrieb am Mittwoch, 16. September 2020 um 14:32:28 UTC+2:

> Dear Jonathan,
>
> 0. It would be good to benefit from extended CPU instructions
> for having faster bitsets.
>
> 1. As mentioned in the Cython documentation [1], pxi files are
> not the advised way to deal with Cython code. inline functions
> are perfectly usable when written in pxd headers. See for
> example the header file sage/libs/linbox/conversion.pxd which
> has no pyx implementation since everything is inlined.
>
> 2. Many people care about efficient bitsets and I doubt that
> there is no finely tuned library around. I would rather try
> to find an actively maintained open source project focused
> on bitsets rather making it part of Sage internals.
>
> 3. Depending on the application you have in mind you might
> want to distinguish between sparse and dense bitsets. Sparse
> could be implemented as sets via has tables or binary trees,
> etc
>
> [1] 
>
> https://cython.readthedocs.io/en/latest/src/userguide/language_basics.html?highlight=pxi#cython-file-types
>
> Le 16/09/2020 à 11:59, 'jonatha...@googlemail.com' via sage-devel a 
> écrit :
> > Dear all, I want to redesign the bitset structure of combinatorial
> > polyhedron and move it to `data_structures/bitset.pxi`. This includes 
> some
> > changes to bitset.pxi. Please comment, whether the proposed design 
> changes
> > on the ticket are ok. Mostly they are the following:
> > 
> > 1. Define most of the functions in bitset.pxi for fuzed types.
> > 
> > 2. Move functions that can be optimized by intrinsics to a seperate file.
> > 
> > 3. (Not yet done, but also important.) Optimize some functions in
> > bitset.pxi by intrinsics. This includes an overalignment condition. One
> > disadvantage of overalignment is that it makes realloc much more
> > complicated. Small

[sage-devel] Changes to bitset.pxi

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

Dear all, I want to redesign the bitset structure of combinatorial 
polyhedron and move it to `data_structures/bitset.pxi`. This includes some 
changes to bitset.pxi. Please comment, whether the proposed design changes 
on the ticket are ok. Mostly they are the following:

1. Define most of the functions in bitset.pxi for fuzed types.

2. Move functions that can be optimized by intrinsics to a seperate file.

3. (Not yet done, but also important.) Optimize some functions in 
bitset.pxi by intrinsics. This includes an overalignment condition. One 
disadvantage of overalignment is that it makes realloc much more 
complicated. Small bitsets also need more memory.

4. Indirect typecast of functions in `bitset.pxi` will no longer be 
possible. E.g. you cannot call `bitset_add` with signature `(bitset_t, 
PyObject)`, but `(bitset_t, int)` or `(bitset_t, size_t)` or similar are 
ok. See https://trac.sagemath.org/ticket/30572.

Eventually, this should go into smaller tickets. But until then it would be 
good to know, if the general direction is acceptable or which part is not.

See https://trac.sagemath.org/ticket/30549 for more detail.

-- 
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/06b59c3f-86be-4853-a91c-8a05f42163e5n%40googlegroups.com.