--- 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
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 hand
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 data
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 opta
[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
I'v
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 fingerpri
[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 i
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 y
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
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.
T
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 wa
[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 o
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
[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 w
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 expressio
Nicholas Clark wrote:
> There's nothing wrong with stealing, er "borrowing" the good bits of
> reptiles though, is there?. I didn't think that perl was fussy about where
> it gets its inspiration from.
It isn't and never will be. We're openly friendly to all languages. But
Perl is also quite diff
Smylers <[EMAIL PROTECTED]> writes:
> 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 summariz
19 matches
Mail list logo
