Re: the future of testing
Allison Randal wrote in perl.perl6.internals : In the Python test suite, there's a single global location to declare a list of test files that are expected to be skipped on a particular platform. This has a much cleaner feel than our own motley collection of skip and todo markers in various test files. That assumes that tests are skipped per file, which is not always the case (sometimes you want to skip only one test, sometimes even to work around an OS bug that appears only in one specific version). But reorganizing platform-dependent tests might be a good idea. I (mostly on behalf on P5P) would find it interesting to see how that turns out to be implemented in parrot's test suite, so we can blatanly copy the good ideas and avoid the pitfalls :) -- The man does not exist who, outside his own specialty, is not credulous. -- Borges
Re: RPMs
David Fetter wrote in perl.perl6.internals : Folks, I've been wrestling with the .spec file to generate RPMs for parrot 0.4.12, and so far, the .spec file is winning, so I figured I'd do what I always do when I'm losing: fight dirty and call in help :) I think that Steven Pritchard has worked on RPMs for Fedora. See the fedora-perl-devel-list, at redhat.com. Notably, he posted this specfile there : http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec -- I asked for concrete usage cases, not for everyone's opinions. -- Jeff Johnson in rpm-devel
Re: Safety and security
Larry Wall wrote in perl.perl6.internals :
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and validate those bits of code before
running them. Doesn't do you much good to disallow
eval 'system rm -rf /';
at run time if you don't also catch
BEGIN { system rm -rf /; }
at compile time...
That's mostly what Perl 5's Safe is doing. Hence my previous comment.
The major flaw with this approach is that it's probably not going to
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of allowed ops.
(in each case, you abuse system resources: CPU, memory or ability to
send a signal. I don't know how to put restrictions on all of these
in the general case...)
Re: Configure.pl and the history of the world
Larry Wall wrote in perl.perl6.internals : Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Actually as parrot already uses IIUC variables set up by Configure, I think one could drop the or something like it. The biggest drawback of Configure is that it's UNIX-centric. But it's yet impressively portable and backwards-compatible (ask any Richard Clamp). [Some time ago Raphael Manfredi, bored by the autocrap tools (as he names it) expressed the intent to work on metaconfig again, but then he disappeared again.]
Re: parrotbug working...
Jerome Quelin wrote in perl.perl6.internals : But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? - status-ok: ? - status-nok: should open a RT ticket? Excuse me from stepping in, but I don't see why three adresses are necessary. From my (limited) knowledge of RT, I thing that the parrot bug address could create a ticket in the parrot queue, or add the mail body to the appropriate ticket if the subject contains [perl #X] -- then, it could close the ticket automatically if the subject matches an OK report.
Re: This Week's Summary
Piers Cawley wrote in perl.perl6.internals : I want a Ponie! I promise that, as development of Ponie (the port of Perl 5 to Parrot) accelerates you'll see a summary of Ponie activity in this summary as well. In fact I imagined I was more or less going to do this, based on imagining what will be the contents of the future ponie discussions : how the hell will I be able to interface that spaghetti Perl 5 mess with that clean Parrot API ? Will I really be forced to reimplement the whole subrecursive frobnizer for tied magic ?
Re: This week's summary
Alan Burlison wrote in perl.perl6.internals : Piers Cawley wrote: Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? That doesn't make this per-C-file-cc-option-tweaking necessarily unuseful. Perl 5 uses something similar, because the lexer is sometimes miscompiled when some compilers with a high optimization level. Example : see the hints files and lookup XXX_cflags or toke_cflags in hints/README.hints.
Re: Using imcc as JIT optimizer
Nicholas Clark wrote in perl.perl6.internals : r-score = r-use_count + (r-lhs_use_count 2); r-score += 1 (loop_depth * 3); [...] I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc that added trap code for all classes of undefined behaviour, and caused code to abort (or something more colourfully undefined) if anything undefined gets executed. I realise that code would run very slowly, but it would be a very very useful debugging tool. What undefined behaviour are you referring to exactly ? the shift overrun ? AFAIK it's very predictable (given one int size). Cases of potential undefined behavior can usually be detected at compile-time. I imagine that shift overrun detection can be enabled via an ugly macro and a cpp symbol. (what's a nasal demon ? can't find the nasald(8) manpage)
Re: AUTOLOADED pre- and post- handler methods?
Dan Sugalski wrote in perl.perl6.internals :
In Perl terms, assume we have a method PRE that gets called before
any method in a class is called, and AUTOLOAD which is called if you
call a method on a class and that method doesn't exist. Does AUTOLOAD
have to get called to check for PRE if PRE doesn't exist in a class?
In Perl 5, AUTOLOAD is called for destructors :
$ perl -wle 'sub AUTOLOAD{print $AUTOLOAD};bless{}'
main::DESTROY
While I think this is annoying in most cases, I imagine this may be
useful. And adding an empty destructor to a class is not a huge effort.
The situation is similar for a PRE method. If it's not defined, there's
no error ; if it's not defined but if AUTOLOAD exists, AUTOLOADing is
tried. (I imagine that if AUTOLOAD gracefully refuses to create the PRE
method, no further attempt will be made.)
Re: Tasks for the interested
Dan Sugalski wrote in perl.perl6.internals : Okay, here are some tasks for the interested. They're all related (I expect you'll see the pattern), but independent anyway. 1) Dig through the perl source and find out all the opcodes. (pp.c and friends) Document the opcodes and what they do. Hint for the brave soul : look at opcode.pl. (Be sure to send the docs to P5P, too.)
Re: Perl 5 to Parrot
Melvin Smith wrote in perl.perl6.internals : It sounds like what you are embarking on is a compiler implementation with a full grammar, etc. Right? Not at all, he wants to reuse the perl 5 parser to generate parrot opcodes from perl 5 opcodes. I also remember there was work already in progress, Simon Cozens mailed out a tokenizer and I recall Damian Conway saying he was going to deliver a parser (maybe I'm confused as I often am)? I assume this could be reused, else we end up with 2 architectures of compiler for Perl5 and Perl6. Well, IIRC Simon's tokenizer was a draft perl 6 tokenizer. http://www.cpan.org/authors/id/S/SI/SIMON/Perl6-Tokener-0.01.tar.gz
Re: Perl 5 to Parrot
James A Duncan wrote in perl.perl6.internals : I've started work on B::Parrot, which is a Perl 5 to Parrot translation engine. Its very basic at the moment, but I've got it successfully translating things like: my $perliv = 10; my $perlpv = \n; print $perliv; print $perlpv; into working, assemble-able parrot code. Before I go any further on this crack-fuelled project is there anything I should be aware of? Are others working on this? Have I done far too much crack smoking to consider doing something like this now? I think you're already aware of the main issue : the compiler backends are executed after compilation of the Perl 5 program. Thus, things that happen at compile-time (BEGIN and CHECK blocks, hints to the compiler via pragmas and the $^H / %^H variables) are difficult (or impossible) to spot correctly. The best (safest) method to port Perl 5 to Perl 6 would be IHMO to reimplement a full-blown Perl 5 parser to generate Parrot code. However this doesn't exclude the interest of your B::Parrot approach. Do you plan to release it on CPAN ? Oh, and don't forget to test it with and without threads. Look at the existing B:: modules for hints. -- Rafael Garcia-Suarez : http://rgarciasuarez.free.fr/ It's not a can of worms, it's a tank of shai-hulud. -- Jarkko Hietaniemi
Re: CPP Namespace pollution
Simon Cozens wrote in perl.perl6.internals: Similarly, I'd like Parrot/ to move to lib/ And Test/, while you're at it. But doesn't this require much CVS hackery to keep the revision history? Don't be the slave of your tools ;-) -- Rafael Garcia-Suarez
