[sage-devel] Re: Preferred way to patch the Mac app?

On Jan 4, 10:19 pm, Nicholas Kirchner wrote: > The instructions at "Walking Through the Development Process" do not seem > quite suitable for patching the app, which resides in > SAGE_ROOT/devel/ext-main/sage/ext/mac-app.  What's the preferred way to > create a patch for a Trac ticket on the Mac a

[sage-devel] Preferred way to patch the Mac app?

I've been having the problem that the Mac app won't stop the sage server when I ask it to. I know the problem: the Mac app source code references .sage/sage_notebook.sagenb/twistd.pid, whereas it should reference sagenb.pid. The instructions at "Walking Through the Development Process" do not

[sage-devel] Re: Attribute errors with polynomials

On Jan 4, 8:17 pm, Dima Pasechnik wrote: > > The abs() method is defined in sage.structure.element.RingElement. If > > but why? not all rings have any meaningful abs().. > > > that method makes sense for your specific class of ring elements, > > implement a method __abs__. Perhaps more importantl

[sage-devel] Re: Attribute errors with polynomials

On 2013-01-04, Simon King wrote: > Hi Nathann, > > On 2013-01-04, Nathann Cohen wrote: >> --e89a8f6467594d8d3f04d276c2d8 >> Content-Type: text/plain; charset=ISO-8859-1 >> sage: p >> x^3 - 3*x >> sage: p.abs() >> ... >> AttributeError: >> 'sage.rings.polynomial.polynomial_integer_dense_flint.Poly

Re: [sage-devel] How to make Sage worksheets publically available

On Fri, Jan 4, 2013 at 2:50 PM, Dan Drake wrote: > On Fri, 04 Jan 2013 at 11:30AM +, John Cremona wrote: > > Have others found a good solution to this? > > I don't have a good solution (yet), but for some time I've wanted to > make a nice way to attach a worksheet to a PDF file -- and get the

Re: [sage-devel] Re: Attribute errors with polynomials

tab-completion has been fun for me from time to time, as John Cremona points out. thinking of how java interfaces & multiple inheritance work: wouldn't it be possible to have an interface orabstract class that defines an abstract function abs, along with associated functions that require an abs

[sage-devel] Re: How to make Sage worksheets publically available

On Jan 4, 4:08 am, John Cremona wrote: > A disadvantage is that one loses all the beauty of a workable > worksheet which can be instructive to look at even if one does not > want to run the code. Perhaps old-fashioned, but since a notebook is ultimately rendered as an HTML page, you can your your

Re: [sage-devel] How to make Sage worksheets publically available

On Fri, 04 Jan 2013 at 11:30AM +, John Cremona wrote: > Have others found a good solution to this? I don't have a good solution (yet), but for some time I've wanted to make a nice way to attach a worksheet to a PDF file -- and get the notebook server to automatically pull such worksheets out o

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On Fri, Jan 4, 2013 at 10:44 AM, kcrisman wrote: > > > On Friday, January 4, 2013 1:28:11 PM UTC-5, Robert Bradshaw wrote: > >> On Fri, Jan 4, 2013 at 5:17 AM, Volker Braun wrote: >> >>> Having a full url for the ticket makes it click-able if your terminal is >>> smart enough. >>> >> >> On this

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On Friday, January 4, 2013 1:28:11 PM UTC-5, Robert Bradshaw wrote: > > On Fri, Jan 4, 2013 at 5:17 AM, Volker Braun > > wrote: > >> Having a full url for the ticket makes it click-able if your terminal is >> smart enough. >> > > On this note, it would be lovely to have a full clickable URL in

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On Fri, Jan 4, 2013 at 5:17 AM, Volker Braun wrote: > Having a full url for the ticket makes it click-able if your terminal is > smart enough. > On this note, it would be lovely to have a full clickable URL in trac email messages as well. - Robert -- You received this message because you are

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On Fri, Jan 4, 2013 at 5:17 AM, Volker Braun wrote: > While we are at it, why not just > > === cython-0.14.1.p3 (http://trac.sagemath.org/10493) === > > Your name is already in the commit message and and on trac. If you really > like to see it you can still add it below the headline. > > Date is

[sage-devel] Re: Do we need databases/conv.py?

On Jan 4, 7:08 am, kcrisman wrote: > Let's hope Sage continues to yield 100-fold fruit > from what we put into it! Ah, that explains the memory management practices :-). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send

[sage-devel] Re: Attribute errors with polynomials

I don't know if this could be doable, but here is a proposal: to modify the tab completion code so that methods that consist only in raising a NotImplemented error are not shown. This way we could keep the structure there for developpers to follow the name conventions, and we wouldn't confuse user

[sage-devel] Re: Do we need databases/conv.py?

> > > >> Really? Nobody knows? I can't believe it. Let's get rid of it, then? >> > > You can delete it. Needs review at #13910. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups

Re: [sage-devel] Re: Do we need databases/conv.py?

On Friday, January 4, 2013 10:12:17 AM UTC-5, Snark wrote: > > Does it make sense that the rubiks spkg is in the base sage? > > That's been asked before, but probably for historical reasons it doesn't make sense to remove... it's certainly used, for instance for William Joyner's book, if I'm no

Re: [sage-devel] Re: Do we need databases/conv.py?

On Friday, January 4, 2013 10:13:30 AM UTC-5, John Cremona wrote: > > On 4 January 2013 15:08, kcrisman > > wrote: > >>> > > > Thanks. Any of the other things in databases code which is no longer > used? > > sage.databases.cremona is used! > > :-) -- You received this message because

