On Tue, Dec 13, 2005 at 07:01:01PM +, Nicholas Clark wrote:
> On Mon, Dec 12, 2005 at 10:08:24AM -0800, Chip Salzenberg wrote:
> > Neat - this is a fine approximate solution until we have real pbc
> > hashing, and *may* continue to be necessary even with hashing,
> > depending on whether we can
On Mon, Dec 12, 2005 at 10:08:24AM -0800, Chip Salzenberg wrote:
> On Mon, Dec 12, 2005 at 01:16:35PM +0100, Leopold Toetsch wrote:
> > As of r10458 Parrot doesn't load_bytecode the same file [1] twice anymore.
>
> Neat - this is a fine approximate solution until we have real pbc
> hashing, and *
On Mon, Dec 12, 2005 at 01:16:35PM +0100, Leopold Toetsch wrote:
> As of r10458 Parrot doesn't load_bytecode the same file [1] twice anymore.
Neat - this is a fine approximate solution until we have real pbc
hashing, and *may* continue to be necessary even with hashing,
depending on whether we ca
On Dec 6, 2005, at 16:08, jerry gay wrote:
On 12/6/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
2) I'm very much inclined to remove the Win32 special casing (see also
r8673)
There are already 2 possibilities to specify the runtime prefix (where
libs are searched).
a) perl Configure --prefix
On 12/6/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 2) I'm very much inclined to remove the Win32 special casing (see also
> r8673)
>
> There are already 2 possibilities to specify the runtime prefix (where
> libs are searched).
> a) perl Configure --prefix=foo
> This sets the built in pre
At 11:00 AM -0400 9/1/04, Aaron Sherman wrote:
On Sat, 2004-08-28 at 16:17, Dan Sugalski wrote:
Time to finish this one and ensconce the API into the embedding interface.
That reminds me, I was reading P6&PE yesterday, and I came across a
scary bit on loading of shared libraries. The statement was
On Sat, 2004-08-28 at 16:17, Dan Sugalski wrote:
> Time to finish this one and ensconce the API into the embedding interface.
That reminds me, I was reading P6&PE yesterday, and I came across a
scary bit on loading of shared libraries. The statement was made that
Parrot would search the current di
On Aug-28, Dan Sugalski wrote:
>
> We dynamically load libraries. Whee! Yay, us. We need a set of
> semantics defined and an API to go with them so we can meaningfully
> and reliably work with them.
Hm. Today I was working with the current implementation of this stuff,
and uncovered a bunch of
At 6:38 PM +0200 4/28/04, Jens Rieks wrote:
On Wednesday 28 April 2004 17:17, Dan Sugalski wrote:
1 - no good, try the next entry in the array
0 - Good, done
-1 - good, try the next entry in the array anyway
exception - something went wrong
The string parameter is the unqualified n
On Wednesday 28 April 2004 17:17, Dan Sugalski wrote:
> 1 - no good, try the next entry in the array
> 0 - Good, done
> -1 - good, try the next entry in the array anyway
> exception - something went wrong
>
> The string parameter is the unqualified name of the library to load.
> The par
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 10, 2003 at 05:44:05PM +0200, Leopold Toetsch wrote:
>> >> - the opcode numbers are assigned dynamically:
> What happens if the opcode library is rebuilt with more ops after the
> bytecode using it is compiled and frozen to disk?
Its as inva
On Fri, Oct 10, 2003 at 05:44:05PM +0200, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Fri, 10 Oct 2003, Leopold Toetsch wrote:
>
> >> - the opcode numbers are assigned dynamically:
> >> When you load an oplib containing 100 ops, they get op numbers
> >> e.g. 1206 ..
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Oct 2003, Leopold Toetsch wrote:
>> - the opcode numbers are assigned dynamically:
>> When you load an oplib containing 100 ops, they get op numbers
>> e.g. 1206 ... 1305. Next oplib starts at 1306 ...
>> - on load all runcores are notified
On Fri, 10 Oct 2003, Leopold Toetsch wrote:
> - the opcode numbers are assigned dynamically:
> When you load an oplib containing 100 ops, they get op numbers
> e.g. 1206 ... 1305. Next oplib starts at 1306 ...
> - on load all runcores are notified to use the new oplib function
> or address t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right now there's a load_pmc op, which goes along with the load_opcode_lib
> and loadlib ops. I'd like to unify that
I'll start the opcode load thingy, based on my experimental code I has
posted here mid-March.
The basics are:
- assembler and runtime mus
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Next, the sequence of loading.
> Right now there's a load_pmc op
Gone.
> and loadlib ops. I'd like to unify that
Done.
> When we load a library, the bytecode should probe for and, if it exists,
> call Parrot_lib_load_%s, where %s is the library name.
On Mon, 29 Sep 2003, Dan Sugalski wrote:
> Firstly, we're adding a new method INIT to the .pmc file. *If* it exists
This, by the by, corresponds to the _init method in loading, and is called
on each thread instantiation. We're also going to add a LOAD method, again
optional, which will be called
17 matches
Mail list logo
