# New Ticket Created by Will Coleda
# Please include the string: [perl #57796]
# in the subject line of all future correspondence about this issue.
# 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 manif
s
> the current pertinence of the issues 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 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 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 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
[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
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 coup
t; > >
> > > > 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).
> >
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 fil
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 resu
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).
&g
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...
# Collecting svn:eol-style attributes...
# Fai
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
"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)
# 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
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #24922]
# in the subject line of all future correspondence about this issue.
# 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:
> 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
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 possibilitie
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 fir
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 co
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 ca
arator.
We can skip that for a bit, though.
> >It's OK for the code that handles 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
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, no
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 tha
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
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 relativ
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
commo
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? Va
--- 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 wi
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
... (bang, there goes the line numbers ;)
If you want to debug, you dont want optimizations. When you 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
>
--- [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 wi
ode whats to produce 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.
ble 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 compil
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
[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 w
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.
Of course, the most natural candidate for the
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.
If it is a
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
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 b
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
--- 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
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 implem
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
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 incomplet
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 shouldn
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 te
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 mappe
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
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, 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 succ
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
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 quic
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
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 bo
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
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, tho
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 exe
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
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 :)
na
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 t
ried)
> If there's a directory of some sort, it should record the type ID and
> the offset to the beginning of the chunk. 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 w
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 suc
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 Linu
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,
P
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
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 mem
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 (
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 m
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),
anal
d 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 do think that, whatever "native" (i.e. understood by
>
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 #
# >met
ks 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 me
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 thin
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
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
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
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
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 sim
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 to have
# in either the pac
general interests me--it looks like a general
annotation system we can attach to the bytecode. (I admit, I haven't
read the page you pointed at) I will admit, though, that I was
thinking more about metadata that the engine could use itself, or
would provide to programs running on it, bu
--- 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
--- 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
>
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.
d 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 is a PMC consisting of three parts
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 ei
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
--- 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 ei
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
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 l
G'day all.
On Fri, Apr 19, 2002 at 05:28:12PM -0300, Daniel Grunblatt wrote:
> Add me to the list, because I'm writting the jit optimizer and ran into
> the same problem, we must add some metadata otherwise I will end up
> hard-coding all the information deep into the opti
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 keywor
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
At 1:59 PM +1000 4/19/02, Andrew J Bromage 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:
Ah. Hmmm. Well, we&#x
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
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 w
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
1 - 100 of 136 matches
Mail list logo
