[perl #75008] [BUG] Null PMC access on 'nextsame' in multi sub in Rakudo

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #75008]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=75008 >


 rakudo: multi foo() { nextsame }; foo()
 rakudo 3d3893: OUTPUT«Null PMC access in clone()␤current
instr.: '&nextsame' [...]
* masak submits rakudobug

[perl #75030] [PATCH] Lexical persistence & autoprinting for the REPL

[via RT]

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


> my $x = 10
10
> my $y = 1
1
> while $x { $y *= $x-- }
> $y
3628800
> [*] ^10
0
> [*] 1..10
3628800
> sub fac($n) { [*] 1..$n }
fac
> fac 10
3628800
> $*AUTOPRINT = 0
0
> fac(20)
> fac(20).say
2.43290200817664e+18

Internally, the YOU_ARE_HERE mechanism is generalized to allow continuing any
lexical scope.  Yes, this does mean that extremely long REPL sessions will take
linear space; I'm not too worried.
>From b9c4079ccc62711f9e29f2a8d9833da27d5b14d8 Mon Sep 17 00:00:00 2001
From: Stefan O'Rear 
Date: Tue, 4 May 2010 03:00:55 -0700
Subject: [PATCH] Lexical persistence and printing for the REPL

It works by reusing and generalizing the settings machinery; each line acts
as the setting for subsequent lines.  The setting is also used to initialize
the symbol table for compilations, so lexicals will be found.

$*AUTOPRINT, a compile time contextual, causes 'say' to be wrapped around
every expression statement.  It is disabled in blocks and all non-REPL
sources of code.  Autoprinting can be toggled in the REPL itself by
assigning to $*AUTOPRINT.
---
 src/Perl6/Actions.pm   |   73 
 src/Perl6/Compiler.pir |   43 
 src/Perl6/Grammar.pm   |2 +
 src/glue/run.pir   |   11 ++-
 4 files changed, 110 insertions(+), 19 deletions(-)

diff --git a/src/Perl6/Actions.pm b/src/Perl6/Actions.pm
index fca683c..a0115db 100644
--- a/src/Perl6/Actions.pm
+++ b/src/Perl6/Actions.pm
@@ -42,17 +42,42 @@ method deflongname($/) {
 }
 
 method comp_unit($/, $key?) {
+my $setting := $*IN_REPL ?? '!RESUME_HERE' !! '!YOU_ARE_HERE';
+
 # If this is the start of the unit, add an outer module.
 if $key eq 'open' {
 @PACKAGE.unshift(Perl6::Compiler::Module.new());
 @PACKAGE[0].block(@BLOCK[0]);
+
+# Make setting lexicals available at compile-time.  XXX not all of
+# these should be :does_abstraction.
+
+my $outer := pir::get_hll_global__PS($setting);
+
+until pir::isnull__IP($outer) {
+my $lexinfo := $outer.get_lexinfo;
+
+for $lexinfo -> $kv {
+@BLOCK[0].symbol($kv.key, :scope('lexical'),
+:does_abstraction(1));
+}
+
+$outer := $outer.get_outer;
+}
+
 return 1;
 }
 
 # Create the block for the mainline code.
 my $mainline := @BLOCK.shift;
 $mainline.push($.ast);
-
+
+# In the REPL, we want to save the lexical scope so it can be reused
+# in the next line
+if $*IN_REPL {
+$mainline[0].push(make_lexical_continuation("!RESUME_HERE"));
+}
+
 # If it's the setting, just need to run the mainline.
 if $*SETTING_MODE {
 $mainline.hll($?RAKUDO_HLL);
@@ -73,6 +98,7 @@ method comp_unit($/, $key?) {
 PAST::Op.new(
 :pirop('tailcall'),
 PAST::Var.new( :name('!UNIT_START'), :namespace(''), :scope('package') ),
+PAST::Var.new( :name($setting), :namespace(''), :scope('package') ),
 $mainline,
 PAST::Var.new( :scope('parameter'), :name('@_'), :slurpy(1) )
 )
@@ -96,7 +122,8 @@ method comp_unit($/, $key?) {
 :pirflags(':load'), :lexical(0), :namespace(''),
 PAST::Op.new(
 :name('!UNIT_START'), :pasttype('call'),
-PAST::Val.new( :value($unit) ),
+PAST::Var.new( :name($setting), :namespace(''), :scope('package') ),
+PAST::Val.new( :value($unit) )
 )
 )
 );
@@ -169,6 +196,9 @@ method statement($/, $key?) {
 $past := PAST::Op.new($cond, $past, :pasttype(~$ml), :node($/) );
 }
 }
+if $*AUTOPRINT && !$mc && !$ml {
+$past := PAST::Op.new(:pasttype('call'), :name('&say'), $past);
+}
 }
 elsif $ { $past := $.ast; }
 else { $past := 0; }
@@ -594,25 +624,32 @@ method term:sym($/)   { make $.ast; }
 method term:sym($/) { make create_code_object($.ast, 'Block', 0, ''); }
 method term:sym($/){ make $.ast; }
 
-method term:sym($/) {
-my $past := PAST::Block.new(
-:name('!YOU_ARE_HERE'),
-PAST::Var.new( :name('mainline'), :scope('parameter') ),
-PAST::Op.new( :pasttype('callmethod'), :name('set_outer'),
-PAST::Var.new( :name('mainline'), :scope('lexical') ),
-PAST::Var.new( :scope('keyed'), PAST::Op.new( :pirop('getinterp P') ), 'sub' )
-),
-PAST::Op.new( :pasttype('call'), PAST::Var.new( :name('mainline'), :scope('lexical') ) )
-);
-@BLOCK[0][0].push(PAST::Var.new(
-:name('!YOU_ARE_HERE'), :isdecl(1), :viviself($past), :scope('lexical')
-));
-make PAST::Op.new( :pasttype('call'),
- 

[perl #75026] [PATCH] Enable per-stage timing generation

[via RT]

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


PCT has support for timing individual stages of a long compilation, but this
functionality is not accessible in Rakudo because we overwrite the list of
command options instead of adding to it.  The attached patch fixes that, and
enables per-stage timing in time-instrumented builds.
>From 2836728f760725eca41d125f4af14d28dd1db3ba Mon Sep 17 00:00:00 2001
From: Stefan O'Rear 
Date: Mon, 10 May 2010 00:29:52 -0700
Subject: [PATCH] Enable support for --stagestats in Rakudo

This consists of a bugfix analogous to 9d4c8a9 in NQP-rx, and changes the
Makefile system to pass --stagestats to Rakudo when compiling the setting
and Test.pm in --makefile-timing builds.
---
 Configure.pl   |1 +
 build/Makefile.in  |6 --
 src/Perl6/Compiler.pir |6 +++---
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Configure.pl b/Configure.pl
index 2809f15..9d5c0c3 100644
--- a/Configure.pl
+++ b/Configure.pl
@@ -163,6 +163,7 @@ sub create_makefile {
 
 my $maketext = slurp( 'build/Makefile.in' );
 
+$config{'stagestats'} = $makefile_timing ? '--stagestats' : '';
 $config{'win32_libparrot_copy'} = $^O eq 'MSWin32' ? 'copy $(PARROT_BIN_DIR)\libparrot.dll .' : '';
 $maketext =~ s/@(\w+)@/$config{$1}/g;
 if ($^O eq 'MSWin32') {
diff --git a/build/Makefile.in b/build/Makefile.in
index 30c7acf..0e387ff 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -289,6 +289,8 @@ CLEANUPS = \
 HARNESS_WITH_FUDGE = $(PERL) t/harness --fudge --keep-exit-code --icu=$(HAS_ICU)
 HARNESS_WITH_FUDGE_JOBS = $(HARNESS_WITH_FUDGE) --jobs
 
+STAGESTATS = @stagestats@
+
 # the default target
 all: $(PERL6_EXE) Test.pir
 
@@ -313,7 +315,7 @@ $(PERL6_EXE): $(PERL6_PBC)
 
 # the complete compiler, including core/setting
 $(PERL6_PBC): $(S1_PERL6_PBC) src/gen/core.pm
-	$(PARROT) $(PARROT_ARGS) $(S1_PERL6_PBC) --target=pir \
+	$(PARROT) $(PARROT_ARGS) $(S1_PERL6_PBC) --target=pir $(STAGESTATS) \
 	src/gen/core.pm > $(CORE_PIR)
 	$(PARROT) $(PARROT_ARGS) -o $(PERL6_PBC) src/Perl6/Compiler.pir
 
@@ -410,7 +412,7 @@ $(PMC_DIR)/objectref.pmc : $(PMC_DIR)/objectref_pmc.template build/gen_objectref
 
 ##  testing targets
 Test.pir: Test.pm perl6.pbc
-	$(PARROT) $(PARROT_ARGS) perl6.pbc --target=pir --output=Test.pir Test.pm
+	$(PARROT) $(PARROT_ARGS) perl6.pbc $(STAGESTATS) --target=pir --output=Test.pir Test.pm
 
 test: coretest
 
diff --git a/src/Perl6/Compiler.pir b/src/Perl6/Compiler.pir
index f634780..4d69039 100644
--- a/src/Perl6/Compiler.pir
+++ b/src/Perl6/Compiler.pir
@@ -117,9 +117,9 @@ Perl6::Compiler - Perl6 compiler
 nqpproto.'parsegrammar'($P0)
 $P0 = get_hll_global ['Perl6'], 'Actions'
 nqpproto.'parseactions'($P0)
-$P0 = split ' ', 'e=s help|h target=s dumper=s trace|t=s encoding=s output|o=s combine version|v parsetrace'
-setattribute nqpproto, '@cmdoptions', $P0
-
+$P0 = getattribute nqpproto, '@cmdoptions'
+push $P0, 'parsetrace'
+
 # Set up @*INC from $PERL6LIB, languages/perl6/lib and ~/.perl6/lib
 .local pmc env, interp, config
 # Convert PERL6LIB first
-- 
1.6.6

[perl #75010] [BUG] @x and @.x in class methods treated differently

[via RT]

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


See IRC May 10
@.x[1 .. +...@x] is not being treated (rakudo dies) in the same way as @y[1 
.. +...@y]

In particular:

finanalyst: rakudo: class AB{has @.x; method aa { my @y=1,2,3; .say for 
@y[1 .. +...@y]; .say for @.x; .say for @.x[1 ..^ +...@.x] } };my AB $y 
.=new(:x(1,2,3)); $y.aa;
p6eval: rakudo 3d3893: OUTPUT«2␤3␤␤1␤2␤3␤No applicable candidates found 
to dispatch to for 'postcircumfix:<[ ]>'. Available candidates are:␤Mu : 
Int $i;; *%_)␤Mu : Block $b;; *%_)␤Mu : !whatever_dispatch_helper ;; 
*%_)␤␤current instr.: '!postcircumfix:<[ ]>' pc 11329 
(src/builtins/Role.pir:26)␤»


More detail:

finanalyst: rakudo: my @x=1,2,3,4; .say for @x[1 ..^ +...@x]
p6eval: rakudo 3d3893: OUTPUT«2␤3␤4␤»
finanalyst: works
finanalyst: rakudo: class AB{has @.x; method aa { .say for @.x; .say for 
@.x[1 ..^ +...@.x] } };my AB $y .=new(:x(1,2,3)); $y.aa;
p6eval: rakudo 3d3893: OUTPUT«1␤2␤3␤No applicable candidates found to 
dispatch to for 'postcircumfix:<[ ]>'. Available candidates are:␤Mu : 
Int $i;; *%_)␤Mu : Block $b;; *%_)␤Mu : !whatever_dispatch_helper ;; 
*%_)␤␤current instr.: '!postcircumfix:<[ ]>' pc 11329 
(src/builtins/Role.pir:26)␤»
finanalyst: doesnt work
masak: that is indeed odd.
colomon: ah, I believe that's an array-handling bug.
moritz_: seems like @.x is not the same kind of array as @x
moritz_: rakudo: class A { has @.x }; say A.new(:x[1, 2, 3]).x.WHAT
p6eval: rakudo 3d3893: OUTPUT«Array()␤»
colomon: ran into this same sort of problem passing @x as an argument.
moritz_: rakudo: class A { has @.x }; say A.new(:x[1, 2, 3]).x.PARROT
p6eval: rakudo 3d3893: OUTPUT«Array␤»
finanalyst: rakudo: class AB{has @.x; method aa { my @y=1,2,3; .say for 
@y; .say for @.x; .say for @.x[1 ..^ +...@.x] } };my AB $y 
.=new(:x(1,2,3)); $y.aa;
p6eval: rakudo 3d3893: OUTPUT«1␤2␤3␤1␤2␤3␤No applicable candidates found 
to dispatch to for 'postcircumfix:<[ ]>'. Available candidates are:␤Mu : 
Int $i;; *%_)␤Mu : Block $b;; *%_)␤Mu : !whatever_dispatch_helper ;; 
*%_)␤␤current instr.: '!postcircumfix:<[ ]>' pc 11329 
(src/builtins/Role.pir:26)␤»
masak: rakudo: class A { has @.x }; say A.new(:x(1, 2, 3)).x.WHAT
p6eval: rakudo 3d3893: OUTPUT«Array()␤»
finanalyst: rakudo: class AB{has @.x; method aa { my @y=1,2,3; .say for 
@y[1 .. +...@y]; .say for @.x; .say for @.x[1 ..^ +...@.x] } };my AB $y 
.=new(:x(1,2,3)); $y.aa;
p6eval: rakudo 3d3893: OUTPUT«2␤3␤␤1␤2␤3␤No applicable candidates found 
to dispatch to for 'postcircumfix:<[ ]>'. Available candidates are:␤Mu : 
Int $i;; *%_)␤Mu : Block $b;; *%_)␤Mu : !whatever_dispatch_helper ;; 
*%_)␤␤current instr.: '!postcircumfix:<[ ]>' pc 11329 
(src/builtins/Role.pir:26)␤»
finanalyst: definitely treating @y and @.x differently
moritz_: rakudo: class AB{has @.x; method aa { my @y=1,2,3; .say for 
@!x[1@!x] } }; AB.new(:x[1, 2, 3]).aa
p6eval: rakudo 3d3893: OUTPUT«No applicable candidates found to dispatch 
to for 'postcircumfix:<[ ]>'. Available candidates are:␤Mu : Int $i;; 
*%_)␤Mu : Block $b;; *%_)␤Mu : !whatever_dispatch_helper ;; 
*%_)␤␤current instr.: '!postcircumfix:<[ ]>' pc 11329 
(src/builtins/Role.pir:26)␤»
- envi^home has joined the room
colomon: rakudo: sub foo(@a) { .say for @a[1 ..^ +...@a] }; my @a = 1... 4; 
foo(@a)
p6eval: rakudo 3d3893: OUTPUT«2␤3␤4␤»

