# New Ticket Created by Ron Blaschke
# Please include the string: [perl #44949]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44949 >
Problem: I came across this when using GnuWin32's PCRE, where the
library is called F, b
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
As of r10458 Parrot doesn't load_bytecode the same file [1] twice anymore.
That is:
load_bytecode 'foo.pir'
load_bytecode 'foo.pasm' # silently ignored
load_bytecode 'foo.pbc'# silently ignored
load_bytecode 'bar/foo.pir'# ok [2]
There is also an interface to query load
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
a workable, documented solution that covers all
operating systems, i'll make sure it's implemented correctly on
windows. this will probably require no more than a few changes to the
hints files in the configure system. if it helps improve the quality
of the the library loading code, i'm all for it.
~jerry
tcl and possibly other users of Parrot are currently suffering from
some obscure uninitialized memory bugs, somewhere hidden inside library
loading (see also #37814 and the attached valgrind log).
I've been looking up and down through the code, but there is no obvious
problem. E.g
Jonathan Worthington wrote:
Hi,
Under Win32 it's common to install stuff...well...anywhere the person
installing it wants. With this patch, we can create binary
distributions for Win32 that don't need Parrot to be installed in the
place that "make install" decides to put it.
Thanks, appl
Hi,
Under Win32 it's common to install stuff...well...anywhere the person
installing it wants. With this patch, we can create binary distributions
for Win32 that don't need Parrot to be installed in the place that "make
install" decides to put it.
Normally libraries are loaded by appending
ment was made that
Parrot would search the current directory first.
It does? Urk. No, not by default. We need to work out some library
loading stuff, but this is *definitely* not going to be the default.
--
Dan
--it's like this---
Dan
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
Time to finish this one and ensconce the API into the embedding interface.
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.
So, to start, here are the semantics I think we're going to n
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
k into the interpreter, but I'm OK with
that. It'll make wedging in more active library loading code easier
in general, which is fine.
--
Dan
--"it's like this"---
Dan Sugalski
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 17, 2003, at 11:07 AM, Leopold Toetsch wrote:
>> *But*, when writing that stuff, one prelim was, that the compiler sees
>> all libs in the same sequence as runtime does. So above code (or your
>> second example) is illegal.
> Okay for now then. But
On Nov 17, 2003, at 11:07 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
My main point is that you can't do conditional library loading. This
code will try to load the "doesnt_exist" library, and I don't think it
should:
branch
Jeff Clites <[EMAIL PROTECTED]> wrote:
> My main point is that you can't do conditional library loading. This
> code will try to load the "doesnt_exist" library, and I don't think it
> should:
> branch HERE
> loadlib P1, "do
On Nov 17, 2003, at 1:59 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:
1) External libraries are being loaded at parse time.
Inside of INS() in imcc/pa
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I've run into a couple of issue with library loading which have their
> origin down inside the IMCC code:
> 1) External libraries are being loaded at parse time.
> Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is call
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:
1) External libraries are being loaded at parse time.
Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at
parse-time when loadlib is encountered. This is causing libr
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
Since I'm working on this now, I figure I'd best give everyone a heads-up
as to what I'm doing.
Right now, I'm working on loading PMCs, both dynamic and static, and the
initialization sequence they go through. I know we've got some of this
down already, but adding in MMD and the need to initialize
31 matches
Mail list logo
