Re: [sage-devel] sage-6.4 fallout: stein-watkins-ecdb

On 2014-11-15 19:57, William Stein wrote: I installed the huge stein-watkins-ecdb optional spkg, sage -i stein-watkins-ecdb The correct command is sage -i database_stein_watkins We should really *remove* the optional package stein-watkins-ecdb. -- You received this message because you ar

[sage-devel] [ARM] Sage 6.4

Hi, will a bdist of sage 6.4 for ARM be made available on the website, or should I compile one myself and pass it along as usual? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiv

Re: [sage-devel] Re: About recmpilations caused by Git

On Monday, November 17, 2014 3:06:42 AM UTC, Nathann Cohen wrote: > > You declared that "unnecessary merges are bad" > Its not just me, ask any lager project that is using git. Half of them even force you to clean up your history before submitting anything. The log is not just there for the re

[sage-devel] Re: [ARM] Sage 6.4

Our gcc 4.9.2 doesn't compile on arm, and nobody reviewed http://trac.sagemath.org/ticket/17348 so far. On Monday, November 17, 2014 8:33:44 AM UTC, Snark wrote: > > Hi, > > will a bdist of sage 6.4 for ARM be made available on the website, or > should I compile one myself and pass it along a

Re: [sage-devel] sage-6.4 fallout: stein-watkins-ecdb

On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer wrote: > We should really *remove* the optional package stein-watkins-ecdb. I can do this, but it would break for older Sage installs, right? The bad one is in the "huge" directory, whereas the good one is in "upstream". Besides that, there are th

Re: [sage-devel] sage-6.4 fallout: stein-watkins-ecdb

We haven't formulated a policy yet. Obviously we'll have to delete old tarballs at one point, but is disk space really an issue already? On Monday, November 17, 2014 11:22:00 AM UTC, Harald Schilly wrote: > > On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer > wrote: > > We should really *remov

[sage-devel] Warning message and encoding

Matrix(RR, [[1,2],[3,4]]).eigenvalues() gives warning message "Using generic algorithm for an inexact ring - -", which is of course correct. After that it prints "#!/usr/bin/env python". But on one occasion I already get "# -*- coding: utf-8 -*-" aftew warning on version 6.4. Is this reproduci

Re: [sage-devel] Re: About recmpilations caused by Git

Yo ! > Its not just me, ask any lager project that is using git. Half of them even > force you to clean up your history before submitting anything. Volker, I am not telling you that having bad histories is good, I am telling you that letting newcomers not care about the amount of merge commits is

Re: [sage-devel] Re: About recmpilations caused by Git

On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote: > > Volker, I am not telling you that having bad histories is good > So we agree, perfect ;-) Really the problem is that we rely on time stamps for deciding what to compile. That is a technical issue that we'll fix eventually. -

Re: [sage-devel] Re: About recmpilations caused by Git

>> Volker, I am not telling you that having bad histories is good > > So we agree, perfect ;-) > > Really the problem is that we rely on time stamps for deciding what to > compile. That is a technical issue that we'll fix eventually. There is something wrong with the world. Sometimes I t

[sage-devel] Re: Warning message and encoding

I agree that it is not desirable, but that is the standard IPython behavior: $ ipython [...] In [1]: import warnings In [2]: warnings.warn('foo') /usr/bin/ipython:1: UserWarning: foo #!/usr/bin/python On Monday, November 17, 2014 11:45:53 AM UTC, Jori Mantysalo wrote: > > Matrix(RR, [[1,2],[3

Re: [sage-devel] sage-6.4 fallout: stein-watkins-ecdb

On 17 November 2014 11:21, Harald Schilly wrote: > On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer > wrote: >> We should really *remove* the optional package stein-watkins-ecdb. > > > I can do this, but it would break for older Sage installs, right? > The bad one is in the "huge" directory, wher

[sage-devel] NTL and Singular updates

