On Jan 24, 2010, at 2:48 AM, Dima Pasechnik wrote:
Robert,
On Jan 24, 5:29 pm, Robert Bradshaw
wrote:
On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Ironically, I personally find shipping all our dependancies ma
Robert,
On Jan 24, 5:29 pm, Robert Bradshaw
wrote:
> On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote:
>
> > Robert,
> > the advantage is that it will simplify the *development* of Sage.
>
> Ironically, I personally find shipping all our dependancies makes
> development easier--I don't have to
On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Ironically, I personally find shipping all our dependancies makes
development easier--I don't have to worry about someone else using
different version than I have,
Hi Georg,
On Jan 24, 1:24 am, "Georg S. Weber"
wrote:
> Hi Dmitrii,
>
>
>
>
>
> > OK, I oversimplified.
>
> > As far as a practical step towards having more flexibility:
> > Presently Sage does not have any mechanism allowing for "virtual"
> > packages (I am stealing from Debian/Fink here)
> > th
Hi Dmitrii,
> OK, I oversimplified.
>
> As far as a practical step towards having more flexibility:
> Presently Sage does not have any mechanism allowing for "virtual"
> packages (I am stealing from Debian/Fink here)
> that would allow for using the already installed, somewhere on the
> system, no
William,
On Jan 23, 3:37 am, William Stein wrote:
> On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> > William Stein wrote:
>
> >> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>
> >>> Robert,
> >>> the advantage is that it will simplify the *development* of Sage.
> >>> Right
Martin Albrecht wrote:
It looks like there are plenty of patches to singular: spkg-install
contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Sin
CC to [libsingular-devel] to make the Singular development team (which has
been incredibly helpful and supportive in the past!) aware of this discussion.
> >> I so wish you were right!The programs you refer to like Singular
> >> are very simple and tiny compared to Sage. If things were so ea
Dag Sverre Seljebotn wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come
William Stein wrote:
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I a
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> William Stein wrote:
>>
>> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>>>
>>> Robert,
>>> the advantage is that it will simplify the *development* of Sage.
>>> Right now lots of stoppers seem to come from upstream packages.
>>>
>>
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> William Stein wrote:
>>
>> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>>>
>>> Robert,
>>> the advantage is that it will simplify the *development* of Sage.
>>> Right now lots of stoppers seem to come from upstream packages.
>>>
>>
Dr. David Kirkby wrote:
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" o
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" of
packages. Somehow
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
> Robert,
> the advantage is that it will simplify the *development* of Sage.
> Right now lots of stoppers seem to come from upstream packages.
>
> I also do not see a real problem with "specific versions" of
> packages. Somehow,
> all the o
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" of
packages. Somehow,
all the other open-source math projects seem to be able to manage this
well,
e
William Stein wrote:
But tell me what perl modules are needed. If
1) There is some agreeemnt to exit if they do not exist AND
2) There is some reasonably simple way of checking for them,
IIRC, the only place perl is used in all of Sage is for the PARI and
NTL build systems.
I don't know what
On 2010-Jan-22 02:09:05 -0200, Gonzalo Tornaria
wrote:
>If it could be done with gfortran, it can be done with other
>dependencies.
Well, gfortran was included for some targets only. Having to include
gfortran (and support libraries) for all supported targets would
definitely and unnecessarily
On Thu, Jan 21, 2010 at 10:41 PM, Dr. David Kirkby
wrote:
> Gonzalo Tornaria wrote:
>>
>> On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
>> wrote:
>>>
>>> But sorting out whether the version of libraries on a system are
>>> suitable,
>>> can be tricky. Even having the right versions does not g
Gonzalo Tornaria wrote:
On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
wrote:
But sorting out whether the version of libraries on a system are suitable,
can be tricky. Even having the right versions does not guarantee they will
be found in preference to some other version.
Sure. We already
On Fri, 22 Jan 2010 19:27:56 Gonzalo Tornaria wrote:
> > If you are only going to shave off 20 MB or so from the source code, it
> > might be more hassle than it is worth. If you could cut the download time
> > by 30%, then I could see it would probably be worth the effort in doing
> > this. But I'
On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
wrote:
> But sorting out whether the version of libraries on a system are suitable,
> can be tricky. Even having the right versions does not guarantee they will
> be found in preference to some other version.
Sure. We already have related issues.
On Thu, Jan 21, 2010 at 8:09 PM, Gonzalo Tornaria
wrote:
>>> I think Sage is mature enough now to slowly migrate toward this.
>>> Besides, there can still be spkgs for those packages, and there could
>>> be a sage-with-batteries-included tarball with dependencies included.
>>
>> What would be the
Gonzalo Tornaria wrote:
Plus, there can *still* be spkgs for all the dependencies. And there
could be a "sage-with-batteries-included" tarball which works just as
it does now. And another
"sage-reduced-for-expert-developers-and-distros" tarball which doesn't
include the spkgs which can be replac
On Thu, Jan 21, 2010 at 7:11 PM, William Stein wrote:
> +1 to Robert's comments. I can't tell you how many people just in the
> last few days have told me that they use (and work on!) Sage *only*
> because when they try to build it on their computer it "just worked".
Do people tell you when they
On Thu, Jan 21, 2010 at 6:05 PM, Robert Bradshaw
wrote:
> On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
>
>> On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
>>>
>>> My personal feeling is that it would be nice if some of the more generic
>>> packages (eg bzip, zlib, readline, mercuria
On Thu, Jan 21, 2010 at 12:05 PM, Robert Bradshaw
wrote:
>
> On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
>
>> On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
>>>
>>> My personal feeling is that it would be nice if some of the more generic
>>> packages (eg bzip, zlib, readline, mercu
On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy
wrote:
My personal feeling is that it would be nice if some of the more
generic
packages (eg bzip, zlib, readline, mercurial) were moved out of sage
and made explicit requirements.
+1
I th
On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
> My personal feeling is that it would be nice if some of the more generic
> packages (eg bzip, zlib, readline, mercurial) were moved out of sage
> and made explicit requirements.
+1
I think Sage is mature enough now to slowly migrate toward t
On 2010-Jan-17 04:53:11 +, "Dr. David Kirkby"
wrote:
>Could an argument not be made to the Debian people that the code is
>gap singular etc, but patched versions of them. Call them Foo and Bar
>if necessary! No seriously, I can understand them not wanting
>'standard' things packaged, but if t
2010/1/16 Dima Pasechnik :
>
>
> On Jan 17, 12:53 pm, "Dr. David Kirkby"
> wrote:
>> Dima Pasechnik wrote:
>> > I understand that Debian support is on hold. AFAIK, a proper Debian
>> > requires a complete refactoring
>> > of the code, in particular removing all the things that are not really
>> >
On Jan 17, 12:53 pm, "Dr. David Kirkby"
wrote:
> Dima Pasechnik wrote:
> > I understand that Debian support is on hold. AFAIK, a proper Debian
> > requires a complete refactoring
> > of the code, in particular removing all the things that are not really
> > Sage, e.g. mercurial, gap, singular, e
2010/1/16 Dima Pasechnik :
> I understand that Debian support is on hold. AFAIK, a proper Debian
> requires a complete refactoring
> of the code, in particular removing all the things that are not really
> Sage, e.g. mercurial, gap, singular, etc etc etc.
> I understand it has been done at some poi
Dima Pasechnik wrote:
I understand that Debian support is on hold. AFAIK, a proper Debian
requires a complete refactoring
of the code, in particular removing all the things that are not really
Sage, e.g. mercurial, gap, singular, etc etc etc.
I understand it has been done at some point for Sage 3
I understand that Debian support is on hold. AFAIK, a proper Debian
requires a complete refactoring
of the code, in particular removing all the things that are not really
Sage, e.g. mercurial, gap, singular, etc etc etc.
I understand it has been done at some point for Sage 3, but then the
main pers
Robert Miller wrote:
Greetings!
sage-4.3.1.rc0 is finally here. This should be a good base version for
Bug Days, and closes a good deal of tickets. I thought it would be
good to plan on an rc1 with just the ticket to fix building on OS X
10.6 (thoughts?). Also, reverting #7818 fixed a good deal
On 16 led, 07:42, Robert Miller wrote:
> Greetings!
>
> sage-4.3.1.rc0 is finally here. This should be a good base version for
> Bug Days, and closes a good deal of tickets. I thought it would be
> good to plan on an rc1 with just the ticket to fix building on OS X
> 10.6 (thoughts?). Also, reve
38 matches
Mail list logo
