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:
>
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
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
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.
I just built Pugs fresh from SVN on four different platforms (Win32,
Solaris, OS X Panther, and OS X Tiger) and noticed these things
cons
On Tue, Apr 05, 2005 at 10:33:00AM -0700, Larry Wall wrote:
> : Aye. Is there an idea on how the two forms of `if` would be defined
> : using plain Perl 6?
>
> That's exactly what the syntactic category syntax is for, and why
> parsing has to be done indirectly in terms of syntactic categories,
>
On Wed, Apr 06, 2005 at 12:32:37AM +0800, Autrijus Tang wrote:
: On Tue, Apr 05, 2005 at 08:24:42AM -0700, Larry Wall wrote:
: > That's why there's a statement_control:, and there's a
: > statement_modifer:, but there's no prefix:. If you see
: > a statement modifier in the middle of an expression
On Tue, Apr 05, 2005 at 08:24:42AM -0700, Larry Wall wrote:
> That's why there's a statement_control:, and there's a
> statement_modifer:, but there's no prefix:. If you see
> a statement modifier in the middle of an expression, it must be
> interpreted as a statement modifier regardless of the co
On Tue, Apr 05, 2005 at 09:22:29PM +0800, Autrijus Tang wrote:
: On Mon, Apr 04, 2005 at 09:01:20PM -0400, Stevan Little wrote:
: > eval 'sub foobar { return if 1; }';
:
: I've fixed everything except this. I'm not exactly sure how the postfix
: form of "if" is supposed to work here, because the
On Mon, Apr 04, 2005 at 09:01:20PM -0400, Stevan Little wrote:
> eval 'sub foobar { return if 1; }';
I've fixed everything except this. I'm not exactly sure how the postfix
form of "if" is supposed to work here, because the first thing the
parser tries is to parse it as return(if(1)), as a valid
Got another one!
This one is your basic parsing error, and hopefully easily fixed.
Basically the return statement will not work without a value to return,
unless you have a () after it (which I assume is not "correct" syntax,
but also not really "wrong" syntax (but I will leave that for the
lan
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
Hello all,
I found another bug, this one to do with single quoted stings.
Basically, pugs does not seem to correctly parse the single quoted
string 'test\'
See t/pugsbugs/string_escaping.t for a test.
- Stevan
Autrijus,
I un-TODO-ed the tests, and built you a TODO list of what I saw as
outstanding issues. I did my best to differentiate between bugs in the
implementation and un-implemented features.
Enjoy ;)
- Stevan
t/builtins/
- die.t
The stringified version of $! is printing Haskell type information
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
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
array ref problem. I will try and flesh out the hash-ref tests in the
s
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
>
Autrijus & Co.
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
t/op/unshift.t
Note that these issues may not be related t
27 matches
Mail list logo
