On Fri, Apr 17, 2009 at 1:07 AM, mabshoff <mabsh...@googlemail.com> wrote: > > > > On Apr 17, 12:58 am, Ondrej Certik <ond...@certik.cz> wrote: >> On Fri, Apr 17, 2009 at 12:21 AM, mabshoff <mabsh...@googlemail.com> wrote: > > <SNIP> > >> > If SAGE_ROOT is already set sage aborts: >> >> Ah, so I think I smell where the problem is --- I broke the SAGE_ROOT >> stuff. When I fix it, which I have to fix anyway, thing should start >> working. > > Good. > >> >> If there is, could I fix it by introducing a variable to notebook() >> >> that would control this? >> >> > Do you still want to do that? The fewer config options there are the >> > better it is ;) >> >> No, I just didn't know where the problem is. > > :) > >> I am breaking stuff from time to time now, but once I figure out how >> to customize Sage, it should then be really easy to maintain it. I >> just keep all changes as a set of documented patches in a git "spd" >> branch and original Sage sources in the master branch, so with each >> new Sage release, I just update the master branch and then just rebase >> (or merge, that's probably better to preserve history for debugging) >> my spd branch. > > Well, I think what we should do is merge as much of SPD into Sage as > possible to lessen the maintainance burden. One thing I could see here > is to define SAGE_EXECUTABLE and you would just set it to spd in your > code. > > But the longer term goal should be something along the line of > changing the SAGE_$FOO variables as much as possible with SPD_$FOO > variables and then have a wrapper script, say sage-env :), that just > sets all SAGE_$FOO values to SPD_$FOO values. This suggestion has not
Yes, but imho this can happen gradually, now I have more urgent things to fix. > been discussed before (I mentioned it on the list once) and I am > unclear how much of this might actually happen, but I think we (as in > the Sage project) should support SPD as much as possible and if that > means some changes like the above I am fine with it. That'd be awesome. I think that could make Python much more viable alternative to Matlab and other commercial tools (like many engineering tools for finite elements that Sage currently cannot compete with at all, without including tons of libraries) by allowing anyone to create a simple all in one package, that just works. > If your plan is still to recreate all scripts to be BSD the above > would be more or less pointless, so you need to let us know what you > want to do. I really don't want to relicense my code in $SAGE_LOCAL/ I am not going to rewrite all the scripts just because of the license and also because I very much just prefer to use Sage with minimal modifications. > bin/sage-$FOO to BSD since the EPD for example has fixes to various > python packages that have not been fed back to the community and I Not giving changes back is bad, on the other hand the question is if they would give the changes back if it was GPL, e.g. maybe there would not be any EPD at all. One may also argue if EPD is doing any harm to the community by not being free and I don't think it's doing any harm. > honestly have no interest in something like that happening via other > companies and SPD in the long term. Obviously we don't need to do the Yes, I definitely respect that, as I stated already on this list. > whole BSD vs. GPL flame war here I hope since we have dicsussed this > in IRC often enough and more or less agree. :) My opinion on this is clear an can be searched on this and the sympy list, for low level libraries like sympy I clearly prefer BSD, for high level stuff like SPD I prefer the license that can get the job done, which currently is GPL, given that Sage (or things that I need from Sage) is GPL and given your position on it. I cannot pull SPD off myself and honestly I think the only way to really pull it off is by working tightly with you and William and other Sage devs, so the right license is GPL, because that's what the majority of Sage devs like (with sympy it's a totally different story, where majority of devs prefer something more permissive than GPL). Also because a crucial part of this is the notebook, which is also GPL. And also I most probably will want to include (in my custom modifications of SPD for finite elements) some GPL library anyway, like libmesh.sf.net. However, and that was my point on the scipy list, if there is sufficient interest to have SPD as BSD, it can in principle be done if someone rewrites all the scripts (including all the spkg scripts) and also rewrites the notebook (I think ipython has something, but definitely not as usable). I am not going to do that myself simply because I have better ways to waste my time. :) I just want something now which is usable, which has a web notebook and which can solve the problem now. GPL is the only possible license for SPD, given the current situation. Ondrej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
