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):
: >
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->()'
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 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.
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 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
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 8/24/06, Larry Wall <[EMAIL PROTECTED]> wrote:
The pugs idea of reality is that a bug doesn't exist unless there's a
test failing for it. And the correct way to report a bug is to write
a test for it and check it in. :)
Fair enough. I'll work on decoding the test env.
It's purposefully
On Thu, Aug 24, 2006 at 02:29:04PM -0400, Mark J. Reed wrote:
: Is there a repository of current known bugs with pugs, like there is
: with Parrot? I'm just starting and don't want to point out things
: that are already known.
The pugs idea of reality is that a bug doesn't exist unless there's a
Larry,
Yes, I realized that my test was wrong. What I really wanted to test
for was this:
pugs -e "say 'foo\\'"
which gives the error:
unexpected end of input
expecting "\\'" or end of string
NonTerm SourcePos "-e" 1 12
Perl5 handles this correctly with:
pe
On Tue, Mar 22, 2005 at 05:32:04PM -0500, Stevan Little wrote:
: Basically, pugs does not seem to correctly parse the single quoted
: string 'test\'
That is not a single-quoted string. That's the beginning of a
single-quoted string. All parsing in Perl 6 is left-to-right, without
"lookaheads" f
On Tue, Mar 08, 2005 at 12:41:40PM +0100, Joost Diepenmaat wrote:
> +todo_is(eval(
> +'sub swap ([EMAIL PROTECTED] is rw) { @_[0,1] = @_[1,0]; }
> [EMAIL PROTECTED] = qw(1 2);
> +swap(@in);
> [EMAIL PROTECTED]'),
> +"2 1","swap");
Meh. That's wrong.
it shoud be:
todo_is(eval(
'sub swap ([EMA
On Mon, Mar 07, 2005 at 06:08:21PM -0500, Stevan Little wrote:
> Autrijus and Co.
>
> I have found another weird bug. It apprears to be a problem with the
> way the return statement handles Array refs and Hash refs in scalar
> context. I have some tests in t/op/sub_return_values.t which test the
On Sat, Mar 05, 2005 at 12:04:16AM +0800, Autrijus Tang wrote:
: The double evaluation bug has been fixed today. It was result of a
: misunderstanding of the role of $_ when the subroutine body does
: not mention $_, but makes use of slurpy arrays (as is the default with
: @*_), and has no invocan
On Wed, Mar 02, 2005 at 03:17:03PM -0500, Stevan Little wrote:
> I have managed to track down two different bugs/issues with PUGS. I
> explain them here in detail with examples, and todo_* tests for them
> are included in the following test files:
> t/op/shift.t
> t/op/pop.t
> t/op/push.t
>
15 matches
Mail list logo