[sage-devel] Re: Race condition when closing tickets

The obvious answer: Don't change a ticket once it is positive review. Treat it like "closed" -- if you find a bug open a new ticket. On Wednesday, April 15, 2015 at 7:58:50 AM UTC+2, Clemens Heuberger wrote: > > > Ticket #17221 > http://trac.sagemath.org/ticket/17221#comment:20 > > #17221 had

[sage-devel] Race condition when closing tickets

Ticket #17221 http://trac.sagemath.org/ticket/17221#comment:20 #17221 had been set to positive_review before, then reopened, another change (2e62790e) was pushed at 2015-04-13T04:22:22-07 and then set to positive_review again. It was closed at 2015-04-14T12:44:07-07 with the bran

Re: [sage-devel] Re: hosting the sage cell server

On Tue, Apr 14, 2015 at 8:12 PM, Sung-Jin Kim wrote: > Hi William, > > It is interesting to host a Sage cell server. > I have a simple question. Is it only one or one of severals? It is one: http://sagecell.sagemath.org/ 1) Somebody provides Andrew N. access to a sufficiently powerful compu

Re: [sage-devel] Re: hosting the sage cell server

Hi William, It is interesting to host a Sage cell server. I have a simple question. Is it only one or one of severals? James Kim CCB, Harvard sungjin...@fas.harvard.edu On Tue, Apr 14, 2015 at 8:17 PM, William Stein wrote: > On Tue, Apr 14, 2015 at 2:50 PM, William Stein wrote: > > Hi Sage De

[sage-devel] Shout-out to various Sage-related "products" in AMS blog

http://blogs.ams.org/blogonmathblogs/2015/04/13/online-toolbox-for-number-theorists/#sthash.76Vaxs54.lPedVDky.dpbs Among others, the Jones and LMF dbs get a mention. "And as if the database on its own wasn’t cool enough, you can actually load it into Sage and do number field computations to your

[sage-devel] Re: hosting the sage cell server

On Tue, Apr 14, 2015 at 2:50 PM, William Stein wrote: > Hi Sage Developers, > > Is there anybody who would be willing to host the Sage cell server? > http://sagecell.sagemath.org/ > > This would take a dedicated machine or VM with at least 32GB RAM and > at least 100GB fast hard drives. This requ

[sage-devel] hosting the sage cell server

Hi Sage Developers, Is there anybody who would be willing to host the Sage cell server? http://sagecell.sagemath.org/ This would take a dedicated machine or VM with at least 32GB RAM and at least 100GB fast hard drives. -- William -- William (http://wstein.org) -- You received this message

Re: [sage-devel] Re: How to save an animation

On Tuesday, April 14, 2015 at 10:58:16 PM UTC+2, martin@gmx.net wrote: > > I don't mind additional arguments with a higher level of abstraction. But > if you want "show" as a preview to "save" (as in methods 3 and 4), then > "show" should support all the options "save" does. > Typically yo

Re: [sage-devel] Re: How to save an animation

On Tuesday, April 14, 2015 at 9:21:22 PM UTC+2, Volker Braun wrote: > > The output type control for "show" should be more about what the user > wants to achieve, not the technical minutiae of file type that can achieve > it. That is, "show" should be more about raster vs. vector graphics, lossy

[sage-devel] Two poset tickets: graded vs. ranked

There has been some discussion about 'graded' vs. 'ranked' in posets. However, these two tickets are still waiting someone knowing about the area to clarify: http://trac.sagemath.org/ticket/17485 http://trac.sagemath.org/ticket/17487 I can modify the docs and/or code if needed, but don't know

Re: [sage-devel] Deprecate or just remove

There are a lot of questions in that one post... I certainly don't think that the 1-year deprecation rule is an absolute rule. 1) Fixing bugs doesn't require deprecation. 2) Obscure code which isn't documented (except perhaps in the function/class itself), is not used in the Sage library, wh

Re: [sage-devel] Re: Deprecate or just remove

On Tue, 14 Apr 2015, Niles Johnson wrote: another 2c: There is also the option of deprecating, but for less than the somewhat arbitrary 1 year. I would say no to this. If there is some reason to add a deprecating at all, then it should be there for one year at least. -- Jori Mäntysalo

Re: [sage-devel] Re: How to save an animation

On Tuesday, April 14, 2015 at 8:55:58 PM UTC+2, William wrote: > > From an implementation perspective (and maybe others) it is ugly. > But from a pure usability perspective it is nice, since you only have > to remember *one* thing, the name of renderer and nothing else Yes, good. In fact, I wou

[sage-devel] Re: Deprecate or just remove

Not the first time that the xkcd space bar heating feature is mentioned in a ticket. See comment:8 of #16612:) I always used deprecation warnings for removing/renaming/changing a method/function. The only reason where I would allow myself to not

[sage-devel] Re: How to save an animation

The option 3 is the one I like to use: 3. Use "show" instead of "save" for a preview, tweak arguments to that till > I'm satisfied, then change the "show" to a "save". > Sébastien -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: How to save an animation

