Re: Solving '=' confusion: ':=' for aliasing

[Roger Browne]

Salzenberg wrote:

> ... any language using ":=" for assignment is doomed
> to obscurity.[*]  It's a law of nature.

 :-)

> (Ah, language design.  :-))

No choice will satisfy everyone. So we each say our piece, then we
happily accept whatever the designer decides. No problem.

Regards,
Roger Browne

Re: Solving '=' confusion: ':=' for aliasing

[Josh Isom]

My view  I understand the way it's currently done.  I'm totally lost
at what's being proposed.

Joshua

On Wed, 30 Nov 2005, Roger Browne wrote:

> Salzenberg wrote:
>
> > ... any language using ":=" for assignment is doomed
> > to obscurity.[*]  It's a law of nature.
>
>  :-)
>
> > (Ah, language design.  :-))
>
> No choice will satisfy everyone. So we each say our piece, then we
> happily accept whatever the designer decides. No problem.
>
> Regards,
> Roger Browne
>

Re: pdd03 (calling conventions) revised; get_params vs. READONLY

[Roger Browne]

Chip Salzenberg wrote:

> Most importantly, I've proposed (but not mandated) a get_params flag
> called "READONLY", which automatically creates a read-only wrapper
> around a PMC parameter.

I'd use READONLY if it existed, though I can get by without it.

Regards,
Roger Browne

pdd03 and Overflow/Underflow - r10269

[Leopold Toetsch]

Parrot didn't throw exceptions on param or result count mismatch until 
now, and still doesn't. [1]


But, I have invented 2 more error flag bits [2], which can enable 
stricter argument checking and the exception is catchable in the 
subroutine itself now:


  .include "errors.pasm"
   errorson .PARROT_ERRORS_PARAM_COUNT_FLAG
   foo(1, 2)
   ...
   .sub foo
  push_eh handler
  get_params '(0)', $P0# no .params yet - sorry

handler:
  .local pmc e
  .local string m
  .get_results (e, m)
  printerr m
  exit 1

A few tests are in t/op/calling.t

I hope this is useful.
leo

[1] all PGE and PGE-based stuff is failing, when both are turned on
[1] please reconfigure, perldoc ops/core.ops /errorson

Re: Packfile writing bug

[Leopold Toetsch]

Jonathan Worthington wrote:

Hi,

I seem to be touching a bug related to writing compiled code.

pir_comp = compreg "PIR"
pbc_out = pir_comp(gen_pir)
fh = open output
print fh, pbc_out
close fh

On the print line, I get this error:-

directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160


It could be related to classes/eval.pmc:218 ff, but I can't reproduce 
it. There is a test in t/pmc/eval.t 'eval.freeze', which is very 
similar. I tried to insert more code but this didn't show the problem.


Please submit a full example showing the bug or better check it in as a 
todo test.


This used to work - I sync'd up my Parrot tree from one that's at least 
a week old and it was broken, however.  So I guess the outcome or a 
recent change.


It may highly depend on the compiled code and other stuff.


Fixes very welcome,

Jonathan


leo

Re: Packfile writing bug

[Jonathan Worthington]

"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:

Jonathan Worthington wrote:

Hi,

I seem to be touching a bug related to writing compiled code.

pir_comp = compreg "PIR"
pbc_out = pir_comp(gen_pir)
fh = open output
print fh, pbc_out
close fh

On the print line, I get this error:-

directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160


It could be related to classes/eval.pmc:218 ff, but I can't reproduce it. 
There is a test in t/pmc/eval.t 'eval.freeze', which is very similar. I 
tried to insert more code but this didn't show the problem.


Please submit a full example showing the bug or better check it in as a 
todo test.


OK, attached.  If you run this as a PIR example, it works just fine.  If you 
compile it to a PBC, then you get the error.


$ parrot breaks2.pir example.dll

$ parrot -o breaks2.pbc breaks2.pir

$ parrot breaks2.pbc example.dll
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160

Note: example.dll need not exist.  Sorry it's not a particularly small test 
case - the problem seemed to vanish when I simplified it further than I 
have.


Thanks,

Jonathan 


breaks2.pir
Description: Binary data

Re: Packfile writing bug

[Peter Sinnott]

