Newsgroups: perl.perl6.internals
Path: controlnews3.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <par...@jensbeimsurfen.de>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 26074 invoked from network); 21 May 2004 11:33:49 -0000
Received: from x1.develooper.com (63.251.223.170)
  by onion.develooper.com with SMTP; 21 May 2004 11:33:49 -0000
Received: (qmail 14538 invoked by uid 225); 21 May 2004 11:33:48 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 14528 invoked by alias); 21 May 2004 11:33:48 -0000
X-Spam-Status: No, hits=3.3 required=7.0
	tests=RCVD_IN_DYNABLOCK,RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS
X-Spam-Check-By: la.mx.develooper.com
Received: from blao.de (HELO mail.t0c.de) (217.160.165.51)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Fri, 21 May 2004 04:33:47 -0700
Received: from [192.168.2.100] (p50921DFC.dip.t-dialin.net [80.146.29.252])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mail.t0c.de (Postfix) with ESMTP
	id 55ED81780F4; Fri, 21 May 2004 13:33:43 +0200 (CEST)
Subject: bytecode library
Date: Fri, 21 May 2004 13:33:22 +0200
User-Agent: KMail/1.6.1
References: <20040519211439.28881.qmail@x1.develooper.com> <200405200813.i4K8DTT06304@thu8.leo.home>
In-Reply-To: <200405200813.i4K8DTT06304@thu8.leo.home>
MIME-Version: 1.0
Content-Disposition: inline
To: l...@toetsch.at
Cc: perl6-intern...@perl.org
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Message-ID: <200405211333.22233.parrot@jensbeimsurfen.de>
X-Spam-Rating: onion.develooper.com 1.6.2 0/1000/N
Approved: n...@nntp.perl.org
From: par...@jensbeimsurfen.de (Jens Rieks)

Hi,

On Thursday 20 May 2004, Leopold Toetsch wrote:
> I know that's too early to comment much WRT these changes. Could you
> please outline the goals that you want to achieve?
My goal is to replace the path handling code (imcc's include_file,=20
Parrot_load_bytecode and Parrot_load_lib) with bytecode versions=20
("parrotlib").

The problem is how to actually load (byte)code without the help of these=20
functions. Thats why I've added Parrot_load_bytecode_direct. The "not direc=
t"=20
version can use parrotlib code to locate the specified file by iterating=20
through a list of "directories" (or better Sub PMCs, as outlined by Dan).

The parrotlib bytecode can be located with the help of parrot's "config=20
system" (if it is not part of parrotlib), with an hardcoded file location o=
r=20
maybe even linked directly to parrot on platforms supporting the "exec"=20
functionality.

> That code following here is for loading C extensions: NCI, dynamic opcode
> libraries and dynamic classes. How will you load these shared libs, when
> you deactivate the loader?
I think it is possible to do the load and init stuff completely with byteco=
de.=20
If this is not feasible, the bytecode can at least be used to get the absol=
ute=20
filename of the library to load.

> But the first problem we have to address is: where is the runtime stuff.
> Your patch just adds one more hardcoded path. We have *first* to do
> something for running parrot{,exe} outside it's build dir, e.g.:
>
> $ cd languages/bf
>
> $ make
> ../../parrot -o bf.pbc bf.pasm
> string_set_data_directory: ICU data files not found(apparently) for \
> =A0directory [blib/lib/icu/2.6.1]make: *** [build] Error 1
Yes, thats one of the problems I want to tackle.
We should IMO hardcode the location of parrot's runtime directory (as=20
discussed some time ago), and make it overrideable with an environment=20
variable and command line switch.=20
Maybe we can also use parrotlib to setup the ICU's data files? I have not=20
looked at the ICU stuff yet.



Parrotlib has an initialization function that creates an hash with function=
=20
names as keys, and signatures as values. If you use
	Parrot_library_query(interpreter, "foo", ...)
the hash is used to lookup the signature of "foo", and if one is found the=
=20
method with the same name is called with this signature. The return value o=
f=20
the bytecode function will be the value returned by Parrot_library_query.

Example:
	STRING *name =3D string_from_cstring(...);
	name =3D Parrot_library_query(interpreter, "include_file_location", name);
After this, name will be either a null string (if the file was not found), =
or=20
the full name of the given file.
Whether its an absolute or relative path is up in the air...

jens

PS: we need the stat op!