Dear all, Anyone feeling like reviewing the updates to NTL 6.2.1 (http://trac.sagemath.org/ticket/16882) and Singular 3-1-7 (http://trac.sagemath.org/ticket/17184) ? It would be nice to have them in before working on the much more involved Singular 4-0-x and (surely not so hard) NTL 7.0.1 updat

[sage-devel] How to clean up local git history?

Hi! On another thread, there was talk about "avoiding unnecessary merge comits". I agree that a nice git history is, well, nice. But I need some pointers to achieve it. Situation: I have a local branch "branch_local" (not published) that I'd like to rebase on top of the latest develop, in order t

Re: [sage-devel] Re: About recmpilations caused by Git

On Monday, 17 November 2014 22:53:53 UTC+11, Volker Braun wrote: > > On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote: >> >> Volker, I am not telling you that having bad histories is good >> > > So we agree, perfect ;-) > > OK, so if I have a branch that is using an old version o

[sage-devel] Document patches in the patch file, not in SPKG.txt

I would like to propose another change to SPKG.txt, and that is to NOT document patches in there but in the patch file. As you might know, the patch can have arbitrary text before the first diff hunk, anything that is not an actual diff is ignored. The documentation change will be http://trac.

Re: [sage-devel] Re: About recmpilations caused by Git

On Monday, November 17, 2014 12:43:28 PM UTC, Andrew wrote: > > OK, so if I have a branch that is using an old version of sage what is the > recommended way of moving it up to the latest development branch. > The recommended way is to stay on the old version unless you actually need something fr

[sage-devel] Re: Document patches in the patch file, not in SPKG.txt

On Monday, November 17, 2014 1:45:09 PM UTC+1, Volker Braun wrote: > > I would like to propose another change to SPKG.txt, and that is to NOT > document patches in there but in the patch file. As you might know, the > patch can have arbitrary text before the first diff hunk, anything that is > n

[sage-devel] Re: How to clean up local git history?

1) Thats a bit vague, but it wouldn't surprise me that merge has fewer conflicts since it has more information available. Rebase just replays the commits so you have to re-resolve conflicts. Though there is git rerere to help with that. 2) The default should be not to merge either branch with t

Re: [sage-devel] Re: About recmpilations caused by Git

> This pull a lot of (unclean) garbage into my history so I am guessing that, > on principle, Nathan would refuse to review such patches when they are done. Nathann-bashing has become a game or what ?... I would see nothing wrong with that branch. By the way on trac the diff file would only show

Re: [sage-devel] Code of Conduct

> > [X ] Yes, this is a great idea. About time! > To a newcomer, some of the posts may make the Sage community look aggressive and end up steering them in another direction. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe fr

[sage-devel] Re: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)

This is Trac Ticket #17205 . John Palmieri gave a quick fix in comment #2. Note that I'm not one of the developers of this package -- merely a happy user. :-) Best, Konstantin -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: About recmpilations caused by Git

> > > This pull a lot of (unclean) garbage into my history so I am guessing > that, > > on principle, Nathan would refuse to review such patches when they are > done. > > Nathann-bashing has become a game or what ?... > > I read that as just repeating what you said as a statement, but I may h

[sage-devel] Re: sage-6.4 fallout: brian optional package

> > sage: !sage -i brian >> Found package brian in >> /usr/local/sage/sage-6.4/upstream/brian-1.4.1.p0.spkg >> brian-1.4.1.p0 >> (Stripping trailing CRs from patch; use --binary to disable.) >> patching file brian/units.py >> Hunk #1 FAILED at 11173 (different line endings). >> 1 out of 1 h

Re: "merged in" field of trac (was: Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems)

> IMHO the most convenient place is to look in the git history, this also > works if you don't currently have internet access for starters. The > git-trac script implements this: > > $ git trac find 4f8b380 > Commit has been merged in 6.4.rc1. > Very useful, but perhaps not so much to people

Re: [sage-devel] Re: Code of Conduct

> > >>1. Continuing to lose talented Sage developers specifically because > >> they do not feel comfortable with the tone of the lists, and > > > > > > Can you give an example of this, even if vaguely? I don't read every > > conversation on the lists, but in my personal experience, the co

Re: [sage-devel] Re: About recmpilations caused by Git

Hello ! > I read that as just repeating what you said as a statement, but I may have > misread it? Well, the branch I had in mind had something like 5-6 commits and all had the same message "merged with develop" or something. No way to know what was happening, and of course they were not only mer

Re: [sage-devel] Bug in abs(I*x).diff(x)

