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,
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
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
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 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 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
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
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
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
29 matches
Mail list logo
