[perl #48645] [CAGE] Make PMCs depend on Parrot::Pmc2c::* Modules

[via RT]

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


If you modify one of the Perl modules that turns .pmc files into .c files, 
then run make again, nothing happens.  The .pmc rules should each have a 
dependency on the appropriate .pm file.

This task requires a minor amount of Perl knowledge and some Makefile 
knowledge.  It should take less than an hour to complete.

[svn:parrot-pdd] r23932 - trunk/docs/pdds

[allison]

Author: allison
Date: Sat Dec 15 05:00:55 2007
New Revision: 23932

Modified:
   trunk/docs/pdds/pdd00_pdd.pod

Log:
[pdd] Clarify on the kind of content expected in PDDs.


Modified: trunk/docs/pdds/pdd00_pdd.pod
==
--- trunk/docs/pdds/pdd00_pdd.pod   (original)
+++ trunk/docs/pdds/pdd00_pdd.pod   Sat Dec 15 05:00:55 2007
@@ -46,14 +46,13 @@
 
 =back
 
-PDDS B discuss the implementation details or trade-offs, unless
-they absolutely have to.  Such implementation documentation should go in the
-relevant F file.  On the other hand, PDDs B document
-design trade-offs, i.e. the paths not chosen.
-
-These guidelines may seem fuzzy.  The line between "design" and
-"implementation" is a murky one.  Still, please try to adhere to this design
-for Parrot design documentation.  How you implement it is up to you.  :-)
+PDDs don't generally discuss the implementation details.  Low-level
+implementation documentation, the maintainer's guides, should go in the
+relevant F file.
+
+PDDs may document design trade-offs, i.e. the paths not chosen. In many cases
+they don't, just to keep the PDDs relatively short and readable. The history
+of Parrot's design is retrievable from the source repository.
 
 =head1 IMPLEMENTATION
 

on non-pdd documentation

[Klaas-Jan Stol]

this morning pdd00 was updated by Allison about what should and what should
not go into PDDs.

>From that document:

PDDs don't generally discuss the implementation details.  Low-level
implementation documentation, the maintainer's guides, should go in the
relevant F file.

First of all, I certainly agree with this POV (even though I myself tend to
put in details in stuff that i update, for instance PDD19. The thing is, I
don't have a better solution where to store these details. I could leave
them out, but then the info is lost except for people who knew this stuff
already. Newcomers are certainly not included.).

Indeed, docs/dev/ contains several documents about implementation details.
However, docs/dev doesn't seem to be much structured yet. Moreover, docs/
also contains docs with impl. details. (should the go intodocs/dev/?)
Of course, it is a good thing to have docs at all, but IMHO, it would be a
good thing to have more clarity or a standard way for organizing this, just
as PDDs are organized well.

Often, when looking for docs on something, it's not entirely clear where one
must look; at least to me. I can imagine for new people this might be the
case een more.
I'm not criticizing the current state, and I certainly don't want to take
too much time that otherwise could be spent on features; I guess I don't
have a better solution handy, but  I merely want to mention this and see how
other people feel about this, and maybe trigger some discussion on how to
manage documentation properly.

Just some thoughts.

kjs

