On Monday 04 August 2008 16:22:35 Will Coleda via RT wrote:
> Post pdd25cx mergeback, updating the syntax yet again, and simplifying it
> slightly, we have the attached file, which generates:
>
> ok #test exception from init vtable
> not ok #test exception from init vtable
>
> Even better, remove
On Thursday 31 July 2008 15:16:33 Donald Hunter wrote:
> This is a patch for t/pmc/os.t to fix test failures on Cygwin. This is
> generated against revision 29913.
Thanks, applied as r30050.
> One anomaly remains. The test was skipping the inode field for Cygwin
> because the installed Perl 5 is
On Sunday 03 August 2008 05:15:07 Reini Urban wrote:
> Attached patch adds support for the old ctags/etags from XEmacs 21
Thanks, applied as r30049.
-- c
On Tuesday 05 August 2008 01:35:48 Reini Urban wrote:
> Attached patch adds the directory ports/cygwin with
> the most recent cygports file,
> the most recent src patch and the sources for the CYGWIN patches.
> (the contents of parrot-0.6.4-2.cygwin.patch which creates those files
> in CYGWIN-PATC
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #57638]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57638 >
>From PDD19:
{{DEPRECATION NOTE: PIR will no longer support the old PASM-style syntax
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #57634]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57634 >
hi,
in PIR you can use the .globalconst directive in a sub to define a constant
that
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #57636]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57636 >
>From pdd19:
The optional C<:unique_reg> modifier will force the register allocator t
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #57630]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57630 >
PDD09 says that the acronym "DOD" for "dead object detection" is
deprecated. At the
# from jerry gay
# on Tuesday 05 August 2008 14:13:
>>On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell wrote:
>> Which reminds me: chromatic, what was your reasoning for major
>> releases being every three months, instead of four or six?
>>
>> I agree we don't want to go much beyond six months f
On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote:
>> We also need to think about deprecation cycles. If you deprecate a
>> feature in 1 version and then it disappears in the next then the time
>> between when my
On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote:
> We also need to think about deprecation cycles. If you deprecate a
> feature in 1 version and then it disappears in the next then the time
> between when my code works and when it doesn't is only 6 months. Some
> distros provide support
On Tuesday 05 August 2008 13:19:52 Michael Peters wrote:
> If you deprecate a
> feature in 1 version and then it disappears in the next then the time
> between when my code works and when it doesn't is only 6 months. Some
> distros provide support for several years.
If they want to support ancien
On Tuesday 05 August 2008 13:14:27 Geoffrey Broadwell wrote:
> > I can see patching the previous release in case of a critical bugfix, but
> > if we get in the habit of encouraging users to expect updates of anything
> > older than the previous stable release for free, we've doomed the
> > project
On Aug 5, 2008, at 3:46 PM, Geoffrey Broadwell wrote:
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote:
["branch" feature]
This sounds very useful. Is the SVK paradigm changing so that online
use is assumed, and offline is a mode to switch to temporarily?
No. But that's a common eno
Geoffrey Broadwell wrote:
Complete and
utter refusal to support users who expect that they can install Parrot 1.0
and get free support from the mailing list or IRC for the next eight to ten
years.
Half agree. I agree that we should only *directly* support a release
for a limited time, thoug
On Tue, 2008-08-05 at 12:54 -0700, chromatic wrote:
> On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
> > bugfixes that should be backported to one or more already released
> > versions and re-released immediately.
>
> I can see patching the previous release in case of a critical bugfi
On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
> We will definitely need multiple long-lived branches. Just to make
> explicit the reasoning: data loss, security, or otherwise critical
> bugfixes that should be backported to one or more already released
> versions and re-released im
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote:
> ["branch" feature]
This sounds very useful. Is the SVK paradigm changing so that online
use is assumed, and offline is a mode to switch to temporarily? I'm
used to thinking of SVK in one two ways:
1. As a better SVN client for normal
On Tue, 2008-08-05 at 13:20 -0400, Will Coleda wrote:
> On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > Gah, no maintenance releases please! See "Mommy, why did it take over five
> > years to release a new stable version of Perl 5 with a bugfix I made in
> > 2002?"
>
> Per
Author: kjs
Date: Tue Aug 5 11:16:36 2008
New Revision: 30041
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
[pdd19] add an RT ticket referring to deprecated old-style pasm registers
deprecation decision.
Modified: trunk/docs/pdds/pdd19_pir.pod
On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 August 2008 09:48:22 Will Coleda wrote:
>
>> Branches that don't rebase from trunk regularly are out of
>> touch, yes. If you rebase regularly, then you're basically just a
>> patch waiting to be applied.
> ... an
On Tuesday 05 August 2008 09:48:22 Will Coleda wrote:
> Branches that don't rebase from trunk regularly are out of
> touch, yes. If you rebase regularly, then you're basically just a
> patch waiting to be applied.
... and, as time goes by, an ever-larger patch waiting to land on trunk with a
big
On Tue, Aug 5, 2008 at 12:16 PM, Andy Lester <[EMAIL PROTECTED]> wrote:
>
> On Aug 5, 2008, at 11:12 AM, chromatic wrote:
>
>> Don't use long-lived branches. The smaller the merge in *any* system, the
>> easier it is.
>
>
> I agree 100%. If you think your project is so big that you have to have a
On Aug 5, 2008, at 11:12 AM, chromatic wrote:
Don't use long-lived branches. The smaller the merge in *any*
system, the
easier it is.
I agree 100%. If you think your project is so big that you have to
have a long-lived branch, then it should be broken up into smaller,
mergeable miles
On Tuesday 05 August 2008 07:51:35 Will Coleda wrote:
> Using svn as a backing store, how can we more easily work with long
> lived branches?
>
> I've some existing branches which are long lived, and doing the svn
> merge either way is extremely slow.
>
> I know much of our community used svk for
On Tue Jul 01 18:56:40 2008, coke wrote:
> On Thu Nov 29 22:08:11 2007, [EMAIL PROTECTED] wrote:
> > Will Coleda wrote:
> > >
> > > 1) using getclass (aka, reject this ticket)
> > > 2) doing something custom for the say method here (like, say,
> > > translating say 'what' into something like "getst
On Aug 5, 2008, at 11:50 AM, Reini Urban wrote:
2008/8/5 Will Coleda <[EMAIL PROTECTED]>:
So these branch commands actually create branches on the svn
repository that's doing the hosting, so they're defacto shared with
the community in the obvious location? (presuming you're online and
pushing
--- Begin Message ---
Will Coleda wrote:
On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote:
Git is really nice for:
local branches,
This is on par with svk...
frequently(daily) rebasing local branches to keep in sync with HEAD,
How does this work?
2008/8/5 Will Coleda <[EMAIL PROTECTED]>:
> So these branch commands actually create branches on the svn
> repository that's doing the hosting, so they're defacto shared with
> the community in the obvious location? (presuming you're online and
> pushing changes back?)
>
> That seems to be the best
On Aug 5, 2008, at 11:32 AM, Will Coleda wrote:
[SVK 2.2]
Sounds spiffy.
So these branch commands actually create branches on the svn
repository that's doing the hosting, so they're defacto shared with
the community in the obvious location? (presuming you're online and
pushing changes back?
On Tue, Aug 5, 2008 at 11:19 AM, Jesse Vincent <[EMAIL PROTECTED]> wrote:
>
> On Aug 5, 2008, at 10:51 AM, Will Coleda wrote:
>
>> Using svn as a backing store, how can we more easily work with long
>> lived branches?
>>
>> I've some existing branches which are long lived, and doing the svn
>> merg
On Aug 5, 2008, at 10:51 AM, Will Coleda wrote:
Using svn as a backing store, how can we more easily work with long
lived branches?
I've some existing branches which are long lived, and doing the svn
merge either way is extremely slow.
I know much of our community used svk for a while; I thin
On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote:
> Git is really nice for:
>local branches,
This is on par with svk...
>frequently(daily) rebasing local branches to keep in sync with HEAD,
How does this work? What's the pain threshold?
>publishing local branches
Git is really nice for:
local branches,
frequently(daily) rebasing local branches to keep in sync with HEAD,
publishing local branches for others to review,
allowing non-committers to make changes and publish those changes
publicly
Kevin
Will Coleda wrote:
Using svn as a backi
Using svn as a backing store, how can we more easily work with long
lived branches?
I've some existing branches which are long lived, and doing the svn
merge either way is extremely slow.
I know much of our community used svk for a while; I think the usage
there has dropped off as git is the new
On Tue, Aug 5, 2008 at 10:39 AM, Ronald Schmidt
<[EMAIL PROTECTED]> wrote:
> Michael Peters wrote:
>>
>> Ronald Schmidt wrote:
>> I've been meaning to update that wiki page to point to the progress we're
>> making toward this. I should also write up how Smolder already accomplishes
>> those goals (
Michael Peters wrote:
Ronald Schmidt wrote:
I've been meaning to update that wiki page to point to the progress
we're making toward this. I should also write up how Smolder already
accomplishes those goals (well, the ones it does accomplish).
Thanks. If I had noticed that smolder was already
As far as I could see, it seems that the whole "n_operators" thing is no
longer mentioned in pdd19.
if it's what Pm thinks, just a change from ".pragma n_operators" to
".n_operators", then that should be added.
kjs
On Sat, Aug 2, 2008 at 6:56 PM, Patrick R. Michaud <[EMAIL PROTECTED]>wrote:
> O
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #57610]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57610 >
pdd23:
Exception handlers can resume execution immediately after the
"throw" opcode by
On Thu, Jul 31, 2008 at 8:20 PM, via RT Will Coleda
<[EMAIL PROTECTED]> wrote:
> The parrot_debugger version should, IMO, be identical to the parrot
> version. (e.g., it's currently reporting as 0.4 instead of 0.6.x.)
Done in r30034
--
Salu2
40 matches
Mail list logo
