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 d
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
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
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 t
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 parrot
