chromatic wrote:
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
Oh, you mean the fact that much of the time it's not loading bytecode at
all? It has crossed my mind, but the irritation hasn't
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
> load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
I wonder if there could be a variant that evaluates the code with the
appropriate compiler, too:
load_{something} 'file', 'compiler_name'
Leopold Toetsch wrote:
This means, we'd have:
.include "file.pasm/.pir" ... load macros or constants (no code)
>
load_bytecode "file.pbc" ... load a "module"
$P0 = loadlib "file" ... load a shared lib (pmc or ops)
.loadlib "file"... same during compilation
Th
On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote:
> >- If another HLL wants to create a Perl6Str, how does it do it?
> >- If another HLL wants to create a subclass of Perl6Str...?
I just realized that I misinterpreted these questions. I thought that the
first question was a
Patrick R. Michaud wrote:
IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries...
.include is currently compile-time only, and only works with .pir/.pasm
...
Yes, the suggestion is an extreme reuse of existing syntax. Something
that's good to avoi
Will Coleda wrote:
I would prefer .include to maintain its current meaning. Not everything
you .include is a complete PIR program.
I think the most common case at the moment is stitching together .pir
files generated by PGE/TGE. Which is useful.
Allison
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:
> So the type is bound to a number in the .pbc? Isn't this dangerous for
> types that are not built in? Couldn't this number mean something
> different if libraries happen to get loaded in a different order?
The declaration order of PM
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>Date: Wed, 12 Jul 2006 21:15:44 +0200
>
>On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
>> The perl6 compiler has a custom string type, currently called
>
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> > Well, there was already one very legitimate usage of compile time
> > loadlib, which is now using C<.loadlib> for that:
>
> We certainly need both compile-time and runtime loading of libraries.
> So,
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 21:15:44 +0200
On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > >
> > > $P0 = new 'Perl6Str'
> >
> > I tend to use:
> >
> > .local int str_type
> > str_t
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> >Well, there was already one very legitimate usage of compile time
> >loadlib, which is now using C<.loadlib> for that:
>
> We certainly need both compile-time and runtime loading of libraries.
> So, it
On Jul 12, 2006, at 3:18 PM, Allison Randal wrote:
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:
We certainly need both compile-time and runtime loading of
libraries. So, it's just a question of wh
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > > The perl6 compiler has a custom string type, currently called
> > > "Perl6Str". What's the canonical
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:
We certainly need both compile-time and runtime loading of libraries.
So, it's just a question of which syntax to use for which case.
chromatic suggests
On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
> an object of that type?
>
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = ne
On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > The perl6 compiler has a custom string type, currently called
> > "Perl6Str". What's the canonically correct mechanism for creating
> > an object of that type?
> >
> > $P
On 7/12/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
The perl6 compiler has a custom string type, currently called
"Perl6Str". What's the canonically correct mechanism for creating
an object of that type?
$P0 = new 'Perl6Str'
$P0 = new .Perl6Str
$P0 = new [ 'Perl6Str' ]
At dif
On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
> an object of that type?
>
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = new [ 'Perl6S
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib
> directive shouldn't operate at :immediate time, but at :init time,
> because it's more common to want a library to load when you run the code
> than to load o
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib
> directive shouldn't operate at :immediate time, but at :init time,
> because it's more common to want a library to load when you run the code
> than to load o
It occurs to me, after thinking about it overnight, that the .loadlib
directive shouldn't operate at :immediate time, but at :init time,
because it's more common to want a library to load when you run the code
than to load only when you compile the code.
Which leaves us with :immediate for the
On Wed, Jul 12, 2006 at 12:14:21AM -0400, Audrey Tang wrote:
> Allison and Chip expressed their go-ahead with a .loadlib pragma, to
> replace this current use:
>
> .sub foo :immediate
> $I0 = loadlib "XXX"
> .end
>
> With this:
>
> .loadlib "XXX"
Done, r13262.
Actually loading libs matc
23 matches
Mail list logo
