rurban's Journal rurban'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:32:20+00:00 pudge Technology hourly 1 1970-01-01T00:00+00:00 rurban's Journal B::Debugger breakthrough - perl -d -M=Od=C <p>Finally I got the B Debugger working as I wanted it to work.</p><p>Od - Debug a Perl Compiler backend</p><p>perl -d -MOd=Backend[,OPTIONS]</p><p><code>$ perl -d -MOd=C</code></p><p><code>Od::CODE(0x154c5a0)((eval 9)[lib/]:25):<br>25: &amp;$compilesub();<br>DB 1 s<br>B::C::CODE(0x12c0aa0)(lib/B/<br>3163: return sub { save_main() };<br>DB 1 s<br>B::C::save_main(lib/B/<br>2881: my $warner = $SIG{__WARN__};<br></code></p><p>This module is a debugging replacement to O, the Perl Compiler frontend.</p><p>It delays the start of the B compiler compile function from the CHECK block<br>to the INIT block, so that the debugger can be started there.</p> rurban 2009-12-19T17:30:03+00:00 journal The Perl Compiler B::C is released (again) <p>On December 18, 1987 Larry Wall released Perl 1 to the public. 1995 Malcolm Beattie took the chance to win a laptop and wrote the Perl compiler until 1997, which compiled to bytecode (.plc and<nobr> <wbr></nobr>.pmc) and C, and subseqently to native code via perlcc.</p><p>On Mai 7, 2007 the compiler suite was removed from CORE, and I took the chance to port it to 5.10, fix most of the remaining bugs and improve it.</p><p>I'm happy to announce after two years of work that today, on the Perl birthday, the Perl compiler is released for 5.10 and 5.11, and fixes a lot of bugs for 5.6 and 5.8 also.<br>It is the first public compiler re-release since it was removed from CORE.</p><p>There are still a couple of bugs and limitations, but is actively used and actively maintained and there are a lot of plans to increase performance in subsequent releases.<br>This is the main bugfix and new port release. The Bytecode compiler for 5.10 and higher still has some more bugs, keeping B::C bugfree is the main target for now.</p><p>I haven't tested it against the perl CORE tests yet, just against it's own enhanced testsuite and on a couple of bigger programs.</p><p>See <a href=""></a> and<br><a href=""></a> for more.</p><p>Many thanks to Nick Koston from cPanel to persuade me to continue my work from last year. They are using it in big applications.</p><p>Reini Urban, Dec 18 2009</p> rurban 2009-12-18T14:03:40+00:00 journal B Debugger thoughts <p>I had the convincing idea of a better B::Debugger, so I stood up and began to write Od.</p><p>Like this:<br>==================<br>This module is used as debugging replacement to C, the Perl Compiler frontend.</p><p>Debugging is done in two steps, first you store a optree dump in the CHECK stage into C, or the dumpfile specified with the C option, and the Compiler backend is never called.</p><p>Then you load the dump into the INIT stage and continue.</p><p><code><br> &nbsp; &nbsp; perl -d -MOd=Backend[,OPTIONS] foo.dump<br></code></p><p>Loads the stored optree after the CHECK stage, sets up the PL_main_root to point to the loaded optree dump and starts the debugger as specified via -d.<br>==================</p><p>But than the nasty head of Storable and B appeared. B::OP's are a tree of linked pointers. So I needed a walkoptree which stores all visited OPs into the Storable stream.<br>Like<br><code><br> &nbsp; &nbsp; CHECK {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; eval 'require Storable';<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Storable-&gt;import 'store_fd';<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $fh = open '&gt;', '].$dump.[';<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; my $t = new Od::Tree;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; walkoptree_slow(main_root, 'visit');<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; close $fh;<br> &nbsp; &nbsp; }<br></code></p><p>But then what to do in the 2nd thaw stage?<br>B objects cannot be written to! All pointers are read-only.<br>Storable hooks? Will fail on thaw.<br>Setting up a dummy B package just for debugging makes no sense, as I want to debug the compiler which runs through a real B optree.</p><p>Oh my, so I gave up on this idea.<br>The current B::Debugger just has a simple read-eval op loop, but nothing like perl5db. And I cannot step through the CHECK stage, through a compiler module.</p> rurban 2009-12-10T17:50:08+00:00 journal perl-compiler progress 1.04_24 <p>Together with Nick Koston from cPanel we made big compiler progress today.<br>As I found out, 5.6.2 compiles flawlessly huge modules, just a few optimizations should be added, esp. sharing method name strings, "package::name".<br>So I enabled 5.6 also. Just getting the linker line right might be tricky from platform to platform on 5.6. ExtUtils::Embed is a nightmare on 5.6.</p><p>Some tests failed because all variables in the %main:: stash were not initialized, from the very beginning on, since 1998. We fixed that today, so two failing tests pass now, but we got another failure because on the main stash destruction there is a null pointer free. Should be easy to fix though.</p><p>It's advancing faster than I thought. Just minor bugs are still lurking somewhere.</p> rurban 2009-11-29T22:46:30+00:00 journal illguts-1.10 ready <p>Back in 1998 Gisle Aas prepared a graphical overview of all the major internal perl structures, as described in perlguts.pod</p><p>However this all changed with 5.10, and since nobody else did it and I helps me immensely to work on the compiler, I updated illguts ("illustrated guts") to the current perl state.</p><p>old: <a href=""></a><br>new: <a href=""></a><br>slides: <a href=""></a><br>tardist: <a href=""></a></p> rurban 2009-11-21T21:48:42+00:00 journal B::C (perl-compiler) news <p>perl has a native compiler, it just doesn't work for 5.10 and blead yet. I'm working on it in my rare spare time, but now it's winter time and I was motivated by a company which needs it.</p><p>The new cygwin gcc-4.3 has obviously still some bugs, because the B::Bytecode compiler suddenly smashes the stack, but on other platforms it still works okay.</p><p>I'm working on B::C right now.<br>version 1.04_21 fixed regexp (strange and hard).<br>Today I got xpvmg working (easy),<br>PADLISTs are very broken with DEBUGGING only (strange and hard),<br>and some more minor issues are missing.</p><p>I hope to get it ready end of february. I also have to keep an eye on my broken compiler on my main platform.</p> rurban 2009-11-13T23:23:33+00:00 journal parrot packfile alignment to keep cross-platform portability I thought that having portable parrot bytecode (pbc) is a good idea, similar to portable perl5 bytecode (B::Bytecode). And parrot was designed for bytecode portability. So it should be better than perl5 plc. And it is. <p> Anyway, it does not work since a while. Some random notes for debugging this: </p><p> We support 32-bit and 64-bit architectures, that makes a wordsize (integer) and ptrsize of 4 and 8, and the floats can be 8-byte (double), 12-byte (long double on i386) and 16-byte (long double elsewhere). </p><p> The trouble with portability is besides the required bitshuffling when reading foreign pbc files, the trouble of what to do with deprecated features (new parrot reading old file), and new features (old parrot reading new file). </p><p> And interestingly better architectures require a ptr alignment &gt; 1. Sparc 32-bit requires 4-byte ptr alignment, Sparc 64-bit requires 8-byte ptr alignment. You can reset this with a compiler flag but it is not recommended for performance reasons.</p><p> This hits us when writing code on our simple i386 platform with a ptr alignment of 1 and a wordsize of 4. <br> The 64-bit sparc just does cursor++ (a opcode_t ptr) running through the file. cursor is 8-byte there, 4 byte here. So we have to take care in the writer also to properly align code, because it must be easily readable on the foreign machine also.</p><p> The section I'm tempted to adding to the pdd31_bytecode.pod is:</p><blockquote><div><p>=head4 8-byte ptr_alignment</p><p> We should be aware that some systems such as a Sparc/PPC 64-bit use strict 8-byte ptr_alignment per default, and all (opcode_t*)cursor++ or (opcode_t*)cursor += advances must ensure that the cursor ptr is 8-byte aligned. We enforce 16-byte alignment at the start and end of all segments and for all strings, but not in-between, esp. with 4-byte integers and 4-byte opcode_t pointers. </p><p> Which means that for a 32-bit (4-byte) pbc on a 8-byte ptr_alignment machine the pmc designer should take care that integers and opcode_t pointers appear pairwise in the frozen format, so that the 16-byte padding at the end of a segment already happens on an already 8-byte aligned pointer (xxx0 or xxx8), and not on a 4-byte ptr (xxx4 or xxxc) alignment. Operations on aligned pointers are much faster than on un-aligned pointers. </p></div> </blockquote><p> With #define TRACE_PACKFILE 1 in include/parrot/packfile.h you can enable debugging output for the packfile reader, the parrot utils pbc_dump accept a --debug flag to use this. But you can also use the debugger to check alignment problems. </p><p> There's nice table in the PPC manual which I need often, because when staring at the ALIGN'ed ptr's you have to see errors, which will happen if start reading at the wrong point. Un-aligned.</p><p> <code> Operand Length Addr if aligned (in bits, 0b)<br> Byte 8 bits xxxx any <br> Halfword 2 byte xxx0 even <br> Word 4 byte xx00 0 4 8 c <br> Doubleword 8 byte x000 0 8 <br> Quadword 16 byte 0000 0 <br> </code> So look for any ending hexbyte but 0 and 8 for your ptr's to see 8-byte misalignment, and 0 for proper 16-byte alignment.</p><p> The interesting point, which I first got wrong, is that the ptr alignment (we guarantee 16-byte ptr alignment) is for the cursor stepper cursor++ to advance the ptr in memory not to the next char, but the to next word = opcode_t.</p><p> This is the macro (WRONG), which automates the cursor stepper. To makes things complicates we already copied the contents into memory, so the base address is not 0 but <tt>pf-&gt;src</tt> and the alignment must be guaranteed for all three ptrs involved: the base <tt>pf-&gt;src</tt>, the cursor (current position) and the offset, the relative position in the file, <tt>cursor - pf-&gt;src</tt>.</p><p> <code> #define ALIGN_16(st, cursor) \ <br> (cursor) += ROUND_16((const char *)(cursor) - (const char *)(st))/sizeof (opcode_t) </code> </p><p> cursor += advances the pointer by the alignment calculation in the macro. But this does not do ptr alignment! The ptr must already be properly aligned in terms of the native ptrsize. So on 32-bit (4-byte) there must be 0 4 8 or c as last hexdigit in the cursor and the offset. The padding can only 0, 1, 2 or 3.<br> On 64-bit (8-byte) there must be 0 or 8 as last hexdigit in the cursor and the offset. The padding can only 0 or 1. </p><p> My padding tables for ALIGN_16:</p><p> <code> ptrsize=8 pad <br> 0 0 <br> 8 1 <br> </code> </p><p> <code> ptrsize=4 pad <br> 0 0 <br> 4 1 <br> 8 2 <br> c 3 <br> </code> </p><p> The other problems are simply looking innocent steppers, like this in PF_fetch_string() (WRONG):</p><p> <code> size = ROUND_UP_B(size, wordsize); <br> *((const unsigned char **) (cursor)) += size; </code> or this from PF_fetch_op() (CORRECT):</p><p> <code> o = (pf-&gt;fetch_op)(*((const unsigned char **)stream)); <br> *((const unsigned char **) (stream)) += pf-&gt;header-&gt;wordsize; </code> </p><p> Here we cast the ptrsize stream down to 1 to be able to advance misaligned pointers, but upwards in the directory segment we should be aligned again. And PF_fetch_op() and PF_fetch_integer() only guarantee 4-byte alignment, not 8-byte as needed on 64-bit strict PowerPC.</p><p> Strings are the most potential problem to destroy alignment, because they may be mod 1, mod 2 or mod 3 byte long, any size. But strings are safer because we ensure proper ptrsize alignment for them. 4-byte integers and pointers are more problematic because on 8-byte machine we easily get misalignment in uneven integer or pointer pairs.</p><p> So look for uneven ptrs, also when thaw'ing pmc data. This must also be aligned! </p><p> Did you see catch the error above? No? Me neither, but there is one, and it is hidden in the ROUND_UP_B macro, which is not 32/64-bit proof. It only works on the native platform.</p><p> And don't whine about this stupid machines. They are right, even if its just a 64-bit sparc which is that strict (ptr alignment 8, remember), unaligned code is shorter, but much slower.</p><p> So it's better to catch unaligned data while compiling or even running (as on the sparc), than running slow and misaligned. </p> rurban 2009-02-21T20:14:13+00:00 journal svn cleanup (parrot) <p>From time to time I want a clean svn repo again, esp. for parrot.</p><p>Something like a <tt>make distclean</tt> if that would work in parrot.</p><p>I could delete all files which are not in MANIFEST, but easier is this simple svn hack, <tt> <b>svn-cleanup</b> </tt>:</p><p><code><br>#!/bin/sh<br># remove unknown files<br>svn status|perl -ane'print "$F[1]\n" if<nobr> <wbr></nobr>/^\?/' |\<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xargs rm<br># AND revert modified files. take care!!!<br>for f in $(svn status | \<br> &nbsp; &nbsp; perl -ane 'print "$F[1]\n" if<nobr> <wbr></nobr>/^\M/')<br>do<br> &nbsp; &nbsp; svn revert $f<br>done<br></code></p><p>This deletes all files not in the repo and reverts all my private modifications.</p> rurban 2009-01-03T16:04:06+00:00 journal cygwin parrot-0.8.2-1 released <p>After several months of hacking and testing I updated the cygwin package for parrot-0.8.2, which is equivalent to the pdd30install_stage3 branch.<br>Get it via <a href=""></a><br>See <a href=""></a><br><a href=""></a> and<br><a href=""></a></p><p>And <a href=""></a><br>or<br><a href=""></a><br>for the cygwin specific patches.</p><p>Issues: lua is temp. broken.</p><p>Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 20 January 2009, where all the cygwin patches will be merged into trunk. Until then cygwin is still the only parrot distro which works without the source tree.</p><p>Packaging Details:<br>----- version parrot-0.8.2-1 -----<br>* merged from branches/pdd30install_stage3<br>* perl6 copied manually from installable_perl6</p> rurban 2008-12-29T17:39:32+00:00 parrot yapc08_twincity - Need help with the perl compiler - talk <tt>Bratislava, 2008-11-08 16:05 MET<br><br>=head1 NAME<br><br>Need help with the perl compiler, emit C or JIT, blabla<br><br>=head1 Preparation<br><br>&nbsp; open L&lt;B-C/perloptreeguts.pod&gt; and<br>&nbsp; L&lt;perl-current/pod/perlguts.pod&gt;<br><br>=head1 Contents<br><br>I'll present very briefly about 5% of the internals, will debug<br>some real-life problem and you have enough time to task deeper<br>questions.<br><br>* History<br>* Current Status<br>* Compilation<br>* The op tree<br>* B::Bytecode<br>* B::C<br>* Using the compiler<br>* Debugging a problem<br>* Ideas, pro and contra B<br><br>-----------<br><br>=head1 History<br><br>The "perl compiler" modules B&lt;B::Bytecode&gt;, B&lt;B::C&gt; and B&lt;B::CC&gt;<br>(C&lt;B::C&gt; compiles B to simple C, C&lt;B::CC&gt; to optimized C source)<br><br>written 96-97 by Malcolm Beattie, Oxford.<br><br>in core since Alpha 5, perl5.002<br><br>Out of core since 5.9.5 (5.10)<br><br>Now at CPAN as B::C maintained by me, rurban,<br>at F&lt;; (still as devel)<br><br>--------<br><br>With alpha3 (1997) it could compile almost the<br>whole perl test suite for all 3 compilers.<br><br>With 5.10 it cannot even compile a regexp (due to the 5.10<br>rewrite and SV changes) and its 21 internal tests<br>(due to advanced features since 5.002: AUTOLOAD, our,<nobr> <wbr></nobr>...).<br><br>&nbsp; perl -MO=C,-otest.c<br>&nbsp; &nbsp; =&gt; test.c<br>&nbsp; gcc test.c<br><br>--------<br><br>=head1 Current Status<br><br>5.002 up to 5.8.9 works "ok", most tests pass, but not all.<br><br>For 5.10 properly calling and saving a lexical context needs some<br>help, most likely from eastern hackers. I have best experiences<br>with russians.<br><br>For 5.10/5.11 calling and constructing a regexp for B::C<br>needs help. From demerque in Frankfurt, or someone else who<br>knows how to call PM_SETRE and CALLREGCOMP in XS in 5.10.<br><br>When these two problems are solved, I can release it as<br>B-C-1.05 and replace B::C from 5.8.<br><br>When the testsuite with some advanced tests will pass, we can<br>start using the compiler and bytecode features. Probably put the<br>bytecode stuff back into core, because we need plc/pmc support<br>and the ByteLoader part builtin.<br><br>5.6 and earlier will keep using the core B::C modules,<br>as its internal structures changed too much.<br><br>--------<br><br>=head1 "Compilation"<br><br>perl has an internal compiler, i.e. a parser (perly.y) reads the<br>source lines and compiles it to a so-called op tree, a tree of<br>simple operators (ops), which are internal pp_() functions.<br><br>&nbsp; See or perloptreeguts.pod<br><br>As with XS all internal perl pp_ functions take no arguments,<br>all arguments are expected to be on the "perl stack", which<br>is a special heap area, not the CPU stack. (pp for "push/pop")<br><br>The op tree represents the program code, but a program also needs<br>the data, the SV's, AV's and HV's. The arguments for the ops are<br>typically pointers to those SV's (SVREF) or lexicals (on PADs)<br>or direct SV's.<br><br>perl is not too much functional, so there are seldom pointers to<br>ops used as args to ops, mostly lexicals and SV's.<br>In L&lt;perlguts.pod&gt; you will see the all the used perl data, the<br>internal variables, the SV's, AV's, HV's, but also CV's, GV's,<br>...&nbsp; But you will not learn about the op tree, the structure of<br>the ops.&nbsp; The perl compiler is all about the op tree, the ops.<br><br>When executing a program, perl compiles ("parses and constructs")<br>the optree and then simply runs linearly through the optree (a<br>linear list now) from the beginning to the end.<br><br>In the "perl compiler", the B backend is just the XS<br>representation of the optree as perl objects, you can use perl<br>methods to read from the various OP structs.<br><br>The perl compiler consists of various B modules to convert from<br>those B objects, representing the ops, to bytecode or C code.<br><br>----------<br><br>=head1 The op tree<br><br>See L&lt;perloptreeguts.pod&gt; (in B::C and the perl5 wiki) and<br>L&lt;perlhack.pod&gt;<br><br>Similar to the perl internal variables, the SV's, the B&lt;OP&gt;'s are<br>built as hierarchical C structures, based upon the BASEOP, and<br>then more specialized OPs, for the different number of args and<br>types of operations.<br><br>&nbsp; "$a + $b * $c"<br><br>is compiled to (in C syntax, but really in memory)<br><br>&nbsp; newBINOP(OP_ADD, flags,<br>&nbsp; &nbsp; &nbsp;newSVREF($a),<br>&nbsp; &nbsp; &nbsp;newBINOP(OP_MULTIPLY, flags,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;newSVREF($b),<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;newSVREF($c)<br>&nbsp; &nbsp; &nbsp;)<br>&nbsp; )<br><br>Two BINOP's for ADD and MULTIPLY take two args (BINOP), and of<br>those two args are the op for a SVREF (pointer to the SV for $a,<br>$b and $c) and the OP_MULTIPLY.<br><br>This parse-tree is recursive and looks like nested LISP code.<br><br>The internal compiler (not B::C) runs in three passes over the<br>perl code. The various passes contain also a "peephole"<br>optimizer, which optimizes this recursive op tree and in the end<br>it is ensured that we can linearly run through the tree by simply<br>stepping through the C&lt;op_next&gt; pointers and with lists through<br>the C&lt;op_sibling&gt; pointers.<br><br>The Walker:<br><br>&nbsp; int<br>&nbsp; Perl_runops_standard(pTHX)<br>&nbsp; {<br>&nbsp; &nbsp; dVAR;<br>&nbsp; &nbsp; while ((PL_op = CALL_FPTR(PL_op-&gt;op_ppaddr)(aTHX))) {<br>&nbsp; &nbsp; &nbsp; &nbsp; PERL_ASYNC_CHECK();<br>&nbsp; &nbsp; }<br>&nbsp; &nbsp; TAINT_NOT;<br>&nbsp; &nbsp; return 0;<br>&nbsp; }<br><br>=head1 B::Bytecode<br><br>Generate the optree from a binary<nobr> <wbr></nobr>.plc/.pmc file,<br>platform-compatible.<br><br>CROSS-PLATFORM PORTABILITY<br>For different endian-ness there are ByteLoader converters in effect.<br>Header entry: byteorder.<br>64int - 64all - 32int is portable. Header entry: ivsize<br>ITHREADS are unportable.<br><br>Needs much less opcodes (~100) than perl,<br>all the pp_ functions (~400).<br>Just for every op, all the op flags (the struct fields)<br>and for every sv/av/hv type.<br><br>Assembler and disassembler roundtrips.<br><br>=head1 B::C<br><br>Similar to bytecode it generates the whole optree ("code") and<br>data in memory with XS functions, and then jumps into ENTER<br>via the main walker C&lt;Perl_runops_standard&gt;.<br><br>But it generates C code, which is statically compiled and linked<br>to libperl. Dynamic perl features are still dynamic, but<br>guaranteed static decisions can be optimized. =&gt; L&lt;B::CC&gt;<br><br>=head1 Using the compiler<br><br>&nbsp; perlcc<br><br>&nbsp; t/ (see the<nobr> <wbr></nobr>.plc,<nobr> <wbr></nobr>.asm,<nobr> <wbr></nobr>.disasm files and<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the roundtrips)<br><br>&nbsp; t/ 2<br><br>=head1 Debugging a problem<br><br>See STATUS<br><br>&nbsp; t/ 02<br><br>Debug a failure in the PREGCOMP call<br><br>Expand the preprocessor C macros to find<br>the actual failing calls.<br><br>&nbsp; gcc -E =&gt;<nobr> <wbr></nobr>.cee<br><br>Fix the line number from main() on for the gdb stepper.<br>Our main() is perl_init_aaaa() here.<br><br>Step to the problem and inspect it. gdb b perl_init_aaaa p<br><br>=head1 Ideas<br><br>The B modules can be used the read or change or transform the<br>perl optree - a perl program in the internal representation.<br><br>We might want to convert perl5 to various other formats, such as<br>native code (JIT), perl6 or PIR, but maybe also to java, LISP,<br>scheme, and compile this then to fast native and optimized code.<br><br>Other possible advanced ways are:<br><br>1. B&lt;PPI&gt;, the perl source level parser together with a source<br>filter, which could be used for source level macro trickery.<br><br>2. B&lt;MAD&gt;, compiles the optree externally to XML or YAML, and<br>offline tools can convert these XML to other formats, such as<br>perl6 code.&nbsp; Advantage: This looks awful, but is easily debuggable.<br><br>3. undump() and unexec<br><br>Some cool B modules are L&lt;B::Concise&gt;, L&lt;B::Deparse&gt;, L&lt;B::Lint&gt;,<br>L&lt;B::Generate&gt;.<br><br>And as advanced modules L&lt;Devel::TypeCheck&gt;, L&lt;optimize&gt;,<br>L&lt;optimizer&gt;, L&lt;types&gt;.<br>These are the building blocks for a statically optimized<br>compiler (as B::CC), in contrast to the current slow,<br>dynamic interpreter.<br><br>--<br>rurban<br><br>__END__<br>Local Variables:<br>&nbsp; fill-column:65<br>End:<br></tt> rurban 2008-11-26T11:56:14+00:00 journal oplines - win-win memory AND speed <p>I've already wrote that some time ago, forgot where, probably p5p, but got no responses.<br>Today I tried it again on irc #p5p and ended writing a simple statistic script and the beginning of the OPLINES branch.</p><p>The patch is working but the tests results look irreal. Uploaded to <a href=""></a></p><p>My 1st testscript is poor and fails mostly (<a href=""></a>, but I will fix it and run over more files to get better stats.<br>My 2nd is better:</p><p><code><br>#! perl</code></p><p><code>=pod</code></p><p><code>=head1 NAME</code></p><p><code>oplines - ops per line + nextstate win stats for TRY_OPLINES patch</code></p><p><code>=head1 SYNOPSIS</code></p><p><code> &nbsp; &nbsp; </code></p><p><code>=head1 DESCRIPTION</code></p><p><code>Theory:</code></p><p><code>Move cop_line from COP to BASEOP, and reduce the need for nextstate<br>ops, which will be an overall win in memory and speed for typical<br>undense code, less than 4 ops per line.</code></p><p><code>A cop has 5 ptrs more than a BASEOP, so the memory win will be like<br>following:<br> &nbsp; &nbsp; 4 ops/line avg.<br> &nbsp; &nbsp; 90% nextstate COP win per lines</code></p><p><code>=&gt; on 32bit: 4*4=16 byte per line. for 10k src =&gt; 200-160k=40k memory win.<br> &nbsp; &nbsp; &nbsp; + 4k runtime win (need less nextstate cops)</code></p><p><code> &nbsp; &nbsp; &nbsp; on 64bit you try.</code></p><p><code>The unknown factors:<br> &nbsp; &nbsp; a) typical # of ops per line<br> &nbsp; &nbsp; b) nextstate win:<br> &nbsp; &nbsp; &nbsp; &nbsp; * typical # of nextstate cops per 1000-line file.<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; minus # of really needed nextstate cops (lexcops) per 1000-line file.</code></p><p><code>2008-09-21 21:41:06 rurban</code></p><p><code>=cut</code></p><p><code>use Config;<br>use lib ".";</code></p><p><code>my ($sumfiles, $sumlines, $sumops, $sumnextstates, $sumlexstates);<br>my ($files, $lines, $ops, $nextstates, $lexstates);</code></p><p><code>open PM, "&gt;";<br>while () { print PM "$_"; };<br>close PM;</code></p><p><code>for my $file (@ARGV) {<br> &nbsp; &nbsp; $s = `$^X -c -MB_Stats $file`;<br> &nbsp; &nbsp; my @s = split<nobr> <wbr></nobr>/\t/, $s;<br> &nbsp; &nbsp; if (@s &gt; 4 and $s[0] =~<nobr> <wbr></nobr>/\d+/) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ($files, $lines, $ops, $nextstates, $lexstates) = @s;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumfiles += $files;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumlines += $lines;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumops += $ops;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumnextstates += $nextstates;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumlexstates += $lexstates;<br> &nbsp; &nbsp; }<br>}<br>print "files: $sumfiles\n";<br>print "lines: $sumlines\n";<br>print "ops: $sumops\n";<br>my $opsratio = $sumlines ? $sumops/$sumlines : 0;<br>my $copratio = $sumnextstates/($sumfiles+$sumlexstates);<br>print "ops/line: ",sprintf("%0.2f",$opsratio),"\n";<br>print "cops: ",sprintf("%0.2f%",$copratio), " (lex+filecops=",<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $sumfiles+$sumlexstates," / nextstates=$sumnextstates)\n";<br>my $runtimewin = $sumnextstates - ($sumfiles+$sumlexstates);<br>my $opsize = 3*$Config{ptrsize}+4+$Config{intsize};<br>my $copsize = $opsize + 4*$Config{ptrsize} + 8;<br>my $memwin = ($Config{ptrsize} * $copsize * $runtimewin) # win the cops<br> &nbsp; &nbsp; - ($sumops * $Config{intsize}); # minus the added line_t cop_line<br>print "memory win: $memwin byte (",<br> &nbsp; &nbsp; ($Config{ptrsize} * $copsize * $runtimewin)," - ",($sumops * $Config{intsize}),")\n";<br>print "runtime win: $runtimewin ops ",sprintf("%0.2f%",($runtimewin*100/$sumops))," ($sumnextstates - ",$sumfiles+$sumlexstates,") \n";</code></p><p><code>__DATA__<br>use B::Utils qw(walkallops_simple);<br>use B qw(OPf_PARENS);<br>my ($files, $lines, $ops, $nextstates, $lexstates);</code></p><p><code>sub count_ops {<br> &nbsp; &nbsp; &nbsp; &nbsp; my $op = shift;<br> &nbsp; &nbsp; &nbsp; &nbsp; $ops++; # count also null ops<br> &nbsp; &nbsp; &nbsp; &nbsp; if ($op-&gt;isa('B::COP')) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $nextstates++;<br> &nbsp; &nbsp; &nbsp; &nbsp; $lexstates++ if ($$op and (($op-&gt;flags != 1)<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; or $op-&gt;label));<br> &nbsp; &nbsp; &nbsp; &nbsp; }<br>}</code></p><p><code>CHECK {<br> &nbsp; &nbsp; ($files, $lines, $ops, $nextstates, $lexstates) = (0,0,0,0,0);<br> &nbsp; &nbsp; ($oldfile, $oldlines) = ("",0);<br> &nbsp; &nbsp; walkallops_simple(\&amp;count_ops);<br> &nbsp; &nbsp; $files = scalar keys %INC;<br> &nbsp; &nbsp; for (values %INC) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; open IN, ") { $lines++; }; close IN;<br> &nbsp; &nbsp; }<br> &nbsp; &nbsp; print "$files\t$lines\t$ops\t$nextstates\t$lexstates\n";<br>}<br>1;<br></code></p><p>So how is the practice?</p><p>As it looks like an avg sample has 0.5-2 ops/line (but pod needs to be skipped), and about 100-200 times more pure linecops than really needed cops (block entry, new files). So the win seems to be dramatic (8% speed win for the op traversal). But I have to inspect the cops more firmly now.</p><p><code><nobr> <wbr></nobr>./oplines *.pl<br>files: 245<br>lines: 85756<br>ops: 59263<br>ops/line: 0.69<br>cops: 11.23% (lex+filecops=494 / nextstates=5549)<br>memory win: 652628 byte (889680 - 237052)<br>runtime win: 5055 ops 8.53% (5549 - 494)<br></code></p><p><code><br>$<nobr> <wbr></nobr>./ $(find lib ext -name \*.pm)<br>files: 12051<br>lines: 5042732<br>ops: 6629648<br>ops/line: 1.31<br>cops: 39.15% (lex+filecops=15334 / nextstates=600266)<br>memory win: 76429440 byte (102948032 - 26518592)<br>runtime win: 584932 ops 8.82% (600266 - 15334)<br></code></p><p>IMPLEMENTATION</p><p>The parser emits lots of nextstate cops to track linenumbers: These cops can be omitted and the lines stored in the current op PL_op, not PL_curcop anymore.<br>The parser can be simplified a lot for the PL_curcop cases.<br>Also find_cops() is not needed anymore in most cases, where just the line # is needed, but it is still needed for getting the current filename.</p> rurban 2008-09-21T20:10:57+00:00 journal Some more parrot scripts - fix svn ps <p>A one-liner which fixes wrong svn properties</p><p><code><br>perl t/distro/file_metadata.t 2| \<br> &nbsp; &nbsp; perl -ne'system (substr($_,3)) if<nobr> <wbr></nobr>/^#\s+svn ps<nobr> <wbr></nobr>/'<br></code></p> rurban 2008-09-14T15:35:15+00:00 parrot Some more parrot test scripts - remake <p>remake: (this version for trunk)<br><code><br>#!/bin/sh<br>args=$*<br>if [ "${args:0:3}" = "all" ]; then<br> &nbsp; &nbsp; # make all parrot_utils perl6.exe languages installable test codetest<br> &nbsp; &nbsp; args="all parrot_utils perl6.exe languages installable ${args:3}"<br>fi<br>if test -f Makefile; then<br> &nbsp; &nbsp; if $(grep reconfig Makefile &gt;/dev/null); then<br> &nbsp; &nbsp; &nbsp; &nbsp; make reconfig $args<br> &nbsp; &nbsp; else<br> &nbsp; &nbsp; &nbsp; &nbsp; make clean realclean &amp;&amp; perl &amp;&amp; make $args<br> &nbsp; &nbsp; fi<br>else<br> &nbsp; &nbsp; perl &amp;&amp; make $args<br>fi<br></code></p><p>remake for cygwin070patches, where it is easier</p><p><code><br>#!/bin/sh<br>if test -f Makefile; then<br> &nbsp; &nbsp; make reconfig $*<br>else<br> &nbsp; &nbsp; perl &amp;&amp; make $*<br>fi<br></code></p> rurban 2008-09-14T10:50:28+00:00 journal Some parrot test scripts - testvm <p>testvm:</p><p><code><br>#!/bin/bash<br># Test a parrot branch on some of my remote machines (vm's or whatever)<br># must be started in the root build_dir of the branch</code></p><p><code>declare -a vm_name<br>declare -a vm_dir</code></p><p><code># which branch? trunk cygwin070patches gsoc_pdd09 exceptionmagic<nobr> <wbr></nobr>...<br>base=$(basename `pwd`)</code></p><p><code># define my various vm's by name and dir with the parrot tree<br>n=0<br># freebsd7 with gcc-4.2 and llvm-2.3<br>vm_name[$n]=freebsd<br># on freebsd I test only one branch: trunk or cygwin070patches or whatever<br>vm_dir[$n]=/usr/src/perl/parrot<br>let n+=1<br># define llvm conf_args: cc and link<br>vm_name[$n]=freebsd<br>vm_dir[$n]=/usr/src/perl/parrot<br>vm_conf[$n]="--cc=llvm-gcc --link=llvm-ld"<br>let n+=1<br># on debian 4 I test trunk and cygwin070patches<br># gcc-4.1.2<br>vm_name[$n]=debian<br>vm_dir[$n]=/usr/src/perl/parrot/$base<br>let n+=1<br>#vm_name[$n]=gentoo-vm<br>#vm_dir[$n]=/usr/src/perl/parrot<br>#let n+=1<br>#vm_name[$n]=fedora<br>#vm_dir[$n]=/usr/src/perl/parrot<br>#let n+=1<br>#vm_name[$n]=ubuntu<br>#vm_dir[$n]=/usr/src/perl/parrot<br>#let n+=1<br>#vm_name[$n]=centos<br>#vm_dir[$n]=/usr/src/perl/parrot<br>#let n+=1<br>#vm_name[$n]=solaris<br>#vm_dir[$n]=/usr/src/perl/parrot<br>#let n+=1</code></p><p><code>if [ ! -f ]; then<br> &nbsp; &nbsp; &nbsp; &nbsp; echo "$0 must be run a parrot build_dir. not found"<br> &nbsp; &nbsp; &nbsp; &nbsp; exit<br>fi<br>if [ -f Makefile ]; then<br> &nbsp; &nbsp; &nbsp; &nbsp; make clean realclean<br>fi<br>find -name \*.exe -o -name \*.bak -o -name \*~ -o -name \*.stackdump -delete</code></p><p><code>n=0<br>while [ -n "${vm_name[${n}]}" ]<br>do<br> &nbsp; &nbsp; &nbsp; &nbsp; if [ -z "${1}" -o "${1}" = "${vm_name[${n}]}" ]; then<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; echo "rsync -avzC --delete --exclude=.svn . ${vm_name[${n}]}:${vm_dir[${n}]}/"<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; rsync -avzC --delete --exclude=.svn . "${vm_name[${n}]}:${vm_dir[${n}]}/"</code></p><p><code> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; echo "ssh ${vm_name[${n}]} cd ${vm_dir[${n}]}; perl ${vm_conf[${n}]} &amp;&amp; make all parrot_utils perl6 installable languages smoke smolder_test languages-smoke"<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ssh ${vm_name[${n}]} "cd ${vm_dir[${n}]}; perl &amp;&amp; make all parrot_utils perl6 installable languages smoke smolder_test languages-smoke"<br> &nbsp; &nbsp; &nbsp; &nbsp; fi</code></p><p><code> &nbsp; &nbsp; &nbsp; &nbsp; let n+=1<br>done<br></code></p> rurban 2008-09-14T10:46:55+00:00 parrot More parrot languages - java <p>Working over the <a href=""><nobr>3<wbr></nobr> 0_install.pod?view=markup</a> plan to make parrot and its languages installable (and do a make with an already installed parrot), I fixed and tested all of the included languages. Looking deeper at dotnet, which converts a<nobr> <wbr></nobr>.NET<nobr> <wbr></nobr>.exe or<nobr> <wbr></nobr>.dll assembly to a parrot library (pir or pbc), I saw the similarities to java.<br>See <a href=""></a> for Jonathan Worthington's paper describing it.</p><p>So I thought, why not try to rewrite (i.e. copy &amp; paste + tags-query-replace) dotnet to jvm.</p><p>Both bytecodes look very similar, the<nobr> <wbr></nobr>.NET bytecode has a few extra specialities, both can be converted from the stack-based vm to a register vm via some perl5 SRM compiler, which is currently used in dotnet and WMLScript.</p><p>Sun's Hotspot compiler source which is available at <a href=""></a> shows that Sun took a similar path with the bytecode table description. In the perl5 bytecode compiler we have an opcode table with references to c and perl code for special ops and types (<a href=""></a>.<br>In parrot we have a simple ini-style list of ops, with arguments and return type description in the target format (which is PIR) and some simple source template to expand the intermediate stack and temp. locations. <a href=""><nobr>v<wbr></nobr> iew=markup</a><br>With Hotspot Sun invented an adl format ("Architecture Description Language") to describe the ops. This also has a cost attribute for each op which enables an optimizing compiler, if static or JIT. See "hotspot\src\share\vm\adlc\Doc\Syntax.doc" and<br>"hotspot\src\cpu\i486\vm\"</p><p>With a class2pbc (JVM to Parrot) converter we could use all the existing java libraries out there.<br>However, Jonathan's net2pbc dotnet converter currently works only for about 50% of the<nobr> <wbr></nobr>.NET assemblies.</p><p>Currenly with jvm I am stuck at opcode "iinc" 0x84 which increments the local integer variable on the current thread-local frame within the stack-based vm ("increment an int lexical"). Our SRM "compiler" takes stack arguments and converts it to our registers.<br>However I'm not sure how it deals with stack temporaries, so-called stack frame variables. And besides those stack frame vars the jvm also uses temporary int variables heavily, which are usually stored in registers if possible.</p><p>Note that usually closures and class methods store their lexical vars on the C stack right above its code, so that a return to an uplevel function/method automatically cleans up the stack with its code and vars, which is much faster than the perl5 pad layout, where the lexical vars are kept in seperate arrays.<br>It could be that the java vm keeps its stack frame lexicals on the so-called "C stack" as C and lisp do it, or on the heap as perl5 does it with its PAD arrays.</p> rurban 2008-09-07T09:16:08+00:00 journal cygwin parrot-0.7.0-1 released <p>After several days of hacking and testing I could release the cygwin package for parrot-0.7.0 with a lot of patches:<br>See <a href=""></a></p><p>Problems:<br>The new exception code only affected dotnet, which I fixed with #58176-dotnet-exceptions.patch</p><p>Most problems came from languages which were not included in my huge #56554-make-install-lang.patch yet. make languages installable and add the actions to their makefiles.<br>I finished this treatment now for all langs, just a few are still misbehaving and I gave up on m4, pipp, tcl, pheme and forth.</p><p>I described it at <a href=""></a></p><p>Interesting is</p><p>$ parrot-forth<br>Could not find non-existent sub _config<br>current instr.: ' init' pc 944 (forth.pir:11)<br>called from Sub 'main' pc 1033 (forth.pir:55)</p><p>which looks like that pbc_to_exe already solved the _config bootstrap problem, but fails.</p><p>$ parrot-pipp.exe<br>Parrot VM: Can't stat<nobr> <wbr></nobr>/usr/src/perl/parrot/parrot-0.7.0-1/build/languages/pipp/s<br>rc/common/pipplib.pbc, code 2.<br>Unable to append PBC to the current directory<br>current instr.: 'parrot;Pipp;__onload' pc 55 (src/common/pipp.pir:95)<br>called from Sub 'parrot;Pipp;pipp' pc -1 ((unknown file):-1)</p><p>$ parrot-pheme.exe<br>"load_bytecode" couldn't find file 'compilers/tge/TGE/Rule.pbc'<br>current instr.: 'parrot;TGE;__onload' pc 19 (TGE.pir:94) called from Sub 'parrot;Pheme::AST::Grammar;__onload' pc 6901 (languages/pheme/lib/ASTGrammar.pir:5)<br>called from Sub 'parrot;Pheme::Compiler;main' pc -1 ((unknown file):-1)</p> rurban 2008-08-23T16:56:35+00:00 parrot cygwin parrot-0.7.0-1 is near <p>I had to switch from a simple self-cooked build system to quilt (<a href=""></a>) to manage my yet unapplied parrot patches because they were trampling over each other.<br>I don't want to switch to git yet.</p><p>So, quilt applied says:<br>#57476-pdb-version.patch<br>#57546-tags-xemacs.patch<br>39742-installed-conflict.patch<br>56544-install_files.patch<br>57006-opengl-cyg.patch -p0<br>58034-config_args.patch<br>56554-make-install-lang.patch<br>56998-cygdll_versioning.patch -p0</p><p>quilt series says additionally:<br>56996-fhs-runtime.patch<br>57548-CONDITIONED_LINE_enh.patch<br>51944-README_cygwin.patch</p><p>So the next release will have some of the old patches applied -<br>0.6.4 Locally applied patches:<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #51944] [DOCS] Cygwin Readme<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56562] [PATCH] add cygwin importlib<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56544] [PATCH]<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56558] [PATCH] pdb rename to parrot_pdb<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56998] [TODO] rename cygwin dll to cygparrot.dll<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57006] [PATCH] add cygwin opengl config quirks<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57110] [PATCH] ncurses for cygwin<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57112] [PATCH] postgres for cygwin<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57114] [PATCH] urm RealBin issue<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57296] [TODO] make install -C languages</p><p>but several new ones, which were enhancements of the old way to make parrot build to proper installables.<br>0.7.0 - Locally applied patches:<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #39742] [BUG] installed conflict<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #51944] [DOCS] Cygwin Readme<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56544] [PATCH]<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56998] [PATCH] rename cygwin dll to cygparrot$MAJOR_$MINOR_$PATCH.dll<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #57006] [PATCH] add cygwin opengl config quirks<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56554] [TODO] make install -C languages<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #58034] [TODO] config_args<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [perl #56996] [TODO] FHS runtime paths</p><p>These patches of mine are not stable enough:<br>56996-fhs-runtime.patch<br> &nbsp; &nbsp; Still working on library.c getting the<br> &nbsp; &nbsp; interpreter INTERPINFO_RUNTIME_PREFIX or CONFIG_HASH and check<br> &nbsp; &nbsp; for the new "installed" key if present.<br>57548-CONDITIONED_LINE_enh.patch<br> &nbsp; &nbsp; works fine, but too early. needs some feedback for this.</p><p>I'm also working on a draft/pdd30_install.pod.</p><p>chromatic said, that I should get the contributor license agreement sent to the foundation, but this letter still needs a stamp.</p><p>My current patches are at <a href=""><nobr>p<wbr></nobr> atches</a>, the commit at <a href=""></a></p><p>I have one blocking test: t/pmc/namespace_65.pir which also failed for others, see<br><a href=""></a><br><a href=""></a> and mine at<br><a href=""></a></p> rurban 2008-08-17T18:37:03+00:00 journal cygwin ports and patches also at google code <p>My collection of official and inofficial cygwin package patches and scripts is now also at google code: <a href=""></a></p><p>Browse the cygwin Perl build and patches (a custom build-system):<br><a href=""></a></p><p>Browse the cygwin Parrot patches:<br><a href=""></a></p> rurban 2008-08-01T16:15:07+00:00 journal <p>B::C is now at <a href=""></a></p><p>With full SVN history since I took over,<br>and the current issues in the tracker.</p> rurban 2008-07-28T21:49:11+00:00 journal parrot and perl6 on cygwin <p>The parrot and perl6 packages had been updated for cygwin.</p><p>Packaging was a major struggle because from my limited point of view there are still some major architectural hurdles running a self-hosting rakudo perl6.exe and the languages.<br>The test-suite from within the source directory works just fine. And working within the source directory also.</p><p>It will get problematic when you start to try a make install, which is not yet supported. Now I know why. In parrot we have a global _config hash, just like in the perl5 module<br>But parrot is more self-containing, i.e. perl6.exe already contains this hash in a frozen state.</p><p>And there are even two different binaries: perl6.exe which only works inside the source dir, and installable_perl6.exe which accesses<nobr> <wbr></nobr>/usr/lib/parrot/include/... and not<nobr> <wbr></nobr>/runtime/parrot/include</p><p>The problem is that the runtime subdirs are mapped to<nobr> <wbr></nobr>/usr/lib/parrot, not all required files are installed on make reallyinstall, and the worst,<br>that some installable_* exe files still try to access<nobr> <wbr></nobr>/usr/runtime/parrot/include/config.pir (the global hash which is already linked into the binary), using a non-FHS compliant path (it should be<nobr> <wbr></nobr>/usr/lib/parrot/include/config.pir at least)</p><p>The build system is quite clever linking to a seperate install_config.o for those installables.<br>But some important functions like<nobr> <wbr></nobr>.include or load_bytecode still try to access<nobr> <wbr></nobr>/usr/lib/parrot/include/config.pir even if the hash is already loaded. And _config is only required to get the lib_path, to be able to traverse the dirs. A typical chicken-and-egg bootstrapping problem.</p><p>I wonder how to fix this the easiest way.<br>1. Maybe I just missed some trick and it should work ootb right now.<br>2. check if a a global _config hash exists and use it in load_bytecode and include and avoid loading config.pir in _config() if so.</p><p>This has a API limitation.<br>a. _config() is a function, not a hash, and<br>b. _config has no sideeffects, it just returns a hash into a local $P0 e.g. so you never know how to access the frozen hash at install_config.o.</p><p>If _config would be a global hash, you could just check for it, and avoid loading the file with the definition of _config. Since _config() is a global function I see no major problem changing the API from a global function to a global hash.<br>Maybe that's what interpinfo<nobr> <wbr></nobr>.INTERPINFO_RUNTIME_PREFIX is for. Haven't found the idea behind that yet.</p><p>Note: All this is just needed so that frozen states don't do unnecessary file accesses to files in wrong lib_paths (/usr/runtime/parrot). Once _config is initialized, the lib_path is correct and no wrong stats are done.<br>And runtime/parrot/include is also gone.<br>But this patch is still hardcoded into some libs. BAD!</p><p>A basic module system, like require would also help. Then I would just say<nobr> <wbr></nobr>.require 'config'</p><p>The idea to remove to formerly interpreter global config hash was re-entrancy (as explained by particle on irc). At least it worked before.<br>The current idea is to freeze the sub _config() and not the hash. So when the frozen _config is linked it is already available and find_sub('_config') can be used to check its existance and avoid unnecessary attempts to find 'include/config.pir' in a non-existing lib_path.</p><p>Tickets: <a href=""></a><br><a href=""></a></p><p>There are more major hurdles for installable parrot languages.<br>make install e.g. is missing for the languages also, and make test-installable to test against a installable_$lang.exe without accessing the build_dir, only accessing an already installed parrot.</p><p><a href=""></a> contains some info, but most info is in the cygwin parrot source package, the cygport file and the patches. The source is now online at <a href=""></a></p> rurban 2008-07-27T17:53:13+00:00 parrot pugs installation on cygwin <p>This is how I managed to install latest pugs on <b>cygwin</b>. This is the same as for any platform without existing packages.</p><p>Download and install <b>ghc</b> from <a href=""></a><br> &nbsp; &nbsp; Note that from ghc 6.8 on Pugs will not compile OOTB, you'd need Cabal then.<br>This is a win32 native and goes into "c:/ghc/ghc-6.8.3"</p><p>Create symlinks in our path:<br>$ for f in ln -s<nobr> <wbr></nobr>/cygdrive/c/ghc/ghc-6.8.3/bin/*; do ln -s $f<nobr> <wbr></nobr>/usr/local/bin/; done</p><p>Download and install <b>Cabal</b> required for cabal-install. Cabal-, which comes with ghc-6.8.3, is not new enough. Sigh.<br>Cabal tar.gz packages at <a href=""></a></p><p>wget<br>tar xfz Cabal-<br>cd Cabal-<br>runhaskell<nobr> <wbr></nobr>./Setup.hs configure --ghc<br>runhaskell<nobr> <wbr></nobr>./Setup.hs build<br>runhaskell<nobr> <wbr></nobr>./Setup.hs install<br>cd<nobr> <wbr></nobr>..</p><p># Get zlib and HTTP, two required deps for cabal-install:</p><p>wget<br>tar xfz HTTP-3001.0.4.tar.gz<br>cd HTTP-3001.0.4.tar.gz<br>runhaskell<nobr> <wbr></nobr>./Setup.lhs configure --ghc<br>runhaskell<nobr> <wbr></nobr>./Setup.lhs build<br>runhaskell<nobr> <wbr></nobr>./Setup.lhs install<br>cd<nobr> <wbr></nobr>..</p><p>wget<br>tar xfz zlib-<br>cd zlib-<br>runhaskell<nobr> <wbr></nobr>./Setup.hs configure --ghc<br>runhaskell<nobr> <wbr></nobr>./Setup.hs build<br>runhaskell<nobr> <wbr></nobr>./Setup.hs install<br>cd<nobr> <wbr></nobr>..</p><p># now get cabal-install, which is the haskell version of CPAN.</p><p>wget<nobr>.<wbr></nobr> 5.1.tar.gz<br>tar xfz cabal-install-0.5.1.tar.gz<br>cd cabal-install-0.5.1<br>runhaskell<nobr> <wbr></nobr>./Setup.hs configure --ghc<br>runhaskell<nobr> <wbr></nobr>./Setup.hs build<br>runhaskell<nobr> <wbr></nobr>./Setup.hs install<br>cd<nobr> <wbr></nobr>..</p><p># copy the installed bin\cabal.exe to<nobr> <wbr></nobr>/usr/local/bin/<br>cp<nobr> <wbr></nobr>/cygdrive/c/Program\ Files/Cabal/.../bin/cabal.exe<nobr> <wbr></nobr>/usr/local/bin/<br># and now it's getting easier:</p><p>cabal update<br>cabal install Pugs</p><p># here I get a stupid regex-base-0.93.1 failure<br># ghc version &gt;=6.4 is required but it could not be found.<br># The package locations are registered in C:\ghc\ghc-6.8.3\package.conf</p><p>cabal install -v regex-base<br># verbose. aha, the cached tar.gz is deep there<br>cp 'C:/Doc..../regex-base-0.93.1.tar.gz' .<br>tar xfz regex-base-0.93.1.tar.gz<br>cd regex-base-0.93.1<br>runhaskell<nobr> <wbr></nobr>./Setup.hs configure --ghc<br># =&gt; stupid error<br>joe regex-base.cabal<br># add Build-Type: Simple<br># after Tested-With:<br># Ctrl-k x<br>runhaskell<nobr> <wbr></nobr>./Setup.hs configure --ghc<br>runhaskell<nobr> <wbr></nobr>./Setup.hs build<br>runhaskell<nobr> <wbr></nobr>./Setup.hs install<br>cd<nobr> <wbr></nobr>..</p><p># and continue...<br>cabal install Pugs</p><p># dada!<br>cp 'C:\Program Files\Haskell\bin\pugs.exe'<nobr> <wbr></nobr>/usr/local/bin/</p><p>pugs</p><p> &nbsp; &nbsp; &nbsp; ______<nobr> <wbr></nobr>/\ __ \<br> &nbsp; \ \ \/\ \ __ __ ______ ______ (P)erl 6<br> &nbsp; &nbsp; \ \ __//\ \/\ \/\ __ \/\ ___\ (U)ser's<br> &nbsp; &nbsp; &nbsp; \ \ \/ \ \ \_\ \ \ \/\ \ \___ \ (G)olfing<br> &nbsp; &nbsp; &nbsp; &nbsp; \ \__\ \ \____/\ \____ \/\_____\ (S)ystem<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \/__/ \/___/ \/___/\ \/____/<nobr> <wbr></nobr>/\____/ Version:<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \/___/ Copyright 2005-2008, The Pugs Contributors<br>--------------------------------------------------------------------<br> &nbsp; Web: Email:</p><p>Welcome to Pugs -- Perl6 User's Golfing System<br>Type<nobr> <wbr></nobr>:h for help.</p><p>Loading Prelude... done.<br>pugs&gt;</p> rurban 2008-07-11T14:43:48+00:00 journal cygwin parrot-0.6.3 and perl6 ready for inspection <p>I've finally packaged parrot and its languages (perl6!) for cygwin.<br>icu was the main blocker, but we (Yaakov and me) finally we got that out, so now the fun starts.</p><p>ITP and info at<br><a href=""></a></p><p>It just needs a GTG ("Good to go"), then it will be uploaded.</p><p>The make install step is still in its infancy, the<nobr> <wbr></nobr>.include search patch a bit insane.<br><code><nobr> <wbr></nobr>/usr/runtime/parrot/include<br><nobr> <wbr></nobr>/usr/runtime/parrot<br><nobr> <wbr></nobr>/usr<br><nobr> <wbr></nobr>/usr/lib/parrot/include<br><nobr> <wbr></nobr>/usr/lib/parrot/<br><nobr> <wbr></nobr>.</code></p><p><br>with extensions: <code>""<nobr> <wbr></nobr>.exe<nobr> <wbr></nobr>.lnk<nobr> <wbr></nobr>.exe.lnk<nobr> <wbr></nobr>.past<nobr> <wbr></nobr>.past.exe<nobr> <wbr></nobr>.past.lnk<nobr> <wbr></nobr>.past.exe.lnk<nobr> <wbr></nobr>.pir<nobr> <wbr></nobr>.pir.exe<nobr> <wbr></nobr>.pir.lnk<nobr> <wbr></nobr>.pir.exe.lnk</code></p><p>The<nobr> <wbr></nobr>.exe and<nobr> <wbr></nobr>.lnk stuff is cygwin magic.</p><p>parrot, libparrot0 and libparrot-devel is in debian, freebsd ports, fedora and gentoo.<br>parrot-perl6 in debian at least. parrot-languages is my compressed version of the fedora split,<br>they have for every single language a seperate package.<br>Otherwise the package layout is similar to fedora, debian, gentoo and freebsd.<br>It's still a mess and a make install is not fully supported yet, but we have to start somewhere to get it finished.<br>I just left the docs/examples, the others stripped it.<br>pdb is called parrot_pdb, disassemble is called pbc_disassemble.</p> rurban 2008-07-06T11:24:01+00:00 parrot cygwin upgraded to 5.10 <p>After a busy year cygwin moved from 5.8.8 to 5.10.<br>It was quite an effort to coordinate a lot of dependant packages. Thanks to Yaakov Selkovitz, who had a to wait a few months.<br>And we have now a completely new and sane build system as simple shell scripts.</p><p>But even after testing for about half year, the first official try 5.10.0-4 has a serious error, which never showed up in any testcase. Jan Dubois found it.</p><p>perl -E "say for sort keys %Win32::" is empty.</p><p>cygperl links Win32CORE statically to libperl. Because some libtool packages which link to perl like mod_perl, cannot deal with mixed static + dynamic libs. The single static Win32CORE.a breaks it.</p><p>The problem is that I accidently removed the Config{static_ext} entry somehow in the intermediate step when compiling perl.c. init_Win32CORE() is not called.<br>The final static_ext is good again, because then the ExtUtils::Embed tests or my perl compiler tests would have found it.<br>Oh dear! The Win32 testsuite didn't find it.</p><p>The update to perl5.10.0-5 will have this fixed, but will be based on a current MAINT patchlevel.<br>My patch queue was getting huge, and I almost had to switch to quilt.<br>So I rather test it a bit longer.<br>cpan tests with about 500 packages were good so far.</p> rurban 2008-07-03T08:02:00+00:00 journal B-C-1.04_15 <p>After busy weeks moving house and attending the local film-festival, work started again.</p><p>I've added machinery to support Bytecode portability and maybe across versions also. This will need some opcode version table for older versions.</p><p>Thanks to cpantest I've found and fixed some non-threaded bugs.</p><p>The main feature with this version is the commented disassembler output.</p><p>The main problem was that in the ByteLoader xpv_len is not the length of xpv_pv string. xpv_len also counts the ending \0 byte, but xpv_cur is the correct strlen.<br>So "\\d\000" has length 3, but a strlen of 2.<br>This caused problems on an early 5.10 pregcomp() minlen check, so all regexp tests failed.</p><p>I've also added a maxstring argument to asciiz strconst strings, which are no pascal-like strings, to avoid buffer-overflow attacks with handcrafted<nobr> <wbr></nobr>.pmc files.</p><p>Next I'll attack the pad panics and<br>SIGSEGV in Perl_fbm_instr() = Perl_re_intuit_start() = Perl_pp_subst()<br>Getting the correct re in the PMOP to be accepted by pp_match() is a nightmare.</p> rurban 2008-04-12T11:21:08+00:00 journal compiler updates <p>I've put my current work onto CPAN as developer releases. The perl compiler B-C has the same features and bugs as the official perl-5.8 release versions, just a little bit enhanced, so I could pull out the underscores, but I have to wait for authorization anyway.</p><p>1) <a href=""></a> the perl compiler<br>2) <a href=""></a> the optree debugger<br>3) And the start for a perloptreeguts.pod at<br><a href=""></a></p><p>People complained that the perl internals are so hairy and complicated, and I have to completely disagree. It's just hard to debug at the early parsing/compiler stages. At least we have perl level hooks and don't have to write hooks in C or XS. And the optree debugger helps also. Or it could be that my background is LISP, and parsing, compilation and code transformation within lisp is a non-brainer.</p><p>I was a little bit worried about the lack of GSOC students, so I released incomplete work.</p><p>Missing authorization seems to be my fate anyway. When John Tobey handed me over C::DynaLib, he couldn't give me co-maintainership for the base module C::DynaLib neither, so this is marked as unauthorized also.</p> rurban 2008-03-22T18:56:44+00:00 journal perl compiler B-C-1.04_05 <p>I finally found the disturbing ByteLoader bug.<br>It had nothing to do with my bytecode changes, just the DATA handle reader started too early, because I added the byteorder header.<br>I'm still working on the machinery to debug the compiler, but it is getting better now.<br>The Bytecode backend is almost ready, just some general options (-Ox, -Dx) have to be supported.<br>The C backend produces some simple to fix syntax errors.<br>For the Jit backend I wrote some docs, and for my preferred native Asm backends I have to look for some abstraction.<br>The problem will be how to produce optimized ops from existing ops, and keeping them in sync. Something like stripping common arg headers and footers from the code. Or generating some optimized ops from pp.c automatically.</p><p><a href=""></a></p><p>1.04_05 2008-02-18 rurban<br> &nbsp; &nbsp; &nbsp; &nbsp; * added t/ and t/test*.sh to MANIFEST.<br> &nbsp; &nbsp; &nbsp; &nbsp; * fixed ByteLoader reading from the filter.<br> &nbsp; &nbsp; &nbsp; &nbsp; * fixed -H<nobr> <wbr></nobr>.plc header parsing<br> &nbsp; &nbsp; &nbsp; &nbsp; * updated Bytecode options in NOTES and pod<br> &nbsp; &nbsp; &nbsp; &nbsp; * added -O=Bytecode,-v option</p> rurban 2008-02-18T15:33:42+00:00 journal perl compiler 5.9.5 <p>I was worried about the perl compiler state after parts have been removed from CORE with 5.9.5.<br>Having patched parts of B::Generate and more packages for 5.10, I felt to give B::C and friends a try.</p><p>I also wanted to experiment with the GNU lightning library, which I also evaluate for a clisp bytecode compiler extension (done recently by Yann Nicolas Dauphin in parallel), and for another project of mine. The JIT compiler for clisp is now usable, but slow.</p><p>So I fixed the obvious compiler warnings with the changed structs, and packaged B::C, B::CC, ByteLoader and its helper packages for a forthcoming B-C-1.05 package.</p><p>I also had some thoughts on future optimizations<br>when a native code perl compiler backend is available. This is what JIT lightning does.<br>E.g. type checking and detecting IVonly or PVonly ints or strings, which could be optimized to smaller and faster ops in JIT assembler.<br>Thinking about new B::Asm and B::JIT backends, "PLJC" ByteLoader 4-byte magic header.<br>byterun.c =&gt; jitrun.c</p><p>Current state:<br>1.04_02 2008-01-22 rurban<br> &nbsp; &nbsp; &nbsp; &nbsp; * removed from CORE, now on CPAN.<br> &nbsp; &nbsp; &nbsp; &nbsp; * added byteorder to bytecode header.<br> &nbsp; &nbsp; &nbsp; &nbsp; * added support for 5.10 (NOT YET WORKING!), 5.9.5 not tested.<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; up to 5.8.x already in CORE, so disabled.<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; add back support later, when C/CC is improved or more features<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; are added.<br> &nbsp; &nbsp; &nbsp; &nbsp; * added type hekindex<br> &nbsp; &nbsp; &nbsp; &nbsp; * added c.t and cc.t tests<br> &nbsp; &nbsp; &nbsp; &nbsp; * extended format: added version logic<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to have strictly consecutive indices</p><p>All compile-time failures fixed, but still some run-time failures for bytecode XCV_STASH and PV handling.</p><p></p> rurban 2008-02-02T09:51:42+00:00 journal cygwin perl updated to 5.10.0-2, libwin32 and Win32::GUI <p>The cygwin packages for perl-5.10.0-2 and the cygwin modules perl-libwin32-0.28-1 and perl-Win32-GUI-1.05-2 have been updated. Still experimental until all other cygwin perl modules are also updated to 5.10.</p><p>What changed from 5.10.0-1 to -2?<br>@INC has now no duplicate site_perl and vendor_perl entries which came with the new _stem vars and a proper inc_version_list. Stupid.</p><p>To add<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.8, without the archlib to @INC I patched perl.c to omit the archlib from otherlibdirs. If someone wants the archlib he should add it explictly to otherlibdirs.</p><p>Changed @INC, the include path,<br>from<br> &nbsp; &nbsp; @INC:<nobr> <wbr></nobr>/usr/lib/perl5/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/5.10<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10<br> &nbsp; &nbsp; &nbsp; &nbsp; .<br>to<br> &nbsp; &nbsp; @INC:<nobr> <wbr></nobr>/usr/lib/perl5/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/5.10<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.10<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10/cygwin<nobr> <wbr></nobr>/usr/lib/perl5/vendor_perl/5.10<nobr> <wbr></nobr>/usr/lib/perl5/site_perl/5.8<br> &nbsp; &nbsp; &nbsp; &nbsp; .</p><p>See the cygwin announce:<br> (not yet there)<br>and the vendor patches at<br></p> rurban 2008-01-06T00:52:42+00:00 journal cygwin perl-5.10.0-1 uploaded <p>The cygwin perl packages perl and perl_manpages have<br>been updated in the experimental branch to 5.10.0-1.<br> &nbsp; &nbsp; Click on [Exp]</p><p>Several libraries will follow soon. When all libraries have been updated we can switch from Experimental to Current.</p><p>perl-5.10.0 cygwin notes:</p><p>This release is binary incompatible with the previous 5.8 releases, but<br>compatible to all future 5.10.x releases. That's why we named the main<br>perl DLL<nobr> <wbr></nobr>/bin/cygperl5_10.dll and not cygperl5_10_0.dll.</p><p>The requirements for the special perl link driver ld2 and perlld had<br>been removed.</p><p>Cygwin mount point information is now accessible, esp. text/binary<br>detection.</p><p>Some modules have been added to vendor_perl, but most of the old vendor<br>modules moved to CORE.<br>Included are Bundle::CPAN, CPAN::Reporter, XML::LibXML and several<br>Test modules.<br>Note: Installed modules (e.g. via CPAN) in site_perl have higher<br>precedence than vendor_perl modules. So you can easily update these.</p><p>See<br>ChangeLog:<br>Cygwin README:</p><p>Vendor patches:<br>* CYG04 - major.version cygperl5_10.dll and not cygperl5_10_x.dll<br>* CYG11 - no-bs Empty<nobr> <wbr></nobr>.bs files are not generated anymore</p><p>Update recommendations:<br>-----------------------</p><p>Since 5.10 is not installed in parallel to 5.8 (it is possible, but not<br>with this package), all your old 5.8 modules will need to be reinstalled<br>for 5.10.<br>Your old 5.8 modules are not deleted, just not accessible to 5.10.<br>Non-binary packages can be used by adding<nobr> <wbr></nobr>/usr/lib/perl5/site_lib/5.8 to<br>your @INC, but the below procedure is recommended to get the latest<br>version for each installed package.<br>This will not harm most of your previous 5.8 modules in case you want to<br>switch back to 5.8, just the<nobr> <wbr></nobr>/bin scripts might get overwritten.</p><p>BEFORE INSTALLATION of 5.10 !<br># get the list of installed 5.8 modules<br>$ perl -MExtUtils::Installed \<br> &nbsp; &nbsp; -e'print join("\n", new ExtUtils::Installed-&gt;modules)' &gt; module.list</p><p>AFTER INSTALLATION of 5.10 !<br># install all previous modules for 5.10<br>$ cpan `cat module.list`</p><p>Detailed NEWS from README<br>-------------------------<br>5.10.0-1</p><p>- Configure -de -Dmksymlinks -Duse64bitint -Dusethreads -Uusemymalloc \<br> &nbsp; &nbsp; &nbsp; &nbsp; -Doptimize='-O3' -Dman3ext='3pm' -Dusesitecustomize<br> &nbsp; &nbsp; (unchanged from 5.8)</p><p>- cygwin<nobr> <wbr></nobr>/bin g+w incompatible with TAINT (-T)<br> &nbsp; &nbsp; The default directory permissions for<nobr> <wbr></nobr>/bin drwxrwxr-x is incompatible<br> &nbsp; &nbsp; with perl tainting. chmod g-w<nobr> <wbr></nobr>/bin to allow perl -T scripts to run<br> &nbsp; &nbsp; without warnings.</p><p>- included vendor_perl packages</p><p> &nbsp; &nbsp; Rationale: Same local vendor_perl packages included as in 5.8.7,<br> &nbsp; &nbsp; plus some of the new CPAN packages which went to core with 5.9.5,<br> &nbsp; &nbsp; Bundle::CPAN, CPAN::Reporter, Module::Build for a full CPAN bootstrap,<br> &nbsp; &nbsp; and the new patched libXML packages, and some almost-core<br> &nbsp; &nbsp; dependencies:</p><p> &nbsp; &nbsp; Pod-Escapes-1.04 Pod-Simple-3.05 Test-Pod-1.26<br> &nbsp; &nbsp; Devel-Symdump-2.08 Pod-Coverage-0.19 Test-Pod-Coverage-1.08<br> &nbsp; &nbsp; Compress-Raw-Bzip2-2.008 IO-Compress-Bzip2-2.008 Compress-Bzip2-2.09<br> &nbsp; &nbsp; IO-String-1.08<br> &nbsp; &nbsp; Archive-Zip-1.23<br> &nbsp; &nbsp; Math-BigInt-FastCalc-0.15<br> &nbsp; &nbsp; Term-ReadLine-Perl-1.0302 Term-ReadLine-Gnu-1.16 TermReadKey-2.30<br> &nbsp; &nbsp; XML-NamespaceSupport-1.09 XML-SAX-0.16 XML-LibXML-Common-0.13<br> &nbsp; &nbsp; XML-LibXML-1.65 XML-Parser-2.36<br> &nbsp; &nbsp; Proc-ProcessTable-0.41<br> &nbsp; &nbsp; YAML-0.66 Config-Tiny-2.12 File-Copy-Recursive-0.35 IPC-Run3-0.039<br> &nbsp; &nbsp; Probe-Perl-0.01 Tee-0.13 IO-CaptureOutput-1.06 File-pushd-1.00<br> &nbsp; &nbsp; File-HomeDir-0.67 Digest-SHA-5.45 Module-Signature-0.55<br> &nbsp; &nbsp; URI-1.35 HTML-Tagset-3.10 HTML-Parser-3.56 libwww-perl-5.808<br> &nbsp; &nbsp; CPAN-1.9205 Test-Reporter-1.38 CPAN-Reporter-1.0601<br> &nbsp; &nbsp; Net-Telnet-3.03 Module-ScanDeps-0.81 PAR-Dist-0.25<br> &nbsp; &nbsp; B-Generate-1.11 PadWalker-1.5 Alias-2.32</p><p>Thanks to Jerry D. Hedden and Jan Dubois.</p> rurban 2007-12-25T17:48:08+00:00 journal Future Cygwin:: enhancements I just <a href="">added cygpath style conversions to blead</a> and now I'm wondering what other useful internal API's would be useful to be exported to perl starting with 5.10. <p> And if it should require the "use Cygwin;" importer. Probably so. The current list of 6 cygwin functions in core require no "use Cygwin;". </p><p> I came up with this list for a future Cygwin package:</p><blockquote><div><p> <tt>&nbsp; cygserver_running() =&gt; bool<br>&nbsp; CW_GETVERSIONINFO() =&gt; str<br>&nbsp; CW_GET_CYGDRIVE_PREFIXES($user, $system) =&gt; flags as str<br>&nbsp; CW_SET_CYGWIN_REGISTRY_NAME($path)<br>&nbsp; CW_GET_CYGWIN_REGISTRY_NAME =&gt; str<br>&nbsp; CW_STRACE_ACTIVE() =&gt; bool<br>&nbsp; CW_EXTRACT_DOMAIN_AND_USER(\%pw) =&gt; (domain, user)<br>&nbsp; CW_CMDLINE($pid) =&gt; str<br>&nbsp; CW_CHECK_NTSEC($filename) =&gt; bool<br>&nbsp; CW_GET_ERRNO_FROM_WINERROR($error, $deferrno) =&gt; int<br>&nbsp; CW_GET_POSIX_SECURITY_ATTRIBUTE($attribute, \@psa) =&gt; \%sd<br>&nbsp; CW_GET_SHMLBA() =&gt; GetSystemInfo.dwAllocationGranularity<br>&nbsp; CW_GET_UID_FROM_SID($psid) =&gt; $uid<br>&nbsp; CW_GET_GID_FROM_SID($psid) =&gt; $gid</tt></p></div> </blockquote><p> <i>Of course CW_ will be removed and properly lower cased. Look up sys/cygwin.h and/or <a href=";content-type=text/x-cvsweb-markup&amp;cvsroot=src">winsup/ </a> for example.</i></p> rurban 2007-07-02T20:57:44+00:00 journal