avar's Journal http://use.perl.org/~avar/journal/ avar's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:41:52+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 avar's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~avar/journal/ The CL backend for the kp6 Perl 6 compiler making headway http://use.perl.org/~avar/journal/34699?from=rss <p>The Common Lisp backend for KindaPerl6 has been making a lot of progress since <a href="http://use.perl.org/~avar/journal/34522">I last wrote about it</a>.</p><p> We now have working variables, subroutines, lexicals (and closures), methods and other nice stuff. The full report is <a href="http://pugs.blogs.com/pugs/2007/10/kindaperl6-comm.html"> on the pugs blog</a>. </p> avar 2007-10-17T03:10:04+00:00 perl6 Perl 6 to machine code via Common Lisp and sbcl http://use.perl.org/~avar/journal/34522?from=rss <p>Aankhen, fglock and me have recently been working on a Common Lisp emitter for KindaPerl6. KindaPerl6 is a self-compiling compiler written in a subset of Perl 6 with support for multiple emitter backends. Up until now it has been running on the Perl 5 backend but now the Common Lisp backend is getting up to speed.</p><p>Hello world is about the only thing the CL backend is currently compiling, but it's doing so quite impressively already. I've <a href="http://pugs.blogs.com/pugs/2007/08/playing-with-th.html?cid=83743157#comment-83743157">posted an update</a> to a recent thread on pugs.blogs.com that shows how fast Perl 6 to machine code via sbcl is doing compared to the kp6 perl5 backend and the parrot nqp compiler.</p><p>Common Lisp has <a href="http://www.cliki.net/Common%20Lisp%20implementation">other implementations</a> you could do some interesting stuff with, for instance you could run the same program under <a href="http://common-lisp.net/project/movitz/">movitz</a> "on the metal". If someone wanted to implement an operating system in Perl now would be a good time to start:)</p> avar 2007-09-23T00:23:52+00:00 perl6 split // will be around 3x as fast in 5.10 http://use.perl.org/~avar/journal/34077?from=rss After a recent <a href="http://public.activestate.com/cgi-bin/perlbrowse/p/31693">patch of mine</a> to blead <code>split<nobr> <wbr></nobr>//</code> is around three times as faster than it was, it's even faster than unpack! I'll be giving a <a href="http://search.cpan.org/dist/Talk-NothingIsFaster510/">lightning talk on this</a> (click the "slides/index.html" link) at YAPC::EU 2007 if the conference organizers will let me. avar 2007-08-10T22:58:27+00:00 newsnews Partly-compatable regular expressions http://use.perl.org/~avar/journal/33585?from=rss <tt>Since I finished my changes to what will become the pluggable regex<br>API in perl 5.10 I've been working on writing re::engines again, first<br>on Plan 9 and then on finishing PCRE which audrey and yves started<br>(but didn't quite finish).<br><br>I based the new PCRE wrapper on the Plan 9 and upgraded the underlying<br>PCRE library to 7.2, and aside from a bug in how split is handled it<br>works for most of the cases where the Perl engine does.<br><br>Having wrapped PCRE running Perl's own regex tests under PCRE becomes<br>really easy. There are almost 1300 test for the regex syntax in<br>t/op/regex.t in perl core. Running these under re::engine::PCRE<br>reveals the following incompatibilities (and some bugs) between it and<br>Perl:<br><br>(?{}) and (??{}) tests fail (obviously). Getting at least (?{}) to<br>work might be possible with pcre's callout mechanims but I haven't<br>looked closely at that.<br><br>A few tests such as "bbbbXcXaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" =~<br>/.X(.+)+X/ fail because PCRE recurses away and runs into its internal<br>MATCH_LIMIT while recursing. Using pcre_dfa_exec() instead of<br>pcre_exec() yields a match but the DFA routine has different matching<br>semantics.<br><br>One test fails because PCRE treats [a-[:digit:]] as an invalid range<br>while Perl takes it to mean a character class matching 'a', '-' or a<br>[:digit:]. Perl is probably being too permissive in this case.<br><br>"aba" =~<nobr> <wbr></nobr>/^(a(b)?)+$/; say "$1-$2" will yield "a-b" under PCRE but<br>"a-" under Perl. That is, PCRE eats the inner (b) while perl goes with<br>the outer +. Both match the entire string.<br><br>Perl accepts curly modifiers on (?!) e.g.<nobr> <wbr></nobr>/foo(?!bar){2}/ but PCRE<br>doesn't. I couldn't get Perl to do anything useful with that<br>though.<nobr> <wbr></nobr>/foo(?!bar{2})/ works in both engines and doesn't match "foo"<br>followed by "barbar".<br><br>PCRE does not match &lt;&lt;!&gt;!&gt;!&gt;&gt;&lt;&gt;&gt;!&gt;!&gt;!&gt; against<br>^(&lt;(?:[^&lt;&gt;]+|(?3)|(?1))*&gt;)()(!&gt;!&gt;!&gt;)$ but Perl does. I haven't looked<br>into why.<br><br>PCRE does not support (*FAIL) and (*F) which cause the pattern to<br>fail, nor does it support (*ACCEPT).<br><br>Three tests try to match \x{85} against \R in an UTF-8 upgraded string<br>("\305\205") in a pattern that wasn't compiled with PCRE_UTF8. This<br>isn't a PCRE issue but an API usage problem in re::engine::PCRE, the<br>best solution is probably to upgrade all patterns and strings to<br>UTF-8 before calling pcre_compile/pcre_exec.<br><br>PCRE accepts numeric keynames such as ^(?'0'ook)$, ^(?&lt;0&gt;ook)$,<br>^(?&lt;1a&gt;ook)$. These all match the literal string "ook" and set up the<br>named capture "0" or "1a". Perl does not currently accept named<br>buffers that start with a number.<br><br>re::engine::PCRE doesn't support multiple named match buffers under<br>the same name while Perl does. At first I thought this was a PCRE<br>limitation but it turns out that I just didn't know about the<br>PCRE_DUPNAMES option:)<br><br>So aside from inline eval re::engine::PCRE is pretty much a drop-in<br>replacement for Perl's engine. And perhaps more significantly PCRE's<br>compatability can now be tested (and errors fixed) by running it<br>against Perl's own test suite.<br><br>To run Perl's tests on PCRE get blead and re::engine::PCRE 0.10<br>(coming to a CPAN near you), build it and run:<br><br>&nbsp; &nbsp; perl5.9.5 -Mblib t/perl/regexp.t<br><br>By default it skips the failing tests, these can currently be enabled<br>by commenting out line 86 in regexp.t:<br><br>&nbsp; &nbsp; @pcre_fail{@pcre_fail} = ();</tt> avar 2007-06-23T04:49:15+00:00 journal