On Wed, Nov 30, 2005 at 03:49:36PM -, Jonathan Worthington wrote:
> OK, attached.  If you run this as a PIR example, it works just fine.  If 
> you compile it to a PBC, then you get the error.
> 
> $ parrot breaks2.pir example.dll
> 
> $ parrot -o breaks2.pbc breaks2.pir
> 
> $ parrot breaks2.pbc example.dll
> directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
> 
> Note: example.dll need not exist.  Sorry it's not a particularly small test 
> case - the problem seemed to vanish when I simplified it further than I 
> have.
> 

Might this be related to bug 32392?

http://rt.perl.org/rt3/index.html?q=32392


-- 
The customer can count on us to seamlessly promote corporate intellectual 
capital to allow us to collaboratively restore business methods of empowerment

Re: Packfile writing bug

[jerry gay]

On 11/30/05, Peter Sinnott <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 30, 2005 at 03:49:36PM -, Jonathan Worthington wrote:
> > OK, attached.  If you run this as a PIR example, it works just fine.  If
> > you compile it to a PBC, then you get the error.
> >
> > $ parrot breaks2.pir example.dll
> >
> > $ parrot -o breaks2.pbc breaks2.pir
> >
> > $ parrot breaks2.pbc example.dll
> > directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
> >
> > Note: example.dll need not exist.  Sorry it's not a particularly small test
> > case - the problem seemed to vanish when I simplified it further than I
> > have.
> >
>
> Might this be related to bug 32392?
>
> http://rt.perl.org/rt3/index.html?q=32392
>
if you mean GETARGS: and GOTARGS:, no, they're not duplicates ;)

~jerry

Re: Packfile writing bug

[jerry gay]

On 11/30/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
> > Jonathan Worthington wrote:
> >> Hi,
> >>
> >> I seem to be touching a bug related to writing compiled code.
> >>

i can't recreate this bug (r10271).

D:\usr\local\parrot\trunk>parrot breaks2.pir example.dll

D:\usr\local\parrot\trunk>parrot -o breaks2.pbc breaks2.pir

D:\usr\local\parrot\trunk>parrot breaks2.pbc example.dll

D:\usr\local\parrot\trunk>

~jerry

Re: Packfile writing bug

[Leopold Toetsch]

Jonathan Worthington wrote:


$ parrot -o breaks2.pbc breaks2.pir

$ parrot breaks2.pbc example.dll
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160


Same answer as Jerry - works here on x86/linux.


Thanks,

Jonathan


leo

Re: Packfile writing bug

[Peter Sinnott]

On Wed, Nov 30, 2005 at 08:05:09AM -0800, jerry gay wrote:
> On 11/30/05, Peter Sinnott <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 30, 2005 at 03:49:36PM -, Jonathan Worthington wrote:
> > > OK, attached.  If you run this as a PIR example, it works just fine.  If
> > > you compile it to a PBC, then you get the error.
> > >
> > > $ parrot breaks2.pir example.dll
> > >
> > > $ parrot -o breaks2.pbc breaks2.pir
> > >
> > > $ parrot breaks2.pbc example.dll
> > > directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
> > >
> > > Note: example.dll need not exist.  Sorry it's not a particularly small 
> > > test
> > > case - the problem seemed to vanish when I simplified it further than I
> > > have.
> > >
> >
> > Might this be related to bug 32392?
> >
> > http://rt.perl.org/rt3/index.html?q=32392
> >
> if you mean GETARGS: and GOTARGS:, no, they're not duplicates ;)
>

GETARGS GOTARGS? I have no idea what your talking about

I was refering to the bug that said :

"Also label fixup handling is different so just don't compile
PIR files to PASM except for debugging"

and wondering if whatever caused pir->pasm->execute pasm
to not always work also caused pir->pbc->execute pbc to not always
work.

> ~jerry

-- 
The customer can count on us to seamlessly promote corporate intellectual 
capital to allow us to collaboratively restore business methods of empowerment

Components of Parrot

[Klaas-Jan Stol]

Hello,

Some time ago, I announced I would be writing a paper on the 
architecture of Parrot. The paper will be about 10 pages (I think, at 
this point), so there will be quite a high level of abstraction in order 
to be able to fit all important info. (so no "class" diagrams, if one 
could even speak of classes, but more "components", or (black) boxes 
that have some functionality).


Anyway, the structure will be more or less as follows (very global, for 
details, the interested reader can refer to the paper, which is at
http://members.home.nl/joeijoei/parrot/paper.pdf , only 4 pages 
currently, including references, and section headers):


the sections are:

-introduction *
-motives for Parrot *
-stakeholders *
-requirements *
-architecture overview
-main components -> some sections, each one on a different important 
component, for example, a section on the Garbage Collector
-other features (things that I can't fit or are architecturally speaking 
not very significant/interesting)

