[sage-devel] Re: Project: LatticeWithIsometry
Dear Dima, sorry for taking such a long time to answer your question. I'd say it could do a lot of stuff involving over and sublattices. But then it seems like Alex is counting orbits. You'd have to build on top of my code to achieve that. For my purposes it sufficed to consider a single isometry at a time. Best --Simon On Tuesday, September 6, 2016 at 3:08:56 PM UTC+2, Dima Pasechnik wrote: > > > > On Tuesday, September 6, 2016 at 9:20:55 AM UTC, Simon Brandhorst wrote: >> >> Dear all, >> >> I have written some code (toy implementation) in sage. It could be useful >> for other people as well. >> So now I am wondering whether I should make an effort to implement it >> meeting the sage-devel standards. >> How good are the chances for such a project to be included in the sage >> source code? >> >> >> So here is the project: LatticeWithIsometry >> where a lattice L is a free abelian group equipped with a non-degenerate >> symmetric bilinear form (ZZ or QQ valued). An isometry f is a ZZ-Module >> automorphism preserving the bilinear form. >> So we want to model (L,f) >> >> Functionality: >> - constructor for ideal lattices - that is lattices (+isometries) cooked >> up from irreducible reciprocal polynomials (think of the cyclotomic >> polynomials) and their trace forms >> - gluing of lattices. That is taking a direct sum >> (L,f) + (N,g) and getting integral overlattices compatible with (f,g). >> - describing the action of the isometry on sub/super lattices such as the >> dual lattice L' or quotients such as the discriminant group L'/L >> - a method to decide whether a given isometry of a hyperbolic lattice >> preserves a chamber of the positive cone cut out by the root hyperplanes >> (this relates to Weyl groups) >> >> A possible reference for this is: >> http://www.math.harvard.edu/~ctm/papers/home/text/papers/pos/pos.pdf >> >> My personal aim in this is to model integral hodge isometries of K3 >> surfaces or IHSMs. >> > > Sounds like a lot of fun; my latest personal foray into this was doing > some computations in > http://arxiv.org/abs/1604.05836 > (with Lemma 2.11 attributed to me :-)) > and I'm still trying to understand whether I can publish anything > meaningful out of it. > > It would be interesting to what extent your package can do computations in > that paper. > > Just in case, > Dima > > >> >> >> I also wonder how this would fit into the sage world. Should this inherit >> from quadratic forms ? (feels wrong) or is there some lattice class out >> there? >> Since I am new in sage, writing a whole lattice class seems to be too >> much work for me (and well above my level of experience). >> >> There seem to have been previous discussions about lattices e.g. >> >> Discussion in Sage devel: >> >> >> https://groups.google.com/forum/#!searchin/sage-devel/lattice|sort:relevance/sage-devel/OO0ADcuraqE/mUG5_UrYFD4J >> and >> >> https://groups.google.com/forum/#!searchin/sage-devel/lattice$20-poset|sort:relevance/sage-devel/KTmqIcav9e4/wWdiQ71PWVYJ >> >> There also seem to have been previous attempts for implementing lattices >> such as >> https://trac.sagemath.org/ticket/11940 >> https://trac.sagemath.org/ticket/15976 >> >> >> What has happened to them? >> >> Or the rather incomplete FreeQuadraticModule >> >> http://doc.sagemath.org/html/en/reference/modules/sage/modules/free_quadratic_module.html >> which claims to have non trivial functionality over ZZ - I couldn't find >> any. >> >> >> >> Simon >> > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: LatticeWithIsometry
On Tuesday, September 6, 2016 at 11:20:55 AM UTC+2, Simon Brandhorst wrote: > > Dear all, > Dear Simon, > > I have written some code (toy implementation) in sage. It could be useful > for other people as well. > That is nice! I am sure it could be useful to other. > So now I am wondering whether I should make an effort to implement it > meeting the sage-devel standards. > Of course you should. The main reason being that your research will benefit from having doctested and documented code: you will trust your code. > How good are the chances for such a project to be included in the sage > source code? > I have seen so many times modules trying to get into Sage with difficulty for bad and also for good reasons. Good reasons being that for a module to get into Sage, it needs to be mature (changing its interface requires deprecation warnings after it gets into sage...) What I would strongly suggest you to do is to create your own pip installable package and share its existence to sage-devel. This will make it easy for people to try your code, easy for you to change its interface if you want, including backward incompatible changes... The question of merging the code into sage will come by itself later once your code and its interface becomes stable, once your code meets the sage-devel standards (if it happens that you have time to do so: the best thing being to write code directly meeting the sage standards that being said) and more importantly once the community has decided that your code must live longer than yourself working on this project. Cheers! Sébastien Labbé -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: LatticeWithIsometry
O.K. It seems there is some functionality for positive definite lattices in https://trac.sagemath.org/ticket/15976 and it hides in the sage source :). However I could not find anything for Indefinite "lattices". On Tuesday, September 6, 2016 at 11:20:55 AM UTC+2, Simon Brandhorst wrote: > > Dear all, > > I have written some code (toy implementation) in sage. It could be useful > for other people as well. > So now I am wondering whether I should make an effort to implement it > meeting the sage-devel standards. > How good are the chances for such a project to be included in the sage > source code? > > > So here is the project: LatticeWithIsometry > where a lattice L is a free abelian group equipped with a non-degenerate > symmetric bilinear form (ZZ or QQ valued). An isometry f is a ZZ-Module > automorphism preserving the bilinear form. > So we want to model (L,f) > > Functionality: > - constructor for ideal lattices - that is lattices (+isometries) cooked > up from irreducible reciprocal polynomials (think of the cyclotomic > polynomials) and their trace forms > - gluing of lattices. That is taking a direct sum > (L,f) + (N,g) and getting integral overlattices compatible with (f,g). > - describing the action of the isometry on sub/super lattices such as the > dual lattice L' or quotients such as the discriminant group L'/L > - a method to decide whether a given isometry of a hyperbolic lattice > preserves a chamber of the positive cone cut out by the root hyperplanes > (this relates to Weyl groups) > > A possible reference for this is: > http://www.math.harvard.edu/~ctm/papers/home/text/papers/pos/pos.pdf > > My personal aim in this is to model integral hodge isometries of K3 > surfaces or IHSMs. > > > I also wonder how this would fit into the sage world. Should this inherit > from quadratic forms ? (feels wrong) or is there some lattice class out > there? > Since I am new in sage, writing a whole lattice class seems to be too much > work for me (and well above my level of experience). > > There seem to have been previous discussions about lattices e.g. > > Discussion in Sage devel: > > > https://groups.google.com/forum/#!searchin/sage-devel/lattice|sort:relevance/sage-devel/OO0ADcuraqE/mUG5_UrYFD4J > and > > https://groups.google.com/forum/#!searchin/sage-devel/lattice$20-poset|sort:relevance/sage-devel/KTmqIcav9e4/wWdiQ71PWVYJ > > There also seem to have been previous attempts for implementing lattices > such as > https://trac.sagemath.org/ticket/11940 > https://trac.sagemath.org/ticket/15976 > > > What has happened to them? > > Or the rather incomplete FreeQuadraticModule > > http://doc.sagemath.org/html/en/reference/modules/sage/modules/free_quadratic_module.html > which claims to have non trivial functionality over ZZ - I couldn't find > any. > > > > Simon > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: LatticeWithIsometry
On Tuesday, September 6, 2016 at 9:20:55 AM UTC, Simon Brandhorst wrote: > > Dear all, > > I have written some code (toy implementation) in sage. It could be useful > for other people as well. > So now I am wondering whether I should make an effort to implement it > meeting the sage-devel standards. > How good are the chances for such a project to be included in the sage > source code? > > > So here is the project: LatticeWithIsometry > where a lattice L is a free abelian group equipped with a non-degenerate > symmetric bilinear form (ZZ or QQ valued). An isometry f is a ZZ-Module > automorphism preserving the bilinear form. > So we want to model (L,f) > > Functionality: > - constructor for ideal lattices - that is lattices (+isometries) cooked > up from irreducible reciprocal polynomials (think of the cyclotomic > polynomials) and their trace forms > - gluing of lattices. That is taking a direct sum > (L,f) + (N,g) and getting integral overlattices compatible with (f,g). > - describing the action of the isometry on sub/super lattices such as the > dual lattice L' or quotients such as the discriminant group L'/L > - a method to decide whether a given isometry of a hyperbolic lattice > preserves a chamber of the positive cone cut out by the root hyperplanes > (this relates to Weyl groups) > > A possible reference for this is: > http://www.math.harvard.edu/~ctm/papers/home/text/papers/pos/pos.pdf > > My personal aim in this is to model integral hodge isometries of K3 > surfaces or IHSMs. > Sounds like a lot of fun; my latest personal foray into this was doing some computations in http://arxiv.org/abs/1604.05836 (with Lemma 2.11 attributed to me :-)) and I'm still trying to understand whether I can publish anything meaningful out of it. It would be interesting to what extent your package can do computations in that paper. Just in case, Dima > > > I also wonder how this would fit into the sage world. Should this inherit > from quadratic forms ? (feels wrong) or is there some lattice class out > there? > Since I am new in sage, writing a whole lattice class seems to be too much > work for me (and well above my level of experience). > > There seem to have been previous discussions about lattices e.g. > > Discussion in Sage devel: > > > https://groups.google.com/forum/#!searchin/sage-devel/lattice|sort:relevance/sage-devel/OO0ADcuraqE/mUG5_UrYFD4J > and > > https://groups.google.com/forum/#!searchin/sage-devel/lattice$20-poset|sort:relevance/sage-devel/KTmqIcav9e4/wWdiQ71PWVYJ > > There also seem to have been previous attempts for implementing lattices > such as > https://trac.sagemath.org/ticket/11940 > https://trac.sagemath.org/ticket/15976 > > > What has happened to them? > > Or the rather incomplete FreeQuadraticModule > > http://doc.sagemath.org/html/en/reference/modules/sage/modules/free_quadratic_module.html > which claims to have non trivial functionality over ZZ - I couldn't find > any. > > > > Simon > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Project: add hundreds of contributors to sage
Replying to an old thread I realized I'd starred... On Thu, May 29, 2014 at 6:48 PM, kcrisman kcris...@gmail.com wrote: Well, I am thankful that my rant led to some pretty substantive discussion. Here let me summarize some thoughts. A) +1 to having something where a github-like editing thing works. I've used this at least once with matplotlib. My beef with github is orthogonal to the web interface piece. If there is a good workflow where we can direct contributors to make smaller edits on the github mirror and they'll be taken care of, that's great. All pull requests on github turn into tickets, so this easy web interface flow works now. B) I didn't realize that the release manager commits were separate from the author ones. That is strange to me, but I guess it's there. Nonetheless, I think that the vast majority of ticket descriptions are (or at least start as) fairly half-baked notions of what could be added or fixed, and are entirely inappropriate for a commit message to siphon through in git log. Especially since they are so long compared to most commit messages (and not for good reasons). This is an awareness issue--ticket descriptions should be well written descriptions of what's in the ticket, and now there's further motivation to do so as they're also stored in the git log when the ticket in question is closed. C) I haven't heard any -1's to Merged in being resuscitated, so maybe that should really happen. [More thoughts: Robert B: I think Travis' point about doing it near the release time is so that people know where to start from. My whole trouble earlier today ended up being because, since it said closed, I assumed the Maxima upgrade HAD to be in the latest beta - which it wasn't. And several git pull attempts in my develop branch did nothing, since develop is still at 6.3.beta2 as of this writing (on github at least). As it turned out, it wasn't based on the right ticket, so I guess that could have been needs work, but it *says* Depends on #13973 so in the old workflow that should have been enough (install #13973, then install this one). I feel like this is closely related.] You can still have depends on. The nice thing is that if you merge a depends on that's already in it's a no-op. D) Patchbot? What patchbot? At least the colorings aren't working right now, it seems. But I would love to trust that again and not have to rebuild trivial things. Just checked, it's still up. There may eventually be a replacement, but if you want tickets to get updated faster, run a patchbot client on your own machine. (You can even configure it to test your tickets/favorite category first.) E) Please everyone let's put Trac #s back in the commit messages, then, if the immutability is a barrier there. Some of the most recent ones are completely mystifying. And then it will be possible to figure out where the new code IS in the tree, as opposed to just the merges which can be patchbombs. -- 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: Project: add hundreds of contributors to sage
I hope no one minds my resurrecting this, but after having spent a lot of time waiting for Sage to rebuild itself 3 or 4 times, I just discovered this hint, and would like to suggest it make its way onto http://www.sagemath.org/doc/developer/trac.html#section-review-patches, and all other similar pages in the developer guide. If that's already in the works, then never mind me; just carry on... john perry On Saturday, May 31, 2014 8:33:14 AM UTC-5, Volker Braun wrote: I've implemented a version of this now. From the README: * Review tickets with minimal recompiling. This assumes that you are currently on the develop branch, that is, the latest beta. Just checking out an older ticket would most likely reset the Sage tree to an older version, so you would have to compile older versions of packages to make it work. Instead, you can create an anonymous (detached HEAD) merge of the ticket and the develop branch:: $ git trac try 12345 Volker, is this in the current git-trac? -- 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: Project: add hundreds of contributors to sage
yes it is... On Wednesday, August 27, 2014 1:26:02 PM UTC+1, kcrisman wrote: I hope no one minds my resurrecting this, but after having spent a lot of time waiting for Sage to rebuild itself 3 or 4 times, I just discovered this hint, and would like to suggest it make its way onto http://www.sagemath.org/doc/developer/trac.html#section-review-patches, and all other similar pages in the developer guide. If that's already in the works, then never mind me; just carry on... john perry On Saturday, May 31, 2014 8:33:14 AM UTC-5, Volker Braun wrote: I've implemented a version of this now. From the README: * Review tickets with minimal recompiling. This assumes that you are currently on the develop branch, that is, the latest beta. Just checking out an older ticket would most likely reset the Sage tree to an older version, so you would have to compile older versions of packages to make it work. Instead, you can create an anonymous (detached HEAD) merge of the ticket and the develop branch:: $ git trac try 12345 Volker, is this in the current git-trac? -- 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: Project: add hundreds of contributors to sage
On Wednesday, August 27, 2014 8:33:24 AM UTC-4, Volker Braun wrote: yes it is... But it's not even in http://www.sagemath.org/doc/developer/git_trac.html Presumably the development of git trac should be pretty tightly connected to that document. We keep telling people to read it, after all. -- 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: Project: add hundreds of contributors to sage
You don't need to know about that particular subcommand to develop, its just a bandaid until we have a better build system. There are plenty other git concepts and subcommands that can definitely be useful in certain circumstances, but aren't really necessary to work on a ticket. On Wednesday, August 27, 2014 4:08:23 PM UTC+1, kcrisman wrote: On Wednesday, August 27, 2014 8:33:24 AM UTC-4, Volker Braun wrote: yes it is... But it's not even in http://www.sagemath.org/doc/developer/git_trac.html Presumably the development of git trac should be pretty tightly connected to that document. We keep telling people to read it, after all. -- 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: Project: add hundreds of contributors to sage
I hope no one minds my resurrecting this, but after having spent a lot of time waiting for Sage to rebuild itself 3 or 4 times, I just discovered this hint, and would like to suggest it make its way onto http://www.sagemath.org/doc/developer/trac.html#section-review-patches, and all other similar pages in the developer guide. If that's already in the works, then never mind me; just carry on... john perry On Saturday, May 31, 2014 8:33:14 AM UTC-5, Volker Braun wrote: I've implemented a version of this now. From the README: * Review tickets with minimal recompiling. This assumes that you are currently on the develop branch, that is, the latest beta. Just checking out an older ticket would most likely reset the Sage tree to an older version, so you would have to compile older versions of packages to make it work. Instead, you can create an anonymous (detached HEAD) merge of the ticket and the develop branch:: $ git trac try 12345 This will only touch files that are really modified by the ticket. In particular, if only Python files are changed by the ticket (which is true for most tickets) then you just have to run `sage -b` to rebuild the Sage library. When you are finished reviewing, just checkout a named branch. For example:: $ git checkout develop If you want to edit the ticket branch (that is, add additional commits) you cannot use `git trac try`. You must use `git trac checkout` to get the actual ticket branch as a starting point. On Saturday, May 31, 2014 2:31:16 AM UTC+1, Dima Pasechnik wrote: I asked for essentially this functionality to be in git trac, see https://github.com/sagemath/git-trac-command/issues/13 -- 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: Project: add hundreds of contributors to sage
On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote: everything, as for rebuilding docs nothing short of make distclean make works. sage -sync-build sage -b make doc-clean make doc almost always works (there has been maybe one case where it didn't, and that was pretty f-ed up). -- 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: Project: add hundreds of contributors to sage
On Friday, May 30, 2014 5:11:08 PM UTC+1, kcrisman wrote: Right, but the problem is that currently I am uploading it ;-) Which is exactly why it ought to be difficult to make wrong-way merges in a branch, so that you can't accidentally/misguidedly upload without understanding enough of git to know that it is wrong. -- 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: Project: add hundreds of contributors to sage
I've implemented a version of this now. From the README: * Review tickets with minimal recompiling. This assumes that you are currently on the develop branch, that is, the latest beta. Just checking out an older ticket would most likely reset the Sage tree to an older version, so you would have to compile older versions of packages to make it work. Instead, you can create an anonymous (detached HEAD) merge of the ticket and the develop branch:: $ git trac try 12345 This will only touch files that are really modified by the ticket. In particular, if only Python files are changed by the ticket (which is true for most tickets) then you just have to run `sage -b` to rebuild the Sage library. When you are finished reviewing, just checkout a named branch. For example:: $ git checkout develop If you want to edit the ticket branch (that is, add additional commits) you cannot use `git trac try`. You must use `git trac checkout` to get the actual ticket branch as a starting point. On Saturday, May 31, 2014 2:31:16 AM UTC+1, Dima Pasechnik wrote: I asked for essentially this functionality to be in git trac, see https://github.com/sagemath/git-trac-command/issues/13 -- 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: Project: add hundreds of contributors to sage
There is nothing wrong with merges * if you need them * if the original branch is the first parent. Doing it the wrong way makes the history more difficult to understand, and we shouldn't teach or facilitate that antipattern. On Saturday, May 31, 2014 2:35:30 PM UTC+1, Nathann Cohen wrote: Yo ! If you want to edit the ticket branch (that is, add additional commits) you cannot use `git trac try`. You must use `git trac checkout` to get the actual ticket branch as a starting point. Why can't you add commits after a merge ? I do this all the time O_o 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: Project: add hundreds of contributors to sage
There is nothing wrong with merges * if you need them * if the original branch is the first parent. Doing it the wrong way makes the history more difficult to understand, and we shouldn't teach or facilitate that antipattern. That's my question from last november : https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/e9RMBUvl7ygJ that's your answer from then : https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/sDoYyZOQHY0J By the way, given that with this trick I can avoi recompiling Sage for hours, I still think that it is the right way to work. 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: Project: add hundreds of contributors to sage
By the way I improved this gtmp method since, so that it prepares a
commit message which makes the history clearer (at least to a human)
function gtmp
{
cd ~/sage
git checkout d
rel=$(git log --oneline d ^d~1 | sed s/.*\ //g)
tn=$(echo $1 | grep -o [0-9]*)
echo ===
echo trac #$tn: Merged with $rel
echo ===
git branch -D tmp
git checkout -b tmp d
git pull trac $1
}
Example :
~/sage$ gtmp u/ncohen/16347
Switched to branch 'd'
Your branch is up-to-date with 'trac/develop'.
===
trac #16347: Merged with 6.3.beta2
===
Deleted branch tmp (was 27f6c9a).
Switched to a new branch 'tmp'
From trac.sagemath.org:sage
* branchu/ncohen/16347 - FETCH_HEAD
And then I copy/paste this commit message... As I found no easy way to
make it the default commit message :-)
Nathann
On 31 May 2014 15:52, Nathann Cohen nathann.co...@gmail.com wrote:
There is nothing wrong with merges
* if you need them
* if the original branch is the first parent.
Doing it the wrong way makes the history more difficult to understand, and
we shouldn't teach or facilitate that antipattern.
That's my question from last november :
https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/e9RMBUvl7ygJ
that's your answer from then :
https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/sDoYyZOQHY0J
By the way, given that with this trick I can avoi recompiling Sage for
hours, I still think that it is the right way to work.
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: Project: add hundreds of contributors to sage
Volker Braun wrote: On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote: everything, as for rebuilding docs nothing short of make distclean make works. sage -sync-build sage -b make doc-clean make doc almost always works (there has been maybe one case where it didn't, and that was pretty f-ed up). Did someone meanwhile track down what exactly went wrong / broke docbuilding (such that it hangs)? (I also deleted all temporary folders, $DOT_SAGE, and the Cython cache, ran 'sage -ba', reinstalled Sphinx and later even Python and all packages that depend on it... to no avail B) .) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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: Project: add hundreds of contributors to sage
And which part of it being a common assumption among git users that the first merge commit points back to the branch did you not understand? On Saturday, May 31, 2014 2:52:15 PM UTC+1, Nathann Cohen wrote: That's my question from last november : https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/e9RMBUvl7ygJ that's your answer from then : https://groups.google.com/d/msg/sage-git/Nokq-kVfONc/sDoYyZOQHY0J -- 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: Project: add hundreds of contributors to sage
On Saturday, May 31, 2014 3:14:41 PM UTC+1, leif wrote: Did someone meanwhile track down what exactly went wrong / broke docbuilding (such that it hangs)? I can't reproduce it, works for me. -- 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: Project: add hundreds of contributors to sage
On 2014-05-31, Volker Braun vbraun.n...@gmail.com wrote: On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote: everything, as for rebuilding docs nothing short of make distclean make works. sage -sync-build sage -b make doc-clean make doc almost always works (there has been maybe one case where it didn't, and that was pretty f-ed up). Volker, feel free to borrow my apparently totally f-ed up laptop, as on it this just doesn't work for months, when I am back from Philly, and have a look... Cheers, Dima -- 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: Project: add hundreds of contributors to sage
If I understand your complaint correctly, the problem is that
re-compiling after switching branches is too expensive.
You *NEVER* need to recompile everything when switching branches. There is
a trick : you should never checkout a branch but instead pull it (merge it)
with your current version of Sage.
This way, you never have to checkout a branch of Sage which is based on an
old release.
This is the gtmp function I use for almost everything (and in particular
for review). It deletes then create a tmp branch in git containing the
remove branch you are interested in (assuming that the local branch 'd'
points toward the release that you use, i.e. develop in my case)
function gtmp
{
cd ~/sage
git checkout d
git branch -D tmp
git checkout -b tmp d
git pull trac $1
}
I only type gtmp public/branch_name and I can review/test a branch, no
recompilation involved as only the files changes in the branch have been
modified.
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: Project: add hundreds of contributors to sage
On Friday, May 30, 2014 2:19:24 AM UTC-4, Nathann Cohen wrote:
If I understand your complaint correctly, the problem is that
re-compiling after switching branches is too expensive.
You *NEVER* need to recompile everything when switching branches. There is
a trick : you should never checkout a branch but instead pull it (merge it)
with your current version of Sage.
Hmm, I was kind of going on the avoid unnecessary merges thing. Also I
am scared about merge conflicts, which I do not know how to handle because
I don't have a merge editor, or maybe I do and don't know it. But this
is helpful to know, thanks.
This is the gtmp function I use for almost everything (and in particular
for review). It deletes then create a tmp branch in git containing the
remove branch you are interested in (assuming that the local branch 'd'
points toward the release that you use, i.e. develop in my case)
Volker, is there some similar functionality in git trac?
function gtmp
{
cd ~/sage
git checkout d
git branch -D tmp
git checkout -b tmp d
git pull trac $1
}
I only type gtmp public/branch_name and I can review/test a branch, no
recompilation involved as only the files changes in the branch have been
modified.
Well, if there are .pyx files or pkg changes... but point taken. Thanks!
--
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: Project: add hundreds of contributors to sage
On Friday, May 30, 2014 1:18:43 PM UTC+1, kcrisman wrote: Hmm, I was kind of going on the avoid unnecessary merges thing. You can of course do whatever you want on your computer as long as you don't upload it... Also I am scared about merge conflicts, which I do not know how to handle because I don't have a merge editor You don't need anything special, imho the standard git procedure of adding conflict markers and editing that file is perfectly fine (and what I use most of the time even though I have some special merge editors). Volker, is there some similar functionality in git trac? No (it doesn't really do anything different as far as communicating with trac goes), but we could easily add it... -- 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: Project: add hundreds of contributors to sage
Hmm, I was kind of going on the avoid unnecessary merges thing. You can of course do whatever you want on your computer as long as you don't upload it... Right, but the problem is that currently I am uploading it ;-) -- 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: Project: add hundreds of contributors to sage
Just got a Github Education account today for my lab, which led me to look a bit more at their site. This video is relevant: https://education.github.com/stories#UCBerkeley If extra eyes were all that were necessary, there would be no long-standing mathematical conjectures. What is needed is both extra eyes and a community welcoming of new ideas. That's what the polymath projects do, and they have been quite successful so far, proving results that had vexed Fields medalists. Paul Paul-Olivier Dehaye SNF Assistant Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Thu, May 29, 2014 at 11:34 AM, Paul-Olivier Dehaye paul-olivier.deh...@math.uzh.ch wrote: Thanks for the thoughtful replies. It's a fine line between being critical of the idea and dismissive of the students. Please everyone limit yourselves to criticizing the idea, as students might come to this thread later. I don't think one should dismiss the students. Look at the Mathworks competition (another thing MATLAB does!), as it is described in Nielsen's book Reinventing Dicovery. There is a history there of microcontributions on code leading to optimised code. There is also two assumptions in your emails: 1) that they will all have just learned python: the course might be just the right blend of mathematics and CS so that some participants actually a background in python. On top, one can modulate the difficulty progressively to make sure to attract some students who actually have a strong python background already (in MOOCs, there are always some experts lurking) 2) that I would let them choose the topic. Not so. For the specifics of how the course will be run, I need to bring the discussion out of the mailing list. As William points out, small contributions are important (example in docstring) and the process is currently suboptimal. I would add that other small contributions could be important, such as semantic information coming from professional mathematicians who have just learned utter basics of python, to have a mere sense of how the decorator they have just added will affect the method itself. For this, existing annotation tools suffice. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Thu, May 29, 2014 at 3:40 AM, rjf fate...@gmail.com wrote: On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote: Again, in the big wave of emails, this one also got misdirected: Hi everyone, I am looking for people who want to help me, in one way or another, bring hundreds of new first time contributors to sage. If I do not find enough partners, I will look for other more suitable python-based projects. The idea would be quite simple: teach python programming around some mathematics (such as combinatorics) and simultaneously produce code that would be useful for research and worth including in sage. Two catches: students are given individual problems to work on, and the course is taught on Coursera. Motivation for the students would come in various ways: internships, for instance. Quality of the code would be ensured by peer-testing the programs. William Stein has already responded to the major issues regarding the Sage development process, but I would just like to comment on this particular aspect of peer-testing. Having two or more people who have just learned python and do not know much mathematics peer review code does not lead to much of an ensured level of quality. Certainly there are other clumps of python aggregating code that are not as daunting as Sage. Numpy and Sympy come to mind, but I doubt that they would really relish a MOOC's-worth of naive contributions, when it is pretty much guaranteed that a very high percentage would, under careful scrutiny, be duplicative, erroneous, poorly coded, or all three. It's a nice thought to get many hands to write code free. But impractical, in spite of Eric Raymond's Cathedral and Bazaar essay. All bugs are shallow with enough eyes (or whatever the wording is...) is perhaps plausible if the system is itself shallow (like linux). Where I differ with Raymond is I think there are not enough eyes on the planet to make some bugs shallow in a deep system-- one that does (say) sophisticated symbolic mathematics. If extra eyes were all that were necessary, there would be no long-standing mathematical conjectures. If you do not know what Coursera or MOOCs are, you are welcome to take my upcoming course https://class.coursera.org/massiveteaching-001 If you are interested to play with a MOOC platform yourself, you might want first to watch the videostream of the 2pm-3pm slot of this conference I am co-organising on
[sage-devel] Re: Project: add hundreds of contributors to sage
On 2014-05-30, Nathann Cohen nathann.co...@gmail.com wrote: If I understand your complaint correctly, the problem is that re-compiling after switching branches is too expensive. You *NEVER* need to recompile everything when switching branches. There is a trick : you should never checkout a branch but instead pull it (merge it) with your current version of Sage. +1 On the other hand, as long as the docbuild is broken, and as long as we care about docs being bildable, one often has to recompile everything, as for rebuilding docs nothing short of make distclean make works. -- 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: Project: add hundreds of contributors to sage
On 2014-05-30, kcrisman kcris...@gmail.com wrote: On Friday, May 30, 2014 2:19:24 AM UTC-4, Nathann Cohen wrote: If I understand your complaint correctly, the problem is that re-compiling after switching branches is too expensive. You *NEVER* need to recompile everything when switching branches. There is a trick : you should never checkout a branch but instead pull it (merge it) with your current version of Sage. Hmm, I was kind of going on the avoid unnecessary merges thing. Also I am scared about merge conflicts, which I do not know how to handle because I don't have a merge editor, or maybe I do and don't know it. But this is helpful to know, thanks. This is the gtmp function I use for almost everything (and in particular for review). It deletes then create a tmp branch in git containing the remove branch you are interested in (assuming that the local branch 'd' points toward the release that you use, i.e. develop in my case) Volker, is there some similar functionality in git trac? I asked for essentially this functionality to be in git trac, see https://github.com/sagemath/git-trac-command/issues/13 -- 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: Project: add hundreds of contributors to sage
Thanks for the thoughtful replies. It's a fine line between being critical of the idea and dismissive of the students. Please everyone limit yourselves to criticizing the idea, as students might come to this thread later. I don't think one should dismiss the students. Look at the Mathworks competition (another thing MATLAB does!), as it is described in Nielsen's book Reinventing Dicovery. There is a history there of microcontributions on code leading to optimised code. There is also two assumptions in your emails: 1) that they will all have just learned python: the course might be just the right blend of mathematics and CS so that some participants actually a background in python. On top, one can modulate the difficulty progressively to make sure to attract some students who actually have a strong python background already (in MOOCs, there are always some experts lurking) 2) that I would let them choose the topic. Not so. For the specifics of how the course will be run, I need to bring the discussion out of the mailing list. As William points out, small contributions are important (example in docstring) and the process is currently suboptimal. I would add that other small contributions could be important, such as semantic information coming from professional mathematicians who have just learned utter basics of python, to have a mere sense of how the decorator they have just added will affect the method itself. For this, existing annotation tools suffice. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Thu, May 29, 2014 at 3:40 AM, rjf fate...@gmail.com wrote: On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote: Again, in the big wave of emails, this one also got misdirected: Hi everyone, I am looking for people who want to help me, in one way or another, bring hundreds of new first time contributors to sage. If I do not find enough partners, I will look for other more suitable python-based projects. The idea would be quite simple: teach python programming around some mathematics (such as combinatorics) and simultaneously produce code that would be useful for research and worth including in sage. Two catches: students are given individual problems to work on, and the course is taught on Coursera. Motivation for the students would come in various ways: internships, for instance. Quality of the code would be ensured by peer-testing the programs. William Stein has already responded to the major issues regarding the Sage development process, but I would just like to comment on this particular aspect of peer-testing. Having two or more people who have just learned python and do not know much mathematics peer review code does not lead to much of an ensured level of quality. Certainly there are other clumps of python aggregating code that are not as daunting as Sage. Numpy and Sympy come to mind, but I doubt that they would really relish a MOOC's-worth of naive contributions, when it is pretty much guaranteed that a very high percentage would, under careful scrutiny, be duplicative, erroneous, poorly coded, or all three. It's a nice thought to get many hands to write code free. But impractical, in spite of Eric Raymond's Cathedral and Bazaar essay. All bugs are shallow with enough eyes (or whatever the wording is...) is perhaps plausible if the system is itself shallow (like linux). Where I differ with Raymond is I think there are not enough eyes on the planet to make some bugs shallow in a deep system-- one that does (say) sophisticated symbolic mathematics. If extra eyes were all that were necessary, there would be no long-standing mathematical conjectures. If you do not know what Coursera or MOOCs are, you are welcome to take my upcoming course https://class.coursera.org/massiveteaching-001 If you are interested to play with a MOOC platform yourself, you might want first to watch the videostream of the 2pm-3pm slot of this conference I am co-organising on Tuesday: tinyurl.com/openedx-zurich as it will help you assess the technical challenges. I am looking at a start date for the course of around October-November, and to bring the discussion off the mailing list (to private) so as to keep an element of surprise for the students. Let me know! Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: paulo...@gmail.com twitter: podehaye freenode irc: pdehaye -- 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
[sage-devel] Re: Project: add hundreds of contributors to sage
Hi! Thanks again for your thoughtful comments. I see two different issues arising in this thread. 1) Your desire to have a MOOC teaching Python programming around some mathematics, which might end up contributing to Sage. (Or sympy, or numpy, or Gambit, or ...) That sounds awesome. I think the hardest part of doing this is not specifically the ability or knowledge of students, but the realities of getting everyone up to speed on any larger system and contributing without huge amounts of involvement by the instructor/mentor/peer leader/whatever. I am cautiously optimistic that there is plenty to do in Sage, but without some direction it will not end up being useful. For a great example, see Vincent Knight's GSOC project - there are lots of students who could implement some basic game theory stuff by the end of a course like this, but to have it actually play well with the rest of Sage, classes, and fit in with (say) 50 other MOOCers' contributions would tax even the most patient overseer. Which is why having it be a GSOC project is a very good idea. And here is one place I agree with rjf - Raymond is very insightful, but does not have a monopoly on insights regarding open source or software development. If you don't know calculus and Lisp, you can't help with large bits of Maxima (hence Sage), period, no matter how talented otherwise. For me personally, I would have to see a syllabus (however archaic that may seem) and the typical intro level for the students, though such a thing probably doesn't exist. Given that MOOC dropout rates are pretty high, and that it will probably be hard to figure out ahead of time what a given student brings to the table, one would need a very large collection of things to look at indeed. Unless one had a far smaller set of carefully selected projects, and then let a few dozen MOOCers at each of them, and then perhaps as a final project had them decide which of these was best... that's just a brainstorm, though. Having given my caveats, I want to reiterate that it sounds awesome, and IS doable, but probably with more work than one thinks. And I'll put my money where my mouth is and volunteer to chat personally at some point this summer regarding some possible projects - though again, it may be surprising just how involved even very simple things end up getting in production, as I've experienced with some students I've worked with on contributing to Sage. 2) There is a higher burden to development than needs be. This is always true to some extent, of course, but especially for documentation this doesn't have to be the case. William summarized this well. In particular, the git switch was supposedly going to make this sort of contribution easier, but as far as I can tell, it is no easier, and maybe harder, than with the previously workflow. See a postscript for a rant about this. Anyway, this is something that will be an issue for contributing to any longer-term project, I think, in nontrivial ways. - kcrisman -- 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: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 8:49 AM, kcrisman kcris...@gmail.com wrote: Hi! Thanks again for your thoughtful comments. I see two different issues arising in this thread. 1) Your desire to have a MOOC teaching Python programming around some mathematics, which might end up contributing to Sage. (Or sympy, or numpy, or Gambit, or ...) That sounds awesome. +1 I think the hardest part of doing this is not specifically the ability or knowledge of students, but the realities of getting everyone up to speed on any larger system and contributing without huge amounts of involvement by the instructor/mentor/peer leader/whatever. I am cautiously optimistic that there is plenty to do in Sage, but without some direction it will not end up being useful. For a great example, see Vincent Knight's GSOC project - there are lots of students who could implement some basic game theory stuff by the end of a course like this, but to have it actually play well with the rest of Sage, classes, and fit in with (say) 50 other MOOCers' contributions would tax even the most patient overseer. Which is why having it be a GSOC project is a very good idea. And here is one place I agree with rjf - Raymond is very insightful, but does not have a monopoly on insights regarding open source or software development. If you don't know calculus and Lisp, you can't help with large bits of Maxima (hence Sage), period, no matter how talented otherwise. For me personally, I would have to see a syllabus (however archaic that may seem) and the typical intro level for the students, though such a thing probably doesn't exist. Given that MOOC dropout rates are pretty high, and that it will probably be hard to figure out ahead of time what a given student brings to the table, one would need a very large collection of things to look at indeed. Unless one had a far smaller set of carefully selected projects, and then let a few dozen MOOCers at each of them, and then perhaps as a final project had them decide which of these was best... that's just a brainstorm, though. Having given my caveats, I want to reiterate that it sounds awesome, and IS doable, but probably with more work than one thinks. And I'll put my money where my mouth is and volunteer to chat personally at some point this summer regarding some possible projects - though again, it may be surprising just how involved even very simple things end up getting in production, as I've experienced with some students I've worked with on contributing to Sage. Though I wouldn't expect everyone to end up with a workable contribution, it's not a stretch to expect at least a handful of ready-to-incorporate improvements. 2) There is a higher burden to development than needs be. This is always true to some extent, of course, but especially for documentation this doesn't have to be the case. William summarized this well. There is so much bureaucracy. I just keep thinking back to the 22 easy steps to contribute to Sage. In particular, the git switch was supposedly going to make this sort of contribution easier, but as far as I can tell, it is no easier, and maybe harder, than with the previously workflow. See a postscript for a rant about this. I think that's because we took our trac-based (and patch-based) workflow and just plugged git in. I don't know if we want to open this discussion now, but it's certainly worth revisiting (starting with defining what our goals are rather than what our tools are). But now that we're on git a pull request is 99% of what a ticket is (specifically, an annotated point to a particular git branch/commit that needs review) and we should seriously consider accepting that format for contributions. Anyway, this is something that will be an issue for contributing to any longer-term project, I think, in nontrivial ways. - kcrisman -- 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: Project: add hundreds of contributors to sage
Please excuse the following rant. As usual, it is ill-informed, and if some of the points are due to ignorance, I have no problem with that being pointed out. But from reading the lists, I'm not the only one experiencing difficulty with this sort of thing. At the very least I think it shows it's not that easy to do everything right now. rant Git workflow. The goal was to reduce work for some developers and make things more modular, but in fact what happens is that people are basing their branches on all kinds of different starting points, forcing constant recompilation for even the most trivial changes. I'm told ccache will help with this, but it's still not in the developer guide, and I'm not sure it will help with [s]pkgs anyway, which also change frequently. In addition, a web-based interface just like github pull requests was promised, but I don't see it. Since we don't use the github version to allow people to just edit (see e.g. https://github.com/grant/sage/commit/27c97d376a956a05c6e4abd97102f80195bda4c0 for one request that apparently has been ignored), we are actually in a *worse* place than we were with patches, where at least those could be applied more or less independently of the state of Sage. As another example, in attempting to review one patch which relies upon the new Maxima update: where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less both do not tell me that in fact, even though Trac says closed, #13973 apparently is not yet in a merged release, and so I just wasted a lot of time figuring that out. Since Merged in is no longer updated. You would think that I could learn this by doing $ git log | grep 13973 but since Trac #s are no longer in commit messages, that isn't foolproof either. And indeed, the standard output of git log is kind of scary, because while some entries look like this, roughly as in the old one commit 3ea4f9bfc3c1acb6cb9eaa8e7a8ffa41779a6181 Author: XYZ Date: Thu May 22 08:37:36 2014 +0200 16199: documentation cosmetics others look like this commit e9352062ad7fedbe00ad62d397672203824e0267 Merge: cc54f6e 80e319d Author: XYZ Date: Thu May 22 08:01:19 2014 +0200 Merge branch 'develop' into t/16199/improve_docs__add_doctests_in_power_seri * develop: (606 commits) Updated Sage version to 6.3.beta1 trac #16237: Typos Use lazy_import instead Use point collections more directly. trac #15036: fix late import of is_Matrix to avoid startup problems Fixes to normal_form_pc to work with point collections properly. Fixed failing doctests. trac #16277: A typo minor fixes Trac 15099: numeric evaluation of zetaderiv trac 16211: Review reviewer patch. Added a category parameter to Module change raise syntax to python3 style and still others look like this commit 9a4b0b83fa06a113c485f22f37af02c24ef35e90 Merge: f4cbb5f b8fea1c Author: Release Manager rele...@sagemath.org Date: Wed May 21 16:40:31 2014 +0100 Trac #15921: work around Maxima fpprintprec bug and other ARM-specific probl [https://groups.google.com/d/msg/sage-devel/oRpkswzpK38/rNVbVN2RyEcJ Maxima uses CL FORMAT function wrongly], resulting in outputting wrong number of digits for floats (one extra), and contradicting its own manual on fpprintprec. In particular it outputs too many digits on ix86 and ix86_64, which got in Sage's doctests. As a result, doctests fail on ARM. The fixes are to convert the results into `RealField(prec)`, with appropriate `prec` (at least 54, or sometimes more). This ticket also fixes ARM-specific numerical noise stemming from various other upstream problems, such as `eglibc` loss of precision in `lgamma`. I don't know why the description of a ticket is ending up in the log. We want a description of what actually was done, and the description in the ticket is often full of brainstorming etc. Oh, and this all assumes that one knows about pipes and grep. Perhaps git trac deals with these kinds of situations, which is great, but one shouldn't really have to use git or the command line at all to find out some of this information. Particularly not as a beginner. Anyway, in order to use git properly to do trivial change, one still really has to learn at least as much as before with hg_sage or hg or sage -dev or whatever the flavor of the month is. For instance, for this one I guess I need to first do #13973, and then somehow add #13712 on top of it - which sounds like a more advanced operation of merging, and we are many times warned not to do unnecessary merges. A hint from Travis S. and some Google helped me eventually figure out how to do this but it's certainly no easier than what I would have done before. /rant Okay, done ranting, and foolish stuff it probably was. At first I thought this wasn't all
[sage-devel] Re: Project: add hundreds of contributors to sage
I never really have had a problem with the new workflow (in fact, I actually prefer it to the old one). However I had a good command of git coming into this and read the git the hard way. So my 2 cents would be to have developers spend time learning git properly instead of using the dev scripts (I think this is a useful skill beyond Sage development). However I do see your point that this is an extra barrier to Sage development since IMO one generally needs to know more about git than about Hg in order to development. 1) Put Merged in back. +1 I'd also suggest not closing/merging tickets until shortly before releasing the next beta. 2) Fix just how much crazy stuff shows up in git log, presumably by merging things differently or with different messages or something. I don't think there's much we can do about this considering how git workflows are suppose to work and since the develop does have everything merged in. 4) Get http://trac.sagemath.org/ticket/14372 in. +1 Best, 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: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 10:01 AM, kcrisman kcris...@gmail.com wrote: Please excuse the following rant. As usual, it is ill-informed, and if some I appreciate it, and I'm glad we're having this discussion. (It's a rant, but it isn't a flame. Yeah!) of the points are due to ignorance, I have no problem with that being pointed out. But from reading the lists, I'm not the only one experiencing difficulty with this sort of thing. At the very least I think it shows it's not that easy to do everything right now. rant Git workflow. The goal was to reduce work for some developers and make things more modular, but in fact what happens is that people are basing their branches on all kinds of different starting points, forcing constant recompilation for even the most trivial changes. I'm told ccache will help with this, but it's still not in the developer guide, and I'm not sure it will help with [s]pkgs anyway, which also change frequently. There were arguments last year by various people that our patch-based workflow was bad, at least as opposed to using branches. There was little in the way of arguments back for patches. I personally wasn't really paying attention then, and I frankly didn't know which was better, having only had experience with patches.I'm glad that you're presenting some of the arguments below in favor of the value of a more patches-based workflow. I recently listened to an interview with the release manager for the stable linux kernel. Linux is of course a big project that uses git -- in fact, as we all know, Linus invented git for Linux development. They use *patches* rather than branches. In fact, their workflow is email + patches.He argues in the interview (in response to questions, etc.) that this is far more efficient than the branch model. Evidently, git has extremely good support for sending patches via email and applying them from email (at least in a local mail spool). Another project I'm involved in called bup (https://github.com/bup/bup) does the same thing -- all code contributions are patches to the mailing list, so I've seen this work. I'm not arguing for replacing trac by patches to a mailing list! I'm just pointing out that some people's assertions that using patches instead of branches is not properly using git can't be right, since the Linux kernel devs use of git is just as proper as anybody else's.Basically, I'm trying to argue that there is merit to your rant. In addition, a web-based interface just like github pull requests was promised, but I don't see it. Since we don't use the github version to allow people to just edit (see e.g. https://github.com/grant/sage/commit/27c97d376a956a05c6e4abd97102f80195bda4c0 for one request that apparently has been ignored), we are actually in a *worse* place than we were with patches, where at least those could be applied more or less independently of the state of Sage. As another example, in attempting to review one patch which relies upon the new Maxima update: where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less both do not tell me that in fact, even though Trac says closed, #13973 apparently is not yet in a merged release, and so I just wasted a lot of time figuring that out. Since Merged in is no longer updated. You would think that I could learn this by doing $ git log | grep 13973 but since Trac #s are no longer in commit messages, that isn't foolproof either. And indeed, the standard output of git log is kind of scary, because while some entries look like this, roughly as in the old one commit 3ea4f9bfc3c1acb6cb9eaa8e7a8ffa41779a6181 Author: XYZ Date: Thu May 22 08:37:36 2014 +0200 16199: documentation cosmetics others look like this commit e9352062ad7fedbe00ad62d397672203824e0267 Merge: cc54f6e 80e319d Author: XYZ Date: Thu May 22 08:01:19 2014 +0200 Merge branch 'develop' into t/16199/improve_docs__add_doctests_in_power_seri * develop: (606 commits) Updated Sage version to 6.3.beta1 trac #16237: Typos Use lazy_import instead Use point collections more directly. trac #15036: fix late import of is_Matrix to avoid startup problems Fixes to normal_form_pc to work with point collections properly. Fixed failing doctests. trac #16277: A typo minor fixes Trac 15099: numeric evaluation of zetaderiv trac 16211: Review reviewer patch. Added a category parameter to Module change raise syntax to python3 style and still others look like this commit 9a4b0b83fa06a113c485f22f37af02c24ef35e90 Merge: f4cbb5f b8fea1c Author: Release Manager rele...@sagemath.org Date: Wed May 21 16:40:31 2014 +0100 Trac #15921: work around Maxima fpprintprec bug and other ARM-specific probl [https://groups.google.com/d/msg/sage-devel/oRpkswzpK38/rNVbVN2RyEcJ Maxima uses CL
[sage-devel] Re: Project: add hundreds of contributors to sage
On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote: As another example, in attempting to review one patch which relies upon the new Maxima update The git branch contains the entire code, so automatically has all requirements. You don't need to know where the maxima update comes from to use the branch. : where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less The git log is not a plain text file, its a directed acyclic graph. There is much more useful information in it than any possible linearization. More complicated than mailing patches? Sure. Why? Because mailing patches around doesn't work at that scale. $ git log | grep 13973 $ git log build/pkgs/maxima # see which commits actually touched maxima commit 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 Author: Peter Bruin p.br...@warwick.ac.uk Date: Fri May 16 11:33:00 2014 +0100 Trac 13973: upgrade Maxima to 5.33.0 Although Peter thought that the commit was for #13973 when he wrote it, that need not be the ticket that actually made use of the commit and pulled it into Sage. We check: # git trac find 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 $ git trac find 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 Commit has been merged, but not into a released version. commit 6220027f174e01ae252f277acb3a75de7053239c Merge: a3c4cf3 a130eed Author: Release Manager rele...@sagemath.org Date: Sun May 25 11:20:54 2014 +0100 Trac #13973: Upgrade Maxima to 5.33.0 This is a continuation of #13364, and aims at including more upstream bug fixes, which e.g. fix an [http://permalink.gmane.org/gmane.comp.mathematics.sage.support/30644 issue reported on sage-support], which was reported as Maxima bug [https://sourceforge.net/p/maxima/bugs/2535 2535], and marked there as closed in post-5.29.1. I don't know why the description of a ticket is ending up in the log. We want a description of what actually was done, and the description in the ticket is often full of brainstorming etc. Its up to you (the ticket author/reviewer) to make the description fit the ticket. For instance, for this one I guess I need to first do #13973, and then somehow add #13712 on top of it No. For reviewing #13712 (say) you only need to get that branch. Batteries are already included. If it doesn't work then that is a negative review. -- 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: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 10:49 AM, Volker Braun vbraun.n...@gmail.com wrote: On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote: As another example, in attempting to review one patch which relies upon the new Maxima update The git branch contains the entire code, so automatically has all requirements. You don't need to know where the maxima update comes from to use the branch. : where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less The git log is not a plain text file, its a directed acyclic graph. There is much more useful information in it than any possible linearization. More complicated than mailing patches? Sure. Why? Because mailing patches around doesn't work at that scale. The argument that mailing patches doesn't work at that scale isn't convincing, since Linux kernel development is much bigger than Sage development, and they mail patches around [1].There must be better arguments Just to be clear -- I'm definitely not arguing that we should switch to mailing patches around, or even that we should switch back to using patches; also me and many other people are *very, very* impressed and pleased with how you (Volker) are doing release management using the current system! [1] https://www.kernel.org/doc/Documentation/SubmittingPatches $ git log | grep 13973 $ git log build/pkgs/maxima # see which commits actually touched maxima commit 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 Author: Peter Bruin p.br...@warwick.ac.uk Date: Fri May 16 11:33:00 2014 +0100 Trac 13973: upgrade Maxima to 5.33.0 Although Peter thought that the commit was for #13973 when he wrote it, that need not be the ticket that actually made use of the commit and pulled it into Sage. We check: # git trac find 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 $ git trac find 33417fa92057fc7ef1cf52e301b9b73a2d5c2a83 Commit has been merged, but not into a released version. commit 6220027f174e01ae252f277acb3a75de7053239c Merge: a3c4cf3 a130eed Author: Release Manager rele...@sagemath.org Date: Sun May 25 11:20:54 2014 +0100 Trac #13973: Upgrade Maxima to 5.33.0 This is a continuation of #13364, and aims at including more upstream bug fixes, which e.g. fix an [http://permalink.gmane.org/gmane.comp.mathematics.sage.support/30644 issue reported on sage-support], which was reported as Maxima bug [https://sourceforge.net/p/maxima/bugs/2535 2535], and marked there as closed in post-5.29.1. I don't know why the description of a ticket is ending up in the log. We want a description of what actually was done, and the description in the ticket is often full of brainstorming etc. Its up to you (the ticket author/reviewer) to make the description fit the ticket. For instance, for this one I guess I need to first do #13973, and then somehow add #13712 on top of it No. For reviewing #13712 (say) you only need to get that branch. Batteries are already included. If it doesn't work then that is a negative review. -- 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. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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: Project: add hundreds of contributors to sage
On Thursday, May 29, 2014 7:00:52 PM UTC+1, William wrote: The argument that mailing patches doesn't work at that scale isn't convincing, since Linux kernel development is much bigger than Sage development, and they mail patches around That is not really true. They do mail patches around, but only at one very specific point in the lifetime of a changeset. The entire model is geared towards making everything as easy as possible for Linus. You present your change in a way that is as easy as possible for one of the inner circle to look at, and then forward to Linus. They don't collaborate with you, the only feedback is that your code is merged or refused (likely before it ever reaches Linus). Since it is a one way road its of course easier to mail a patch. The way I see it that does make it more difficult for the developers outside of the inner circle, they will have to resolve conflicts in their own branches whenever a new version appears. But that is parallelizable and developers are experienced with the tools, so its not a problem for the kernel. -- 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: Project: add hundreds of contributors to sage
Hi Volker, On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote: : where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less The git log is not a plain text file, its a directed acyclic graph. There is much more useful information in it than any possible linearization. If a simple question such as what is the ticket number for the latest Maxima upgrade is not easy to answer from the git log, then the information is *not* useful. The information exists, but is not useful. That's an important practical difference. Anyway, you have shown in your mail that it *is* possible to get the information in this case. Maxima is an spkg. Let's instead look at the Sage library. We can use git blame similar to hg annotate to get the revision in which a particular line of code was changed. This information can be used to search the corresponding commit message in the log. Before switching to git, we had the policy (enforced by commit hooks, if I recall correctly) that the commit message mentions the ticket number. I think this was very helpful. But now---because you keep saying that a commit does not belong to a specific ticket---the log often does not mention the ticket number. Some people mention the ticket number, others don't. Hence, when I wonder about a specific line of code and want to look up the discussion that took place on trac and resulted in this line of code: How can I easily find that discussion? Admittedly, one could argue that people shouldn't be so lazy and put the ticket number in. But then git causes a meta-problem: Some people advocating git go around and tell people that a commit does not belong to a ticket. Hence, people are not putting the ticket number into the commit message. And on the side of trac, there can not be an automatism that inserts the ticket number if it is missing, because Changing a commit message is changing history---which is something that I technically understand (the commit's sha1 hash depending on the commit message), but still consider it a flaw. More complicated than mailing patches? Sure. Why? Because mailing patches around doesn't work at that scale. Yes, it only works on the tiny scale of Linux development, as William pointed out... :-D I don't know why the description of a ticket is ending up in the log. We want a description of what actually was done, and the description in the ticket is often full of brainstorming etc. Its up to you (the ticket author/reviewer) to make the description fit the ticket. The main complaint was that the entire ticket description is ending up in the log. Don't you think that a ticket description has a different purpose than a commit message? Cheers, Simon -- 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: Project: add hundreds of contributors to sage
On Thursday, May 29, 2014 7:26:35 PM UTC+1, Simon King wrote: Before switching to git, we had the policy (enforced by commit hooks, if I recall correctly) that the commit message mentions the ticket number. No, that was Jeroen manually (ok, with a script) telling you days/weeks/months later that the commit message is wrong and needs to be fixed. code: How can I easily find that discussion? Pretty easy, I would say: git trac find sha1. We can add an option to open the trac ticket in a browser window if its too slow for you ;-) (the commit's sha1 hash depending on the commit message), Commits are immutable, and enforcing that is the primary feature of every version control system. In mercurial, too. There are tools for editing the history, but using them always comes at a price. Really, you have two options: * The branching model we are using where all individual commits end up public * The kernel model where every developer is responsible for cleaning up their history until it is perfect, and only then share the code. The second places a much higher burden on the individual developer, and on his direct collaborators who have to follow the rebases. The advantage is that the history looks beautiful, and it is more efficient for the guy at the top. The main complaint was that the entire ticket description is ending up in the log. Don't you think that a ticket description has a different purpose than a commit message? These are different commits. Every developer's commit contains a message to summarize what the commit is about. The release manager's merge commit doesn't have any intention behind it beyond the obvious merge that branch. So the commit message is up for grabs. I think its a good idea to put some of the ticket metadata there, for example this is then still available if you are not currently connected to the internet. -- 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: Project: add hundreds of contributors to sage
Hi Volker, On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote: code: How can I easily find that discussion? Pretty easy, I would say: git trac find sha1. Wow! That is in fact very useful. Didn't know about this. So far, I was mainly using the dev scripts, and git trac only once, I think. Cheers, Simon -- 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: Project: add hundreds of contributors to sage
On 29 May 2014 20:22, Simon King simon.k...@uni-jena.de wrote: Hi Volker, On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote: code: How can I easily find that discussion? Pretty easy, I would say: git trac find sha1. Wow! That is in fact very useful. Didn't know about this. So far, I was mainly using the dev scripts, and git trac only once, I think. Can someone point me to instructions for how to install (and use) git trac? John Cheers, Simon -- 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: Project: add hundreds of contributors to sage
On 2014-05-29, John Cremona john.crem...@gmail.com wrote: On 29 May 2014 20:22, Simon King simon.k...@uni-jena.de wrote: Hi Volker, On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote: code: How can I easily find that discussion? Pretty easy, I would say: git trac find sha1. Wow! That is in fact very useful. Didn't know about this. So far, I was mainly using the dev scripts, and git trac only once, I think. Can someone point me to instructions for how to install (and use) git trac? https://github.com/sagemath/git-trac-command John Cheers, Simon -- 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.
Re: [sage-devel] Re: Project: add hundreds of contributors to sage
On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote: Can someone point me to instructions for how to install (and use) git trac? The developer guide on a sufficiently recent (6.2+) Sage version. On a related note, the docs on the web page are still from 6.1.1 -- 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: Project: add hundreds of contributors to sage
On 29 May 2014 20:50, Volker Braun vbraun.n...@gmail.com wrote: On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote: Can someone point me to instructions for how to install (and use) git trac? The developer guide on a sufficiently recent (6.2+) Sage version. On a related note, the docs on the web page are still from 6.1.1 Thanks to both -- now installed in two machines and trying out. John -- 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: Project: add hundreds of contributors to sage
Robert Bradshaw wrote: [...] now that we're on git a pull request is 99% of what a ticket is I'm happy that this (still) is *not* the case (for most tickets at least). (specifically, an annotated point to a particular git branch/commit that needs review) and we should seriously consider accepting that format for contributions. I personally don't like trac very much (although it's become better over time), but IMHO all discussion / review of a contribution should (finally) happen in a central place, which currently is trac for Sage development. (During the switch to git, trac and ordinary reviewing effectively got bypassed; fortunately that stopped after the switch.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 2:22 PM, leif not.rea...@online.de wrote: kcrisman wrote: rant Git workflow. The goal was to reduce work for some developers and make things more modular, but in fact what happens is that people are basing their branches on all kinds of different starting points, forcing constant recompilation for even the most trivial changes. [...] /rant Nobody ever promised it would make *reviewers'* life easier. Making the reviewer's life easier should be a primary goal as well--look at the number of unreviewed tickets sitting on trac right now. Previously, we still had people basing their branches on all kinds of different starting points, but it was all implicit, so it was harder to look at and test exactly the code someone else intended to be contributing. If I understand your complaint correctly, the problem is that re-compiling after switching branches is too expensive. http://trac.sagemath.org/ticket/14372 needs to be resolved. I would note that for most trivial changes there's no need to download and build/test it yourself--the patchbot should do this for you. Of course sometimes you want to try out (and contribute back!) different corner cases, bigger examples, etc. but that's not essential for many reviews. It would be very cool if there was a way to have multiple builds of Sage co-exist cheaply. Imagine a service where you could ssh into trac1234.sagemath.org and be presented with a sage prompt with ticket #1234 built and ready to play with. Or a notebook. How cheap could it be to have a SMC project for every open ticket? And then you could take some of your examples and insanely easily (e.g. with the click of a button, or maybe a copy-paste) add them to a docstring. That's my vision of how to make life easier for reviewers on top of what the patchbot already does. - Robert -- 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: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 10:37 AM, William Stein wst...@gmail.com wrote: On Thu, May 29, 2014 at 10:01 AM, kcrisman kcris...@gmail.com wrote: Please excuse the following rant. As usual, it is ill-informed, and if some I appreciate it, and I'm glad we're having this discussion. (It's a rant, but it isn't a flame. Yeah!) of the points are due to ignorance, I have no problem with that being pointed out. But from reading the lists, I'm not the only one experiencing difficulty with this sort of thing. At the very least I think it shows it's not that easy to do everything right now. rant Git workflow. The goal was to reduce work for some developers and make things more modular, but in fact what happens is that people are basing their branches on all kinds of different starting points, forcing constant recompilation for even the most trivial changes. I'm told ccache will help with this, but it's still not in the developer guide, and I'm not sure it will help with [s]pkgs anyway, which also change frequently. There were arguments last year by various people that our patch-based workflow was bad, at least as opposed to using branches. There was little in the way of arguments back for patches. I personally wasn't really paying attention then, and I frankly didn't know which was better, having only had experience with patches.I'm glad that you're presenting some of the arguments below in favor of the value of a more patches-based workflow. I recently listened to an interview with the release manager for the stable linux kernel. Linux is of course a big project that uses git -- in fact, as we all know, Linus invented git for Linux development. They use *patches* rather than branches. In fact, their workflow is email + patches.He argues in the interview (in response to questions, etc.) that this is far more efficient than the branch model. Evidently, git has extremely good support for sending patches via email and applying them from email (at least in a local mail spool). Another project I'm involved in called bup (https://github.com/bup/bup) does the same thing -- all code contributions are patches to the mailing list, so I've seen this work. I'm not arguing for replacing trac by patches to a mailing list! I'm just pointing out that some people's assertions that using patches instead of branches is not properly using git can't be right, since the Linux kernel devs use of git is just as proper as anybody else's.Basically, I'm trying to argue that there is merit to your rant. In addition, a web-based interface just like github pull requests was promised, but I don't see it. Since we don't use the github version to allow people to just edit (see e.g. https://github.com/grant/sage/commit/27c97d376a956a05c6e4abd97102f80195bda4c0 for one request that apparently has been ignored), we are actually in a *worse* place than we were with patches, where at least those could be applied more or less independently of the state of Sage. As another example, in attempting to review one patch which relies upon the new Maxima update: where that is, one cannot learn easily from git log, since $ git log | grep maxima | less $ git log | grep Maxima | less both do not tell me that in fact, even though Trac says closed, #13973 apparently is not yet in a merged release, and so I just wasted a lot of time figuring that out. Since Merged in is no longer updated. You would think that I could learn this by doing $ git log | grep 13973 but since Trac #s are no longer in commit messages, that isn't foolproof either. And indeed, the standard output of git log is kind of scary, because while some entries look like this, roughly as in the old one commit 3ea4f9bfc3c1acb6cb9eaa8e7a8ffa41779a6181 Author: XYZ Date: Thu May 22 08:37:36 2014 +0200 16199: documentation cosmetics others look like this commit e9352062ad7fedbe00ad62d397672203824e0267 Merge: cc54f6e 80e319d Author: XYZ Date: Thu May 22 08:01:19 2014 +0200 Merge branch 'develop' into t/16199/improve_docs__add_doctests_in_power_seri * develop: (606 commits) Updated Sage version to 6.3.beta1 trac #16237: Typos Use lazy_import instead Use point collections more directly. trac #15036: fix late import of is_Matrix to avoid startup problems Fixes to normal_form_pc to work with point collections properly. Fixed failing doctests. trac #16277: A typo minor fixes Trac 15099: numeric evaluation of zetaderiv trac 16211: Review reviewer patch. Added a category parameter to Module change raise syntax to python3 style and still others look like this commit 9a4b0b83fa06a113c485f22f37af02c24ef35e90 Merge: f4cbb5f b8fea1c Author: Release Manager rele...@sagemath.org Date: Wed May 21 16:40:31 2014 +0100 Trac #15921: work around Maxima fpprintprec bug and other ARM-specific
Re: [sage-devel] Re: Project: add hundreds of contributors to sage
On Thu, May 29, 2014 at 10:29 AM, Travis Scrimshaw tsc...@ucdavis.edu wrote: I never really have had a problem with the new workflow (in fact, I actually prefer it to the old one). However I had a good command of git coming into this and read the git the hard way. So my 2 cents would be to have developers spend time learning git properly instead of using the dev scripts (I think this is a useful skill beyond Sage development). Yes, yes, yes. git trac fits well here to plug in only the sage-specific bits. However I do see your point that this is an extra barrier to Sage development since IMO one generally needs to know more about git than about Hg in order to development. 1) Put Merged in back. +1 I'd also suggest not closing/merging tickets until shortly before releasing the next beta. Why? 2) Fix just how much crazy stuff shows up in git log, presumably by merging things differently or with different messages or something. I don't think there's much we can do about this considering how git workflows are suppose to work and since the develop does have everything merged in. On this note, I think the ticket description is the perfect thing to put in the merge commit. People should be more aware of that, and craft (sometimes as the ticket evolves) good descriptions that describe exactly what the ticket is about. - Robert -- 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: Project: add hundreds of contributors to sage
Well, I am thankful that my rant led to some pretty substantive discussion. Here let me summarize some thoughts. A) +1 to having something where a github-like editing thing works. I've used this at least once with matplotlib. My beef with github is orthogonal to the web interface piece. If there is a good workflow where we can direct contributors to make smaller edits on the github mirror and they'll be taken care of, that's great. B) I didn't realize that the release manager commits were separate from the author ones. That is strange to me, but I guess it's there. Nonetheless, I think that the vast majority of ticket descriptions are (or at least start as) fairly half-baked notions of what could be added or fixed, and are entirely inappropriate for a commit message to siphon through in git log. Especially since they are so long compared to most commit messages (and not for good reasons). C) I haven't heard any -1's to Merged in being resuscitated, so maybe that should really happen. [More thoughts: Robert B: I think Travis' point about doing it near the release time is so that people know where to start from. My whole trouble earlier today ended up being because, since it said closed, I assumed the Maxima upgrade HAD to be in the latest beta - which it wasn't. And several git pull attempts in my develop branch did nothing, since develop is still at 6.3.beta2 as of this writing (on github at least). As it turned out, it wasn't based on the right ticket, so I guess that could have been needs work, but it *says* Depends on #13973 so in the old workflow that should have been enough (install #13973, then install this one). I feel like this is closely related.] D) Patchbot? What patchbot? At least the colorings aren't working right now, it seems. But I would love to trust that again and not have to rebuild trivial things. E) Please everyone let's put Trac #s back in the commit messages, then, if the immutability is a barrier there. Some of the most recent ones are completely mystifying. And then it will be possible to figure out where the new code IS in the tree, as opposed to just the merges which can be patchbombs. -- 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: Project: add hundreds of contributors to sage
On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote: Again, in the big wave of emails, this one also got misdirected: Hi everyone, I am looking for people who want to help me, in one way or another, bring hundreds of new first time contributors to sage. If I do not find enough partners, I will look for other more suitable python-based projects. The idea would be quite simple: teach python programming around some mathematics (such as combinatorics) and simultaneously produce code that would be useful for research and worth including in sage. Two catches: students are given individual problems to work on, and the course is taught on Coursera. Motivation for the students would come in various ways: internships, for instance. Quality of the code would be ensured by peer-testing the programs. William Stein has already responded to the major issues regarding the Sage development process, but I would just like to comment on this particular aspect of peer-testing. Having two or more people who have just learned python and do not know much mathematics peer review code does not lead to much of an ensured level of quality. Certainly there are other clumps of python aggregating code that are not as daunting as Sage. Numpy and Sympy come to mind, but I doubt that they would really relish a MOOC's-worth of naive contributions, when it is pretty much guaranteed that a very high percentage would, under careful scrutiny, be duplicative, erroneous, poorly coded, or all three. It's a nice thought to get many hands to write code free. But impractical, in spite of Eric Raymond's Cathedral and Bazaar essay. All bugs are shallow with enough eyes (or whatever the wording is...) is perhaps plausible if the system is itself shallow (like linux). Where I differ with Raymond is I think there are not enough eyes on the planet to make some bugs shallow in a deep system-- one that does (say) sophisticated symbolic mathematics. If extra eyes were all that were necessary, there would be no long-standing mathematical conjectures. If you do not know what Coursera or MOOCs are, you are welcome to take my upcoming course https://class.coursera.org/massiveteaching-001 If you are interested to play with a MOOC platform yourself, you might want first to watch the videostream of the 2pm-3pm slot of this conference I am co-organising on Tuesday: tinyurl.com/openedx-zurich as it will help you assess the technical challenges. I am looking at a start date for the course of around October-November, and to bring the discussion off the mailing list (to private) so as to keep an element of surprise for the students. Let me know! Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: paulo...@gmail.com javascript: twitter: podehaye freenode irc: pdehaye -- 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: project web servers
On Tuesday 17 February 2009, William Stein wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them.Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Hi, http://m4ri.sagemath.org doesn't exist anymore (since the switch). Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
planet.sagemath.org point's to William's homepage On Tue, Feb 17, 2009 at 4:53 AM, Martin Albrecht m...@informatik.uni-bremen.de wrote: On Tuesday 17 February 2009, William Stein wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them.Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Hi, http://m4ri.sagemath.org doesn't exist anymore (since the switch). Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Feb 17, 9:02 am, Timothy Clemans timothy.clem...@gmail.com wrote: planet.sagemath.org point's to William's homepage Yep, Harald already mentioned that off-list yesterday and there was some talk to resurrect the planet with nicer skinning, etc. soon. Thanks for reporting it again :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Tue, Feb 17, 2009 at 1:53 AM, Martin Albrecht m...@informatik.uni-bremen.de wrote: On Tuesday 17 February 2009, William Stein wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them.Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Hi, http://m4ri.sagemath.org doesn't exist anymore (since the switch). Please check that it works now. http://m4ri.sagemath.org/ Also, please check that you can login to boxen.math and from there do ssh m...@sagemath so you can login to the m4ri account and edit the website. You can add ssh keys for anybody else who should edit the website. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Tue, Feb 17, 2009 at 9:02 AM, Timothy Clemans timothy.clem...@gmail.com wrote: planet.sagemath.org point's to William's homepage This should now be fixed. Let me know if you see any other problems. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
Please check that it works now. http://m4ri.sagemath.org/ Also, please check that you can login to boxen.math and from there do ssh m...@sagemath so you can login to the m4ri account and edit the website. You can add ssh keys for anybody else who should edit the website. All good, thanks! Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On 17 Feb., 20:04, William Stein wst...@gmail.com wrote: On Tue, Feb 17, 2009 at 9:02 AM, Timothy Clemans timothy.clem...@gmail.com wrote: planet.sagemath.org point's to William's homepage This should now be fixed. Let me know if you see any other problems. William Hi William, the link I used to access trac is currently broken: http://sagetrac.org/sage_trac/ due to http://sagetrac.org/ also pointing to your home page. Cheers, gsw --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Tue, Feb 17, 2009 at 11:47 AM, Georg S. Weber georgswe...@googlemail.com wrote: On 17 Feb., 20:04, William Stein wst...@gmail.com wrote: On Tue, Feb 17, 2009 at 9:02 AM, Timothy Clemans timothy.clem...@gmail.com wrote: planet.sagemath.org point's to William's homepage This should now be fixed. Let me know if you see any other problems. William Hi William, the link I used to access trac is currently broken: http://sagetrac.org/sage_trac/ due to http://sagetrac.org/ also pointing to your home page. Cheers, gsw Thanks. This is now fixed. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Feb 16, 9:25 pm, William Stein wst...@gmail.com wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them. Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Attaching sub-1kb patches is broken in Sage's trac with [9:39pm] mabs: wstein2: I cannot attach patches to trac all the sudden. It worked 10 minutes ago: [9:39pm] mabs: Traceback (most recent call last): [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 387, in dispatch_request [9:39pm] mabs: dispatcher.dispatch(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 237, in dispatch [9:39pm] mabs: resp = chosen_handler.process_request(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 361, in process_request [9:39pm] mabs: self._do_save(req, attachment) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 450, in _do_save [9:39pm] mabs: size = upload.file.len I tested and as soon as a patch is larger than 1023 bytes it works again. -- William -- William Stein Cheers, Michael Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Mon, Feb 16, 2009 at 9:45 PM, mabshoff mabsh...@googlemail.com wrote: On Feb 16, 9:25 pm, William Stein wst...@gmail.com wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them.Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Attaching sub-1kb patches is broken in Sage's trac with [9:39pm] mabs: wstein2: I cannot attach patches to trac all the sudden. It worked 10 minutes ago: [9:39pm] mabs: Traceback (most recent call last): [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 387, in dispatch_request [9:39pm] mabs: dispatcher.dispatch(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 237, in dispatch [9:39pm] mabs: resp = chosen_handler.process_request(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 361, in process_request [9:39pm] mabs: self._do_save(req, attachment) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 450, in _do_save [9:39pm] mabs: size = upload.file.len I tested and as soon as a patch is larger than 1023 bytes it works again. -- William OK, this is now fixed. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: project web servers
On Mon, Feb 16, 2009 at 9:45 PM, mabshoff mabsh...@googlemail.com wrote: On Feb 16, 9:25 pm, William Stein wst...@gmail.com wrote: Hi, I had to migrate all the cython, Sage and mpir websites and related servers to another machine, due to some hardware failures on the server that was hosting them.Please let me know if any of the cython, Sage, or MPIR websites are suddenly broken. Attaching sub-1kb patches is broken in Sage's trac with [9:39pm] mabs: wstein2: I cannot attach patches to trac all the sudden. It worked 10 minutes ago: [9:39pm] mabs: Traceback (most recent call last): [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 387, in dispatch_request [9:39pm] mabs: dispatcher.dispatch(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/web/main.py, line 237, in dispatch [9:39pm] mabs: resp = chosen_handler.process_request(req) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 361, in process_request [9:39pm] mabs: self._do_save(req, attachment) [9:39pm] mabs: File /home/sage/sage_install/stable/local/lib/ python2.5/site-packages/trac/attachment.py, line 450, in _do_save [9:39pm] mabs: size = upload.file.len I tested and as soon as a patch is larger than 1023 bytes it works again. Thanks for pointing this out. I've upgraded the trac servers for sage, cython, and mpir all to trac-0.11.3. Again, let me know if you have any problems as a result. Note that trac-0.11* has much better support for workflows, but I haven't done anything with that -- I just migrated the old installs. Mike Hansen will likely incorporate better workflow support, at least for the sage project. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 22, 7:36 am, Bill Page [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote: Hello folks, ... In the defense of GCL, *most* components of Sage were a mess gcl is in way more of a mess than any other component in Sage I can imagine. But then I wasn't around in the early days of Sage ;) like above when I/you/whoever first tried to add them to Sage. I personally haven't tried much using cvs GCL only, partly because it scares me to use cvs for a deployed quality product. Since cvs might be broken one day, not the next, etc., and one has no clue if the code has been tested or not or what. The last released version is from 2005, and it's clear the website is just dead (maybe somebody lost the password?!) I mean, it just looks a little silly for the website (http://www.gnu.org/software/gcl/) to start with: NEW! (20050810) GCL 2.6.7 is released. The release notes can be found here. ... The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. No doubt about it - GCL does not have sufficient resources for maintenance and has been somewhat neglected of late. As you say: It is not a situation that you find entirely uncommon among the packages that have been added to Sage in the past. Necessity is what drives most of this kind of work. I've made a gcl Sage optional spkg: http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg It's just GCL-from-cvs + a simple spkg-install. I have never got it to build on any system. It's a pretty big spkg, since it appears to include the entire gas assembler, some version of GMP, etc. Try it out and see if it *doesn't* work for you too :-) wgethttp://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg sage -i gcl-20080421.spkg Thanks. It doesn't work for me either. :-( You are right that the source is bloated by a bunch of code that it does not use. As I understand it gcl needs only a small part of binutils - depending on the build options for a particular system. Is this source from cvs head at: http://savannah.gnu.org/projects/gcl/ as of today? Yes. This version of GCL fails on my Solaris x86 system with the following obscure error message: gcc -c -fsigned-char -pipe -Wall -O3 -fomit-frame-pointer -I/export/home0/wspa ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c cmpaux.c: In function `object_to_fcomplex': cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function) cmpaux.c:329: error: (Each undeclared identifier is reported only once cmpaux.c:329: error: for each function it appears in.) cmpaux.c: In function `object_to_dcomplex': cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function) gmake[1]: *** [cmpaux.o] Error 1 rm list.c gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o' gmake: *** [unixport/saved_pre_gcl] Error 2 That is an issue most likely with complex.h - IIRC _Imaginary_I is part of the Sun's libc or libm - I would need to check. --- At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl'I see changes as recent as 3 months ago. The last time I built GCL from head was about 10 months ago. I tried 8 months or so ago and then roughly 4 months or so ago, both times with disastrous results. The most recent branch 'Version_2_6_8pre' is what we normally use to build Axiom. There is a change about 4 months old. If I recall correctly 'Version_2_6_8pre' actually corresponds to the version distributed on Debian and would probably be the most likely to be stable on the largest number of platforms. At least testing ships CVS head. And not to be too picky here: The last tarball from the website predates OSX 10.5 and also Solaris 10, so maybe it is time to cut another bug fix release since everybody seems to be using 2.6.8CVS anyway. But when I build stable releases I do not poke around in the CVS repo. Asking could have helped, but if nobody bothered to update the website in three years anyway what is the point? 2.6.7 actually also miserably fails on Solaris 9 for me, and that has been out for a while before 2.6.7. Bill Page -- I would be interested in any comments you might have. For example, is the fact that GCL doesn't build for us anywhere, something that you think we'll get passed by just trying harder? Or is it going to be really really hard. The fact that it doesn't build for you anywhere is definitely strange. I would give it a try again with $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gcl co -r Version_2_6_8pre gcl I do expect that (with the right help) you will be able to build gcl everywhere that you build Sage. Instead of just trying harder I think it is very appropriate to ask for help. Only if there is no help forthcoming, perhaps I
[sage-devel] Re: Project
Michael, Wow, it sure it nice to have someone on the other end of the phone, so as to speak ... :-) I think it is really great that Google came through with financial support that is making it possible for you and others to dedicate so much time to this. On Tue, Apr 22, 2008 at 2:41 AM, mabshoff wrote: On Apr 22, 7:36 am, Bill Page wrote: ... The most recent branch 'Version_2_6_8pre' is what we normally use to build Axiom. There is a change about 4 months old. If I recall correctly 'Version_2_6_8pre' actually corresponds to the version distributed on Debian and would probably be the most likely to be stable on the largest number of platforms. At least testing ships CVS head. Are you sure? I suppose that we had better check with Camm. And not to be too picky here: The last tarball from the website predates OSX 10.5 and also Solaris 10, so maybe it is time to cut another bug fix release since everybody seems to be using 2.6.8CVS anyway. Yes, 2.6.8pre (as in pre-release). 2.6.8 was never officially released. But when I build stable releases I do not poke around in the CVS repo. Asking could have helped, but if nobody bothered to update the website in three years anyway what is the point? 2.6.7 actually also miserably fails on Solaris 9 for me, and that has been out for a while before 2.6.7. This is open source age and GCL existed well before that. I am not making excuses but ... ... Well, since the Maxima folks now have told us that they will support ecls soon the decision has been made on our end to switch to Maxima +ecls. Choose your own poison. ;-) Actually I don't know much about ecl but I seriously doubt the long term viability of ecl will be any different than the half dozen other alternatives. Of course I am all for co-operation between projects so if Maxima is willing to make a version that is more suitable for use in Sage, the more power (money and resources ...) to them! :-) There is no point in beating the dead horse that is gcl. I take offense. gcl is not a dead horse no matter how neglected it might look to you. ecls has MSVC support *today* and is probably trivially to port to Sun Forte if it doesn't run already. The mailing list is alive and well. I have looked at the code and fixed some issues myself, so why would I want to touch gcl? I don't know. The OpenAxiom and FriCAS forks of Axiom work on ecl so I am also not too worried about gcl in the long run. --- Anyway, none of this solves the immediate problem of providing support for symbolic mathematics in Sage without adding the burden of supporting Lisp in all target environments. Right now you depend on the linkage with Maxima for this feature, And I think you see symbolic manipulation as a particular domain or mode of computation within Sage rather than the reason d'etre of computer algebra systems. I would like to argue however that from an overall design perspective Axiom is a better match for Sage than Maxima. Like Sage itself, the Axiom library is built-up in a (more or less) rigorous manner from more fundamental mathematical constructions. One of these complex constructions is called 'Expression'. This is the domain in which most symbolic calculations are done in Axiom. However as it will be in Sage, it is necessary that Expression interact in a well-defined manner with other Axiom domains of computation. I believe that if you were to re-implement the Maxima symbolic functionality within Sage (Python) then you would essentially be implementing something rather similar to the Expression domain in Axiom. In the longer term (pending resolution of the remaining open source license issues), Aldor could provide much of the same set of functionality of Axiom through it's BasicMath and other libraries without the overhead of the Axiom interpreter interface. This would completely eliminate the need for Lisp. I still have some hope that this could happen in the near future. If Sage were to pursue this path, I think the Aldor license issues might be resolved more quickly. Well, I think NAG chose the non-commercial only license on purpose. Well yes, of course it was on purpose. They have stated that they felt obligated to do this by the terms under which they originally received Axiom (and Aldor) from IBM. NAG itself is a non-commerical organization. We have discussed the issue here before and everybody agrees that it is GPL incompatible. Yes, that is the said truth. Some people at NAG apparently also have a philosophical disagreement with the Free Software Foundation about the reasonableness of GPL but I am still optimistic that this can be overcome. Afterall, you can only shoot yourself in the foot so many times ... ;-) But I have little hope that Sage's potential interest in Aldor would get somebody to change the license. I think you greatly under estimate the
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 8:12 AM, William Stein [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 5:32 AM, Gabriel Dos Reis [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 2:39 AM, mabshoff [EMAIL PROTECTED] wrote: On Apr 22, 9:15 am, Alfredo Portes [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 1:41 AM, mabshoff [EMAIL PROTECTED] Hi, Well, I think NAG chose the non-commercial only license on purpose. We have discussed the issue here before and everybody agrees that it is GPL incompatible. But I have little hope that Sage's potential interest in Aldor would get somebody to change the license. A non- commercial only Open Source license is often the kiss of death to a project. Abandoned by its commercial parent company, but not free in reality it is neither here nor there. Either you make the code free [your choice: GPL, LGPL, MIT, BSD] or you don't. It is either Open Source code or it isn't, just like you can't be a little big pregnant :) Yes, just like QT...oh wait. Well, I don't think the situation is comparable. TrollTech understood Open Source way back. Axiom was released under BSD, so why the different treatment for Aldor? From the little I know, the situation -- as it has been carefully explained to me -- is far more complicated, and I'm not sure it is one that can be resolved by emails. All I can say is that there really are good guys at NAG who would not like to see Axiom die (as it was) and they did the best to make it open source under a very liberal license (no poison). The surrounding environment and conditions for releasing Aldor had changed from what they were back when Axiom was released. I would recommend you talk to Mike Dewar, Stephen Watt, Barry Trager (among others) about the situation. However, I doubt it can be resolved by public emails -- and if it is resolved by public emails, then that is fantastic!. I can imagine.Is the conclusion to draw from the above that you think it unlikely Aldor will be released under a standard open source license in the near future, but that you very much wish it would be? Stephen Watt has indicated, at many times, that he is very willing to clarify the Aldor license terms -- I believe he intends to write a sort of FAQ that would shed light on the issue. I can imagine that the voice of a big player (Sage) is not the same as that of a small group (Axiom community at the time); so it might be that Sage could be more persuasive; but I suspect it would take lot of face-to-face conversions. At ISSAC'08, you'd very likely to meet people would shaped the development and release of Axiom and Aldor. However, unless there is a new player with new material in the discussion, I would not expect the situation to change. A petition to really open source Aldor won't hurt I think. What is the worst that can happen? Yes, I know the answer go and start one :-( Out of curiosity: Are there download statistics of Aldor binaries and source? Is there any kind of estimate of user numbers? How far along is FriCAS and/or OpenAxiom from using pure Aldor and no lisp? Are there any benchmarks to compare those two? Because of licensing issues -- OpenAxiom is released under BSD license -- and dependency problems, I cannot make OpenAxiom purely depending on Aldor. Whoever, it should be possible to call Aldor libraries from OpenAxiom and vice versa (and if that does not work, it is likely a bug in OpenAxiom). You didn't answer the questions about downloads/users/etc. Sorry about that -- I did not have enough coffee :-) Download: The numbers I have are the ones from SF website. When I ask for the raw number for the last two months ( Feb 23, 2008 - Apr 22, 2008), it says 685 downloads. I see a peak at 34 yesterday (I have no clue about what was going on yesterday). http://sourceforge.net/project/stats/detail.php?group_id=203172ugn=open-axiomtype=prdownload The Windows binary is said to have been downloaded 319 times but Alfredo and I know that the actual numbers are higher than that because the count was reset when the binary file was upgraded. The source tarball has been downloaded 133 times. Combined, the RPMs have been downloaded 78 times. Users: I have no numbers, except extrapolating from downloads and people sending me emails. Should we write to NAG to ask? Yes, that is a very good initiative. Mike Dewar is among the NAG people you might want to talk to. As I have stated many times, and part of the reasons for OpenAxiom, I would like to get away from Lisp as soon as possible: This isn't negociable. For people in Sage-devel who don't know, OpenAxiom has the following goal
[sage-devel] Re: Project
mabshoff wrote: Well, since the Maxima folks now have told us that they will support ecls soon the decision has been made on our end to switch to Maxima +ecls. Michael, I don't mean to rain on the parade, but: I personally am willing to try to resolve the problems compiling Maxima with ECLS, but I can't promise that anyone else is going to be interested. There is no point in beating the dead horse that is gcl. It has been proposed more than once on the Maxima mailing list to drop GCL. The main issue is that GCL runs on Windows and some other Lisps of interest (SBCL, CMUCL) do not. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 6:50 AM, Bill Page [EMAIL PROTECTED] wrote: Michael, Wow, it sure it nice to have someone on the other end of the phone, so as to speak ... :-) I think it is really great that Google came through with financial support that is making it possible for you and others to dedicate so much time to this. I'm very thankful to them. By the way, Microsoft Research is also funding Sage work right now, and I'm also very grateful to them. On Tue, Apr 22, 2008 at 2:41 AM, mabshoff wrote: On Apr 22, 7:36 am, Bill Page wrote: ... The most recent branch 'Version_2_6_8pre' is what we normally use to build Axiom. There is a change about 4 months old. If I recall correctly 'Version_2_6_8pre' actually corresponds to the version distributed on Debian and would probably be the most likely to be stable on the largest number of platforms. At least testing ships CVS head. Are you sure? I suppose that we had better check with Camm. Please do. And not to be too picky here: The last tarball from the website predates OSX 10.5 and also Solaris 10, so maybe it is time to cut another bug fix release since everybody seems to be using 2.6.8CVS anyway. Yes, 2.6.8pre (as in pre-release). 2.6.8 was never officially released. But when I build stable releases I do not poke around in the CVS repo. Asking could have helped, but if nobody bothered to update the website in three years anyway what is the point? 2.6.7 actually also miserably fails on Solaris 9 for me, and that has been out for a while before 2.6.7. This is open source age and GCL existed well before that. I am not making excuses but ... GCL started in 1984 I guess. ... Well, since the Maxima folks now have told us that they will support ecls soon the decision has been made on our end to switch to Maxima +ecls. Choose your own poison. ;-) Actually I don't know much about ecl but I seriously doubt the long term viability of ecl will be any different than the half dozen other alternatives. Perhaps you should know more about ecl before you make such assertions. I also don't know much about ecl, but I do know that Michael Abshoff knows how to evaluate code and build systems well, and if he says that ecls is much more viable codewise I wouldn't try to refute it by simply saying I seriously doubt it without a good argument. Michael did give real technical arguments for ecls. Aside: Several very successful senior industry-type people have mentioned to me on several occasions that successful software projects tends to have a life cycle, which is maybe around 30 years. I do not know if I believe this, but their reasoning goes that software does something like this: Years 0-9: rapid growth of new project by a bunch of smart kids Years 10-19: stability; usability Years 20-29: decline GCL is from 1984. I'm still not at all sure I buy into this 30 year lifecycle deal, but there is probably something to it. Perhaps the only way to escape it is to reinvent the software -- e.g., Cayley which started in 1973, was reinvented as Magma in the early 1990s. Maybe Magma is being reinvented as Sage... :-) Of course I am all for co-operation between projects so if Maxima is willing to make a version that is more suitable for use in Sage, the more power (money and resources ...) to them! :-) Good. There is no point in beating the dead horse that is gcl. I take offense. gcl is not a dead horse no matter how neglected it might look to you. ecls has MSVC support *today* and is probably trivially to port to Sun Forte if it doesn't run already. The mailing list is alive and well. I have looked at the code and fixed some issues myself, so why would I want to touch gcl? I don't know. The OpenAxiom and FriCAS forks of Axiom work on ecl so I am also not too worried about gcl in the long run. --- Anyway, none of this solves the immediate problem of providing support for symbolic mathematics in Sage without adding the burden of supporting Lisp in all target environments. Right now you depend on the linkage with Maxima for this feature, And I think you see symbolic manipulation as a particular domain or mode of computation within Sage rather than the reason d'etre of computer algebra systems. I would like to argue however that from an overall design perspective Axiom is a better match for Sage than Maxima. Like Sage itself, the Axiom library is built-up in a (more or less) rigorous manner from more fundamental mathematical constructions. One of these complex constructions is called 'Expression'. This is the domain in which most symbolic calculations are done in Axiom. However as it will be in Sage, it is necessary that Expression interact in a well-defined manner with other Axiom domains of
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 9:35 AM, Robert Dodier [EMAIL PROTECTED] wrote: There is no point in beating the dead horse that is gcl. It has been proposed more than once on the Maxima mailing list to drop GCL. The main issue is that GCL runs on Windows and some other Lisps of interest (SBCL, CMUCL) do not. Yes, that is a strong argument. See http://sourceforge.net/mailarchive/message.php?msg_name=877ifavq4r.fsf%40cantab.net -- Gaby --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
..snip... If the lisp community were alive and well their tools would be alive and well. That is clearly not the case of gcl and clisp certainly has some serious issues to deal with with newer gcc releases as well as compilers not gcc. I'm also on the clisp mailing list and I don't recall seeing any sage-related bug reports there either. Can gcl be improved? Certainly. But I am not holding my breath. ..snip... I know you don't care about lisp and that's fine. And I know you've encountered problems with lisp builds. And we both know that when someone encounters problems with open source tools it is expected behavior to post bug reports (as I did with Sage this morning). Please post specific bug reports. We all know that's the only real way anything will get done to solve the problems. The clisp maintainers are very responsive to mailing list bug reports. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 4:25 PM, root [EMAIL PROTECTED] wrote: I know you don't care about lisp and that's fine. And I know you've encountered problems with lisp builds. And we both know that when someone encounters problems with open source tools it is expected behavior to post bug reports August 08, 2007 http://lists.gnu.org/archive/html/gcl-devel/2007-08/msg4.html August 19, 2007: http://lists.gnu.org/archive/html/gcl-devel/2007-08/msg00017.html No answer, no acknowledgment. If I'm reading `date` output correctly, today is April 22, 2008. How long do you think Don Winieki -- who is *begging* to contribute to GCL -- should wait till he gets an answer to this basic question: http://lists.gnu.org/archive/html/gcl-devel/2008-04/msg4.html http://lists.gnu.org/archive/html/gcl-devel/2008-02/msg4.html -- Gaby --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 22, 11:25 pm, root [EMAIL PROTECTED] wrote: Hi Tim, ..snip... If the lisp community were alive and well their tools would be alive and well. That is clearly not the case of gcl and clisp certainly has some serious issues to deal with with newer gcc releases as well as compilers not gcc. I'm also on the clisp mailing list and I don't recall seeing any sage-related bug reports there either. Two examples I could find in my local mail archive [I have more, but not all my email that I send is stored locally and searchable]: * clisp 2.43 Solaris 9 build failure 11/09/2007 * clisp.run 2.41 segfaults on Solaris 9 in 32 bit mode 08/18/2007 I send more emails about two two months ago, but much of that traffic was off-list to Sam directly with William in the CC. Sam has an account on one of William's Solaris boxen, so he can't claim that he doesn't have access. The gcc 4.2 and 4.3 issues are well documented in clisp's sf bugtracker. The report originally was by cartman, which used to hang around in #sage-devel. I have also commented on various ticket at clisp's sf based bug tracker. So I would say I have met the burden of being involved and attempted to fix things. Can gcl be improved? Certainly. But I am not holding my breath. ..snip... I know you don't care about lisp and that's fine. And I know you've encountered problems with lisp builds. And we both know that when someone encounters problems with open source tools it is expected behavior to post bug reports (as I did with Sage this morning). Yes. Your feedback is certainly appreciated and I will fix the bug you reported in 3.0.1. The README.txt says that the minimal supported version of gcc is 3.4 and when building FLINT [later on after eclib] it will error out telling you that you need a C99 compiler. We will move that test to the start of the Sage build process so the error will not happen. Please post specific bug reports. We all know that's the only real way anything will get done to solve the problems. The clisp maintainers are very responsive to mailing list bug reports. Yes, they are, but they haven't solved the problem. Re gcc 4.2+4.3 it boils down to: We know it miscompiles, it is likely a bug in gcc, so if you figure out what is wrong let us know. Well, after 6+ months I decided that enough is enought [and I looked at their code to get it to compile with Sun Forte's cc or CC] and we are building the code with -O0 to avoid hitting that bug. But even -O0 doesn't help on Solaris for example. The last working clisp on Solaris is 2.39 compiled with gcc 3.3 on Solaris 8. I got it to run as a binary by tricking it [it wants readline.so.4, but causes it to segfault, so linking readline.so.5 to readline.so.4 and manipulating LD_LIBRARY_PATH for clisp does the trick]. I feel that I have done more than a reasonable amount of work here. Do you agree or disagree? Tim Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 3:25 PM, mabshoff wrote: I googled for it and it seems lenny is using 2.6.7 while sid is using 2.6.7-36.1. So I might have gotten my wires crossed with unstable here. So my bad. Beware of the release numbering. The most recent reference I could find is: http://lists.gnu.org/archive/html/gcl-devel/2008-01/msg2.html 2.6.8pre by contrast is nearer at hand. I do think we will need a windows installer for this release. I'd also like a working mac intel port. Otherwise, the image (packaged as Debian gcl-2.6.7-36) is carrying axiom, maxima, acl2, and hol88 to all 12 Debian platforms. So I guess as of January this year Debian 2.6.7-36.1 was actually 2.6.8pre in cvs. But it still raises the point that the website should either have snap shots or a pointer to the Debian page. I know that Camm is heavily involved with Debian, so I knew where to look after the 2.7CVS failed for me the first time I checked it eight months or so ago. Yes it would be nice to have accurate up to date information at the gcl website. Maybe a wiki would be nice but it still takes someone with time and motivation. ... Well, I think NAG chose the non-commercial only license on purpose. Well yes, of course it was on purpose. They have stated that they felt obligated to do this by the terms under which they originally received Axiom (and Aldor) from IBM. Odd, IBM as a whole seems to be very OS friendly, but in reality it somewhat depends on the unit you deal with. I also suspect that if it were possible to approach IBM about the license situation with Axiom and Aldor now, one might obtain a different picture than the one presented by NAG. But NAG's relationship with IBM was circa 1995 and this is now. Different people are involved. NAG itself is a non-commerical organization. Well, be that as it may, but their numerical library isn't free. Therein lies the rub. Originally, acquiring Axiom was a way for NAG to package and market it's numerical library. They did a *lot* of work to link Axiom to the numerical library - all of which was lost in the open source version of Axiom. When the numerical library was licensed to Maple circa 2000, NAG found themselves in a bit of a conflicted position. ... Nope, I am fully aware of the power of Sage. But let's get $FOO into Sage is not the solution and will not magically make a project better. It seems to me that my proposal for the place that Axiom/Aldor could have in Sage has more depth to it than that... :-( ... Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 11:32 PM, Bill Page [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 3:25 PM, mabshoff wrote: I googled for it and it seems lenny is using 2.6.7 while sid is using 2.6.7-36.1. So I might have gotten my wires crossed with unstable here. So my bad. Beware of the release numbering. The most recent reference I could find is: http://lists.gnu.org/archive/html/gcl-devel/2008-01/msg2.html 2.6.8pre by contrast is nearer at hand. I do think we will need a windows installer for this release. I'd also like a working mac intel port. Otherwise, the image (packaged as Debian gcl-2.6.7-36) is carrying axiom, maxima, acl2, and hol88 to all 12 Debian platforms. So I guess as of January this year Debian 2.6.7-36.1 was actually 2.6.8pre in cvs. Just for the record -- I looked at the source package of gcl 2.6.7-36.1 a couple days ago, and it's a big mess. The orig.tar.gz is smaller than the debian.diff, that patches nearly every file. Also the debian/ directory contains garbage like this: $ ls debian/.#* debian/.#changelog.1.220.2.1.4.1.2.1.2.1.2.2.2.1.2.19.2.207.2.23.2.11.2.14.2.13.4.7.2.22.2.97 debian/.#control..1.2.2.1.2.5.6.1.2.1.2.3.2.8 debian/.#control.1.35.4.1.4.5.6.1.2.1.2.5.2.8 debian/.#control.cvs.1.1.2.1.2.5.6.1.2.1.2.3.2.8 debian/.#rules.1.41.4.2.2.7.4.1.2.1.2.2.2.1.2.8 But that's minor. Well, I am glad I don't have to touch and maintain such a thing. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
I feel that I have done more than a reasonable amount of work here. Do you agree or disagree? Have you done a reasonable amount of work? That's for you to judge since you're the person with the need. But lets see what seems to be going on with Clisp. Sam's reply to you seems to be that you need a certain combination of operating systems and compilers and libraries to generate a supported build. (This is very similar to the reply to my Sage bug report, essentially fix your compiler.) So the expected response would be for you to reinstall Solaris to the correct version with the correct libraries and the bug goes away. Asking a user to fix their system is not a valid response but that seems to be the essence of the replies. Ask yourself why you might get this kind of response. Sam (and Camm) may have time constraints. I know that Camm does the work in his free time. I know Camm is working on a massive rewrite (probably NOT in public). I don't know what Sam does for a living but I suspect his work is also a free time activity. Axiom is also free time support. Dormant bug reports are not an indication of inactivity. Sage may have a few bug reports that are a few months old. Clisp is free software. You have the source code, you have the need, post a patch. Sam (and Camm) may have hardware/operating system constraints. Possibly the boxen that they use are borrowed and they cannot reproduce your exact environment. I have 9 physical machines here with 32 virtual boxen and I still cannot reproduce all of the combinations. I don't have access to a Sparc, for instance. Sourceforge took down their compile farm and HP doesn't have a large set in their farm. Axiom runs in many more places than I publish but there are outstanding build issues so I won't claim it runs anywhere but on a published subset of combinations. You do the same thing (e.g. no redhat9 gcc x.x.x). I did ask Google, Microsoft, and Sourceforge to put up compile farms but nothing happened. If we all used a standard compile farm this problem might be minimized. For now, though, the odds are good that Sam does not have your Solaris machine configuration and cannot reproduce your bug. We are both in the same business; you package Sage to run everywhere and I package Axiom to run everywhere. As soon as you touch anything at all, something breaks. When GCL breaks, I post a patch and locally apply the patch until it is accepted upstream (if at all). If Clisp fails for you then fix it, post a patch, locally apply the patch until it gets applied upstream, and move on. It is not a question of reasonable amount of work. It is a question of expectations. What, exactly, do you expect? Instant, top-of-the-pile bug fixes on all of YOUR hardware/software combinations? This is free and open source software. The only thing you can expect is to get the source code so you can fix it and post a patch. Everything else is not in the contract. That's why people pay for software. Franz would be willing to fix your issues immediately. I'm not sure your check to Sam has cleared yet. If you don't want to build patches then send Sam a contract. I'm sure he'd be happy to get paid. Sage will have this same problem in the future as various package maintainers move on or you can no longer reach your Sparc. What if your expectations are not fulfilled? Well, that generally leads to anger and frustration, both natural reactions. But it seems that you have used hasty generalization to conclude that Lisp is dead. And from there to conclude that Lisp should be removed from everywhere. That's a shame because Maxima contains an astonishing amount of well debugged algorithms by recognized experts in the field. And characterizing Lisps like SBCL (fork of CMUCL, child of the CMU Spice Lisp research project) as polishing a turd, implies that Scott Fahlman wasted his time studying dynamic language optimization in compilers. Python has yet to even think about these issues, most of which have already been solved by Scott. Everywhere else in Sage I see people struggle over milliseconds. Then I see Maxima built on Clisp (an interpreter) rather than SBCL, a optimizing compiler. Ultimately the point of my post was that, despite not seeing immediate results, it is STILL worthwhile to post bug reports. At minimum, other people can google them and find that they also have the problem. As for your original question, if your bug reports contain a patch THEN you've done a reasonable amount of work, at least by my definition of reasonable. Your definition might differ. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 6:50 PM, mabshoff [EMAIL PROTECTED] wrote: I don't want this discussion to go out of hand [too late], but ultimately this is all about what is best for the Sage project. And my opinion there counts a whole lot more in that regard than yours, just as my opinion about Axiom is totally irrelevant. Michael -- Don't worry too much about being distracted by Tim. Just providing data as you have been doing so well is sufficient for us to form opinion. Please keep the good work up. And certainly, I value your opinion about CASs for the Axiom family. -- Gaby --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 23, 1:58 am, Gabriel Dos Reis [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 6:50 PM, mabshoff [EMAIL PROTECTED] wrote: I don't want this discussion to go out of hand [too late], but ultimately this is all about what is best for the Sage project. And my opinion there counts a whole lot more in that regard than yours, just as my opinion about Axiom is totally irrelevant. Michael -- Gaby, Don't worry too much about being distracted by Tim. Just providing data as you have been doing so well is sufficient for us to form opinion. Please keep the good work up. And certainly, I value your opinion about CASs for the Axiom family. Well, since I have no stake over in the Axiom family because I do not contribute code I meant to say that Tim is free to ignore my opinion. I certainly have an opinion on Axiom, but this thread is loaded enough that I do not need to pour gasoline in the flames ;) But it is important to me that sage-devel is a forum where each voice is heard and while I fundamentally disagree with Tim I greatly prefer him to be around. This forum should not be some cult like thing where we all tell each other how great we are and that William walks on water. I am rude, opinionated and I state my opinion honestly. I have been wrong, very wrong, very, very wrong and will be wrong again in the future, but in that case I am the first to call myself an idiot in public. Tim might be right 99% of the time, but he fights for his ideas as fiercely even for the 1% where he might be wrong. So, in the end I might owe Tim an apology on some of the things where he is right, but in my point of view he is wrong about lisp and also wrong about literate programming. This is a free country [planet :)], so both of us are free to follow up on their own opinion. I am sure Sage will succeed, which is all that matters to me. What is also important is that in sage-devel technical reasons trumps all else, i.e. just because you are are reputable, widely respected person in the mathematical world expect no lenience from me if I think you are wrong. In mathematics you are either wrong or right - we don't have that luxury in programming, hence we have discussions like this. I immensely enjoy those, but I am getting back to work on Sage 3.0.1 now. :=) -- Gaby Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 7:33 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Apr 21, 6:48 am, Bill Page [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: SNIP GCL uses the C compiler directly. I am not suggesting that GCL is necessarily the right lisp for Sage (or even that Sage needs a lisp compiler at all) but I do rather think you should give GCL another try. I would be glad to try to help you debug the problems on Solaris. In both cases the current CVS checkout out from savannah blows up on Solaris 9 and 10 in the same spot: Solaris 9: # Subconfigure of BFD done # # checking size of long... 4 checking size of int... 4 checking size of short... 2 checking size of char... 1 checking for number of bits in char... 8 checking whether byte ordering is bigendian... yes checking for sbrk... yes checking for randomized sbrk... no checking for required object alignment... 8 checking for C extension variable alignment... __attribute__ ((aligned (8))) checking TYPE_BITS macro... 0xff09 checking sizeof struct contblock... 8 checking for pagewidth... 13 checking DBEGIN... 0x2 checking CSTACK_ADDRESS... 0xffbf checking NEG_CSTACK_ADDRESS... yes checking finding CSTACK_ALIGNMENT... 8 checking CSTACK_DIRECTION... -1 checking for shared library/C stack ceiling to heap... failed Solaris 10: # # Subconfigure of BFD done # # checking size of long... 4 checking size of int... 4 checking size of short... 2 checking size of char... 1 checking for number of bits in char... 8 checking whether byte ordering is bigendian... yes checking for sbrk... yes checking for randomized sbrk... no checking for required object alignment... 8 checking for C extension variable alignment... __attribute__ ((aligned (8))) checking TYPE_BITS macro... 0xff09 checking sizeof struct contblock... 8 checking for pagewidth... 13 checking DBEGIN... 0x2 checking CSTACK_ADDRESS... 0xffbf checking NEG_CSTACK_ADDRESS... yes checking finding CSTACK_ALIGNMENT... 8 checking CSTACK_DIRECTION... -1 checking for shared library/C stack ceiling to heap... ./configure: !: not found usage: tail [+/-[n][lbc][f]] [file] tail [+/-[n][l][r|f]] [file] failed This second failure leaves me to believe that someone is assuming a version of GNU tail. I am using a gcc 4.2.2 compiled from sources both times. But thinking about the above issue I do not believe that it is actually the root cause. And some more build tests: 3) OSX 10.5.2 Intel, current XCode 3.0: bsd:gcl mabshoff$ uname -a Darwin bsd.local 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 checking how to switch to text section... .text checking how to switch to data section... .data checking what assembly label suffix to use... : checking how to export a symbol... .globl checking if globals are prefixed by underscore... configure: error: Test program links neither with nor without underscore. # # # # Subconfigure of GMP done # # cp: gmp3/gmp.h: No such file or directory checking for leading underscore in object symbols... yes checking for GNU ld option -Map... no checking for size of gmp limbs... Cannot determine mpsize 4) And the most ironic build failure on an x86-64 Debian box: [EMAIL PROTECTED]:~/gcl$ uname -a Linux sage 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64 GNU/Linux [EMAIL PROTECTED]:~/gcl$ make make: *** No rule to make target `/usr/lib/libbfd.a', needed by `copy_bfd'. Stop. I have hit the same bug months ago with RHEL 4 x86-64, so I am not being the unluckiest person on the planet and check out cvs on the wrong day. On a positive note it build fine on RHEL 5/Itanium. So, in the end I only hope that you can understand why I am more than a little dubious about the build quality of gcl. All these are boxen that build Sage fine [the Solaris boxen need a little help, i.e. about 2,3 fixes, but all that is getting merged back into Sage 3.0.1 or 3.0.2], so this is far from some FUBAR build box where I set gcl up to fail. Regards, Bill Page. Cheers, Michael Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Sun, Apr 20, 2008 at 11:41 PM, mabshoff [EMAIL PROTECTED] wrote: On Apr 21, 7:33 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Apr 21, 6:48 am, Bill Page [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: SNIP GCL uses the C compiler directly. I am not suggesting that GCL is necessarily the right lisp for Sage (or even that Sage needs a lisp compiler at all) but I do rather think you should give GCL another try. I would be glad to try to help you debug the problems on Solaris. In both cases the current CVS checkout out from savannah blows up on Solaris 9 and 10 in the same spot: Solaris 9: # Subconfigure of BFD done # # checking size of long... 4 checking size of int... 4 checking size of short... 2 checking size of char... 1 checking for number of bits in char... 8 checking whether byte ordering is bigendian... yes checking for sbrk... yes checking for randomized sbrk... no checking for required object alignment... 8 checking for C extension variable alignment... __attribute__ ((aligned (8))) checking TYPE_BITS macro... 0xff09 checking sizeof struct contblock... 8 checking for pagewidth... 13 checking DBEGIN... 0x2 checking CSTACK_ADDRESS... 0xffbf checking NEG_CSTACK_ADDRESS... yes checking finding CSTACK_ALIGNMENT... 8 checking CSTACK_DIRECTION... -1 checking for shared library/C stack ceiling to heap... failed Solaris 10: # # Subconfigure of BFD done # # checking size of long... 4 checking size of int... 4 checking size of short... 2 checking size of char... 1 checking for number of bits in char... 8 checking whether byte ordering is bigendian... yes checking for sbrk... yes checking for randomized sbrk... no checking for required object alignment... 8 checking for C extension variable alignment... __attribute__ ((aligned (8))) checking TYPE_BITS macro... 0xff09 checking sizeof struct contblock... 8 checking for pagewidth... 13 checking DBEGIN... 0x2 checking CSTACK_ADDRESS... 0xffbf checking NEG_CSTACK_ADDRESS... yes checking finding CSTACK_ALIGNMENT... 8 checking CSTACK_DIRECTION... -1 checking for shared library/C stack ceiling to heap... ./configure: !: not found usage: tail [+/-[n][lbc][f]] [file] tail [+/-[n][l][r|f]] [file] failed This second failure leaves me to believe that someone is assuming a version of GNU tail. I am using a gcc 4.2.2 compiled from sources both times. But thinking about the above issue I do not believe that it is actually the root cause. And some more build tests: 3) OSX 10.5.2 Intel, current XCode 3.0: bsd:gcl mabshoff$ uname -a Darwin bsd.local 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 checking how to switch to text section... .text checking how to switch to data section... .data checking what assembly label suffix to use... : checking how to export a symbol... .globl checking if globals are prefixed by underscore... configure: error: Test program links neither with nor without underscore. # # # # Subconfigure of GMP done # # cp: gmp3/gmp.h: No such file or directory checking for leading underscore in object symbols... yes checking for GNU ld option -Map... no checking for size of gmp limbs... Cannot determine mpsize 4) And the most ironic build failure on an x86-64 Debian box: [EMAIL PROTECTED]:~/gcl$ uname -a Linux sage 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64 GNU/Linux [EMAIL PROTECTED]:~/gcl$ make make: *** No rule to make target `/usr/lib/libbfd.a', needed by `copy_bfd'. Stop. I have hit the same bug months ago with RHEL 4 x86-64, so I am not being the unluckiest person on the planet and check out cvs on the wrong day. On a positive note it build fine on RHEL 5/Itanium. So, in the end I only hope that you can understand why I am more than a little dubious about the build quality of gcl. All these are boxen that build Sage fine [the Solaris boxen need a little help, i.e. about 2,3 fixes, but all that is getting merged back into Sage 3.0.1 or 3.0.2], so this is far from some FUBAR build box where I set gcl up to fail. In the defense of GCL, *most* components of Sage were a mess like above when I/you/whoever first tried to add them to Sage. I personally haven't tried much using cvs GCL only, partly because it scares me to use cvs for a deployed quality product. Since cvs might be broken one day, not the next, etc., and one has no clue if the code has been tested or not or what. The last released version is from 2005, and it's clear the website is just dead (maybe somebody lost the password?!) I mean, it just looks a little silly for the
[sage-devel] Re: Project
For example, is the fact that GCL doesn't build for us anywhere, something that you think we'll get passed by just trying harder? Or is it going to be really really hard. http://axiom.axiom-developer.org/axiom-website/download.html All versions are built with GCL. I do not have access to a Sparc although GCL has run there in the past. I no longer have access to my Zaurus although GCL has run there in the past. I do have access to an OLPC-XO. I release Axiom every two months so I'm likely to get it working in the next release cycle. GCL runs on windows although I have not spent any time on a windows port. Waldek has, so he might have an opinion. Given what I know about GCL internals I have every reason to believe that it would compile using MS or Borland compilers (modulo a few #ifdefs to pay homage to C). I don't have access to a native C compiler for windows. GCL is just a (big) C program and like every other C program I've ever used, it is sarcasm lang=Ceasily ported/scarcasm. But the actual fact of the matter is that it does run everywhere I've ever tried to make it run. All it requires is the right set of ./configure switches. My collection above includes, I86-32, I86-64, and PowerPC. The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. You claim that you pass problem reports upstream but I don't see many Sage postings to the GCL mailing list. Camm, the GCL maintainer, has always been very responsive and effective in his replies. But, like you, he needs good, clear, effective bug reports. I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? Having spent a fair portion of my life porting software, I understand the frustrations you feel. And having spent the bulk of my life using Lisp I get the get-rid-of-lisp pushback. But a lot of astonishingly good computer algebra exists in lisp (we won't discuss the reasons). Reproducing Axiom's million-things-of-code in Python would be no small task, especially since some of the experts are dead. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? We do compile python from scratch on every platform. It's part of the Sage distribution. +1 for you, -1 for me. t --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 2008, at 12:09 PM, root wrote: I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? We do compile python from scratch on every platform. It's part of the Sage distribution. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Mon, Apr 21, 2008 at 9:09 AM, root [EMAIL PROTECTED] wrote: For example, is the fact that GCL doesn't build for us anywhere, something that you think we'll get passed by just trying harder? Or is it going to be really really hard. http://axiom.axiom-developer.org/axiom-website/download.html All versions are built with GCL. I do not have access to a Sparc although GCL has run there in the past. I no longer have access to my Zaurus although GCL has run there in the past. I do have access to an OLPC-XO. I release Axiom every two months so I'm likely to get it working in the next release cycle. GCL runs on windows although I have not spent any time on a windows port. Waldek has, so he might have an opinion. Given what I know about GCL internals I have every reason to believe that it would compile using MS or Borland compilers (modulo a few #ifdefs to pay homage to C). I don't have access to a native C compiler for windows. GCL is just a (big) C program and like every other C program I've ever used, it is sarcasm lang=Ceasily ported/scarcasm. But the actual fact of the matter is that it does run everywhere I've ever tried to make it run. All it requires is the right set of ./configure switches. It also requires the right set of dependencies. And those themselves can have all kinds of issues My collection above includes, I86-32, I86-64, and PowerPC. The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. You claim that you pass problem reports upstream but I don't see many Sage postings to the GCL mailing list. Camm, the GCL maintainer, has always been very responsive and effective in his replies. But, like you, he needs good, clear, effective bug reports. We chose clisp instead of GCL long ago for a number of reasons, so there's been no reason for me to post to the gcl mailing list. I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? You don't know what you're talking about here. The python build-from-source ecosystem is in much better shape than the lisp one.Python has easily 100 times as many people supporting it as clisp or gcl. Having spent a fair portion of my life porting software, I understand the frustrations you feel. And having spent the bulk of my life using Lisp I get the get-rid-of-lisp pushback. But a lot of astonishingly good computer algebra exists in lisp (we won't discuss the reasons). Reproducing Axiom's million-things-of-code in Python would be no small task, especially since some of the experts are dead. In my opinion the best computer algebra system for research mathematics on the planet is Magma, and it is written in C. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Mon, Apr 21, 2008 at 11:09 AM, root [EMAIL PROTECTED] wrote: GCL runs on windows although I have not spent any time on a windows port. Waldek has, so he might have an opinion. Well, *I* spend considerable time making Axiom buildable on Windows back when I was working on Axiom.build-improvements, which is the basis for both OpenAxiom and Fricas. The build environment requirement is the usual msys/mingw (which makes the life a bit more bearable on that platform, when working with most software based on GNU toolchains).You need on thing: you need to make rsym.exe callable when dumping the final image to disk. rsym.exe is built by GCL but for some reasons (mostly related to pathnames I guess), GCL is unable to find it. See the hack @axiom_gcl_rsym_hack@ I introduced here http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/configure.ac.pamphlet?r1=393r2=395 to be used in: http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/src/lisp/Makefile.in?revision=395view=markup Given what I know about GCL internals I have every reason to believe that it would compile using MS or Borland compilers (modulo a few #ifdefs to pay homage to C). I don't have access to a native C compiler for windows. Please try it for real and tell us how is works, for GCL has a strong dependency on GCC. -- Gaby --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
I get the following error: ;; Compiling ../lsp/gcl_listlib.lsp. ;; End of Pass 1. ;; End of Pass 2. ;; OPTIMIZE levels: Safety=3, Space=0, Speed=3, (Debug quality ignored) ;; Finished compiling ../lsp/gcl_listlib.o. ;; Loading /opt/sage-3.0.alpha6/spkg/build/gcl-20080421/src/lsp/gcl_listlib.o __stack_chk_fail is undefined Error: ERROR Cannot get relocated section contents Fast links are on: do (si::use-fast-links nil) for debugging Signalled by LOAD1. ERROR Cannot get relocated section contents Broken at LOAD1. Type :H for Help. make: *** [unixport/saved_pre_gcl] Error 255 Error building GCL. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 6:09 pm, root [EMAIL PROTECTED] wrote: SNIP Hi Tim, The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. You claim that you pass problem reports upstream but I don't see many Sage postings to the GCL mailing list. Camm, the GCL maintainer, has always been very responsive and effective in his replies. But, like you, he needs good, clear, effective bug reports. Yes, I can certainly agree with you on that one. Detailed bug reports are required to get anything fixed. But I get paid to do a job: * port Sage to Solaris * support Sage on Linux/Itanium * port Sage to Windows While I am at it I do a number of other Sage related jobs: * play a release manager * hunt down memory leaks in general * port Sage to FreeBSD * port Sage to Linux/Sparc * port Sage to Linux/PPC64 When I am done with the above [i.e. in the evening ;)] I would really, really like to do: * audit Singular for memory leaks with its test suite and fix those bugs ;) * get deeply into PolyBoRi and help dealing with their memory management issues * compile gcc 4.4CVS [or whatever is next] and make Sage build with it. After fixing all the bugs push them upstream [I did many of those with gcc 4.3 about six months ago, but only finished pushing the fixes in 3.0] The above three tasks are something that gives me credit with my peers and would certainly benefit me and my reputation in the CAS community [at least with many algebra people ;)]. Now let's contrast this with gcl: * gcl is a mature project, i.e. it should just work out of the box most of the time * It *should* build on the vast majority of platforms that it claims it supports. Reality: there are many, many problems - and that is with me not being an ass and deliberately doing something stupid on purpose Looking at the above lists you will hopefully understand that I have no interest in working on gcl since doing efficient bug reporting would require that I get familiar with the code. I would likely get into it since I could fix many of those bugs myself. But since I have no interest in lisp and would like to spend my time on projects where I would I personally know the people and share common goals with I will not do that. To put it nicely: gcl is stagnating. The last release was in 2005 [not 5 years ago like I mistakenly claimed]. If the lisp community would be a large thriving community *I* wouldn't have to do anything about that issue, but you would likely have had some release since 2005 and many of the problems I saw would have already been solved, i.e. it would just work. Am I wrong to assume that the gcl community does not have access to a reasonably large number of non-Linux boxen? I spend a huge amount of time on any exotic and not so exotic build problem with Sage, hence I expect other projects to do the same thing. If that is not the case I will not use their code and due to the insane number of issues with clisp, gcl and so on I have drawn the conclusion that Sage without a lisp dependency in its core [i.e. code I am getting paid to support] would be a better Sage. That doesn't mean that Sage will not be very accommodating to say Maxima, Axiom, FriCAS and OpenAxiom via an optional lisp package, but as long as they depend on lisp [forever would be my guess here] I do not see a chance for them to stay in the core or become part of the core long term. Prove me wrong: Get gcl to build out of the box on various Linuxes [with gcc], Solaris 9, 10 with Sun Forte, OSX 10.4, 10.5 with XCode [no stupid MacPorts here] and Windows with MSVC and I will be the first guy to help you out. I see ecls potentially in that role, but as long as it isn't supported in Maxima I see no urgent reason to spend any work on that. But I have dealt with the ecls maintainer, both by reporting problems and submitting patchlets, so I know he is up to the job. He for example already uses MSVC on Windows to build ecls, so he is far ahead of any other Open Source lisp AFAIK. That gives me hope since his goals and understanding of the importance to support non-gcc compilers are very much aligned to my personal opinions. I think you'd feel the same frustrations with Python if you compiled Python from scratch for every platform. You ship sources but assume that the python language exists and is compatible, which is not likely to be the case when 3.0 arrives. If you can assume the python language, why can't you assume the lisp language? If you can't assume the lisp language, why can you assume the python language? As others have pointed out already we do build Python from source. Once Python 2.6 comes out [in parallel with Python 3K] we will migrate first to 2.6 and then likely to 3.0 at some point. But since we build Python we control our own destiny here. Having spent a fair portion of my life porting software, I understand
[sage-devel] Re: Project
Having spent a fair portion of my life porting software, I understand the frustrations you feel. And having spent the bulk of my life using Lisp I get the get-rid-of-lisp pushback. But a lot of astonishingly good computer algebra exists in lisp (we won't discuss the reasons). Reproducing Axiom's million-things-of-code in Python would be no small task, especially since some of the experts are dead. Well, many things are available in non-lisp CASes and many of them are in Sage, so it isn't that Sage without Axiom isn't viable [not that you implied that]. If a sufficient number of people want Lisp to remain a significant player in the CAS world [and computer science in general] it will be so. We are not forcing you to use Python or Sage. This is all about what tool gets the job done for you and in your case it is Axiom ;) Well, Sage doesn't actually use Axiom. William has no long term focus except to compete with the 4Ms. Sage doesn't use GCL. And the project is strongly motivated to elide lisp. Except for my involvement in the Sage program committee for the Nancy conference, I don't see that I can be of much help. Sorry for the noise. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 20, 5:55 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. Aside from just getting stuff linked together (plenty of trouble to start with), the more difficult problem is that Maxima is written with a pervasive assumption that there is someone at the console, e.g you ask for an integral or a limit and Maxima comes back with a question about some parameter. That make interaction with another program very difficult (as I think you know already). I have attempted to resolve this by converting questions into conditional expressions e.g. Is x positive, negative, or zero? = if x 0 then ... elseif x 0 then ... else It sort of works but there are difficulties. If anyone wants to work on it with me, I'd be glad to have the help. Robert Dodier Maxima developer --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 11:48 pm, Robert Dodier [EMAIL PROTECTED] wrote: On Apr 20, 5:55 pm, mabshoff [EMAIL PROTECTED] Hi Robert, dortmund.de wrote: I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. Aside from just getting stuff linked together (plenty of trouble to start with), Sure, that is an issue, but you can't fail if you don't try ;) the more difficult problem is that Maxima is written with a pervasive assumption that there is someone at the console, e.g you ask for an integral or a limit and Maxima comes back with a question about some parameter. That make interaction with another program very difficult (as I think you know already). Yes, I never had to deal with it via the pexpect interface in Sage, but others certainly have. I have attempted to resolve this by converting questions into conditional expressions e.g. Is x positive, negative, or zero? = if x 0 then ... elseif x 0 then ... else It sort of works but there are difficulties. If anyone wants to work on it with me, I'd be glad to have the help. I cannot pledge anybody else's time here and I don't see any time for myself opening up soon to work on this end of the problem. But I read your message on fricas-devel about ecls support for Maxima and I am certainly willing to help make that happen and test ecls build and building Maxima on top of ecls on a wide range of platforms. I am also willing to work on ecls itself and fix potential portability issues. On top of that once ecls+Maxima works I will also likely lead the push to get that combo merged into Sage. There are some other issues you mention in your email to fricas-devel, but I will answer them over there. Robert Dodier Maxima developer Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
William suggested I forward/post the stuff I wrote on fricas-devel over there, too. Since his wish is my command ;) here we go: On Apr 21, 9:46 pm, Robert Dodier [EMAIL PROTECTED] wrote: On Apr 20, 9:29 am, William Stein [EMAIL PROTECTED] wrote: Hello folks, c) ecls: the ray of hope? Bug Maxima can't be build on top of it due to same issues with save and load image. Well, if there is any interest in resolving the problems, let's join forces then. I got Maxima compiled by ECLS some months ago; there were some problems but if there is enough interest, I would be willing to try again. This is excellent news. As I wrote in this thread over on sage-devel I am willing to put some serious time into getting ecls to build on Sage's current and future supported platforms as well do serious testing that Maxima works on top of it. And it certainly sounds like FriCAS would not mind ecls being in Sage per default instead of clisp since the clisp we shop seems to be too broken to support FriCAS. The current plan is to rewrite symbolic manipulation in Cython using lots of tricks so it will be very fast, flexible, and not depend on Maxima at all. I have an agenda to push here, so you can take this with a grain of salt, but: Lisp was invented in part to do the kind of expression mogrification which is needed for symbolic algebra. A symbolic system written in some other language is probably going to replicate a lot of Lisp functionality. I am pretty sure that trying to get Maxima recompiled with some/any Lisp implementation will be easier than reinventing both Maxima and Lisp. Well, we are looking at several problems here: a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue some commands and parse the results. While that is something that works well for say integrals or ODEs it is a huge performance drain on arithmetic. For example: Moving some operation on permutation groups form GAP+pexpect to Cython made the operation 4,000 times as fast. The implementation in Cython is roughly 3 times slower than the same operation in the GAP kernel, but since pexpect is out of the equation the somewhat slower Cython implementation is a huge win since we have not connected the GAP kernel to Sage as a library. Nobody has attempted to do that, but it will likely be quite a bit of work and a large effort. b) Using Maxima in itself is not bad and the thread that started this whole discussion was motivated by build issues with self hosted lisp. Since Maxima is written in lisp and the only reason we ship lisp currently with Sage my desire was to solve the lisp build problem and Maxima would have ended up as potential road kill in the process. c) Maxima has a lot of well debugged, well working code, but it seems for many things the 4 Ms are much faster. Factorization is one example, I am not quite clear how Integration compares, but my general impression from alt.sci.symbolic is that it is not on par with the commercial systems [feel free to correct me]. d) Sage itself wants to compete with the 4Ms, but it isn't the only Open Source CAS out there, in fact it is a quite young effort and William's method called for building on top of existing systems. But while he went through what I call the rapid expansion phase it was more important to get things working than to implement because doing things right as you point out would take many, many man years of effort. But now people are demanding more performance and due to (a) symbolic arithmetic is being rewritten. And according to Gary [the guy implementing it] it is much faster than Maxima [even accounting for clisp vs. sbcl and so on]. I cannot verify the number but since he is quite serious about the issue and he really, really *needs* fast symbolics I have little reason to doubt him. So, now the question is: Why doesn't he work with the Maxima code then and improve it there. Everybody would benefit [Sage Maxima] and all the higher level algorithms would likely get a boost by it. And the answer is: Because he prefers not to use lisp and that is something that is completely up to him. It is difficult to recruit developers and most people in Sage prefer C/C++/Python/Cython over list just like Maxima developers prefer lisp. Both camps are self selecting, so no surprises there. But to get back to the issue at hand: Once Maxima runs on ecls nearly all the issues I have with the build side of things will likely evaporate and I will put my energy toward other issues. It would likely also lessen the drive to get rid of Maxima considerably, but I am certain that over the next couple years more and more functionality that Maxima provides by Sage will be implemented on top of other systems unless Maxima gets faster. Systems inside Sage compete and it would be naive to believe that Sage does not compete will all its components for users as well as developers. But in the end Sage is supposed to be inclusive and should function as a unifying force of
[sage-devel] Re: Project
Thank you very much for agreeing to work on this Michael. Way down the road, thin will be a big deal i think. On Mon, Apr 21, 2008 at 8:45 PM, mabshoff [EMAIL PROTECTED] wrote: William suggested I forward/post the stuff I wrote on fricas-devel over there, too. Since his wish is my command ;) here we go: On Apr 21, 9:46 pm, Robert Dodier [EMAIL PROTECTED] wrote: On Apr 20, 9:29 am, William Stein [EMAIL PROTECTED] wrote: Hello folks, c) ecls: the ray of hope? Bug Maxima can't be build on top of it due to same issues with save and load image. Well, if there is any interest in resolving the problems, let's join forces then. I got Maxima compiled by ECLS some months ago; there were some problems but if there is enough interest, I would be willing to try again. This is excellent news. As I wrote in this thread over on sage-devel I am willing to put some serious time into getting ecls to build on Sage's current and future supported platforms as well do serious testing that Maxima works on top of it. And it certainly sounds like FriCAS would not mind ecls being in Sage per default instead of clisp since the clisp we shop seems to be too broken to support FriCAS. The current plan is to rewrite symbolic manipulation in Cython using lots of tricks so it will be very fast, flexible, and not depend on Maxima at all. I have an agenda to push here, so you can take this with a grain of salt, but: Lisp was invented in part to do the kind of expression mogrification which is needed for symbolic algebra. A symbolic system written in some other language is probably going to replicate a lot of Lisp functionality. I am pretty sure that trying to get Maxima recompiled with some/any Lisp implementation will be easier than reinventing both Maxima and Lisp. Well, we are looking at several problems here: a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue some commands and parse the results. While that is something that works well for say integrals or ODEs it is a huge performance drain on arithmetic. For example: Moving some operation on permutation groups form GAP+pexpect to Cython made the operation 4,000 times as fast. The implementation in Cython is roughly 3 times slower than the same operation in the GAP kernel, but since pexpect is out of the equation the somewhat slower Cython implementation is a huge win since we have not connected the GAP kernel to Sage as a library. Nobody has attempted to do that, but it will likely be quite a bit of work and a large effort. b) Using Maxima in itself is not bad and the thread that started this whole discussion was motivated by build issues with self hosted lisp. Since Maxima is written in lisp and the only reason we ship lisp currently with Sage my desire was to solve the lisp build problem and Maxima would have ended up as potential road kill in the process. c) Maxima has a lot of well debugged, well working code, but it seems for many things the 4 Ms are much faster. Factorization is one example, I am not quite clear how Integration compares, but my general impression from alt.sci.symbolic is that it is not on par with the commercial systems [feel free to correct me]. d) Sage itself wants to compete with the 4Ms, but it isn't the only Open Source CAS out there, in fact it is a quite young effort and William's method called for building on top of existing systems. But while he went through what I call the rapid expansion phase it was more important to get things working than to implement because doing things right as you point out would take many, many man years of effort. But now people are demanding more performance and due to (a) symbolic arithmetic is being rewritten. And according to Gary [the guy implementing it] it is much faster than Maxima [even accounting for clisp vs. sbcl and so on]. I cannot verify the number but since he is quite serious about the issue and he really, really *needs* fast symbolics I have little reason to doubt him. So, now the question is: Why doesn't he work with the Maxima code then and improve it there. Everybody would benefit [Sage Maxima] and all the higher level algorithms would likely get a boost by it. And the answer is: Because he prefers not to use lisp and that is something that is completely up to him. It is difficult to recruit developers and most people in Sage prefer C/C++/Python/Cython over list just like Maxima developers prefer lisp. Both camps are self selecting, so no surprises there. But to get back to the issue at hand: Once Maxima runs on ecls nearly all the issues I have with the build side of things will likely evaporate and I will put my energy toward other issues. It would likely also lessen the drive to get rid of Maxima considerably, but I am certain that over the next couple years more and more functionality that
[sage-devel] Re: Project
On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote: ... In the defense of GCL, *most* components of Sage were a mess like above when I/you/whoever first tried to add them to Sage. I personally haven't tried much using cvs GCL only, partly because it scares me to use cvs for a deployed quality product. Since cvs might be broken one day, not the next, etc., and one has no clue if the code has been tested or not or what. The last released version is from 2005, and it's clear the website is just dead (maybe somebody lost the password?!) I mean, it just looks a little silly for the website (http://www.gnu.org/software/gcl/) to start with: NEW! (20050810) GCL 2.6.7 is released. The release notes can be found here. ... The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. No doubt about it - GCL does not have sufficient resources for maintenance and has been somewhat neglected of late. As you say: It is not a situation that you find entirely uncommon among the packages that have been added to Sage in the past. Necessity is what drives most of this kind of work. I've made a gcl Sage optional spkg: http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg It's just GCL-from-cvs + a simple spkg-install. I have never got it to build on any system. It's a pretty big spkg, since it appears to include the entire gas assembler, some version of GMP, etc. Try it out and see if it *doesn't* work for you too :-) wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg sage -i gcl-20080421.spkg Thanks. It doesn't work for me either. :-( You are right that the source is bloated by a bunch of code that it does not use. As I understand it gcl needs only a small part of binutils - depending on the build options for a particular system. Is this source from cvs head at: http://savannah.gnu.org/projects/gcl/ as of today? This version of GCL fails on my Solaris x86 system with the following obscure error message: gcc -c -fsigned-char -pipe -Wall -O3 -fomit-frame-pointer -I/export/home0/wspa ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c cmpaux.c: In function `object_to_fcomplex': cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function) cmpaux.c:329: error: (Each undeclared identifier is reported only once cmpaux.c:329: error: for each function it appears in.) cmpaux.c: In function `object_to_dcomplex': cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function) gmake[1]: *** [cmpaux.o] Error 1 rm list.c gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o' gmake: *** [unixport/saved_pre_gcl] Error 2 --- At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl' I see changes as recent as 3 months ago. The last time I built GCL from head was about 10 months ago. The most recent branch 'Version_2_6_8pre' is what we normally use to build Axiom. There is a change about 4 months old. If I recall correctly 'Version_2_6_8pre' actually corresponds to the version distributed on Debian and would probably be the most likely to be stable on the largest number of platforms. Bill Page -- I would be interested in any comments you might have. For example, is the fact that GCL doesn't build for us anywhere, something that you think we'll get passed by just trying harder? Or is it going to be really really hard. The fact that it doesn't build for you anywhere is definitely strange. I would give it a try again with $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gcl co -r Version_2_6_8pre gcl I do expect that (with the right help) you will be able to build gcl everywhere that you build Sage. Instead of just trying harder I think it is very appropriate to ask for help. Only if there is no help forthcoming, perhaps I would agree that the problems might be of a kind that you will not be able to get passed just by trying harder. I expect that like me, you would find the learning curve for the GCL source code very high. -- Now since you asked, maybe I should take a deep breath and try to explain my personal views on this subject... I am in fact fully sympathetic with the expressed desire to eliminate Lisp from Sage. As you may know, I am also in favor of eliminating Lisp from Axiom! I believe that was the direction in which Axiom was headed when it was last sold as commercial software and would have very much preferred it if that development had continued. The Aldor compiler (written in C) was positioned to replace the exising library compiler for Axiom. Aldor could be targeted to produce either Lisp or object code linked into a C run-time environment based on an abstract machine specification (FOAM). Also the version of Lisp underlying the commercial version of Axiom (CCL) was heavily modified and optimized as the
[sage-devel] Re: Project
On Apr 20, 8:13 pm, TimDaly [EMAIL PROTECTED] wrote: SNIP Hi Tim, There are rumblings but *definitely* no specific plans to remove lisp or maxima. Lisp has already solved a lot of the problems Python has yet to face. Sure, but how about reading Lisp: Good News, Bad News, How to Win Big from 1991 at http://www.dreamsongs.com/WIB.html While I disagree with the author on many points, i.e. calling Unix bad names and so, the interesting comment is: The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C+ +. How prophetic ;) But since that discussion is a prelude to a language war I'll end it here. Well, this isn't about a language war, i.e. $FOO is better than $BAR at solving some programming problem. This is fundamentally about the lisp ecosystem, i.e. how viable is the Open Source lisp tool world. And I have build numerous lisp implementations on a wide range of platforms and compared to building C, C++, Fortran compilers or Python itself there are numerous problems. I have often said that your whole ecosystem cannot be viable if your fundamental tools are hanging on by a thread. After I posted about *my* intention to make clisp disappear from Sage in the long term at alt.sci.symbolic William and I got in a long off list discussion with Fateman about Maxima, Axiom, Sage and lisp in general. Among the point Fateman made about me pointing out that building lisp from source sucked were: He never had to build lisp from source, so what is the problem? That is so short sighted it isn't even funny, i.e. water comes out of the spout, electricity is supplied by the socket in the wall. And I can only say the the Open Source lisp community is far behind on its tools and since it has been decades where the situation has either stagnated or gotten worse I don't see much of a future there. Compare the vitality of the lisp machine vs. gcc, compare the support gcc experiences by companies like Apple and IBM which are very interested in it succeeding. Where is the lisp support? lisp in itself is no better or worst than Python and assuming one is a master at a given language one will likely will write a better program than a n00b or bad programmer in a competing language. In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. I am porting Sage to Linux/PPC 64 [PPC 32 works] and Linux/Sparc[32|64] at the moment and once we get access to AIX runnning on Power64 I will also port Sage to it. I have even been thinking about porting it to OSX/ARM, i.e. the iPhone. We have started on the Sage/MSVC 32 and 64 bit ports to Windows. In each of those cases clisp will be a pain to deal with. ecls could fill the gap and I would personally throw a huge effort in making sure ecls does build and work on all of those platforms and all platforms Sage already supports assuming Maxima would work with it. So, the ball is in your court. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
After I posted about *my* intention to make clisp disappear from Sage in the long term at alt.sci.symbolic William and I got in a long off list discussion with Fateman about Maxima, Axiom, Sage and lisp in general. Among the point Fateman made about me pointing out that building lisp from source sucked were: He never had to build lisp from source, so what is the problem? Richard was deeply involved in lisp and knows a fair bit about the subject, more than he lets on, but that's up to him to defend. I have great respect for his opinions. I helped William Schelter in the development of GCL back when it was known as AKCL. He used my office often during his visits and we worked closely on portions of its development. I have written parts of the garbage collector and some other small pieces so I'm intimately familiar with the guts of it. That is so short sighted it isn't even funny, i.e. water comes out of the spout, electricity is supplied by the socket in the wall. And I can only say the the Open Source lisp community is far behind on its tools ... eh? really? not for me. but that way lies language-wars so lets stop. In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. I'm sure you have good reasons for choosing ECLS but I don't understand. Frankly, I'd think that it would be straightforward to write a python compiler in lisp (if only the EU would give me the $20M Euro it gave the other project). Once that was done you could compile and optimize the python automatically. My son implemented a commercially available PHP compiler in lisp in under 3 years and python is about the same complexity. In fact, if I were still teaching the compiler course, I'd assign it as a class project. Until python has a decent compiler I have trouble considering it anything more than MS-basic with classes. (And that, of course, is certainly NOT gonna make me popular). Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
Dear Tim! On Mon, Apr 21, 2008 at 12:46 AM, TimDaly [EMAIL PROTECTED] wrote: After I posted about *my* intention to make clisp disappear from Sage in the long term at alt.sci.symbolic William and I got in a long off list discussion with Fateman about Maxima, Axiom, Sage and lisp in general. Among the point Fateman made about me pointing out that building lisp from source sucked were: He never had to build lisp from source, so what is the problem? Richard was deeply involved in lisp and knows a fair bit about the subject, more than he lets on, but that's up to him to defend. I have great respect for his opinions. I helped William Schelter in the development of GCL back when it was known as AKCL. He used my office often during his visits and we worked closely on portions of its development. I have written parts of the garbage collector and some other small pieces so I'm intimately familiar with the guts of it. That is so short sighted it isn't even funny, i.e. water comes out of the spout, electricity is supplied by the socket in the wall. And I can only say the the Open Source lisp community is far behind on its tools ... eh? really? not for me. but that way lies language-wars so lets stop. In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. I'm sure you have good reasons for choosing ECLS but I don't understand. Frankly, I'd think that it would be straightforward to write a python compiler in lisp (if only the EU would give me the $20M Euro it gave the other project). Once that was done you could compile and optimize the python automatically. My son implemented a commercially available PHP compiler in lisp in under 3 years and python is about the same complexity. In fact, if I were still teaching the compiler course, I'd assign it as a class project. Until python has a decent compiler I have trouble considering it anything more than MS-basic with classes. (And that, of course, is certainly NOT gonna make me popular). just speaking for myself here: another way at looking at things is that I want to use today's (maybe imperfect) tools and today's (maybe busy) people and I want to get something useful (maybe imperfect) today. And the beauty of it is to manage everything just right to get something useful out of it, that people actually find interesting and usable. Yes, I love to live just now. :) Also I love the Linus quote Talk is cheap. Show me the code.. So it's nice it's maybe theoretically possible to write a python interpreter in lisp, but right now, at this very moment, there is no such thing in Debian, so that is not a technology for me. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 12:46 am, TimDaly [EMAIL PROTECTED] wrote: Hi Tim, After I posted about *my* intention to make clisp disappear from Sage in the long term at alt.sci.symbolic William and I got in a long off list discussion with Fateman about Maxima, Axiom, Sage and lisp in general. Among the point Fateman made about me pointing out that building lisp from source sucked were: He never had to build lisp from source, so what is the problem? Richard was deeply involved in lisp and knows a fair bit about the subject, more than he lets on, but that's up to him to defend. I have great respect for his opinions. Well, some times he is right, some times he is wrong. That is just the nature of things. I helped William Schelter in the development of GCL back when it was known as AKCL. He used my office often during his visits and we worked closely on portions of its development. I have written parts of the garbage collector and some other small pieces so I'm intimately familiar with the guts of it. I do not doubt that gcl is a good tool, but I doubt it is a good tool to use in Sage. That is so short sighted it isn't even funny, i.e. water comes out of the spout, electricity is supplied by the socket in the wall. And I can only say the the Open Source lisp community is far behind on its tools ... eh? really? not for me. but that way lies language-wars so lets stop. We might measure viability by different standards - let's just leave it at that ;) In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. No, it fails to build on Solaris and since Sage on Solaris is of essential importance we will/cannot use it. It used to be quite bad on OSX, but it has gotten much better there. I am certain I can get some sort of lisp running on pretty much any system, but that is not the Sage way. We want a self hosted, compile from source anywhere lisp that Maxima supports and we are now talking about the empty set. Feel free to prove me wrong, I would be very, very happy to be proven wrong on this. Ironically the most portable lisp implementation is the one in Emacs, but I don't think it is common lisp. I'm sure you have good reasons for choosing ECLS but I don't understand. I just works with little need to do have a magic lisp machine working since it uses a C compiler directly. Frankly, I'd think that it would be straightforward to write a python compiler in lisp (if only the EU would give me the $20M Euro it gave the other project). PyPy sucks and blows at the same time. Throwing money at a problem never solved it. I am sure you have read the mythical man month. ;) Once that was done you could compile and optimize the python automatically. My son implemented a commercially available PHP compiler in lisp in under 3 years and python is about the same complexity. Sure, I am not saying it is impossible. Some people (like you and Fateman) prefer lisp and think it is the answer. But if I look around at people at the university level or a couple years out of it there is very, very little lisp. So, while the absolute number of lisp programmers might have grown over the years its part of the programming market has shrunk since the programming market has gotten so much bigger. The beautiful thing about Open Source is that as long as one person cares a project does not die. But that doesn't mean that lisp+Sage is a good match ;) In fact, if I were still teaching the compiler course, I'd assign it as a class project. Until python has a decent compiler I have trouble considering it anything more than MS-basic with classes. (And that, of course, is certainly NOT gonna make me popular). Tim Well, I don't see lisp making a come back any time soon. People have done a python to lisp machine port but it never got very far and there is quite a difference between something that works for me to something that works! - I experience this daily with Sage and it is hard, hard work to make Sage run and compile beyond the normal Linux OSX mix. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 12:46 am, TimDaly [EMAIL PROTECTED] wrote: SNIP Hi Tim, I have no idea why you think ECLS is a silver bullet. I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Sun, Apr 20, 2008 at 4:22 PM, mabshoff [EMAIL PROTECTED] wrote: In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. No, it fails to build on Solaris and since Sage on Solaris is of essential importance we will/cannot use it. It used to be quite bad on OSX, but it has gotten much better there. I am certain I can get some sort of lisp running on pretty much any system, but that is not the Sage way. We want a self hosted, compile from source anywhere lisp that Maxima supports and we are now talking about the empty set. Feel free to prove me wrong, I would be very, very happy to be proven wrong on this. Ironically the most portable lisp implementation is the one in Emacs, but I don't think it is common lisp. I'm sure you have good reasons for choosing ECLS but I don't understand. I just works with little need to do have a magic lisp machine working since it uses a C compiler directly. Frankly, I'd think that it would be straightforward to write a python compiler in lisp (if only the EU would give me the $20M Euro it gave the other project). PyPy sucks and blows at the same time. Throwing money at a problem never solved it. I am sure you have read the mythical man month. ;) Once that was done you could compile and optimize the python automatically. My son implemented a commercially available PHP compiler in lisp in under 3 years and python is about the same complexity. Sure, I am not saying it is impossible. Some people (like you and Fateman) prefer lisp and think it is the answer. But if I look around at people at the university level or a couple years out of it there is very, very little lisp. So, while the absolute number of lisp programmers might have grown over the years its part of the programming market has shrunk since the programming market has gotten so much bigger. This webpage has a ranking of programming language popularity, which might be a bit more scientific then the above anecdotal when I look around. This page is for the following purpose: The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html It goes: Java, C, Visual Basic, PHP, C++, Perl, Python then C#, Ruby, Delphi, Javascript, D, PL/SQL, then SAS, Pascal, Lisp/Scheme, FoxPro, Cobol, ADA, so lisp is number 17. In raw numbers Python is ten times as popular as Lisp and Scheme. In the next group (below 20) is: ColdFusion, Logo, Lua, ActionScript, FORTRAN, RPG, Matlab, Prolog, AWK, ... and R is at 45th. -- William The beautiful thing about Open Source is that as long as one person cares a project does not die. But that doesn't mean that lisp+Sage is a good match ;) Also projects (even closed ones) can die and be resurrected. Maybe Scratchpad/Axiom an example of such a project... That's a good thing. In fact, if I were still teaching the compiler course, I'd assign it as a class project. Until python has a decent compiler I have trouble considering it anything more than MS-basic with classes. (And that, of course, is certainly NOT gonna make me popular). Tim Well, I don't see lisp making a come back any time soon. People have done a python to lisp machine port but it never got very far and there is quite a difference between something that works for me to something that works! - I experience this daily with Sage and it is hard, hard work to make Sage run and compile beyond the normal Linux OSX mix. Disagree with Michael about porting/building issues at your own peril. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
I have no idea why you think ECLS is a silver bullet. I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. I looked at pexpect. It appears to be a process controller of sorts that interprets and parses console I/O. Axiom has its own version called sman (superman). You don't normally type directly at the axiom command prompt but are talking to sman which mediates the console i/o. Sman manages a set of processes (the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes it appear that you are talking to axiom. You could talk directly to the AXIOMsys system prompt or directly to AXIOMsys thru a network port (which is how the Axiom Firefox works). But sman doesn't actually parse anything at all. It is just a very small C program which forks processes and sets up ptys and thus has nearly zero overhead. I'm not sure what Maxima does. But I'd bet that almost all of the overhead you're seeing isn't Maxima but pexpect delay. Somebody is probably playing parsing games to get prompt and end-of-input processing and that has got to cost a lot. Why not just reach into the lisp and do it directly? Why use a console connection at all? Using pexpect has got to be the worst of all possible ways to talk to Maxima. In any case, it is certainly possible to use lisp as a library element rather than using pexpect. I'm not sure why ECLS is special in this context since I've never used it. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Sun, Apr 20, 2008 at 6:38 PM, root [EMAIL PROTECTED] wrote: I have no idea why you think ECLS is a silver bullet. I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. I looked at pexpect. It appears to be a process controller of sorts that interprets and parses console I/O. Axiom has its own version called sman (superman). You don't normally type directly at the axiom command prompt but are talking to sman which mediates the console i/o. Sman manages a set of processes (the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes it appear that you are talking to axiom. You could talk directly to the AXIOMsys system prompt or directly to AXIOMsys thru a network port (which is how the Axiom Firefox works). But sman doesn't actually parse anything at all. It is just a very small C program which forks processes and sets up ptys and thus has nearly zero overhead. I'm not sure what Maxima does. But I'd bet that almost all of the overhead you're seeing isn't Maxima but pexpect delay. Are you saying that all the *overhead* we're seeing with communicating with Maxima via pexpect is overhead associated with pexpect? That's kind of circular. Somebody is probably playing parsing games to get prompt and end-of-input processing and that has got to cost a lot. Why not just reach into the lisp and do it directly? How does one just reach into lisp? Why use a console connection at all? Using pexpect has got to be the worst of all possible ways to talk to Maxima. Sort of like how democracy is the worst of all possible governments that work or something. Anyway, one bonus of using Maxima via pexpect is that it works, and moreover almost the same code that works for this works for using about 15 other math software systems from Sage in almost exactly the same way. In any case, it is certainly possible to use lisp as a library element rather than using pexpect. That's great news. Could you implement using lisp as a library element from python? Thanks. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 3:38 am, root [EMAIL PROTECTED] wrote: I have no idea why you think ECLS is a silver bullet. Hi Tim, I forgot one important argument here: With ecls you can embed the lisp interpreter into an external library, hence we would be able to use Maxima as a library instead of using the inefficient pexpect interface. I am not sure how much work this would be, but if I were a Maxima coder I would certainly look into that possibility since it opens a whole lot of possibilities for Maxima IMHO - totally independent of Maxima's role in Sage. I looked at pexpect. It appears to be a process controller of sorts that interprets and parses console I/O. correct. Axiom has its own version called sman (superman). You don't normally type directly at the axiom command prompt but are talking to sman which mediates the console i/o. Sman manages a set of processes (the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes it appear that you are talking to axiom. You could talk directly to the AXIOMsys system prompt or directly to AXIOMsys thru a network port (which is how the Axiom Firefox works). But sman doesn't actually parse anything at all. It is just a very small C program which forks processes and sets up ptys and thus has nearly zero overhead. Well, what do you send via the socket or via the commandline? It must be some kind of ASCII I assume. I'm not sure what Maxima does. But I'd bet that almost all of the overhead you're seeing isn't Maxima but pexpect delay. Somebody is probably playing parsing games to get prompt and end-of-input processing and that has got to cost a lot. Why not just reach into the lisp and do it directly? Why use a console connection at all? Using pexpect has got to be the worst of all possible ways to talk to Maxima. Using a socket here doesn't solve the problem. Using Maxima via ecls embedded in a library offers the possibility to work directly with the data without the need to translate anything [unless you want to get you data back into Sage structures or the other way around]. It would also kill synchronization issues that crop up with pexpect for example. In any case, it is certainly possible to use lisp as a library element rather than using pexpect. I'm not sure why ECLS is special in this context since I've never used it. I am not aware of any other lisp interpreter that you can easily embed in a C library. Can you point me to one? Tim Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: ... I do not doubt that gcl is a good tool, but I doubt it is a good tool to use in Sage. ... In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. Tim Daly wrote: I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. ?? The Debian arm version of Axiom installs on Zaurus without problems. As far as I know all of the Debian Axiom builds were done by Camm Maguire who is also the primary maintainer of GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. I am not so sure one could honestly say that it is actively maintained, but I would have to agree that Camm Maguire is usually very responsive. No, it fails to build on Solaris and since Sage on Solaris is of essential importance we will/cannot use it. That is strange. I have built recent versions of GCL from cvs on Solaris 10 - both sparc and x86 - without problems. I am using the gnu tool chain from Blastwave. Have you contacted Camm Maguire about the problems you are having? ... I just works with little need to do have a magic lisp machine working since it uses a C compiler directly. GCL uses the C compiler directly. I am not suggesting that GCL is necessarily the right lisp for Sage (or even that Sage needs a lisp compiler at all) but I do rather think you should give GCL another try. I would be glad to try to help you debug the problems on Solaris. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
On Apr 21, 6:48 am, Bill Page [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: Hi Bill, I do not doubt that gcl is a good tool, but I doubt it is a good tool to use in Sage. ... In the end it all boils down to platform support and I see ecls as the silver bullet here for Sage+lisp. Tim Daly wrote: I have no idea why you think ECLS is a silver bullet. Three years ago I moved Axiom onto the handheld Zaurus using GCL. ?? The Debian arm version of Axiom installs on Zaurus without problems. As far as I know all of the Debian Axiom builds were done by Camm Maguire who is also the primary maintainer of GCL. And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima runs (fast) using GCL. Why do you want to move off that platform? It contains everything you need, it builds from source, it is actively maintained, and is very fast. I am not so sure one could honestly say that it is actively maintained, but I would have to agree that Camm Maguire is usually very responsive. No, it fails to build on Solaris and since Sage on Solaris is of essential importance we will/cannot use it. That is strange. I have built recent versions of GCL from cvs on Solaris 10 - both sparc and x86 - without problems. I am using the gnu tool chain from Blastwave. Have you contacted Camm Maguire about the problems you are having? I am using my own gcc 4.2.2 based toolchain and binutils build on Solaris 9. It builds every other components of Sage unlike the Blastwave toolchain ;) ... I just works with little need to do have a magic lisp machine working since it uses a C compiler directly. GCL uses the C compiler directly. I am not suggesting that GCL is necessarily the right lisp for Sage (or even that Sage needs a lisp compiler at all) but I do rather think you should give GCL another try. I would be glad to try to help you debug the problems on Solaris. I will try it out. Should gsl build on Solaris I am more than willing to try switching away from clisp. Let me give it a whirl and see what happens. Regards, Bill Page. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
