On Fri, Apr 17, 2009 at 2:33 AM, mabshoff <mabsh...@googlemail.com> wrote: > > > > On Apr 17, 2:04 am, Ondrej Certik <ond...@certik.cz> wrote: >> On Fri, Apr 17, 2009 at 1:07 AM, mabshoff <mabsh...@googlemail.com> wrote: > > <SNIP> > >> > 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. > > Well, it would happen from my end. I think that in the process we > would do some serious cleanup, but the switch over should be quick > *if* we do it IMHO.
Yes -- but wait until I have all my patches ready (couple weeks). Then it will be clear what has to be changed and how. For example I am also changing the occurrences of the word Sage in the notebook, and so on. Besides, when you change SAGE_ROOT to SPD_ROOT, then you have to also change all the spkg packages. Which I would like to avoid, so that it's as compatible with Sage as possible. > >> > 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. > > Yep, another thing I want to do is to autogenerate the dependency file > from some list of components, i.e. it would know that scipy requires > some sort of BLAS as well as a Fortran compiler and so on. We would > also have required versions, etc, but since it has to be cross > platform we cannot use anything existing. But that might be a while > off, but seems to be crucial for someone non-technical to just > assemble a custom SPD for his/her particular purpose. Excellent, when we last discussed that I thought you were opposed to any dependencies. >> 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. > > Well, setuptools is infrastructure and my statement was due to some > remarks on the scipy list last week, i.e. I have no detailed info what > they fixed. I am perfectly fine with the BSD license and companies > like Enthought being in business selling and supporting numpy/scipy/ > EPD etc. But most Sage people are Open Source people and as you can > see from all the code written in Sage, i.e. the Sage library. there > is no preference for the BSD license. We obviously happily use BSD > licensed software and push back the changes. Sure. I myself think that Enthought is doing great and that they are giving back as much as their business model permits. > >> > 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, > > Yep. Nothing wrong with that per see, but obviously all heathens must > be tarred and feather once the revolution comes. :) > >> 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. > > One aspect here is that the notebook is pure python, so there is no > linking going on. And the notebook also happily executes any non-free > piece of software that can be started via pexpect, so the GPL in this > case should not really be a major hindrance and not applicable since > the GPL's license does not apply to anything beyond code started in a > different process. Were the Sage notebook C or some other compiled > code you had to link with I could see the GPL impeding adoption in > certain communities and I am sure some people would be happy if the > code were BSD so you can change and modify in non-source form, but > that is not my problem :) Right, didn't occur to me. This brings a question what is the purpose of GPL if it cannot even be enforced in Python, e.g. if I can still use it and distribute it with proprietary stuff. > >> 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). > > What specifically are you talking about? I am not aware of any > notebook interface and the build bits from Sage do not exist in > IPython AFAIK. If you remember the Sage Days 8 at Enthought a year ago, we were playing with a notebook in ipython together with Fernando, Brian and others. But I think noone had time to develop it further. The build bits do not exist in ipython, but I think ipython should have some good web notebook. > >> 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. > > Yeah, I am hoping that all the energy for net based notebook like > interfaces will unite behind the sagelite project. I.e. I don't think > Knoboo will become mature any time soon, i.e. there seems to be at > best glacial development on the repo for the last couple months again, > etc. Yes, I think so too, I want to just use the Sage notebook, for teaching and presentations and other stuff. If someone writes something better, then why not, but currently the Sage notebook is by far the best thing around. 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 -~----------~----~----~----~------~----~------~--~---
