[svn:parrot-pdd] r24108 - in trunk: . docs/pdds

2007-12-20 Thread allison
Author: allison Date: Thu Dec 20 00:53:11 2007 New Revision: 24108 Added: trunk/docs/pdds/pdd27_multiple_dispatch.pod Changes in other areas also in this revision: Modified: trunk/MANIFEST Log: [pdd] Launch the Multiple Dispatch PDD. Added: trunk/docs/pdds/pdd27_multiple_dispatch.pod ===

Re: [svn:parrot-pdd] r24108 - in trunk: . docs/pdds

2007-12-20 Thread Jonathan Worthington
Hi, Just given this a quick read over; looks pretty good. The only thing I don't see is a way to get the Sub PMC that is going to be invoked without actually invoking it. Invoke does the lookup and then the call, but what if I want to supply the arguments, and then just work out what will be

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

2007-12-20 Thread allison
Author: allison Date: Thu Dec 20 01:31:52 2007 New Revision: 24110 Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod (contents, props changed) Log: [pdd] Set file properties on new PDD 27. Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod ===

Re: [svn:parrot-pdd] r24108 - in trunk: . docs/pdds

2007-12-20 Thread Klaas-Jan Stol
hi, looks good as far as I can tell. W.r.t. the selection part, the "don't care" type is missing, which is "_" IIRC. So, .sub foo :multi(Integer,_,_) .param pmc i :invocant .param pmc j .param pmc k .end (must j and k be flagged as :invocant?) then this foo can be invoked with 2 parameters,

Re: [svn:parrot-pdd] r24108 - in trunk: . docs/pdds

2007-12-20 Thread Jonathan Worthington
Klaas-Jan Stol wrote: looks good as far as I can tell. W.r.t. the selection part, the "don't care" type is missing, which is "_" IIRC. My guess is that if you can specify which parameters are invocants, with :invocant, then the need for an "any" type goes away, since you just don't mark the

Re: breakdown of tasks for PMC PDD implementation

2007-12-20 Thread Klaas-Jan Stol
On Dec 19, 2007 11:30 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > Next month's development milestone is the implementation of the new PMC > spec. This milestone involves many small tasks, which can be divided up > pretty easily between a handful of people. Now that Jonathan's shipped > the rel

Re: [svn:parrot-pdd] r24108 - in trunk: . docs/pdds

2007-12-20 Thread Klaas-Jan Stol
I guess you're right :-) I was thinking of ambiguity, like .sub foo :multi(Integer, Integer) .param pmc i :invocant .param pmc j .param pmc k :invocant .end .sub foo :multi (Integer, Integer) .param pmc j :invocant .param pmc k :invocant .end but I guess parrot will see that the other foo h

Re: Concerns about "{...code...}"

2007-12-20 Thread Adriano Ferreira
On Dec 20, 2007 1:48 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > I was reading an article about Perl 6, I forget which one, and it happened to > mention that code can be interpolated inside double quoted strings. That's > one thing, my concern is with the selected syntax. > > say "f

Re: Concerns about "{...code...}"

2007-12-20 Thread Mark J. Reed
I think the issue is that bare vars don't interpolate anymore, but they still have sigils of their own, so adding to the default interp syntax is too noisy: ${$var} is not really much improvement over ${\(expr)}. - Original message - I am not quite sure of all the implications in t... On 12/20/

Re: Test failures on Solaris 9

2007-12-20 Thread Paul Cochrane
On 20/12/2007, James E Keenan <[EMAIL PROTECTED]> wrote: > Paul Cochrane wrote: > > Hi everyone, > > > > these failures probably aren't critical for release, however I thought > > it best to mention them. > > > > Paul > > > > System: Solaris 9 > > cc: Sun C 5.8 2005/10/13 > > Parrot revision: 24033

Re: [PATCH] fix for pcre test if libpcre installed in non-standard location

2007-12-20 Thread Mark J. Reed
That output suggests that you dont have libpcre installed, which makes it not much of a test for the patch. :) On 12/19/07, James Keenan via RT <[EMAIL PROTECTED]> wrote: > On Mon Dec 03 20:04:08 2007, [EMAIL PROTECTED] wrote: > > Uploading updated version of patch based on discussion with chroma

