On Fri Jul 14 06:23:20 2006, coke wrote:
> So, does .loadlib wipe the current .HLL pragma that's in effect? (if
> it's intereacting with the other dot-pragmas, we need to document.)
>
> Regards.
>
> On Jul 14, 2006, at 7:17 AM, Audrey Tang wrote:
>
> >
> > 在 2006/7/14 上午 6:45 時，Audrey Tang 寫到：
So, does .loadlib wipe the current .HLL pragma that's in effect? (if
it's intereacting with the other dot-pragmas, we need to document.)
Regards.
On Jul 14, 2006, at 7:17 AM, Audrey Tang wrote:
在 2006/7/14 上午 6:45 時，Audrey Tang 寫到：
Changing it back to :immediate makes tests pass again.
Al
在 2006/7/14 上午 6:45 時，Audrey Tang 寫到：
Changing it back to :immediate makes tests pass again.
Alternately, skipping the Parrot_register_HLL part in IMCC makes
tests pass again.
After several rounds of trial-and-error, I've committed r13294 that
works around the problem:
* Tcl: Change bac
在 2006/7/14 上午 5:26 時，Leopold Toetsch via RT 寫到：
Err, t/dynpmc/dynlexpad.t is using .loadlib and is testing fine.
Please try to
provide a minimal parrot test showing the problem.
Trying (though it remained a bit elusive), but if you "make
realclean", and then change
languages/tcl/src/tcls
Am Freitag, 14. Juli 2006 04:02 schrieb Will Coleda via RT:
> Whoops, re-opening.
>
> This apparently isn't quite ready yet, as converting tcl to use the new
> syntax results in a nearly- complete fail of the test suite.
>
> Per Audrey: .loadlib 'dynlexpad' stopped working, because
> Parrot_regist
Whoops, re-opening.
This apparently isn't quite ready yet, as converting tcl to use the new syntax
results in a nearly-
complete fail of the test suite.
Per Audrey: .loadlib 'dynlexpad' stopped working, because Parrot_register_HLL
breaks on non-
HLL-group .so files.
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
# New Ticket Created by Autrijus Tang
# Please include the string: [perl #39796]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39796 >
Allison and Chip expressed their go-ahead with a .loadlib pragma, to
replace this cur
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
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"
This might be done as part of vsoni's IMCC refactoring, or as a lexer
action that loads the
library as soon as this dire
31 matches
Mail list logo