-summary

The *'ed items are more or less complete, but will be subject to 
reviewing later on.


Now, I'm at the "architecture overview". In this section, I'd like to 
give a picture of what Parrot looks like from 10 miles in the sky.
So, what main components are there, and, very important, what are the 
mutual relations between those components.


As said, in the sections after that, I'll talk about a number of these 
components that have interesting design decisions, such as the Parrot 
core (i.e. why registers, and not stack oriented, data types, why not 
PMC and Strings unified?, that kind of stuff), the garbage collector 
(why not ref.counting, etc.), threads (how implemented, OS, or some library)
Luckily, a lot of that stuff is documented *somewhere* in the docs or 
can be retrieved in the mailing list.


Now, my question is, are there any docs describing, or containing 
pictures, of these main components of Parrot? (I'm talking about a 
picture containing boxes, with lines of interaction between them). For 
example, the part of Parrot running the actual opcodes would be a box, 
(this is the engine), and it would have interaction with the registers 
(themselves being represented by a box "registers" or something like 
that). Then there is a box "heap" memory or something (would there 
be??), and a box called Garbage collector having interaction with that 
memory.


I vaguely remember a dependency graph which was generated, and could be 
found on the Parrot Wiki (IIRC). Maybe something like that could be of 
help too (the wiki is down, last time I checked). Of course, I would 
very much like to include some graphics, which helps the reader to see 
how Parrot is constructed of "components" with certain functionality.


Anyway, help of any kind (pointers to docs, or whatever) would be 
greatly appreciated :-),


kind regards,

klaas-jan

Re: Solving '=' confusion: ':=' for aliasing

[Joshua Juran]

On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:


On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote:

On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:

I'm planning a flag day sometime in December.  I'm also planning to
create a simple "handles most cases" translator.


That's all ok with me, but not without an automatic translator [...]


Excellent.  Now if only I knew a good language for text filters...


How about sed or awk?

Josh

Re: statement_control()

[Piers Cawley]

Larry Wall <[EMAIL PROTECTED]> writes:

> On Tue, Nov 22, 2005 at 10:12:00AM +0100, Michele Dondi wrote:
> : Oh, I'm not the person you were responding to, and probably the less 
> : entitled one to speak in the name of everyone else here, but I feel like 
> : doing so to say that in all earnestness I'm quite sure no one took any 
> : offense out of your words. Despite the slight harshness, they're above all 
> : witty. Just as usual: and that's the style we all like!
>

$fh = open '>>', 'quotefile' or fail;
$fh.print <<'EOQ'
I like witty sayings as much as the next guy, but wit can hurt when
misdirected.  If people want me to be machine for cranking out quote
file fodder, I'll do my best.  But I also care about my friends.

Larry
EOQ

-- 
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/

Re: pdd03 (calling conventions) revised; get_params vs. READONLY

[Jonathan Sillito]

On 11/29/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> I've reviewed pdd03 and brought it back from pdds/clip.

Thanks for reviving this document Chip. Way back when I implemented
some of the original lexical and calling code (like the scratchpad --
may it rest in peace). What is the status of the todo's mentioned in
the BUGS section, who is working on these -- I am looking for a place
to jump in. Also what is the status of the exception subsystem you
mentioned?

I guess one more todo I could take on is the add the use of the set_*
and get_* ops to examples/subs. A short example in the pdd might be
helpful too.

Jonathan

Re: pdd03 and Overflow/Underflow - r10269

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
> Parrot didn't throw exceptions on param or result count mismatch
> until now, and still doesn't. [1]
> [1] all PGE and PGE-based stuff is failing, when both are turned on

Exceptions should still be the default, even if PGE needs some
changes.  I agree with you that it should be possible to avoid
throwing exceptions, but the error bits aren't the way: they're
dynamic, which makes it difficult for compilers to reliably set
parameter exception policy.

Allowing too few parameters is already possible through the extensive
use of :optional.  As for the too-many case: If we add a :last flag
which means "any additional incoming values should be ignored", then
that's covered too.  Then users can avoid throwing exceptions in all
cases, if that's what they want.

Patrick, would that work for you?  For that matter, did you know that
your code dies when parameter counts are enforced?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Solving '=' confusion: ':=' for aliasing

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote:
> On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
> >Excellent.  Now if only I knew a good language for text filters...
> 
> How about sed or awk?