Re: [sage-devel] Re: Do we need databases/conv.py?

On 4 January 2013 15:08, kcrisman wrote: >>> > Thanks. Any of the other things in databases code which is no longer used? sage.databases.cremona is used! John > I've opened #13910 for this one. > -- You received this message because you are subscribed to the Google Groups "sage-devel" grou

Re: [sage-devel] Re: Do we need databases/conv.py?

Does it make sense that the rubiks spkg is in the base sage? kcrisman a écrit : > >> >> >>> Really? Nobody knows? I can't believe it. Let's get rid of it, >then? >>> >> >> You can delete it. This is code I wrote in 2005, which didn't ended >up >> growing. Just like when I'm gardening,

[sage-devel] Re: Do we need databases/conv.py?

> > >> Really? Nobody knows? I can't believe it. Let's get rid of it, then? >> > > You can delete it. This is code I wrote in 2005, which didn't ended up > growing. Just like when I'm gardening, not every seed I plant grows. :-) > > Very apt metaphor, and a venerabl

[sage-devel] Re: Do we need databases/conv.py?

On Fri, Jan 4, 2013 at 6:05 AM, kcrisman wrote: > > > On Thursday, January 3, 2013 3:59:47 PM UTC-5, kcrisman wrote: >> >> As far as I can tell, this code has not been touched in nontrivial ways >> since commit ZERO. Among other wackiness, it refers to a src directory >> under SAGE_ROOT... Remo

Re: [sage-devel] Removing Python Unladen Swallow experimental package

On 2013-01-04 15:40, Harald Schilly wrote: > it is in the archive aka spkg graveyard Good enough, thanks! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this gr

[sage-devel] Re: Attribute errors with polynomials

Helloo !!! Well, it provides a general interface for typical tasks (in order to avoid > that the same functionality is provided by methods of different names in > different classes). I think it's useful, even though it means that some > methods > exist in a context in which they ma

[sage-devel] Re: GCC optional spkg

> > >>> But in the spirit of actually getting #6743 finished, maybe for now we >>> could just have the GCC spkg check whether Cygwin 4.5.x is installed? >>> After all, we need GCC to compile GCC, right? >>> >> I don't see exactly what is really gained by requiring gcc but not g++ >>> or gfor

Re: [sage-devel] Removing Python Unladen Swallow experimental package

ok, consider it deleted (although it is in the archive aka spkg graveyard) h On Fri, Jan 4, 2013 at 3:29 PM, Jeroen Demeyer wrote: > Since nobody replied: > > Harald, please *delete* this dead package: > http://www.sagemath.org/packages/experimental/python-unladen-2009Q2.spkg > > > On 2012-12-19

Re: [sage-devel] Re: Attribute errors with polynomials

I agree with Nathan. There may well be many rings for which it makes sense to have an abs() function, but as that is not true for all rings I cannot see the sense in having a dummy abs() function that high up the hierarchy.Similarly with N. Another one is version() which I just noticed exists

Re: [sage-devel] Removing Python Unladen Swallow experimental package

Since nobody replied: Harald, please *delete* this dead package: http://www.sagemath.org/packages/experimental/python-unladen-2009Q2.spkg On 2012-12-19 10:58, Jeroen Demeyer wrote: > I am refering to the package > http://www.sagemath.org/packages/experimental/python-unladen-2009Q2.spkg > > I as

[sage-devel] Re: GCC optional spkg

On Friday, January 4, 2013 3:22:37 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Friday, January 4, 2013 3:12:35 PM UTC+1, kcrisman wrote: >> >> >> >> On Friday, January 4, 2013 5:31:23 AM UTC-5, Jean-Pierre Flori wrote: >>> >>> By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.

[sage-devel] Re: GCC optional spkg

