[sage-devel] Re: Code style guidelines

2011-10-27 Thread Keshav Kini
Cleaning up a patch and giving it to the user sounds fine to me. But it's a different matter to create a sage command which automatically doctests and submits patches. That's going too far, IMO. It's nice to allow developers to stay away from the details as much as possible, which lowers the bar

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread William Stein
On Thu, Oct 27, 2011 at 12:57 PM, Volker Braun wrote: > On Thursday, October 27, 2011 1:38:34 PM UTC-4, Martin Albrecht wrote: >> >> Sure, but it's still worrisome that a computation is slower in libSingular >> than in Singular. > > Just to reiterate in case I wasn't clear, as long as the "computa

[sage-devel] Re: Code style guidelines

2011-10-27 Thread leif
On 28 Okt., 01:57, Robert Bradshaw wrote: > On Thu, Oct 27, 2011 at 3:25 PM, Robert Bradshaw > > Ideally, when you upload a patch it would do a bunch of checks and > > present to you a "fixed" file with the option of downloading it or > > replacing the original file right there. Obviously. Any id

Re: [sage-devel] Re: Code style guidelines

2011-10-27 Thread Robert Bradshaw
On Thu, Oct 27, 2011 at 3:25 PM, Robert Bradshaw wrote: > On Tue, Oct 25, 2011 at 11:44 AM, William Stein wrote: >> On Tue, Oct 25, 2011 at 11:06 AM, leif wrote: >>> On 25 Okt., 12:04, Jeroen Demeyer wrote: On 2011-10-25 09:51, Dan Drake wrote: > I think that would be a good idea, alt

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
Okay, a patch is up. See If people have objections to the whole plan, please keep them here. If you have issues with the particular implementation, let's discuss that on the ticket. -- John -- To post to this group, send an email to sage-

Re: [sage-devel] Re: Code style guidelines

2011-10-27 Thread Robert Bradshaw
On Tue, Oct 25, 2011 at 11:44 AM, William Stein wrote: > On Tue, Oct 25, 2011 at 11:06 AM, leif wrote: >> On 25 Okt., 12:04, Jeroen Demeyer wrote: >>> On 2011-10-25 09:51, Dan Drake wrote: >>> > I think that would be a good idea, although if you're just running that >>> > through sed, the exact

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread leif
On 27 Okt., 23:15, leif wrote: > On 27 Okt., 22:17, John H Palmieri wrote: > > > Anyway, in my > > preliminary patches, I'm adding a warning about using "make -j2" on > > machines with one processor. > > Until it died :( I used to build Sage on a single-core Pentium4 (very > similar to Cicero, bu

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
On Thursday, October 27, 2011 2:15:34 PM UTC-7, leif wrote: > > P.S.: Incidentally I also posted about parallel make on sage-support > today: > > http://groups.google.com/group/sage-support/msg/a17f6e561583e1a5 > > http://groups.google.com/group/sage-support/msg/f4d0c2e3815f1157 > Yes, henc

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread leif
On 27 Okt., 22:17, John H Palmieri wrote: > Anyway, in my > preliminary patches, I'm adding a warning about using "make -j2" on > machines with one processor. Until it died :( I used to build Sage on a single-core Pentium4 (very similar to Cicero, but with only 768MB RAM) with MAKE="make -j3", wh

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread leif
On 27 Okt., 21:28, kcrisman wrote: > As it turns out, trying the "wrong" behavior (make -j2 with parallel > spkgs) on one of my one processor machines does lead to unusual build > failures which seem to have to do with waiting for jobs.  And then it > finishes the next spkg before actually stoppin

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread leif
On 27 Okt., 20:43, Jeroen Demeyer wrote: > Even better solution: make the SAGE_PARALLEL_SPKG_BUILD="yes" behaviour > the default and *remove the environment variabele*. +1 > There is absolutely > no reason why anybody would need to set SAGE_PARALLEL_SPKG_BUILD="no". > Simply set MAKE="make -j1"

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
On Thursday, October 27, 2011 12:28:00 PM UTC-7, kcrisman wrote: > > > As it turns out, trying the "wrong" behavior (make -j2 with parallel > spkgs) on one of my one processor machines does lead to unusual build > failures which seem to have to do with waiting for jobs. And then it > finishes t

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread kcrisman
On Oct 27, 2:52 pm, John H Palmieri wrote: > On Thursday, October 27, 2011 11:43:56 AM UTC-7, Jeroen Demeyer wrote: > > > On 2011-10-27 19:14, John H Palmieri wrote: > > > The option to build spkg's in Sage in parallel has been available for > > > quite a while now, but it has to be enabled by s

Re: [sage-devel] build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
On Thursday, October 27, 2011 11:43:56 AM UTC-7, Jeroen Demeyer wrote: > > On 2011-10-27 19:14, John H Palmieri wrote: > > The option to build spkg's in Sage in parallel has been available for > > quite a while now, but it has to be enabled by setting the shell > > variable SAGE_PARALLEL_SPKG_BUI

Re: [sage-devel] build spkg's in parallel by default?

2011-10-27 Thread Jeroen Demeyer
On 2011-10-27 19:14, John H Palmieri wrote: > The option to build spkg's in Sage in parallel has been available for > quite a while now, but it has to be enabled by setting the shell > variable SAGE_PARALLEL_SPKG_BUILD equal to "yes". Should we change the > default, building in parallel unless thi

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
On Thursday, October 27, 2011 10:29:37 AM UTC-7, kcrisman wrote: > > > > On Oct 27, 1:14 pm, John H Palmieri wrote: > > The option to build spkg's in Sage in parallel has been available for > quite > > a while now, but it has to be enabled by setting the shell variable > > SAGE_PARALLEL_SPKG

