Re: [sage-devel] Mathematica interface

On 22 Dec 2014 00:43, "Robert Jacobson" wrote: > > Hi. I have yet to contribute code to sage, but I think I've found something easy enough for me to start with. I'd like to talk about how to proceed. > > I found ticket #13892 and the apparent duplicate ticket #15318 which indicate that the Mathema

[sage-devel] Mathematica interface

Hi. I have yet to contribute code to sage, but I think I've found something easy enough for me to start with. I'd like to talk about how to proceed. I found ticket #13892 and the apparent duplicate ticket #15318 wh

[sage-devel] Re: How to avoid duplicate work when merging?

Hey Simon, > > > If so, then you're doing > > things wrong. If you have A <- B, then you should merge develop into A, > > then merge A into B. > > That's what I do. > > > If you get any more conflicts, then it's from the > > implementation of B. > > That's what I expected to happen, but I'm

[sage-devel] Re: How to avoid duplicate work when merging?

Hi Travis, On 2014-12-21, Travis Scrimshaw wrote: > Hey Simon, >Are you merging develop into every branch? I merge develop in a branch only if there is a merge conflict to be resolved, or (as is the case now) if otherwise the branch wouldn't build for reasons that are unrelated with my branc

[sage-devel] Re: How to avoid duplicate work when merging?

Hey Simon, Are you merging develop into every branch? If so, then you're doing things wrong. If you have A <- B, then you should merge develop into A, then merge A into B. If you get any more conflicts, then it's from the implementation of B. Also if you don't get any conflicts then any branc

[sage-devel] Re: How to avoid duplicate work when merging?

On Sunday, December 21, 2014 4:31:27 PM UTC+1, Simon King wrote: > > Thank you for the pointer. I think that a tool to arbitrarily move commits > around would be very helpful > You can always use "git cherry-pick" to move a commit (i.e. make a new commit using the changeset from a different comm

[sage-devel] Re: How to avoid duplicate work when merging?

Hi Volker, Am Sonntag, 21. Dezember 2014 15:40:53 UTC+1 schrieb Volker Braun: > > On Sunday, December 21, 2014 12:54:57 PM UTC+1, Simon King wrote: >> >> Concretely, someone found that a certain boilerplate function for >> sequences >> of bounded integers should better have a different name. I a

[sage-devel] Re: Correct way to wrap a C++ class in Cython

Volker, I am using gcc version 4.8.2 and the git version of sage that I myself compiled. I am also attaching the graph.hh file in case I trimmed it too much. Could you please check what is going on? Thanks for your help, Jernej On Saturday, 20 December 2014 17:27:03 UTC+1, Volker Braun wrote

[sage-devel] Re: How to avoid duplicate work when merging?

On Sunday, December 21, 2014 12:54:57 PM UTC+1, Simon King wrote: > > Concretely, someone found that a certain boilerplate function for > sequences > of bounded integers should better have a different name. I am using that > function in all subsequent tickets, and hence I *do* need to propagate

Re: [sage-devel] Re: How to avoid duplicate work when merging?

> The problem comes if you rebase a branch on which somebody else had based a > commit (so started a parallel branch that he meant to merge later). Of course in this case you should not. But often you have a rather good idea of whether anybody (but you) is using your branches ;-) Nathann -- You

[sage-devel] Re: How to avoid duplicate work when merging?

Hi Volker, On 2014-12-21, Volker Braun wrote: > On Sunday, December 21, 2014 11:41:42 AM UTC+1, Nathann Cohen wrote: >> >> Really, I did work with 4+ tickets in linear order. If you add a >> commit to the first one that's 1+2+3+4=10 merge commits that appears >> on Sage's tickets. Now do that t

Re: [sage-devel] Re: Checking whether a Parent models the real field

On 20 December 2014 at 23:46, David Roe wrote: > There are also p-adic fields and others (function fields for example). I > don't think K(-1).is_square() is a good idea Agreed, for any general situation. I was only pointing out the place where the offending code was introduced, and the cont

Re: [sage-devel] Re: How to avoid duplicate work when merging?

On Sunday, December 21, 2014 11:41:42 AM UTC+1, Nathann Cohen wrote: > > Really, I did work with 4+ tickets in linear order. If you add a > commit to the first one that's 1+2+3+4=10 merge commits that appears > on Sage's tickets. Now do that twice, and look at your branches. > Do not do it, the

Re: [sage-devel] Re: How to avoid duplicate work when merging?

> > P.S.: I do not understand why you say that rebasing branches would > make it *harder* to keep branches conflict-free. Once the rebase is > done you don't even have a *trace* that there was once a conflict. As > if it had been solved from the start ! How can that make things more > complicated l

Re: [sage-devel] Re: How to avoid duplicate work when merging?

Hello ! > Thats terrible advice. Rebasing always makes it harder to keep multiple > branches conflict-free. The only advantage of rebasing are > easier-to-understand logs. It does make easier-to-understand logs. I also believe (but Simon would have to check) that it would avoid his double-conflic

[sage-devel] Re: How to avoid duplicate work when merging?

Thats terrible advice. Rebasing always makes it harder to keep multiple branches conflict-free. The only advantage of rebasing are easier-to-understand logs. On Sunday, December 21, 2014 4:22:02 AM UTC+1, Nathann Cohen wrote: > > Hello Simon ! > > If I did not misunderstand your post, I think