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.
> > 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.
> > 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.
Ok, I misunderstood the remark you made about the BSD then.
> > 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.
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.
> > 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 :)
> 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.
> 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.
> Ondrej
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
-~----------~----~----~----~------~----~------~--~---
