Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
On 09/14/10 04:18 PM, kcrisman wrote: Otherwise, please move this thread to sage-flame - if only out of self- interest. Potential developers will read this, and the tone (not facts, which are not at issue) may help them decide to move on. Thanks, - kcrisman To quote Nathann from him in an email sent to several of us who working on getting Nathann's GLPK package into Sage: = though my way of seeing it would really be to avoid spending hours wondering how it could fail when it seems so easy to just test it and write patches when errors are reported. = That development attitude belongs on sage-devel, not sage-flame. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
Hi Nathann, On Tue, Sep 14, 2010 at 10:48 PM, Nathann Cohen nathann.co...@gmail.com wrote: If by any miracle you still ignored that I wrote this (very poor -- let me add it for you) interface and all the functions of Sage that use Cliquer, you will find my name under the SPKG Maintainer field of the SPKG.txt file you made me modify not so long ago, which may be enough to drop me a line when you are asking whether the package should be removed. This response is understandable. What I'm saying is: If a problem arises from a standard spkg, one could send an email to sage-devel and CC the maintainer(s) of that spkg. It has been one year since I wrote that and I was learning both Cython and how to contribute to Sage at that time, but I would be glad to answer any question you could have on this respect. I'll be looking into the Cliquer spkg. I hope you would answer any questions I have regarding that spkg or about computing cliques. I think Cliquer is a nice addition in Sage's Graph Library. It is. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
Hi David, On Wed, Sep 15, 2010 at 12:01 AM, Dr. David Kirkby david.kir...@onetel.net wrote: I had my suspicions it was you, but I was not sure - I had no intentions of accusing anyone unless I was sure. I had in fact cc'ed you on the ticket, but you made no comments whatsoever. I also touched the Cliquer spkg, so I feel partly responsible. Another change that has been made is to the Makefile to build a shared library. Again, not commented. There's nothing in SPKG.txt to indicate you added a shared library. I remember working on build issues for the Cliquer spkg. But NONE of that should be to the upstream source code. How the hell I am supposed to know what changes you have made? Sure, some have changes with sage in the name, but how does one really know what else is changed? Am I expected to track down an old version of the code (no longer on line), and try to work out what changes have been made? That is a valid comment. The idea of having the directory src/ within an spkg is for depositing pristine upstream code. IMHO, if you can't be bothered to read the Sage developers guide and read how .spkg files are supposed to be maintained, then you should not maintain them. You do a very poor job of doing so, which creates headaches for others. When Nathann and I worked on the Cliquer spkg during the 4th quarter of 2009, some sections of the Developer's Guide was not available then. One notable example is the section Patching a Sage Package [1]. Now there is little excuse for us or anyone maintaining/developing Sage and standard spkg's not to read the Developer's Guide. [1] http://www.sagemath.org/doc/developer/patching_spkgs.html -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Cliquer - upstream modifications and dubious code
Hi Jan, On Wed, Sep 15, 2010 at 3:43 PM, Jan Groenewald j...@aims.ac.za wrote: Is there a sage-devel code of conduct (like Ubuntu's perhaps -- it could easily be adapted from that)?. It might be a good addition. I have been collecting some information [1] on managing an open source community, with a view to adapting the information to the Sage community. The Ubuntu Code of Conduct [2] is relevant here. [1] http://wiki.sagemath.org/CommunityManagement [2] http://www.ubuntu.com/community/conduct -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
Hi Nathann, Hello Minh ! I'll be looking into the Cliquer spkg. I hope you would answer any questions I have regarding that spkg or about computing cliques. I would and I will. If, as Dima mentionned it, I was meant to read this whole conversation as a Nathann, could you update the Cliquer SPKG so that your modifications only appear in a patch folder (and at some point the whole of Cliquer's source was in this patch/ folder), this would indeed require very few work which I can of course take care of. This could be done now that David is done working on #9871 (which updated cliquer to p7) and if he does not intend to address #7782 right now Or perhaps should we wait for the p7 version to be included in a Sage release before updating it again ? I have to admit I am not really looking forward upgrading the sources to the latest version released (1.2.1) myself -- fearing any problem that could result from such an upgrade regarding Solaris support. Ticket 9871 was initially entitled Update Cliquer to 1.21 and get the library buiilding properly on Solaris, and when I look a what it has become, I know I could not handle it and will not be seen to try. Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
If, as Dima mentionned it, I was meant to read this whole conversation as a Nathann, could you update the Cliquer SPKG so that your modifications only appear in a patch folder (and at some point the whole of Cliquer's source was in this patch/ folder), this would indeed require very few work which I can of course take care of. This could be done now that David is done working on #9871 (which updated cliquer to p7) and if he does not intend to address #7782 right now Or perhaps should we wait for the p7 version to be included in a Sage release before updating it again ? Hmmm... David just created 9870. I will wait until he his done working on this spkg before touching it again. Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
On 09/15/10 11:01 AM, Nathann Cohen wrote: If, as Dima mentionned it, I was meant to read this whole conversation as a Nathann, could you update the Cliquer SPKG so that your modifications only appear in a patch folder (and at some point the whole of Cliquer's source was in this patch/ folder), this would indeed require very few work which I can of course take care of. This could be done now that David is done working on #9871 (which updated cliquer to p7) and if he does not intend to address #7782 right now Or perhaps should we wait for the p7 version to be included in a Sage release before updating it again ? Hmmm... David just created 9870. I will wait until he his done working on this spkg before touching it again. Nathann I did not just create #9870 - it has been open for 8 days. I just CC'ed you it, as I omitted to do that before. Leif agreed to take ownership of that. Perhaps you can work with Leif on that. Leif may or may desire your involvement, though I think you would find working with him rather hard, as even I find his attention to detail a bit excessive some times. I think you and Leif would clash even more than you and I! However, I had already CC'ed you on #9871 and #9833, but you made no comments on either. Had you read those tickets, you would have been aware of the problems people were facing with modified upstream code. There is one technical question you can however answer. Do we need the binary file cl so it can be executed from the command line, or is the library libcliquer.so sufficient? Perhaps you can state that fact on http://trac.sagemath.org/sage_trac/ticket/9870 is it will affect how the package gets changed. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Cliquer - upstream modifications and dubious code
On 09/15/10 06:17 AM, Minh Nguyen wrote: I'm disheartened that this happened. One should not modify upstream source, but place patches against upstream source under the directory patch/. I think you mean patches. I did notice a patch directory in Cliquer, but http://www.sagemath.org/doc/developer/patching_spkgs.html#overview-of-patching-spkg-s says patches. That's a minor point though. I worked on getting Cliquer to build as a shared library on Cygwin, Linux, Mac OS X and Solaris (t2.math). I take your comments as an encouragement for me (or anyone) to further investigate how to polish up the Cliquer spkg. In my programming work, I have been following advice from E. S. Raymond's book The Art of Unix Programming [1] and D. A. Wheeler's book Secure Programming for Linux and Unix HOWTO -- Creating Secure Software [2]. I hope you would continue to share your thoughts, as you have generous done, on good programming practices so that contributors to the Sage community can benefit from your experience. Clearly Minh you take the time to read up on what are considered good practices, but your attention to such issues is not universal among Sage developers. #1 seems pretty useful for all Sage developers to read. #2 is a bit less so, though clearly anyone dealing with the notebook should look at #2. IMHO, the notebook is very bad from a security point of view, but I have some sympathy for William over that. He probably never expected to get a large number of people using one sage server, so security was not high on his priority list. It's s shame there are not any decent books online about best practices in software engineering. Whatever I've found tends to be in expensive books. [1] http://catb.org/~esr/writings/taoup/html/ [2] http://www.dwheeler.com/secure-programs/ [3] http://en.wikipedia.org/wiki/Clique_(graph_theory) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
On 09/14/10 01:48 PM, Nathann Cohen wrote: David, I tried 10 times to give an answer to your message, but none managed to stay very calm after the 5th line. I still have great hopes for the following attempt. First, I remember having said once on this mailing list -- but perhaps it was not to you and in this case I do not mind saying it again -- that I mostly disliked to be criticized (for loss of a better word) by people who hided behind the developper, the programmer, or any name they could find other than mine when they obviously perfectly know who they are talking about. If they absolutely have to do it, though, I like to be added as a recipient of the message, and not to find this out by pure luck on this google group. Nathann Nathann, You were cc'ed on #9833 fatal relocation error with Cliquer library on 64-bit Solaris and OpenSolaris. You made no comments on that ticket. You were also CC'ed on #9871, the *original* title of which was Update Cliquer to 1.21 and get the library buiilding properly on Solaris. So that is two tickets, with Cliquer in the tile, and you cc'ed on. But on neither ticket have you made a single comment. Had you read the comments on those tickets, you would have seen that people (especially Leif) were unhappy about the code quality. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Cliquer - upstream modifications and dubious code
This might be of interest on security grounds: http://www.amazon.com/Secure-Coding-Robert-C-Seacord/dp/0321335724 On 9/15/2010 6:46 AM, Dr. David Kirkby wrote: On 09/15/10 06:17 AM, Minh Nguyen wrote: I'm disheartened that this happened. One should not modify upstream source, but place patches against upstream source under the directory patch/. I think you mean patches. I did notice a patch directory in Cliquer, but http://www.sagemath.org/doc/developer/patching_spkgs.html#overview-of-patching-spkg-s says patches. That's a minor point though. I worked on getting Cliquer to build as a shared library on Cygwin, Linux, Mac OS X and Solaris (t2.math). I take your comments as an encouragement for me (or anyone) to further investigate how to polish up the Cliquer spkg. In my programming work, I have been following advice from E. S. Raymond's book The Art of Unix Programming [1] and D. A. Wheeler's book Secure Programming for Linux and Unix HOWTO -- Creating Secure Software [2]. I hope you would continue to share your thoughts, as you have generous done, on good programming practices so that contributors to the Sage community can benefit from your experience. Clearly Minh you take the time to read up on what are considered good practices, but your attention to such issues is not universal among Sage developers. #1 seems pretty useful for all Sage developers to read. #2 is a bit less so, though clearly anyone dealing with the notebook should look at #2. IMHO, the notebook is very bad from a security point of view, but I have some sympathy for William over that. He probably never expected to get a large number of people using one sage server, so security was not high on his priority list. It's s shame there are not any decent books online about best practices in software engineering. Whatever I've found tends to be in expensive books. [1] http://catb.org/~esr/writings/taoup/html/ [2] http://www.dwheeler.com/secure-programs/ [3] http://en.wikipedia.org/wiki/Clique_(graph_theory) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cliquer - upstream modifications and dubious code
Dear David, Your post finds me in a very good mood. I just went out for a walk to think about my graphs and found out again that I loved the sight of a deep blue sky, small streets, seagulls and sea more than any other. There can be no better background for a graph problem :-) You were cc'ed on #9833 fatal relocation error with Cliquer library on 64-bit Solaris and OpenSolaris. You made no comments on that ticket. You were also CC'ed on #9871, the *original* title of which was Update Cliquer to 1.21 and get the library buiilding properly on Solaris. So that is two tickets, with Cliquer in the tile, and you cc'ed on. But on neither ticket have you made a single comment. I am terribly sorry. I usually pay attention to what is happening to Cliquer (e.g. the present thread), but what happened on these Solaris-related tickets was way beyond my abilities. I usually try not to intrude on any ticket whose title contains Solaris as a rule, knowing you probably do not need my help dealing with them. As you know, You, me, all of us, are constantly struggling with time : we have very few and try to make the most of it. I am trying to concentrate on what I can do, sometimes neglecting important duties. I hope you will not hold any hard feelings toward me because of that, and I encourage you to send me an email immediately if you feel I could be useful at some point. As you probably noticed, I did not fail to answer your question on #9870. Had you read the comments on those tickets, you would have seen that people (especially Leif) were unhappy about the code quality. This grieves me. I dearly hope that you will find me constantly improving in the future. Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: non-stable .spkgs (alpha, beta, svn/cvs snapshots etc)
On Mon, Sep 13, 2010 at 3:37 AM, David Kirkby david.kir...@onetel.net wrote: True. But if person A creates the ticket, person B reviews it and the release manager finds it passes, it may end up getting merged. I see that as someone not doing there job properly if we were to decide that a vote is required in that case. Let's face it, we can always imagine a scenario where safeguards fails. We are just minimizing risks and damages. Francois But the current rules permit this. * Person A decides to update a .spkg to a non-stable release * There's no need to discuss it on sage-devel or have a vote. * Person B reviews this unstable release and gives it positive review. * The release manager merges this snapshot and we all suffer. This is the current situation, and one I feel is very wrong. My thread has only attracted responses from yourself and Jason, so perhaps it's not of interest to many. If we have to send everything to a vote, this will paralyze development. Both person A and person B and the manager should be aware that a given spkg is off an unstable release, and feel comfortable with the justifications for using it rather than the old version. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: non-stable .spkgs (alpha, beta, svn/cvs snapshots etc)
We are all adults here. Well mostly, excluding some child-prodigy- developers we have. Policy is for people who have no judgment. I just read a ticket where Robert Miller said, Take it to sage-devel. Burcin took another ticket I was in on to sage-devel. A third ticket got sent back to needs info by Mike Hansen after having a positive review for 10 days. Don't know about the resolution of the first ticket (yet), but I know the latter two were improved by the expanded discussion. So we can, and do, back up and reconsider or take things to a larger group. And if an spkg mucks up a release in testing it can be pulled. Isn't that why we test (as opposed to setting a positive-review standard that requires passage on a wide variety of systems)? What about the packages that only release stable every couple years, but we know are high quality in between? Or the stable releases of others that really aren't that good no matter what? Can we exercise some judgment? And move back and forth from sage-devel and Trac as appropriate, needed, requested, desired? I have enough policy in my life. I want Sage to be high-quality. But I want that to come from the reasoned judgment of smart and dedicated people I trust and respect. Yes, we do need some policy - like doctesting, code formats, etc. Yes, the issue of spkg quality should definitely be addressed in the Developers Guide and sage-devel announcements should be prominently mentioned as one avenue (and maybe the possibility of votes if it seems necessary). Lets replace policy with culture. I'd rather we monitored sage-devel and Trac and participated politely and respectfully rather than promulgate policy. Help each other out and teach one another when we see someone stray (often necessarily) into areas (build systems, languages, interfaces, web design, mathematics) where their skills are weak and ours are strong. I'm no expert, but I've derived a lot of satisfaction from helping several newbies get started developing for Sage - some of whom have since made significant contributions. And I'd really rather see fewer Sage developers refer to an ever increasingly bureaucratic model used for Sage. Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: non-stable .spkgs (alpha, beta, svn/cvs snapshots etc)
+1 to Rob Beezer's comments. I don't have anything to add to them, other than my agreement - very well said. -Marshall Hampton On Sep 15, 8:50 pm, Rob Beezer goo...@beezer.cotse.net wrote: We are all adults here. Well mostly, excluding some child-prodigy- developers we have. Policy is for people who have no judgment. I just read a ticket where Robert Miller said, Take it to sage-devel. Burcin took another ticket I was in on to sage-devel. A third ticket got sent back to needs info by Mike Hansen after having a positive review for 10 days. Don't know about the resolution of the first ticket (yet), but I know the latter two were improved by the expanded discussion. So we can, and do, back up and reconsider or take things to a larger group. And if an spkg mucks up a release in testing it can be pulled. Isn't that why we test (as opposed to setting a positive-review standard that requires passage on a wide variety of systems)? What about the packages that only release stable every couple years, but we know are high quality in between? Or the stable releases of others that really aren't that good no matter what? Can we exercise some judgment? And move back and forth from sage-devel and Trac as appropriate, needed, requested, desired? I have enough policy in my life. I want Sage to be high-quality. But I want that to come from the reasoned judgment of smart and dedicated people I trust and respect. Yes, we do need some policy - like doctesting, code formats, etc. Yes, the issue of spkg quality should definitely be addressed in the Developers Guide and sage-devel announcements should be prominently mentioned as one avenue (and maybe the possibility of votes if it seems necessary). Lets replace policy with culture. I'd rather we monitored sage-devel and Trac and participated politely and respectfully rather than promulgate policy. Help each other out and teach one another when we see someone stray (often necessarily) into areas (build systems, languages, interfaces, web design, mathematics) where their skills are weak and ours are strong. I'm no expert, but I've derived a lot of satisfaction from helping several newbies get started developing for Sage - some of whom have since made significant contributions. And I'd really rather see fewer Sage developers refer to an ever increasingly bureaucratic model used for Sage. Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Decorators degrading documentation
(Say that subject three times fast.) I'm looking at a ticket whose main purpose is to apply the @rename_keyword decorator in lots of places, outside of the plot module, where it was first employed. When I build the HTML version of the reference manual, it would appear these functions are now listed simply and universally as foo(*args, **kwds) and any automatic information about the exact nature of the real arguments is lost. If the docstrings were to list this information carefully, at least it would be there, but the docstrings are not always so careful. I believe there is a similar behavior with the @options decorator, though I have not investigated as thoroughly. Again, these options are not always listed in the docstring. I think this explains why sometimes it hard to tell just what plotting options are available. In the case of @rename_keyword there is automatically a deprecation warning. So someday, the decorator will be pulled and the documentation will go back to a more informative version. I find the generic version of the function definitions less than satisfactory. I'd guess it would be had to make Sphinx pickup the more detailed info in these situations? I'd also guess the decorators could maybe manipulate the docstring and inject some information based on the arguments of the decorator? Either way, could the effect of these decorators on the documentation be improved? Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
