On 07/ 1/10 05:26 AM, François Bissey wrote:
I must admit, I can't follow your patch - one obvious thing is that it
would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
to yes. I've not actually applied your version. I'm actually sitting
in bed now, and have given up coding tod
I've tried to build a slightly modified version of Sage 4.5.alpha1 on
OpenSolaris x64 as a 64-bit application, but have hit two non-trivial issues.
* Maxima will not build.
* R will not build
So I typed
$ touch spkg/installed/maxima-$version
$ touch spkg/installed/r-$Rversion
$ SAGE_PARALLEL
> On 07/ 1/10 05:26 AM, François Bissey wrote:
> >> I must admit, I can't follow your patch - one obvious thing is that it
> >> would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
> >> to yes. I've not actually applied your version. I'm actually sitting
> >> in bed now, and have
> I've tried to build a slightly modified version of Sage 4.5.alpha1 on
> OpenSolaris x64 as a 64-bit application, but have hit two non-trivial
> issues.
>
> * Maxima will not build.
> * R will not build
>
> So I typed
>
> $ touch spkg/installed/maxima-$version
> $ touch spkg/installed/r-$Rv
On 1 July 2010 09:54, François Bissey wrote:
>> I've tried to build a slightly modified version of Sage 4.5.alpha1 on
>> OpenSolaris x64 as a 64-bit application, but have hit two non-trivial
>> issues.
>>
>> * Maxima will not build.
>> * R will not build
>>
>> So I typed
>>
>> $ touch spkg/ins
I was thinking of "sage -testall" make test does a few things before
starting sage -testall that I suspect will stop the whole thing.
Francois
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googleg
I propose that we make GNU patch a standard package, so that patches
to Sage can be made in a more sensible manner than using 'cp' as now.
(There's no point in 'patch' being optional at all, as it would be
needed when building Sage).
For
* It is small - the source code is about 240 KB, so a Sage
On 30 June 2010 08:29, Robert Bradshaw wrote:
> On Jun 28, 2010, at 10:20 AM, luisfe wrote:
>
>> Hi,
>>
>> I have found an unhandled SIGFPE in number_field_element_quadratic as
>> explained in ticket http://trac.sagemath.org/sage_trac/ticket/9357
>>
>> Basically, sage does not check if a quadratic
> I propose that we make GNU patch a standard package, so that patches
> to Sage can be made in a more sensible manner than using 'cp' as now.
> (There's no point in 'patch' being optional at all, as it would be
> needed when building Sage).
>
> For
> * It is small - the source code is about 240
On 1 July 2010 11:07, François Bissey wrote:
> I was thinking of "sage -testall" make test does a few things before
> starting sage -testall that I suspect will stop the whole thing.
>
> Francois
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from thi
+1 for the convincing reasons cited (and similar to why Sage includes
bzip2), unless there are downsides which I have not thought of.
John
On 1 July 2010 12:00, François Bissey wrote:
>> I propose that we make GNU patch a standard package, so that patches
>> to Sage can be made in a more sensib
On 1 July 2010 00:07, Jason B. Hill wrote:
>
> This seems to overlap the recent discussion on hardware and trac ticket
> #8048.
> I am about 90% done with a python script to do this on Linux, and I need to
> chop it apart and "functionalize" it, so to speak. Basically, the /proc info
> is standard
If someone wants an easy patch to review,
http://trac.sagemath.org/sage_trac/ticket/9399
should come pretty easy. Currently a header file is included on all
operating systems except Solaris (where _sun_ is defined). This just
removes the Sun specific bits and makes the header file behave no
diffe
[Yes] Include GNU patch as a standard package in Sage
Sounds good to me.
Adam
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.g
It is officially none of my business what you decide.
However, given that developers are the only people likely
to know how to create and post a diff-Naur patch file and
developers are likely able to install tools and 'patch' is
a well-known, widely used, and standard tool ...
does it make sense
+1
-Ivan
On Jul 1, 2010, at 5:18 AM, David Kirkby wrote:
> I propose that we make GNU patch a standard package, so that patches
> to Sage can be made in a more sensible manner than using 'cp' as now.
> (There's no point in 'patch' being optional at all, as it would be
> needed when building Sage
Is there an easy way to make this work?
% sage -R
R version 2.10.1 (2009-12-14)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()
Yes, I agree. I missed the point.
David Kirkby wrote:
On 1 July 2010 15:26, Tim Daly wrote:
It is officially none of my business what you decide.
However, given that developers are the only people likely
to know how to create and post a diff-Naur patch file and
developers are likely able to
On 1 July 2010 15:26, Tim Daly wrote:
> It is officially none of my business what you decide.
> However, given that developers are the only people likely
> to know how to create and post a diff-Naur patch file and
> developers are likely able to install tools and 'patch' is
> a well-known, widely
On 1 July 2010 15:30, Jason Grout wrote:
> Would it make sense to have a sage-wide SAGE_COMPILE_GUI switch that enables
> these command-line graphics options for all packages, rather than having
> separate matplotlib, R, etc., compile option variables?
>
> Thanks,
>
> Jason
It makes sence to hav
> > It is officially none of my business what you decide.
> > However, given that developers are the only people likely
> > to know how to create and post a diff-Naur patch file and
> > developers are likely able to install tools and 'patch' is
Ixnay on the developers being likely to know how to i
On 7/1/10 3:18 AM, David Kirkby wrote:
I propose that we make GNU patch a standard package, so that patches
to Sage can be made in a more sensible manner than using 'cp' as now.
(There's no point in 'patch' being optional at all, as it would be
needed when building Sage).
For the discussion, I
On Jul 1, 10:30 am, Jason Grout wrote:
> Is there an easy way to make this work?
>
> % sage -R
>
> R version 2.10.1 (2009-12-14)
> Copyright (C) 2009 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to
> I propose that we make GNU patch a standard package, so that
patches
> > to Sage can be made in a more sensible manner than using 'cp' as now.
> > (There's no point in 'patch' being optional at all, as it would be
> > needed when building Sage).
>
> For the discussion, I believe David is referri
On Thu, Jul 1, 2010 at 9:03 AM, kcrisman wrote:
> > I propose that we make GNU patch a standard package, so that
> patches
>> > to Sage can be made in a more sensible manner than using 'cp' as now.
>> > (There's no point in 'patch' being optional at all, as it would be
>> > needed when building S
Dear all,
At Sagedays 16 David Kohel gave a talk about ECHIDNA, which is a
database of open-source code for MAGMA, and invited people to port it
to SAGE. I am planning to port his code for computing dimensions of
eigenspaces of the Atkin-Lehner operator to SAGE (he has released this
under the GPL)
On Thu, Jul 1, 2010 at 10:50 AM, Lloyd Kilford wrote:
> Dear all,
>
> At Sagedays 16 David Kohel gave a talk about ECHIDNA, which is a
> database of open-source code for MAGMA, and invited people to port it
> to SAGE. I am planning to port his code for computing dimensions of
> eigenspaces of the
On 1 July 2010 18:02, William Stein wrote:
> I vote NO to including patch in sage.
>
> 1. We can accomplish the same thing when creating the spkg. E.g, the command
>
> sage -pkg foo-1.2.3
>
> could *automatically* apply patch using each file in
> foo-1.2.3/patches/ and create the corresponding
On Thu, Jul 1, 2010 at 11:21 AM, David Kirkby wrote:
> On 1 July 2010 18:02, William Stein wrote:
>
>> I vote NO to including patch in sage.
>>
>> 1. We can accomplish the same thing when creating the spkg. E.g, the command
>>
>> sage -pkg foo-1.2.3
>>
>> could *automatically* apply patch usin
On 1 July 2010 19:26, William Stein wrote:
> My suggestion requires changing no spkg-install files; your involves
> changing all of them.
> Mine does involve rewriting patches/ directories though.
> William Stein
As I made clear, I doubt anyone would go around changing the patches
which are cur
On Thu, Jul 1, 2010 at 11:47 AM, David Kirkby wrote:
> On 1 July 2010 19:26, William Stein wrote:
>
>> My suggestion requires changing no spkg-install files; your involves
>> changing all of them.
>> Mine does involve rewriting patches/ directories though.
>
>> William Stein
>
> As I made clear,
On 1 July 2010 19:49, William Stein wrote:
> On Thu, Jul 1, 2010 at 11:47 AM, David Kirkby wrote:
>> Others have expressed dismay at the way the patching currently works.
>
> My proposal does involve using patch. It's just that patch is used
> automatically by
> "sage -pkg" rather than explicit
What are others' thoughts on this? I can do a script as well, but only for
Linux. I am also wondering how one would sort by OS, since it is my
understanding that the main identifier (uname) is about as consistent
between platforms as /etc/issue is between linux distros.
I'm off to the mountains fo
On Thu, Jul 1, 2010 at 12:05 PM, David Kirkby wrote:
> I don't understand your proposal. Would it need the patch command
> added to Sage? I don't understand your method, so can't comment
> really.
William's proposal is to
1) Standardize the filenames of patches so that the only file which
patche
Have you asked David about this? I have a feeling he may have started
to do this. See #6426.
John
On 1 July 2010 18:53, William Stein wrote:
> On Thu, Jul 1, 2010 at 10:50 AM, Lloyd Kilford wrote:
>> Dear all,
>>
>> At Sagedays 16 David Kohel gave a talk about ECHIDNA, which is a
>> database
On Thu, Jul 1, 2010 at 12:25 PM, Mike Hansen wrote:
> On Thu, Jul 1, 2010 at 12:05 PM, David Kirkby wrote:
>> I don't understand your proposal. Would it need the patch command
>> added to Sage? I don't understand your method, so can't comment
>> really.
>
> William's proposal is to
>
> 1) Standar
On 2010-Jul-01 13:09:30 -0600, "Jason B. Hill" wrote:
>What are others' thoughts on this? I can do a script as well, but only for
>Linux. I am also wondering how one would sort by OS, since it is my
>understanding that the main identifier (uname) is about as consistent
>between platforms as /etc/i
I am not completely sure that I understand how William's proposal
affects the procedure for making spkgs. What I have done the last
couple of times that I made an spkg update is:
1. sage -sh
2. tar xjf package.p0.spkg
3. replace src with the new version
4. (re)place files in package.p0/patches
On Thu, Jul 1, 2010 at 2:07 PM, Nils Bruin wrote:
> I am not completely sure that I understand how William's proposal
> affects the procedure for making spkgs. What I have done the last
> couple of times that I made an spkg update is:
> 1. sage -sh
> 2. tar xjf package.p0.spkg
> 3. replace src
Hi Ryan,
On Wed, 30 Jun 2010 14:49:59 -0700 (PDT)
Ryan Hinton wrote:
> I was looking for a way to use Sage to do some symbolic summations,
> products, exponentiation, etc. For background, see
>
> http://groups.google.com/group/sage-support/browse_thread/thread/e4ac1eabec630f99/81e1a71e4344b249
Since Sage already has lots and lots of "batteries included", I agree
to say that we should be careful about whether additional spkgs are
really needed.
I vote "-1" to the inclusion of an additional "patch.spkg".
May I assume there is consensus about mercurial (once successfully
installed) provid
On Thu, Jul 1, 2010 at 2:43 PM, Georg S. Weber
wrote:
> Since Sage already has lots and lots of "batteries included", I agree
> to say that we should be careful about whether additional spkgs are
> really needed.
>
> I vote "-1" to the inclusion of an additional "patch.spkg".
>
> May I assume ther
I'm missing something. What's broken, and why do you want to fix it?
On Thu, Jul 1, 2010 at 3:18 AM, David Kirkby wrote:
> I propose that we make GNU patch a standard package, so that patches
> to Sage can be made in a more sensible manner than using 'cp' as now.
> (There's no point in 'patch' b
I voted +1 for the idea of using patches instead of edited version of
source files, which everyone seems to agree on. I thought from
earlier postings that this requires having the patch function
installed, so voted in favour. But now it is quite clear that this is
*not* necessary, so I withdraw t
When Sage starts on my OpenSolaris machine it crashes, with a segfault and a
message about "...or is not properly wrapped with _sig_on, _sig_off"
Having a look in the source code, I believe _sig_on and _sig_off should be in
pairs - is that correct? If so, should there not be an equal number of
On Thu, Jul 1, 2010 at 3:18 PM, Dr. David Kirkby
wrote:
> When Sage starts on my OpenSolaris machine it crashes, with a segfault and a
> message about "...or is not properly wrapped with _sig_on, _sig_off"
>
> Having a look in the source code, I believe _sig_on and _sig_off should be
> in pairs -
On Jul 1, 2:17 pm, William Stein wrote:
> My entire proposal is:
>
> Modify "sage -pkg" so that it generates the patched files from the patches.
>
> That's it.
Part of the original proposal, if I understand it, was just to
distribute the patches in order to make the spkg files smaller. I
don
On Thu, Jul 1, 2010 at 3:25 PM, John H Palmieri wrote:
> On Jul 1, 2:17 pm, William Stein wrote:
>
>> My entire proposal is:
>>
>> Modify "sage -pkg" so that it generates the patched files from the
>> patches.
>>
>> That's it.
>
> Part of the original proposal, if I understand it, was just to
What's the best way to go about debugging a Sage which wont start up? I've tried
running it under gdb, and that don't help me a lot. Also tried loading the core
file, and again its not being very useful.
Both python and ipython seem functional.
I guess the fact the source code has been deleted
On Thu, Jul 1, 2010 at 4:02 PM, Dr. David Kirkby
wrote:
> What's the best way to go about debugging a Sage which wont start up? I've
> tried running it under gdb, and that don't help me a lot. Also tried loading
> the core file, and again its not being very useful.
If this is opensolaris, then th
On 07/ 2/10 12:06 AM, William Stein wrote:
On Thu, Jul 1, 2010 at 4:02 PM, Dr. David Kirkby
wrote:
What's the best way to go about debugging a Sage which wont start up? I've
tried running it under gdb, and that don't help me a lot. Also tried loading
the core file, and again its not being very
On 07/ 2/10 12:06 AM, William Stein wrote:
On Thu, Jul 1, 2010 at 4:02 PM, Dr. David Kirkby
wrote:
What's the best way to go about debugging a Sage which wont start up? I've
tried running it under gdb, and that don't help me a lot. Also tried loading
the core file, and again its not being very
On 1 July 2010 20:25, Mike Hansen wrote:
> On Thu, Jul 1, 2010 at 12:05 PM, David Kirkby wrote:
>> I don't understand your proposal. Would it need the patch command
>> added to Sage? I don't understand your method, so can't comment
>> really.
>
> William's proposal is to
>
> 1) Standardize the fi
53 matches
Mail list logo
