Search paths and library routines
Dan Sugalski
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.
(Yeah, I know. Yes, I am feeling OK :) At least not the runtime
library loading, and if we can skip it for the assembly level that'd
be fine too. What I'd like to do is pass off the job of finding
generally-unqualified names to a library routine and have it look for
the thing for me. That means we need a method of registering search
paths (which ought be a library routine itself) too. So I'd like that
stuff in the library.
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. Hard to load in your library if your library
finding code's in the library, after all. I'm also not averse to some
sort of special accommodation for low-level library code so it can be
found relatively quickly without a full namespace search if it seems
necessary, though I'm not so sure about that one. We'll see.
Note here that I'm not talking about perl/python/ruby/tcl's standard
library here -- this is parrot's low-level library, stuff that we
need but isn't time-critical enough to warrant opcodes.
So. Anyone want to champion parrot's standard library? And anyone
want to take a shot at getting fully functioning embeddable bytecode,
along with spec'ing out whatever (hopefully minimal) APIs might be
needed to make 'em work?
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent 'Dax' Royal-Gordon
> 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 pbc2cc utility I've written, the patches to
embed.[ch] might be useful; they implement a new embedding interface
function for loading a packfile that's already in memory.)
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
There is no cabal.
Leopold Toetsch
> Dan Sugalski <d...@sidhe.org> 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.
Too evil. No constants, no metadata, a special function to call the
code. BTW a similar approach is already in the tree, this is
embed.c:Parrot_run_native(). Passing a second incarnation the bytecode
would do it.
But, we should do the right thing:
* 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
should of course be just a Parrot Sub. WRT namespace, we can attach it
to either the Library or the ParrotInterpreter PMC. So we could do:
$P0 = getinterp
$P1 = $P0."_lib_loader"(args)
runtime/parrot/library/parrot_lib.imc is a starting point for the
functionality, but should be rewritten to use OO and a modular approach.
Static configuration should be embedded as a frozen image, as outlined
in a mail a few days before the last release.
leo
Nicholas Clark
> Brent 'Dax' Royal-Gordon <bren...@gmail.com> 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? IIRC the fastest compilable representation of arbitrary byte blocks
we found for perl 5 was how Encode does it, which was {} initialisers such as
static const U8 enctable[512] = { 194,128,194,129,194,130,194,131,194,132,
194,133,194,134,194,135,194,136,194,137,194,138,194,139,194,140,194,141,194,
...
239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255 };
Nicholas Clark
Leopold Toetsch
> 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, which was {} initialisers such as
> static const U8 enctable[512] = { 194,128,
Ok, ok. It has to be readable by the compiler, that's all. Decimal is
better for opcodes anyway.
> Nicholas Clark
leo