:(
I just tried and the Sun Sep 23 13:00:00 2001 UTC
segfaults all the way in t/op/number.t and t/op/trans.t,
( IV = long, NV = double )
( other tests are 100% OK ), so there are problems
with floats. Tomorrow at the university
I can debug the problem
( debugging over a dialup is a pain... )
Cool; thanks for this. Can you add a row to your smoke configuration
which does *not* change the default type sizes?
Sure. WRT segfaults, I think I found the cause for the problems:
The files inf cvs.perl.org/snapshots seem out of date.
$ diff -u parrot/assemble.pl ../parrot.cvs/assemble.pl |
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard numbers to support the claims.
Unless you are
On Sun, 23 Sep 2001, Mattia Barbon wrote:
Cool; thanks for this. Can you add a row to your smoke configuration
which does *not* change the default type sizes?
Sure. WRT segfaults, I think I found the cause for the problems:
The files inf cvs.perl.org/snapshots seem out of date.
Oops.
On Sun, 23 Sep 2001, Bart Lateur wrote:
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard
On Sun, Sep 23, 2001 at 08:42:51PM -0700, Wizard wrote:
Is Parrot to have a strings db for error and UI strings (i18n)?
Parrot should not be outputting that many errors or UI strings. However,
those that it does should go through I18N, yes.
If so, it should probably go on the TODO list (the
At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
http://astray.com/mandlebrot.pasm
Leon, you're a sick, sick man.
Okay, I think that means we need to weld in bitmap handling opcodes into
the interpreter. :)
Also looks like there are some bugs in the num register handling that need
fixing. :(
At 05:32 PM 9/23/2001 +0200, Bart Lateur wrote:
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much
At 01:32 AM 9/24/2001 +0100, Simon Cozens wrote:
On Sun, Sep 23, 2001 at 08:42:51PM -0700, Wizard wrote:
Is Parrot to have a strings db for error and UI strings (i18n)?
Parrot should not be outputting that many errors or UI strings. However,
those that it does should go through I18N, yes.
So,
At 04:53 PM 9/22/2001 -0400, Ken Fox wrote:
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU.
It's not, we just haven't gotten to the interesting bits yet. :)
What if we
did something non-traditional that made implementing
IRIX64 6.2 cc -n32 issues 123 warnings (one per op code) complaining
that
interpreter.c, line 219: warning(1048): cast between pointer-to-object and
pointer-to-function
BUILD_TABLE(foo);
^
This patch makes them go away.
- SWM
Index: build_interp_starter.pl
I see there's a lot of embedded documentation going into the core, and
that's a good thing. That brings up a question, though--what exactly should
we document, and where should it be seen?
For an example, the opcode functions should *never* be used outside the
interpreter core itself, but
At 08:57 PM 9/22/2001 -0400, Michael Maraist wrote:
I don't remember if this has already been experimented with; I've
lost track of what the previous sets of benchmarks were for. I was
curious to see how much faster a single-function switch based interpreter
would go.
Alas, whether a
13 matches
Mail list logo
