Re: [perl #60456] Str ~~ Grammar do not return Match object, but return strange hash

[Patrick R. Michaud]

On Mon, Nov 10, 2008 at 03:21:47AM -0800, Ilya Belikin wrote:
> 
> grammar G {
> token TOP { ':' + };
> token foo { \d };
> }
> 
> my $a = ":123" ~~ G::TOP;

The official syntax for matching against a rule or grammar
has not yet been determined.  So, I'm marking this ticket
as "stalled" until we have that.

In the meantime, I suggest:

my $a = G::TOP(":123");

Pm

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

[pmichaud]

Author: pmichaud
Date: Tue Nov 11 10:54:28 2008
New Revision: 14605

Modified:
   doc/trunk/design/syn/S03.pod

Log:
Fix a misnamed reference.


Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Nov 11 10:54:28 2008
@@ -1433,7 +1433,7 @@
 
 += -= **= xx= .= etc.
 
-See L.
+See L.
 
 =back
 

Re: [perl #58602] subset types and multi dispatch don't mix

[chromatic]

On Sunday 14 September 2008 12:48:07 Moritz Lenz wrote:

> Currently (r31122) the example dies with "Ambiguous dispatch.".
>
> (On a related note, could we get more verbose error messages? "Ambiguous
> dispatch for { sub | method } $name" would be more helpful.)

Added in r32552.

-- c

[perl #60474] Configure.pl doesn't properly detect osname

[via RT]

# New Ticket Created by  Mike Kelly 
# Please include the string:  [perl #60474]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=60474 >


---
osname= linux
osvers= 2.6.27-7-generic
arch=   x86_64
cc= cc
---
Flags:
category=core
severity=low
ack=no
---
Test 4 of t/op/sysinfo.t fails for me.

To configure, I just ran: perl ./Configure.pl. However, parrot seems to
detect my osname as 'x86_64' (my processor), rather than as 'linux'.

$ prove t/op/sysinfo.t
t/op/sysinfoNOK 4
#   Failed test 'sysinfo osname'
#   in t/op/sysinfo.t at line 74.
#  got: 'linux'
# expected: 'x86_64'

Perl (v5.8.8), though, sees my os as linux:

$ perl -MConfig -e 'print "$Config{osname}\n"'
linux

For the sake of completeness:

$ uname -a
Linux aether 2.6.27.4 #2 SMP Mon Nov 3 21:02:47 EST 2008 x86_64 GNU/Linux

Sorry, I don't have a patch yet, I'm still figuring out how Configure.pl
works.


---
Summary of my parrot 0.8.0 (r32447) configuration:
  configdate='Sat Nov  8 12:20:31 2008 GMT'
  Platform:
osname=x86_64, archname=x86_64
jitcapable=0, jitarchname=nojit,
jitosname=x86_64, jitcpuarch=
execcapable=0
perl=/usr/bin/perl5.8.8
  Compiler:
cc='cc', ccflags=' -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST  
-DHASATTRIBUTE_DEPRECATED  -DHASATTRIBUTE_MALLOC  -DHASATTRIBUTE_NONNULL  
-DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE  -DHASATTRIBUTE_UNUSED  
-DHASATTRIBUTE_WARN_UNUSED_RESULT  -falign-functions=16 -fvisibility=hidden 
-maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual 
-Wchar-subscripts -Wcomment -Wendif-labels -Wextra -Wformat -Wformat-extra-args 
-Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport 
-Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmissing-braces 
-Wmissing-field-initializers -Wno-missing-format-attribute 
-Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type 
-Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing 
-Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef 
-Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-func
 tion-cast -Wc++-compat -Wdeclaration-after-statement 
-Werror=declaration-after-statement -Wimplicit-function-declaration 
-Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes 
-Wnested-externs -Wnonnull -DHAS_GETTEXT',
  Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib64',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline 
-lncurses -lpcre -lcrypto '
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib64 -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib64 -fPIC'
  Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=1 byteorder=12345678, 
nv=double, numvalsize=8, doublesize=8

---
Environment:
HOME =/home/pioto
LANG =en_US.utf8
LANGUAGE  (unset)
LD_LIBRARY_PATH  (unset)
LOGDIR  (unset)
PATH 
=/home/pioto/bin:/sbin:/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/bin:/opt/bin
SHELL =/bin/bash

[perl #57990] Implement prefix:<\> operator

[Chris Dolan via RT]

On Sat Aug 16 07:30:22 2008, [EMAIL PROTECTED] wrote:
> - Need some clarity in spec and spectests for Capture objects

Perhaps more clarity is needed, but the basics seems to work.  I propose
this ticket should be closed.

[perl #60358] Rakudo doesn't recognize grammars with :: in the name

[[EMAIL PROTECTED] via RT]

On Wed Nov 05 19:31:36 2008, chrisdolan wrote:
> It took a while to understand the code, but the solution was a
> one-liner.  Patch attached.
Unfortunately, the patch produced a bunch of spectest failures. However,
it wasn't because the patch was wrong, but rather a bug in some code
generation in PCT. I fixed that, and then the patch worked and did the
Right Thing, so it's applied in r32546. Plus got us spectesting this.

Thanks!

Jonathan

[perl #57980] Fix bugs with nested ?? !!

[Chris Dolan via RT]

On Sat Aug 16 07:29:36 2008, [EMAIL PROTECTED] wrote:
> - Awaiting parser improvements (PGE)

A simple, failing test:

say True ?? 1 !! False ?? 2 !! 3;

(says 2, should say 1)

[perl #60456] Str ~~ Grammar do not return Match object, but return strange hash

[via RT]

# New Ticket Created by  Ilya Belikin 
# Please include the string:  [perl #60456]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=60456 >


grammar G {
token TOP { ':' + };
token foo { \d };
}

my $a = ":123" ~~ G::TOP;
say +$/; # 0 But match success. :(
say +$a; # 1

say $/.WHAT; # Match
say $a.WHAT; # Hash (!?)

# Hash, hmmm. I expect Match object.

say $/.perl; # {"foo" => [{}, {}, {}]}
say $a.perl; # {"foo" => [{}, {}, {}]}

# Strange hash

say $/.WHAT; # List
say $a.WHAT; # List

[perl #58602] subset types and multi dispatch don't mix

[[EMAIL PROTECTED] via RT]

On Fri Sep 05 08:26:34 2008, [EMAIL PROTECTED] wrote:
> Rakudo r30787 dies on multi dispatch when subset types are involved:
> 
> test file:
> 
> subset Even of Int where { $_ % 2 == 0 };
> subset Odd  of Int where { $_ % 2 == 1 };
> 
> multi sub test_subtypes(Even $y){ 'Even' }
> multi sub test_subtypes(Odd  $y){ 'Odd'  }
> say test_subtypes(3)
> 
> dies with
> No applicable methods.
> 
I just checked this after further fixes to Perl6MultiSub and am happy to
say that as of r32528 this now works (whether that's the revision it
started working in, I'm not sure - but it does the Right Thing.)

Thanks!

Jonathan

[perl #58388] [BUG] Num typecheck doesn't accept integers

[[EMAIL PROTECTED] via RT]

On Wed Aug 27 02:29:23 2008, stifynsemons wrote:
> my Num $x = 3;
> causes a typecheck failure, whereas:
> 
Fixed in r32528.

Thanks,

Jonathan

[perl #57400] Working with %*ENV in Rakudo is difficult

[Patrick R. Michaud via RT]

On Thu Oct 16 06:31:14 2008, masak wrote:
> Here's a thorough investigation of the strange properties of %*ENV.

Here's an explanation -- I'll start with the summary first and then look
at the examples.

> In summary:
> 
> 1. Ordinary strings and strings in %*ENV are unequally treated. You
can call
> .trans(), or .trans([]) on the former, but you have to send in two non-
> invocant arguments to the latter.

Rakudo's %*ENV is simply an instance of Parrot's Env PMC.  Whenever we
fetch something from the Env PMC, we get back a String PMC.  This isn't
a full Rakudo Str object, though, so their behaviors are a bit latter.

In particular, Parrot's String PMC already has a .trans method defined
on it, so Rakudo's .trans method for Str doesn't override it.

> 2. The result of a successful .trans call on an %*ENV item returns
something
> which, when touched in any way, causes Rakudo to explode.

The .trans method on String PMC doesn't return a value at all -- it does
an inplace modification.  So, the return value is garbage that indeed
causes Parrot to go boom.

> 3. Actively modifying the %*ENV item using .=trans produces a Null PMC
> access
> in another Parrot sub, and doing this from within a subroutine, produces
> a Null
> PMC acces in yet another Parrot sub.

Since %*ENV returns a Parrot String PMC, and since the .trans method on
the String PMC returns garbage, the inplace modifier ends up trying to
store garbage back into the String PMC.

> 4. Setting an %*ENV item using infix:<=> has no effect. Setting it using
> infix:<:=> works. 

The values that come back from %*ENV are String PMCs that aren't tied to
the environment at all, thus assigning to those PMCs has no effect.

However, binding an item using <:=> does activate the set_*_keyed VTABLE
of the underlying Env PMC, so that does work.

> Setting %*ENV itself using infix:<=> produces a Parrot VM
> error.

The Env PMC is a singleton PMC that doesn't understand assignment. 
We'll need to map this somehow so that it understands how to rebuild
itself from a list or hash. 

> Setting it using infix:<:=> works. 

You can rebind %*ENV to a different hash, but then it loses its magical
Env properties.  (This may also end up being the case for infix:<=> above.)

> Assigning %*ENV to another
> variable
> using infix:<=> produces another Parrot VM error.

The Parrot Env PMC is a singleton PMC, so apparently there's not a way
to clone or copy it.  This will probably be fixed via ObjectRefs, if
it's not fixed already.

> 5. When calling the methods .keys, .values, .kv or .perl on %*ENV,
something
> fails with "No applicable methods". 

Since %*ENV (and the Env PMC) is not really a Hash or Mapping, none of
those methods yet apply.  This is probably fixable if we map the Env PMC
onto Rakudo's Mapping class.


So, with those points out of the way, here are the explanations of the
examples:


> say %*ENV.WHAT;
> # Str

%*ENV actually returns a Parrot String PMC, which we've mapped onto
the Rakudo Str type, so it reports 'Str' as its type (even though it isn't).

> say %*ENV.trans();
> # too few arguments passed (1) - 3 params expected

Since the String PMC has its own .trans method, the Str.trans method
doesn't get invoked (and the signatures are different).


> say %*ENV.trans( [], [] );
> # Null PMC access in get_string()
> say %*ENV.trans( [], [] ).WHAT;
> # Null PMC access in find_method()

This invocation matches the signature for String.trans (not Str.trans),
but that .trans is an inplace modification that returns PMCNULL.

> 
> %*ENV .= trans([ "A" => "B" ], [])'
> # Null PMC access in name()

This ends up calling %*ENV.trans( ... ), which returns PMCNULL and
cannot be assigned back to %*ENV.

> %*ENV = "OH HAI"; say %*ENV.perl
> # ""
> %*ENV := "OH HAI"; say %*ENV.perl
> # "OH HAI"

Assignment doesn't work, but binding does.



Hope this helps -- I'll see which of the above I can clean up.

Pm

[perl #59484] [TODO] Implement $?PACKAGE in Rakudo

[[EMAIL PROTECTED] via RT]

On Tue Sep 30 06:04:03 2008, masak wrote:
> ...as described in S02:
> 
>  
> 
> Package declarations are not implemented yet, but even without them,
> $?PACKAGE could be useful in the following case:
> 
> class A { say "This is class $?PACKAGE" }
> 
Implemented in r32567; for the example you give here we now get the
output "This is class A". Note that of you've got a reference to the
namespace, not the proto-object, which is what you'll be able to get
(IIUC) when $?CLASS is done.

Jonathan

flagging compiler-generated code

[Chris Dolan]

I'm thinking ahead to the Parrot equivalent of Perl::Critic, which I  
hope will someday be able to analyze arbitrary .pbc files.  One  
problem I foresee is that there seems to be no way to distinguish  
anonymous subs ("my $f = sub { 1 };") from inner blocks.  Both  
compile down to something like this:

  .sub "_block16" :anon :lexid("23") :outer("21")

Would it be feasible to add a new PIR adverb to mark anonymous  
methods invented by the compiler so we can easily tell them apart  
from anonymous methods invented by the programmer?  In Java, the  
former get isSynthetic=true, which makes it easier to suppress  
complaints about code violations in code out of the programmer's  
control.


Chris