This works now as expected:
m: sub Foo(uint32 :$bar) { say $bar }; Foo(:bar(4))
rakudo-moar ae6177ca2: OUTPUT: «4»
I think, it was fixed with https://github.com/perl6/nqp/commit/fc727ea911
(bisectable pointed to the corresponding NQP bump).
Since the tests in S02-types/native.t are pass
UILD(uint8 :$!x) { }
> }; A.new(:x(5)).perl.say
> rakudo-moar c8ec5a: OUTPUT«Bytecode validation error at
> offset 102 [...]»
> psch: I think the problem is that argument binding is
> *binding*, and you cannot bind to natively typed containers
> or something along those lines
> of
erl.say # but..?
rakudo-moar c8ec5a: OUTPUT«Cannot modify an immutable uint8
in submethod BUILD [...]»
m: class A { has uint8 $.x; submethod BUILD(uint8 :$!x) { }
}; A.new(:x(5)).perl.say
rakudo-moar c8ec5a: OUTPUT«Bytecode validation error at
offset 102 [...]»
psch: I think the problem is
# New Ticket Created by Salvador Ortiz
# Please include the string: [perl #127813]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127813 >
In code like:
class Foo is repr('CPointer') {
...
method Bar(:named, :named2, ui
I've made a new patch that does not require TAP::Harness 3.x, and uses a
Rakudo test with a call to run() to run the Parrot test which loads the
bytecode.
>From 039c18b01b2c12b95de560c5a26bdc7ac9dd7a32 Mon Sep 17 00:00:00 2001
From: Duke Leto
Date: Wed, 9 Jun 2010 13:44:41 -0700
Subject
2010 13:44:41 -0700
Subject: [PATCH] Add test for loading perl6.pbc bytecode
---
build/Makefile.in |2 +-
t/02-embed/01-load.pir | 29 +
t/harness | 14 +-
3 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 t/02-e
Tadeusz Sośnierz wrote:
> On 29-01-2010 14:46:40, Moritz Lenz wrote:
>> Hi,
> Hi, thanks for your response.
>
>> Tadeusz Sośnierz wrote:
>> > However, compiling the code for later use makes problems:
>> >
>> > $ perl6 --target=pir hello.pl > hello.pir
>> > $ parrot /usr/lib/parrot/2.0.0/language
At present. But the development process has not reached a stage where
compiling the main program produces any real benefit.
By the way, if you have used 'make install', then all you need is
/full/path/to/binary/perl6 scriptfile.p6 [args args args ...]
rather than
parrot /full/path/to/binary/pe
Hi,
Tadeusz Sośnierz wrote:
> However, compiling the code for later use makes problems:
>
> $ perl6 --target=pir hello.pl > hello.pir
> $ parrot /usr/lib/parrot/2.0.0/languages/perl6/perl6.pbc hello.pir
You should use parrot to turn the .pir file, not the Perl 6 compiler. So try
parrot hello.pi
2010/1/29 Tadeusz Sośnierz :
> Hello,
> I recently got interested in Perl 6, installed Parrot 2.0.0 and Rakudo
> 2010-01. Running the code works fine:
>
> $ cat hello.pl
> say "Hello, world!"
> $ parrot /usr/lib/parrot/2.0.0/languages/perl6/perl6.pbc hello.pl
> Hello, world!
>
> However, compiling
Hello,
I recently got interested in Perl 6, installed Parrot 2.0.0 and Rakudo
2010-01. Running the code works fine:
$ cat hello.pl
say "Hello, world!"
$ parrot /usr/lib/parrot/2.0.0/languages/perl6/perl6.pbc hello.pl
Hello, world!
However, compiling the code for later use makes problems:
$ perl
On Thu, Feb 05, 2009 at 04:45:50PM -0800, James Keenan via RT wrote:
> On Sat Jun 21 07:39:32 2008, pmichaud wrote:
> > Jonathan says that it's possible to generate and save
> > bytecode within PIR -- see languages/dotnet/src/net2pbc.pir
> > as an example.
> >
>
# New Ticket Created by Kevin Tew
# Please include the string: [perl #60590]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60590 >
On Sun Apr 20 18:38:22 2008, [EMAIL PROTECTED] wrote:
> This ticket exists to track progress on the "M2 Bytecode format"
> milestone. Work on this milestone is occurring in the "pdd13pmc"
> branch.
>
> I am using RT to track progress on this milestone. I will
Thanks.
Applied in r29937.
Francois.
2008/8/1 Robert G. Jakabosky (via RT) <[EMAIL PROTECTED]>:
> # New Ticket Created by Robert G. Jakabosky
> # Please include the string: [perl #57504]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Disp
- Original Message -
From: "Robert G. Jakabosky (via RT)" <[EMAIL PROTECTED]>
Subject: [perl #57504] [PATCH][Lua] Fixed 64bit bug in Lua bytecode
decoder/translator.
Changes to 'languages/lua/t/os.t':
1 test from 'os.t' fails on 64bit systems be
# New Ticket Created by Robert G. Jakabosky
# Please include the string: [perl #57504]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57504 >
Hello everyone,
This is my first patch to the parrot project.
This patch
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56186]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56186 >
Jonathan says that it's possible to generate and save
bytecode within PI
From: "chromatic via RT" <[EMAIL PROTECTED]>
Date: Tue, 06 May 2008 12:18:19 -0700
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). S
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). So
> perhaps the change chromatic made didn't actually fix it . . .
Are you still seeing breakage?
From: Mark Glines <[EMAIL PROTECTED]>
Date: Sun, 27 Apr 2008 09:51:43 -0700
On Thu, 17 Apr 2008 21:33:50 -0400
Bob Rogers <[EMAIL PROTECTED]> wrote:
> I find pdump somewhat useful.
Ok. How do you actually *build* that? There doesn't seem to be a
Makefile rule for it, or ma
On Sun, 27 Apr 2008 09:51:43 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:
> > I find pdump somewhat useful.
>
> Ok. How do you actually *build* that? There doesn't seem to be a
> Makefile rule for it, or maybe I just haven't found it yet.
Oh, nevermind. It's there, I'm just braindead. Thanks!
On Thu, 17 Apr 2008 21:33:50 -0400
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Mark Glines <[EMAIL PROTECTED]>
>Date: Thu, 17 Apr 2008 07:59:03 -0700
>
>. . .
>
>Should this PMC implement the "pdump" functionality
> (src/packdump.c) as well as packfile.c/packout.c?
>
> I find p
On Sun Apr 20 18:38:22 2008, [EMAIL PROTECTED] wrote:
> This ticket exists to track progress on the "M2 Bytecode format"
> milestone. Work on this milestone is occurring in the "pdd13pmc"
> branch.
That should, of course, read "pdd13pbc".
Mark
# New Ticket Created by Mark Glines
# Please include the string: [perl #53128]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53128 >
This ticket exists to track progress on the "M2 Bytecode format"
milest
From: Mark Glines <[EMAIL PROTECTED]>
Date: Thu, 17 Apr 2008 07:59:03 -0700
. . .
Should this PMC implement the "pdump" functionality (src/packdump.c)
as well as packfile.c/packout.c?
I find pdump somewhat useful.
Speaking of "pdump", it seems to be mentioned in various places
On Thu, Apr 17, 2008 at 10:59 AM, Mark Glines <[EMAIL PROTECTED]> wrote:
> :
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
>
> Hi, Jonathan (and everyone else)!
>
> Wednesday on IRC, we discussed the "M
:
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi, Jonathan (and everyone else)!
Wednesday on IRC, we discussed the "M2 Bytecode format" milestone. This
email is my attempt to formalize a plan for this work. I am hoping you
will read
James Keenan via RT wrote:
On Sat Dec 16 21:56:15 2006, allison wrote:
Adequately covered by PDD 13. Leaving ticket to Jonathan to close when
implemented.
Your cage cleaner wants to know ... has this been implemented?
No, not yet.
Jonathan
On Sat Dec 16 21:56:15 2006, allison wrote:
> Adequately covered by PDD 13. Leaving ticket to Jonathan to close when
> implemented.
Your cage cleaner wants to know ... has this been implemented?
Thank you very much.
kid51
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 12:44:02 -0500
From: "Peter Gibbs via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 07:57:13 -0800
Hi Bob
Please try revision 26025. This should be a full fix for the problem I
started working on in
From: "Peter Gibbs via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 07:57:13 -0800
Hi Bob
Please try revision 26025. This should be a full fix for the problem I
started working on in r25990.
Regards
Peter Gibbs
Works like a champ in r26026. Thanks heaps for the swift t
From: "chromatic via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 01:29:53 -0800
On Friday 22 February 2008 19:52:29 Bob Rogers wrote:
> The "[loading list.pbc]" message shows that it is dying in the
> load_bytecode op for this file. (If the bug fails to manifest, the code
>
- Original Message -
From: "Bob Rogers (via RT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 23, 2008 5:52 AM
Subject: [perl #51122] GC bug in bytecode loading (again)
To reproduce, unpack the attached tarball as follows:
copy.
On Friday 22 February 2008 19:52:29 Bob Rogers wrote:
> The "[loading list.pbc]" message shows that it is dying in the
> load_bytecode op for this file. (If the bug fails to manifest, the code
> will fail to find a *.pbc file in fairly short order.)
>
>In GDB, the backtrace from the segfault
Andy also needs we need a pbc disassembler where it dumps .pbc to
pasm, if we don't have one.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
et/Display.html?id=42381 >
>
>
> In the file src/ops/core.ops within the load_bytecode() op there is
> the todo item embedded in a docstring:
>
> "Load Parrot bytecode from file $1, and (TODO) search the library
> path, to locate the file."
>
> This function
tem embedded in a docstring:
"Load Parrot bytecode from file $1, and (TODO) search the library path,
to locate the file."
This functionality needs implementation.
Fixed in r17210.
e entries for "Get python bytecode translator done"
and "Pass the pie-thon test suite". Are these still active
waypoints on the roadmap, or should we remove them?
Pm
Am Montag, 23. Oktober 2006 18:31 schrieb Jonathan Worthington:
> > 1,5) same + range of indices
> >
>
> Will a dynamic character set or encoding library that we load not
> possibly contain more than one character set or encoding and therefore
> need a range of indices too? I have gone with thi
de librar{y,ies}
loaded. In the best case, it was the same opcode library and the opcode numbers
just happen to match. But that's pure luck.
The same argument holds for all other above resources.
I have added a dependencies segment that can be used to list all of the
dynamically loaded resou
Leopold Toetsch wrote:
Indeed. But we probably want to have an UUID to identify
loaded .pasm/.pir/.pbc to avoid loading duplicates.
The UUID as proposed was intended for that; I just hashed up the
definition in the PDD. Er, no pun intended.
As a side note: distinct PBC segments for checksu
Bernhard Schmalhofer wrote:
One thing that I noticed is the naming of the new field UUID.
||| The UUID is |
||| computed by applying the hash function specified
in|
||| the UUID type field over the entire packfile
not |
||
Am Donnerstag, 5. Oktober 2006 23:04 schrieb Bernhard Schmalhofer:
> Shouldn't this field be renamed to something like 'checksum' ? The term
> 'UUID' already has a specific meaning, http://en.wikipedia.org/wiki/UUID.
Indeed. But we probably want to have an UUID to identify
loaded .pasm/.pir/.pbc
Jonathan Worthington schrieb:
Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One thing that I noticed is the naming of the new field UUID.
||| The UU
Am Freitag, 29. September 2006 01:39 schrieb Jonathan Worthington:
> Hi,
>
> I've checked in the proposed bytecode PDD and also most of the changes
> that I discussed with Allison earlier today. Feedback on it would be
> greatly appreciated.
Great work, thanks.
> A coup
Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One of the areas that it would good to have some input on, even if it's
just a "yes, that's sane", i
I just got off the phone with Jonathan Worthington. At YAPC::EU he
agreed to draft a PDD for Parrot's bytecode file format. He has done a
fantastic job. He's checking it in now, so everyone will have a chance
to comment. The PDD incorporates a handful of important changes that
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hey, new guy here.
Welcome. :-)
I'm really interested in the parrot bytecode. What are the files/dirs I
should be looking at to understand everything about packfiles, including
layout, api to deal with it, extracting, w
Hey, new guy here.
I'm really interested in the parrot bytecode. What are the files/dirs I
should be looking at to understand everything about packfiles, including
layout, api to deal with it, extracting, writing, JIT compiling, etc.
I took a look at the parrot bytecode format pag
"Will Coleda via RT" <[EMAIL PROTECTED]> wrote:
This was a very old TODO from the TODO file:
Is this now covered with the recent changes?
[coke - Sun Aug 15 13:27:07 2004]:
Bytecode
Metadata (source line number info, symbol table)
Hard to say; depends if it
This was a very old TODO from the TODO file:
Is this now covered with the recent changes?
> [coke - Sun Aug 15 13:27:07 2004]:
>
> Bytecode
>
> Metadata (source line number info, symbol table)
Joshua Hoblitt via RT wrote:
>>[doughera - Thu Oct 06 07:21:15 2005]:
>>
>>I think this bug can be closed. I just got those tests to pass on
>>Sparc/Solaris 8 with gcc -m64 -mcpu=v9. (Mind you lots of other tests
>>fail, but that's a separate problem.)
>>
>>
>>
>
>
> Jarrko,
>
> Are you OK w
On Thu, 6 Oct 2005, Joshua Hoblitt wrote:
> On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> > > Jarkko,
> > >
> > > I never got a response from anyone. How would you feel about closing
> > > this bug?
> >
> > I don't think it can be closed until at least another big-
On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> -J
>
>
>
>
> >>>
> >>
> >
> > Jarkko,
> >
> > I never got a response from anyone. How would you feel about closing
> > this bug?
>
> I don't think it can be closed until at least another big-endi
-J
>>>
>>
>
> Jarkko,
>
> I never got a response from anyone. How would you feel about closing
> this bug?
I don't think it can be closed until at least another big-endian 64-bit
platform (like IRIX 64 is/was) has been used to verify that things work.
> -J
>
>
>
Does anyone has access to an IRIX machine?
-J
--
On Thu, Sep 22, 2005 at 07:37:44PM +0300, Jarkko Hietaniemi wrote:
>
> >
> > Jarkko,
> >
> > Are there still outstanding issues on IRIX? AFAIK nobody else has been
> > building parrot on that platform.
>
> Unfortunately I no more have access t
>
> Jarkko,
>
> Are there still outstanding issues on IRIX? AFAIK nobody else has been
> building parrot on that platform.
Unfortunately I no more have access to that platform.
> -J
>
>
>
>
On Fri, 15 Apr 2005, Nigel Sandever wrote:
> I struck me a while back that there is a contradiction in idea of a shared,
> 'my' variable.
>
> I want to say lexical, but a var declared with 'our' is in some sense lexical.
Shared-between-threads and shared-between-scopes are orthogonal properties;
u
}
>
>> is called from two threads, do the threads share a single closure or
>> each get their own separate closure?
>
>AFAIK: the closure bytecode is shared,
Great.
>the Closure PMC with the lexical
>pad is distinct.
I think that makes perfect sense. No imp
their own separate closure?
AFAIK: the closure bytecode is shared, the Closure PMC with the lexical
pad is distinct. But that all isn't implemented yet.
> njs
leo
On Thu, 31 Mar 2005 21:17:39 -0500, [EMAIL PROTECTED] (MrJoltCola)
wrote:
> At 05:57 PM 3/31/2005, Nigel Sandever wrote:
> >Is Parrot bytecode reentrant?
>
> Yes.
>
> >That is, if I want to have two instances of a class in each of two
> >threads, will
> >t
At 05:57 PM 3/31/2005, Nigel Sandever wrote:
Is Parrot bytecode reentrant?
Yes.
That is, if I want to have two instances of a class in each of two
threads, will
the bytecode for the class need to be loaded twice?
No, just once.
Also, will it be possible to pass objects (handles/references
Is Parrot bytecode reentrant?
That is, if I want to have two instances of a class in each of two threads,
will
the bytecode for the class need to be loaded twice?
Also, will it be possible to pass objects (handles/references) between threads?
Thanks njs.
On Mon, Dec 13, 2004 at 01:46:49PM -0500, Matthew Zimmerman wrote:
> I'm going to have to stop sending patches if it's going to take 5 hours
> for my messages to get to the list. You guys are so damned fast, I can't
> compete! :)
I think that your messages hit the moderator, as your address wasn
Dan Sugalski (via RT) wrote:
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist t
chromatic wrote:
On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote:
A plain
./parrot foo.pbc
when foo.pbc doesn't exist triggers a core dump on OS X.
The problem is in embed.c not checking the results of
Parrot_locate_runtime_file(). Here's a naive patch.
[snip chromatic's fine patch, very
Dan Sugalski (via RT) wrote:
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist t
Matthew Zimmerman <[EMAIL PROTECTED]> wrote:
> strlen() is puking on the NULL return from Parrot_locate_runtime_file()
> in Parrot_readbc. Attached patch fixes this behavior.
Thanks, applied.
leo
On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote:
> A plain
>
> ./parrot foo.pbc
>
> when foo.pbc doesn't exist triggers a core dump on OS X.
The problem is in embed.c not checking the results of
Parrot_locate_runtime_file(). Here's a naive patch.
Is there a good place to put tests f
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 >
A plain
./parrot foo.pbc
when foo.pbc doesn't exist triggers a core dump on OS
On Wed, 2004-11-03 at 20:08, Milscvaer wrote:
> First, Perl ought to allow bytecode, already compiled,
> to be loaded via a bytecode equivelant to eval(), if
> this cannot be done already.
Please read through the design documents:
http://dev.perl.org/perl6/
Many of these i
First, Perl ought to allow bytecode, already compiled,
to be loaded via a bytecode equivelant to eval(), if
this cannot be done already. This would work the same
way as executing Perl code via eval(). For instance,
perhaps through a new bceval function:
bceval($bytecode);.
In addition, Perl
Well, we were shooting for an end-of-August release, but needless to
say that's not happened. Both Leo and my translators were reasonably
near completion, and need to be pushed that final bit of the way.
Neither of us have the time, so... Anyone want to take a shot? Leo's
builds faster code but
# New Ticket Created by Will Coleda
# Please include the string: [perl #31147]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31147 >
Bytecode
Metadata (source line number info, symbol table)
(From
Fixed a bug in the damn thing (that I'd introduced) and fixed the tests to
actually test properly, including both a Python 2.2 and 2.3 format
bytecode file in the archive.
Rather than mail the thing to people *again* I've just stuck it up for web
snagging.
http://www.sidhe.org/~
The last rev of Python::Bytecode is up and available for poking at.
http://www.sidhe.org/~dan/Python-Bytecode-2.3.tar.gz if you want it.
Handles multiple code objects in a file now (woo!) as well as actually
supporting Python 2.1 and 2.2. I think. Tests would be in order, but I
haven't act
On Mon, 12 Jul 2004, Gregor N. Purdy wrote:
> Leo --
>
> I had tinkered around with this stuff back in 2003, and ended up writing
> Python::Bytecode::SAX to help me visualize bytecode. IIRC, I ran into
> the same issue of only disassembling one code block.
I've finished u
Leo --
I had tinkered around with this stuff back in 2003, and ended up writing
Python::Bytecode::SAX to help me visualize bytecode. IIRC, I ran into
the same issue of only disassembling one code block. I'd be interested
to know if P::B::S treats your example python bytecode any better than
After spending a couple of hours looking at Python::Bytecode and the
Python source, I decided I didn't like the module. So I wrote my own.
I decided Bytecode::Python would work nicely for the name, though it's a
bit close to the namespace. I basically redesigned it, so it should be
Still a bit lacking, 'specially in the documentation department, but I've
got a version that sucks much less than it did, and is possibly even
correct. (Go figure. Surprised me, too... :)
Anyway, if you want to fiddle,
http://www.sidhe.org/~dan/Python-Bytecode-2.2.tar.gz and have at
to give this a
shot. I don't know much about byetcode, but I'd love to save Dan from a
pie in the face (from what I gather he's had a rough go of it lately).
Maybe you could give me an example of some input and the correct output?
Or some documentation?
I've checked out parrot
to give this a
shot. I don't know much about byetcode, but I'd love to save Dan from a
pie in the face (from what I gather he's had a rough go of it lately).
Maybe you could give me an example of some input and the correct output?
Or some documentation?
I've checked out parrot
... is on CPAN (said Dan) and is broken. I'd be glad if people could fix
it and send me a running version ;)
* constants are messed up
* it doesn't disassemble all code objects of a .pbc - just one
$ cd languages/python
$ perl pie-thon.pl -dD some.py
shows more (and AFAIK correct) Python disassem
On Mon, 2004-07-05 at 19:27, Dan Sugalski wrote:
UNARY_NEGATIVE: restore $Px; new $Py, Undef; $Py = $Px * -1; save $Py |
$Px = -1 * $Px
Wouldn't something this do what is desired? I'm just guessing, though.
Brian
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The translation for a number of the python ops depends on whether
> we're going with runtime stack action or compile-time stack->register
> translations.
My experiments[1] show that the latter should be doable, the more because
...
> BINARY_:
>restor
ided by a pipe. (I probably ought to
format this as a table but, well, it's ASCII)
For ops that take a parameter, the parameter name is in lower
case. These are part of the op stream in the python bytecode.
STOP_CODE: end
POP_TOP: restore $Px | noop
ROT_TWO: rotate_up 1 | noop
ROT_THREE: rot
of "directories" (or better Sub PMCs, as outlined by Dan).
We should add a Parrot_packfile_from_buffer(Interpreter, char *buf,
long len) function to the API to load in bytecode files that are
already in memory, and have the base parrot library be a big string
constant in a simple C
Hi,
the code is now in. To use it, uncomment the #define _PARROTLIB in
src/dynext.c:23 (for load_bytecode) and
imcc/imcc.l:815 (for .include instructions)
and create the parrotlib.pbc file:
./parrot -o runtime/parrot/include/parrotlib.pbc \
runtime/parrot/library/parrotlib.imc
WARNIN
t_load_lib) with bytecode versions
("parrotlib").
The problem is how to actually load (byte)code without the help of these
functions. Thats why I've added Parrot_load_bytecode_direct. The "not direct"
version can use parrotlib code to locate the specified file by iterating
t
Jens Rieks <[EMAIL PROTECTED]> wrote:
> @LOAD subs are executed if loaded with load_bytecode, but not when
> they are in inside the initial bytecode loaded by parrot.
Yep. In the first loaded segment @MAIN or the first line is executed. I
don't think that we need @LOAD here too.
> jens
leo
Hi,
@LOAD subs are executed if loaded with load_bytecode, but not when they are in
inside the initial bytecode loaded by parrot.
Please have a look at the attached patch against t/pmc/sub.t for an example.
jens
Index: t/pmc/sub.t
e can register
a C function (via NCI) or a PASM function too.
Sure, but if you've an NCI function you might as well directly
register it and skip the extra indirection. :)
Anyway, it won't be too long before bytecode can register MMD
functions, albeit only bytecode functions. I'll
At 10:28 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ cvs ci library/vtable_constants.pasm ]
Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file
could be easily auto-created like almost all inside
F
Ah, damn, that's what I get for not double-checking my working
Dan Sugalski wrote:
[ cvs ci library/vtable_constants.pasm ]
Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file
could be easily auto-created like almost all inside
F
leo
Dan Sugalski wrote:
At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote:
Did you consider ussng PMCs as instead of plain function pointers. As
outlined a NCI, C, and PASM Sub PMC would be equally just invoke()d.
Yeah, I did. You end up with a twofold problem there--not only do you
have extra indir
At 9:40 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
You've got me confused here.
Well, the question is: Is it allowed to create a continuation in one
subroutine with the destination label being in a different
subroutine?
Oh, OK.
Erm. No. Mostly.
Subs must be considered self-co
Dan Sugalski wrote:
You've got me confused here.
Well, the question is: Is it allowed to create a continuation in one
subroutine with the destination label being in a different subroutine?
.sub _f1
label = get_addr dest_label
_f2(label)
...
dest_label:
.end
.sub _f2
.param int
At 11:12 AM +0100 3/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ mmd functions ]
Another question:
,--[ pdd15 ]--
|While vtable methods may take a continuation, those
|continuations may not escape the
1 - 100 of 429 matches
Mail list logo