Hm.  If only we had a pir2xml, I could use XSLT.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd03 and Overflow/Underflow - r10269

[Patrick R. Michaud]

On Wed, Nov 30, 2005 at 11:00:36AM -0800, Chip Salzenberg wrote:
> On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
> > Parrot didn't throw exceptions on param or result count mismatch
> > until now, and still doesn't. [1]
> > [1] all PGE and PGE-based stuff is failing, when both are turned on
> ...
> Allowing too few parameters is already possible through the extensive
> use of :optional.  As for the too-many case: If we add a :last flag
> which means "any additional incoming values should be ignored", then
> that's covered too.  Then users can avoid throwing exceptions in all
> cases, if that's what they want.
> 
> Patrick, would that work for you?  For that matter, did you know that
> your code dies when parameter counts are enforced?

Yes, I knew that some code pieces would have trouble when parameter counts
were enforced, but I figured I'd cross that bridge when we came to it.
I guess we're there now.

Short answer:  something like a ":last" flag would be excellent.

Longer answer:  In PGE, each rule is a parrot sub, and some rules
can be parameterized by various parameters, which means that the number
of arguments to a rule can vary depending on the rule and the
context in which it can be called.  So, there's not a hard-and-fast
parameter list that is going to work in all situations and provide
the flexibility we'll want.  Thus, we really ought to have a way to
indicate that a rule (parrot sub) can still be safely run even if
called with more parameters than it expects.

In the meantime, I'll go ahead and see about updating PGE so that
any extra params from callers don't cause much grief.

Pm

pdd20 questions

[Jonathan Sillito]

I have some clarification questions about the new pdd20 on lexical
variables -- likely stemming from my having been out of it for so
long. Also I am happy to send a patch to pdd20 capturing these
clarifications once I am sure I understand things correctly.

1. What is expected to be in P0 in:

   .lex "$a", P0

2. Should we provide a way for a compiler to provide depths to the
find_lex and store_lex ops if it chooses to?

3. 'Call frame' is mentioned often--what is a call frame in the
context of continuation passing style?

4. In the section "Closure creation: Capturing the lexical
environment", LexPad is used a couple of times when LexEnv is meant,
right?

5. Thinking about closure support vs. outer support - the difference
and the need for both mechanisms is not clear to me.

6. The pdd mentions walking the call stack to find frames ... but is
there a call stack? And finding lexpads on the call stack makes me
think of dynamic variable binding rather than lexical?

7. Finally, what is the status of the implementation?

(As an aside is there interest in having the names of the invoke ops
more consistent, say: callcc and callcc_method; or invokecc and
invokecc_method?)

Jonathan

Re: statement_control()

[Larry Wall]

On Wed, Nov 30, 2005 at 06:36:22PM +, Piers Cawley wrote:
: $fh = open '>>', 'quotefile' or fail;
: $fh.print <<'EOQ'
: I like witty sayings as much as the next guy, but wit can hurt when
: misdirected.  If people want me to be machine for cranking out quote
: file fodder, I'll do my best.  But I also care about my friends.

Er, please append this to your program:

system "perl -i.bak -pe 's/to be machine/to be a machine/' quotefile";

:-)

Larry

Re: pdd03 and Overflow/Underflow - r10269

[Will Coleda]

On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:


On Wed, Nov 30, 2005 at 11:00:36AM -0800, Chip Salzenberg wrote:

On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:

Parrot didn't throw exceptions on param or result count mismatch
until now, and still doesn't. [1]
[1] all PGE and PGE-based stuff is failing, when both are turned on

...
Allowing too few parameters is already possible through the extensive
use of :optional.  As for the too-many case: If we add a :last flag
which means "any additional incoming values should be ignored", then
that's covered too.  Then users can avoid throwing exceptions in all
cases, if that's what they want.

Patrick, would that work for you?  For that matter, did you know that
your code dies when parameter counts are enforced?


Yes, I knew that some code pieces would have trouble when parameter  
counts

were enforced, but I figured I'd cross that bridge when we came to it.
I guess we're there now.

Short answer:  something like a ":last" flag would be excellent.

Longer answer:  In PGE, each rule is a parrot sub, and some rules
can be parameterized by various parameters, which means that the  
number

of arguments to a rule can vary depending on the rule and the
context in which it can be called.  So, there's not a hard-and-fast
parameter list that is going to work in all situations and provide
the flexibility we'll want.  Thus, we really ought to have a way to
indicate that a rule (parrot sub) can still be safely run even if
called with more parameters than it expects.



