Re: [perl #59810] [PATCH] store hash seed in parrot_string_t struct
On Sun, Nov 16, 2008 at 06:52:08PM -0800, chromatic wrote: > I'd rather remove the hash seed from the key calculation. Instead, let's use > a global seed (#defined somewhere) as the initial seed, cache the calculated You don't want a constant global seed, else you fall foul of Algorithmic Complexity attacks: http://www.cs.rice.edu/~scrosby/hash/ > Any mathematician is welcome to prove that this makes things worse, however. Scott A Crosby and Dan S Wallach appear to be computer scientists. Will they do? :-) Nicholas Clark
Re: [perl #59810] [PATCH] store hash seed in parrot_string_t struct
Nicholas Clark wrote: On Sun, Nov 16, 2008 at 06:52:08PM -0800, chromatic wrote: I'd rather remove the hash seed from the key calculation. Instead, let's use a global seed (#defined somewhere) as the initial seed, cache the calculated You don't want a constant global seed, else you fall foul of Algorithmic Complexity attacks: http://www.cs.rice.edu/~scrosby/hash/ Any mathematician is welcome to prove that this makes things worse, however. Scott A Crosby and Dan S Wallach appear to be computer scientists. Will they do? :-) Nicholas Clark What about a per-interp seed, set to some random value during Parrot's initialization? This would keep any sharp edges away from users and avoid those charming algorithmic complexity attacks (assuming Parrot_int_rand can find sufficient randomness).
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Sun, 16 Nov 2008, chromatic via RT wrote: > Storable 2.18 required in r32744, which should resolve this issue. But the ultimate problem was that the issue was an unnecessary hurdle. At the time of the bug report, I tried building with Storable-2.12 and with 2.18 and observed *no difference*. That means that Storable-2.13 wasn't really *required* at all. I agree that explicitly requiring 2.18 early on gives a failure with a clear error message right away, which is definitely much better than getting a failure a long time after you've started the process and walked away. It's just that no failure is necessary at all. 2.12 worked just fine for parrot. -- Andy Dougherty [EMAIL PROTECTED]
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Nov 17 14:00:01 2008 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 44 new + 604 open = 648 Created this week: 20 Closed this week: 31 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 60338 [BUG] NCI segfaults with null pcc_params_signature 2 - 3 weeks old 60292 [BUG][MMD] wrong dispatch with LuaString & is_equal 60218 [PATCH] P6object.new_class 'hll' option is ignored 60206 [BUG] [MMD] Segfault in Lua exception handler 60172 segfault in expand_pcc_sub_call 3 - 4 weeks old 4 - 5 weeks old 59978 [TODO] Add SVN revision number of reports to Smolder front page 59968 [BUG] Calling Test::More sub after catching a div by zero exception segfaults 5 - 6 weeks old 59720 [BUG] Parrot doesn't allow two HLLs to have a class of the same name 59696 [TODO] Unimplemented Unicode Functions 6 - 7 weeks old 7 - 8 weeks old 8 - 9 weeks old 58990 [TODO] Design new spec coverage mechanism 58980 [TODO][IMCC] .return in a .begin/end_return will be replaced by .set_return 58978 [TODO][IMCC] replace .result by .get_result 58976 [TODO][IMCC] .arg will be replaced by .set_arg 9 - 10 weeks old 58740 [CAGE] t/configure/*.t and t/steps/*.t: Cleanup test setup/teardown code 10 - 11 weeks old 58672 [TODO] implement method lookup iterators 58670 Parrot_print_backtrace() depends on __USE_GNU 58668 src/exceptions.c exposes brokenness in make cover 58488 crashing parrot when calling create_lexinfo 11 - 12 weeks old 12 - 13 weeks old 58188 [TODO] Parrot_find_encoding_converter 58108 [BUILD] languages/Makefile 'test' target has too many deps 58070 [RFC] Disallow .local declarations in long-style call statement 13 - 14 weeks old 58050 Segfault in "make testr" for t/compilers/imcc/syn/hll.t:2 14 - 15 weeks old 57680 [CAGE] Problems in find_write_record 57678 [CAGE] Poor Man's Deadlock Detection 57676 [CAGE] Check for shared status of STM handle 15 - 16 weeks old 16 - 17 weeks old 57236 [TODO] pbc_to_exe --install pbc1 [pbc2...] 17 - 18 weeks old 18 - 19 weeks old 56782 [TODO] question in getNameForKey in Getopt::Obj 19 - 20 weeks old 56634 [RFC] future direction for config 20 - 21 weeks old 56458 Failure to promote RetContinuation objects --- Overview of Open Issues Platform Severity Tag Lang aix 1abandoned 05005threads 0 Amber 0 All 1fatal 1bounce0 BASIC 0 bsdos 0High 1Bug 111 bc 0 cygwin2low 1compiler 0 befunge 0 cygwin_nt 0medium1configure 3 bf 0 darwin8none 1core 2 cola0 dec_osf 0Normal1dailybuild0 forth 0 dgux 0unknown 0docs 3 jako0 dos 0Wishlist 3duplicate 0 Lisp0 dynixptx 0 install 2 lolcode 0 freebsd 5 library 0 m4 0 generic 0 notabug 0 ook 0 gnu 0 notok 0 perl6 2 HPUX 2 ok0 plot0 irix 0 Patch34 punie 0 irix640 regex 2 pynie 0 Linux 2 sendToCPAN0 python 0 lynxos0 Todo276 ruby0 mac 0 unknown 0 scheme 0 machten 0 utilities 0 tcl 0 macos 0 wontfix 0 urm 0 MacOS X 8Zcode 0 mswin32 2 netbsd1 next 0 openbsd 2 os2 0 os390 0 other 0 powerux 0 qnx 0 riscos0 sco 0 Solaris 7 sunos 1 svr4 0 svr5 0 sysv 0 unicos0 unicosmk 0 unix 0 unknown 0 uts 0 vms 0 VOS 0 Win32 8 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Pa
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
2008/11/17 Andrew Dougherty <[EMAIL PROTECTED]>: > On Sun, 16 Nov 2008, chromatic via RT wrote: > >> Storable 2.18 required in r32744, which should resolve this issue. > > But the ultimate problem was that the issue was an unnecessary hurdle. > At the time of the bug report, I tried building with Storable-2.12 and > with 2.18 and observed *no difference*. That means that Storable-2.13 > wasn't really *required* at all. > > I agree that explicitly requiring 2.18 early on gives a failure with a > clear error message right away, which is definitely much better than > getting a failure a long time after you've started the process and walked > away. It's just that no failure is necessary at all. 2.12 worked just > fine for parrot. 2.12 only works okay for a newer perl > 5.8.6. 5.8.4 fails for sure, and I forgot if it was 5.8.6, which fixed overloading in CORE. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 17 Nov 2008, Reini Urban via RT wrote: > 2008/11/17 Andrew Dougherty <[EMAIL PROTECTED]>: > > On Sun, 16 Nov 2008, chromatic via RT wrote: > > > >> Storable 2.18 required in r32744, which should resolve this issue. > > > > But the ultimate problem was that the issue was an unnecessary hurdle. > > At the time of the bug report, I tried building with Storable-2.12 and > > with 2.18 and observed *no difference*. That means that Storable-2.13 > > wasn't really *required* at all. > > > > I agree that explicitly requiring 2.18 early on gives a failure with a > > clear error message right away, which is definitely much better than > > getting a failure a long time after you've started the process and walked > > away. It's just that no failure is necessary at all. 2.12 worked just > > fine for parrot. > > 2.12 only works okay for a newer perl > 5.8.6. > 5.8.4 fails for sure, and I forgot if it was 5.8.6, which fixed > overloading in CORE. Sigh. No. 5.8.4 does not fail for sure. I tested that explicitly. Just to be sure, I decided to check again. Here is the actual script I just ran (this was on Linux, just in case the patched OpenSolaris version of 5.8.4 included a patch which happened to be relevant.) The output at the end compares the directory trees for parrot built using Storable 2.12 and 2.18. The *only* differences reported are: 1. Different values for PARROT_CONFIG_DATE. 2. Binary files differ. (Expected because of #1 above, as well as time stamps.) 3. The Storable version requirement patch (s/2.18/2.12/) I applied to get parrot to compile with plain 5.8.4. 4. The temp file names used in the test suite There were no other differences. None. Each version fared identically on the test suite. This is what I mean when I say that I tried building with Storable-2.12 and with 2.18 and observed no difference. I am not saying that there are no bugs in the older Storable. Just that version 2.12 worked fine for parrot. #!/bin/sh prefix=/tmp/perl-5.8.4 perl=$prefix/bin/perl rm -rf $prefix bzip2 -d -c perl-5.8.4.tar.bz2 | tar -xf - cd perl-5.8.4 sh Configure -Dprefix=$prefix -des make -j 4 make install cd .. wget http://svn.perl.org/snapshots/parrot/parrot-latest.tar.gz cat > patch-2.12 < test.log 2>&1 cd .. mv parrot parrot-2.12 gzip -d -c Storable-2.18.tar.gz | tar -xf - cd Storable-2.18 $perl Makefile.PL make make install cd .. # Build using Storable 2.18 gzip -d -c parrot-latest.tar.gz | tar -xf - cd parrot $perl Configure.pl make make test > test.log 2>&1 cd .. mv parrot parrot-2.18 diff -r -u parrot-2.12 parrot-2.18 -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 17 Nov 2008, Andrew Dougherty wrote: > On Sun, 16 Nov 2008, chromatic via RT wrote: > > > Storable 2.18 required in r32744, which should resolve this issue. Note, by the way, that perl-5.8.8 only shipped with Storable 2.15. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60528] Rakudo wrongly permits mutation of readonly variables in some cases
[EMAIL PROTECTED] via RT wrote: > I've fixed it in a patch that's about to go in as soon as it smokes; > please can somebody make sure that a regression test goes in for this. test added in (pugs) r23032. I hereby encourage all Rakudo hackers to give tickets to me if they have fixed it, but there are no tests yet (with an appropriate comment, of course). I can't promise to write tests for everything, but the chances are much higher that way. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Monday 17 November 2008 11:07:52 Andrew Dougherty wrote: > Note, by the way, that perl-5.8.8 only shipped with Storable 2.15. Perl 5.8.8 doesn't ship with File::Which either, and we require that too. (We do bundle that in our repository, which is something we shouldn't do and something I thought we didn't do anymore). Here are my assumptions: * anyone building Parrot now can install dependencies (working C compilation environment, potentially a bignum library, some CPAN modules, potentially flex/bison or equivalents) * it's simpler to require a single version of a dependency that we know will work reliably across platforms and other dependency versions than to create and maintain a matrix of platforms, dependencies, and versions to the effect that people who meet the previous assumption sometimes don't have to type 'cpan install Foo'. I realize that requiring people to install Storable 2.18 is somewhat of a headache, but it looks like the type of headache that's much smaller than the headaches of the alternatives. -- c
[perl #60604] closure in grep?
On Mon Nov 17 01:51:40 2008, ihrd wrote:
> Hi!
> I start that message like bug report, but I have doubt.
>
> example:
>
> class A {
> method foo (@a) {
> @a.grep: { say @a }; # just for example, real code not so
pointless
> }
> }
>
> my $o = A.new;
>
> $o.foo(['foo']); # foo
> $o.foo([1, 2]); # foo
># foo
>
> Look like grep curls construct closure.
> Mb it`s all right in perl6?
This is yet-another lexicals bug, the same bug that causes an issue with
'gather' that masak reported in his use.perl post at
http://use.perl.org/~masak/journal/37871 .
So, I'm going to link this as "yet another lexicals bug" that I expect
to be fixed when the lexicals branch is finished.
Thanks!
Pm
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 17 Nov 2008, chromatic wrote: > On Monday 17 November 2008 11:07:52 Andrew Dougherty wrote: > > > Note, by the way, that perl-5.8.8 only shipped with Storable 2.15. > > Perl 5.8.8 doesn't ship with File::Which either, and we require that too. > (We > do bundle that in our repository, which is something we shouldn't do and > something I thought we didn't do anymore). > > Here are my assumptions: > > * anyone building Parrot now can install dependencies (working C compilation > environment, potentially a bignum library, some CPAN modules, potentially > flex/bison or equivalents) Yes, true enough, though of course the bigger the web of dependencies, the potentially more fragile things become, and the higher the barrier to newcomers. (ICU, for example, was quite a bit of a mess at one time, except on a very few platforms where it was well supported.) As usual, a balance is called for. Parrot's current dependencies are quite mild and, in my opinion, don't present a significant barrier. > * it's simpler to require a single version of a dependency that we know will > work reliably across platforms and other dependency versions than to create > and maintain a matrix of platforms, dependencies, and versions [. . . ] Yes, completely agreed. But my point was that I have seen no evidence that 2.12 *didn't* work reliably. The log for revision 31585 only mentions Storable-2.09. Ticket [perl #59600] contains the only vague indication of there being a problem with versions < 2.13, but doesn't say what the problem actually was. It also admits uncertainty about which precise versions might be involved. So I did some testing. As far as I could determine, 5.8.4 + 2.12 worked just fine, so I reported that. When told I was wrong, I rechecked and reported, with enough detail so that it was obvious exactly what I did. > I realize that requiring people to install Storable 2.18 is somewhat of a > headache, but it looks like the type of headache that's much smaller than the > headaches of the alternatives. No, it's not a headache. It's just that, as far as I can tell, it's totally unnecessary. I have so many different versions of perl built and installed already anway that it doesn't really affect me in any significant way. I was just trying to help keep the entry barrier low for others. But I don't really care very much, so I'll stop now. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, Nov 17, 2008 at 01:38:25PM -0800, chromatic wrote: > Here are my assumptions: > > * anyone building Parrot now can install dependencies (working C compilation > environment, potentially a bignum library, some CPAN modules, potentially > flex/bison or equivalents) Personally, I'm fine with upgrading our requirement to Storable-2.18 (or whatever). But I do want to note that until this change was made, I was able to built Parrot in my base Linux distribution (Kubuntu 8.04) without having to install _any_ CPAN modules or even to set up the CPAN installer. Requiring Storable 2.18 changes that for me. So it's not just a question of whether I _can_ do something; it's that I now _must_ do something where before it was optional. Other considerations that come to my mind: - Some (e.g. students) may be in environments where they can build Parrot but might not be able to easily install CPAN modules. It's been a very long time since I've attempted to install a module in my home directory (instead of the system dirs), but ISTR it wasn't trivial. - Some interested in Parrot for languages _other_ than Perl 6 might be put off by having to learn about CPAN and install a CPAN module in order to get Parrot to work. Chromatic mentioned moving to 2.18 last night and at the time I didn't see any problems with it, but I think I mistakenly assumed that my distribution would already be running at least that version. It's only today when I attempted to rebuild on my desktop machine that I discovered there were now additional steps involved for me. And to repeat my first statement: it's perfectly okay with me if we increase the requirement to 2.18 -- I just wanted to add my experience of the results to the discussion. Pm
Re: [perl #60528] Rakudo wrongly permits mutation of readonly variables in some cases
On Mon, Nov 17, 2008 at 10:15:09PM +0100, Moritz Lenz wrote: > I hereby encourage all Rakudo hackers to give tickets to me if they have > fixed it, but there are no tests yet (with an appropriate comment, of > course). I can't promise to write tests for everything, but the chances > are much higher that way. I go further and make this standard policy: We don't close a ticket until there's a test. For now we'll assign "fixed but no test yet" tickets to moritz. It would be nice if the ticket also mentioned where the appropriate test has been placed. Pm
Re: MAIN conflict in S06?
On Fri, Nov 14, 2008 at 09:14:51AM -0800, Larry Wall wrote: > On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote: > : I'm guessing that the statement at S06:2362 is an artifact of > : an earlier draft that didn't have the section on MAIN subroutines, > : but I'm wanting to verify that this is the case (or seek further > : clarification if it isn't). > > That's correct. We could fix it two ways. Either the mainline code > gets a consistent new name, or the outermost scope is redefined to an INIT > if there is a user-defined MAIN. I can argue it both ways. FWIW, I like the consistent new name approach, as it provides a good handle for "outermost block" that might otherwise be missing. Simply making the outermost scope an INIT (I assume anonymous) doesn't really provide that. For now it's sufficient to have the clarification on MAIN...thanks! Pm
Re: [perl #60564] [TODO] Refactor contexts to be PMCs
Patrick R. Michaud via RT wrote: Can (should) we do one or more of the following...? 1. Mark GC as a dependency for this ticket 2. Mark this ticket as "stalled" waiting for GC issues 3. Move this ticket to the new Trac ticket queue This would help remove this from our "active ticket" queue, since we're not likely to make much progress on it until after GC refactors are done. Go with #2 for now. I only submitted the ticket so the patch wouldn't be lost on my laptop. The GC refactor will start in 2 weeks, so the wait won't be terribly long, but it's good to have the status show that this isn't a ticket in need of active work. Allison
[svn:perl6-synopsis] r14606 - doc/trunk/design/syn
Author: larry Date: Mon Nov 17 17:12:39 2008 New Revision: 14606 Modified: doc/trunk/design/syn/S05.pod Log: Refinement to LTM tiebreaking rules so that foo matches before \w\w\w and fo\w matches before f\w\w. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podMon Nov 17 17:12:39 2008 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 8 Oct 2008 + Last Modified: 17 Nov 2008 Number: 5 - Version: 85 + Version: 86 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I rather than "regular @@ -2164,11 +2164,15 @@ that comes first lexically. However, if two alternatives match at the same length, the tie is +broken first by specificity. The alternative that starts with the +longest fixed string wins; that is, an exact match counts as closer +than a match made using character classes. If that doesn't work, the tie broken by one of two methods. If the alternatives are in different grammars, standard MRO (method resolution order) determines which -one to try first. If the alternatives are in the same grammar, the +one to try first. If the alternatives are in the same grammar file, the textually earlier alternative takes precedence. (If a grammar's rules -are defined in more than one file, the results are undefined.) +are defined in more than one file, the order is undefined, and an explicit +assertion must be used to force failure if the wrong one is tried first.) This longest token prefix corresponds roughly to the notion of "token" in other parsing systems that use a lexer, but in the case of Perl
[perl #60622] [BUG] t/pmc/pmc.t failing on Darwin
# New Ticket Created by James Keenan
# Please include the string: [perl #60622]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60622 >
The following test is failing on Darwin/PPC at r32784. It passed on
Linux at the same revision number.
not ok 3 - PMC type check
# Failed test 'PMC type check'
# at t/pmc/pmc.t line 75.
# Exited with error code: [SIGNAL 11]
# Received:
# All names ok.
#
# Expected:
# /All names ok/
#
The relevant code in t/pmc/pmc.t appears to be this:
my $checkTypes;
my %types_we_cant_test
= map { $_ => 1; } (# These require initializers.
qw(Null Iterator Enumerate Ref STMRef SharedRef
ParrotObject ParrotThread
deleg_pmc BigInt LexInfo LexPad Slice Object),
# Instances of these appear to have other types.
qw(PMCProxy Class) );
while ( my ( $type, $id ) = each %pmc_types ) {
next
if $types_we_cant_test{$type};
my $set_ro = ( $type =~ /^Const\w+/ ) ? <
Re: [perl #60622] [BUG] t/pmc/pmc.t failing on Darwin
On Monday 17 November 2008 18:17:30 James Keenan wrote: > The following test is failing on Darwin/PPC at r32784. It passed on > Linux at the same revision number. > > not ok 3 - PMC type check > > # Failed test 'PMC type check' > # at t/pmc/pmc.t line 75. > # Exited with error code: [SIGNAL 11] > # Received: > # All names ok. > # > # Expected: > # /All names ok/ > # All SIGNAL 11s on Darwin need a backtrace. Can you provide one? -- c
Re: [perl #60622] [BUG] t/pmc/pmc.t failing on Darwin
On Monday 17 November 2008 19:10:00 James Keenan via RT wrote: > On Mon Nov 17 18:29:34 2008, [EMAIL PROTECTED] wrote: > > All SIGNAL 11s on Darwin need a backtrace. Can you provide one? > Does this look like the correct file to run a backtrace on? That's the one. > (gdb) run t/pmc/pmc_3.pasm > Starting program: /Users/jimk/work/parrot/parrot t/pmc/pmc_3.pasm > All names ok. > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0xdeadbfcb > 0x01118288 in Parrot_cx_delete_task (interp=0x3106770, task=0x4c1680) at > src/scheduler.c:388 > 388 VTABLE_delete_keyed_int(interp, interp->scheduler, tid); > > > Note that this backtrace starts out very similarly to that provided for > t/pmc/packfile.t in RT 60068. I need to see more, but I think I know what this is. Use the 'bt' command in gdb to show the whole backtrace. Hopefully it includes Parrot_really_destroy(). -- c
t/pmc/nci.t failing (parrot vm panic) on linux / amd64 / ubuntu 8.04
TAP output and system information listed below. not ok 68 - nci_vfff - t_tt parameter # Failed test 'nci_vfff - t_tt parameter' # at t/pmc/nci.t line 2689. # Exited with error code: 131 # Received: # Parrot VM: PANIC: vfff is an unknown signature type. # CAN_BUILD_CALL_FRAMES is disabled, add the signature to src/call_list.txt! # C file src/nci.c, line 7500 # Parrot file (not available), line (not available) # # We highly suggest you notify the Parrot team if you have not been working on # Parrot. Use parrotbug (located in parrot's root directory) or send an # e-mail to [EMAIL PROTECTED] # Include the entire text of this error message and the text of the script that # generated the error. If you've made any modifications to Parrot, please # describe them as well. # # Version : 0.8.0-devel # Configured : Tue Nov 18 00:31:09 2008 GMT # Architecture: nojit # JIT Capable : No # Interp Flags: 0x10 # Exceptions : (missing from core) # # Dumping Core... # Quit # # Expected: # 1 # 1 # 1 # # Looks like you failed 1 test of 68. [EMAIL PROTECTED]:~/code/parrot$ svn info Path: . URL: https://svn.perl.org/parrot/trunk Repository Root: https://svn.perl.org/parrot Repository UUID: d31e2699-5ff4-0310-a27c-f18f2fbe73fe Revision: 32784 Node Kind: directory Schedule: normal Last Changed Author: cotto Last Changed Rev: 32784 Last Changed Date: 2008-11-17 19:28:08 -0500 (Mon, 17 Nov 2008) [EMAIL PROTECTED]:~/code/parrot$ perl -v This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi [EMAIL PROTECTED]:~/code/parrot$ uname -a Linux pegasus 2.6.24-21-generic #1 SMP Tue Oct 21 23:09:30 UTC 2008 x86_64 GNU/Linux --Tim
PGE HLLMapping
I've been thinking a lot about how PGE implements closures. Right
now, the closures are a bit rough -- PGE does heuristic look-ahead to
find the end of the closure, saves off the code as a string, and
compiles it at runtime like an eval. To make the heuristic look-
ahead work, PGE insists that closures must be bound by "{{...}}"
instead of "{...}" as Larry has specified. The problems are 1) you
don't find syntax errors at compile time, 2) you need a cache to keep
the compiler from being re-invoked after every match, 3) PIR is
implemented as a special case.
Patrick has mentioned several times that the proper solution to the
problem is a representation of the high-level language that PGE can
interact with. My thoughts about that HLL mapping:
1) we should invoke the other language's compiler at compile-time and
generate an anonymous PIR .sub
a) a special version of the compiler that just parses a block,
rather than a whole program (for Perl6 for example, I think the
distinction is irrelevant)
b) the returned PIR might have several subs. In this case, the
anonymous one will typically be short and will invoke the others
--> so there should be two return values: the library and the
entry point
2) the other language should be represented as an object which can:
a) parse a block
b) pre-process that block to insert boilerplate (see PIR_closure
in PGE::Perl6Regex today) for the anonymous entry point
I thought about co-opting the PGE :lang adverb, which is currently a
string representing the compreg name. If that were optionally a
PGE::HLLMapping instance, then we could conditionally invoke some of
the behavior described above.
Remaining questions:
1) what's the namespace of the generated code?
2) how do we handle languages where embedded code blocks are not
equivalent to whole programs? Do we subclass the grammar and redefine
TOP to be a statement block?
Chris
Re: [perl #60600] [PATCH] rewrite of ops.t to PIR
Christoph Otto via RT wrote: On Sun Nov 16 19:47:36 2008, stockwellb wrote: rewrite of t/oo/ops.t to PIR. ops.t | 265 -- 1 file changed, 130 insertions(+), 135 deletions(-) In op_get_class_p_p, it looks like you switch from "Ape" to "Monkey" when getting the class from a namespace. I can't picture this causing any problems, but it's a good idea to keep the subs as self-contained as possible. As changing "Monkey" to "Ape" in that sub doesn't cause any failures, is there any reason not to do so? Also, tests should be very explicit about which exception type(s) they're catching. This keeps other incidental exceptions from masking bugs. The first test in t/pmc/ro.t is a good example of what to do. You can find the exception type by acking Parrot for the exception's message. Other than that, the patch looks good. Make those changes and I'll be glad to apply it. Christoph ___ http://lists.parrot.org/mailman/listinfo/parrot-dev RT sanity check: feel free to ignore.
