# New Ticket Created by Will Coleda
# Please include the string: [perl #57796]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57796
When adding new files to the repository, please be sure to not only
add them to the
raised in this ticket?
Thank you very much.
kid51
I'm going to reject this ticket; if I we want to add more information regarding
the ops
metadata, we should specifically mention the metadata we want to track.
Regards.
--
Will Coke Coleda
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 Mon Sep 26 21:09:20 2005, jhoblitt wrote:
So would you like to merge this with 31554 or just close them both?
RT 31554 was marked Obsolete by Leo in October 2005. Can anyone assess
the current pertinence of the issues raised in this ticket?
Thank you very much.
kid51
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
On 31/10/2007, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
On Oct 31, 2007 4:35 AM, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 30 October 2007 19:27:52 James Keenan wrote:
As has been the case lately, a couple of 'pirc'-related files have
been failing metadata and coding standards tests
On Oct 31, 2007 4:35 AM, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 30 October 2007 19:27:52 James Keenan wrote:
As has been the case lately, a couple of 'pirc'-related files have
been failing metadata and coding standards tests. Here's results
from make test on Linux tonight (approx
'-related files have
been failing metadata and coding standards tests. Here's results
from make test on Linux tonight (approx rev 22628).
t/distro/file_metadata...# Collecting svn:mime-
type attributes...
# Collecting svn:keywords attributes
PROTECTED] wrote:
On Oct 31, 2007 4:35 AM, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 30 October 2007 19:27:52 James Keenan wrote:
As has been the case lately, a couple of 'pirc'-related files have
been failing metadata and coding standards tests. Here's results
from make test
of 'pirc'-related files have
been failing metadata and coding standards tests. Here's results
from make test on Linux tonight (approx rev 22628).
t/distro/file_metadata...# Collecting svn:mime-
type attributes...
# Collecting svn:keywords
On 31/10/2007, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
sorry, it should have read r22631.
On Oct 31, 2007 11:33 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
Is it ok to revert r22361 now (where chromatic removed the linelength
test from the set of default run tests)?
If the tests are
metadata and coding standards tests. Here's results
from make test on Linux tonight (approx rev 22628).
t/distro/file_metadata...# Collecting svn:mime-
type attributes...
# Collecting svn:keywords attributes...
# Collecting svn:eol-style attributes...
# Failed test (t
On Tuesday 30 October 2007 19:27:52 James Keenan wrote:
As has been the case lately, a couple of 'pirc'-related files have
been failing metadata and coding standards tests. Here's results
from make test on Linux tonight (approx rev 22628).
t/distro/file_metadata
for those of you who might be updating your working copies from svn
(post r10933) and wondering why so many files are changing, i did some
svn metadata cleanup today.
~ the set svn:mime-type property should now be set appropriately based
on file extension. i paid close attention to .t, .xml, .png
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)
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's talking about HLL
# New Ticket Created by Will Coleda
# Please include the string: [perl #31147]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31147
Bytecode
Metadata (source line number info, symbol table)
(From
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #24922]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24922
We need to revamp the ops file parsers to allow easier addition of
ops metadata
Regrettably, this won't be committed for 0.0.12 release since it is
definitely new
feature. If I commit now Leo would probably pummel me with flaming pumpkins,
so I'm going to play nice and follow the rules.
This is what I have currently in my working copy of imcc. I think this does
what we want
Melvin Smith [EMAIL PROTECTED] wrote:
Basically all metadata has to be collected before any code can be emitted.
I was thinking of generating an _init routine that creates the classes,
so we have several possibilities.
Why? A class definition should AFAIK end up in the constant table
On Thu, 23 Oct 2003, Melvin Smith wrote:
I'm working on getting class syntax added to PIR.
It appears IMCC's way of emitting instructions as it collects compilation
was a mistake (mine) and isn't going to work for metadata that needs to
be initialized first.
Basically all metadata has
At 08:36 AM 10/24/2003 +0200, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
Basically all metadata has to be collected before any code can be emitted.
I was thinking of generating an _init routine that creates the classes,
so we have several possibilities.
Why? A class
Melvin Smith [EMAIL PROTECTED] wrote:
At 08:36 AM 10/24/2003 +0200, Leopold Toetsch wrote:
Why? A class definition should AFAIK end up in the constant table as a
class PMC specifying the inheritance and attributes. So a .class
directive is from parsing POV a constant definition, like a string
I'm working on getting class syntax added to PIR.
It appears IMCC's way of emitting instructions as it collects compilation
was a mistake (mine) and isn't going to work for metadata that needs to
be initialized first.
Basically all metadata has to be collected before any code can be emitted.
I
On Tue, 21 Oct 2003, Joseph Ryan wrote:
Will there be a way to specify which methods belong to the class in the
metadata? Or will Method namespaces just have to match class names so
that a lookup can be done?
Hadn't planned on having any particular declaration of methods
PIR and assembly to ignore this for the
moment, at least until the metadata segment is better defined. Which will
be soon, though I'd rather someone else do the bytecode modification as
it's been a long time since I've had my hand in there.
Well we can hide this under PIR. Once PIR is set, we
Here's the scoop:
Metadata for classes is simple. In PIR/assembly, they're noted with
.things:
.class Foo
.is bar
.is baz
.does some_thing
.member x
.member y
.member z
.ssalc
Unless someone tells me that ssalc is horribly obscene in some relatively
common language
Dan Sugalski wrote:
Here's the scoop:
Metadata for classes is simple. In PIR/assembly, they're noted with
.things:
.class Foo
.is bar
.is baz
.does some_thing
.member x
.member y
.member z
.ssalc
Unless someone tells me that ssalc is horribly obscene in some relatively
common
At 07:44 PM 10/21/2003 -0400, Joseph Ryan wrote:
Dan Sugalski wrote:
Here's the scoop:
Metadata for classes is simple. In PIR/assembly, they're noted with
.things:
.class Foo
.is bar
.is baz
.does some_thing
.member x
.member y
.member z
.ssalc
Will there be a way to specify
At 02:55 PM 10/21/2003 -0400, Dan Sugalski wrote:
Here's the scoop:
Metadata for classes is simple. In PIR/assembly, they're noted with
.things:
.class Foo
.is bar
.is baz
.does some_thing
.member x
.member y
.member z
.ssalc
Unless someone tells me that ssalc
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
James Michael DuPont wrote:
--- [EMAIL PROTECTED] wrote:
Mike --
Thats a lot of metadata.
OK that sounds fine. My current problems with the graphs of
meta-data
are the speed of loading.
When you arrange the meta-data
If memory serves me right, James Michael DuPont wrote:
JVM had a LineNumberTable and VarNameTable for debugging which were
declared as ``attributes'' to each method in the .class tree.
I suppose VarNameTable is totally irrelevant for Parrot ...
I dont know that, what is it? Variable
Dear All,
I just wanted to ask about a conclusion on the bytecode metadata.
Here are the things I would like to know about a given bytecode :
what line (maybe column) it comes from
Possible comments about it.
If it is a method call, what is the method name,signature,locatoin
If it is a variable
James Michael DuPont wrote:
Dear All,
I just wanted to ask about a conclusion on the bytecode metadata.
Here are the things I would like to know about a given bytecode :
what line (maybe column) it comes from
File/line information is already there (imcc -d -o...) and working
[EMAIL PROTECTED] writes:
Mike --
Thats a lot of metadata. Sounds like maybe the metadata is primary
and the bytecode is secondary, in which case perhaps what you
really want is a (metadata) tree decorated with bytecode rather than
a (bytecode) array decorated with metadata.
The bytecode
b. --
I agree that under normal circumstances the bytecode is primary.
I was observing that as more and more metadata is considered,
eventually its quantity (measured, say, in bytes) could approach
or even exceed that of the raw bytecode. In cases where one
would feel such a quantity of metadata
to reconstruct the tree for
debugging or reverse engineering (if the compiler that produced the
bytecode whats to produce this).
I would like to prototype some meta-data storage of my gcc
The tree metadata can sure be some kind of intermediate output of the
compiler (the output of the compiler front end
this).
Optimisations ? ... (bang, there goes the line numbers ;)
Normally you dont need this information, I just want to know how I can
store it if I *do* need it.
The metadata from the c++ that i am extracting even exceeds the size of
the sourcecode itself.
yeah, that is the idea. Reflection
--- [EMAIL PROTECTED] wrote:
Mike --
Thats a lot of metadata. Sounds like maybe the metadata is primary
and the bytecode is secondary, in which case perhaps what you
really want is a (metadata) tree decorated with bytecode rather than
a (bytecode) array decorated with metadata.
Fair
run the
debugger in the gcc, it produces a dwarf file, that is the type of
meta-data i am talking about.
Normally you dont need this information, I just want to know how I
can
store it if I *do* need it.
The metadata from the c++ that i am extracting even exceeds the
size
James Michael DuPont wrote:
--- [EMAIL PROTECTED] wrote:
Mike --
Thats a lot of metadata.
OK that sounds fine. My current problems with the graphs of meta-data
are the speed of loading.
When you arrange the meta-data as a single opcode stream, you have ~zero
load time for the mmap()ed
On Sun, 26 Jan 2003, James Mastros wrote:
just define a new packfile section, SIGNATURE, that is defined to be a
cryptographic signature of all sections previous to it in the file.
I'm battling with this in another file format at the moment; if possible can
we please *not* have it sensitive to
If memory serves me right, James Michael DuPont wrote:
Bah. That's parrot -o foo.o foo.pmc isn't it?
And if we make C a parrot supported language we can even build parrot
with parrot?
Hmmm... bootstrapping
1. The gcc : I have %99 of the information about the function bodies of
Nicholas Clark [EMAIL PROTECTED] writes:
[...]
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
will this ever compile?
void data[] is not allowed, and even char data[] is an incomplete
type, so
On 27 Jan 2003, Juergen Boemmels wrote:
Nicholas Clark [EMAIL PROTECTED] writes:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
I agree with the roughly bit, but I'd suggest ensuring that you put
Juergen Boemmels wrote:
Nicholas Clark [EMAIL PROTECTED] writes:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
will this ever compile?
It's similar to opcode_t *data. If size == 0, no data follow in byte
stream. byte_code_{un,}pack is
--- Juergen Boemmels [EMAIL PROTECTED] wrote:
Nicholas Clark [EMAIL PROTECTED] writes:
I guess in future once the normal JIT works, and we've got the pigs
flying
nicely then it would be possible to write a Not Just In Time
compiler that
saves out assembly code and relocation
Sean O'Rourke wrote:
How true. On Solaris, for example, mmap's are aligned on 64k boundaries,
which leads to horrible virtual address space consumption when you map
lots of small things. If we're mmap()ing things, we want to be sure
they're fairly large.
Is one PBC file a small thing? Or in
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote:
The problem's actually _virtual_ memory use/fragmentation, not physical
memory or swap. Say you map in 10k small files -- that's 640M virtual
memory, just over a fourth of what's available. Now let's say you're also
using mmap()
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Is one PBC file a small thing? Or in other words, should we have a low
limit where we start again to malloc and copy PBC files?
Configure option? Commandline switch?
Maybe a config option? The app I'm thinking of was pathological, in that
it mapped
On 01/25/2003 4:26 AM, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also some way of storing a cryptographic signature in the file, so
that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
The palladium parrot :)
Just because it's possible to use a
On 01/26/2003 2:18 PM, Sean O'Rourke wrote:
Maybe a config option? The app I'm thinking of was pathological, in that
it mapped in thousands of 20-byte files. Now that I think about it,
unless someone implements something very strangely (or has absolutely
enormous numbers of threads) this
Nicholas Clark wrote:
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
I agree with the roughly bit, but I'd suggest ensuring that you put
in enough bits to get data[] 64 bit aligned.
If
On Sat, Jan 25, 2003 at 10:26:22AM +0100, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also some way of storing a cryptographic signature in the file, so that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
The palladium parrot :)
naa. I said
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linux box's /usr/share/man/man1 directory.
Linux is not the universe, though.
I have it changed to use mmap() bytecode (other segments, with
Nicholas Clark wrote:
On Sat, Jan 25, 2003 at 10:26:22AM +0100, Leopold Toetsch wrote:
The palladium parrot :)
naa. I said signed by you, not signed by the RIAA^WMPAA^WMicrosoft
Yes, of course. I would do this with a personalized version of
fingerprint.c and generate a separate
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linux box's /usr/share/man/man1 directory.
Linux is not the universe, though.
How true.
On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote:
This means that a Perl server that relies on a lot of modules, and which
forks for each connection (imagine a Perl-based web server), doesn't
consume acres of swap space just to have an in-memory image per Perl
process, of all the
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linux box's
On Sat, Jan 25, 2003 at 10:04:37AM -0500, Jason Gloudon wrote:
On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote:
This means that a Perl server that relies on a lot of modules, and which
forks for each connection (imagine a Perl-based web server), doesn't
consume acres of swap
On Sat, Jan 25, 2003 at 11:43:40PM +, Dave Mitchell wrote:
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that
On Sun, Jan 26, 2003 at 12:40:19AM +, Nicholas Clark wrote:
On Sat, Jan 25, 2003 at 11:43:40PM +, Dave Mitchell wrote:
Okay, I just ran a program on a a Solaris machines that mmaps in each
of 571 man files 20 times (a total of 11420 mmaps). The process size
was 181Mb, but the total
On Sat, 25 Jan 2003, Dave Mitchell wrote:
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that successfully mmap-ed in
Juergen Boemmels wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
It might be even possible to dump the jitted code. This would increase
the startup. Then strip the bytecode to reduce the size of the file
and TADA: Yet another new binary format.
When you then are able to to get the same
Dan Sugalski wrote:
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
This is the way the bytecode currently works, and we will *not* switch
to any bytecode format that doesn't at least allow the
Leopold Toetsch wrote:
I'm currently simplifying the whole packfile routines. It still does
read the old format, but the compat code is centralized now in one place.
Registered types are consecutively numbered, unknown types still get
unpacked or dumped:
typedef enum {
PF_DIR_SEG,
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
How many mmap's can $arch have for one program and for all?
Could we hit some limits here, if every module loaded gets (and stays)
mmap()ed.
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linux
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
How many mmap's can $arch have for one program and for all?
Could we hit some limits here, if every module loaded gets (and stays)
mmap()ed.
I just wrote a quick C program that
. This should allow for a
fairly quick lookup by type. If you think that there might be a demand
for multiple instances of the same type of metadata, you may want to add
a chunk ID of some sort.
It might be useful for making portable fat bytecode.
On Thu, Jan 23, 2003 at 01:39:03PM -0500, Dan
Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on disk) or in the bytecode (in memory).
I
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have
in either the packfile
discussing
metadata. What sorts of metadata do people think are useful to have in
either the packfile (on disk) or in the bytecode (in memory).
My current idea for the in memory format of the bytecode is this:
One bytecodesegment is a PMC consisting of three parts the actual
bytecode (a flat array
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
--- chromatic [EMAIL PROTECTED] wrote:
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start
discussing
metadata. What sorts of metadata do people think
--- Dave Mitchell [EMAIL PROTECTED] wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply
Dave Mitchell [EMAIL PROTECTED] writes:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be
At 10:31 PM +0100 1/23/03, Juergen Boemmels wrote:
Dave Mitchell [EMAIL PROTECTED] writes:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
Dan Sugalski [EMAIL PROTECTED] writes:
This might be possible if the byteorder, wordsize, defaultencoding
etc. are the same in the file on disk and the host.
Which will generally be the case, I expect. Tell a sysadmin that they
can reduce the memory footprint of mod_parrot by 50% by running
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# Dan Sugalski:
# # Since it looks like it's time to extend the packfile
# format and the #
# in-memory bytecode layout, this would be the time to start
# discussing #
# metadata. What sorts of metadata do people think are useful
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply
At 11:48 AM -0800 1/23/03, chromatic wrote:
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think
and the
in-memory bytecode layout, this would be the time to start
discussing
metadata. What sorts of metadata do people think are useful to have
in
either the packfile (on disk) or in the bytecode (in memory).
My current idea for the in memory format of the bytecode is this:
One bytecodesegment
At 2:48 PM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# Dan Sugalski:
# # Since it looks like it's time to extend the packfile
# format and the #
# in-memory bytecode layout, this would be the time to start
# discussing #
# metadata. What sorts
--- Brent Dax [EMAIL PROTECTED] wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# Dan Sugalski:
# # Since it looks like it's time to extend the packfile
# format and the #
# in-memory bytecode layout, this would be the time to start
# discussing #
# metadata. What
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have in
either the packfile (on disk) or in the bytecode (in memory
At 7:23 AM +0100 1/24/03, Leopold Toetsch wrote:
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have
in either the packfile (on disk) or in the bytecode (in memory).
Keep in mind
--- Dan Sugalski [EMAIL PROTECTED] wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have
in either the packfile (on disk
Dear list,
Please excuse my ignorance, and if the answer is just RTFM, then please
shoot me.
What is the plan for declaring Object Oriented APIs in parrot.
In dotnet il, you have a OO concept built into the assembly,
but parrot seems to be missing this. Is there a plan for supporting
the high
On Fri, 19 Apr 2002, Andrew J Bromage wrote:
G'day all.
On Fri, Apr 19, 2002 at 12:44:49AM -0400, Dan Sugalski wrote:
Ah. Hmmm. Well, we're already attaching some metadata to ops in a
different way--that's what the op and inline keywords are doing. For
metadata that use parameters I
G'day all.
This patch allows op-writers to store optional metadata to be
associated along with an op. Very simple key-value stuff at the
moment; may get fancier later.
Once again, this is mostly for the optimizer's benefit, so you
can note things like if an op affects the state of the world
At 1:04 PM +1000 4/19/02, Andrew J Bromage wrote:
This patch allows op-writers to store optional metadata to be
associated along with an op. Very simple key-value stuff at the
moment; may get fancier later.
Interesting. Could you give an example of how an op with metadata would look
G'day all.
On Thu, Apr 18, 2002 at 11:31:32PM -0400, Dan Sugalski wrote:
Interesting. Could you give an example of how an op with metadata would look?
Sure. Here's some of my experimenting with what is the right kind
of metadata to attach. Brief glossary:
- CANNOT_FALL_THROUGH
G'day all.
On Fri, Apr 19, 2002 at 12:44:49AM -0400, Dan Sugalski wrote:
Ah. Hmmm. Well, we're already attaching some metadata to ops in a
different way--that's what the op and inline keywords are doing. For
metadata that use parameters I can see a scheme like you're
proposing, though
Larry Wall [EMAIL PROTECTED] writes:
Charles Bunders writes:
: I came across Simon Cozens email
: (http:[EMAIL PROTECTED]/msg08641.html) again
: tonight and it got me thinking...
:
: In Perl 6 are modules compiled down to pbc (Perl byte code) going to also
: create metadata similar
Charles Bunders writes:
: I came across Simon Cozens email
: (http:[EMAIL PROTECTED]/msg08641.html) again
: tonight and it got me thinking...
:
: In Perl 6 are modules compiled down to pbc (Perl byte code) going to also
: create metadata similar to what .NET has describing methods, use, etc.
We
I came across Simon Cozens email
(http:[EMAIL PROTECTED]/msg08641.html) again
tonight and it got me thinking...
In Perl 6 are modules compiled down to pbc (Perl byte code) going to also
create metadata similar to what .NET has describing methods, use, etc.
I don't think it would
On Mon, Dec 24, Gregor N. Purdy wrote:
Nicholas --
Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
On Mon, Dec 24, 2001 at 02:11:15PM -0500, Gregor N. Purdy wrote:
Or, do we really need to have the three-way in/out/inout tagset?
inline op set(out i, in i|ic) {
$1 = $2;
}
Making the distinction between the three cases enables a number of
optimizations of native code based on
1 - 100 of 128 matches
Mail list logo