Isn't this what :slurpy is for? How else would you even use extras?


In the meantime, I'll go ahead and see about updating PGE so that
any extra params from callers don't cause much grief.

Pm

Re: pdd03 and Overflow/Underflow - r10269

[Patrick R. Michaud]

On Wed, Nov 30, 2005 at 03:27:52PM -0500, Will Coleda wrote:
> On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:
> >Short answer:  something like a ":last" flag would be excellent.
> >
> >Longer answer:  In PGE, each rule is a parrot sub, and some rules
> >can be parameterized by various parameters, which means that the  
> >number
> >of arguments to a rule can vary depending on the rule and the
> >context in which it can be called.  So, there's not a hard-and-fast
> >parameter list that is going to work in all situations and provide
> >the flexibility we'll want.  Thus, we really ought to have a way to
> >indicate that a rule (parrot sub) can still be safely run even if
> >called with more parameters than it expects.
> 
> Isn't this what :slurpy is for? How else would you even use extras?

Oh, I suppose I could :slurpy any extra parameters into a dummy
array.  But that probably involves creating a dummy empty array on every 
call to the parrot sub.

At any rate, I found and fixed the two PGE subs that weren't declaring 
their (unused) parameters.  All p6rules tests now appear to pass in 
r10278 with .PARROT_ERRORS_PARAM_COUNT_FLAG enabled.

Pm

Re: Solving '=' confusion: ':=' for aliasing

[Larry Wall]

On Wed, Nov 30, 2005 at 11:04:43AM -0800, Chip Salzenberg wrote:
: On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote:
: > On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
: > >Excellent.  Now if only I knew a good language for text filters...
: > 
: > How about sed or awk?
: 
: Hm.  If only we had a pir2xml, I could use XSLT.

Well, if you can come up with a PIR -> PIL, and Autrijus can come up
with a PIL to Perl 5, then we're home free, because I can translate
Perl 5 to XML.  Here's "hello world", for instance:












































Hope this helps

Larry

Re: pdd03 and Overflow/Underflow - r10269

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 03:27:52PM -0500, Will Coleda wrote:
> On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:
> >Thus, we really ought to have a way to indicate that a rule (parrot
> >sub) can still be safely run even if called with more parameters
> >than it expects.
> 
> Isn't this what :slurpy is for?

Well, :slurpy is good if you do (or might) want to examine the extra
parameters.  If you just want to throw them away, there should be a
way to say that.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Solving '=' confusion: ':=' for aliasing

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 12:41:59PM -0800, Larry Wall wrote:
>  private="REFCOUNTED"
> refcnt="1">
> 
> 
> 
> 
> 
> 
> 
> [...]
>
> Hope this helps

I sense a great evil.  An evil that has been in abeyance since the
defeat of IP over XML-RPC.

That is not dead which can eternal lie
And with strange aeons, even XML may die
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd03 and Overflow/Underflow - r10269

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote:
> At any rate, I found and fixed the two PGE subs that weren't declaring 
> their (unused) parameters.  All p6rules tests now appear to pass in 
> r10278 with .PARROT_ERRORS_PARAM_COUNT_FLAG enabled.

Excellent.

Leo, would you be so kind as to rescind the parameter passing error
flags, and make mismatches always throw?  Unless/until we have :last,
users can use :slurpy on an unused register to mean "extra params OK".
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd03 and Overflow/Underflow - r10269

[Chip Salzenberg]

Say, I just noticed this:

On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
>.sub foo
>   push_eh handler
>   get_params '(0)', $P0# no .params yet - sorry

I remember at one point that get_params had to be the first opcode in
the sub.  I didn't like that, but I didn't know you'd fixed it.  Are
there any remaining limitations on the placement of the pdd03 opcodes?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd20 questions

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> I have some clarification questions about the new pdd20 on lexical
> variables -- likely stemming from my having been out of it for so
> long. Also I am happy to send a patch to pdd20 capturing these
> clarifications once I am sure I understand things correctly.

Hey, so this is doubly useful.  :-)

> 1. What is expected to be in P0 in:
>.lex "$a", P0

The ".lex" directive is compile-time only, and has no runtime effect
on the contents of P0.  (Of course, once a register is available with
a lexical name, "store_lex" may modify it.)

> 2. Should we provide a way for a compiler to provide depths to the
> find_lex and store_lex ops if it chooses to?

Maximum depths, you mean?  I know of no use case for it.

