2012/8/14 Robert Bradshaw :
> Volkers point is right on: the patchbot is purely advisory.
Then I suggest a small change to the patchbot.
iirc, the patchbot (and its blob on trac) shows a huge "plugin failed"
when there are trailing whitespaces on changed/added lines, without
saying anything about
Can somebody please review this autotools package (meant only for spkg
developers), such that it can be put amongst the *experimental packages*?
On 2012-08-10 16:08, Jeroen Demeyer wrote:
> See http://trac.sagemath.org/sage_trac/ticket/13357
--
--
To post to this group, send an email to sage-de
On 2012-08-14 02:07, Volker Braun wrote:
> In any case, here is another data point. Interestingly, os.path.join is
> about as fast as posix.lstat. I'd take that as another piece of evidence
> that filesystem caches are incredibly well optimized.
What measure of "time" is this using? Unless it's wa
It looks there is quite some work on this:
http://trac.sagemath.org/sage_trac/ticket/12215
http://trac.sagemath.org/sage_trac/ticket/11521
http://trac.sagemath.org/sage_trac/ticket/715
http://trac.sagemath.org/sage_trac/ticket/12313
Let me know if there is something I can help with to move this a
Hi. I the lead developer of SymPy, one of the packages included with Sage. I
was wondering if someone here could help me debug a segfault that comes from
importing the dev version of SymPy in Sage:
$sage -python
Python 2.7.3 (default, Jul 27 2012, 04:22:16)
[GCC 4.6.3] on darwin
Type "help",
If you run the following code, you'll see your memory usage steadily
go up:
alg='default'
n,m=10,22
B=20
while True:
_=matrix(QQ,n,m,[randint(-B,B)/randint(1,B) for i in
range(n*m)]).echelon_form(alg)
The same happens with alg='padic' and alg='multimodular' (I think the
latter amounts to the
Doctests that ensure that certain modules are not imported upon startup are
also fine with me.
In any case, here is another data point. Interestingly, os.path.join is
about as fast as posix.lstat. I'd take that as another piece of evidence
that filesystem caches are incredibly well optimized.
-1 to removing conversions, for sure. Coercions and the symbolic rings
are less clear, there's good arguments on both sides. I do think this
is a big enough change to not just be decided on a trac ticket.
On Sun, Aug 12, 2012 at 2:28 PM, Andrey Novoseltsev wrote:
> I want to point out that the ti
On Mon, Aug 13, 2012 at 8:51 AM, Jeroen Demeyer wrote:
> On 2012-08-13 17:29, Volker Braun wrote:
>> Counting the number of open() is related to startup speed, but it does
>> not account for the majority of the startup time unless you run on NFS.
> True, I just tested a fast disk and there, the *s
On Mon, Aug 13, 2012 at 9:24 AM, Volker Braun wrote:
> On Monday, August 13, 2012 11:36:33 AM UTC-4, Robert Bradshaw wrote:
>>
>> Shouldn't everything needed by the sage notebook (already) be in
>> sagenb.* anyways?
>
>
> Yes, but thats not what I mean. For example, right now we import
> sage.grap
On Mon, Aug 13, 2012 at 2:20 AM, Keshav Kini wrote:
> Andrew Mathas writes:
>> I have some patches on trac and the patchbot is failing them with
>> white space errors with comments like
>>
>>
>> Trailing whitespace inserted on 73 non-empty lines.
>>
>>
>> I used to have my editor set to automatic
On 08/13/2012 06:09 PM, Harald Schilly wrote:
On Monday, August 13, 2012 10:33:27 AM UTC+2, Andrew Mathas wrote:
Trailing whitespace ...
The patchbot probably checks for trailing whitespace on all the lines
starting with '+' in the patch. So, it will catch all the lines which
have bee
On Monday, August 13, 2012 11:36:33 AM UTC-4, Robert Bradshaw wrote:
>
> Shouldn't everything needed by the sage notebook (already) be in
> sagenb.* anyways?
Yes, but thats not what I mean. For example, right now we import
sage.graphs.graph_editor upon startup. And the graph editor imports the
On 2012-08-13 17:29, Volker Braun wrote:
> Counting the number of open() is related to startup speed, but it does
> not account for the majority of the startup time unless you run on NFS.
True, I just tested a fast disk and there, the *system* time was around
25% of the *wall* time. So, it's not t
> You are mostly counting the length of sys.path, which
> is good to keep short but then you can just check len(sys.path).
I am also counting the number of successful imports, which should also
be kept small. Maybe we could check the number of successful open()
calls, in addition to len(sys.path)?
Shouldn't everything needed by the sage notebook (already) be in
sagenb.* anyways? This should be fairly explicit, no need to move
things around further. +1 to only importing notebook() (which lazily
loads what is needed on being called).
On Mon, Aug 13, 2012 at 6:32 AM, Volker Braun wrote:
> I w
On Monday, August 13, 2012 10:04:26 AM UTC-4, Keshav Kini wrote:
>
> We already maintain a Python installation separate from the system
> Python. Now you want to keep some of our python packages in yet another
> location? Is that really necessary?
Its not really necessary, but it'll force the s
Counting the number of open() is related to startup speed, but it does not
account for the majority of the startup time unless you run on NFS. Its
also important that modules don't do computations on import.,
see sage/misc/latex_macros.py for an example of how not to do things (and
flask.babel
I am running the following command from various versions of Sage:
./sage -sh -c 'IPYTHONDIR="$DOT_SAGE/ipython" IPYTHONRC=ipythonrc strace
2>&1 >/dev/null python "$SAGE_LOCAL/bin/sage-ipython" -i' http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
On 2012-08-13 16:37, Simon King wrote:
> Has that changed?
It has changed only in the positive direction. It is possible to run
./sage -i /path/too/package.spkg right after extracting the Sage
tarball. This wasn't possible before sage-5.0.
But downloading a remote package requires that Python is
The function build_flow_graph (called by the flow function of
sage/graphs/generic_graph.py) contains a "g.set_edge_label(l)" instead of
"g.set_edge_label(sp[i],sp[i+1],l)", where l is a number.
This patch should be easy to reviewed.
Thanks for your help,
David.
--
--
To post to this
On 2012-08-13, Simon King wrote:
> On 2012-08-13, Jeroen Demeyer wrote:
>> On 2012-08-13 15:34, Simon King wrote:
>>> What went wrong?
>> You need to install the OpenSSL library with its development headers.
>
> Too bad. How to do so, if one is not root? Is there an spkg?
Yes, there is. I am try
On 2012-08-13, Jeroen Demeyer wrote:
> On 2012-08-13 15:34, Simon King wrote:
>> What went wrong?
> You need to install the OpenSSL library with its development headers.
Too bad. How to do so, if one is not root? Is there an spkg?
Cheers,
Simon
--
--
To post to this group, send an email to s
On 2012-08-13 15:34, Simon King wrote:
> What went wrong?
You need to install the OpenSSL library with its development headers.
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For
Volker Braun writes:
> I would propose that we go one step further:
>
> * Install all notebook dependencies into a separate directory
> * only import notebook() from the sagenb on startup
> * The notebook() function adds notebook dependencies to sys.path
> before importing its prerequisites
Hi Jeroen,
Am Dienstag, 31. Juli 2012 08:29:32 UTC+2 schrieb Jeroen Demeyer:
>
> Sage 5.2 was released on 25 July 2012.
>
I get an error when building it from sources with four parallel threads.
Setting:
$ uname -a
Linux mpc622 2.6.34.linuxpool #0 SMP PREEMPT Wed May 19 16:32:19 CEST 2010
x86_
I would propose that we go one step further:
* Install all notebook dependencies into a separate directory
* only import notebook() from the sagenb on startup
* The notebook() function adds notebook dependencies to sys.path before
importing its prerequisites
This would force the notebook t
Hi Timo,
On Sun, 5 Aug 2012 10:12:41 -0700 (PDT)
Timo Kluck wrote:
> I think that the distinction between
>
> def f(x):
> return x^2
>
> and
>
> f(x) = x^2
>
> is a common source of confusion, and everyone will run into it when
> trying to define piecewise functions. It would be possible
We don't have an official policy, so this is what I think. The Sage library
has trailing whitespace all over the place, and trying to enforce any kind
of whitespace policy without automation through commit hooks just combines
the disadvantages.
* The whitespace plugin in the patchbot is pure
On Monday, August 13, 2012 10:33:27 AM UTC+2, Andrew Mathas wrote:
>
> Trailing whitespace ...
>
>
Hi, I don't know what it is actually doing, but from my experience, it
helped a lot to tweak my vim a bit. Now, it prints a small centered dot for
each space (that is not "ok"), and an arrow to th
On 2012-08-13 11:20, Keshav Kini wrote:
> The patchbot is complaining about trailing whitespace that *you* added.
That's not completely true. I think it also complains about whitespace
on lines which were edited but where the trailing whitespace wasn't removed.
--
--
To post to this group, send
Andrew Mathas writes:
> I have some patches on trac and the patchbot is failing them with
> white space errors with comments like
>
>
> Trailing whitespace inserted on 73 non-empty lines.
>
>
> I used to have my editor set to automatically kill off all trailing
> white space but I found that this
On 13/08/2012 06:50, David Roe wrote:
Thanks for the pointer to that ticket, which explains the change in the the
"is_unit()" behavior.
Why should the inverse of "four" succeed when the result is not in K?
sage: four^-1 in K
False
The order K is analogous to the ring of integers inside QQ. So
I don't think there is an official policy, but at the very least you
should not introduce new trailing whitespace.
Certainly don't go to the other extreme: don't simply remove all
trailing whitespace everywhere, because that does indeed lead to patch
conflicts.
My recommendation is: remove traili
I have some patches on trac and the patchbot is failing them with white
space errors with comments like
Trailing whitespace inserted on 73 non-empty lines.
I used to have my editor set to automatically kill off all trailing white
space but I found that this led to constant conflicts when mergin
35 matches
Mail list logo