On Friday, January 4, 2013 3:12:35 PM UTC+1, kcrisman wrote: > > > > On Friday, January 4, 2013 5:31:23 AM UTC-5, Jean-Pierre Flori wrote: >> >> By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 >> cannot, so it would be nice to have a minimal GCC 4.7.2 spkg. >> (Cygwin shi

Re: [sage-devel] ask.sagemath spam

On Thursday, January 3, 2013 9:03:13 AM UTC-5, kcrisman wrote: > > > > On Thursday, January 3, 2013 8:36:59 AM UTC-5, Burcin Erocal wrote: >> >> Hi Karl-Dieter, >> >> On Thu, 3 Jan 2013 05:11:44 -0800 (PST) >> kcrisman wrote: >> >> > The last few weeks there has been a marked increase in spam

Re: [sage-devel] Re: What to do with magically-resolved tickets ?

A better way to ensure that the objects that should have been deleted are actually deleted is to actually look for them. For example, the following doctest in sage/categories/homset.py sage: for p in prime_range(200): ... K = GF(p) ... H = Hom(ZZ, K) ... sage: import

[sage-devel] Re: Attribute errors with polynomials

Hi Nathann, On 2013-01-04, Nathann Cohen wrote: > --e89a8f6467594d8d3f04d276c2d8 > Content-Type: text/plain; charset=ISO-8859-1 > sage: p > x^3 - 3*x > sage: p.abs() > ... > AttributeError: > 'sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint' > object has no att

[sage-devel] Re: GCC optional spkg

On Friday, January 4, 2013 5:31:23 AM UTC-5, Jean-Pierre Flori wrote: > > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 > cannot, so it would be nice to have a minimal GCC 4.7.2 spkg. > (Cygwin shipped GCC 4.5.3 is ok as well, but in the spirit of as few > dependencies

Re: [sage-devel] Re: What to do with magically-resolved tickets ?

Hi Simon, On Jan 4, 2013, at 2:59 PM, Simon King wrote: > On 2013-01-04, Charles Bouillaguet wrote: >> There's also a (fixed) memory-leak : I am not sure if this can be doctested >> properly… > > Which memory leak do you mean? sage-5.6.beta2 contains a couple of fixes for > memory > leaks (#7

[sage-devel] Re: Do we need databases/conv.py?

On Thursday, January 3, 2013 3:59:47 PM UTC-5, kcrisman wrote: > > As far as I can tell, this code has not been touched in nontrivial ways > since commit ZERO. Among other wackiness, it refers to a src directory > under SAGE_ROOT... Removing it would certainly help the coverage score as > we

[sage-devel] Re: Attribute errors with polynomials

Hi Nathan, What do you mean by calling absolute value or norm of a polynomial? Why should these methods even be defined? Cheers, J On Friday, January 4, 2013 1:50:14 PM UTC, Nathann Cohen wrote: > > Hell everybody !!! > > Of course I do not know if what I do has any meaning, but I sti

[sage-devel] Re: What to do with magically-resolved tickets ?

Hi Charles, On 2013-01-04, Charles Bouillaguet wrote: > There's also a (fixed) memory-leak : I am not sure if this can be doctested > properly… Which memory leak do you mean? sage-5.6.beta2 contains a couple of fixes for memory leaks (#715). The fixes originally made some trouble (segfaults),

[sage-devel] Attribute errors with polynomials

Hell everybody !!! Of course I do not know if what I do has any meaning, but I still get exceptions by calling the methods of a polynomial : sage: p = sage.graphs.matchpoly.matching_polynomial(graphs.CompleteGraph(3)) sage: p x^3 - 3*x sage: p.abs() ... AttributeError: 'sage.rings.polyno

Re: [sage-devel] What to do with magically-resolved tickets ?

> solved). How do we handle these tickets ? Mark them as invalid/won't > fix/duplicates ? Give them a positive review ? > Maybe also add doctests (with a reference to the tickets) showing that the > problems are actually solved? > > Absolutely. We want to prevent regression. Another reason t

[sage-devel] Could someone please review #13836?

Hello all, Christian Kuper noted that the critical_points() function of PiecewisePolynomial depended on the variable involved. He then noticed that other functions also depended on the variable. I went through the code and fixed all the variable dependence, with the exception of the convolution fu

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On 2013-01-04 14:17, Volker Braun wrote: > While we are at it, why not just > > === cython-0.14.1.p3 (http://trac.sagemath.org/10493) === > > Your name is already in the commit message and and on trac. If you > really like to see it you can still add it below the headline. I don't mind. -- Yo

[sage-devel] Re: Mentioning Trac ticket numbers in spkgs

While we are at it, why not just === cython-0.14.1.p3 (http://trac.sagemath.org/10493) === Your name is already in the commit message and and on trac. If you really like to see it you can still add it below the headline. Date is useless. Its also duplicated in the commit. Having a full url fo

Re: [sage-devel] Re: Mentioning Trac ticket numbers in spkgs

On 2013-01-04 14:04, Jean-Pierre Flori wrote: > I like it much better than having to search for tickets number on trac > (which if you recall used to be horribly slow although this is now > solved) > but some will claim this is too much bureaucracy :) Not if the Trac ticket number is added automat

[sage-devel] Re: Mentioning Trac ticket numbers in spkgs

In fact, why not generate the whole subtitle automatically? I'm not sure if its worth the effort if we are going to switch things around with the move to git in the spring... On Friday, January 4, 2013 12:55:44 PM UTC, Jeroen Demeyer wrote: > > Based on an idea of Robert Bradshaw, I propose th

[sage-devel] Re: Mentioning Trac ticket numbers in spkgs

I like it much better than having to search for tickets number on trac (which if you recall used to be horribly slow although this is now solved), but some will claim this is too much bureaucracy :) We could also agree on date format, commit message formats, etc. And, just kidding, what if the re

[sage-devel] Mentioning Trac ticket numbers in spkgs

Based on an idea of Robert Bradshaw, I propose the following syntax for spkg changelogs (in SPKG.txt): === cython-0.14.1.p3 (Robert Bradshaw, 1 March 2011, #10493) === * Upgrade Cython to 0.14.1 * Disable (broken) temp arg assignments. Note the ticket number in the top line. Do you like this id

Re: [sage-devel] Re: How to make Sage worksheets publically available

On 4 January 2013 11:42, P Purkayastha wrote: > > I just convert my worksheets to .sage files and put it on github. You can > link to the raw files, and you can put up specific instructions how to run > the files, etc., by writing a README file. > > If you want to do any modifications later, you

[sage-devel] Re: How to make Sage worksheets publically available

On 01/04/2013 07:30 PM, John Cremona wrote: I am working on a paper which establishes some theoretical results and gives some algorithms for things which were implemented in Sage, and have been included in Sage for 2-3 years. The paper contains some worked examples, and I have a Sage worksheet

[sage-devel] How to make Sage worksheets publically available

I am working on a paper which establishes some theoretical results and gives some algorithms for things which were implemented in Sage, and have been included in Sage for 2-3 years. The paper contains some worked examples, and I have a Sage worksheet which contains these examples together with a

Re: [sage-devel] Re: GCC optional spkg

On Friday, January 4, 2013 12:22:18 PM UTC+1, Jeroen Demeyer wrote: > > On 2013-01-04 11:31, Jean-Pierre Flori wrote: > > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 > > cannot, so it would be nice to have a minimal GCC 4.7.2 spkg. > This is harder than you think. G

Re: [sage-devel] Re: GCC optional spkg

On 2013-01-04 11:31, Jean-Pierre Flori wrote: > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 > cannot, so it would be nice to have a minimal GCC 4.7.2 spkg. This is harder than you think. GCC-4.6.3 is released as separate pieces, but GCC-4.7.2 is released monolithically.

[sage-devel] Re: Interactive Sage doesn't exit on sys.exit()

Probably the same reason why ipython always asks "Do you really want to exit ([y]/n)?" if you type Ctrl-D. I call it the "overly attached Python interpreter" ;-) On Friday, January 4, 2013 10:35:21 AM UTC, Jeroen Demeyer wrote: > Why this? > > > sage: sys.exit() > --

Re: [sage-devel] Re: GCC optional spkg

On Friday, January 4, 2013 11:38:09 AM UTC+1, Jeroen Demeyer wrote: > > On 2013-01-04 11:31, Jean-Pierre Flori wrote: > > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 > > cannot > Do you have a pointer to the error message for GCC-4.6.3? And does this > refer to the

Re: [sage-devel] Re: GCC optional spkg

On 2013-01-04 11:31, Jean-Pierre Flori wrote: > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 > cannot Do you have a pointer to the error message for GCC-4.6.3? And does this refer to the Sage-shipped GCC or the Cygwin-shipped GCC? -- You received this message because yo

[sage-devel] Interactive Sage doesn't exit on sys.exit()

Why this? sage: sys.exit() --- SystemExitTraceback (most recent call last) /usr/local/src/sage-5.5.rc1/ in () SystemExit: Type %exit or %quit to exit IPython (%Exit or %Quit do so uncondition

[sage-devel] Re: GCC optional spkg

By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3 cannot, so it would be nice to have a minimal GCC 4.7.2 spkg. (Cygwin shipped GCC 4.5.3 is ok as well, but in the spirit of as few dependencies as possible...) -- You received this message because you are subscribed to the