Re: [sage-combinat-devel] Re: Permutations... again.
Helloo Andrew ! I'm sure that I should drop this but... At this level it may not hurt anymore :-) When ever anything gets big enough I think this starts to break down. For example, when I whined about the lack of documentation for the pickle jar the people who put this is place didn't feel the need to step in and address this. Even though I am just a sage-combinat customer:), I posted a patch on trac and it is being reviewed (really!). HMmm.. I don't agree with that. I do not work with that many Sage developpers but I am totally convinced that any of them feels responsible about his own code to fix it when a bug is found. But you talk of documentation, and there I totally expect that it may not work anymore, as it is less urgent and dangerous. At least for the classes I am patching now, I am pretty convinced that the explanation lies in the fact that nobody here wrote them. I think that we are rather on the ascending path than the final explosion. I agree that's nice, but what I am complaining about is a general lack of documentation in sage, particularly for the metaclass framework, rather than documentation for code in sage/combinat. If you check, the code in sage/combinat has a relatively high coverage rate. Well documenting the methods when it comes to categories is not really helping, it asks for a more detailed explanation. This way of writing doctests works nicely for the graph stuff, where you only want to know what the method parameters mean and what the output is quickly, but the category stuff only asks for a 10 pages explanation with paragraphs, definitions and a long list of corner-cases situations. One other point I really do not like about the combinat model is that, unfortunately, you all know each other. I am really quite amazed that you see this as a bad thing! Ahhah. Sorry. I love to present as a bad thing something that is definitely good, and the opposite too. Sometimes I get convinced that it helps to think... There are many situations where you do not see the very bad sides of a good situation. It looks so good, it just has to have good sides only !. But I insist that it is not only good in this case, especially when documenting code. Florent and I have done the same thing a couple of times : he has a patch to write and I do not know what is it, or barely, and I try to write its documentation while he explains it to me, and while I ask him questions. This way, you know what a totally ignorant users needs to know when he first meets the class. But the same way that -- after a while -- Sage developpers are totally unable to see things through the eyes of a newcomer and take a LOT for granted, it is hard to explain to somebody new something that you have taken for granted for weeks while talking with a colleague. Of course it is great to be able to talk together. I like this very much, even though I keep complaining about everything. Nicolas and Florent teach me many things quicker than I would have been able to teach myself otherwise(we find bugs by just doing that), but there is, in this way of working, a problem that does not exist when you cannot talk with each other : the guy who does the review will get the very same input the users will : the doc, and nothing else. I think that was you are really complaining about are bug fixes which end up in the sage-combinat queue but are not posted to trac. Yep I fully agree that patches should be posted to trac as soon as they are ready for review and that people shouldn't keep half finished patches lying around in the sage-combinat queue, or elsewhere. I don't see any harm, however, in a patch being both on trac and also in the sage-combinat queue if it is relevant. Oh. I'm talking about the development model, and actually of... politics. If you keep adding fixes to the combinat queue, the bug will be fixed as far as the combinat guys are concerned, and they will not have any need to send it to trac. There is no need, and so it does not get done. Of course there is nothing wrong with having bugfixes in Sage-combinat. There is, for instance, no problem at all with including inside of Sage combinat a positively reviewed patch that will be merged . later, when Jeroen will feel like doing it. But the point is that if you insist a bugfix patch should not be there unless it is already positively reviewed, or not at all, then I am pretty sure everybody will send those patches to trac, because like everybody you need to have the bugs you meet FIXED in the code you work with. 2) Something I discussed with Florent : everybody in Sage-combinat should have at most 2 or 3 patches in the queue. Nothing more. If you want to add another one, get your patches merged into Sage As Anne said, it would be a good idea to try to integrate patches in the sage-combinat queue more quickly. That will not happen by just asking, though. That's what a development model is. That's what politics is all about.
Re: [sage-combinat-devel] Re: state of the queue: 5.4, 5.5.beta0
Hi, Thanks for doing this for me Travis and Nicolas! I've just synced and everything is fine. I now have again a reliable connection to test the queue. Unfortunately, it still didn't work for me to install sage combinat on a plain 5.5.rc0. I had to disable Travis' 12587 due to tons of conflicts and to update my new version of the universal cyclotomics (which hopefully make it into main sage soon, thanks to Frédéric!), and then it worked again. Since others didn't have this problem, I don't update the queue as long as Travis doesn't ask me to do so (I also tent to make mistakes in the process, so it might me my fault)... Best, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
Hi all, In very short: You are totally independent of Sage, you don't *NEED* to contribute to have your version of it evolve Not quite true: we do pay a heavy price for each and every patch that is not merged: we have to keep rebasing them. I can tell you that it *hurts*. We all agree that we should get more patches in *and* we are working on it. Another fact: many of the patches in the Sage-Combinat queue have strong dependencies. This not just because we screwed up our splitting of the task; it is intrinsic to the things we are developing. In the dependencies are things that are basically out of our control (e.g. the patches around #715) that are super technical and that just take time to get into Sage. Given this, there is nothing we can do but keep those patches alive. That being said, I certainly take the blame for not finishing faster the more functorial patch faster. Last fact: many of us spent weeks, if not months, at Sage days this year training newcomers. Don't worry, we *are* getting strong feedback from outsiders. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
YES, but if you were working with the Sage TRAC server the patches would HAVE to be finalised. Please please, that's the whole point ! Nathan, I think that this is the whole point that you are not seeing: we do work with sage and we do use trac. Extensively. Personally, I want my patches posted to trac as quickly as possible and merged into sage. Andrew ps As I am sure you know, putting a patch up on trac in no way guarantees that it will ever be finalised. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/m7NE3uytN6YJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
Hello !! Nathan, I think that this is the whole point that you are not seeing: we do work with sage and we do use trac. Extensively. Personally, I want my patches posted to trac as quickly as possible and merged into sage. Yeah, perhaps I am wrong on that. I said a lot of things about stuff I do not really understand during the last two days. I never worked with Sage-combinat because I never saw the point. What I say is actually just a result of conversations I had with Nicolas and Florent. Iar them talk abou patches, try to work with Florent to write documentation, and I see how it goes... I guess you may have as many combinat experiences as you have combinat users ^^; ps As I am sure you know, putting a patch up on trac in no way guarantees that it will ever be finalised. Well. Indeed, but if you have no other way to share it with a colleague before, that's still a strong force to motivate you :-) Nathann -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
Hi, I have been using the sage-combinat branch from 2008 to 2010 (all of my patches were in sage-combinat before getting on the sage trac) and then stop using it. Here is my view of this. First I believe the following principle is simple but very important : Principle #1 : The priority (ordering) of patches to be merged into Sage should be given to the next patch which is ready and have positive review. To me the main disadvantage of Sage-Combinat queue is that it does not tend to respect Principle #1. Here is why I claim this. First let us introduce some definitions. Definition #2 - Conflict. There is conflicts between two patches if they is a conflict when applying one patch after the other or if the doctest of one patch is broken by the other. Principle #3 : When someone creates a patch in the sage-combinat queue, he or she will put the patch somewhere it does not disturb others, so somewhere it does not create conflicts with other patches. That means the patch will most probably be added after related patches susceptible to conflicts. The consequence of Principle #3 is that the creator of a patch in the sage-combinat queue accept that *the time before inclusion of its own patch into Sage is larger than the time of inclusion of all patches it depends on*. Moreover, those patches depends on others which depends on others and so on... Definition #4 - Slow patch : A patch is slow if it stays on the needs work or needs review status for a long time. The problem is that a certain patch might depend on a slow patch, so that it can be considered as a slow patch even if it is during a period of time while you are promptly working on Sage. I understand that a group of developpers working on similar research subject might work on similar patches/files and are suceptible to conflicts. Thus, it might be a good idea to share a common queue to anticipate and see conflicts in advance. For example : the sage-combinat queue. But, this tends to respect Principle #3 which violates Principle #1. Another reason which tends to violate Principle #1 is that changing the series file (changing the order of patches) takes a non negligeable amount of energy so that you might prefer to keep the ordering as it is and defined following Principle #3. Indeed, testing if a patch commutes with others is not that fast to check : one must unapply the patches, change the series file, reapply all the patches, run sage -br (with hundreds of modified files!!!) Then, once the commutativity is proved, one must recheck that the patch still work before putting it under review (unapply patches to go back to you patch, sage -br (with hundreds of modified files again). You might after build the documentation doing sage -docbuild reference html (with again hundreds of modified files again!!!) Hence, I believe that a development model where there exists a sane competition to be the first to be merged (creating conflicts to eventual slow patches) might be better than a system which tries to avoid conflicts (favorising slow patches). I am looking forward to discuss with Nicolas, Florent and Nathann about it during the next meeting of Sage users in Paris region. Cheers, Sébastien -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/1HdTwfvjSqwJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: state of the queue: 5.4, 5.5.beta0
Hi Christian-- The queue applies fine for me on plain 5.5.rc0. Maybe your guards are not set correctly? This is what is usually the problem for me when the queue seems to have suddenly gone wonky. If that is the case, it can be fixed in one step by running: sage -combinat qselect. cheers, Hugh On Saturday, November 24, 2012 2:34:06 AM UTC-8, Christian Stump wrote: Hi, Thanks for doing this for me Travis and Nicolas! I've just synced and everything is fine. I now have again a reliable connection to test the queue. Unfortunately, it still didn't work for me to install sage combinat on a plain 5.5.rc0. I had to disable Travis' 12587 due to tons of conflicts and to update my new version of the universal cyclotomics (which hopefully make it into main sage soon, thanks to Frédéric!), and then it worked again. Since others didn't have this problem, I don't update the queue as long as Travis doesn't ask me to do so (I also tent to make mistakes in the process, so it might me my fault)... Best, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/nVFxA_yQmfYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
