Re: [perl #38432] [BUG] Exception thrown from constructor leads to oddness/segfault

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

Re: [perl #57486] [patch] Fix stat / lstat test failure on Cygwin

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

Re: [perl #57546] [PATCH] tags-xemacs

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

Re: [perl #57608] [PATCH] add ports/cygwin

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

Re: [perl #57626] [BUG] perl6 -e 'say "hello"' ==> Segmentation fault

On Tuesday 05 August 2008 07:50:41 [EMAIL PROTECTED] (via RT) wrote: > * Today I downloaded parrot-0.6.4 to my Debian PC. > * I also installed the libicu-dev, libicu38 packages before configuration > * cd parrot-0.6.4; perl Configure.pl; make; cd languages/perl6; make perl6 > * It seems that every

Re: A few multiple dispatch questions

On Tuesday 05 August 2008 15:25:47 Bob Rogers wrote: >On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: >> I believe "veto" is giving the wrong idea here as something that >> happens after the fact.  What's the term for only allowing >> "acceptable" candidates to put their names

[perl #57638] [IMCC] old-style PASM registers no longer supported.

# 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

[perl #57634] [RFC] Remove ".globalconst" from PIR

# 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

[perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag

# 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

[perl #57630] [TODO] Deprecate "DOD" acronym for PDD09

# 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

[perl #57626] [BUG] perl6 -e 'say "hello"' ==> Segmentation fault

# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #57626] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57626 > * Today I downloaded parrot-0.6.4 to my Debian PC. * I also installed the libicu-de

Re: enterprise parrot

# 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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: A few multiple dispatch questions

On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: > I believe "veto" is giving the wrong idea here as something that > happens after the fact.  What's the term for only allowing "acceptable" > candidates to put their names on the ballot? "disenfranchise" -- c

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: A few multiple dispatch questions

On Tue, Aug 05, 2008 at 06:17:30PM +0200, Jonathan Worthington wrote: > Hi, > > I am currently reviewing bits of the spec surrounding multiple dispatch > and, of course, have a question or two (I'll probably have some more > later, as the dust settles in my head). > > 1) The spec says: > > -- >

[svn:parrot-pdd] r30041 - trunk/docs/pdds

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: A few multiple dispatch questions

HaloO, Jonathan Worthington wrote: Does the "veto" take place once the multiple dispatch has given us a candidate and we try to bind the parameters to the signature, or as part of the multiple dispatch? For example, supposing I declare: multi foo(Int $a;; Num $b) { ... } # 1 multi foo(Int $a;

Re: new article, "A Romp Through Infinity"

HaloO, John M. Dlugosz wrote: Please let me know if you see any coding errors, and of course any feedback is welcome. Firstly, shouldn't there also be infinite strings? E.g. 'ab' x Inf is a regularly infinite string and ~pi as well. Other classes might have elaborate notions of infinity. The C

A few multiple dispatch questions

Hi, I am currently reviewing bits of the spec surrounding multiple dispatch and, of course, have a question or two (I'll probably have some more later, as the dust settles in my head). 1) The spec says: -- A proto also adds an implicit multi to all routines of the same short name within its

Re: Branching

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

Re: Branching

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

[perl #47972] [DEPRECATED] getclass opcode

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

Re: Branching

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

[Fwd: Re: Branching]

--- 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?

Re: Branching

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

Re: Branching

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?

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Branching

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

Re: Edits to submit - Routine/Callable

Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote: Audrey Tang 提到: However, in S02 you removed the Code class and replaced it with Routine, but that does not really work; for example, a bare block is a Code, but it cannot be a Routine since it can't be wrapped in place, and caller() would bypa

Branching

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

Re: Beta of web services to fulfill smoke "Queryability" requirements.

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 (

Re: Beta of web services to fulfill smoke "Queryability" requirements.

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

Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators

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

[perl #57610] [PATCH] Resumable exceptions

# 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

Re: [perl #57476] [pdb] parrot version

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

Re: Edits to submit

Audrey Tang 提到: However, in S02 you removed the Code class and replaced it with Routine, but that does not really work; for example, a bare block is a Code, but it cannot be a Routine since it can't be wrapped in place, and caller() would bypass it when considering caller frames. I should've

Re: syntax question: "method close is export ()"

John M. Dlugosz 提到: Does that mean that traits can come before the signature? Or should it be corrected to method close () is export { ... } It's a simple typo. Thanks, fixed in r14572. Cheers, Audrey

[svn:perl6-synopsis] r14572 - doc/trunk/design/syn

Author: audreyt Date: Tue Aug 5 02:43:49 2008 New Revision: 14572 Modified: doc/trunk/design/syn/S12.pod Log: * Typo spotted by John M. Dlugosz++: method close is export () { ... } # Wrong method close () is export { ... } # Right Modified: doc/trunk/design/syn/S12.pod ===

Re: Edits to submit

John M. Dlugosz 提到: I've edited several of the S??.pod files,but I have not heard back from the owner ($Larry, whose name is on the top of the file) about accepting merging or rejecting my changes. I've posted the files to so they don't get lost, unti

[svn:perl6-synopsis] r14571 - doc/trunk/design/syn

Author: audreyt Date: Tue Aug 5 02:38:33 2008 New Revision: 14571 Modified: doc/trunk/design/syn/S02.pod Log: * S02: A few more C<...> an C<<...>> blocks, Contributed by John M. Dlugosz++. Modified: doc/trunk/design/syn/S02.pod

syntax question: "method close is export ()"

Does that mean that traits can come before the signature? Or should it be corrected to method close () is export { ... } ?

Class Name Question

In S12, "So when you say "Dog", you're referring to both a package and a protoobject, that latter of which points to the actual object representing the class via HOW." Does that mean that the object referred to by Dog "does" both roles? In that case "the latter" is confusing wording. Or doe