Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
To make this actually work we need some standards, and the ability to
embed bytecode segments into an executable (like, say, parrot :) so
they're always at hand.
The attached patch implements one (evil)
On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
* a PackFile is a PMC (needed e.g. for eval anyway)
* the binary representation is a frozen PackFile
So, pbc2cc.pl needs just to hexify that image. And the entry point
hexify?
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
So, pbc2cc.pl needs just to hexify that image. And the entry point
hexify? IIRC the fastest compilable representation of arbitrary byte blocks
we found for perl 5 was how Encode does it,
Okay, this has been an ongoing source of annoyance, and I think it's
time to address it.
We need to get search paths for loading of stuff into parrot, both at
the pir/pasm assembly level and at runtime for dynamic library
loading.
Now, bizarrely enough, I *don't* want to build this into
Dan Sugalski [EMAIL PROTECTED] wrote:
To make this actually work we need some standards, and the ability to
embed bytecode segments into an executable (like, say, parrot :) so
they're always at hand.
The attached patch implements one (evil) way to do this. (Even if we
don't end up using the
