On Thu, Mar 28, 2013 at 01:14:10AM +0100, Tobias Hansen wrote:
> Two people from Sage, Jeroen Demeyer and John Palmieri, volunteered to
> cover the Sage side of mentoring the project. Julien Puydt, who already
> put a lot of work into packaging Sage dependencies for Debian, is also
> on board. All
When you say "write/exchange the build systems for the core parts (c_lib,
python-sage, extcode...)" what exactly is your goal?
I don't think it makes much sense completely rewriting the setup.py/modules,
especially in Makefile (as it sounds like you might have been thinking).
If you are looking
Hi Andrew.
thanks for your comments.
On Sun, Apr 21, 2013 at 03:47:36AM -0700, R. Andrew Ohana wrote:
> When you say "write/exchange the build systems for the core parts (c_lib,
> python-sage, extcode...)" what exactly is your goal?
currently, the modules c_lib and sage-python etc. don't have
On Sun, Apr 21, 2013 at 4:59 AM, Felix Salfelder wrote:
> Hi Andrew.
>
> thanks for your comments.
>
> On Sun, Apr 21, 2013 at 03:47:36AM -0700, R. Andrew Ohana wrote:
> > When you say "write/exchange the build systems for the core parts (c_lib,
> > python-sage, extcode...)" what exactly is your
On Sun, Apr 21, 2013 at 05:22:30AM -0700, R. Andrew Ohana wrote:
> > it's not completely rewriting, think of it as modularization/conversion
> > (while adding checks for availability/headers/libraries and the like).
> >
>
> Ah, yes, I see your point. One suggestion then is to maybe think about
> a
On Sun, Apr 21, 2013 at 12:17:33PM +0200, Felix Salfelder wrote:
> 1 write/exchange the build systems for the core parts (c_lib,
> python-sage, extcode...).
> 2 modify sage ("the distribution") to use the new build systems instead
> of running 'setup.py'.
> 3 build stand-alone sage, draft debia
On 04/21/2013 06:36 PM, Felix Salfelder wrote:
but i'm curious: why doesn't sage simply use $PATH to locate executables? this
looks quite involved, what's the point?
The reason not to use $PATH is that we know for sure which "gap" program
is executed: we want the want from Sage, not some random
On Sun, Apr 21, 2013 at 2:12 PM, Jeroen Demeyer wrote:
> On 04/21/2013 06:36 PM, Felix Salfelder wrote:
>
>> but i'm curious: why doesn't sage simply use $PATH to locate executables?
>> this
>> looks quite involved, what's the point?
>>
> The reason not to use $PATH is that we know for sure which
On Sun, Apr 21, 2013 at 6:05 AM, Felix Salfelder wrote:
> a configure script would locate headers depending on the flags
> (--with-ntl=/here/or/there ...), does a check (optional) and then sets
> CFLAGS/wheteverFLAGS accordingly. Cython is used to write .c out of
> .pyx, i don't see why/how it cou
Hi Andrew.
some of this is confusing a lot...
On Sun, Apr 21, 2013 at 03:45:10PM -0700, R. Andrew Ohana wrote:
> Ah, yes, I see your point. One suggestion then is to maybe think about
> adding such checking functionality to Cython directly (since it already
> computes the entire dependency tree,
On 04/22/2013 09:28 AM, Felix Salfelder wrote:
sage already was modular in that sense, before the git transition
started. all that was missing, was a build system for sagelib and
sage-python (this is where i ignorantly started my first proposal).
switching to git is a great idea. if submodules/ex
On Mon, Apr 22, 2013 at 09:45:18AM +0200, Jeroen Demeyer wrote:
> On 04/22/2013 09:28 AM, Felix Salfelder wrote:
> >sage already was modular in that sense, before the git transition
> >started. all that was missing, was a build system for sagelib and
> >sage-python (this is where i ignorantly start
On 04/22/2013 09:57 AM, Felix Salfelder wrote:
do you see disadvantages in treating sage parts as modules?
It doesn't even make sense to treat them as modules, since they are not
independent. libcsage means nothing without the Sage Python library, the
Sage Python library requires libcsage and t
On 04/22/2013 11:14 AM, Jeroen Demeyer wrote:
On 04/22/2013 09:57 AM, Felix Salfelder wrote:
do you see disadvantages in treating sage parts as modules?
It doesn't even make sense to treat them as modules, since they are not
independent. libcsage means nothing without the Sage Python library, t
On Mon, Apr 22, 2013 at 11:14:43AM +0200, Jeroen Demeyer wrote:
> On 04/22/2013 09:57 AM, Felix Salfelder wrote:
> >do you see disadvantages in treating sage parts as modules?
> It doesn't even make sense to treat them as modules, since they are
> not independent. libcsage means nothing without the
On 22/04/13 19:57, Felix Salfelder wrote:
> On Mon, Apr 22, 2013 at 09:45:18AM +0200, Jeroen Demeyer wrote:
>> On 04/22/2013 09:28 AM, Felix Salfelder wrote:
>>> sage already was modular in that sense, before the git transition
>>> started. all that was missing, was a build system for sagelib and
>
Op maandag 22 april 2013 09:57:19 UTC+2 schreef Felix Salfelder het
volgende:
>
> do you see disadvantages in treating sage parts as modules?
>
> maybe it doesnt matter much, whether c_lib and scripts are in the same
> module or not, for distribution purposes it makes sense to have
> python-sa
On Mon, Apr 22, 2013 at 10:08:48PM +1200, Francois Bissey wrote:
> If you change the way c_lib is built by using the python library
> setup.py instead, we'll ditch our own separate package.
if you ask me, setup.py should be used *only* for the python library
(which is then treated as a module). yo
On 22/04/13 21:14, Jeroen Demeyer wrote:
> On 04/22/2013 09:57 AM, Felix Salfelder wrote:
>> do you see disadvantages in treating sage parts as modules?
> It doesn't even make sense to treat them as modules, since they are not
> independent. libcsage means nothing without the Sage Python library, t
Hi Timo.
On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote:
> We're trying to replace the current spkg system (actually the spkg system
> like it exists in the git repo) by some version of Gentoo's portage. This
> would be similar to the lmonade project, except that it's trying to be a
* Felix Salfelder [2013-04-22 13:01:20 +0200]:
> On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote:
> > We're trying to replace the current spkg system (actually the spkg system
> > like it exists in the git repo) by some version of Gentoo's portage. This
> > would be similar to the lmo
Hi Julian
On Mon, Apr 22, 2013 at 01:24:21PM +0200, Julian Rüth wrote:
> * Felix Salfelder [2013-04-22 13:01:20 +0200]:
> > On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote:
> > > We're trying to replace the current spkg system (actually the spkg system
> > > like it exists in the git
> debian has already packages for most of the foreign packages, and this
> is totally unrelated to sage. what i need is just packages for the core
> modules (currently the directories in /src). my proposal
> is to handle all modules (foreign or not) alike, and add build systems
> where missin
Hi Timo.
On Mon, Apr 22, 2013 at 05:23:10AM -0700, Timo Kluck wrote:
> So you're trying to make Sage "native" on Debian as opposed to making
> packages for the sage-patched foreign packages.
yes.
> That's probably an
> unrelated effort to our portage work, except that whatever build system
>
Op maandag 22 april 2013 14:52:15 UTC+2 schreef Felix Salfelder het
volgende:
>
> > I was
> > thinking of the idea of having sage-specific deb packages for sage's
> > foreign (often patched) modules. So maybe sage-gap, sage-maxima, et
> cetera,
> > which would install into /opt/sage.
>
> is t
Op maandag 22 april 2013 14:57:17 UTC+2 schreef Timo Kluck het volgende:
>
> No, it's about publishing a recent version of sage in a PPA (or in the app
> store) for ubuntu.
>
I should add: but this is not something I'm actually working on, it's
just what the idea was about. :-)
Timo
--
Y
On 04/22/2013 12:41 PM, Francois Bissey wrote:
My current sage-on-gentoo install on a OS X prefix is without sagenb and
as far as I am concerned it works.
What do you mean with "it works"? Sage-without-sagenb certainly doesn't
work for me, when starting Sage:
Traceback (most recent call last):
On 04/22/2013 12:06 PM, Felix Salfelder wrote:
why not leave these choices to the user?
Because it's more work for us to support this, for absolutely no advantage.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
Le 22/04/2013 17:15, Jeroen Demeyer a écrit :
On 04/22/2013 12:06 PM, Felix Salfelder wrote:
why not leave these choices to the user?
Because it's more work for us to support this, for absolutely no advantage.
I suggest sage-the-distribution sticks to not leaving choices to the
users because
On Mon, Apr 22, 2013 at 11:34:05AM +0200, Tobias Hansen wrote:
> On 04/22/2013 11:14 AM, Jeroen Demeyer wrote:
> > [..]
> >libcsage means nothing without the Sage Python library, the
> >Sage Python library requires libcsage and the scripts make no sense
> >without Sage.
(see the other posts about
On Mon, Apr 22, 2013 at 06:01:17PM +0200, Felix Salfelder wrote:
> On Mon, Apr 22, 2013 at 11:34:05AM +0200, Tobias Hansen wrote:
> > On 04/22/2013 11:14 AM, Jeroen Demeyer wrote:
> > > [..]
> > >libcsage means nothing without the Sage Python library, the
> > >Sage Python library requires libcsage
On Mon, Apr 22, 2013 at 05:15:30PM +0200, Jeroen Demeyer wrote:
> On 04/22/2013 12:06 PM, Felix Salfelder wrote:
> >why not leave these choices to the user?
> Because it's more work for us to support this, for absolutely no advantage.
Dear Jeroen,
I would really like to do that project, and i'm t
On 04/28/2013 08:23 PM, Felix Salfelder wrote:
I would really like to do that project, and i'm trying hard to
understand your objections against modules.
I have no objection in what you describe below. I *do* have an objection
against splitting up the sources, not against splitting up the build
I think the problem was mainly unclarity with the definition of
"module". I thought you wanted to split up the sources into different
repos, like we have now. And that's the only thing I am against.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
On Sun, Apr 28, 2013 at 11:35:43PM +0200, Jeroen Demeyer wrote:
> I think the problem was mainly unclarity with the definition of
> "module". I thought you wanted to split up the sources into
> different repos, like we have now. And that's the only thing I am
> against.
hi Jeroen.
that's great. i
On 04/29/2013 09:18 AM, Felix Salfelder wrote:
theres not even a need for a
monolithic build system within /src?
No, there is no need for a monolithic build system. In fact, I prefer a
separate build system for each "module". Of course, there should be a
top-level Makefile which runs the build
Hi There
i have updated my proposal, taking into account the discussion. I've
mostly extended the Details section. Thanks for reading.
=== Title, Project Synopsis
"Get Sage ready for Linux distributions"
Sage is currently shipped as a software distribution that, next to
genuine code, includes al
2013/4/23 Felix Salfelder :
> Hi There
Hi,
Sorry for only commenting in this thread this late; I have been very
busy with my work and should still be for a few months, but always
find some time to contribute and work on some personal projects :-)
I had a sagemath review request for Fedora
On Tue, Apr 23, 2013 at 06:08:54PM -0300, Paulo César Pereira de Andrade wrote:
> I will make a few comments, attempting to be as constructive
> as possible :-)
Hi Paolo, hi list.
Thanks for going through all this. i'll consider your comments as far
as the scope of this project allows.
> The
On 04/24/2013 11:46 AM, Felix Salfelder wrote:
part of my proposal is
to make it possible to just install sage ("the distribution") skipping
everything but the core modules and the notebook.
So your plan is to make it possible to run configure and make for each
directory in /src separately, bu
Hi Tobias.
On Wed, Apr 24, 2013 at 02:47:06PM +0200, Tobias Hansen wrote:
> On 04/24/2013 11:46 AM, Felix Salfelder wrote:
> >part of my proposal is
> >to make it possible to just install sage ("the distribution") skipping
> >everything but the core modules and the notebook.
>
> So your plan is t
41 matches
Mail list logo