[perl #48657] [Bug][Lua] Recent changes broke languages/lua

[Patrick R. Michaud via RT]

On Sat Dec 15 05:30:57 2007, bernhard wrote:
> ...
> 
> The other problem is that the method 'ostgrammar' has been removed 
> from PCT::HLLCompiler.
> IMHO this should be fixed with porting languages/lua from using 
> 'PAST-pm' to using the shiny new
> PCT::PAST.

Yes, I didn't quite expect anyone to be using PCT::HLLCompiler with
PAST-pm, or supplying their own PAST->POST transformation.

If we need to put the ostgrammar back into the HLLCompiler, we can do
that.  Either that or Lua can subclass PCT::HLLCompiler to provide the
ostgrammar transformation.  Let me know if help is needed for this.

Another approach would be to subclass PAST::Compiler to provide the
additional Lua-specific transformations that don't exist in the current
PAST compiler.  This would be interesting and worthwhile in a number of
respects, so we could verify that the PAST implementation is indeed
extensible to support language-specific needs.

Pm

Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua

[Allison Randal]

Patrick R. Michaud via RT wrote:


Yes, I didn't quite expect anyone to be using PCT::HLLCompiler with
PAST-pm, or supplying their own PAST->POST transformation.

If we need to put the ostgrammar back into the HLLCompiler, we can do
that.  


Supplying your own PAST->POST transformation should at least be an 
option. HLLCompiler is useful for all HLLs, even ones that don't use 
PGE, NQP, PAST, or POST at all in their implementation.


Allison

Re: on non-pdd documentation

[Allison Randal]

Klaas-Jan Stol wrote:


First of all, I certainly agree with this POV (even though I myself tend to
put in details in stuff that i update, for instance PDD19. The thing is, I
don't have a better solution where to store these details. I could leave
them out, but then the info is lost except for people who knew this stuff
already. Newcomers are certainly not included.).


As an example, I'd say PDD 19 should have the level of detail needed to 
create an implementation of PIR, but shouldn't outline all the guts of 
the internals of IMCC. (Especially since that level of detail would be 
entirely irrelevant to PIRC, and the PGE-based PIR parser.) It's not a 
hard rule, just a general guideline.



Indeed, docs/dev/ contains several documents about implementation details.
However, docs/dev doesn't seem to be much structured yet.


Agreed, it's a mess. The top-level docs directory is also a mess. At 
least docs/project is sane.



Moreover, docs/
also contains docs with impl. details. (should the go into docs/dev/?)


Yes. Or be merged into the relevant PDD and deleted.


Of course, it is a good thing to have docs at all, but IMHO, it would be a
good thing to have more clarity or a standard way for organizing this, just
as PDDs are organized well.


Three cheers!


I merely want to mention this and see how
other people feel about this, and maybe trigger some discussion on how to
manage documentation properly.


Some thoughts:

We might create a series of subdirectories in docs/dev that correspond 
to each subsystem. Something like docs/dev/gc, docs/dev/oo, 
docs/dev/imcc, docs/dev/config, docs/dev/build, docs/dev/install, etc. 
Then a README file in docs/dev explaining what people will find in each 
subdir.


It looks like docs/dev/wranglers.pod should be moved to 
docs/project/ticket_wrangler_guide.pod.


Also, we need a check for what's implemented. It looks like 
docs/dev/fhs.pod is a proposal for making Parrot's install directories 
compatible with a standard directory structure, but I suspect it was 
never reviewed, approved, or implemented.


Allison

Re: [perl #48611] [TODO][ROADMAP] roadmap on parrotcode.org outdated

[Will Coleda]

On Dec 14, 2007 5:45 AM, via RT Klaas-Jan Stol
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Klaas-Jan Stol
> # Please include the string:  [perl #48611]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=48611 >
>
>
> it seems the "ROADMAP", found in http://www.parrotcode.org/docs/roadmap.html
>
> is outdated. Is this page still useful?

It is due for review +/or scuttling. Feel free to add this ticket # to
the document warning of staleness.

-- 
Will "Coke" Coleda

Re: Status of docs/embed.pod and Parrot::Embed?

[Will Coleda]

On Dec 10, 2007 2:44 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Tim Bunce wrote:
> >
> > p.s. How do I get a commit bit? Or should I just post patches for now?
>
> Start with patches.
>
> - Mail/fax in a contribution agreement.
>  (I thought we
> had one for you for Perl 5, but apparently not.)
>
> - Committers are voted in by the core dev team, based on the sanity of
> prior contributions. You've been contributing since at least 2003 (first
> post I found), if not earlier, which gives you a longer history than our
> average new committer. :)

And with the paperwork out of the way, I'd like to congratulate Tim
and welcome him aboard.

I look forward to getting at least one commit from him into the 0.5.2
release this coming Tuesday! ^_^

-- 
Will "Coke" Coleda

[svn:parrot-pdd] r23923 - trunk/docs/pdds/draft

[kjs]

Author: kjs
Date: Sat Dec 15 03:09:12 2007
New Revision: 23923

Modified:
   trunk/docs/pdds/draft/pdd19_pir.pod

Log:
[pdd19] add deprecation note at .emit/.eom dir'ves


Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Sat Dec 15 03:09:12 2007
@@ -350,11 +350,14 @@
 Define a compilation unit containing PASM code (only opcodes and a limited
 subset of directives). Always paired with C<.eom>.
 
