[svn:parrot-pdd] r34694 - in trunk: docs/pdds languages/perl6/src/builtins

Author: bernhard Date: Wed Dec 31 01:53:48 2008 New Revision: 34694 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/languages/perl6/src/builtins/control.pir Log: [codingstd] Satisfy trailing_space.t and pdd_format.t Modified: tr

[svn:parrot-pdd] r34697 - in trunk: docs/pdds src/pmc

Author: bernhard Date: Wed Dec 31 03:56:58 2008 New Revision: 34697 Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod Changes in other areas also in this revision: Modified: trunk/src/pmc/class.pmc Log: Some tidbits: speling, code alignment, add code comments Modified: trunk/docs/pdd

Re: [perl #61860] Printing a variable from inside an eval yields Null PMC Access in Rakudo

On Tue, Dec 30, 2008 at 01:04:58PM -0800, Carl Mäsak wrote: > > rakudo: my $a = 5; eval 'say $a' > rakudo 34665: RESULT«Null PMC access in find_method() [...] > * masak submits rakudobug At the moment eval strings are unable to access their outer lexical environment -- fixing this will involve

Bug or feature? Hash autovivification

Just stumbled across this, but I can't tell from S09 if this is a bug or feature: $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl' {"a" => undef} I wasn't expecting auto-vivification there. The examples in S09 use HoH instead of a flat hash: But these bindings do autovivify:

Hangman in Perl 6

I wrote a hangman game in Perl 6. Suggestions are very welcome. Some issues with it are from things I don't understand. Others are due to bugs or limitations in Rakudo. http://use.perl.org/~Ovid/journal/38191 All in all, I'm quite pleased with how things are coming along. Cheers, Ovid -

[perl #61874] [PATCH] Fixed typos in docs

# New Ticket Created by Saleem A. Ansari # Please include the string: [perl #61874] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=61874 > Fixed typos in docs/book ch08_architecture.pod | 11 +-- ch09_pct.pod

Re: Bug or feature? Hash autovivification

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote: : Just stumbled across this, but I can't tell from S09 if this is a bug or feature: : : $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl' : {"a" => undef} Definitely bug. Rvalues aren't supposed to autovivify. Larry

[perl #61868] say eval ""

# New Ticket Created by Simon Cozens # Please include the string: [perl #61868] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=61868 > This causes a null access in PMC, presumably because the eval is returning the wrong kin

Re: Ticket #105 (NULL checks)

On Wed, Dec 31, 2008 at 09:22:01AM -0800, Mark Glines wrote: > kjstol wrote: > > > > > > On Wed, Dec 31, 2008 at 5:03 PM, Mark Glines > > wrote: > > > > Andy Dougherty wrote: > > > One trap: If the gcc attribute_nonnull is still used for these same > > > f

r24707 - docs/Perl6/Spec

Author: particle Date: 2008-12-31 19:50:40 +0100 (Wed, 31 Dec 2008) New Revision: 24707 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] fix typo, s1n++ Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec

r24708 - docs/Perl6/Spec

Author: particle Date: 2008-12-31 19:53:43 +0100 (Wed, 31 Dec 2008) New Revision: 24708 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] metasyntactic options should shout, to stand out. TimToady++ Modified: docs/Perl6/Spec/S19-commandline.pod ==

r24711 - docs/Perl6/Spec

Author: particle Date: 2008-12-31 20:37:46 +0100 (Wed, 31 Dec 2008) New Revision: 24711 Modified: docs/Perl6/Spec/S06-routines.pod Log: [S06] update to shortname syntax in command-line examples Modified: docs/Perl6/Spec/S06-routines.pod =

r24712 - docs/Perl6/Spec

Author: particle Date: 2008-12-31 20:39:19 +0100 (Wed, 31 Dec 2008) New Revision: 24712 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] update C<--CHECK{...}> syntax with more standard C<-e 'CHECK{...}'> Modified: docs/Perl6/Spec/S19-commandline.pod ===

r24714 - docs/Perl6/Spec

Author: particle Date: 2008-12-31 21:16:50 +0100 (Wed, 31 Dec 2008) New Revision: 24714 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] s/bundl/cluster/g; update date/version Modified: docs/Perl6/Spec/S19-commandline.pod

Re: Ticket #105 (NULL checks)

On Wednesday 31 December 2008 12:26:07 Andy Dougherty wrote: > This is not a hypothetical what-if situation.  I have lost many hours to > just this situation.  See my long example in ticket RT #50684.  To save > everyone from looking it up, I will extract the relevant example here: Your copy and

Re: Ticket #105 (NULL checks)

On Wed, 31 Dec 2008, chromatic wrote: > On Wednesday 31 December 2008 12:26:07 Andy Dougherty wrote: > > > This is not a hypothetical what-if situation.  I have lost many hours to > > just this situation.  See my long example in ticket RT #50684.  To save > > everyone from looking it up, I will e

Re: Ticket #105 (NULL checks)

On Dec 31, 2008, at 3:50 PM, Andy Dougherty wrote: We can solve it by getting rid of the attribute_nonnull decorations and replacing them with assert()s. An even better solution is to keep the attribute_nonnull and also add asserts. The ARGIN()/ARGOUT() decorators are useful both to GCC