Re: [sage-devel] Re: Code style guidelines

2011-10-27 Thread Ivan Andrus
On Oct 27, 2011, at 2:38 AM, Keshav Kini wrote: > Would it be possible to configure emacs to pretend there is space there, or > something like that? I imagine it should be easy to add something to ~/.emacs > which upon loading a .py or .pyx file searches for blocks of empty lines, > checks previ

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Volker Braun
On Thursday, October 27, 2011 1:38:34 PM UTC-4, Martin Albrecht wrote: > > Sure, but it's still worrisome that a computation is slower in libSingular > than in Singular. > Just to reiterate in case I wasn't clear, as long as the "computation in Singular" just references a singular variable as out

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Martin Albrecht
On Thursday 27 October 2011, Volker Braun wrote: > Your test2() function leave the polynomial data inside Singular. Of course > its faster to not pull the (pretty big) coefficients out of Singular. > Wouldn't the following be a much better comparison? > > def test3(x,y,z): > x = singular(x) >

[sage-devel] Re: build spkg's in parallel by default?

2011-10-27 Thread kcrisman
On Oct 27, 1:14 pm, John H Palmieri wrote: > The option to build spkg's in Sage in parallel has been available for quite > a while now, but it has to be enabled by setting the shell variable > SAGE_PARALLEL_SPKG_BUILD equal to "yes".  Should we change the default, > building in parallel unless t

[sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Volker Braun
Your test2() function leave the polynomial data inside Singular. Of course its faster to not pull the (pretty big) coefficients out of Singular. Wouldn't the following be a much better comparison? def test3(x,y,z): x = singular(x) y = singular(y) z = singular(z) for i in rang

[sage-devel] build spkg's in parallel by default?

2011-10-27 Thread John H Palmieri
The option to build spkg's in Sage in parallel has been available for quite a while now, but it has to be enabled by setting the shell variable SAGE_PARALLEL_SPKG_BUILD equal to "yes". Should we change the default, building in parallel unless this variable is explicitly set to "no" (or "n")?

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Martin Albrecht
On Thursday 27 October 2011, Volker Braun wrote: > I don't understand how thread safety in libSingular is an issue, Sage runs > in a single thread after all. > I thought the explanation is that Singular uses a slightly wonky > optimization for small integer coefficients, roughly > storing it in

[sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Volker Braun
I don't understand how thread safety in libSingular is an issue, Sage runs in a single thread after all. I thought the explanation is that Singular uses a slightly wonky optimization for small integer coefficients, roughly storing it in the place that would usually hold the pointer to the GMP s

[sage-devel] Re: Using sagetex for large blocks of code

2011-10-27 Thread Andrey Novoseltsev
Hi Javier, One of the main points of sagecommandline is to create examples with *automatic* output, similar to doctests in modules. This is also the reason why stuff without "sage:" or "..." in the beginning does not show up: it is interpreted as output that should NOT be inserted into the final r

[sage-devel] Re: Code style guidelines

2011-10-27 Thread kcrisman
I won't repeat Jason's email above, but +1 to everything he said. On Oct 27, 2:18 am, Simon King wrote: > Hi Florent, > > On 26 Okt., 17:58, Florent Hivert wrote: > > > If you want some example of what has been painful in the past, here they > > are. Note: I don't intend any offense against the

[sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Simon King
Hi Martin, hi Burcin, On 27 Okt., 12:38, Martin Albrecht wrote: > > Isn't Singular using a fairly uncommon memory management? If I > > remember correctly what Hans presented at the last Singular Sage Days > > in Kaiserslautern, their memory management is a lot faster for what > > Singular needs.

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Martin Albrecht
On Thursday 27 October 2011, Simon King wrote: > Hi Martin, > > On 27 Okt., 11:39, Martin Albrecht > > wrote: > > On Thursday 27 October 2011, Simon King wrote: > > > Is that something to worry about? > > > > Yes! > > Good. I created trac ticket #11957. > > > Hence my guess: > > we are using

Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Burcin Erocal
Hi Simon, On Thu, 27 Oct 2011 03:11:42 -0700 (PDT) Simon King wrote: > On 27 Okt., 11:39, Martin Albrecht > wrote: > > On Thursday 27 October 2011, Simon King wrote: > > > Is that something to worry about? > > > > Yes! > > Good. I created trac ticket #11957. > > > Hence my guess: > > we are u

[sage-devel] Re: libSingular much slower than Singular via pexpect??

2011-10-27 Thread Simon King
Hi Martin, On 27 Okt., 11:39, Martin Albrecht wrote: > On Thursday 27 October 2011, Simon King wrote: > > Is that something to worry about? > > Yes! Good. I created trac ticket #11957. > Hence my guess: > we are using different memory allocation functions for GMP and these functions > might be

Re: [sage-devel] libSingular much slower than Singular via pexpect??

2011-10-27 Thread Martin Albrecht
On Thursday 27 October 2011, Simon King wrote: > Hi! > > I just found the following: > sage: P. = QQ[] > sage: def test1(x,y,z): > : for i in range(100): > : p = (x+y+z)^i > : > sage: def test2(x,y,z): > : x = singular(x) > : y = singular(y)

[sage-devel] libSingular much slower than Singular via pexpect??

2011-10-27 Thread Simon King
Hi! I just found the following: sage: P. = QQ[] sage: def test1(x,y,z): : for i in range(100): : p = (x+y+z)^i : sage: def test2(x,y,z): : x = singular(x) : y = singular(y) : z = singular(z) : for i in range(100): :