For reference (since Sage uses Ginac for most derivatives) see http://www.cebix.net/pipermail/ginac-devel/2014-April/002105.html -- 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, sen

Re: [sage-devel] Bug in abs(I*x).diff(x)

Vladimir V. Kisil kisilv's patch http://www.ginac.de/pipermail/ginac-devel/2013-November/002053 looks like a good start to me especially if one doesn't want to consider the issue of derivatives of non-analytic functions in general. On 17 November 2014 10:14, kcrisman wrote: > For reference (sin

Re: [sage-devel] Bug in abs(I*x).diff(x)

> Vladimir V. Kisil kisilv's patch > > http://www.ginac.de/pipermail/ginac-devel/2013-November/002053 > > looks like a good start to me especially if one doesn't want to > consider the issue of derivatives of non-analytic functions in > general. > > http://www.ginac.de/pipermail/ginac-devel/

Re: [sage-devel] vote: include pip with sage

vdelecroix wrote: > The pip ticket (#16479) is now positively reviewed. Should I open a > new one to make it standard? > Yes! -- 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, s

Re: [sage-devel] vote: include pip with sage

> > > The pip ticket (#16479) is now positively reviewed. Should I open a >> new one to make it standard? >> > > Yes! > Alternately (or complementarily?) see #17155. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this gro

[sage-devel] Re: sage-6.4 fallout: brian optional package

> > > > Is there a reason we need to have our own version? > > Actually, I think there is, because see the original ticket #9675: I must say I detected some problems with Brian units related to the Sage classes 'RealNumber? ' and 'Integer', so I create

[sage-devel] Re: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)

> This is Trac Ticket #17205 . John > Palmieri gave a quick fix in comment #2. > > Note that I'm not one of the developers of this package -- merely a happy > user. :-) > > Note also that http://www.risc.jku.at/research/combinat/software/ore_algebra/ sug

Re: [sage-devel] Re: sage-6.4 fallout: brian optional package

On Nov 17, 2014 10:42 AM, "kcrisman" wrote: >> >> >> > Is there a reason we need to have our own version? >> > > Actually, I think there is, because see the original ticket #9675: > > I must say I detected some problems with Brian units related to the Sage classes 'RealNumber?' and 'Integer', so I

Re: [sage-devel] Re: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)

> Note also that > http://www.risc.jku.at/research/combinat/software/ore_algebra/ suggests > that >> Right now you are using Version 0.2 last updated on November 16, 2014, > developed for Sage 6.3. > > So maybe we just need to update our package? > > ore_algebra-0.1 . no

Re: [sage-devel] Bug in abs(I*x).diff(x)

Hi Bill, On Sat, Nov 15, 2014 at 9:18 AM, Bill Page wrote: > On 14 November 2014 14:29, Ondřej Čertík wrote: >> >> On Nov 14, 2014 11:30 AM, "Bill Page" wrote: >>> >>> What do you mean by "the real derivative"? >> >> The absolute value doesn't have a complex derivative, but it has a real >> der

Re: [sage-devel] Bug in abs(I*x).diff(x)

> I still don't understand exactly your proposal. We've played with a > few ideas above, in particular we have considered at least (below d/dz > is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives > with respect to "x" or "iy" in z=x+i*y) : > > 1) d/dz > 2) d/dz + d/d conjugate(z)

Re: [sage-devel] Re: About recmpilations caused by Git

> Nathann-bashing has become a game or what ?... > Sorry, wasn't intended as Nathan-bashing: I was just referring to your previous comment. > The problem with your method is that you change all timestamps. I do > it reverse: fetch the remote branch, and merge it into develop. No > change

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 17 November 2014 15:17, Ondřej Čertík wrote: > On Sat, Nov 15, 2014 at 9:18 AM, Bill Page wrote: >> >> I am sorry for the confusion. What I am proposing is that the >> Wirtinger derivative(s) be considered the fundamental case (valid >> for complex or even quaternion variables). As you noted

Re: [sage-devel] Bug in abs(I*x).diff(x)

Hi Bill, Thanks for the clarification. So your point is that 2) is not sufficient, that we really need two Wirtinger derivatives --- it's just that one can be expressed using the other and a conjugate, so perhaps CAS can only return one, but a chain rule needs modification and probably some other