+{{ DEPRECATED. See RT#47846 }}
+
 =item .eom
 
 End a compilation unit containing PASM code. Always paired with
 C<.emit>.
 
+{{ DEPRECATED. See RT#47846 }}
 
 =item #line  
 

NCI PMC comments

[Jonathan Worthington]

Hi,

At the top of the NCI PMC, there are these comments:

--
Invoking an NCI function changes some registers according to PDD 3.

The caller has to preserve registers if needed.
--

Am I right in thinking that's no longer true?

Thanks,

Jonathan

[Release] request for NEWS, PLATFORMS updates

[Jonathan Worthington]

Hi all,

It's fallen to me to do the release this month, and I'm lucky enough to 
get to do the one that falls on Perl's birthday. The rest of the world 
is unlucky enough that, unless I recieve a better suggestion, I'm 
considering naming the release "Happy Birdday", which is about the worst 
pun I've dreamt up in, oh, a few hours.


Onto more serious requests. If you've Done Stuff since the last release, 
please put a note about it in the NEWS file. Updates to PLATFORMS are 
also encouraged and, of course, I'm happy to take and apply them in 
patch form from anyone without a commit bit.


From now, please try and avoid checking anything in that has a high 
probability of breaking stuff; the releases are all that some people see 
of Parrot, so it's good if they can be reasonably stable and working.


Thanks for your help in making the next release happen!

Take care,

Jonathan

[svn:parrot-pdd] r23918 - trunk/docs/pdds/draft

[kjs]

Author: kjs
Date: Sat Dec 15 02:11:50 2007
New Revision: 23918

Modified:
   trunk/docs/pdds/draft/pdd19_pir.pod

Log:
[pdd19] add something about unique ids for macro exapnsions for unique 
labels.locals. removed the comment suggesting this. imcc currently supports the 
labels; locals will be done later (compilers/pirc/[new/macro] supports this, 
but is not yet complete)

Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Sat Dec 15 02:11:50 2007
@@ -896,10 +896,10 @@
 to the parser will read as follows:
 
   .sub main
-.local int local__foo__b
+.local int local__foo__b__2
 ...
-local__foo__b = 42
-print local__foo__b
+local__foo__b__2 = 42
+print local__foo__b__2
 
   .end
 
@@ -940,16 +940,14 @@
 This will result in code for the parser as follows:
 
   .sub main
-.local int local__foo__x
-.local int local__bar__x
+.local int local__foo__x__2
+.local int local__bar__x__4
   .end
 
-
-{{ PROPOSAL: should C<.macro_local> also add a random value to the munged name,
-to allow multiple calls to the same macro from within the same compilation
-unit? May not be used often enough to be worth adding it. The same effect can
-be achieved by using a symbolic parameter name for the macro local, it's just
-slightly less convenient.  }}
+Each expansion is associated with a unique number; for labels declared with
+C<.macro_label> and locals declared with C<.macro_local> expansions, this 
+means that multiple expansions of a macro will not result in conflicting
+label or local names.
 
 =head3 Ordinary local variables
 

[perl #48657] [Bug][Lua] Recent changes broke languages/lua

[via RT]

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


Hi,

recent changes have broken Lua.
 From the shared object file for the dynamic ops I got
   undefined symbol: CONST_STRING
This might be fixable by including an appropriate header file.
Reverting r23916 in lib/Parrot/Pmc2c/PMCEmitter.pm also works.


@@ -635,7 +635,7 @@
 foreach my $dynpmc (@$dyn_mmds) {
 next if $dynpmc eq $classname;
 $cout .= <<"EOC";
-int my_enum_class_$dynpmc = pmc_type(interp, 
CONST_STRING(interp, "$dynpmc"));
+int my_enum_class_$dynpmc = pmc_type(interp, 
string_from_literal(interp, "$dynpmc"));
 EOC
 }


The other problem is that the method 'ostgrammar' has been removed from 
PCT::HLLCompiler.
IMHO this should be fixed with porting languages/lua from using 
'PAST-pm' to using the shiny new
PCT::PAST.

Regards,
  Bernhard

Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua

[chromatic]

On Saturday 15 December 2007 05:31:00 Bernhard Schmalhofer wrote:

> recent changes have broken Lua.
>  From the shared object file for the dynamic ops I got
>undefined symbol: CONST_STRING
> This might be fixable by including an appropriate header file.
> Reverting r23916 in lib/Parrot/Pmc2c/PMCEmitter.pm also works.
>
>
> @@ -635,7 +635,7 @@
>  foreach my $dynpmc (@$dyn_mmds) {
>  next if $dynpmc eq $classname;
>  $cout .= <<"EOC";
> -int my_enum_class_$dynpmc = pmc_type(interp,
> CONST_STRING(interp, "$dynpmc"));
> +int my_enum_class_$dynpmc = pmc_type(interp,
> string_from_literal(interp, "$dynpmc"));
>  EOC
>  }

Oops.  That was me.  Go ahead and revert that.  After the next release we can 
consider something better.

-- c

Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua

[Patrick R. Michaud]

On Sat, Dec 15, 2007 at 05:45:56PM +0200, Allison Randal wrote:
> Patrick R. Michaud via RT wrote:
> >
> >Yes, I didn't quite expect anyone to be using PCT::HLLCompiler with
> >PAST-pm, or supplying their own PAST->POST transformation.
> >
> >If we need to put the ostgrammar back into the HLLCompiler, we can do
> >that.  
> 
> Supplying your own PAST->POST transformation should at least be an 
> option. HLLCompiler is useful for all HLLs, even ones that don't use 
> PGE, NQP, PAST, or POST at all in their implementation.

It is possible now.  I've been thinking that the way for someone to 
supply a custom PAST->POST transformation would be any or all of:

1.  Use the addstage(), removestage(), or stages() methods to
change the compiler stage sequence and/or introduce new
or replacement stages for the PAST->POST step.

2.  Subclass the PCT::HLLCompiler class to provide a custom 
'post' method that calls whatever is desired.

3.  Subclass the PAST::Compiler class to provide custom PAST->POST
transformations that might not exist in standard PCT.

Given that this gives us at least three "good" ways to supply
a custom PAST->POST transformation into PCT::HLLCompiler, I didn't
think we really needed a fourth one that is specific to ostgrammars
and TGE.

I'm also thinking that HLLGrammar may evolve slightly so that
each translator can globally register itself with HLLCompilers as
"I know how to transform something of type Foo into another thing
of type Bar".  Then an ostgrammar would simply register itself
as another PAST->POST converter, and a HLLCompiler would have some way of
saying "use the ostgrammar instead of POST::Compiler".

Pm

[perl #48493] [CAGE] Parrot::Configure::Step: Explicitly pass all arguments to all methods

[James Keenan via RT]

I created the 'explicitconf' branch in the repository today to work on this.

Re: [perl #48657] [Bug][Lua] Recent changes broke languages/lua

[Allison Randal]

Patrick R. Michaud wrote:


It is possible now.  I've been thinking that the way for someone to 
supply a custom PAST->POST transformation would be any or all of:


1.  Use the addstage(), removestage(), or stages() methods to
change the compiler stage sequence and/or introduce new
or replacement stages for the PAST->POST step.


Thumbs up on flexibility and ease-of-use. This is perfect.

2.  Subclass the PCT::HLLCompiler class to provide a custom 
'post' method that calls whatever is desired.


3.  Subclass the PAST::Compiler class to provide custom PAST->POST
transformations that might not exist in standard PCT.


I suspect these will rarely be used. That little extra bit of complexity 
is enough to make compiler writers avoid it unless they really need 
extensive customization. Nice to have it when it's needed, though.



Given that this gives us at least three "good" ways to supply
a custom PAST->POST transformation into PCT::HLLCompiler, I didn't
think we really needed a fourth one that is specific to ostgrammars
and TGE.


Agreed. We're not at a stage of development where we need to provide 
extensive backward compatibility with old interfaces. addstage, etc. 
cover the needed feature, so ditch the old interface.



I'm also thinking that HLLGrammar may evolve slightly so that
each translator can globally register itself with HLLCompilers as
"I know how to transform something of type Foo into another thing
of type Bar".  Then an ostgrammar would simply register itself
as another PAST->POST converter, and a HLLCompiler would have some way of
saying "use the ostgrammar instead of POST::Compiler".


That has definite potential.

Allison

[perl #48493] [CAGE] Parrot::Configure::Step: Explicitly pass all arguments to all methods

[James Keenan via RT]

I've worked up the changes needed in r23953 committed to the
'explicitconf' branch.  Because trunk is broken at the moment, and
because the breakage occurred before I spun off this branch, 'make' is
not working in this branch.  So I'm holding off on trunk.

[PATCH] Script to automatically populate a directory in languages/

[Patrick R. Michaud]

While at a meeting today I had a period of time where I couldn't
easily sync with the Parrot repository to work on it, so I hacked
together a small script to automatically populate a new languages/ 
subdirectory with a "standard" compiler tools setup.  The script
is attached.

With this script, one can do:

$ perl tools/dev/mk_language_shell.pl Xyz

The script will automatically create a languages/xyz/
directory with the following files (all customized to the
language being created):

xyz.pir
config/makefiles/root.in
src/parser/grammar.pg
src/parser/actions.pm
src/builtins/say.pir
t/harness
t/00-sanity.t
   
The script also runs the reconfigure step on the directory
to produce a Makefile from config/makefiles/root.in .  So,
after running the above to create a compiler shell for 'Xyz',
one can immediately do:

$ cd languages/xyz
$ make test
../../parrot  
/home/pmichaud/parrot/trunk/runtime/parrot/library/PGE/Perl6Grammar.pbc \
--output=src/gen_grammar.pir \
src/parser/grammar.pg
../../parrot  /home/pmichaud/parrot/trunk/compilers/nqp/nqp.pbc 
--output=src/gen_actions.pir \
--target=pir src/parser/actions.pm
/usr/bin/perl -MExtUtils::Command -e cat src/builtins/say.pir  
>src/gen_builtins.pir
../../parrot  -o xyz.pbc xyz.pir
/usr/bin/perl t/harness
t/00-sanity..ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.06 cusr  0.01 
csys =  0.09 CPU)
Result: PASS
$

After that the language implementor can start customizing the grammar,
actions, etc. for whatever language is being built.

Comments welcomed.  Let me know if/when we want this script added
to tools/dev/ .

Pm

Re: [perl #48677] [BUG] r23917 led to 'make' failure

[Jonathan Worthington]

Hi,

Basically, it appears to me that the failure happens with some versions 
of GCC when you're doing (once you look through the macros):


*d = *s;

Where d and s are PMCs. I can only conclude that the compiler is 
generating all the reads, then all the writes, which of course requires 
sizeof(PMC)/sizeof(void*) registers to do the copy, and then finding it 
can't allocate it when doing the cgoto core, possibly because when 
compiling computed goto it backs out of doing other things it does with 
other runcores that can resolve this issue.


I suspect re-writing it to do a memcpy would solve the problem...anyway, 
sleep calls...


Jonathan

Re: [PATCH] Script to automatically populate a directory in languages/

[chromatic]

On Saturday 15 December 2007 14:58:01 Patrick R. Michaud wrote:

> While at a meeting today I had a period of time where I couldn't
> easily sync with the Parrot repository to work on it, so I hacked
> together a small script to automatically populate a new languages/
> subdirectory with a "standard" compiler tools setup.  The script
> is attached.
>
> With this script, one can do:
>
> $ perl tools/dev/mk_language_shell.pl Xyz
>
> The script will automatically create a languages/xyz/
> directory with the following files (all customized to the
> language being created):
>
> xyz.pir
> config/makefiles/root.in
> src/parser/grammar.pg
> src/parser/actions.pm
> src/builtins/say.pir
> t/harness
> t/00-sanity.t
>
> The script also runs the reconfigure step on the directory
> to produce a Makefile from config/makefiles/root.in .  So,
> after running the above to create a compiler shell for 'Xyz',
> one can immediately do:
>
> $ cd languages/xyz
> $ make test
> ../../parrot 
> /home/pmichaud/parrot/trunk/runtime/parrot/library/PGE/Perl6Grammar.pbc \
> --output=src/gen_grammar.pir \
> src/parser/grammar.pg
> ../../parrot  /home/pmichaud/parrot/trunk/compilers/nqp/nqp.pbc
> --output=src/gen_actions.pir \ --target=pir src/parser/actions.pm
> /usr/bin/perl -MExtUtils::Command -e cat src/builtins/say.pir 
> >src/gen_builtins.pir ../../parrot  -o xyz.pbc xyz.pir
> /usr/bin/perl t/harness
> t/00-sanity..ok
> All tests successful.
> Files=1, Tests=2,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.06 cusr 
> 0.01 csys =  0.09 CPU) Result: PASS
> $
>
> After that the language implementor can start customizing the grammar,
> actions, etc. for whatever language is being built.
>
> Comments welcomed.  Let me know if/when we want this script added
> to tools/dev/ .

Max Mohun wrote something similar after YAPC::NA this year, but I held off on 
it until NQP was complete.  Here's the most recent tarball he produced.  I 
think it's a bit further along, but it's definitely along the same lines.

-- c



make_parrot_compiler.tar.bz2
Description: application/tbz

[perl #48493] [CAGE] Parrot::Configure::Step: Explicitly pass all arguments to all methods

[James Keenan via RT]

For no reason more profound than ease of editing, when I went to require
that each of 6 Parrot::Configure::Step methods be passed $conf
explicitly, I put that argument first.

Which of course makes it look much like a Parrot::Configure method call.
 And since the Parrot::Configure object constructed within
Parrot::Configure::Step is *the* singleton P::C object, that's not
surprising.

So is there any compelling reason why these 6 methods should *not* be
moved into Parrot::Configure.pm?  That would leave P::C::Step as a
location for utility subroutines which do not depend on the P::C object.

Thoughts?

kid51