--- 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 as a
Wow, Parrot has certainly made a lot of progress since I've last looked at it.
I've lightly gone through the documentation Perl Assembly Language
documentation a couple times, and I'm confused over a couple of (hopefully
simple) points. Keep in mind that I'm not a Perl coder:
1. How do you
The interpreter depends on the various ops files for actually executing
byte code.
Currently all ops files except obscure.ops get logically appended and
built into core_ops_*.c. This makes for huge core_ops files, with a lot
of unused operations, bad cache locality and so on. It will get worse,
David wrote:
1. How do you handle variant (either string or numeric) data? Do you set up
one of the string registers with a string ssss to keep track of
datatypes?
N/Y. This would need probably a new PMC type.
2. What happens if a routine needs more than 32 variables of one
Leo --
You need to account for the possibility that the number of ops in an oplib
could change over its versions, and so depending on it being stable is
a losing proposition. That is exactly what is going on in the scheme
below,
where you append oplibs en their entirety to the code segment's
[EMAIL PROTECTED] wrote:
Leo --
You need to account for the possibility that the number of ops in an oplib
could change over its versions,
This does invalidate the PBC, as it's currently done via fingerprinting.
I think this needs to be done at the op level, not at the oplib level (as
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep
your favorite halide handy. ]]
You need to account for the possibility that the number of ops in an
oplib
could change over its versions,
This does invalidate the PBC, as it's currently done via
[EMAIL PROTECTED] wrote:
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep
your favorite halide handy. ]]
The per-op approach makes fingerprinting obsolete, which is another
reason I'm for it.
Yes partly, see below.
... Having major changes in opsfiles will
Leo --
... Having major changes in opsfiles will invalidate PBCs, as
e.g. a change from gcc 2.x to 3.x invalidates C++ object files.
I disagree that it is too expensive, but I expect it will require
hard data to settle the matter. Since this is my pet issue, I
expect you won't be
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
Hi,
I am trying to implement a PMC for complex numbers. For that I have
created a file 'complex.pmx' which implements 'add_same()'.
However, during test I found that 'add_same()' is never called.
This is consistent with the fact, that there is no call to add_same() in
lib/Parrot/OpLib/core.pm.
Leo wrote:
1. How do you handle variant (either string or numeric) data? Do you set
up one of the string registers with a string ssss to keep track
of datatypes?
N/Y. This would need probably a new PMC type.
OK. This is pretty common with a lot of scripting languages, so I was
[EMAIL PROTECTED] wrote:
Leo --
- a opcode is obsoleted = you can't delete it anyway, so keep it,
update docs.
Aside: Begs the question: Should op metadata include an 'obsolete' tag?
It would allow you to report on obsolete op use.
Would't harm, yep.
- a opcode gets more or less
Leo --
- a opcode gets more or less or changed params = you are as out of
luck
with the old PBC as my approach is: invalidate PBC file.
Nope. The op 'name' includes the number and types of the args,
foo_i_ic.
A change involves a new op and marking the old one obsolete. As far
as
existing
[EMAIL PROTECTED] wrote:
I see. So you would need to keep the implementation of 'foo_i_ic' for
old PBCs and you would have 'foo_x_y_z', your new variant of this
opcode. Seems not the best idea too me, in terms of maintanability and
code size.
Yep. But I don't see how this is different from
Miko O'Sullivan wrote:
The idea of discussion summaries has been well received, ...
I read this thread over the past couple of days. It's only today that,
having thought about it, an objection occurred to me. I've no problem
with people summarizing threads, but with this bit:
The summaries
On Tue, Feb 04, 2003 at 01:57:00AM +0100, Stéphane Payrard wrote:
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
17 matches
Mail list logo