> 3. 'Call frame' is mentioned often--what is a call frame in the
> context of continuation passing style?

I think "activation record" is the usual term of art.  If that's
right, and now that I just remembered it (!), I'd welcome a patch that
fixes the terminology.

> 4. In the section "Closure creation: Capturing the lexical
> environment", LexPad is used a couple of times when LexEnv is meant,
> right?

Fixed.  Also, while I was at it, I think I fixed nested closures.  At
least, I fixed the spec for them.  :-)

> 5. Thinking about closure support vs. outer support - the difference
> and the need for both mechanisms is not clear to me.

Could you unpack this, please?

> 6. The pdd mentions walking the call stack to find frames ... but is
> there a call stack?

I call it that mostly for historical reasons.  From any given starting
point, the records form a singly-linked acyclic list.  The overall set
of activation records is a tree, with child nodes pointing to parents.

> And finding lexpads on the call stack makes me think of dynamic
> variable binding rather than lexical?

Well, only call frames that belong to textually enclosing subroutines
are considered.  The old lexical system ignored textual enclosure,
which made it broken in all the ways you might think.

> 7. Finally, what is the status of the implementation?

AFAIK, it all works from the user point of view, except that there
are no LexEnv objects per se.

Leo has written the pdd20 closure support in a way that keeps more
live data than the LexEnv approach.  Closures thus use more memory
than necessary, but as a result, they may be a lot faster to create.
I need to evaluate this to decide whether it (1) works in a way I can
live with and (2) even if it does, if the memory issues mean that it
needs to be replaced with a real LexEnv.

> (As an aside is there interest in having the names of the invoke ops
> more consistent, say: callcc and callcc_method; or invokecc and
> invokecc_method?)

I'm not planning to rename any opcodes ATM.  As Allison correctly
observes, PIR is an assembly language, not an HLL.  So the barrier
to cosmetic cleanups is higher.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd20 questions

[Jonathan Sillito]

On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > I have some clarification questions about the new pdd20
>
> > 1. What is expected to be in P0 in:
> >.lex "$a", P0
>
> The ".lex" directive is compile-time only, and has no runtime effect
> on the contents of P0.  (Of course, once a register is available with
> a lexical name, "store_lex" may modify it.)

OK, so this directive makes "$a" an alias for P0.

> > 2. Should we provide a way for a compiler to provide depths to the
> > find_lex and store_lex ops if it chooses to?
>
> Maximum depths, you mean?  I know of no use case for it.

Not maximum depth but the exact depth for a given lexical variable in
the case of closures. The reason would simply be performance, though
maybe insignificant in the common case (i.e. shallow nesting).

> > 5. Thinking about closure support vs. outer support - the difference
> > and the need for both mechanisms is not clear to me.
>
> Could you unpack this, please?

Well, using :outer allows the look up algorithm to walk through
enclosing lexical scopes ($sub = $sub.outer). In the case of closures
the LexEnv is populated with the enclosing LexPads which I assume come
from enclosing lexical scopes, which allows the the look up to do the
same thing, no? I must be missing something here.

> Chip Salzenberg <[EMAIL PROTECTED]>

Thanks,
Jonathan

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 2005-11-27
Another week passes. Another summary is written. Another sentence
remains steadfastly in the passive voice.

This week in perl6-compiler
  Perl 5 tests for PGE::P5Regexp
Jerry Gay announced that he'd checked in a subset of perl 5.9.2's regexp
tests to give PGE something to work on. Right now only 130 of 960 tests
are running, in part because the test harness he's using can't quite
cope with the test file syntax used for the original tests. I'm sure it
won't stay that way or long.

A couple of days later he announced that more tests were being converted
and that there were now 360 passing tests and a further 155 or so TODO
tests.

Well done Jerry.



  PDD 20 and :outer
Leo had some questions about the workings of lexical pads and ":outer".
He showed a couple of examples in high level language and wondered if
his parrot conversions were right. Chip thought that Leo shouldn't worry
about implementing the Perl 5 semantics of a named inner subroutine
because the way Perl 5 does it is a bug not a feature. Dave Mitchell
wasn't so sure.



  DynLexPad
Leo's working on implementing a DynLexPad PMC to provide 'a more dynamic
lexpad' akin to the new deprecated ScratchPad PMC. He outlined his
current plans and asked for comments from HLL authors about what they
needed.



  Punie to AST
Allison has checked in the code to transform PunieGrammar match objects
into Abstract Syntax Trees (ASTs). Apparently the set of AST node types
she's using isn't quite the same as the Pugs PIL. Hopefully one day
we'll have a common AST format, and all manner of things shall be well.



