Re: [sage-devel] Re: Code of Conduct
It seems to me that there is newgroup etiquette that for this group should include anyone requesting anyone else to move a discussion to private mail, or to sage-flame. At least for a while. Common courtesy would be to agree, even if it might not be entirely to your liking. Changing code is more troublesome. Group A says 0^0 should be simplified to1 because it is consistent with x^0=1. Group B says 0^0 should be 0 because 0^x=0. Group C says it is undefined, UND or NaN. Group D says signal an error... or someone fresh from a calculus course says the answer is log(abs(x)) not log(x). (Remember that?) How to mediate? Not obvious, but sometimes a consensus can be reached through an educational process. Or as is sometimes done in Maxima, by introducing a flag that allows you to implement both choices. Or having a library that, when read in, makes a bunch of changes to suit some context of mathematics. (This is extremely easy in Maxima, loading a Lisp file. I assume there is a way from Sage to cause routines to be overwritten, and even to instruct Maxima to overwrite some of its routines. If a group of people conspire to write, review, and approve a bunch of changes that another group of people think is wrong, then consider the US Congress. Do you want votes, vetoes, filibusters? I think the nuclear option is to make a project fork, as was done for example in the CAS Axiom -- FriCAS. RJF On Saturday, November 15, 2014 9:05:51 PM UTC-8, Nathann Cohen wrote: Hello ! Here are some links to discussions that look to me have gone astray. Also, as you might notice that some of the participants in these discussions have since ceased to post on the public mailing lists, even though they were active contributors/developers before: Ahahaha. Such a long thread, advocating that criticism should never get personnal, and all of a sudden I learn that it is only there to decide what Sage should dispose of my humble self ? :-PPP If we want to avoid that discussions drift off to private mailing lists or to loose contributors, as we all seem to agree is not desirable, then I think guidelines for discussions would be helpful. You see, in this case the effect of guidelines would only be to close discussions. Or, to be more direct, to throw me out of it. And I do not think that this is a good way out. If I make no mistake, in two of those threads I was mostly complaining against lack of actions. The thing with a code of conduct is that a winning strategy is just to stop answering/posting as it only condems insults and verbal violence, while I believe that in some cases that would be escaping one's responsibilities. Responsibility is hard to define in a code of conduct. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: checkout for closed tickets which are not yet in develop
On Sunday, November 16, 2014 6:34:56 AM UTC, Clemens Heuberger wrote: Works for me, possibly because I have a newer git. Can it be that it works for you because the commit ec0aae9358f5204a3db6406b2c2f2818a78f5892 (this is the actual commit of #16747) is contained in your local repository? Yes, and I have the commit visible because I ran git remote update trac (and trac is not set up as tracking remote). This pulls down all branches, so in particular it makes the commit visible again. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
There is git trac try 12345 which basically does that. It also switches to a detached head to minimize the danger of pushing unnecessary merges back to trac. On Sunday, November 16, 2014 4:52:16 AM UTC, Nathann Cohen wrote: Hello everybody ! On 16 November 2014 01:48, john_perry_usm john@usm.edu javascript: wrote: (1) When switching development to Git, it became harder for the less talented to contribute. I'm not the only one who encountered a complete recompilation of Sage when reviewing a new ticket -- even one that didn't touch Cython. See, e.g., some of my comments on ticket #17298, where at one point I wrote, I can't afford to tie up my installation for 2 hours of compilation every time a few lines of Python code change. This used not to occur in Mercurial. Just wondered if we could not have some git hook (I do not exactly know what it can do) to make sure that one cannot checkout a branch which is not a descendent of the latest release of Sage in the local history. Thing is that to my experience this is the only reason why git triggers big recompilations. So what having a git hook saying something like you cannot checkout this branch, it is too old. If you want to use it, merge it with the latest beta instead ? And we could have some -f flag when we really want to do that... But that would prevent newcomers from wasting a couple of hours. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
There is git trac try 12345 which basically does that. It also switches to a detached head to minimize the danger of pushing unnecessary merges back to trac. H O_o And do newcomers still make the mistake ? Or do they run different commands and end up having to recompile everything ? Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: 2x2 integer matrices
On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote: Hello, We currently have two much implementation of 2x2 matrices. I found at least three that leads to distinct element classes sage: M1 = SL2Z sage: M2 = MatrixSpace(ZZ,2) sage: from sage.matrix.matrix_integer_2x2 import MatrixSpace_ZZ_2x2 sage: M3 = MatrixSpace_ZZ_2x2() sage: m1 = M1([2,1,1,1]) sage: m2 = M2([2,1,1,1]) sage: m3 = M3([2,1,1,1]) SL2Z is mostly used in code related to modular forms. And I found only one place where MatrixSpace_ZZ_2x2 is used. I would like to: - try to remove the special class we have for SL2Z (or at least inherit from the generic 2x2 integer which is faster and interacts nicely with the rest of matrix code) - make the MatrixSpace_ZZ_2x2 be the default when we call MatrixSpace(ZZ,2). I wanted to ask about opinions before starting. Vincent PS: benchmark sage: %timeit m1**1001 1000 loops, best of 3: 237 µs per loop sage: %timeit m1*m1 10 loops, best of 3: 14.8 µs per loop sage: %timeit m2**1001 1 loops, best of 3: 74.4 µs per loop sage: %timeit m2*m2 10 loops, best of 3: 4.4 µs per loop sage: %timeit m3**1001 1 loops, best of 3: 19.3 µs per loop sage: %timeit m3*m3 100 loops, best of 3: 847 ns per loop Is this with or without http://trac.sagemath.org/ticket/16803 ? In C, m**1001 takes 6 µs and m*m takes 200 ns for me with flint. Fredrik -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: 2x2 integer matrices
2014-11-16 5:42 UTC−07:00, Fredrik Johansson fredrik.johans...@gmail.com: On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote: Hello, We currently have two much implementation of 2x2 matrices. I found at least three that leads to distinct element classes sage: M1 = SL2Z sage: M2 = MatrixSpace(ZZ,2) sage: from sage.matrix.matrix_integer_2x2 import MatrixSpace_ZZ_2x2 sage: M3 = MatrixSpace_ZZ_2x2() sage: m1 = M1([2,1,1,1]) sage: m2 = M2([2,1,1,1]) sage: m3 = M3([2,1,1,1]) SL2Z is mostly used in code related to modular forms. And I found only one place where MatrixSpace_ZZ_2x2 is used. I would like to: - try to remove the special class we have for SL2Z (or at least inherit from the generic 2x2 integer which is faster and interacts nicely with the rest of matrix code) - make the MatrixSpace_ZZ_2x2 be the default when we call MatrixSpace(ZZ,2). I wanted to ask about opinions before starting. Vincent PS: benchmark sage: %timeit m1**1001 1000 loops, best of 3: 237 µs per loop sage: %timeit m1*m1 10 loops, best of 3: 14.8 µs per loop sage: %timeit m2**1001 1 loops, best of 3: 74.4 µs per loop sage: %timeit m2*m2 10 loops, best of 3: 4.4 µs per loop sage: %timeit m3**1001 1 loops, best of 3: 19.3 µs per loop sage: %timeit m3*m3 100 loops, best of 3: 847 ns per loop Is this with or without http://trac.sagemath.org/ticket/16803 ? In C, m**1001 takes 6 µs and m*m takes 200 ns for me with flint. Hello Frederik, I did the benchmark on sage-6.4 in which #16803 is already merged. What do you mean by in C? Vincent -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: 2x2 integer matrices
On Sun, Nov 16, 2014 at 4:08 PM, Vincent Delecroix 20100.delecr...@gmail.com wrote: 2014-11-16 5:42 UTC−07:00, Fredrik Johansson fredrik.johans...@gmail.com: On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote: Hello, We currently have two much implementation of 2x2 matrices. I found at least three that leads to distinct element classes sage: M1 = SL2Z sage: M2 = MatrixSpace(ZZ,2) sage: from sage.matrix.matrix_integer_2x2 import MatrixSpace_ZZ_2x2 sage: M3 = MatrixSpace_ZZ_2x2() sage: m1 = M1([2,1,1,1]) sage: m2 = M2([2,1,1,1]) sage: m3 = M3([2,1,1,1]) SL2Z is mostly used in code related to modular forms. And I found only one place where MatrixSpace_ZZ_2x2 is used. I would like to: - try to remove the special class we have for SL2Z (or at least inherit from the generic 2x2 integer which is faster and interacts nicely with the rest of matrix code) - make the MatrixSpace_ZZ_2x2 be the default when we call MatrixSpace(ZZ,2). I wanted to ask about opinions before starting. Vincent PS: benchmark sage: %timeit m1**1001 1000 loops, best of 3: 237 µs per loop sage: %timeit m1*m1 10 loops, best of 3: 14.8 µs per loop sage: %timeit m2**1001 1 loops, best of 3: 74.4 µs per loop sage: %timeit m2*m2 10 loops, best of 3: 4.4 µs per loop sage: %timeit m3**1001 1 loops, best of 3: 19.3 µs per loop sage: %timeit m3*m3 100 loops, best of 3: 847 ns per loop Is this with or without http://trac.sagemath.org/ticket/16803 ? In C, m**1001 takes 6 µs and m*m takes 200 ns for me with flint. Hello Frederik, I did the benchmark on sage-6.4 in which #16803 is already merged. What do you mean by in C? I mean just calling the flint functions directly in a C program. I'm surprised that there is so much overhead (4 µs) on the Sage side for multiplying two matrices, particularly considering that there seems to be less than 1 µs overhead for multiplying two MatrixSpace_ZZ_2x2. I guess exponentiation doesn't call fmpz_mat_pow at all and just does binary exponentiation on Sage objects. Fredrik -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
Hi, Maybe the instruction git checkout -b my_branch FETCH_HEAD in the developer's guide at http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets should be replaced by git checkout -b my_branch git merge FETCH_HEAD In this way, the trac branch is merged into the user one. If the trac branch is based on a version of Sage that is older than that of the user, this should not trigger a full recompilation, contrary to the previous instruction. Eric. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
A) this will change time stamps and hence cause a lengthy compilation anyways B) there is a very real cost in unnecessary merges, they make the log harder to read. If you want to argue in favor of unnecessary merges then please also provide a reason why other git-using projects are wrong when they discourage unnecessary merges. On Sunday, November 16, 2014 4:40:26 PM UTC, Eric Gourgoulhon wrote: Hi, Maybe the instruction git checkout -b my_branch FETCH_HEAD in the developer's guide at http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets should be replaced by git checkout -b my_branch git merge FETCH_HEAD In this way, the trac branch is merged into the user one. If the trac branch is based on a version of Sage that is older than that of the user, this should not trigger a full recompilation, contrary to the previous instruction. Eric. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
Yo ! A) this will change time stamps and hence cause a lengthy compilation anyways Nono, it only change the timestamps of the files which are modified by the branch. I am using a small bash script that does that for me since I use git in Sage and never had this problem anymore. B) there is a very real cost in unnecessary merges, they make the log harder to read. Well, first when the guy only wants to review/checkout a branch you do not care, because it is only done on his computer. Then, it is not that big of a problem, really. In most tickets there is no need for a merge as they are written between two releases, and otherwise you have one merge commit when you set a ticket to needs_work because there is some conflict. The merge is the last of the branch, and usually that is all. If you want to argue in favor of unnecessary merges then please also provide a reason why other git-using projects are wrong when they discourage unnecessary merges. For beginners it is easier. And that it a big problem of ours at the moment. We could tell them later on that we prefer them to rebase the branches or something, but well.. Really I have been writing dozens of tickets this way and I do not think that the git histories were so ugly. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 5:47:05 PM UTC, Nathann Cohen wrote: If you want to argue in favor of unnecessary merges then please also provide a reason why other git-using projects are wrong when they discourage unnecessary merges. For beginners it is easier Ok, everybody who is using git and discourages unnecessary merges is just stupid and hasn't realized it yet. Possible, but unlikely reason. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
For beginners it is easier Ok, everybody who is using git and discourages unnecessary merges is just stupid and hasn't realized it yet. Possible, but unlikely reason. I don't know, man I am just telling you that we could advise beginners to do that because it is easier for them (+does not hurt anyone), and to tell them later that we don't like it (if for some reason we don't), and you make me say everybody else is stupid. I give up. It's getting late here anyway. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
I agree: one shall unvoid unnecessary merges. Can you please tell what the command git trac try 12345 does, in terms of plain git ? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 6:02:22 PM UTC, Eric Gourgoulhon wrote: Can you please tell what the command git trac try 12345 does, in terms of plain git ? It just does the merge in a detached head (HEAD is no longer a named branch, so you can't push it accidentally) git checkout --detach develop git fetch trac u/user/descrption git merge FETCH_HEAD -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Code of Conduct
On Saturday, November 15, 2014 11:37:50 PM UTC+1, Anne Schilling wrote: On 11/15/14 11:47 AM, mmarco wrote: I am afraid i would need more information to make a decission about this. I wasn't aware of the existence of the problems you mention. Without knowing what happened in those cases, i cannot say if the proposed code of conduct would have been a good idea to prevent them or not. Here are some links to discussions that look to me have gone astray. Also, as you might notice that some of the participants in these discussions have since ceased to post on the public mailing lists, even though they were active contributors/developers before: While that definitely illustrates the point, I find it curious that the one of the advocates of a code of conduct is the same one to write, ... no, I won't go there. I think I'd better just check out of the conversation at this point. john perry -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 5:52:16 AM UTC+1, Nathann Cohen wrote: Hello everybody ! ... Just wondered if we could not have some git hook (I do not exactly know what it can do) to make sure that one cannot checkout a branch which is not a descendent of the latest release of Sage in the local history. Thanks for paying attention to that. :-) If I understand correctly, your proposals fix the problem with tickets, but I think there's a bigger problem. Or, maybe I just don't understand, but if so, you can correct me here, and that should save me trouble later, right? In the most recent debacle that constitutes my attempts to help with Sage ;-) I followed the steps listed in the developer's guidelines from the most recent release: checked out a branch (apparently it checks out itself, though I'm not sure) then modified the few lines of Python code, then executed ./sage -br. Cue the complete rebuild of Sage. (This may be because I downloaded a binary, but I don't think so. Even if so, it doesn't make sense: I only changed a few lines a Python code.) *After* that, Travis Scrimshaw made some very helpful changes, but he did them based on the development version. So, when I tried to work with it, so as to give it a positive review (which actually needed more work)... cue another complete rebuild of Sage. I don't see how the proposed change would have fixed either problem. Sorry if this is completely off base, but I thought the extra clarification might help. john perry -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
...ah, and to emphasize: in the old system, this simply wouldn't have happened. I would have applied the patch, and only the things that needed recompilation would have recompiled. Sometimes, as in this case, that would be an empty set. In the old days, I only recompiled Sage when I completely juiced my system... which wasn't an empty set, but it wasn't of large cardinality, either. Basically, would it be possible to add an intermediate step where people could download only the relevant patch (like before), apply experiment only with the patch (like before), then, when that seemed okay, check against the most recent branch (like now)? Sorry if this sounds like ignorant babble; I'm not familiar with the correct vocabulary. john perry On Sunday, November 16, 2014 7:53:43 PM UTC+1, john_perry_usm wrote: On Sunday, November 16, 2014 5:52:16 AM UTC+1, Nathann Cohen wrote: Hello everybody ! ... Just wondered if we could not have some git hook (I do not exactly know what it can do) to make sure that one cannot checkout a branch which is not a descendent of the latest release of Sage in the local history. Thanks for paying attention to that. :-) If I understand correctly, your proposals fix the problem with tickets, but I think there's a bigger problem. Or, maybe I just don't understand, but if so, you can correct me here, and that should save me trouble later, right? In the most recent debacle that constitutes my attempts to help with Sage ;-) I followed the steps listed in the developer's guidelines from the most recent release: checked out a branch (apparently it checks out itself, though I'm not sure) then modified the few lines of Python code, then executed ./sage -br. Cue the complete rebuild of Sage. (This may be because I downloaded a binary, but I don't think so. Even if so, it doesn't make sense: I only changed a few lines a Python code.) *After* that, Travis Scrimshaw made some very helpful changes, but he did them based on the development version. So, when I tried to work with it, so as to give it a positive review (which actually needed more work)... cue another complete rebuild of Sage. I don't see how the proposed change would have fixed either problem. Sorry if this is completely off base, but I thought the extra clarification might help. john perry -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote: This may be because I downloaded a binary, but I don't think so. Even if so, it doesn't make sense: I only changed a few lines a Python code. I can think of lots of reasons how unpacking the binary tarball (and the relocation script) can screw up time stamps. In any case, this is unrelated to git. *After* that, Travis Scrimshaw made some very helpful changes, but he did them based on the development version. So, when I tried to work with it, so as to give it a positive review (which actually needed more work)... cue another complete rebuild of Sage. Really that is Travis' fault for doing an unnecessary merge. Which, in turn, forced you to recompile to follow the merge. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 11:08:36 AM UTC-8, Volker Braun wrote: On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote: This may be because I downloaded a binary, but I don't think so. Even if so, it doesn't make sense: I only changed a few lines a Python code. I can think of lots of reasons how unpacking the binary tarball (and the relocation script) can screw up time stamps. In any case, this is unrelated to git. *After* that, Travis Scrimshaw made some very helpful changes, but he did them based on the development version. So, when I tried to work with it, so as to give it a positive review (which actually needed more work)... cue another complete rebuild of Sage. Really that is Travis' fault for doing an unnecessary merge. Which, in turn, forced you to recompile to follow the merge. Well, not necessarily. I had the following situation recently: I was reviewing two tickets based on two different versions of Sage. Every time I moved between the branches, everything had to recompile. So at the end I rebased one of the patches to the most current version of Sage, so that I could review the tickets simultaneously. How else would you handle this situation? Of course that forced the author of the patch to recompile once for a long time ... Best, Anne -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 7:20:38 PM UTC, Anne Schilling wrote: so that I could review the tickets simultaneously. How else would you handle this situation? As long as both branches are close enough so that sage -br works (no make required) I don't think thats an issue. If they are far apart then you could use more than one Sage installation, you can even share the upstream/ folder with a symlink. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
Le dimanche 16 novembre 2014 19:31:25 UTC+1, Volker Braun a écrit : On Sunday, November 16, 2014 6:02:22 PM UTC, Eric Gourgoulhon wrote: Can you please tell what the command git trac try 12345 does, in terms of plain git ? It just does the merge in a detached head (HEAD is no longer a named branch, so you can't push it accidentally) git checkout --detach develop git fetch trac u/user/descrption git merge FETCH_HEAD Thanks for the explanation. Eric. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 8:08:36 PM UTC+1, Volker Braun wrote: On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote: This may be because I downloaded a binary, but I don't think so. Even if so, it doesn't make sense: I only changed a few lines a Python code. I can think of lots of reasons how unpacking the binary tarball (and the relocation script) can screw up time stamps. In any case, this is unrelated to git. Okay, yes, in hindsight that's obvious. I suspect that's the reason for the first recompile. *After* that, Travis Scrimshaw made some very helpful changes, but he did them based on the development version. So, when I tried to work with it, so as to give it a positive review (which actually needed more work)... cue another complete rebuild of Sage. Really that is Travis' fault for doing an unnecessary merge. Which, in turn, forced you to recompile to follow the merge. I get that (Travis mentioned it himself), but I'm not sure why it's Travis' fault. First, the only change that needed to be made was a few lines of Python code. If we could download test patches as before, this wouldn't be a problem. As it is, I basically gave the ticket a positive review by following his advice hand-copying a few more changes he made, which is morally equivalent to the old way. :-) Second, wouldn't that test against the development version have to be made at some point, anyway? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 8:50:41 PM UTC, john_perry_usm wrote: I get that (Travis mentioned it himself), but I'm not sure why it's Travis' fault. First, the only change that needed to be made was a few lines of Python code. If we could download test patches as before, this wouldn't be a problem. You can still do that, git show sha1 is just a patch that you can apply by hand. Its going to be just as manual labor intensive and error prone as before, of course. Second, wouldn't that test against the development version have to be made at some point, anyway? The trac ticket shows whether there is a merge conflict, if there isn't one then there is no need to test it by hand. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code of Conduct
On Friday, November 14, 2014 6:05:02 AM UTC-6, mmarco wrote: So, about the code of conduct, it sounds like a nice set of guidelines. But, do we really need it? I mean, has it been some hard conflict that i have not been aware of? I know that we have some trolling and flaming going on every once in a while, but it doesn't seem to have been harmful so far. In general, the discussion here is very respectfull (I haven't seen any RTFM answer to people asling for help, for instance). My impression is that the Sage community is nice for newcommers. We have done quite well so far without a code of conduct. Frames of reference vary. When I am interacting with Sage developers, I routinely edit my draft posts to make them more assertive and less nice. --Ursula. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
Incidentally it is totally archaic and unnecessary that one should have to do make or sage -b at all after changing pure python code. That's purely a technically problem that we should have solved long ago. Mike Hansen even implemented something much better once but it didn't get positive review. If you work on nonsage python projects they mostly support e.g. pythob setup.py develop for this sort of thing. William. On Nov 16, 2014 12:59 PM, Volker Braun vbraun.n...@gmail.com wrote: On Sunday, November 16, 2014 8:50:41 PM UTC, john_perry_usm wrote: I get that (Travis mentioned it himself), but I'm not sure why it's Travis' fault. First, the only change that needed to be made was a few lines of Python code. If we could download test patches as before, this wouldn't be a problem. You can still do that, git show sha1 is just a patch that you can apply by hand. Its going to be just as manual labor intensive and error prone as before, of course. Second, wouldn't that test against the development version have to be made at some point, anyway? The trac ticket shows whether there is a merge conflict, if there isn't one then there is no need to test it by hand. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
You can still do that, git show sha1 is just a patch that you can apply by hand. Its going to be just as manual labor intensive and error prone as before, of course. I don't recall finding it manual labor intensive, and for a while I was doing quite a bit w/Nathann on MILP. As I recall, I had bigger problems trying to write code Nathann liked, and trying to explain my needs, than I did with applying the patches. And that was *with* Cython recompilations. john perry -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
On Sunday, November 16, 2014 9:59:34 PM UTC+1, Volker Braun wrote: On Sunday, November 16, 2014 8:50:41 PM UTC, john_perry_usm wrote: I get that (Travis mentioned it himself), but I'm not sure why it's Travis' fault. First, the only change that needed to be made was a few lines of Python code. If we could download test patches as before, this wouldn't be a problem. You can still do that, git show sha1 is just a patch that you can apply by hand. Its going to be just as manual labor intensive and error prone as before, of course. Oh, wait: are you talking about having to trace back through different tickets, on those occasions where there *was* a significant difference? In that case, yes, it was labor-intensive, and automating by git is great. No argument there. To repeat what I said in another thread: I don't object to git; I understand why it's been adopted (I'm actually using git at the moment on another system), and I had see the git try ... think before, so I realize the major developers recognize are working on it. I'm not questioning all that. What I'm saying is that, for all the present setup's advantages with medium to large changes, forcing the casual developer to recompile frequently, on very minor changes, is a big disincentive. So if git show sha1 obtains a usable patch that I can apply as before (I will try it at some point) then that should go into the developer's manual. john perry -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About recmpilations caused by Git
Really that is Travis' fault for doing an unnecessary merge. Which, in turn, forced you to recompile to follow the merge. So instead I have to let my Sage recompile just because I want to work on a ticket not currently based on the latest development? In fact, I'm worried I might not even be able to start Sage because of more recent spkgs. If that's what I have to do, then I'm never going to review someone else's ticket I don't know if they mind merges to latest develop. (However I do take responsibility for not explicitly mentioning that I merged the latest develop.) Merging with the latest develop branch is not unnecessary as it is something that must be done and it would put my Sage development into a standstill as I almost always need the latest develop. IMO unnecessary merges are those where *small* unrelated changes are made to a base branch and merged in 1 by 1. I'm more than willing to spend time and energy to teach people git usage to reduce large re-compilations. Travis -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
I agree with Travis. You declared that unnecessary merges are bad and from that line we find ourselves with bigger problems, i.e. those that are faced by the beginners when they first review a ticket or write one. When doing a review the merge is unimportant as it will never be pused to the branch. When working on a ticket we often have to merge anyway as the branch becomes incompatible with the latest beta. I have seen branches with bad git history and the problem was not the many merge commits: it was the lack of proper/clear commit messages. Also, they misunderstood the role of commits: they are there to make sense to the reviewer, and to help him understand how the code is written. I have been working this way since the beginning and I do not think anybody found my branches particularly messy. If you want to insist on the religious point that unnecessary merges are bad, I really believe that this is how we should teach our newcomers, for it is already sufficiently painful to contribute at first, with all rules we have for code. And you can enforce a religion on them later on if you want to. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
Hello John ! ...ah, and to emphasize: in the old system, this simply wouldn't have happened. I would have applied the patch, and only the things that needed recompilation would have recompiled. Sometimes, as in this case, that would be an empty set. In the old days, I only recompiled Sage when I completely juiced my system... which wasn't an empty set, but it wasn't of large cardinality, either. Well, if you systematically merge the remote branch with the latest release available on your computer, git behaves like hg and you only have to recompile the files modified by the branch. I have a script that does something like that: git branch -D tmp git checkout -b tmp develop git pull trac remote_branch When the remote branch was already up-to-date it creates no commit, it is just a 'fast-forward' in git's terminology When the remote branch is not up-to-date but there is no conflict, I just fill a commit message saying trac #number: rebased on the latest beta When the remote branch is not compatible with the latest release I fix the problems then create the merge commit. I insist that this way of doing things make it behave like mercurial did with respect to recompilations. Also, I worked like that for a long time and my branches usually have no merge commit (when they get reviewed between two betas) or one for the longest ones. Sometimes they have two, for very very long ones (but I usually rebase them when they get this old). What I mean to say is that if beginners write branches with one or two merge commits, this is not a very hard price to pay to make it easier for them. Plus beginners branches are usually simple things, which are quickly reviewed: thus there should be no merge commit at all. Finally, I think that this is the best procedure to *review* branches, as it triggers the minimum amount of recompilation and there is no problem with the branch history as everything only happens on the reviewer's computer. Nathann -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
