Re: [sage-devel] Overcommitted memory and error handling

I think it crashes for a different reason: there are some unchecked allocations in realloc(). This has nothing to do with overcommit. -- 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

[sage-devel] Re: git-trac push

no idea why, but now it works (I deleted the branch and checked it out again :-) Martin Am Dienstag, 18. Oktober 2016 08:56:21 UTC+2 schrieb Martin R: > > git-trac doesn't like me - what have I done wrong? > > martin@Martin-Laptop:~/sage-develop$ git-trac push 21594 > Pushing to Trac #21594...

Re: [sage-devel] Overcommitted memory and error handling

On 2016-10-17 17:40, Jori Mäntysalo wrote: Setting (as root) the value of /proc/sys/vm/overcommit_memory will not help Are you sure? With vm.overcommit_memory set to "2", the error should happen during allocation. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] NTL 1v0.1.0

Are you sure you need an account on the trac to report it? The http version at least seems to accept essentially anonymous input. Alternatively, I guess JP's suggestion should work fine. It might be even better if some discussion is needed about what interface NTL should provide. Bill. On

Re: [sage-devel] git-trac push

On 2016-10-18 08:56, 'Martin R' via sage-devel wrote: > martin@Martin-Laptop:~/sage-develop$ git-trac push 21594 > Pushing to Trac #21594... > Guessed remote branch: u/mantepse/growth_diagrams > Traceback (most recent call last): > ... > raise GitError(result) > git_trac.git_error.GitError It

Re: [sage-devel] NTL 1v0.1.0

On Tuesday, October 18, 2016 at 8:52:23 AM UTC+2, François wrote: > > > > On 18/10/2016, at 19:42, Jean-Pierre Flori > wrote: > > > > > > > > On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote: > > Good! But it should be determined if there is an

Re: [sage-devel] Overcommitted memory and error handling

On Tue, 18 Oct 2016, Jeroen Demeyer wrote: Setting (as root) the value of /proc/sys/vm/overcommit_memory will not help Are you sure? With vm.overcommit_memory set to "2", the error should happen during allocation. Yes, I tested that too. Just add print-function before and after the line I

Re: [sage-devel] NTL 1v0.1.0

I probably assumed too much. But it felt wrong to say “there is a problem building ntl but ntl upstream is happy to talk to you about your needs” (and doing that anonymously feels like a prank call). I prefer the mailing list option and I am actually subscribed. Still have to get to it. François

Re: [sage-devel] Overcommitted memory and error handling

On 2016-10-17 17:40, Jori Mäntysalo wrote: Is it even theoretically possible to handle something like Graph(10^10)? That will crash at the line memset(self.vertices, NULL, nverts * self.hash_length * sizeof(SparseGraphBTNode *)) Are you *sure* that it crashes at the above line? It seems to

[sage-devel] developer for SageMath and third party softwares

Dear all, This is an announcement for an engineer position at Bordeaux (France). It is a position for 1 to 3 years inside the OpenDreamKit project. See the details at [1]. Best, Vincent [1] http://opendreamkit.org/2016/06/28/developer-position2-bordeaux/ -- You received this message because

Re: [sage-devel] Conversion bug: field to vector space

It is indeed a problem! The interfaces should be compatible. Adding a _vector_ method to the GF(p) elements should be enough. 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

Re: [sage-devel] git-trac push

On Tuesday, October 18, 2016 at 10:37:24 AM UTC+2, Daniel Krenn wrote: > > It would be nice, if the actual git errors were shown by git-trac. Is > this (easily) possible? > Doing "git-trac --log=DEBUG" probably works. Of course the ideal solution would be for main to catch errors and present

[sage-devel] Conversion bug: field to vector space

Hi, I think this is a bug: sage: F.=GF(9) sage: V=F.vector_space() sage: V(a) (0, 1) sage: G.=GF(3) sage: W=G.vector_space() sage: W(b) ... TypeError: can't initialize vector from nonzero non-list The cause is sage: a._vector_() (0, 1) sage: b._vector_() ... AttributeError:

[sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

Hi, we're trying to package Sage 7.4 for Debian and are running into a difficulty. This will affect not just Debian, but all buildsystems / distributions that want to (1) run tests at build-time, before installation and (2) don't allow extra installations or network access *during* the build of

Re: [sage-devel] Overcommitted memory and error handling

On 2016-10-18 12:13, Jeroen Demeyer wrote: I think it crashes for a different reason: there are some unchecked allocations in realloc(). This has nothing to do with overcommit. Fixed at https://trac.sagemath.org/ticket/21720 -- You received this message because you are subscribed to the

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

Here is another solution, but it involves upstream fpylll. I'm not sure how realistic it is, because of the auto-generated config.pxi: (3) Ship the Cython-generated files with fpylll. This moves the dependency on Sage from build-time to packaging-time. -- You received this message because

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

On 2016-10-18 17:52, Ximin Luo wrote: One straw-man way to resolve this is to move the tests into a separate Debian package "sagemath-distribution". I still think that this is the real solution, also because it mimics what Sage does: within the Sage-the-distribution build system,

Re: [sage-devel] Conversion bug: field to vector space

> It is indeed a problem! The interfaces should be compatible. Adding a > _vector_ method to the GF(p) elements should be enough. > > Also, from a quick check, all of the other implementations of finite fields provide a _vector_() method as well. So I think Vincent's fix is the way to go.

Re: [sage-devel] Embedding graphs on the projective plane

Dear Joshua, Welcome to Sage development! It is good idea to ask for a trac account for the following reasons * create a ticket on trac.sagemath.org that makes your project public * upload your code changes on the git server and make your code publicly available for discussion Did you already

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

Jeroen Demeyer: > On 2016-10-18 17:52, Ximin Luo wrote: >> One straw-man way to resolve this is to move the tests into a separate >> Debian package "sagemath-distribution". > > I still think that this is the real solution, also because it mimics what > Sage does: within the

Re: [sage-devel] Conversion bug: field to vector space

Ok. Now this is https://trac.sagemath.org/ticket/21723#ticket -- 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 post to

[sage-devel] Embedding graphs on the projective plane

Hi all, Sage rookie here. I've been working on writing functions to test whether a graph can be embedded on the projective plane, as in Myrvold and Roth's paper (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.1102=rep1=pdf). I'm still working out some bugs, and working on

Re: [sage-devel] Embedding graphs on the projective plane

> > Hello Vincent, Thank you! I did review the developer guide; the admonition there to check here for interest in a topic before requesting a trac account is what brought me here. I'll go ask for a trac account. Best, Joshua -- You received this message because you are subscribed to the

Re: [sage-devel] NTL 1v0.1.0

On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote: > > Good! But it should be determined if there is an interface that ntl could > provide so that this problem goes away I think that what you suggested: extracting gmp bignums from NTL's ZZ (and the other way around) would

Re: [sage-devel] NTL 1v0.1.0

> On 18/10/2016, at 19:42, Jean-Pierre Flori wrote: > > > > On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote: > Good! But it should be determined if there is an interface that ntl could > provide so that this problem goes away > > I think that what you

[sage-devel] git-trac push

git-trac doesn't like me - what have I done wrong? martin@Martin-Laptop:~/sage-develop$ git-trac push 21594 Pushing to Trac #21594... Guessed remote branch: u/mantepse/growth_diagrams Traceback (most recent call last): File "/home/martin/git-trac-command/bin/git-trac", line 18, in

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

Hi there, Ximin Luo writes: > We can do "pre-install tests" with Sage 7.3, by doing a "dummy > install" using Sage's Makefiles, running the tests here, then > installing them to the "real location". (This requires some patching, > but we have achieved this already and it works.) However with Sage

Re: [sage-devel] NTL 1v0.1.0

And posted to libsingular-devel: https://groups.google.com/d/msg/libsingular-devel/u8-aHNMqf44/GNVvSYGEAQAJ > On 18/10/2016, at 21:39, Jean-Pierre Flori wrote: > > > > On Tuesday, October 18, 2016 at 8:52:23 AM UTC+2, François wrote: > > > On 18/10/2016, at 19:42,

Re: [sage-devel] NTL 1v0.1.0

I will anyway add routines to get and set the limbs of a ZZ. -- 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 post to