Meanwhile, in perl6-internals
  RESPONSIBLE_PARTIES or ENTITIES_AT_FAULT?
Joshua Hoblitt suggested that Jerry Gay should be added to the
RESPONSIBLE_PARTIES file as the person in charge of the test suite.
After a small amount of byplay suggesting the file be renamed, the
nomination was strongly seconded and Jerry's name added to the list.



  Curses and parrot problems?
Josh Isam has been having problems with using the curses library under
both Darwin and freebsd. He wondered if anyone had any pointers for
fixing things. Leo thought it might be that the parrot ncurses support
was getting a function signature wrong somewhere and suggested Josh
check that.



  Subs may not contain dynamic call info, ever
Repeat after Chip: "Subs don't have callers. Call frames have callers."

After a short discussion with Leo, Chip wrote a short treatise on the
relationships between Subs and Closures, noting that they should only
hold static information.



  Undefined labels
While working on TODO #37590 (catch illegal bsr at compile time), Leo's
made parrot rather more picky about labels and how they are used.
Essentially, if you weren't doing daft things with labels you're
probably all right. If you were, you should probably check this post.

After Leo checked the fixes in (r10168), several PGE tests started
breaking. Less than 6 hours later, Patrick check version r10176 in and
the tests started passing again. Leo (and I) was impressed.





  Exception handlers and calling conventions
Leo posted a brain dump about how to get exception handling to work in
Parrot. In particular he wanted help with syntax (exception handling
semantics aren't exactly rocket science when you've got a continuation
based virtual machine after all). Warnock applied (However, I am
reliably informed that next week's summary will have some responses;
anyone who suggests that that's because this summary is late will be
annoyingly Right).



  Test::More and tests in PIR
Not content with having a pure PIR implementation of Test::Builder,
chromatic posted his implementation of Test::More in pure parrot.
Admittedly the current version should likely be called
Test::Less::Is::More, but the journey of 1000 cliches starts with a
single step and all that. And that's not all, the fearlessly lowercased
one intends to start work on the big daddy, Parrot::Test with an eye to
doing even more in Parrot. (Which makes a good deal of sense. After all,
the plan is to get Parrot to a point where it can be built without
needing a working perl installation)



Meanwhile, in perl6-language
  "\x{123a 123b 123c}"
Juerd had praised Ruud H.G. van Tol's proposal of "\x{123a 123b 123c}"
as a replacement for "\x{123a} \x{123b} \x{123c}" in rules. Larry wasn't
so sure. He suggested "\x[123a,123b,123c]" but still wasn't exactly
happy with it. He also had some th

Re: pdd20 questions

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 03:58:28PM -0800, Jonathan Sillito wrote:
> On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > > 2. Should we provide a way for a compiler to provide depths to the
> > > find_lex and store_lex ops if it chooses to?
> >
> > Maximum depths, you mean?  I know of no use case for it.
> 
> Not maximum depth but the exact depth for a given lexical variable in
> the case of closures.

Ah.  Well, there is already supposed to be a variant on find_lex that
takes a starting depth, and in the closure-efficiency case the
starting depth will always be the final depth, so that use case is
taken care of (or will be, once two-arg find_lex is available).

> > > 5. Thinking about closure support vs. outer support - the difference
> > > and the need for both mechanisms is not clear to me.
> >
> > Could you unpack this, please?
> 
> Well, using :outer allows the look up algorithm to walk through
> enclosing lexical scopes ($sub = $sub.outer). In the case of closures
> the LexEnv is populated with the enclosing LexPads which I assume come
> from enclosing lexical scopes, which allows the the look up to do the
> same thing, no? I must be missing something here.

What you're missing is that without the :outer information, Parrot
wouldn't be able to decide *which* LexPads *should* be searched,
either now (find_lex w/o LexEnv) or later (newclosure -> LexEnv).
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Packfile writing bug

[Leopold Toetsch]

On Nov 30, 2005, at 18:04, Peter Sinnott wrote:


I was refering to the bug that said :

"Also label fixup handling is different so just don't compile
PIR files to PASM except for debugging"


That is a bug related to printing PIR -> PASM and compiling the output 
(which is still avtive, but unchecked).

The decribed problem is compiling PIR -> PBC and running that code.


and wondering if whatever caused pir->pasm->execute pasm
to not always work also caused pir->pbc->execute pbc to not always
work.


