On Thu, Jul 15, 2010 at 2:22 AM, John Cremona wrote:
>>
>> +1 I really like this idea. All the advantages of mercurial queues
>> without the late dependancies or requirement that the source be under
>> revision control. (The patch queue itself would be under the .spkg
>> control). The actual pushi
>
> +1 I really like this idea. All the advantages of mercurial queues
> without the late dependancies or requirement that the source be under
> revision control. (The patch queue itself would be under the .spkg
> control). The actual pushing of a series could probably be a simple
> command in spkg
On Wed, Jul 14, 2010 at 6:01 PM, Carl Witty wrote:
> On Sat, Jul 3, 2010 at 6:27 AM, Volker Braun wrote:
>> I would propose a mercurial patch queue in the spgk root directory.
>> Then sage -pkg simply checks that either all patches in the queue are
>> applied or that there exists an old-style /pa
On Sat, Jul 3, 2010 at 6:27 AM, Volker Braun wrote:
> I would propose a mercurial patch queue in the spgk root directory.
> Then sage -pkg simply checks that either all patches in the queue are
> applied or that there exists an old-style /patches directory and no
> queue.
Since we all seem to lik
On 07/ 4/10 11:15 AM, Volker Braun wrote:
Does sage compile on anything but linux on itanium systems?
Probably not. But it would be shortsighted to write code that would make future
ports more difficult than necessary.
Several years ago, nobody had attempted to build Sage on 64-bit Solaris,
Does sage compile on anything but linux on itanium systems? But I
agree that, if the code is itanium linux-specific, then it must be
wrapped into
#if defined(__linux__) && ( defined(__ia64__)
// itanium linux specific
#endif
About the "readline on itanium" patch, wtf is going on? That patch is
ju
On 07/ 3/10 07:57 PM, Volker Braun wrote:
I believe its
#ifdef __ia64__
// gcc itanium code here
#endif
You would certainly want to add an 'ifdef linux' or similar, since Itanitium
processors can run FreeBSD, Windows, HP-UX and probably some other operating
systems too. (Sun started a port o
I believe its
#ifdef __ia64__
// gcc itanium code here
#endif
On Jul 3, 7:48 pm, Mike Hansen wrote:
> Here is an example patch for Python that is only applied on Itanium
> Linux systems:http://sage.pastebin.com/1hy3cyis
>
> Is there a non-autoconf way to have an ifdef to check for an Itanium
>
On Jul 3, 4:54 pm, Mike Hansen wrote:
> 1) The src/ directory needs be under Mercurial version control. This
> would increase the size of the spkgs by quite a bit.
But you don't need to add all of src/. In fact, you could keep src
in .hgignore and only selectively hg add the files that you actua
On Sat, Jul 3, 2010 at 6:27 AM, Volker Braun wrote:
> I would propose a mercurial patch queue in the spgk root directory.
> Then sage -pkg simply checks that either all patches in the queue are
> applied or that there exists an old-style /patches directory and no
> queue.
I think there are some i
I would propose a mercurial patch queue in the spgk root directory.
Then sage -pkg simply checks that either all patches in the queue are
applied or that there exists an old-style /patches directory and no
queue.
Complicated spkgs that require lots of modifications would then use a
patch queue. Th
On Fri, Jul 2, 2010 at 11:52 AM, William Stein wrote:
> Why? Consider that we *already* successfully conditionally patch
> files without using patch at all... and this works for every spkg
> included in Sage.
Right, but it's all managed by hand. Once you start making automating
things, then th
On Fri, Jul 2, 2010 at 1:10 AM, Mike Hansen wrote:
> I don't think it's feasible to carry out William's proposal with
> conditional patches.
Why? Consider that we *already* successfully conditionally patch
files without using patch at all... and this works for every spkg
included in Sage.
>
> On Fri, 2 Jul 2010 01:10:25 -0700
>
> Mike Hansen wrote:
> > I don't think it's feasible to carry out William's proposal with
> > conditional patches. I'm +1 on including GNU patch in Sage.
>
> I also vote YES to including patch in Sage.
>
> I would like to see some more standardization in h
On Fri, 2 Jul 2010 01:10:25 -0700
Mike Hansen wrote:
> I don't think it's feasible to carry out William's proposal with
> conditional patches. I'm +1 on including GNU patch in Sage.
I also vote YES to including patch in Sage.
I would like to see some more standardization in how the patches are
I don't think it's feasible to carry out William's proposal with
conditional patches. I'm +1 on including GNU patch in Sage.
--Mike
--
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
Fo
On Jul 2, 2010 8:02am, Adam Webb wrote:
I felt that the important part of the proposal was the use of patches.
Yes.
I don't know if there will really be a lot of space saved but I think
that is less important.
Agreed. But the point I would make is that just removing two of the huge
p
On Jul 2, 2010 8:02am, Adam Webb wrote:
I felt that the important part of the proposal was the use of patches.
Yes.
I don't know if there will really be a lot of space saved but I think
that is less important.
Agreed. But the point I would make is that just removing two of the huge
p
On Jul 2, 8:01 am, David Kirkby wrote:
> 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
> >>
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
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
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 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
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: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
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 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 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
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
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: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: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 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 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
> 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 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
> > 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 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
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
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
[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
41 matches
Mail list logo