Re: [perl #48631] [RFE] oo - allow :method to also enter sub in namespace

2007-12-20 Thread Patrick R. Michaud
On Thu, Dec 20, 2007 at 09:20:22AM +0200, Allison Randal wrote: > Patrick R. Michaud wrote: > > > >Of course, in the previous object model I think there was only > >one place to look, and find_method did the searching. > > In the previous model, there was no distinction between subroutines and >

Re: [PATCH] fix for pcre test if libpcre installed in non-standard location

2007-12-20 Thread Devin Heitmueller
Mark is correct. If the pcre-config program cannot be found, then this is the condition you should expect. Note that libpcre does not come with OSX, so this is not unusual (I have it installed via Fink). Devin On Dec 20, 2007 8:48 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote: > That output sugges

Proposal: refactor the test suite according to synopsis

2007-12-20 Thread Patrick R. Michaud
Since the perl6 compiler on Parrot is moving ahead nicely in its new incarnation, it's time for us to start looking at the official test suite again. As a reminder, Pugs is considered the repository for the "official test suite" at the moment ( http://svn.pugscode.org/pugs/t/ ). Having looked at

Re: Concerns about "{...code...}"

2007-12-20 Thread Jonathan Scott Duff
On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote: > I think the issue is that bare vars don't interpolate anymore, but > they still have sigils of their own, so adding to the default interp > syntax is too noisy: ${$var} is not really much improvement over > ${\(expr)}. That's not qui

Re: Concerns about "{...code...}"

2007-12-20 Thread Jonathan Scott Duff
On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote: > Adriano answered #1 I think: $yaml = Q:!c"{ $key: 42 }"; Er, I just looked over the spec again and realized that Q does absolutely no interpolation, so it would be more like this: $yaml = Q:qq:!c"{ $key: 42 }"; or perhap

Re: Proposal: refactor the test suite according to synopsis

2007-12-20 Thread Larry Wall
On Thu, Dec 20, 2007 at 11:27:14AM -0600, Patrick R. Michaud wrote: : I'm thinking of this organization scheme as primarily a guiding : principle and not something to be strictly applied. For example, : I wouldn't advocate a strict one-to-one correspondence between : subdirectories and major headi

Re: Proposal: refactor the test suite according to synopsis

2007-12-20 Thread jerry gay
On Dec 20, 2007 9:27 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > There are certainly plenty of organization schemes we could use > for this, but one that leaps to my mind is to organize tests based > loosely on where the feature is described in the synopses or the > camel book (the p5 camel

Re: Concerns about "{...code...}"

2007-12-20 Thread Dave Mitchell
On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote: > On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote: > > Adriano answered #1 I think: $yaml = Q:!c"{ $key: 42 }"; > > Er, I just looked over the spec again and realized that Q does > absolutely no interpolation

Re: Concerns about "{...code...}"

2007-12-20 Thread Patrick R. Michaud
On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote: > On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote: > > Adriano answered #1 I think: $yaml = Q:!c"{ $key: 42 }"; > > Er, I just looked over the spec again and realized that Q does > absolutely no interpolation

[perl #48735] [DEPRECATED] :: in PIR identifiers

2007-12-20 Thread Klaas-Jan Stol via RT
On Sun Dec 16 21:11:34 2007, coke wrote: > From PDD 19: > > NOTE: The use of C<::> in identifiers is deprecated. > what exactly does this mean? I take it that "::" can still appear in typenames, as in "PAST::Op", but not, for instance like so: .local int some::var Is that it?

Re: Concerns about "{...code...}"

2007-12-20 Thread Michael G Schwern
Patrick R. Michaud wrote: > Just to add another perspective, PHP uses curlies inside of > double-quoted strings to indicate various forms of > interpolation, and it doesn't seem to cause major issues > there. PHP has 8000 built in functions and it doesn't seem to cause issues there. I'll not be t

Re: Concerns about "{...code...}"

2007-12-20 Thread Mark J. Reed
On Dec 20, 2007 4:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > Just to add another perspective, PHP uses curlies inside of > double-quoted strings to indicate various forms of > interpolation, and it doesn't seem to cause major issues > there. But PHP's use of curlies is limited and co

Re: Concerns about "{...code...}"

2007-12-20 Thread Mark J. Reed
No need to get snippy. PHP may be the best argument out there for namespace control, but that doesnt mean it doesnt also have some nice bits. Im rather fond of its extended foreach syntax, for instance. (Though I disagree with the conflation of numeric and associative arrays, a flaw shared by Jav

Re: Concerns about "{...code...}"

2007-12-20 Thread Michael G Schwern
Jonathan Scott Duff wrote: > On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote: >> I think the issue is that bare vars don't interpolate anymore, but >> they still have sigils of their own, so adding to the default interp >> syntax is too noisy: ${$var} is not really much improvement ov

Re: Concerns about "{...code...}"

2007-12-20 Thread Patrick R. Michaud
On Thu, Dec 20, 2007 at 06:01:53PM -0500, Mark J. Reed wrote: >On Dec 20, 2007 4:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > Just to add another perspective, PHP uses curlies inside of > double-quoted strings to indicate various forms of > interpolation, and it does

Re: [perl #48735] [DEPRECATED] :: in PIR identifiers

2007-12-20 Thread Will Coleda
-- Will "Coke" Coleda On Dec 20, 2007, at 12:49 PM, "Klaas-Jan Stol via RT" <[EMAIL PROTECTED] > wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C<::> in identifiers is deprecated. what exactly does this mean? I take it that "::" can still appear in type

Re: Concerns about "{...code...}"

2007-12-20 Thread Mark J. Reed
Since i was mistaken about bare vars (scalars still interpolate), I agree with Mr. Schwern: plain curlies are insufficiently distinct for the interpolation syntax. Sigil+curlies would be better. On 12/20/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Thu, Dec 20, 2007 at 06:01:53PM -0500

Re: Concerns about "{...code...}"

2007-12-20 Thread Michael G Schwern
Mark J. Reed wrote: > No need to get snippy. I thought the "I'm just fucking around" emotey would be enough. > PHP may be the best argument out there for > namespace control, but that doesnt mean it doesnt also have some nice > bits. Im rather fond of its extended foreach syntax, for instance.

[perl #48633] [PATCH] config/inter/progs.pm refactored to make it more testable

2007-12-20 Thread James Keenan via RT
No complaints; resolving ticket.

[perl #48074] [PATCH] fix for pcre test if libpcre installed in non-standard location

2007-12-20 Thread James Keenan via RT
Patch applied to trunk in r24118. Devin Heitmueller++ for his first contribution to Parrot! kid51

[perl #48965] [BUG] t/compilers/json/to_parrot.t test failure

2007-12-20 Thread via RT
# New Ticket Created by James Keenan # Please include the string: [perl #48965] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48965 > Running 'make test' tonight on Linux (configuration run by Perl 5.10), I got the follo

Re: [perl #48965] [BUG] t/compilers/json/to_parrot.t test failure

2007-12-20 Thread jerry gay
On Dec 20, 2007 7:22 PM, via RT James Keenan <[EMAIL PROTECTED]> wrote: > # New Ticket Created by James Keenan > # Please include the string: [perl #48965] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=48965 > > > > Runnin

[perl #48965] [BUG] t/compilers/json/to_parrot.t test failure

2007-12-20 Thread James Keenan via RT
On Thu Dec 20 19:35:39 2007, particle wrote: > On Dec 20, 2007 7:22 PM, via RT James Keenan > <[EMAIL PROTECTED]> wrote: > > > > This test was passing 24 hours earlier, so I suspect some change > > since r24106. > > > 24 hours earlier, you didn't have perl 5.10. could you try with an > earlier ver

[perl #48971] Parrot build failure "no such instruction: `trap'"

2007-12-20 Thread via RT
# New Ticket Created by Walter M Szeliga # Please include the string: [perl #48971] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48971 > On a PPC with OSX 10.5.1 Parrot revision number r24118 Running perl Configure.pl ma