On Tue, Apr 14, 2015 at 10:38 AM, Volker Braun wrote: > I'm happy to expose all kinds of options to show() and save() with the > exception that: > * save requires a filename, and derives the output type from the filename > * show does not accept a filename, but has another way to control output >

[sage-devel] Re: Deprecate or just remove

Volker raises some very practical points. Not sure I agree on breaking the laws of physics ;-) Probably a lot of any given controversy on this would be to just add to the deprecation policy the following: "If you feel strongly that in a given instance this policy should not be followed, there

[sage-devel] Re: Bug triaging

> > the outdated ones open also makes old problems that really need work > harder to find. > True! Wish I had more time for this triage now - this summer I will, and I did quite a bit in October. -- You received this message because you are subscribed to the Google Groups "sage-devel" grou

[sage-devel] Re: How to save an animation

I'm happy to expose all kinds of options to show() and save() with the exception that: * save requires a filename, and derives the output type from the filename * show does not accept a filename, but has another way to control output type if there is more than one (the viewer=... argument in 3d-p

[sage-devel] Re: Deprecate or just remove

another 2c: There is also the option of deprecating, but for less than the somewhat arbitrary 1 year. On Tuesday, April 14, 2015 at 12:57:44 PM UTC-4, Volker Braun wrote: > > Since its about me I might just as well add my 2c: > > Its a good rule to deprecate things before changing/removing them.

[sage-devel] Re: Deprecate or just remove

Since its about me I might just as well add my 2c: Its a good rule to deprecate things before changing/removing them. Also, rules are there so you can break them once in a while. Its not a law of physics (good luck with breaking those). Use your judgement. If you take it literally then you can

Re: [sage-devel] How to save an animation

Thanks for your input! On Tuesday, April 14, 2015 at 6:11:01 PM UTC+2, William wrote: > > I vote for 3, which is the situation with 2d graphics for the last *9 > years*, and isn't it the current situation with animations right now. > I'm not sure why you don't clearly say for this poll what th

[sage-devel] Deprecate or just remove

Hi! The deprecation guideline reads: “Before removing any functionality, you should keep a deprecation warning in place for at least one year (if possible).” To me, “any functionality” means just that: any functionality,

Re: [sage-devel] How to save an animation

On Tue, Apr 14, 2015 at 8:54 AM, wrote: > Hi! > > This is a quick poll, triggered by comment 50 of ticket 7298 and also > comment 17 of ticket 18176. How would you like to create and save an > animation using Sage. Options (perhaps presented in a slightly biased way): > > 1. Create the animation

[sage-devel] How to save an animation

Hi! This is a quick poll, triggered by comment 50 of ticket 7298 and also comment 17 of ticket 18176 . How would you like to create and save an animation using Sage. Options (perhaps presented i

Re: [sage-devel] Re: Debugging unpickling failures

On 2015-04-14 16:21, Volker Braun wrote: The class vs. type think suggests that its an old-style vs. new-style class conflict. Can you run explain_pickle() and check exactly which step fails? Thanks for the tip. I was using register_unpickle_override() badly: the third argument really must be

[sage-devel] Debugging unpickling failures

Hello all, I am working on #18109 which does some major restructuring of the IntegerListsLex class. The problem is that breaks some pickles from the pickle jar. This is completely understandable. Now my question is: what to do to fix this? With #17842 (needs review by the way!) I got this tr

[sage-devel] Re: Debugging unpickling failures

The class vs. type think suggests that its an old-style vs. new-style class conflict. Can you run explain_pickle() and check exactly which step fails? On Tuesday, April 14, 2015 at 4:16:14 PM UTC+2, Jeroen Demeyer wrote: > > Hello all, > > I am working on #18109 which does some major restructuri

[sage-devel] Re: Patchbot fails after first attempt

Great ! I am happy every time I see a green blob ! In principle, it should update itself at every develop release. But let us see what happen when 6.7.beta0 is out. Frederic Le mardi 14 avril 2015 11:49:48 UTC+2, Jan Keitel a écrit : > > Whatever the problem was before, it is gone now - at leas

[sage-devel] Re: Bug triaging

> The sage trac server has tons of years-old open tickets about > >(i) the notebook; > (ii) interacts; > (iii) Solaris and AIX ports. > > I suspect a number of them should be closed as duplicate/invalid/ > wontfix; it would be nice if people with better knowledge of these areas > cou

[sage-devel] Re: Bug triaging

kcrisman wrote: > Occasionally people do; I occasionally cull (i) or transfer > them/report > upstream to the github sagenb site, for instance. It's just that > people have other things to work on; in that sense, "triage" is > happening continuously. Sure. I mentioned these specific areas because

[sage-devel] Please review trivial ticket at #18188

http://trac.sagemath.org/ticket/18188 -- 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 this group, send email to

[sage-devel] Re: Re: About __len__

Touché ;-) On Tuesday, April 14, 2015 at 1:56:11 PM UTC+2, Marc Mezzarobba wrote: > > Volker Braun wrote: > > Which of the big M's has multiple > > and subtly-different ways to determine the size of a container? > > Maple. ;-) > -- You received this message because you are subscribed to the

