Joshua Isom wrote:
[snip
Oh, and I do have gmake installed, I just don't use it.
If you have gmake installed, then shouldn't
$conf->data->get('gmake_version') return a true value?
>>
>> if ( $conf->data->get('gmake_version') ) {
>> $conf->data->set( make_c => "$prog -C" );
On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
> The following program works fine in pugs r17041 (which is the rev of
> /usr/bin/pugs on feather):
>
> my $r=\{say $x+1};
> my $x=2;
> $r();
>
> With r17041, this gives 3;
> However, on the latest pugs (r17615 or later), it gives an error:
>
On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
>
> On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
> > The following program works fine in pugs r17041 (which is the rev of
> > /usr/bin/pugs on feather):
> >
> > my $r=\{say $x+1};
> > my $x=2;
> > $r();
> >
> > With r17041, this gives
The following program works fine in pugs r17041 (which is the rev of
/usr/bin/pugs on feather):
my $r=\{say $x+1};
my $x=2;
$r();
With r17041, this gives 3;
However, on the latest pugs (r17615 or later), it gives an error:
***
Unexpected "$r"
expecting "=", "::", context, ":" or "("
V
Wim (>):
> I think it could be a GHC bug: I rebuilt r17041 with ghc-6.6.1 (just a few
> changes to use the new filepath package in Pugs.hs and Pugs/Run.hs) and it
> shows the bug. I assume the pugs on feather really is r17041, to be really
> sure I should build r17041 with ghc-6.6. I should manage
i've just given ron blaschke (aka ron or rblasch) a commit bit. please
join me in welcoming him to the core committers. over the last few
years, ron has submitted many high-quality patches, and has always
been willing to share his knowledge of windows-based programming.
ron has told me privately t
In a message dated Fri, 7 Sep 2007, Wim Vanderbauwhede writes:
On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
Even
if strict weren't in effect this code should not work since the $x in
the closure is not the one created after the closure:
perl -le 'my$r=sub{print $x+1};my $x = 2;$r->()'
I think it could be a GHC bug: I rebuilt r17041 with ghc-6.6.1 (just a few
changes to use the new filepath package in Pugs.hs and Pugs/Run.hs) and it
shows the bug. I assume the pugs on feather really is r17041, to be really
sure I should build r17041 with ghc-6.6. I should manage that next week.
[EMAIL PROTECTED] writes:
> -A leading C<[> or C<+> indicates an enumerated character class. Ranges
> +A leading C<[> indicates an enumerated character class. Ranges
> in enumerated character classes are indicated with "C<..>" rather than
> "C<->".
>
> / <[a..z_]>* /
> - / <+[a..z_
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #45249]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45249 >
Chromatic is already aware of this issue, but I thought I'd
file a ticket for it t
Wim (>):
> The following program works fine in pugs r17041 (which is the rev of
> /usr/bin/pugs on feather):
>
> my $r=\{say $x+1};
> my $x=2;
> $r();
>
> With r17041, this gives 3;
> However, on the latest pugs (r17615 or later), it gives an error:
> ***
> Unexpected "$r"
> expecting "=",
On Fri, Sep 07, 2007 at 03:00:36PM +0100, Wim Vanderbauwhede wrote:
: On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
: >
: > On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
: > > The following program works fine in pugs r17041 (which is the rev of
: > > /usr/bin/pugs on feather):
: >
On Thu, Sep 06, 2007 at 05:12:03PM -0700, [EMAIL PROTECTED] wrote:
> Log:
> old is now <+foo> to suppress capture
> new now is zero-width like
I really like the change from to <+foo>, but I think there's
a conflict (or at least some confusion) in the way the new spec is
worded, especially as i
Some other minor notes about the S05.pod update:
> +In particular, also matches the null string, and always fails.
Perhaps these should be quoted with "C<< ... >>" so that it's
clear that "" and "" are the tokens? When looking at the
.pod file I had to think about it a couple of times to make
On Sep 7, 2007, at 7:19 AM, James E Keenan wrote:
If you have gmake installed, then shouldn't
$conf->data->get('gmake_version') return a true value?
>>
>> if ( $conf->data->get('gmake_version') ) {
>> $conf->data->set( make_c => "$prog -C" );
>> }
>> else {
If so, how wou
On Friday 07 September 2007 09:32:51 Patrick R.Michaud wrote:
> Chromatic is already aware of this issue, but I thought I'd
> file a ticket for it that others can hang information on.
>
> Starting with r21103, Parrot won't build on my 64-bit platform.
> It starts through the normal configure and m
On Thu, 6 Sep 2007, James Keenan via RT wrote:
> Only someone completely lacking a gmake would reach the 'else' block,
> and only such a person would be in a position to write a test for
> anything that would replace \$\(MAKE\).
>
> Can anyone do that? Otherwise, I will mark the ticket as STALLE
On Fri, Sep 07, 2007 at 02:45:52AM -0500, Patrick R. Michaud wrote:
: On Thu, Sep 06, 2007 at 05:12:03PM -0700, [EMAIL PROTECTED] wrote:
: > Log:
: > old is now <+foo> to suppress capture
: > new now is zero-width like
:
: I really like the change from to <+foo>, but I think there's
: a confli
> Other available chars:
>
> <`ws>
> <^ws>
> <&ws>
> <*ws>
> <-ws>
> <|ws>
> <:ws>
> <;ws>
>
I'd vote for <:ws> which is vaguely reminiscent of the former non-capturing
parens (?:).
It (<:ws>) also bears little similarity to any other regex construct -
altho
On Fri, Sep 07, 2007 at 04:05:55PM -0600, Paul Seamons wrote:
: > Other available chars:
: >
: > <`ws>
: > <^ws>
: > <&ws>
: > <*ws>
: > <-ws>
I forgot we're using - already, so scratch that one...
: > <|ws>
: > <:ws>
: > <;ws>
: >
:
: I'd vote for <:ws> whic
Patrick R . Michaud wrote:
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #45249]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45249 >
Chromatic is already aware of this issue, but I thoug
No objections were heard, so I committed these 4 new test files to trunk
in r21126.
On Fri, Sep 07, 2007 at 03:50:09PM -0700, Larry Wall wrote:
> The first list is the ones I'm really considering, and of those, <.ws>
> is the easiest to type and gets out of the way of identifier visually.
> It also looks like a method call, which in fact it is. <~ws> is hard
> to type, and <\ws>
On Sat, Sep 08, 2007 at 12:12:10AM +0100, Nicholas Clark wrote:
: On Fri, Sep 07, 2007 at 03:50:09PM -0700, Larry Wall wrote:
: > I dunno, maybe <\ws> isn't so bad...
:
: But as soon as I saw it I thought the same as you say in the paragraph above -
: in the context of a regexp (or string) \ makes
On Fri, Sep 07, 2007, Larry Wall writes:
> If we stick with +, one approach might be to simply disallow whitespace
> in composite character classes.
Of the choices presented thus far, I like this one the best.
Although I did like being able to stick whitespace in the
character classes for readabil
On Fri, Sep 07, 2007 at 04:05:55PM -0600, Paul Seamons wrote:
> I'd vote for <:ws> which is vaguely reminiscent of the former non-capturing
> parens (?:).
>
> It (<:ws>) also bears little similarity to any other regex construct -
> although it looks a bit like a Perl 6 pair.
For completeness it
Patches committed to trunk in r21127.
Patches applied in r21127.
Please review the patch attached, which contributes 5 files for the
purpose of testing configuration step inter::yacc. The patch also makes
some modifications to config/inter/yacc.pm along the same lines as
revisions proposed yesterday for config/inter/lex.pm and for the same
purpose: to increase
On Sep 7, 2007, at 3:02 PM, chromatic wrote:
On Friday 07 September 2007 09:32:51 Patrick R.Michaud wrote:
Chromatic is already aware of this issue, but I thought I'd
file a ticket for it that others can hang information on.
Starting with r21103, Parrot won't build on my 64-bit platform.
It
30 matches
Mail list logo
