On 12/18/2013 05:58 PM, Robert Bradshaw wrote:
>
> But if you push this then the original author won't be able to cleanly
> pull your rebase. It gets worse if people are depending on this ticket
> for further development.
If nothing in 6.2 affects the branch in question, the commits can still
be
On 12/18/2013 05:01 PM, Simon King wrote:
>
> Isn't rebasing even worse than an occasional merge commit? If I recall
> correctly, gits claim that rebasing a published branch means to change
> the history of the branch and is very evil.
You should try not to change the history of a public branch t
On Wed, Dec 18, 2013 at 9:51 AM, Michael Orlitzky wrote:
> On 12/18/2013 11:59 AM, Jeroen Demeyer wrote:
>> On 2013-12-18 08:24, Robert Bradshaw wrote:
7. But since the "u/johndoe/tracabcde" branch misses everything that went
into Sage in between 6.1 and 6.2, I suppose the first thing I
Rebasing is definitely worse.
*Useless* commits can be annoying, but at least they don't invalidate other
people's work.
If you have a reason to merge (conflict resolution or you need feature from
other branch), then merges are the right thing to do.
On Wednesday, December 18, 2013 10:01:41 PM
The "sage -i filename" only works for old-style spkgs. You can put the
tarball in the upstream/ directory, though.
On Wednesday, December 18, 2013 9:47:02 PM UTC, John Cremona wrote:
>
> On 18 December 2013 21:33, John Cremona >
> wrote:
> > On 18 December 2013 17:19, Harald Schilly
> > >
>
Hi Michael,
On 2013-12-18, Michael Orlitzky wrote:
>> Didn't Volker say that merging is a bad idea?
>>
>
> If there are no changes in 6.2 that affect your branch, you can get away
> with a `git rebase 6.2` here.
Isn't rebasing even worse than an occasional merge commit? If I recall
correctly, g
On 18 December 2013 21:33, John Cremona wrote:
> On 18 December 2013 17:19, Harald Schilly wrote:
>> On Wed, Dec 18, 2013 at 6:07 PM, Volker Braun wrote:
>>> The correct spkg is
>>> http://boxen.math.washington.edu/home/vbraun/upstream/database_cremona_ellcurve-20121022.tar.bz2
>>
>>
>> Hi, I'm
On 18 December 2013 17:19, Harald Schilly wrote:
> On Wed, Dec 18, 2013 at 6:07 PM, Volker Braun wrote:
>> The correct spkg is
>> http://boxen.math.washington.edu/home/vbraun/upstream/database_cremona_ellcurve-20121022.tar.bz2
>
>
> Hi, I'm still a bit confused about this. What I did is to replac
On Wednesday, 18 December 2013 17:59:00 UTC+1, Jeroen Demeyer wrote:
>
> On 2013-12-18 08:24, Robert Bradshaw wrote:
> >> 7. But since the "u/johndoe/tracabcde" branch misses everything that
> went
> >> into Sage in between 6.1 and 6.2, I suppose the first thing I now
> should do
> >> is:
>
On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote:
>
> Users of polynomials should worry about the coefficient ring. What do
> someone should expect of
>
> sage: (6*x^2 - 12).factor()
>
> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic
> polynomial there
Users of polynomials should worry about the coefficient ring. What do
someone should expect of
sage: (6*x^2 - 12).factor()
The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic
polynomial there is no way to make it coherent...
Moreover, I feel very uncomfortable having an extra
On 12/18/2013 11:59 AM, Jeroen Demeyer wrote:
> On 2013-12-18 08:24, Robert Bradshaw wrote:
>>> 7. But since the "u/johndoe/tracabcde" branch misses everything that went
>>> into Sage in between 6.1 and 6.2, I suppose the first thing I now should do
>>> is:
>>>
>>> git merge --no-edit 6.2
>>
>> Yep
On Wed, Dec 18, 2013 at 6:07 PM, Volker Braun wrote:
> The correct spkg is
> http://boxen.math.washington.edu/home/vbraun/upstream/database_cremona_ellcurve-20121022.tar.bz2
Hi, I'm still a bit confused about this. What I did is to replace the
current file with the one from your directory. md5su
On 18 December 2013 16:54, Robert Bradshaw wrote:
> You should still be able to do ./sage -i /path/to/xxx.spkg
... but only if the spkg-install has been updated, which my local copy
hasn't, so I get errors (SAGE_DATA not defined).
>
> You're right, the online one should have worked too. Someone
The correct spkg is
http://boxen.math.washington.edu/home/vbraun/upstream/database_cremona_ellcurve-20121022.tar.bz2
Harald, can you copy that over the current version?
See http://trac.sagemath.org/ticket/14962
On Wednesday, December 18, 2013 4:48:23 PM UTC, John Cremona wrote:
>
> I have the
On 2013-12-18 08:24, Robert Bradshaw wrote:
7. But since the "u/johndoe/tracabcde" branch misses everything that went
into Sage in between 6.1 and 6.2, I suppose the first thing I now should do
is:
git merge --no-edit 6.2
Yep.
Didn't Volker say that merging is a bad idea?
Jeroen.
--
You re
You should still be able to do ./sage -i /path/to/xxx.spkg
You're right, the online one should have worked too. Someone updated
the spkg without updating the checksums (maliciously or otherwise).
On Wed, Dec 18, 2013 at 8:48 AM, John Cremona wrote:
> I have the habit of installing a short list o
I have the habit of installing a short list of optional spkgs whenever
I build a new Sage version on my machine, and to avoid downloads I
have been keeping the .spkg files locally, and using sage -i
/xxx.spkg
I realise that this will probably not work (or will it?) with the the
git arrangement, e.
Actually, we are currently working at removing strings. If you download the
latest version from the git server (see the instructions on the web page;
it should become version 0.4 soon), you would notice that the new syntax is
X. = M.chart('x y z')
The string 'xyz', which was used as a chart ide
Good Job!
But I have to agree with Volker, using strings is not a good idea.
Why not using functions as input instead?
e.g. in your example from the tutorial:
X. = M.chart('x y z', 'xyz')
I would use something like
var('x y z')
charti = x*y*z
X = M.chart(vars = [x,y,z], map = charti)
On Sund
Why reinvent the wheel? A symbolic polynomal class should be capable of a
type checking of the coefficients and transform the polynomial internally
into the correct setting and then call the correct algorithms and methods.
The main purpose of such a class is that the user can work intuitively wi
This is the output of my release-manager script, monkey-patched to get
the info from git:
http://boxen.math.washington.edu/home/jdemeyer/sage-git/logs/tickets.html
and
http://boxen.math.washington.edu/home/jdemeyer/sage-git/logs/sage-6.0.txt
As you can see, there is a lot of red in the HTML fil
Hi again,
On 2013-12-18, maldun wrote:
> 1) I think that applying Polynomial division by commands like
>
> sage: f(x)=3Dx^3+5*x^2-3*x+1
> sage: g(x)=3Dx+1
> sage: f.maxima_methods().divide(g)
> [x^2 + 4*x - 7, 8]
>
> are not very intuitive.
These aren't polynomials but symbolic expressions. If y
Hi,
On 2013-12-18, maldun wrote:
> --=_Part_1054_13775092.1387359867313
> Content-Type: text/plain; charset=ISO-8859-1
>
> And another thing: A more unified interface for polynomials.
>
> Currently we have, as you mentioned, three ways to define polynomials.
No, we have only one. The other t
On Wednesday, December 18, 2013 8:56:45 AM UTC, Ralf Hemmecke wrote:
>
> Right. And I don't know why one ever seriously wants to work detached.
> Detached work is always in danger of being garbage collected via git gc.
>
Its definitely not a feature that I would want to recommend a novice, but
And another thing: A more unified interface for polynomials.
Currently we have, as you mentioned, three ways to define polynomials. It
would enable us to design a class which provides a good default behavior
for the average user.
--
You received this message because you are subscribed to the G
On Tuesday, December 17, 2013 3:01:47 PM UTC+1, Volker Braun wrote:
>
> On Tuesday, December 17, 2013 12:34:31 PM UTC, maldun wrote:
>>
>> And I have another question: why github?
>>
>
> We only use github to mirror our own repo to save bandwidth. All
> development is done with our own git serve
1) I think that applying Polynomial division by commands like
sage: f(x)=x^3+5*x^2-3*x+1
sage: g(x)=x+1
sage: f.maxima_methods().divide(g)
[x^2 + 4*x - 7, 8]
are not very intuitive. This should be done by specific methods/operators for
polynomials, and this can only be done by a specific class f
On 18 December 2013 08:56, Ralf Hemmecke wrote:
>>> 6. And then create a new branch, say "my_branch", to work (do the review)
>>> on, if I choose not to work "detached":
>>>
>>> git checkout -b my_branch FETCH_HEAD
>
> Right. And I don't know why one ever seriously wants to work detached.
> Detach
>> 6. And then create a new branch, say "my_branch", to work (do the review)
>> on, if I choose not to work "detached":
>>
>> git checkout -b my_branch FETCH_HEAD
Right. And I don't know why one ever seriously wants to work detached.
Detached work is always in danger of being garbage collected via
30 matches
Mail list logo