[sage-devel] Bug triaging

The sage trac server has tons of years-old open tickets about (i) the notebook; (ii) interacts; (iii) Solaris and AIX ports. I suspect a number of them should be closed as duplicate/invalid/ wontfix; it would be nice if people with better knowledge of these areas could have a look. -- Ma

[sage-devel] Re: Re: About __len__

Volker Braun wrote: > Which of the big M's has multiple > and subtly-different ways to determine the size of a container? Maple. ;-) -- Marc -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving email

Re: [sage-devel] Re: About __len__

On Tuesday, April 14, 2015 at 12:43:49 PM UTC+2, vdelecroix wrote: > > If you want to do math, use `.cardinality()` If you want to do computer programming, then use plain Python and import whatever parts of Sage you want. Moreover there is a nice difference between `len(S)` and > `S.cardinali

Re: [sage-devel] future of 'var' for creating symbolic variables (#17958)

See also the related #5532 about the syntax sage: R. = QQ[] Vincent On 13/04/15 16:12, Daniel Krenn wrote: Dear all, for those who missed (as me up to now): there is a discussion going on at http://trac.sagemath.org/ticket/17958 about the future of the 'var'-command for creating symbolic

Re: [sage-devel] future of 'var' for creating symbolic variables (#17958)

#5532 -> #5332 On 14/04/15 13:21, Vincent Delecroix wrote: See also the related #5532 about the syntax sage: R. = QQ[] Vincent On 13/04/15 16:12, Daniel Krenn wrote: Dear all, for those who missed (as me up to now): there is a discussion going on at http://trac.sagemath.org/ticket/17958

Re: [sage-devel] About __len__

On 14/04/15 12:50, Jori Mantysalo wrote: On Tue, 14 Apr 2015, Vincent Delecroix wrote: It would indeed be better to also support a cardinality method for `MatrixSpace` (be careful to return a Sage integer there) and to support the following sage: MatrixSpace(GF(3),4,5) in FiniteSets() True (t

Re: [sage-devel] About __len__

On Tue, 14 Apr 2015, Vincent Delecroix wrote: It would indeed be better to also support a cardinality method for `MatrixSpace` (be careful to return a Sage integer there) and to support the following sage: MatrixSpace(GF(3),4,5) in FiniteSets() True (this is currently returning False) I ma

Re: [sage-devel] Re: About __len__

On 14/04/15 12:38, Volker Braun wrote: The behavior of len is just a CPython implementation detail. One that is perfectly fine if you have actual containers but really crappy if you want to do math. Its not like we would break len, it is still in line with the Python docs. If you want to do mat

Re: [sage-devel] Re: About __len__

The behavior of len is just a CPython implementation detail. One that is perfectly fine if you have actual containers but really crappy if you want to do math. Its not like we would break len, it is still in line with the Python docs. On Tuesday, April 14, 2015 at 12:25:58 PM UTC+2, vdelecroix

Re: [sage-devel] Re: About __len__

On 14/04/15 12:20, Volker Braun wrote: The output of the magic __len__ method must be a (non-long) int in CPython. So > 64-bit integers are not supported. On the commandline we should probably overwrite len with a version that looks at cardinality() first I am very against overriding more

[sage-devel] Re: About __len__

The output of the magic __len__ method must be a (non-long) int in CPython. So > 64-bit integers are not supported. On the commandline we should probably overwrite len with a version that looks at cardinality() first On Tuesday, April 14, 2015 at 11:45:14 AM UTC+2, Jori Mantysalo wrote: >

Re: [sage-devel] About __len__

On 14/04/15 11:45, Jori Mantysalo wrote: Just wondering, so feel free to ignore. I noticed that MatrixSpace(GF(3), 4, 5).cardinality() raises an exception. However, there is __len__: sage: MatrixSpace(GF(3), 4, 5).__len__() 3486784401 sage: len(MatrixSpace(GF(3), 4, 5)) 3486784401 but sage: M

[sage-devel] Re: Patchbot fails after first attempt

Whatever the problem was before, it is gone now - at least it just successfully tested #18159. When running the patchbot with skip-base, should I make sure that I update the patchbot/base branch regularly or is that done automatically? Many thanks, Jan Am Montag, 13. April 2015 21:39:06 UTC+2 s

[sage-devel] About __len__

Just wondering, so feel free to ignore. I noticed that MatrixSpace(GF(3), 4, 5).cardinality() raises an exception. However, there is __len__: sage: MatrixSpace(GF(3), 4, 5).__len__() 3486784401 sage: len(MatrixSpace(GF(3), 4, 5)) 3486784401 but sage: MatrixSpace(GF(2003), 4, 5).__len__() 108

[sage-devel] Re: Callable symbolic expressions absent from the reference manual

Marc Mezzarobba wrote: > There are *tons* of modules missing from the reference manual, some > obsolete, some still in pre-sphinx style or with rst syntax errors, > some whose user documentation in fact appears in another module, and > many apparently just forgotten. > > A few weeks ago I started