- 18:25 -
colomon: hmmm
finanalyst: shall i post a rakudobug?
* colomon still thinks it's related to a rakudobug from a couple of 
weeks ago...
colomon: finanalyst: yes.

Re: [perl #73796] rakudo compiler never builds due to thrashing

[Karthik BP]

Yes Moritz.
It builds fine now. Thanks!
--
Karthik


On Tue, May 11, 2010 at 4:01 PM, Moritz Lenz via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sat Apr 03 17:37:16 2010, karthik...@gmail.com wrote:
> > Sure. I'll try.
> > --
> > Karthik
>
> Did you have any success?
>
> >
> > On Fri, Apr 2, 2010 at 4:56 PM, Moritz Lenz via RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > Please try again with the current development version of Rakudo, memory
> > > usage has been significantly reduced since this bug was reported.
> > >
>
>
>
>

Re: [perl #75030] [PATCH] Lexical persistence & autoprinting for the REPL

[Stefan O'Rear]

On Tue, May 11, 2010 at 08:25:47AM -0700, Patrick R. Michaud via RT wrote:
> 1.  I don't like that it modifies the parameters of !UNIT_START.

I see three alternatives - clone UNIT_START (DRY), inline UNIT_START in
the PAST (DRY), and unify !RESUME_HERE with !YOU_ARE_HERE (makes modules
run in the REPL setting - buggy).  Do you see a better one?

> 2.  I don't think we should suppress autoprinting of statements and
> blocks.  For example, the 'while' statement above _does_ return a value,
> it should be printed.

The autoprint heuristic is currently "all non-nested expression statements".
It's the simplest workable one I could think of, but it definitely needs
refinement - some non-expression statements have values worth printing, and
there's no point in printing the value of 'my $x = 2' or 'say $x'.  Again,
ideas welcome.

> 3.  I'm really not a fan that being in REPL mode or having autoprinting
> enabled changes the AST that is produced.  I think it ought to be
> independent somehow.  (Again, I might be able to be argued out of this one.)

Are you suggesting moving all of this logic into PAST::Compiler?  I would
rather see it at least start in Rakudo, where it's easier to change; also
I'm not a fan of PAST::Compiler generating completely different output from
the same input depending on a couple contextuals, whereas our parser already
is highly context sensitive (e.g. $*SCOPE).  Suggestions welcome.

Ideas for a "Object-Belongs-to-Thread" threading model

[Daniel Ruoso]

Hi,

The threading model topic still needs lots of thinking, so I decided to
try out some ideas.

Every concurrency model has its advantages and drawbacks, I've been
wondering about this ideas for a while now and I think I finally have a
sketch. My primary concerns were:

 1 - It can't require locking: Locking is just not scalable;
 2 - It should perform better with lots of cores even if it suffers
 when you have only a few;
 3 - It shouldn't require complicated memory management techniques that 
 will make it difficult to bind native libraries (yes, STM is damn 
 hard);
 4 - It should suport implicit threading and implicit event-based  
 programming (i.e. the feed operator);
 5 - It must be easier to use then Perl 5 shared variables;
 6 - It can't use a Global Interpreter Lock (that already said in 1, 
 but, as this is a widely accepted idea in some other environments,
 I thought it would be better to make it explicit).

The idea I started was that every object has an "owner" thread, and only
that "thread" should talk to it, and I ended up with the following,
comments are appreciated:

0 - The idea is similar to Erlang and the "IO Language". Additionally
to OS threads there are the interpreter processes.

1 - No memory is shared between processes, so no locking is
necessary.

2 - The interpreter implements a scheduler, just like POE.

3 - The scheduler, unlike POE, should be able to schedule in
several OS threads, such that any OS thread may raise any
waiting process.

4 - Each process is run in only one OS thread at a time, it's
like a Global Interpreter Lock, but it's related only to one
specific process.

5 - A process may block, and the scheduler must become aware of
that blocking. That is implemented through Control
Exceptions.

6 - In order to implement inter-process communication, there are:

6.1 - A "MessageQueue" works just like an Unix Pipe, it looks
  like a slurpy array. It has a configurable buffer size
  and processes might block when trying to read and/or
  write to it.

6.2 - A "RemoteInvocation" is an object that has an identifier, a
  capture (which might, optionally, point to a "MessageQueue"
  as input) and another "MessageQueue" to be used as output.

6.3 - An "InvocationQueue" is a special type
  of "MessageQueue" that accepts "RemoteInvocation"
  objects.
  
6.4 - A "RemoteValue" is an object that proxies requests to
  another processes through a "RemoteInvocation".

7 - The process boundary is drawn at each closure, every closure
belongs to a process, every value initialized inside a
closure belongs to that closure. You might read coroutine instead
of closure if you like.

8 - A value might have its ownership transferred to another closure if
it can be detected that this value is in use only for that
invocation or return value, in order to reduce the amount of
"RemoteInvocation"s.

9 - A value might do a special "ThreadSafe" role if it is thread-safe
(such as implementing bindings to thread-safe native libraries) In
which case it is sent as-is to a different thread.

10 - A value might do a special "ThreadCloneable" role if it should
 be cloned instead of being proxied through a "RemoteValue"
 when sent to a different process.

11 - The "MessageQueue" notifies the scheduler through a Control
 Exception whenever new data is available in that queue so the
 target process might be raised.

12 - Exception handling gets a bit hairy, since exceptions might only
 be raised at the calling scope when the value is consumed.

13 - List assignment and Sink context might result in synchronized
 behavior.

comments? ideas?

daniel

Re: Ideas for a "Object-Belongs-to-Thread" threading model

[Larry Wall]

Since I don't think BrowserUK subscribes here, I'll paste in the remarks
he attached to your earlier paste, just to help get the discussion going,
and on the assumption this will not be regarded as antisocial.  :)

Larry

BrowserUK wrote:
> 
> -there are the interpreter processes.
> 
> Inventing (overloaded) terminology will just create confusion. Very
> unhelpful in a context that suffers more than its fair share already.
> 
>- The interpreter implements a scheduler, just like POE.
> 
> POE does *NOT* implement a "scheduler". 
>   It implements a state machine--with the controlling state both
> global and shared.
>   It provides no concurrency. Not even the illusion of concurrency. 
> 
> It does a little of this; and a little of that; and a little of
> something else; but only one thing at a time regardless of how many
> cores are available.
> 
> And if one of those little bits of something hangs, the entire edifice
> hangs.
> 
>  -3 - The scheduler, ulike POE, should be able to schedule in
>  several OS threads, such that any OS thread may raise any
>  waiting process.
>  
> And how are you going to implement that? 
> 
> The only way would be for there to be multiple concurrent (kernel
> threaded) instances of the state-machine running sharing (as in shared
> state concurrency) their controlling state.   
> 
> This re-creates all the very worst problems of: 505threads, green
> threads; and Windows3 cooperative scheduling.
> 
> Besides that it would be a nightmare to implement; it would be an even
> worse nightmare to program,

Re: Ideas for a "Object-Belongs-to-Thread" threading model

[Timothy S. Nelson]

On Tue, 11 May 2010, Daniel Ruoso wrote:


2 - The interpreter implements a scheduler, just like POE.


	I don't have a clue about threading, but I saw POE, and since I know 
that's an event loop mechanism, I thought I'd comment that I want to be able 
to do GTK programming, which I think requires using the GTK event loop. 
There may be some way to hook all this together, but I just thought I'd put 
this thought into the collective mind again.


HTH,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-