Sage Horizon (comments)
Ondrej Certik
there was an interesting talk by William about the future of Sage,
that I just watched at
http://sage.math.washington.edu/home/wstein/sagedays15/
it's the file:
M2U00407-wstein-sage5.0-HORIZON.MPG
(you can watch the compressed version as I did)
So here are couple subjective comments that occured to me during it:
* I realized after moving to the US and actually teaching Calc I (I
was TAing the practical lessons, e.g. lots of calculations), that
being able to get the software to the state that can be used by every
single student in the class even if they never programmed before is
absolutely essential. There are 2 ways --- web notebook, and then the
actual program, which mostly means it has to be ported to windows (of
course it has to work on all other platforms that people use, but that
already works)
* The general approach the Sage uses to get to users is the right one
* I like how mathematica is designed, that one plays with symbolic
high level things, but in the background the right (fastest) algorithm
(and implementation) is used. It seems to me that Sage is also going
on this path. Btw in case you haven't noticed, Wolfram just launched:
try to type some integral in there, e.g.:
http://www.wolframalpha.com/input/?i=integrate+1%2F(1%2Bx**7)
and you get all kinds of information about it and graphs etc. Just
look at all the different ways the result can be represented. This is
just to show how much we are behind Mathematica with anything in Sage
or sympy. Sympy can do some of those transformations already, but it's
still a lot more work to be done.
* at the very end of the presentation there was a discussion about
numeric stuff. There are tons of computational programs in lots of
fields (atomic physics, quantum field theory, electromagnetics,
electronic structure calculations, fluid dynamics, atmospheric
sciences, nuclear engineering ....) and there is just no way how this
can all be in Sage. Nevertheless, people would like to teach with it,
let's say some electrodynamic course, or finite element course, or
(partial) differential equations course. Sage currently cannot do any
of that.
One way out is just to install the particular package for it, but it's
not easy. For example for the finite element solvers that our group[0]
is doing we need (besides python, numpy, scipy, cython) also lots of
solvers (petsc, umfpack, ...), then 3d plotting (mayavi) and other
dependencies. And also I would like to have more than our FEM library,
I would like to include libmesh and other things, unified with one
Python interface, so that one can compare, etc. Adding all of this
into Sage, it would get twice as big.
So the approach that I took with SPD [1] that William was also
discussing in the presentation, was to throw out most of Sage, except
the build system and the scipy+notebook combo. That way our group can
add the finite element + related stuff and have our package that we
can try to get to the end users (e.g. the combination of the web
notebook and the actual program that works on all platforms), and
other groups can do the same for atomic physics, fluid dynamics, etc.
And it is still fully compatible with Sage, e.g. the base packages are
the same, and I think all the other custom packages would also just
work when installed into Sage.
I however still want to be able to represent and manipulate symbolics
(e.g. represent some ordinary or partial differential equation and
then solve it with our C++ solver), so we'll just use sympy for that,
because it's small and it can convert expression from and to Sage, if
needed. I hope we could figure out more ways to collaborate with
pynac, Fredrik (sympy and mpmath dev) is at SD15, so I hope they'll
discuss it. :)
I also want to be able to use plots easily, which fortunately the Sage
notebook can do.
So overall I am very excited where all of this is going.
I am interested in your comments to the above.
Ondrej
[0] http://hpfem.math.unr.edu/
[1] http://code.google.com/p/spdproject/
Tim Lahey
On May 18, 2009, at 12:13 AM, Ondrej Certik wrote:
>
>
> * at the very end of the presentation there was a discussion about
> numeric stuff. There are tons of computational programs in lots of
> fields (atomic physics, quantum field theory, electromagnetics,
> electronic structure calculations, fluid dynamics, atmospheric
> sciences, nuclear engineering ....) and there is just no way how this
> can all be in Sage. Nevertheless, people would like to teach with it,
> let's say some electrodynamic course, or finite element course, or
> (partial) differential equations course. Sage currently cannot do any
> of that.
As Ondrej well knows, I'm quite interested in FEM and PDEs, so I have
an interest in using these with Sage.
> One way out is just to install the particular package for it, but it's
> not easy. For example for the finite element solvers that our group[0]
> is doing we need (besides python, numpy, scipy, cython) also lots of
> solvers (petsc, umfpack, ...), then 3d plotting (mayavi) and other
> dependencies. And also I would like to have more than our FEM library,
> I would like to include libmesh and other things, unified with one
> Python interface, so that one can compare, etc. Adding all of this
> into Sage, it would get twice as big.
>
Having a simple way to interface these packages to Sage and create the
.spkg would be a good thing. That way, once someone figures out the
process,
they can bundle it and make it available for others.
Also, if there is a wiki page where Sage can get URLs for 3rd-party
packages
(with the understanding that these are unsupported by Sage developers)
it
would facilitate sharing and make it easy to install.
> So the approach that I took with SPD [1] that William was also
> discussing in the presentation, was to throw out most of Sage, except
> the build system and the scipy+notebook combo. That way our group can
> add the finite element + related stuff and have our package that we
> can try to get to the end users (e.g. the combination of the web
> notebook and the actual program that works on all platforms), and
> other groups can do the same for atomic physics, fluid dynamics, etc.
> And it is still fully compatible with Sage, e.g. the base packages are
> the same, and I think all the other custom packages would also just
> work when installed into Sage.
I'm interested in the SPD stuff because I'd like to see some of the
FEM stuff available from Sage, although the difficult part of FEM for
me is the derivation, not the solution. Whereas often the equations are
already well known and it's the meshing/solution that presents the
difficulty.
>
> I however still want to be able to represent and manipulate symbolics
> (e.g. represent some ordinary or partial differential equation and
> then solve it with our C++ solver), so we'll just use sympy for that,
> because it's small and it can convert expression from and to Sage, if
> needed. I hope we could figure out more ways to collaborate with
> pynac, Fredrik (sympy and mpmath dev) is at SD15, so I hope they'll
> discuss it. :)
>
Based upon the videos, it looks like sympy integration will be better
fit into Sage 4.0 so I'll probably make some changes to my test
framework
to utilize the new features. This will make testing sympy easier (at
least
from Sage) so hopefully, that will help you as well.
I'm very interested in this. Some of the big advantages of MATLAB and
Mathematica are the toolboxes that are available. MATLAB at least
makes it
quite easy to package a new toolbox, if we can have a simple way to
make and
distribute new Sage toolboxes, that would go a long way.
Then, if it's clear that particular toolboxes are seeing a lot of use,
Sage
developers can look at bringing them into the standard distribution.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey
Marshall Hampton
On May 17, 11:13 pm, Ondrej Certik <ond...@certik.cz> wrote:
* at the very end of the presentation there was a discussion about
numeric stuff. There are tons of computational programs in lots of
fields (atomic physics, quantum field theory, electromagnetics,
electronic structure calculations, fluid dynamics, atmospheric
sciences, nuclear engineering ....) and there is just no way how this
can all be in Sage. Nevertheless, people would like to teach with it,
let's say some electrodynamic course, or finite element course, or
(partial) differential equations course. Sage currently cannot do any
of that.
imagine having all of that in Sage. It just seems to be a chicken-and-
egg issue to me, we need those features to attract those users, and
the corresponding users to supply the packages. This is where Matlab
really has a huge lead, and it will take time to chip away at that.
But conceptually I don't understand why it couldn't happen.
-Marshall
William Stein
I agree. We can do anything if we have enough energy, organization,
resources, and work hard enough.
Having the SPD project build up infrastructure in the numerical
direction is a great way to organize ourselves in order to accomplish
more.
-- William
Tim Lahey
On May 18, 2009, at 2:02 AM, William Stein wrote:
>
> I agree. We can do anything if we have enough energy, organization,
> resources, and work hard enough.
>
> Having the SPD project build up infrastructure in the numerical
> direction is a great way to organize ourselves in order to accomplish
> more.
>
Right now, Sage checks to see which optional packages are available. Can
a check to a Wiki page with 3rd-party URLs for additional experimental
packages be added?
Doing this would make it easier for people to discover new packages and
make it easier for people to make them available.
Ondrej Certik
What I meant is that it can't be easily included by default. Or do you
want to ship Sage with all those extra dependencies?
Let's say I need SPD + another 10 packages. Downloading each of them
by hand with "./sage -i" is boring. Of course I can just ship a script
that does that. But better is to have some package, where I just do
"make" and it builds everything.
What can be done, that when buildling sage, one can do:
make electromagnetics
and it will only build stuff for electromagnetics. Another option is
to use Sage just like Matlab, e.g. you install it once and don't touch
it. And then one would just ship a script "electromagnetics", that
will download and install those 10 more packages. That's definitely
one way. Maybe that's what users want, I don't know. But then I think
the base Matlab like package should be smaller (SPD). :) Even though I
agree Matplab itself is not small.
So I guess it's a question of the right balance between features and size.
Ondrej
William Stein
>
> On Sun, May 17, 2009 at 10:05 PM, Marshall Hampton <hamp...@gmail.com> wrote:
>>
>>
>>
>> On May 17, 11:13 pm, Ondrej Certik <ond...@certik.cz> wrote:
>> * at the very end of the presentation there was a discussion about
>> numeric stuff. There are tons of computational programs in lots of
>> fields (atomic physics, quantum field theory, electromagnetics,
>> electronic structure calculations, fluid dynamics, atmospheric
>> sciences, nuclear engineering ....) and there is just no way how this
>> can all be in Sage. Nevertheless, people would like to teach with it,
>> let's say some electrodynamic course, or finite element course, or
>> (partial) differential equations course. Sage currently cannot do any
>> of that.
>>
>> Why can't it all be included? At least as optional packages, I can
>> imagine having all of that in Sage. It just seems to be a chicken-and-
>> egg issue to me, we need those features to attract those users, and
>> the corresponding users to supply the packages. This is where Matlab
>> really has a huge lead, and it will take time to chip away at that.
>> But conceptually I don't understand why it couldn't happen.
>
> What I meant is that it can't be easily included by default. Or do you
> want to ship Sage with all those extra dependencies?
It's possible that there could be a *version* of Sage with them, if
they all worked well. There's no technical reason why one couldn't do
that at all. It's completely a matter of willpower and effort.
> Let's say I need SPD + another 10 packages. Downloading each of them
> by hand with "./sage -i" is boring. Of course I can just ship a script
> that does that. But better is to have some package, where I just do
> "make" and it builds everything.
>
> What can be done, that when buildling sage, one can do:
>
> make electromagnetics
>
> and it will only build stuff for electromagnetics. Another option is
> to use Sage just like Matlab, e.g. you install it once and don't touch
> it. And then one would just ship a script "electromagnetics", that
> will download and install those 10 more packages. That's definitely
> one way. Maybe that's what users want, I don't know. But then I think
> the base Matlab like package should be smaller (SPD). :) Even though I
> agree Matplab itself is not small.
>
> So I guess it's a question of the right balance between features and size.
>
> Ondrej
>=
At University of Washington, when one downloads the local
site-licensed binary for MATLAB it includes (I think) every MATLAB
toolbox except I think the symbolic toolbox (the only one I want, of
course). It's a 3.6GB compressed download.
-- William
Ondrej Certik
>
> On Sun, May 17, 2009 at 11:47 PM, Ondrej Certik <ond...@certik.cz> wrote:
>> So I guess it's a question of the right balance between features and size.
>>
>> Ondrej
>>=
>
> At University of Washington, when one downloads the local
> site-licensed binary for MATLAB it includes (I think) every MATLAB
> toolbox except I think the symbolic toolbox (the only one I want, of
> course). It's a 3.6GB compressed download.
Ah, I didn't know this. So yes, if it's 3.6GB, and given that Sage is
~300MB, so yes, I think it's doable to fit everything into one
gigantic package.
So it's just a question of manpower. I wonder how long it takes to run
all doctests in 3.6GB compressed package... Or to compile it... Well I
guess it's mostly matlab code that isn't compiled?
Ondrej
Kevin Horton
Will packages created for SPD be usable as-is in Sage, or will they
need to be tweaked in some way before they can be used with Sage?
Will there be some sort of automatic installation of package
dependencies? This would seem to be highly desirable.
--
Kevin Horton
Ottawa, Canada
mabshoff
On May 18, 6:17 am, Kevin Horton <khorto...@rogers.com> wrote:
> On 18 May 2009, at 02:02, William Stein wrote:
> Will packages created for SPD be usable as-is in Sage, or will they
> need to be tweaked in some way before they can be used with Sage?
> Will there be some sort of automatic installation of package
> dependencies? This would seem to be highly desirable.
describe its dependencies and we should then use a little script to
turn that into a dependency makefile. The main problem to do this are
at the moment:
(a) we need to agree on a standard, i.e. file naming conventions, etc
(b) we need to come up with a central spkg repo, i.e.
spd.sagemath.org ;)
(c) we probably will need the concept of meta-spkg, i.e. Fortran
would be one obvious thing where various possibilities arise.
(d) we also need something like a number of toggles, i.e. FRAMEWORK
build on OSX would be one, so if you wanted Mayavi on OSX the build
system should be smart enough to force a framework build on OSX.
(e) minium and maximum version numbers of spkgs allowed, i.e. in case
you have build issue or bugfixes mandate minimum versions, security
fixes, etc.
None of the above is particularly hard to do, someone just needs to
find the time to do it. We should very much orient ourselves toward
the Debian build system, but obviously we cannot use it since we want
to be truly cross platform.
What this very much goes into is the ability to to custom Sage or SPD
distributions, i.e. you could specify a profile like
[profile]
require: sage-fe
require: sage-notebook
[end profile]
and then a little script could spit you out a tarball for your
specific purpose that would have all the dependencies resolved. In
this case it would obviously contain all the bits required to build
the notebook and the packages considered to be part of a not yet
existing finite element set, i.e. some of the stuff Ondrej & friends
are doing.
This would also allow Sage to more or less get rid of most
experimental and optional spkgs and just release them in a pool of spd
maintained packages where hopefully upstream would take care of
maintaining them. Obviously a log of current Sage devs would then keep
taking care of optional and experimental spkgs.
Cheers,
Michael
mabshoff
On May 18, 6:37 am, mabshoff <mabsh...@googlemail.com> wrote:
> On May 18, 6:17 am, Kevin Horton <khorto...@rogers.com> wrote:
>
> > On 18 May 2009, at 02:02, William Stein wrote:
>
> <SNIP>
>
> > Will packages created for SPD be usable as-is in Sage, or will they
> > need to be tweaked in some way before they can be used with Sage?
coffee :)
> Yes.
I meant to say: Yes, they should be usable as-is. That is the whole
point of cooperating between Sage and SPD.
Cheers,
Michael
Kevin Horton
If Sage and SPD are so closely related, and must remain so for each
project to achieve its long term goals, it isn't clear to me why they
are two separate projects.
If I understand properly (and maybe I don't, as I haven't yet found a
clear description of exactly what SPD is), SPD essentially is Sage,
but without requiring the automatic building and installation of the
many dozens of packages that Sage needs to provide its desired long
list of capabilities. If my understanding is correct, could the
purpose of the SPD project be achieved by having a "minimal" target in
the Sage makefile? One would do "make minimal", and get something
that looks like the current SPD? One would then install the specific
packages needed to provide one's needed capabilities.
I'm interested in SPD because my needs are more on the numerical side,
for data analysis plus plotting, with the notebook to record and
report results. I don't need the symbolic side of things. Sage does
what I need, but at the expense of installing a large number of
packages I will never use. This is not a problem on my desktop
computer, but it is a concern on the ancient laptop computer that I
travel with.
Brian Granger
projects (Sage/SPD). In working on SPD, I have already run into small
bugs in Sage's infrastructure. Currently, we have to fix such things
in both SPD and Sage and manage the respective tickets/patches for
both projects. That is pretty painful for things that are simple to
fix.
>> What I meant is that it can't be easily included by default. Or do you
>> want to ship Sage with all those extra dependencies?
>
> It's possible that there could be a *version* of Sage with them, if
> they all worked well. There's no technical reason why one couldn't do
> that at all. It's completely a matter of willpower and effort.
From the organization side of things is the "multiple versions of
Sage" option something you and the other Sage devs would support?
Would this required making changes to the decision making process for
spkgs inclusion?
>> Let's say I need SPD + another 10 packages. Downloading each of them
>> by hand with "./sage -i" is boring. Of course I can just ship a script
>> that does that. But better is to have some package, where I just do
>> "make" and it builds everything.
>>
>> What can be done, that when buildling sage, one can do:
>>
>> make electromagnetics
>>
>> and it will only build stuff for electromagnetics. Another option is
>> to use Sage just like Matlab, e.g. you install it once and don't touch
>> it. And then one would just ship a script "electromagnetics", that
>> will download and install those 10 more packages. That's definitely
>> one way. Maybe that's what users want, I don't know. But then I think
>> the base Matlab like package should be smaller (SPD). :) Even though I
>> agree Matplab itself is not small.
Having custom make targets like this might be a good approach.
Cheers,
Brian
William Stein
>
> From a development perspective, it makes no sense to have two separate
> projects (Sage/SPD). In working on SPD, I have already run into small
> bugs in Sage's infrastructure. Currently, we have to fix such things
> in both SPD and Sage and manage the respective tickets/patches for
> both projects. That is pretty painful for things that are simple to
> fix.
>
>>> What I meant is that it can't be easily included by default. Or do you
>>> want to ship Sage with all those extra dependencies?
>>
>> It's possible that there could be a *version* of Sage with them, if
>> they all worked well. There's no technical reason why one couldn't do
>> that at all. It's completely a matter of willpower and effort.
>
> From the organization side of things is the "multiple versions of
> Sage" option something you and the other Sage devs would support?
Not right now. I'm sure Michael Abshoff would agree that we are way
too busy just dealing with Sage itself.
However, note that there are two versions *right now* -- Sage and SPD
-- and that this is not in any way increasing my workload or
Michael's. It's for this reason that I'm not sure I fully agree with
your statement above that "From a development perspective, it makes no
sense to have two separate projects (Sage/SPD)."
William
mabshoff
On May 18, 9:08 am, William Stein <wst...@gmail.com> wrote:
>
> > From a development perspective, it makes no sense to have two separate
> > projects (Sage/SPD). In working on SPD, I have already run into small
> > bugs in Sage's infrastructure. Currently, we have to fix such things
> > in both SPD and Sage and manage the respective tickets/patches for
> > both projects. That is pretty painful for things that are simple to
> > fix.
I discussed the patches with Ondrej yesterday in IRC and I would
prefer if you posted them here since last time Ondrej found bugs in
Sage's scripts it turned out mostly to be bugs in the way Ondrej used
them.
> >>> What I meant is that it can't be easily included by default. Or do you
> >>> want to ship Sage with all those extra dependencies?
>
> >> It's possible that there could be a *version* of Sage with them, if
> >> they all worked well. There's no technical reason why one couldn't do
> >> that at all. It's completely a matter of willpower and effort.
>
> > From the organization side of things is the "multiple versions of
> > Sage" option something you and the other Sage devs would support?
>
> Not right now. I'm sure Michael Abshoff would agree that we are way
> too busy just dealing with Sage itself.
thinking about. And I think this is entirely doable before the end of
the summer.
> However, note that there are two versions *right now* -- Sage and SPD
> -- and that this is not in any way increasing my workload or
> Michael's. It's for this reason that I'm not sure I fully agree with
> your statement above that "From a development perspective, it makes no
> sense to have two separate projects (Sage/SPD)."
>
> William
special and important case of SPD and that for all practical purposes
SPD's infrastructure bits have been merged back into Sage. So far I
have not seen a single patch which couldn't be handled.
Having everything under one roof just makes sense and I think once the
notebook has been spun off via Mike's code that hasn't been published
yet and when the pexpect problem on Windows has been solved it makes a
whole lot of sense to have all of SPD inside Sage since then Ondrej &
Brian can have the Sage notebook + sympy + numpy + scipy on Windows
and all other platforms.
There is a lot of work I have done in the direction of Sage native on
Windows that isn't visible yet, but the next couple weeks will see all
that work merged into 4.0.x.
Cheers,
Michael
Brian Granger
> I discussed the patches with Ondrej yesterday in IRC and I would
> prefer if you posted them here since last time Ondrej found bugs in
> Sage's scripts it turned out mostly to be bugs in the way Ondrej used
> them.
I don't mind posting them here. It is very possible that many of the
"bugs" we are finding have to do with our using the build system in
buggy ways. I will do that later today. But for following the
tickets on Sage's trac system, it would be great to have an account
when you get a chance.
> I think that hopefully by the end of the summer Sage will be a rather
> special and important case of SPD and that for all practical purposes
> SPD's infrastructure bits have been merged back into Sage. So far I
> have not seen a single patch which couldn't be handled.
I think this model makes a lot of sense. It would allow us to
essentially build our own Sage/SPD versions like we want/need, it
would improve the Sage build system and in the long run it (hopefully)
would impose much of an additional burden on the the Sage devs. In
the meantime Ondrej and I will try hard to feed our work back into
Sage.
> Having everything under one roof just makes sense and I think once the
> notebook has been spun off via Mike's code that hasn't been published
> yet and when the pexpect problem on Windows has been solved it makes a
> whole lot of sense to have all of SPD inside Sage since then Ondrej &
> Brian can have the Sage notebook + sympy + numpy + scipy on Windows
> and all other platforms.
+1
> There is a lot of work I have done in the direction of Sage native on
> Windows that isn't visible yet, but the next couple weeks will see all
> that work merged into 4.0.x.
Great!
Brian
Brian Granger
> too busy just dealing with Sage itself.
OK, I am not surprised - Sage is an ambitious undertaking.
> However, note that there are two versions *right now* -- Sage and SPD
> -- and that this is not in any way increasing my workload or
> Michael's. It's for this reason that I'm not sure I fully agree with
> your statement above that "From a development perspective, it makes no
> sense to have two separate projects (Sage/SPD)."
Yes, SPD really is functioning as a Sage version. I also agree with
you that another true Sage version could create additional work for
the Sage devs - even if folks like myself and Ondrej agreed to
spearhead it.
But, if in the medium term (as Michael is hoping for), the Sage build
system can be improved to the point where both Sage and SPD are using
the same infrastructure, that would help a lot. We could then create
SPD releases with whatever spkgs that we need without burdening the
Sage devs.
Cheers,
Brian
Ondrej Certik
Sounds good.
As to me, I don't mind calling SPD just Sage. I chose a different name
because we were asked explicitly by Michael not to call it Sage. I
guess it's like Ubuntu, it's also not called a Debian, when in fact it
*is* a Debian.
For Kevin: the aim of SPD is to make it easy to create all in one
packages with just the stuff that we need (e.g. packages that are
currently in SPD, like scipy, numpy, notebook and then bunch of custom
libraries, that don't even have a spkg yet). And be compatible with
Sage. That's it.
Ondrej
Tim Lahey
On May 18, 2009, at 12:50 PM, Ondrej Certik wrote:
>
> For Kevin: the aim of SPD is to make it easy to create all in one
> packages with just the stuff that we need (e.g. packages that are
> currently in SPD, like scipy, numpy, notebook and then bunch of custom
> libraries, that don't even have a spkg yet). And be compatible with
> Sage. That's it.
>
Are the custom libraries going to be .spkg as well? So, people using the
full version of Sage can install them?
Brian Granger
> full version of Sage can install them?
Yes, definitely.
Brian
mabshoff
On May 18, 9:29 am, Brian Granger <ellisonbg....@gmail.com> wrote:
> > Not right now. I'm sure Michael Abshoff would agree that we are way
> > too busy just dealing with Sage itself.
>
> OK, I am not surprised - Sage is an ambitious undertaking.
> > However, note that there are two versions *right now* -- Sage and SPD
> > -- and that this is not in any way increasing my workload or
> > Michael's. It's for this reason that I'm not sure I fully agree with
> > your statement above that "From a development perspective, it makes no
> > sense to have two separate projects (Sage/SPD)."
>
> Yes, SPD really is functioning as a Sage version. I also agree with
> you that another true Sage version could create additional work for
> the Sage devs - even if folks like myself and Ondrej agreed to
> spearhead it.
* branding of SPD, i.e. Sage would be one such thing, the other would
be "Ondrej's super delicious FE package" or whatever.
* -sdist to create a minimal SPD skeleton, i.e. prereq and sage-
scripts. sage-scripts needs the infrastructure to pull together
various spkgs and created "install" and "deps". For Sage at the moment
we wouldn't have to got that way since we manually maintain those
files, but with a little work this should be doable via a little shell
script {and/or python I assume since having python to create a new
custom SPD seems reasonable). Then we just take it from there and see
where this journey leads us.
I think SPD will go much further than Sage alone and has the potential
to expand the scientific python community substantially since having
something that just works locally custom build from sources on pretty
much any decent OS is something that should work rather well ;).
> But, if in the medium term (as Michael is hoping for), the Sage build
> system can be improved to the point where both Sage and SPD are using
> the same infrastructure, that would help a lot. We could then create
> SPD releases with whatever spkgs that we need without burdening the
> Sage devs.
upstream python project you just cannot affort not to offer a spkg ;)
> Cheers,
>
> Brian
Cheers,
Michael
mabshoff
On May 18, 9:50 am, Ondrej Certik <ond...@certik.cz> wrote:
> On Mon, May 18, 2009 at 9:29 AM, Brian Granger <ellisonbg....@gmail.com> wrote:
<SNIP>
> > But, if in the medium term (as Michael is hoping for), the Sage build
> > system can be improved to the point where both Sage and SPD are using
> > the same infrastructure, that would help a lot. We could then create
> > SPD releases with whatever spkgs that we need without burdening the
> > Sage devs.
>
> Sounds good.
>
> As to me, I don't mind calling SPD just Sage. I chose a different name
> because we were asked explicitly by Michael not to call it Sage. I
> guess it's like Ubuntu, it's also not called a Debian, when in fact it
> *is* a Debian.
respin. Kubuntu focuses on KDE vs. the more gnome centric Ubuntu.
Analog there is Edubuntu and so on.
In the end we should have Sage-core, i.e. the standard configuration
of Sage, but there is no reason to not have sage-fe with a say loads
of spkgs on top of Sage that aren't in there due to size restriction.
SPD would be the very core infrastructure that can be branded, i.e.
doing notebook+sympy+numpy+scipy+MPL+mavavi+atlas could be something
that is not a subset of sage-core, but has substantial overlap.
> For Kevin: the aim of SPD is to make it easy to create all in one
> packages with just the stuff that we need (e.g. packages that are
> currently in SPD, like scipy, numpy, notebook and then bunch of custom
> libraries, that don't even have a spkg yet). And be compatible with
> Sage. That's it.
>
> Ondrej
Michael
mabshoff
On May 18, 10:03 am, mabshoff <mabsh...@googlemail.com> wrote:
> On May 18, 9:50 am, Ondrej Certik <ond...@certik.cz> wrote:
>
> > On Mon, May 18, 2009 at 9:29 AM, Brian Granger <ellisonbg....@gmail.com> wrote:
>
> <SNIP>
>
> > > But, if in the medium term (as Michael is hoping for), the Sage build
> > > system can be improved to the point where both Sage and SPD are using
> > > the same infrastructure, that would help a lot. We could then create
> > > SPD releases with whatever spkgs that we need without burdening the
> > > Sage devs.
>
> > Sounds good.
>
> > As to me, I don't mind calling SPD just Sage. I chose a different name
> > because we were asked explicitly by Michael not to call it Sage. I
> > guess it's like Ubuntu, it's also not called a Debian, when in fact it
> > *is* a Debian.
>
> Well, I see the relationship between Sage and SPD more as Ubuntu vs. a
> respin. Kubuntu focuses on KDE vs. the more gnome centric Ubuntu.
> Analog there is Edubuntu and so on.
respins, i.e. this all started since Ondrej had trouble building
ntl.spkg on a cluster with a FUBAR network file system and since he
didn't need NTL the rest is history as they say :)
> In the end we should have Sage-core, i.e. the standard configuration
> of Sage, but there is no reason to not have sage-fe with a say loads
> of spkgs on top of Sage that aren't in there due to size restriction.
>
> SPD would be the very core infrastructure that can be branded, i.e.
> doing notebook+sympy+numpy+scipy+MPL+mavavi+atlas could be something
> that is not a subset of sage-core, but has substantial overlap.
Cython the end product was much, much better and Cython is a much
better project now compared to what it would have been had it remained
SageX.
The next success story will be the spun off Sage notebook which
already exists as an informal light version and is used by Ondrej as a
component of SPD. But Mike Hansen has rebuild it partially with pylon
IIRC and will make it completely independent of Sage. And it will just
kill and kick ass out there in the wild ;)
Cheers,
Michal
Serge A. Salamanka
> packages with just the stuff that we need (e.g. packages that are
> currently in SPD, like scipy, numpy, notebook and then bunch of custom
> libraries, that don't even have a spkg yet). And be compatible with
> Sage. That's it.
>
> Ondrej
>
It will be good to place that explanation on the project page.
http://code.google.com/p/spdproject/
I couldn't figure out at once the aim of the project when visiting the
project's website.
Now everything's clear.
#Serge
Ondrej Certik
Gonzalo Tornaria
> I have the desire to fix the dependency problem. i.e. each spkg should
> describe its dependencies and we should then use a little script to
> turn that into a dependency makefile. The main problem to do this are
> at the moment:
>
> (a) we need to agree on a standard, i.e. file naming conventions, etc
> (b) we need to come up with a central spkg repo, i.e.
> spd.sagemath.org ;)
> (c) we probably will need the concept of meta-spkg, i.e. Fortran
> would be one obvious thing where various possibilities arise.
> (d) we also need something like a number of toggles, i.e. FRAMEWORK
> build on OSX would be one, so if you wanted Mayavi on OSX the build
> system should be smart enough to force a framework build on OSX.
> (e) minium and maximum version numbers of spkgs allowed, i.e. in case
> you have build issue or bugfixes mandate minimum versions, security
> fixes, etc.
>
> None of the above is particularly hard to do, someone just needs to
> find the time to do it. We should very much orient ourselves toward
> the Debian build system, but obviously we cannot use it since we want
> to be truly cross platform.
Why not use debian tools for this exact purpose? That's precisely what
fink does, isn't it?
If this is feasible, it would be an excellent way of building a car
without inventing the screws.
> What this very much goes into is the ability to to custom Sage or SPD
> distributions, i.e. you could specify a profile like
>
> [profile]
> require: sage-fe
> require: sage-notebook
> [end profile]
>
> and then a little script could spit you out a tarball for your
> specific purpose that would have all the dependencies resolved. In
> this case it would obviously contain all the bits required to build
> the notebook and the packages considered to be part of a not yet
> existing finite element set, i.e. some of the stuff Ondrej & friends
> are doing.
tarballs are gross... especially 200Mb ones...
> This would also allow Sage to more or less get rid of most
> experimental and optional spkgs and just release them in a pool of spd
> maintained packages where hopefully upstream would take care of
> maintaining them. Obviously a log of current Sage devs would then keep
> taking care of optional and experimental spkgs.
Awesome... this looks very much like debian... :-)
Best,
Gonzalo