Onward & Upward: More New Assignments

[Allison Randal]

Another conference, and another opportunity to meet and talk face-to-face.

I'm pleased to announce that Patrick will be taking on the primary 
development and maintenance of TGE. He and I will continue working 
together on the architecture of TGE and rest of the compiler tool suite. 
Patrick needs no introduction of course, but I would like to mention how 
impressed I am at the way he's taken Larry's vision for how Perl 6 
grammars should be and rendered it to solid working code. I know he'll 
do wonderful things for TGE.


Allison

Re: [perl #39988] [BUG] Exceptions + Vtable Methods

[Bob Rogers]

   From: Leopold Toetsch <[EMAIL PROTECTED]>
   Date: Thu, 27 Jul 2006 20:50:18 +0200

   Am Donnerstag, 27. Juli 2006 19:44 schrieb Matt Diephouse:
   > Running this gives:
   >
   >    caught
   >    No exception to pop.

   PIR code running on behalf of a vtable (or MMD) function is implemented by 
   entering a secondary runloop (see src/pmc/delegate.pmc). The C code and the 
   extra runloop is acting as a Continuation barrier . . .

Ouch.

   I've experimented some time ago to get at least exceptions working by 
   rewinding runloops also, but have failed so far.

IIUC, this is not even theoretically possible, at least not without
putting heavy constraints on the code that a secondary runloop can
run [2].  Last night I thought about capturing the identity of the
current runloop in each closure, e.g. by adding a C to C, so that invoking the closure would return to the runloop
in which it was created.  Then it occurred to me that, once the
secondary runloop exited, invoking the continuation would make Parrot
jump off into never-never land.

   Of course, this also affects calling actions (or dynamic-wind thunks,
or whatever we are calling them this week).  As a result, my "Partial
fix to make closures invoke actions" patch of Wednesday is clearly not
the right thing; please consider it withdrawn.

   There's no way to get full Continuations working around such C code 
barriers, 
   except by *not* entering secondary runloops at all for these cases[1]. This 
   could be achieved by (optionally) returning a new PC for all vtable/MMD 
   functions that is, by changing the internal (C) calling conventions of all 
   the PMC code.

   leo

   [1] we can't avoid that for e.g. custom sort functions, but these are
   special enough that we could restrict these.

I see a solution for simpler cases, that might even work for custom sort
functions, though it's certainly not painless.  Here's what I would like
to do for calling actions:

   In order to call back into bytecode, the C code must set up a call
using the original runloop that invokes more C code on exit in order to
resume the stack rewinding.  This can be done with a C function hook in
the continuation.  Stack rewinding would therefore need to be split up
into a number of thunks that do the rewinding magic, running between
episodes of bytecode:

   T1.  The entrypoint (which could be Continuation:invoke) scans down
the dynamic environment looking for an action to run.  If it finds one,
it sets it up to run, calling T2 when it exits.  If not, call T3
directly.

   T2.  After running an action, we need to look for the next action.
If we find it, set it up to run and call T2 again on exit.  Otherwise,
call T3 directly.

   T3.  We have reached the bottom, and can start scanning up, if
necessary, using the same logic.  (Since at present we don't call
actions on the way up, this is a noop for now.)

   T4.  Having finally gotten to the destination environment, resume
execution from the bytecode pointed to by the sub.

   Keeping track of state between thunk calls would be pretty messy.
Unless the state is garbage-collected, it'd be hard not to leak memory
when the rewinding is aborted because the bytecode happens to call some
other continuation.

   Does this sound sane?

   Beyond that, I have no clue how to rescue the delegate, ParrotClass,
and ParrotObject pmclasses.  In principal, this strategy could be
applied to the general case.  But I find it really hard to imagine
rewriting *every* call to a vtable method to allow for the possibility
that it might call into bytecode . . .

-- Bob Rogers
   http://rgrjr.dyndns.org/

[2]  It might be possible for Exception_Handler, being a restricted sort
 of continuation, but I assume that is no longer interesting, as the
 new PDD23 design doesn't use them.

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[chromatic]

On Friday 28 July 2006 10:23, Leopold Toetsch via RT wrote:

> Am Freitag, 28. Juli 2006 18:41 schrieb chromatic:

> > Hm, sort of.  Is there any reason not to call it from Parrot_new() and
> > not make the C API users do it?
>
> Well, when the next (and maybe common) step is:
>
>   pf = Parrot_readbc(interp, sourcefile);
>
> then the creation of the dummy PF structure was in vain. I.e. the dummy is
> only needed for _compile_string and friends.
>
> We could create a new API
>
>   Parrot_new_with_PF(Parrot_Interp parent, const char *pf_name)
>
> or such though, which does both.

I would use this one all the time instead of Parrot_new() then (and I don't 
know why pf_name is necessary; that's just noise that people shouldn't have 
to provide -- why make people pass in "dummy" if they'll always pass 
in "dummy"?).  In general, I don't know *how* users will use the embedded 
Parrot, whether they'll ever load any bytecode or will only ever always 
compile code from strings.

To my mind, instead of having two calls which do almost similar things 
depending on how well you predict code paths, we ought to have a single 
default which does something harmless in the load_bc() case and does 
something necessary in the other case.

-- c

Re: [perl #39997] [PATCH] PGE P5 Test Cleanup

[jerry gay]

On 7/28/06, jerry gay <[EMAIL PROTECTED]> wrote:

thanks for the effort! however, i don't want to apply this patch as it
is. 're_tests' was stolen directly from perl5's test suite. the idea
is that the test data this file contains is
implementation-independent. therefore, if some other crazy person
(besides patrick) wants to implement yet another perl5 regex engine,
they can use the same test data file, and a harness that is particular
to their implementation.

so, i think it's best to keep the information as to which tests are
todo and which are skip out of the test data file. currently, this
information exists in the test harness, 'p5rx.t', as i think this is
the best place to capture it. i'm glad to see you've expanded the pge
p5 tests to the full 900+ tests in the file, and i'll gladly apply a
patch that does this while leaving the 're_tests' file intact.


i forgot to mention something here... patrick has included the todo /
skip markers in the perl6 regex test file, and i don't think they
belong there, either. these should be factored out into the harness,
as well. i have other plans for those tests, like splitting them up
into seperate files, but that's another story.

i think the best way for me to document all this is to write up some
tickets, so i'll be doing that shortly.
~jerry

Re: [perl #39997] [PATCH] PGE P5 Test Cleanup

[jerry gay]

On 7/28/06, via RT David Romano <[EMAIL PROTECTED]> wrote:

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


I've updated the documentation for p5rx.t as well as moved the signifiers for
skipping or todo'ing a file to the appropriate lines in re_tests. I have also
updated p5rx.t to use all (960) tests in re_tests, marking tests as TODO or
SKIP as needed. The sixth column in re_tests is now a description of the
test.


thanks for the effort! however, i don't want to apply this patch as it
is. 're_tests' was stolen directly from perl5's test suite. the idea
is that the test data this file contains is
implementation-independent. therefore, if some other crazy person
(besides patrick) wants to implement yet another perl5 regex engine,
they can use the same test data file, and a harness that is particular
to their implementation.

so, i think it's best to keep the information as to which tests are
todo and which are skip out of the test data file. currently, this
information exists in the test harness, 'p5rx.t', as i think this is
the best place to capture it. i'm glad to see you've expanded the pge
p5 tests to the full 900+ tests in the file, and i'll gladly apply a
patch that does this while leaving the 're_tests' file intact.

while i'm thinking about it, there should be a better way to reflect
todo or skip reason. if you're up for the challenge, it would be nice
to be able to say something like
 my %todo= ( # similar for skip
   'not yet implemented' => qw< 5 12 35 500 >,
   'broken' => qw< 34 63 11 >,
   ...
);
and have something that decorates the subtests appropriately. that's
not a requirement for the resubmission of your existing patch, but an
extra request. if it doesn't get done this time around, it will
eventually ;)

~jerry

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[Leopold Toetsch]

Am Freitag, 28. Juli 2006 18:41 schrieb chromatic:
> Hm, sort of.  Is there any reason not to call it from Parrot_new() and not
> make the C API users do it?

Well, when the next (and maybe common) step is:

  pf = Parrot_readbc(interp, sourcefile);

then the creation of the dummy PF structure was in vain. I.e. the dummy is 
only needed for _compile_string and friends.

We could create a new API

  Parrot_new_with_PF(Parrot_Interp parent, const char *pf_name)

or such though, which does both.

leo

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

[Audrey Tang]

在 2006/7/28 上午 7:54 時，Aaron Crane 寫到：

The motivation for s/environmental/contextual/ is clear: avoiding a  
term
that's already used for something else.  But, on the same grounds,  
I'm not
sure that "contextual" is the right term, and especially not Ccontext>

-- Perl already has contexts, and this isn't one.


The idea is that context is something you pass along in each of your  
calls.  If your function body is a simple call, then it does not  
affect the context; the callee gets the same context as you are getting.


So one can say that "want" is really one of the contextual variables  
that gets reassigned every time a function is called when a  
particular type is expected.


Thanks,
Audrey



PGP.sig
Description: This is a digitally signed message part

[perl #39995] [PATCH] Minor patch for config/gen/makefiles/editor.in failing copying files

[via RT]

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


Hi parrot-team,

in my cygwin environment (at work) 'make vim-install' fails with output:

bash-3.1$ make vim-install
/usr/bin/perl.exe -MExtUtils::Command -e cp pir.vim.in pir.vim
/usr/bin/perl.exe ops2vim.pl ../src/ops/*.ops >> pir.vim
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
/cygdrive/c/Documents and Settings/khull/.vim
/usr/bin/perl.exe -MExtUtils::Command -e cp skeleton.pir
/cygdrive/c/Documents and Settings/khull/.vim
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
/cygdrive/c/Documents and Settings/khull/.vim/syntax
/usr/bin/perl.exe -MExtUtils::Command -e cp pir.vim
/cygdrive/c/Documents and Settings/khull/.vim/syntax
/usr/bin/perl.exe -MExtUtils::Command -e cp pasm.vim
/cygdrive/c/Documents and Settings/khull/.vim/syntax
/usr/bin/perl.exe -MExtUtils::Command -e cp pmc.vim
/cygdrive/c/Documents and Settings/khull/.vim/syntax
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
/cygdrive/c/Documents and Settings/khull/.vim/plugin
/usr/bin/perl.exe -MExtUtils::Command -e cp filetype_parrot.vim
/cygdrive/c/Documents and Settings/khull/.vim/plugin/parrot.vim
Too many arguments at -e line 1
make: *** [vim-install] Error 2

This is because of the spaces in the "Documents and Settings" Directory.
I now have quoted directories in config/gen/makefiles/editor.in for
targets vim-install and vim-uninstall that this will not happen again.

Now output of 'make vim-install' looks like

bash-3.1$ make vim-install
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
"/cygdrive/c/Documents and Settings/khull/.vim"
/usr/bin/perl.exe -MExtUtils::Command -e cp skeleton.pir
"/cygdrive/c/Documents and Settings/khull/.vim"
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
"/cygdrive/c/Documents and Settings/khull/.vim/syntax"
/usr/bin/perl.exe -MExtUtils::Command -e cp pir.vim
"/cygdrive/c/Documents and Settings/khull/.vim/syntax"
/usr/bin/perl.exe -MExtUtils::Command -e cp pasm.vim
"/cygdrive/c/Documents and Settings/khull/.vim/syntax"
/usr/bin/perl.exe -MExtUtils::Command -e cp pmc.vim
"/cygdrive/c/Documents and Settings/khull/.vim/syntax"
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
"/cygdrive/c/Documents and Settings/khull/.vim/plugin"
/usr/bin/perl.exe -MExtUtils::Command -e cp filetype_parrot.vim
"/cygdrive/c/Documents and Settings/khull/.vim/plugin/parrot.vim"
/usr/bin/perl.exe -MExtUtils::Command -e mkpath
"/cygdrive/c/Documents and Settings/khull/.vim/indent"
/usr/bin/perl.exe -MExtUtils::Command -e cp indent_pir.vim
"/cygdrive/c/Documents and Settings/khull/.vim/indent/pir.vim"
bash-3.1$

Regards, 
kiwi (at work)


parrot_editor.in.patch
Description: Binary data

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[chromatic]

On Friday 28 July 2006 07:26, Guest via RT wrote:

> This should be fixed now with r13613.

Hm, sort of.  Is there any reason not to call it from Parrot_new() and not 
make the C API users do it?  I don't really want to require them to 
understand the use of packfiles or pull in parrot/packfile.h either.

(I don't understand the use of returning a packfile from PackFile_new_dummy() 
either; is there a reason it's not void?)

I applied this patch and things still work.

-- c

=== src/embed.c
==
--- src/embed.c(revision 19589)
+++ src/embed.c(local)
@@ -45,7 +45,13 @@
 Parrot_new(Parrot_Interp parent)
 {
 /* interpreter.c:make_interpreter builds a new Parrot_Interp. */
-return make_interpreter(parent, PARROT_NO_FLAGS);
+Parrot_Interp interp;
+struct PackFile *pf;
+
+interp = make_interpreter(parent, PARROT_NO_FLAGS);
+PackFile_new_dummy( interp, "dummy" );
+
+return interp;
 }
 
 extern void Parrot_initialize_core_pmcs(Interp *interp);
 C denotes the return value. Next chars are arguments.
 
 The return value of this function can be void or a pointer type.
=== t/src/extend.t
==
--- t/src/extend.t(revision 19589)
+++ t/src/extend.t(local)
@@ -598,15 +598,12 @@
 STRING * code_type;
 STRING * error;
 STRING * foo_name;
-Parrot_PackFile packfile;
 
 if (!interp) {
 printf( "Hiss\n" );
 return 1;
 }
 
-packfile = PackFile_new_dummy(interp, "dummy");
-
 code_type = const_string( interp, "PIR" );
 retval= Parrot_compile_string( interp, code_type, code, &error );
 

[perl #40002] TGE Refactor / Compiler Tools Object

[via RT]

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


What bullet items will the TGE refactor consist of?

* better command-line arg processor, like getopts, but returning a capture
* optimization levels based on level, group related optimizations which 
may occur during different transform steps
* support for languages other than PIR
* generic PAST/POST nodes for short-circut ands and ors
* basic conditional and case constructs, there exists a common semantic 
for if/else, it should be represented in a common way in PAST
* for and while loop generation
* label management.
* scope management.
 
*38761 *   *[TODO] 
TGE, precompile more *

[EMAIL PROTECTED]
*39831 *   *TGE - 
Needs more diagnostics on failure. 
*

[EMAIL PROTECTED]
*39854 *   *[PATCH] 
adds preamble section to tge grammar to allow for includes and global 
defines *

[EMAIL PROTECTED]
*39897 *   *[PATCH] 
TGE - add basic syntax error 
*

[EMAIL PROTECTED]
*39905 *   *[TODO] 
TGE - line number reporting. 
*

[EMAIL PROTECTED]
*39913 *   *[BUG] 
TGE - Can't use } in the transform definitions. 
*

[EMAIL PROTECTED]

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

[Aaron Crane]

[EMAIL PROTECTED] writes:
> Log:
> Change "env" variables to "context" variables.

> -$+foo   environmental variable
> +$+foo   contextual variable

> -ENV
> +CONTEXT
>  SUPER
>  COMPILING

> -lexical variable must be declared using "C" rather than C to be
> +lexical variable must have the trait "C" to be

I realise this comment is a little late, but it occurred to me on seeing
Audrey's recent blog entry mentioning this change.

The motivation for s/environmental/contextual/ is clear: avoiding a term
that's already used for something else.  But, on the same grounds, I'm not
sure that "contextual" is the right term, and especially not C
-- Perl already has contexts, and this isn't one.

How about "ambient variables" instead?  I believe that captures the same
sense as "environmental".  It's also an adjective, which I think reads more
naturally, especially in declarations:

my $foo is context;
say CONTEXT::<$foo>;

versus

my $foo is ambient;
say AMBIENT::<$foo>;

-- 
Aaron Crane

PGE/TGE and the future.

[Kevin Tew]

I'm seeking information regarding TGE's design goals, aspirations, 
future plans, etc.


I see that Perl6 implements its own version of PAST and POST nodes.
Is it possible to share basic PAST and POST nodes and extend them for 
particular  HLL needs?
I know that different HLLs  share a lot  of the same semantics, they 
also have huge differences.


If there is a common set of goals or objectives for compiler tools that 
Cardinal can contribute to or utilize, I would like to do so.

This is an offer to help build and test the compiler tools. :)

I just want to start a discussion about compiler tools and learn what 
information, I've missed.


Kevin