label name mangling, but it maybe already resolved by the recent 
changes.


leo

Re: pdd03 (calling conventions) revised; get_params vs. READONLY

[Chip Salzenberg]

On Wed, Nov 30, 2005 at 10:57:26AM -0800, Jonathan Sillito wrote:
> What is the status of the todo's mentioned in the BUGS section, who
> is working on these -- I am looking for a place to jump in. Also
> what is the status of the exception subsystem you mentioned?

All those TODOs are for design, which is hard to delegate.

> I guess one more todo I could take on is the add the use of the
> set_* and get_* ops to examples/subs. A short example in the pdd
> might be helpful too.

Examples are very welcome.  Just make sure to mark all direct usage of
the get/set calling convention opcodes as being not for human
consumption.  PIR macros like .param are the way to go.  "PIR is for
humans.  Pasm is for silicon-based life forms." - me
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd20 questions

[Jonathan Sillito]

On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
>
> What you're missing is that without the :outer information, Parrot
> wouldn't be able to decide *which* LexPads *should* be searched,
> either now (find_lex w/o LexEnv) or later (newclosure -> LexEnv).

Right and I see that this is consistent with the closure creation
section (which is more clear now).

Thanks,
Jonathan

Re: pdd03 and Overflow/Underflow - r10269

[Leopold Toetsch]

On Nov 30, 2005, at 22:08, Chip Salzenberg wrote:


On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote:

At any rate, I found and fixed the two PGE subs that weren't declaring
their (unused) parameters.  All p6rules tests now appear to pass in
r10278 with .PARROT_ERRORS_PARAM_COUNT_FLAG enabled.


Excellent.

Leo, would you be so kind as to rescind the parameter passing error
flags, and make mismatches always throw?  Unless/until we have :last,
users can use :slurpy on an unused register to mean "extra params OK".


While strict argument checking is and was always in the pdd03, it was 
not enforced and is only checkable since today. Therefore I'd like to 
keep current settings until after the release.


This is a serious change in behavior of existing code, which I'd like 
to postpone a bit.


leo

Re: pdd03 and Overflow/Underflow - r10269

[Chip Salzenberg]

On Thu, Dec 01, 2005 at 01:45:49AM +0100, Leopold Toetsch wrote:
> While strict argument checking is and was always in the pdd03, it was 
> not enforced and is only checkable since today. Therefore I'd like to 
> keep current settings until after the release.

Works for me.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: pdd03 and Overflow/Underflow - r10269

[Leopold Toetsch]

On Nov 30, 2005, at 22:16, Chip Salzenberg wrote:


Say, I just noticed this:

On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:

   .sub foo
  push_eh handler
  get_params '(0)', $P0# no .params yet - sorry


I remember at one point that get_params had to be the first opcode in
the sub.  I didn't like that, but I didn't know you'd fixed it.  Are
there any remaining limitations on the placement of the pdd03 opcodes?


One small and not tested item is the placement of C in 
subroutines called via tailcall*. But yes, there was a limitation that 
C has to be the first opcode of a subroutine, which is 
already lifted vastly, as that opcode is now pulling arguments from the 
caller (before the 'invoke' did push args to the sub). It could be that 
(for tailcalled subs) above sequence or just get_params is ok. For 
other subs there are no limitations, but, as you don't know if the sub 
is being tailcalled 


This limitation did prevent local exception handler - like above - to 
be created and is now gone.


I'm still trying to consolidate all the calling conventions stuff, e.g. 
which of these opcode are mandandatory for 'void' calls/returns. If a 
'get_params' opcode is always needed, even with empty arguments, above 
restriction related to tailcalls is also gone.


The source comment is just related to the C<.params> syntax, which is 
strictly bound to the ".sub" due to imcc.y magic (or mis-magic) and 
should be easily fixable now since stack-calling .param can't interfer 
anymore.


leo

Re: This week's summary

[Matt Fowles]

Piers~

On 11/30/05, The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote:
>
> So, I hopped into a taxi (and I use the word hopped advisedly) and
> repaired straightway to King's Cross and thence home to Gateshead, where
> my discomfort was somewhat ameliorated by the distraction of preparing
> this week's summary. I hope to be writing next week's summary as well
> because the week after I'll be moving house and don't quite know when
> I'll have my bandwidth back.

That sounds fine to me.  After next weeks I will start writing weekly
summaries until you send me an email saying you are ready to resume. 
Don't hurry on my account; I know moving is a pain.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary