Re: implicit explicit returns
On Tue, 26 Aug 2008, luben wrote:
I have noticed that Rakudo (and NQP) generates different PIR code for
implicit and explicit returns.
Example for implicit return:
sub foo($n){
$n;
}
And example for explicit return:
sub foo($n){
return $n;
}
Is this on purpose? The implicit return is 4-5 times faster than explicit
return.
the implicit return is by definition always at the end of a sub and
therefore emits a PIR .return(). it's fast and easy.
the explicit return, in contrast, could be anywhere in a subroutine,
including loops, closures, etc. these constructs are also implemented
using parrot subs, so using .return() would return control to the
sub that *contains* the loop, closure, or whatever construct you're using.
that's not what we want.
to get around this, an exception is thrown and caught by the sub that
*should* do the actual returning. you can see that in the PIR you
generate.
(pmichaud, i hope i explained this right! ;-)
-jeff
Re: interpreter persistence issues
On Sat, 16 Aug 2008, Allison Randal wrote: Jeff Horwitz wrote: i'd like to have an option in mod_parrot to clear all user-generated data (globals, namespaces, subs, etc.) from an interpreter, leaving any bytecode that has been loaded (e.g. compilers). the point here is to eliminate problems caused by data persistence on hosted web servers, which is one of several reasons why many hosting companies don't offer mod_perl. the persistence might even cause problems with pipp/PHP, as it's not expected for data to persist, so this is something mod_parrot needs to support. i'm sure we'd have to provide some significant hints to whatever routine is doing the dirty work, but before i even start to look at this, is it even possible with our current architecture? can we get close? It would be tricky at the moment. It'll be much easier once security sandboxing is in place. You'll be able to run mod_parrot code in a virtual interpreter that only has access to make local modifications, though it can read from the parent interpreter. (Think of it as a COW scheme, or lexical interpreters.) So, you can discard the cheap local overlay to get rid of local changes, and still have the full interpreter running in the background with all its loaded modules. Helpful, but not absolutely necessary, would be a list of what should persist and what shouldn't. PHP might provide a good starting point for the list. It's not just a matter of keep loaded modules but discard variables because loaded bytecode may create package or class variables too. the virtual interpreter scheme would certainly do the trick, as we can initialize things the way we want (loading compilers, etc.) in the parent and never touch it again. this also lets the HLL layer determine if and when to discard the local changes, and mod_parrot will just provide the appropriate hooks to do so. when in doubt, pass the buck to the HLL layer. :) so i guess i'll table this issue until the sandboxing is in place. -jeff
interpreter persistence issues
i'd like to have an option in mod_parrot to clear all user-generated data (globals, namespaces, subs, etc.) from an interpreter, leaving any bytecode that has been loaded (e.g. compilers). the point here is to eliminate problems caused by data persistence on hosted web servers, which is one of several reasons why many hosting companies don't offer mod_perl. the persistence might even cause problems with pipp/PHP, as it's not expected for data to persist, so this is something mod_parrot needs to support. i'm sure we'd have to provide some significant hints to whatever routine is doing the dirty work, but before i even start to look at this, is it even possible with our current architecture? can we get close? -jeff
Re: design problem with :outer
On Wed, 25 Jun 2008, Klaas-Jan Stol wrote: maybe I overlooked something, but wouldn't specifying the full outer subname (including its namespace) help? like so: .namespace ['B'] .sub 'inner' :outer(['A';'outer']) ... .end instead of the proposed :lexid property. just a thought. maybe there's something i'm overlooking or missing, but to me this seems like the most obvious solution. i think the problem is that it doesn't work for multi subs. it wouldn't know which version of the sub you were trying to reference. -jeff
Re: [perl #54444] AutoReply: [rakudo] 'No such caller depth' with pure perl mod_perl6
On Mon, 19 May 2008, Parrot via RT wrote:
while converting mod_perl6 from PIR to pure perl6, i encountered the
following error when running a handler:
No such caller depth
current instr.: 'parrot;ModParrot;HLL;perl6;handler' pc 62 (EVAL_13:46)
i tracked down the error to this block in perl6's actions.pm:
unless $?BLOCK.symbol('$/') {
$init.push( PAST::Var.new( :name('$/'), :isdecl(1) ) );
$?BLOCK.symbol( '$/', :scope('lexical') );
$init.push(
PAST::Op.new(
:inline(
%r = getinterp\n
~ %r = %r['lexpad';1]\n
~ if null %r goto no_match_to_copy\n
~ %r = %r['$/']\n
~ store_lex '$/', %r\n
~ no_match_to_copy:\n
)
)
);
}
this code assumes there is a previous call frame which might contain a
lexpad, which is always true when called from PIR or the PCT command line.
however, in a pure perl mod_perl6, a perl6 sub is called directly from C,
and therefore lives in the top level call frame. any reference to the
nonexistent previous frame using the interpreter object bombs out.
you can reproduce this problem in pure PIR with this:
.sub main :main
$P0 = getinterp
$P1 = $P0['lexpad';1]
.end
if we want perl6 subs to be directly invokable from an embedded
environemnt, we either need to teach perl6 to be smarter about this or
change how parrot handles this kind of exception.
-jeff
After further investigation, it looks like the parrotinterpreter PMC is
validating caller depth before looking up the keyed item. So for
$P0['lexpad';1] it verifies there's a call frame 1 level up before doing
anything else. A backtrace reveals that the exception occurs at
parrotinterpreter.pmc:426:
if (!ctx-current_sub)
real_exception(interp, NULL, E_ValueError,
No such caller depth);
So it *does* find a valid context one level up, but no current_sub since
we're calling from C. Is it necessary for this to be fatal? Should we
return NULL here instead of bombing out?
Re: weird perl6/plumhead problem
On Tue, 29 Apr 2008, Patrick R. Michaud wrote: On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' ... My complete off-the-wall guess is that perl6.pbc has a :multi sub that happens to have the same name as a non-multi sub in plumhead. Or something like that. So, when perl6 is loaded first, the :multi sub in perl6 gets replaced by the non-multi sub in plumhead. When plumhead is loaded first, Parrot tries to push the :multi sub in perl6 onto the (non-:multi) sub in plumhead and throws the exception. i think you're right -- i dove into the backtrace and found that the sub in question was 'infix:+', which is multi in perl6 and non-multi in plumhead. assuming this is the problem, it seems to me that the .HLL sandbox that coke mentioned would solve this. correct? -jeff
weird perl6/plumhead problem
mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' i get the same error with this plain PIR: .sub main :main print loading plumhead\n load_bytecode languages/plumhead/plumhead.pbc print loading perl6\n load_bytecode languages/perl6/perl6.pbc print done\n .end [EMAIL PROTECTED]:~/build/parrot$ ./parrot foo.pir loading plumhead loading perl6 push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) any ideas? backtrace is below. Breakpoint 2, cant_do_method (interp=0x804f048, pmc=0x829d204, methname=0x403cda8d push_pmc) at default.pmc:63 63 real_exception(interp, NULL, ILL_INHERIT, (gdb) bt #0 cant_do_method (interp=0x804f048, pmc=0x829d204, methname=0x403cda8d push_pmc) at default.pmc:63 #1 0x402a732e in Parrot_default_push_pmc (interp=0x804f048, pmc=0x829d204, value=0x82fcbac) at default.c:1632 #2 0x4016130a in store_sub_in_multi (interp=0x804f048, sub=0x82fcbac, ns=0x8092ec4) at src/global.c:739 #3 0x40161410 in Parrot_store_sub_in_namespace (interp=0x804f048, sub=0x82fcbac) at src/global.c:777 #4 0x401934de in PackFile_Constant_unpack_pmc (interp=0x804f048, constt=0x83271d0, self=0x81167e0, cursor=0x40aa94f4) at src/packfile.c:3584 #5 0x401933d8 in PackFile_Constant_unpack (interp=0x804f048, constt=0x83271d0, self=0x81167e0, cursor=0x40aa9428) at src/packfile.c:3526 #6 0x401930dc in PackFile_ConstTable_unpack (interp=0x804f048, seg=0x83271d0, cursor=0x40aa9424) at src/packfile.c:3322 #7 0x401907ea in PackFile_Segment_unpack (interp=0x804f048, self=0x83271d0, cursor=0x40a9ff50) at src/packfile.c:1601 #8 0x40190cfd in directory_unpack (interp=0x804f048, segp=0x8327028, cursor=0x40a9ff40) at src/packfile.c:1795 #9 0x401907ea in PackFile_Segment_unpack (interp=0x804f048, self=0x8327028, cursor=0x40a24040) at src/packfile.c:1601 #10 0x4018f8b1 in PackFile_unpack (interp=0x804f048, self=0x8327028, packed=0x40a24000, packed_size=1254976) at src/packfile.c:867 #11 0x40153b10 in Parrot_readbc (interp=0x804f048, fullname=0x8326fb8 /home/jeff/build/parrot/./languages/perl6/perl6.pbc) at src/embed.c:503 #12 0x401937d4 in PackFile_append_pbc (interp=0x804f048, filename=0x8326fb8 /home/jeff/build/parrot/./languages/perl6/perl6.pbc) at src/packfile.c:3701 #13 0x401939b2 in Parrot_load_bytecode (interp=0x804f048, file_str=0x81fba50) at src/packfile.c:3758 #14 0x400f5c4c in Parrot_load_bytecode_sc (cur_opcode=0x8248918, interp=0x804f048) at core.ops:151 #15 0x40199984 in runops_slow_core (interp=0x804f048, pc=0x8248918) at src/runops_cores.c:219 #16 0x4016ac26 in runops_int (interp=0x804f048, offset=0) at src/interpreter.c:916 #17 0x4016b525 in runops (interp=0x804f048, offs=0) at src/inter_run.c:104 #18 0x4016b7aa in runops_args (interp=0x804f048, sub=0x822ac6c, obj=0x8096098, meth_unused=0x0, sig=0x403c3727 vP, ap=0xbbbc P\\b\220) at src/inter_run.c:230 #19 0x4016b8ec in Parrot_runops_fromc_args (interp=0x804f048, sub=0x822ac6c, sig=0x403c3727 vP) at src/inter_run.c:299 #20 0x401545a7 in Parrot_runcode (interp=0x804f048, argc=1, argv=0xbd18) at src/embed.c:941 #21 0x4039f044 in imcc_run_pbc (interp=0x804f048, obj_file=0, output_file=0x0, argc=1, argv=0xbd18) at compilers/imcc/main.c:781 #22 0x4039faf2 in imcc_run (interp=0x804f048, sourcefile=0xbe33 foo.pir, argc=1, argv=0xbd18) at compilers/imcc/main.c:1069 #23 0x080488d8 in main (argc=1, argv=0xbd18) at src/main.c:61
Re: weird perl6/plumhead problem
On Tue, 29 Apr 2008, Patrick R. Michaud wrote: On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' i get the same error with this plain PIR: .sub main :main print loading plumhead\n load_bytecode languages/plumhead/plumhead.pbc print loading perl6\n load_bytecode languages/perl6/perl6.pbc print done\n .end [EMAIL PROTECTED]:~/build/parrot$ ./parrot foo.pir loading plumhead loading perl6 push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) any ideas? backtrace is below. How about with a -t 1 ? duh, should've given you that in the first place. the trace is HUGE, so here's the last 50 lines. you should be able to reproduce the error using the code above if you need more detail. 21 load_bytecode compilers/tge/TGE/Tr 0 newclass P0, TGE::Tree P0=PMCNULL 3 addattribute P0, cell P0=Class=PMC(0x845f814) 6 addattribute P0, visit P0=Class=PMC(0x845f814) 9 addattribute P0, data P0=Class=PMC(0x845f814) 12 addattribute P0, grammar P0=Class=PMC(0x845f814) 15 addattribute P0, agid P0=Class=PMC(0x845f814) 18 set_returns PC7 20 returncc 23 load_bytecode compilers/tge/TGE/Pa 0 push_eh 7 2 subclass P0, PGE::Grammar, TGE::Parser P0=PMCNULL 6 pop_eh 7 set_returns PC3 9 returncc 25 load_bytecode compilers/tge/TGE/Gr 0 newclass P0, TGE::Grammar P0=PMCNULL 3 addattribute P0, rules P0=Class=PMC(0x8516ce4) 6 addattribute P0, symbols P0=Class=PMC(0x8516ce4) 9 set_returns PC5 11 returncc 27 load_bytecode compilers/tge/TGE/Co 0 load_bytecode TGE.pbc 2 get_class P0, TGE::Grammar P0=PMCNULL 5 subclass P1, P0, TGE::Compiler P1=PMCNULL P0=Class=PMC(0x8516ce4) 9 set_returns PC5 11 returncc 29 get_class P0, PC22 P0=Integer=PMC(0x846304c: 1) PC22=Key=PMC(0x820f890) 32 get_hll_global P1, PC24, die P1=PMCNULL PC24=Key=PMC(0x820f874) 36 set_args PC2 (3), P0, die, P1 PC2=FixedIntegerArray=PMC(0x8463394) P0=Class=PMC(0x8518d28) P1=Sub=PMC(0x846836c pc:7) 41 get_results PC19 43 callmethodcc P0, add_methodP0=Class=PMC(0x8518d28) 46 get_hll_global P1, PC24, line_number P1=Sub=PMC(0x846836c pc:7) PC24=Key=PMC(0x820f874) 50 set_args PC2 (3), P0, line_number, P1 PC2=FixedIntegerArray=PMC(0x8463394) P0=Class=PMC(0x8518d28) P1=Sub=PMC(0x8467e80 pc:229) 55 get_results PC19 57 callmethodcc P0, add_methodP0=Class=PMC(0x8518d28) 60 set_returns PC19 62 returncc 32824 push_eh 7 32826 subclass P0, TGE::Grammar, Plumhead::PAST::Gram P0=PMCNULL 32830 pop_eh 32831 set_returns PC22 32833 returncc loading perl6 4 print loading perl6\n 6 load_bytecode languages/perl6/perl push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) ParrotIO objects (like stdout and stderr)are about to be closed, so clearing trace flags.
Re: mod_parrot uses string_nprintf
On Tue, 22 Apr 2008, Donald Hunter wrote: Hi, hi donald! I'm trying to build mod_parrot against Parrot 0.6.1 and have found that string_nprintf no longer exists. I see from ticket #44053 that the function was removed since it had no users. What's the preferred solution? Re-introduce string_nprintf or modify mod_parrot to use another method? hm, i thought i committed the fix for this, but apparently not. check out r334 in the mod_parrot repository. -jeff
Re: Hackathon at FP
I *should* be there, though IIRC, Allison will not. On Thu, 14 Feb 2008, Andy Lester wrote: I see that Allison's going to be at Frozen Perl. Will you be hackathonning? Anyone else going to be there besides me? I'm not sure I'll be sticking around for the hackathon, especially if I don't hear from anyone, so give me a reason to stay! xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
mod_parrot 0.4
From my journal: I'm pleased to announce that after 2 years of hiatus and 6 months of coding, mod_parrot 0.4 has been released. It's been worth the wait, as we now have working mod_perl6 and PHP proof-of-concepts, per-vhost interpreter pools, the framework for a more comprehensive test suite, and even 64-bit support. You can download the full distribution at http://www.smashing.org/mod_parrot/dist/mod_parrot-0.4.tar.gz. The comprehensive list of changes is below. Enjoy! 0.4January 20, 2008 * Support for Parrot 0.5.1 (Hatachi) and later * Many fixes for 64-bit platforms * Begin transition to server-side tests * Keep testing infrastructure on make clean (versus distclean) * Update PIR syntax and types that have changed since mod_parrot 0.3 * Convert classes to new object model * Convert to nested namespaces * Remove apxs from compile and link phases to add flexibility * Search Parrot runtime path for mod_parrot init code * Remove underscore prefix from HLL handler subs * Map Apache MIME types to HLLs * Map Apache handler names to HLLs * Initialize interpreter at the earliest possible Apache phase * Per-server context pools for virtual hosts (default is per-process) * Properly merge server configs * Can pass a PMC note via pmc_notes() * Implement mod_perl-like cleanup handlers * Use proto-objects make mod_parrot classes instantiable from an HLL * New ModParrot;Context class for accessing mod_parrot data structures * New ModParrot;Interpreter class for interpreter introspection * New TODO list replaces the outdated ROADMAP * Update documentation and examples * New example HLL handlers: - Perl 6 - PHP/Plumhead - NQP - Perl 1/Punie * New example handlers in eg * New Apache directives: - ParrotIncludePath - ParrotAddType - ParrotAddHandler - ParrotOptions o Parent o Enable
writing mod_perl6 in perl 6
This just went up in my blog, but I think it's interesting enough to post
to the list as well.
-jeff
One of the goals of the mod_parrot project is to provide the
infrastructure for running the Perl 6 version of mod_perl, a.k.a.
mod_perl6. I've already demonstrated that mod_perl6 works, so that goal is
slowly being achieved. Many thanks to Patrick Michaud, Jerry Gay, and
everyone else who has worked on the Parrot implementation of Perl 6.
Another lesser known goal of mod_parrot is to allow the high level
language (HLL) layers to be written in the HLL itself. That is to say,
write mod_perl6 in Perl 6. Up to this point, mod_parrot has five HLL
layers (PIR, NQP, Perl6, PHP/Plumhead, Perl1/Punie), all written in
Parrot's native PIR. However, yesterday, with some help from Patrick, I
was able to port mod_perl6 from PIR to pure Perl 6!
As an example, here is a very bare-bones mod_perl6 (DISCLAIMER: string
interpolation in namespaces doesn't actually work yet):
module ModParrot::HLL::perl6;
our %loaded_modules;
# load a Perl 6 handler module
sub load($module)
{
unless (%loaded_modules{$module}) {
use $handler;
%loaded_modules{$module} = 1;
}
}
# call a Perl 6 response handler
sub handler($name)
{
my $r = Apache::RequestRec.new();
load($name);
my $status = ::($name)::handler($r);
$status;
}
# call a Perl 6 authentication handler
sub authen_handler($name)
{
my $r = Apache::RequestRec.new();
load($name);
my $status = ::($name)::handler($r);
$status;
}
When calling a Perl 6 handler, mod_parrot loads this module and calls the
individual handler routines according to the Apache configuration. It also
provides the interface to Apache, including the Apache::RequestRec class
needed by mod_perl6. Everything else it leaves to the Perl 6 compiler.
You might think this code doesn't actually do much, and that's the point.
It's really just a simple thunking layer between mod_parrot and your
handlers, enforcing the rules of the mod_perl6 implementation. For
example, in mod_perl, an Apache::RequestRec object is passed to all
response handlers. This layer is responsible for making sure that happens.
As the Perl 6 compiler matures and mod_parrot adds more functionality,
this version of mod_perl6 will inevitably change. But what you see above
will remain at its core -- loading Perl 6 modules, juggling arguments, and
passing control to handler subroutines. And the fact that it's pure Perl 6
will enable scores of Perl programmers to hack on it without having to
know anything about Parrot or C programming. Take that, XS.
oops
apologies for the top post in my previous reply. didn't realize all that error output was down there! :-P
Re: [perl #48677] [BUG] r23917 led to 'make' failure
On Mon, 17 Dec 2007, chromatic wrote: Okay, so memcpy doesn't fix it. That's good to know. How about explicitly putting the destination PMC in a named variable so there's less pointer shuffling and macro madness? memmove fixes it. i submitted a patch, but for some reason it hasn't made it to RT or the list... -jeff
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, 10 Dec 2007, Tim Bunce wrote: Also, what's the status of docs/embed.pod? It seems out of date and/or imcomplete (no mention of Parrot_call_sub, for example). I'm very much a novice with parrot. So my preferred approach for now would be for someone more knowledgeable (Allison, chromatic, ...) to lead the way by updating/expanding the docs/embed.pod specification. I can take a stab at this, as I've done enough Parrot embedding to write a short novel. Looks like PDD10 could use some updating as well -- were there any plans for that? Maybe we should start there? -jeff
Re: [svn:parrot] r21613 - in trunk: lib/Parrot/Configure tools/build
yes, there is a race condition, which we discussed briefly on IRC. i
stayed away from fcntl/flock for portability reasons, but i honestly
didn't spend too much time researching it.
that said, i'm all for avoiding race conditions, so i'd be curious to see
some platform tests with the fnctl patch, especially on windows.
-jeff
On Wed, 26 Sep 2007, chromatic wrote:
On Wednesday 26 September 2007 14:26:20 [EMAIL PROTECTED] wrote:
Author: coke
Date: Wed Sep 26 14:26:19 2007
New Revision: 21613
Modified:
trunk/lib/Parrot/Configure/Messages.pm
trunk/tools/build/c2str.pl
Log:
[build]
Update c2str.pl so that multiple copies running simultaneously no longer
step on each other's toes drunkenly with a jackhammer.
With this fix (Courtesy of jhorwitz++), 'make -j 2' now works, tested
on a variety of platforms.
It even works for make -j 9 for me (two cores, but I like to keep them busy).
However...
Modified: trunk/tools/build/c2str.pl
===
=== --- trunk/tools/build/c2str.pl (original)
+++ trunk/tools/build/c2str.pl Wed Sep 26 14:26:19 2007
@@ -19,6 +19,21 @@
my $outfile = 'all_cstring.str';
my $string_private_h = 'src/string_private_cstring.h';
+my $lockfile = $outfile.lck;
+my $max_lock_wait= 120;
+
+my $start_time = time;
+while ( -e $lockfile ) {
+sleep 1;
+if ( time - $start_time $max_lock_wait ) {
+die Lock still held after $max_lock_wait seconds -- something is
wrong!; +}
+}
... isn't there a race condition right here?
+open my $lock, '', $lockfile or die Can't write '$lockfile': $!;
+print $lock $$\n;
+close $lock;
+
+$SIG{'__DIE__'} = sub { unlink $lockfile };
For what it's worth, I think this patch is safer. I did have some trouble
with -j 3 and higher, but it's working for me on 32-bit x86 Linux now up
to -j 9.
-- c
mod_perl6 update
It gives me great pleasure to introduce you to the world's first mod_perl6
handlers! They are run using Parrot's Perl6 compiler on top of
mod_parrot, and are compiled on the fly the first time a handler is
called. Each handler is passed an [Apache;RequestRec] object instantiated
by mod_parrot, and the handlers can call methods on that object from Perl6
land.
First is Polly. Polly repeats everything from the query string of a URL.
It uses the puts() method for output and args() to retrieve the query
string from Apache.
sub polly_handler($r)
{
$r.puts(h1Polly, a mod_perl6 handler/h1\n);
$r.puts(SQUAWK! Polly says ~$r.args());
0; # Apache OK
}
Second is the counter, which increments a counter each time it is called.
It demonstrates the persistence of the interpreter and proper scoping of
the counter variable using our. Since each Apache process has its own
interpreter, the count might seem to jump between calls, espcially if your
browser isn't using keepalives.
sub counter_handler($r)
{
our $x;
unless ($x) {
$x = 1;
}
$r.puts(h1Hello, I'm a mod_perl6 response handler!/h1\n);
$r.puts(Page views for this interpreter: $x\n);
$x++;
0; # Apache OK
}
Against my better judgment, here are URLs for each handler:
Polly: http://www.smashing.org/sandbox/perl6-handlers/polly?wanna_cracker
Counter: http://www.smashing.org/sandbox/perl6-handlers/counter
Hopefully the server stays up -- I guess this is a pretty good test of
mod_parrot's stability. ;-)
Enjoy,
-jeff
duplicate symbols
not surprisingly, it looks like some symbols in libparrot conflict with exported symbols from other libraries. i ran into this when testing mod_parrot on an apache server with PHP 5 configured: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1077226080 (LWP 9187)] 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so (gdb) bt #0 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so #1 0x40b7f47a in visit_loop_todo_list (interp=0x825c488, current=0x0, info=0xb4e0) at src/pmc_freeze.c:1426 #2 0x40b7f781 in run_thaw (interp=0x825c488, image=0x840978c, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1554 #3 0x40b7f9c6 in Parrot_thaw (interp=0x825c488, image=0x840978c) at src/pmc_freeze.c:1663 [snip] obviously parrot is looking for src/list.c:list_length, but instead gets PHP5's list_length, which is already loaded into apache. i'm sure this problem exists for other functions -- any ideas for how to address this? we could prepend a Parrot_ prefix for the PARROT_API functions (which list_length is), but that may not be appropriate for all situations. -jeff
mod_parrot is back
thanks to the hallway track at OSCON, some help from particle, and many many tuits this weekend, mod_parrot now builds against parrot HEAD, and all tests pass. i went on hiatus way back in 2006 to wait for parrot to mature a bit, and it's amazing how much has changed since i last worked with it! my next step is to tie up any loose ends and release the next version. i will also be working on implementing an actual language on top of mod_parrot -- pmichaud threatened me with nqp, but we'll see about that. :) in the meantime, things are stable as of r235. you can grab it via svn if you feel so inclined: svn co http://svn.perl.org/parrot-modules/mod_parrot/trunk -jeff
Re: Thank you so much Josh Hoblitt for the backtracing
very nice -- i could have used that THIS AFTEROON! :) On Thu, 26 Jul 2007, Andy Lester wrote: Josh putting in the new backtrace behind my new assertions makes debugging assertions SO MUCH EASIER. I'm gonna go s/assert/PARROT_ASSERT/ everywhere. xoxo, Andy P.S. sample # Received: # 1..1 # Backtrace - Obtained 16 stack frames (max trace depth is 32). # (unknown) # Parrot_confess # Parrot_make_COW_reference # Parrot_String_get_string # Parrot_set_s_p # (unknown) # (unknown) # (unknown) # (unknown) # Parrot_runops_fromc_args # Parrot_runcode # (unknown) # imcc_run # (unknown) # __libc_start_main # (unknown) # src/string.c:129: failed assertion 's' # # Expected: # 1..1 # ok 1 # # Looks like you failed 6 tests of 12. t/pmc/exporterdubious Test returned status 6 (wstat 1536, 0x600) -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: UUIDs for PBC headers
On Tue, 18 Oct 2005, Chip Salzenberg wrote: On Mon, Oct 17, 2005 at 10:09:22PM -0400, Jeff Horwitz wrote: On Mon, 17 Oct 2005, Chip Salzenberg wrote: Any problems here? Any suggestions for UUID code that's licensed appropriately for use in Parrot? the UUID library in e2fsprogs might be appropriate. e2fsprogs is GPL, but lib/uuid has a separate and much more flexible BSD-style license. http://e2fsprogs.sourceforge.net/ Hey, neat. On the other hand, the idea has been raised on IRC (by Joshua, IIRC) that an MD5 or SHA256 would protect against corruption, and would also incidentally make a dandy UUID. was there any discussion about what the checksums would be calculated on? one benefit of UUIDs is that they are usually independent of the underlying data they identify, and would therefore have no performance penalty for larger files. i know it's only a one-time hit for PBC files, and a minor one at that, but does this also apply for evals/compiles? -jeff
Re: UUIDs for PBC headers
On Tue, 18 Oct 2005, Chip Salzenberg wrote: On Tue, Oct 18, 2005 at 11:27:16AM -0400, Jeff Horwitz wrote: On Tue, 18 Oct 2005, Chip Salzenberg wrote: On the other hand, the idea has been raised on IRC (by Joshua, IIRC) that an MD5 or SHA256 would protect against corruption, and would also incidentally make a dandy UUID. was there any discussion about what the checksums would be calculated on? one benefit of UUIDs is that they are usually independent of the underlying data they identify, and would therefore have no performance penalty for larger files. i know it's only a one-time hit for PBC files, and a minor one at that, but does this also apply for evals/compiles? I don't see a point in using it for evals/compiles. As for the pbc file case: If you're making a pbc so large that hash creation takes noticeable time, then just imagine how long _writing_ it will take? :-) this answers my question. :) -jeff
Re: UUIDs for PBC headers
On Mon, 17 Oct 2005, Chip Salzenberg wrote: In the use case where the same pbc exists in multiple places in a filesystem (or is renamed during run, or lives on a filesystem without a good definition of same place), it's necessary to detect when a load is redundant. I'm planning to require a UUID in the pbc header which would make each pbc distinguishable from every other pbc. This would have no privacy issues if it's done right, because the pbcs are identified, not the parrot installations that create them. Any problems here? Any suggestions for UUID code that's licensed appropriately for use in Parrot? i know mod_parrot would benefit from this. one question though -- if a redundant UUID is found, will the internals make the decision to load/not load or will that be up to the HLL/embedding code? -- Chip Salzenberg [EMAIL PROTECTED] -jeff
Re: UUIDs for PBC headers
On Mon, 17 Oct 2005, Chip Salzenberg wrote: Any problems here? Any suggestions for UUID code that's licensed appropriately for use in Parrot? the UUID library in e2fsprogs might be appropriate. e2fsprogs is GPL, but lib/uuid has a separate and much more flexible BSD-style license. http://e2fsprogs.sourceforge.net/ -- Chip Salzenberg [EMAIL PROTECTED] -jeff
mod_parrot 0.3
i'm pleased to announce the release of mod_parrot 0.3. the most notable changes include support for all apache hooks, autogeneration of request_rec methods, and a mod_pugs proof of concept. it also supports both the new (leo-ctx5) and old calling conventions. you can download it at http://www.smashing.org/mod_parrot, or from subversion at http://svn.perl.org/parrot-modules/mod_parrot. if you decide to try it, please use a recent svn revision of parrot -- things change quickly around here! changes from 0.2: * Support for Parrot 0.2.2 (geeksunite) * Support new Parrot calling conventions (still backwards compatible) * Autogeneration of request_rec methods (thanks ian!) * All Apache hooks are implemented * The init file is no longer required to be PBC * Include a very simple mod_pugs proof of concept, with tests * ParrotTrace now accepts flags that are passed Parrot's trace facility * Parrot*Handler takes an optional language specifier * Use parrot-config.imc to fetch parrot configuration * Configure.pl no longer requires Apache::Test * ModParrot::NCI::backtrace returns a backtrace string * New APR::Table class * New Apache::RequestRec methods: - notes (returns APR::Table object) - main - prev - next - status -jeff
Re: embedding/extending interface
On Wed, 13 Jul 2005, Nicholas Clark wrote: On Wed, May 11, 2005 at 11:18:30AM +0100, Nicholas Clark wrote: On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote: as part of both the pugs and mod_parrot effort, i've started working on bringing the embedding and extending interfaces into the modern parrot era. i'd like to start by adding public APIs (Parrot_*) where necessary and adding missing prototypes to the headers. this will clean things up without changing any of the working parts. is there anyone else besides myself and autrijus who is actively working on an embedded parrot application? Following a question I raised about this, chromatic has some automated tools ready to help here http://www.nntp.perl.org/group/perl.perl6.internals/29422 However, I don't feel confident to say if this is the correct way to go. (seems like a design question) Did anything come of this? Or is chromatic still waiting in the wings for confirmation that this is the right way to go? i don't know about chromatic's part, but as soon as i began work on this, real life got in the way and autrijus said he'd spearhead the effort. considering his schedule at the time, i'm not sure if he had the tuits to deal with it either. maybe now that i have some more time i can start working on this again. or maybe it's best to wait for leo to finish his current batch of changes. Nicholas Clark -jeff
embedding w/ new calling conventions
mod_parrot is running into a bit of trouble calling subs written in PIR with the new calling conventions. some initial observations: * using Parrot_call_sub_* seems to require a get_params opcode (or a .param), else it dies with no get_params in sub. this is true even when called with a void signature. isn't PIR supposed to take care of that for us? it works fine in a non-embedded environment. * subs can't return anything through the API. a simple .return (0) causes Parrot_call_sub_reti to bomb out with an assertion failure: src/sub.c:444: parrot_pass_args: Assertion `(((src_signature)-obj.flags) PObj_is_PMC_FLAG)' failed. this may all be premature, as leo's branch is still brand-spanking new, and i'm probably missing something. that said, leo, we discussed some API enhancements on #parrot the other day -- if you were planning on implementing something that will fix this, just say the word and i'll keep quiet. :) -jeff
mod_pugs status
i'm happy to report that mod_parrot now comes bundled with mod_pugs!
mod_pugs uses pugs (http://pugscode.org) to let you write apache handlers
in perl6, and runs as an HLL layer on top of mod_parrot. pugs' parrot
backend compiler is still very immature, so you still can't do many of the
things you can do in pugs proper. but you can still see how far we've
come:
module My::PugsHandler;
sub _handler($r)
{
$r.puts(H1This is a Pugs handler!/H1);
return 0;
}
put that in pugs' @INC path, and the following apache config will
configure the handler for the location /pugs/test on your server:
Location /pugs/test
SetHandler parrot-code
ParrotLanguage pugs
ParrotHandler My::PugsHandler
/Location
next on the todo list is to implement more handlers, more methods (so far
only puts and content_type are supported) and rewrite some parts
of mod_pugs in pugs itself. if you want to try it out, check out the
latest revisions of both mod_parrot and pugs from subversion (released
versions will NOT WORK). the eg directory contains a working example and
configuration.
http://svn.perl.org/parrot-modules/mod_parrot
http://svn.openfoundry.org/pugs
-jeff
mmd
for mod_parrot i want to support both passing both PMCs and native types to the apache API, depending on the HLL. MMD was doing a great job handling this for me until i ran into a problem. given the following methods: .sub bar method, @MULTI(Foo, string) .sub bar method, @MULTI(Foo, pmc) .sub bar method, @MULTI(Foo) and assuming 'Foo' is an object PMC, here's what happens when i call 'bar' with various arguments: $I0 = find_type 'Foo' $P0 = new $I0 $P0.'bar'() # calls the empty arg version of bar $P0.'bar'(a string) # calls the string version of bar $P1 = new PerlString $P1 = a perl string $P0.'bar'($P1)# XXX calls the empty arg version of bar the pmc version of bar() is never called, even when passing a PMC. if i change the prototype to @MULTI(Foo, PerlString), i can pass the PerlString to that, but i'd prefer to be able to pass any arbitrary PMC without explicitly specifying its type in the method. -jeff
Re: mmd
On Tue, 24 May 2005, Leopold Toetsch wrote:
Multi subs and especially multi methods are barely tested. 'pmc' or '_'
should match 'Any' PMC, so that's for sure a bug. Can you please provide
a test-like sample file to investigate, thanks.
here you go. it should print string PMC nothing, but instead prints out
string nothing nothing. interestingly, if you change @MULTI(Foo) to
@MULTI(_), it all works, but that seems more of a band-aid solution for
this particular case.
-jeff
---
.namespace ['Foo']
.sub bar method, @MULTI(Foo, string)
print string\n
.end
.sub bar method, @MULTI(Foo, pmc)
print PMC\n
.end
.sub bar method, @MULTI(Foo)
print nothing\n
.end
.namespace ['']
.sub main @MAIN
newclass $P0, 'Foo'
$I0 = find_type 'Foo'
$P0 = new $I0
$P0.'bar'('Bar!')
$P1 = new PerlString
$P1 = Bar!
$P0.'bar'($P1)
$P0.'bar'()
.end
Re: Parrot as an extension language
On 19 May 2005, Colin Paul Adams wrote: [snip] I'm having a problem with this. For Parrot_find_global, I'm specifying global.h as one of the header files which must be read to generate definitions from. But this is failing, apparently because PMC isn't defined. So I tried to find where PMC was defined - it looked like pobj.h to me, but if I include that, I run into trouble with size_t (?!) and DPOINTER (at least). What headers do I need to read for the parrot_find_global call? Parrot_PMC is the public type, and behind the scenes it's defined as PMC *. all you should need to include is embed.h, extend.h and for now, resources.h. i'm actually working on fleshing these files out to be more consistent wrt the public API. see trunk/src/parrot_util.c in the mod_parrot source for a working example of all this. -- Colin Adams Preston Lancashire -jeff
Re: Problems linking with parrot
you need to link with src/parrot_config.o (a recent change). http://www.nntp.perl.org/group/perl.perl6.internals/29468 On 18 May 2005, Colin Paul Adams wrote: I've nearly got my first Eiffel program with an embedded parrot VM to compile - well, actually, it DOES compile, just one remaining link problem, which I can't figure out: gcc -o hello -O2 -m486 -pipe -I/opt/Eiffel55/studio/spec/linux-glibc2.1/include -I. -I/home/colin/parrot/include -I/home/colin/eParrot/manual_wrapper/c/include -I/home/colin/eParrot/generated_wrapper/c/include -I/home/colin/eParrot/generated_wrapper/c/include/spec/ise C4/Cobj4.o C3/Cobj3.o C2/Cobj2.o C1/Cobj1.o E2/Eobj2.o E1/Eobj1.o E1/emain.o \ /home/colin/parrot/blib/lib/libparrot.a -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp /opt/Eiffel55/studio/spec/linux-glibc2.1/lib/libfinalized.a -lm /home/colin/parrot/blib/lib/libparrot.a(global_setup.o)(.text+0xd): In function `create_config_hash': src/global_setup.c:33: undefined reference to `parrot_get_config_string' collect2: ld returned 1 exit status make: *** [hello] Error 1 It's that: src/global_setup.c:33: undefined reference to `parrot_get_config_string' which I can't figure out. It's decalred in library.h, and called from the line quoted, but I can't find it's definition in src or include/parrot. Can anyone tell me what I'm missing? -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
you'll probably want to use the Parrot_call_sub_* API to call individual subroutines and get return values. perldoc extend.c in the parrot source for more info. you might also have a look at the mod_parrot source (http://www.smashing.org/mod_parrot), which is one of the few apps embedding parrot at the moment. the other is pugs (http://www.pugscode.org), but it's written in haskell. -jeff On 17 May 2005, Colin Paul Adams wrote: Hello, I am writing an XSLT 2.0 processor, and I want to give users the option to write their own message and error handling routines and the like in their favourite scripting language. So I thought of using parrot. But when I look at http://www.parrotcode.org/docs/embed.html, I can see no way of getting information back from the script - not even an exit code. Is there anyway of doing this that I have missed? -- Colin Adams Preston Lancashire
embedding/extending interface
as part of both the pugs and mod_parrot effort, i've started working on bringing the embedding and extending interfaces into the modern parrot era. i'd like to start by adding public APIs (Parrot_*) where necessary and adding missing prototypes to the headers. this will clean things up without changing any of the working parts. is there anyone else besides myself and autrijus who is actively working on an embedded parrot application? -jeff
[PATCH] allow array of args for spawnw (fwd)
-- Forwarded message --
Date: Mon, 9 May 2005 14:32:22 -0400 (EDT)
From: Jeff Horwitz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PATCH] allow array of args for spawnw
the attached patch adds a new signature for spawnw so it can take a PMC
array of arguments rather than a single string. with this, parrot can
support perl's system($cmd) as well as system(@args). tests are
included, though i only have unix platforms to test on right now.
-jeff
Index: ops/ops.num
===
--- ops/ops.num (revision 8028)
+++ ops/ops.num (working copy)
@@ -1341,3 +1341,4 @@
not_i 1311
not_p 1312
n_not_p_p 1313
+spawnw_i_p 1314
Index: ops/sys.ops
===
--- ops/sys.ops (revision 8028)
+++ ops/sys.ops (working copy)
@@ -20,9 +20,16 @@
=item Bspawnw(out INT, in STR)
-Spawn a subprocess and wait for it to finish. The return status, which is
-very system-dependent, goes in $1.
+Spawn a subprocess whose program name and arguments are contained in the string
+$2 and wait for it to finish. The return status, which is very
+system-dependent, goes in $1.
+=item Bspawnw(out INT, in PMC)
+
+Spawn a subprocess whose program name and arguments are contained in the array
+$2 and wait for it to finish. The return status, which is very
+system-dependent, goes in $1.
+
=cut
inline op spawnw(out INT, in STR) {
@@ -30,6 +37,11 @@
goto NEXT();
}
+inline op spawnw(out INT, in PMC) {
+ $1 = Parrot_Run_OS_Command_Argv(interpreter, $2);
+ goto NEXT();
+}
+
###
=item Berr(out INT)
Index: t/op/spawnw.t
===
--- t/op/spawnw.t (revision 8028)
+++ t/op/spawnw.t (working copy)
@@ -13,12 +13,12 @@
Tests spawning external commands.
-spanwn does not capture STDOUT and STDERR from the spawnde command.
+spawnw does not capture STDOUT and STDERR from the spawned command.
So only the exit code can be tested.
The returned value is actually returned from the 'waitpid' system call.
-In order to get the exit code from the spawned process, it needs to be right
shifted
-by 8 bit.
+In order to get the exit code from the spawned process, it needs to be right
+shifted by 8 bit.
=head1 TODO
@@ -34,11 +34,13 @@
=cut
-use Parrot::Test tests = 3;
+use Parrot::Test tests = 6;
# perl command coded this way to avoid platform
# quoting issue.
+# test string version of spawnw
+
pasm_output_is('CODE', 'OUTPUT', exit code: 0);
set S1, 'perl -e exit(0)'
set I1, 99
@@ -65,7 +67,6 @@
return code: 123
OUTPUT
-
output_is('CODE', 'OUTPUT', exit code: 3);
set S1, 'perl -e exit(3)'
set I1, 99
@@ -78,3 +79,56 @@
CODE
return code: 3
OUTPUT
+
+# test array version of spawnw
+
+output_is('CODE', 'OUTPUT', exit code: 0);
+new P0, .Array
+set P0, 3
+set P0[0], perl
+set P0[1], -e
+set P0[2], exit(0)
+set I1, 99
+spawnw I1, P0
+ shr I2, I1, 8
+print return code:
+print I2
+print \n
+end
+CODE
+return code: 0
+OUTPUT
+
+output_is('CODE', 'OUTPUT', exit code: 123);
+new P0, .Array
+set P0, 3
+set P0[0], perl
+set P0[1], -e
+set P0[2], exit(123)
+set I1, 99
+spawnw I1, P0
+ shr I2, I1, 8
+print return code:
+print I2
+print \n
+end
+CODE
+return code: 123
+OUTPUT
+
+output_is('CODE', 'OUTPUT', exit code: 3);
+new P0, .Array
+set P0, 3
+set P0[0], perl
+set P0[1], -e
+set P0[2], exit(3)
+set I1, 99
+spawnw I1, P0
+ shr I2, I1, 8
+print return code:
+print I2
+print \n
+end
+CODE
+return code: 3
+OUTPUT
Index: config/gen/platform/platform_interface.h
===
--- config/gen/platform/platform_interface.h(revision 8028)
+++ config/gen/platform/platform_interface.h(working copy)
@@ -123,6 +123,8 @@
struct parrot_string_t;
INTVAL Parrot_Run_OS_Command(Interp*, struct parrot_string_t *);
void Parrot_Exec_OS_Command(Interp*, struct parrot_string_t *);
+INTVAL Parrot_Run_OS_Command_Argv(Interp*, struct PMC *);
+void Parrot_Exec_OS_Command_Argv(Interp*, struct PMC *);
/*
* Local variables:
Index: config/gen/platform/generic/exec.c
===
--- config/gen/platform/generic/exec.c (revision 8028)
+++ config/gen/platform/generic/exec.c (working copy)
@@ -40,6 +40,51 @@
return 1; /* make gcc happy
Re: embedding initialization
excellent! now i can get rid of that silly no-op bytecode i've been using. thanks for the quick turnaround, leo. -jeff On Thu, 5 May 2005, Leopold Toetsch wrote: Jeff Horwitz wrote: i'm neck deep in writing the IMC eval code for pugs. ... ... but i imagine there's a more elegant solution out there. t/src/compiler.t has now all the steps to run a PIR code string from C. It's not elegant though, because there are no APIs, but it should make things running. -jeff leo
embedding initialization
i'm neck deep in writing the IMC eval code for pugs. if i've already loaded bytecode using Parrot_readbc/loadbc, i can then successfully call the PIR compiler and eval code at will from C/Haskell. great! however, without the Parrot_readbc step, everything bombs out because the packfile isn't set up correctly. and after looking at packfile.c and embed.c, it's obvious there's a lot more i need to do than just creating a new packfile. do we have the ability to do this right now or should there be another function that performs this initialization for us? we'll most certainly need this for things like perl -e one-liners. in the short term, i can use a no-op .pbc file to bootstrap with, but i imagine there's a more elegant solution out there. -jeff
Re: Monthly Release Schedule
On Thu, 7 Apr 2005, MrJoltCola wrote: Where did Tinderbox go anyway? I don't mind running a tinderclient at all. i ran a tinderclient on my ultra 60 for a while before the tinderbox went away. i think i was the only solaris box out there, and i'd be more than happy to run it again when and if tinderbox comes back. -jeff
Re: Pugs Q for the Parrot FAQ?
On Wed, 30 Mar 2005, Nicholas Clark wrote: Based on the wheat on IRC this evening, is this question/answer worth adding to the Parrot FAQ on parrotcode.org? Pugs is going great shakes - why not just toss Parrot and run Perl 6 on Pugs? [snipped long response] and let's not forget bytecode compatibility with all the non-perl languages that will hopefully target parrot. -jeff
Re: mod_parrot 0.2
On Tue, 29 Mar 2005, Leopold Toetsch wrote: Jeff Horwitz [EMAIL PROTECTED] wrote: mod_parrot 0.2 is now available from http://www.smashing.org/mod_parrot or from SVN at http://svn.perl.org/parrot-modules/mod_parrot. Steadily evolving, great. major changes include support for parrot 0.1.2 (phoenix), the beginnings of a thread-safe interpreter pool, Didn't find the latter. it's buried in context.c, and it doesn't really work yet. i just needed to get rid of globals and abstract the selection of the interpreter before things got too complicated. we'll flesh it out more when we start using threaded MPMs. right now we're making sure everything works in prefork. BTW. I saw your remark WRT namespaces. Nested namespaces should work now: see t/pmc/namespace.t excellent! didn't catch that one before. One thing still missing is to retrieve the current namespace inside a subroutine, which will be in RSN, e.g.: $P0 = interpinfo .INTERPINFO_CURRENT_NAMESPACE that would certainly be helpful. thanks for the hints! -jeff
mod_parrot 0.2
mod_parrot 0.2 is now available from http://www.smashing.org/mod_parrot or from SVN at http://svn.perl.org/parrot-modules/mod_parrot. major changes include support for parrot 0.1.2 (phoenix), the beginnings of a thread-safe interpreter pool, support for more apache hooks, updated documentation, and more tests. there is also a new HLL layer to support language specific features for each handler. this will allow for plug-in style support for different languages. right now, only PIR handlers are supported, but i plan on implementing a pugs layer (http://www.pugscode.org) once it supports OO and its parrot backend catches up. i guess it's time to learn haskell! ;-) enjoy, -jeff
Re: Calling PIR from a PMC
On Mon, 14 Mar 2005, William Coleda wrote:
How does one call a PIR-defined sub from C?
use the Parrot_call_sub_* API.
My current best guess is, to invoke the PIR sub Tcl::Joe:
PMC *invokeme;
STRING *Tcl,*joe;
Tcl = string_from_const_cstring(INTERP, Tcl, 3);
joe = string_from_const_cstring(INTERP, joe, 3);
invokeme = Parrot_find_global(INTERP, Tcl, joe);
VTABLE_invoke(INTERP,invokeme,);
But I don't know what to put as the argument for next to VTABLE_invoke - I
see some items in dynclasses/*.pmc use the string next, the code seems to
allow for NULL - neither of them seem to actually invoke my method. (a .sub
with a single print statement)
Do I need to be setting up the calling conventions in my calling code? Is
there some other step I'm missing? Is this already documented somewhere?
here's how i do it in mod_parrot, using the Parrot_* datatypes and the
Parrot_call_sub_* API. some of the logic has been factored out into
different functions for code reuse, but you get the idea:
Parrot_PMC get_sub_pmc(Parrot_Interp interp, char *namespace, char *name)
{
Parrot_PMC sub;
sub = Parrot_find_global(
interp,
namespace ? MAKE_PARROT_STRING(namespace) : NULL,
MAKE_PARROT_STRING(name)
);
return(sub);
}
int modparrot_call_sub(Parrot_Interp interp, char *namespace, char *name,
int *ret)
{
Parrot_PMC sub;
sub = get_sub_pmc(interp, namespace, name);
if (!sub) {
return(0);
}
*ret = Parrot_call_sub_ret_int(interp, sub, Iv);
return(1);
}
-jeff
[PATCH] return absolute paths from Parrot_locate_runtime_file
Parrot_readbc can segfault when loading an absolute path to a file (in my
case, only under GDB). the problem lies in Parrot_locate_runtime_file,
and is similar to the one in ticket #32087.
the attached patch adds a check in Parrot_locate_runtime_file so it
returns absolute paths as is. it handles win32 paths (and drive letters)
as well. hopefully i chose the most logical place for this -- i didn't
think it belonged in Parrot_readbc itself.
-jeff
diff -a -u -r1.14 library.c
--- src/library.c 16 Dec 2004 10:37:16 - 1.14
+++ src/library.c 4 Feb 2005 17:10:15 -
@@ -199,6 +199,19 @@
if (!ext) {
internal_exception(UNIMPLEMENTED, no extension: file '%s',
file_name);
}
+
+/* use absolute paths as is */
+#ifdef WIN32
+if (file_name[0] == '\\' || (isalpha(file_name[0]) strncmp(file_name+1,
:\\, 2) == 0)) {
+#else
+if (file_name[0] == '/') {
+#endif
+length = strlen(file_name) + 1;
+full_name = mem_sys_allocate(length);
+strcpy(full_name, file_name);
+return full_name;
+}
+
length = 0;
for (ptr = paths; *ptr; ++ptr) {
int len = strlen(*ptr);
Re: solution to TODO #32365
On Mon, 10 Jan 2005, Leopold Toetsch wrote: [snip] I'm not quite sure, if we need the additional complexity of a build-script that generates parrot-config. It's for sure more flexible but OTOH we probably just need a few shortcuts, which could be handled directly too. One thing I didn't address is what kind of shortcuts folks want. I just have a couple of example shortcuts in the script. Yeah. I was thinking of just --compile --link maybe with shared variants that emit everything needed to create e.g. a t/src/*.c -ish binary. Let's see what other people would need. for me, this would greatly simplify the mod_parrot build process, though i'd like to see it broken down into at least --cflags, --include, --ldflags and --libs so we can use our own flags. these options are pretty standard for *-config programs (apr-config, gtk-config, etc.). -jeff
Re: mandelbrot
hm, works fine for others. maybe the weird port i'm using for that web server isn't agreeing with your firewall. -jeff On Tue, 14 Dec 2004, Michael Walter wrote: On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
mandelbrot
here's a fun little app i cooked up yesterday -- an ASCII mandelbrot browser written as a mod_parrot handler. it's pretty speedy (assuming your connection isn't holding you back), and it's the first handler i've written that parses form inputs. for now, it's on my mod_parrot page at http://www.smashing.org/mod_parrot, which links to a separate web server just in case mod_parrot blows up. :) is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) -jeff
Re: Perl 6 Summary for 2004-11-08 through 2004-11-15
On Mon, 15 Nov 2004, Matt Fowles wrote: Languages with Object Support? Jeff Horwitz wondered if there were any languages with object support that he could bend to the evil ends of mod_parrot. While no one answered, I think Parakeet might be such a language... parakeet's a newcomer to the languages directory, so i hadn't seen it before. it has objects and functions, so it should fit in nicely with mod_parrot. it's currently broken with all the changes that have been going on, but michel is working on the fixes. good suggestion, matt. :) -jeff
parakeet broken?
i was starting to play with parakeet, but unfortunately it keeps dying on me. this is from a cvs checkout from today: 0 4 4 + Null PMC access in get_pmc_keyed_int() and this: 0 func hello hi! println end 0 hello Null PMC access in push_pmc() any clues? thanks, -jeff
object support in languages
i'd like to find a language with object support that i can write mod_parrot handlers with. as far as i can see, none of the bundled languages currently support parrot objects, but since not everything is bundled with parrot, i thought i'd ask around. i know dan was tinkering with the idea of using the language he targeted to parrot at work, but i'm sure he's had better things to do. -jeff
mod_parrot 0.1
I've just released mod_parrot 0.1. As I noted in my previous post a few weeks ago, it now supports authentication handlers. Other major changes include a testing framework (using Apache::Test), access to Apache constants, and POD documentation. You can download it here: http://www.smashing.org/mod_parrot Maybe one day I'll have a real web page there. :) Enjoy, -jeff
Re: extend.c:Parrot_call
this would be great -- i'm currently pulling the return values of my called subs directly out of I5, and it would be nice to have that bit taken care of for me, especially if calling conventions change somewhere down the line (but i certainly hope they don't). :) -jeff On Wed, 27 Oct 2004, Leopold Toetsch wrote: Parrot_call() runs a Parrot subroutine, but it takes PMC arguments only and provides no return value. If no one hollers, I'll replace this function with a more flexible set of functions that are wrappers to the *runops* functions in src/inter_run.c: void *Parrot_call_sub_(interp, sub, signature, ...) [1] Parrot_IntParrot_call_sub_ret_int Parrot_Float Parrot_call_sub_ret_float void *Parrot_call_meth(interp, sub, object, meth, sig, ...) ... The signature of the current Parrot_call is vPPP... [1] return values covered: void, Parrot_STRING, Parrot_PMC leo
Re: extend.c:Parrot_call
On Wed, 27 Oct 2004, Leopold Toetsch wrote: E.g. when you have a sub that ends with: set P5, 100 # ret value set I0, 0 # non-prototyped set I3, 0 # no return value invoke P1 # return then P5 will not be passed to the caller. right. but i'm explicitly using .pcc_begin_return/.return/.pcc_end_return to return values from subs run with Parrot_call. my C code then retrieves the return value from I5, which is where the return integer value would be copied. your changes would save me from having to fetch directly from I5, but until those changes are made, is this the right way to be doing this? -jeff
embedding/extending issues
dan asked to keep everyone up to date on any issues i've had while developing mod_parrot. following are the problems i've encountered. --- i currently get parrot's configuration from config_lib.pasm. however, it is not readily apparent from the configuration the libraries and flags required to link with libparrot.a. in particular: * if linking with ICU, which ICU should we use, and which libraries and linker flags are required? * if parrot is linked with libstdc++ behind the scenes (ICU?), it is not listed in the configuration, so i have to add -lstdc++ manually. i may just have to get this from ICU's configuration, but i think parrot, like perl 5 right now, should be able to list all its required dependencies in one place to make life easier for embedders. --- many of the functions i need to perform in an embedding environment (PMC value manipulation, calling parrot subroutines, etc.) are only available if i include extend.h in addition to embed.h. if these headers are to be mutually exclusive (i believe they were meant to be), then all the functionality i just mentioned should be availble to both embedders and extenders in another environment neutral header. --- there is no NCI signature for (char **), which i need this for calling ap_get_basic_auth_pw(request_rec *r, char **). 'B', which is (void **) doesn't seem to work for this situation. the function returns the pointer to the password in a buffer allocated by apache, and that would have to be converted to a parrot string. as for the buffer, in mod_parrot's case memory leaks won't really be a problem here due to apache's memory pools, but i'd say apache is the exception, not the rule. right now i have a small C wrapper that calls ap_get_basic_auth_pw and returns the parrot stringified password in a register, but it's not as clean as it should be. i'm not sure if this is something that can be fixed for all applications of char **, but it doesn't hurt to ask. :) --- that's it -- really no *major* problems to report, and that says a lot about the state of parrot right now. -jeff
parrot authentication handlers
mod_parrot now supports authentication handlers. i'm planning a release in the next few days, including a whitepaper on its architecture, but here's an example of what you can now do. the following handler accepts any basic authentication with a password of 'squawk' (correpsonding httpd.conf follows the code). .namespace [ 'MyAuthHandler' ] # handler.imc .sub _handler .local pmc r .local pmc ap_const .local string pw .local int status find_global ap_const, 'Apache::Constants', 'ap_constants' # get the request_rec object find_type $I0, 'Apache::RequestRec' r = new $I0 # decline if not the initial request $I1 = r.'is_initial_req'( ) if $I1 != 1 goto auth_declined (status, pw) = r.'get_basic_auth_pw'( ) if pw != 'squawk' goto auth_failure $I0 = ap_const['OK'] goto auth_return_status auth_failure: $I0 = ap_const['HTTP_UNAUTHORIZED'] goto auth_return_status auth_declined: $I0 = ap_const['DECLINED'] goto auth_return_status auth_return_status: .pcc_begin_return .return $I0 .pcc_end_return .end - # httpd.conf ParrotInit /tmp/init.pbc ParrotLoad /tmp/Constants.pbc ParrotLoad /tmp/RequestRec.pbc ParrotLoad /tmp/handler.pbc Directory /usr/local/apache2/htdocs/parrot/private ParrotAuthenHandler MyAuthHandler AuthType Basic AuthName Parrot Test Require valid-user /Directory -jeff
Re: parrot authentication handlers
You will, I trust, keep us up to date on all the places where we're making life difficult? :) for sure. but it's actually been quite a smooth ride so far. i have a short list of problems i've had to deal with, and i'll forward them to the list when i get the chance. what i'd really like to see is a language that utilizes parrot objects (AFAIK there isn't one right now). once we have this, we can start writing handlers in a high level language and REALLY have something to show off. ;-) -jeff On Wed, 20 Oct 2004, Dan Sugalski wrote: At 2:27 PM -0400 10/20/04, Jeff Horwitz wrote: mod_parrot now supports authentication handlers. i'm planning a release in the next few days, including a whitepaper on its architecture, but here's an example of what you can now do. Wow. That's... cool. And a bit scary. But definitely cool. I could have an excessive amount of fun with this. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrot authentication handlers
On Wed, 20 Oct 2004, Dan Sugalski wrote: Well, actually scary though it may be, my Work Project uses parrot objects for everything. Whether this is a useful thing or not's an open question (the language lacks subroutines, for example) but... in general, anything that can generate bytecode/PIR/PASM containing a _handler subroutine in a parrot namespace would fit the bill. -jeff
mod_parrot 0.0
i've just uploaded the mod_parrot source: http://www.smashing.org/mod_parrot/dist/mod_parrot-0.0.tar.gz this initial release allows you to register a parrot content handler and encapsulates apache's request_rec structure in a parrot object. unlike the original version, the current mod_parrot uses NCI exclusively -- no new PMCs or opcodes. that's really all it does right now, but in all honesty, getting to this stage should be the hardest part. here's an example of a simple handler: httpd.conf: ParrotInit /path/to/ModParrot/init.pbc ParrotLoad /path/to/my/handler.pbc Location /parrot/squawk SetHandler parrot-code ParrotHandler MyApp /Location handler.imc: .namespace [ 'MyApp' ] .sub _handler .local pmc r load_bytecode '/path/to/lib/Apache/RequestRec.pbc' find_type $I0, 'Apache::RequestRec' r = new $I0 r.'puts'(You said ) $S0 = r.'args'( ) r.'puts'($S0) r.'puts'(\n) .end this is just a start, but it's already a very convincing demonstration of how far parrot has come since the original mod_parrot. what i'd like to see when this is done is HLLs making use of the interfaces and classes provided by mod_parrot to implement mod_perl, mod_python, etc. this way we can write the Apache layer once instead of once for each language. i'm very interested in people's thoughts on this. enjoy! -jeff
Re: nci and the running process image
thanks leo -- it worked! i'm still going to keep my wrapper lib around though, just in case there are platforms where this dlfunc trick doesn't work. but that can easily be detected during configuration. -jeff On Fri, 10 Sep 2004, Leopold Toetsch wrote: Jeff Horwitz wrote: 1. can you still dlopen the running image by passing a NULL string to loadlib? No. Didn't work that way, IIRC 2. can you dlsym (via dlfunc) a statically linked function? Yes. Pass NULL for the library PMC: .sub main @MAIN .local pmc nul null nul .local NCI f .local pmc io io = getstdout f = dlfunc nul, PIO_puts, vIPt f(io, Hello\n) .end One caveat: currenty JITted NCI stub creation is currently turned off and the code in src/nci.c seems to be unable to handle the I signature for passing the interpreter as argument. -jeff leo
nci and the running process image
okay, i'm bringing back a thread from a year ago. for mod_parrot, i'd like to be able to loadlib the running process image (httpd) and dlfunc the various apache API functions. however, while this works for libc functions, and any other functions from shared libraries, it appears not to work for those statically linked into the binary. in fact, loadlib self_lib, nullstring dlfunc func, self_lib, ap_rputs, ptv will reliably segfault on my box (RHEL 3.0) to get around this, i've written a separate shared object that wraps the apache API functions that i want to call from parrot. i call those via NCI, and it works like a charm. so, my questions: 1. can you still dlopen the running image by passing a NULL string to loadlib? 2. can you dlsym (via dlfunc) a statically linked function? if it turns out i CAN'T access the statically linked functions, i'll keep the wrappers around, but i don't want to get too deep into it without making sure first! -jeff
Re: nci and the running process image
I think the problem here is that you need to pass a NULL into dlopen for the filename to get the main image, not a null string. [snip] null $S0 loadlib self_lib, $S0 that's exactly what i was doing -- i should have included more of the actual code in my original mail (i admit, nullstring is confusing): .local string nullstring .local pmc func .local pmc self_lib null nullstring loadlib self_lib, nullstring dlfunc func, self_lib, ap_rputs, itp == segfaults here store_global ap_rputs, func ... if that looks right to you, i can probably convince apache to core dump and send a backtrace. -jeff On Thu, 9 Sep 2004, Dan Sugalski wrote: At 11:02 AM -0400 9/9/04, Jeff Horwitz wrote: okay, i'm bringing back a thread from a year ago. for mod_parrot, i'd like to be able to loadlib the running process image (httpd) and dlfunc the various apache API functions. however, while this works for libc functions, and any other functions from shared libraries, it appears not to work for those statically linked into the binary. in fact, loadlib self_lib, nullstring dlfunc func, self_lib, ap_rputs, ptv will reliably segfault on my box (RHEL 3.0) If this doesn't work then we'll track things down more to see why. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: nci and the running process image
i put my old code back in and got apache to segfault. here's a backtrace,
which confirms the offending code, but it doesn't offer much explanation.
btw, i'm working off a CVS update from last night.
#0 0xb713b11a in Parrot_dlfunc_p_p_sc_sc (cur_opcode=0xb52a80d0,
interpreter=0x815fc50) at core.ops:1110
#1 0xb71a9025 in runops_slow_core (interpreter=0x815fc50, pc=0xb52a80d0)
at src/runops_cores.c:147
#2 0xb71a6a52 in runops_int (interpreter=0x815fc50, offset=0)
at src/interpreter.c:809
#3 0xb71a7854 in runops (interpreter=0x815fc50, offset=0)
at src/inter_run.c:69
#4 0xb71a792f in Parrot_runops_fromc (interpreter=0x815fc50,
sub=0x82dd8f8)
at src/inter_run.c:140
#5 0xb71354ad in Parrot_call (interpreter=0x815fc50, sub=0x82dd8f8,
argcount=0) at src/extend.c:675
#6 0xb70e700c in modparrot_call_sub (interp=0x815fc50,
name=0xb72670e0 _sub2) at parrot.c:45
#7 0xb70e70b1 in modparrot_handler (r=0x815bc90) at mod_parrot.c:60
#8 0x0807c982 in ap_run_handler (r=0x815bc90) at config.c:152
#9 0x0807ce9a in ap_invoke_handler (r=0x815bc90) at config.c:358
#10 0x0806c727 in ap_process_request (r=0x815bc90) at http_request.c:246
#11 0x08068811 in ap_process_http_connection (c=0x8157ba0) at
http_core.c:250
#12 0x08085aea in ap_run_process_connection (c=0x8157ba0) at
connection.c:42
#13 0x0807b507 in child_main (child_num_arg=0) at prefork.c:609
#14 0x0807b6b2 in make_child (s=0x80b67d8, slot=0) at prefork.c:649
#15 0x0807b70b in startup_children (number_to_start=5) at prefork.c:721
#16 0x0807be0d in ap_mpm_run (_pconf=0x80b40a8, plog=0x80ec188,
s=0x80b67d8)
at prefork.c:940
#17 0x08080da2 in main (argc=4, argv=0xbfffae94) at main.c:617
i also dumped some of the library PMC, just in case you can see something.
(gdb) p interpreter-pmc_reg.registers[cur_opcode[2]]-pmc_ext
$3 = (struct PMC_EXT *) 0x0
(gdb) p interpreter-pmc_reg.registers[cur_opcode[2]]-obj
$4 = {u = {_b = {_bufstart = 0x82dd8b0, _buflen = 0}, _ptrs = {
_struct_val = 0x82dd8b0, _pmc_val = 0x0}, _i = {_int_val = 137222320,
_int_val2 = 0}, _num_val = 6.7796834154634202e-316,
_string_val = 0x82dd8b0}, flags = 512, _pobj_version = 0}
-jeff
On Thu, 9 Sep 2004, Dan Sugalski wrote:
At 11:02 AM -0400 9/9/04, Jeff Horwitz wrote:
okay, i'm bringing back a thread from a year ago. for mod_parrot, i'd
like to be able to loadlib the running process image (httpd) and dlfunc
the various apache API functions. however, while this works for libc
functions, and any other functions from shared libraries, it appears not
to work for those statically linked into the binary. in fact,
loadlib self_lib, nullstring
dlfunc func, self_lib, ap_rputs, ptv
will reliably segfault on my box (RHEL 3.0)
I think the problem here is that you need to pass a NULL into dlopen
for the filename to get the main image, not a null string. (Though
that segfault's pretty unpleasant -- could you enable coredumps and
see what the backtrace looks like?) Try doing:
null $S0
loadlib self_lib, $S0
and see if it works better.
If this doesn't work then we'll track things down more to see why.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
mod_parrot progress
i've made some good progress on mod_parrot. since so much has changed in the past year, i decided to rewrite the thing from scratch. here's what i've been able to implement so far: * rewrite for apache 2 (might as well start with the latest) * per-process interpreter persistence (using prefork MPM) * ability to call individual subroutines (good for handlers) it's at the point where you can set mod_parrot as the handler for a location, and it will call a location-specific subroutine when invoked. this is more for proof-of-concept than anything else, but it is quite promising nonetheless. i'm currently working on the apache 2 PMC and ops, which, like most things in apache 2, will require some relearning. once those are stable enough, i'll clean things up and throw the code out there for people to play with. -jeff
Re: Breathing new life into mod_parrot
kevin falcone gave a short mod_parrot talk at YAPC this year. does he want to lay some claim to it? i'd be willing to pick it up if nobody else speaks up -- a decision i'm sure to regret... ;-) on a related note, last year i wrote extproc_parrot, which lets you call parrot bytecode as an oracle stored procedure. this was a proof of concept to show that to show that extproc_perl (stored procedures in perl) would be able to support perl 6 when it became available. it worked, but the embedding interface was too immature to do much else than a simple Hello world example. based on what you're saying here, i plan on picking this up again. i imagine the work will be quite similar to mod_parrot. -jeff On Wed, 25 Aug 2004, Dan Sugalski wrote: Okay, here's the scoop. Ages ago, Clever People whipped up mod_parrot, an apache module that embedded parrot. This was really cool. Alas, Parrot wasn't up to snuff at the time, and the project languished. This wasn't cool, but neither was it unsurprising. I think we're at the point where mod_parrot is feasible, so I'd like to find someone willing to pick up the project and get it going again. This should let us exercise the embedding interface with something a bit less stressful than ponie, and we'll get a chance to work out the API for setting up IO streams, which'll be nice. This is a bit of a big'un, but when it works it'll be the basis for the parrot version of mod_[perl|python|ruby|tcl|Intercal|Forth] so if you've got a bit of time, well... fame and potential madness (or madness and potential fame, I could see it going either way) await. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Breathing new life into mod_parrot
I caught up with Kevin on irc (#parrot on irc.perl.org, for anyone who cares :) and he lacks the tuits to do anything with it. now that the summer is winding down, i've got plenty of those. so i guess that's me volunteering. -jeff
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Thu, 13 May 2004, Jeff Clites wrote: - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? if you're building a shared library, you need to compiler to produce position independent (relocatable) code, which can be enabled with compiler switches (e.g. -fPIC). -jeff
extproc_parrot
after many days of swimming through source code, i've successfully built a
library that lets you embed parrot in oracle. this was important to me
because for extproc_perl (embeds perl in oracle) to have a future with
perl 6, i had to embed parrot. what makes this even cooler is that now we
can embed other languages like python (via pirate or equivalent), BASIC
(sick, i know, but that should be possible now), and whatever other
languages are targeted to parrot.
the library itself is just a proof-of-concept, hacked up from existing
extproc_perl code, but it works:
# hello.pasm
# Sets S31 to Hello, name, where name is the first argument to parrot
# S31 is retrieved by Oracle as the function's return value
main: set S0, Hello,
set S1, P0[1]
concat S0, S1
set S31, S0
SQL select parrot('hello','Jeff') from dual;
PARROT('HELLO','JEFF')
--
Hello, Jeff
hopefully this can jumpstart some discussion on embedding, since there's
an actual application that can make use of it. i'll post the code once i
put together a working Makefile.
embedding API
i'm beginning to explore the concept of embedding parrot so i can eventually add Perl 6 support to extproc_perl (embeds perl in oracle). i was talking with dan at OSCON a few weeks ago about accessing data from an embedded parrot interpreter, and i know he is probably moving it up in his priority list, but is anyone else actively working on a spec for data access? i'm particulary concerned with the getting and setting of arbitrary registers, so i can pass values to subs and retrieve return values. then again, i wonder how that would work with IMCC... chromatic pointed me to brent's stab at this: http://archive.develooper.com/[EMAIL PROTECTED]/msg11922.html but i'm not sure if anything came of that thread. is it appropriate to start thinking about this now or are there major hurdles that still have to be crossed? -jeff
