Hellooooooooooooooo !! > I share your frustrations. I think we all do, to some extent. It would be > very nice if all of these problems, major an minor, could be fixed but the > reality is that until some one cares enough about a particular problem then, > as you say, it isn't going to happen. I think this is called open-source.
I don't know. People usually pay attention to the code they wrote even much later. I still write to Robert Miller when I have questions on the graph backends, and I like to have his advice on Sage things from time to time. He always answers. But because it seems the combinat/ folder is full of stuff Mike Hansen wrote quickly, nobody feels responsible of them. That's also something which is quickly fixed if the classes were to be rewritten. Somebody would know them totally, and perhaps feel that they owe the community to make it a good work. I really, really hate to see on the sage-devel mailing list "is that a bug in a graph function ?", but unfortunately it happens quite often. I try to answer those things as quickly as possible with a patch. Besides, by doing that you begin to learn what users do with Sage, and you can think of those bugs you fixed when you write some new code. > The absent or poor documentation is what I like least about sage. Welcome to the graph world : http://www.sagemath.org/doc/reference/sage/graphs/base/static_sparse_graph.html http://www.sagemath.org/doc/reference/sage/graphs/pq_trees.html http://www.sagemath.org/doc/reference/sage/graphs/graph_decompositions/graph_products.html http://www.sagemath.org/doc/reference/sage/graphs/convexity_properties.html http://www.sagemath.org/doc/reference/sage/graphs/distances_all_pairs.html http://www.sagemath.org/doc/reference/sage/graphs/comparability.html http://www.sagemath.org/doc/reference/sage/graphs/graph_decompositions/vertex_separation.html Just to say that Sage contains tools that can let you write a lot of documentation if you need to. One other point I really do not like about the combinat model is that, unfortunately, you all know each other. You talk with each other, you can explain stuff to each other. And so the reviewer reviews a piece of code that he already knows how to use. Another thing I do not like much is that I find the code far, far, far too much algebraic. I have 2 examples of graph libraries I could not stand to use because of this exactly. Boost : http://www.boost.org/doc/libs/1_52_0/libs/graph/doc/table_of_contents.html here's their code for breadth first search : http://www.boost.org/doc/libs/1_52_0/boost/graph/breadth_first_search.hpp Mascopt (developped in my former lab) : http://www-sop.inria.fr/mascotte/mascopt/ (I spent 1 day full-time reading the manuals, and I had no idea how to build a graph) Well. You have the right to like abstracton and generalizations. I prefer to duplicate code to make things independent, and easy to understand. But I do not have much code to duplicate, perhaps you do. But I find your code much too algebraic by far. Funnily, several days ago Nicolas Florent and I were talking about Sage. They wondered whether Python was a good choice of language, and whether it would remain an important language in the future. - "It would really be an issue to have to port all of our code to another language, so much is based on Python..." - "Do you really use Python at all ? I mean, you wrote categories and it more or less replaces class inheritance in Python, doesn't it ?" Finally, I admit that I like to play dumb, and that for a large part I do not have to play much. But the use of categories have been explained to me one thousand times, that each time there's something I do not like and have to accept, and that after all that time I still hate the idea of having to deal with it. > It's > annoying that quite a lot of "basic" things need to be implemented and that > others have been done badly. I have fixed the things that I really need, or > worked around them. The responsiveness of sage-devel and sage-combinat is > nice. > > I switched to sage because it is the best platform that I found. Sure, many > things could be better, but I don't like gap4, magma, malple, mathematica, > matlab, C, ... In spite of its many warts and problems I do like writing in > python and working with sage. Using sage, I have been able to compute things > much more quickly and painless than before when I was writing in gap. I'm > happy with that. > > Does anyone have any concrete suggestions for how we could improve the > "development model"? There is definitely room for improvement but short of > paying someone I don't have any good suggestions. The problem is that what I > want implemented is often different to what everyone else wants, but > thankfully there is some overlap and so some give and take. Ideas anyone? The development model of Sage-combinat ? Well, I do not know much about it... A few (very) practical thoughts : 1) A bugfix patch for something that is in Sage should NEVER be included in Sage-combinat. It should be sent to Sage, and sage-combinat will inherit it later, when Sage is updated. This way bugfix patches will be merged before the author's death 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 3) Why the hell do you need to have your own fork anyway ? (just my own thought, but I still don't exactly get it) 4) Just look at the TRAC section named combinat. Each time I go look at the patches, I just dream to put them all on "need_work" state. http://trac.sagemath.org/sage_trac/query?status=needs_review&component=combinatorics&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority&row=description I do not even joke. Look at WHEN the tickets were created. In the order I get with the previous link : Reported 3 years ago. Reported 3 years ago. Reported 3 years ago. Reported 2 years ago. Reported 2 years ago. Reported 2 years ago. Reported 23 months ago. Reported 20 months ago. Reported 16 months ago. Reported 11 months ago. Reported 9 months ago. Reported 9 months ago. Reported 9 months ago. Reported 8 months ago. Reported 7 months ago. Reported 6 months ago. Reported 5 months ago. Reported 5 months ago. Reported 4 months ago. Reported 4 months ago. Reported 3 months ago. Reported 3 months ago. Reported 2 months ago. Reported 26 hours ago. Reported 18 months ago. Reported 13 months ago. Reported 6 months ago. Honestly.... Many of these tickets are not really waiting for a review. Many are waiting for the resurrection of developpers, or for their children to learn Python. Some of them have tickets that are not updated with their Sage-combinat counterpart. So my 4) advice is : please, clean this list of dead tickets. Exchange reviews of a ticket against review of others ? We are talking of years... Years... I just try to convince you that your working model has made you FORK from Sage. You have your own, running version of it, with your own patches. You all know how it works so you do not really need to write the documentation. You behave as if you didn't need to contribute to Sage, and you actually don't. Florent is working on a patch to distribute computations right now, and it is a very nice thing ! But for as long as he can use it without including it in Sage, he will not have to write the documentation, clean it, and send it to be reviewed. ..... Because it is already available on Sage-combinat. 5) Accept the idea that your customers may become users, have no more rights than other Sage users and developpers, update the version of Sage they use, and stop spending a lifetime managing a queue. 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.
