# Failed test (t/dynclass/dynlexpad.t at line 58)
# got: 'Parrot VM: PANIC: Null vtable used!
# C file src/pmc.c, line 167
# Parrot file (not available), line (not available)
#
# We highly suggest you notify the Parrot team if you have not been
working on
# Parrot. Use parrotbug
On Dec 5, 2005, at 21:58, Klaas-Jan Stol wrote:
hi,
if I understood correctly, the global storage is implemented as a hash
table.
If so, will it be possible to load this global hash table in a P
register?
It is possible right now. See the introspection interface of the
interpreter:
On Dec 6, 2005, at 3:43, Stevan Little wrote:
Sorry, I tried to follow docs/submissions.pod, but my patch-fu is very
weak. Please forgive me.
This is a test for C3 MROs, it includes most of the tests from
Perl6::MetaModel prototype in Pugs (which themselves were stolen from
examples in
Leopold Toetsch wrote:
On Dec 5, 2005, at 21:58, Klaas-Jan Stol wrote:
hi,
if I understood correctly, the global storage is implemented as a
hash table.
If so, will it be possible to load this global hash table in a P
register?
It is possible right now. See the introspection interface
On 12/6/05, chromatic [EMAIL PROTECTED] wrote:
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
I wonder if there is a macroey thing that we can do here. That is,
could we make:
ok(1);
is(1, 1);
like(foo, /foo/);
Into:
ok(1);
ok(1 == 1);
On 12/6/05, Luke Palmer [EMAIL PROTECTED] wrote:
That still leaves the problem of what to do with fail() and is() in
the compiler suite.
Here's a handwavey crack at what I was talking about:
Ack. Accidentally sent the half written message. Let's try again:
my $comparators = set == eq
tcl and possibly other users of Parrot are currently suffering from
some obscure uninitialized memory bugs, somewhere hidden inside library
loading (see also #37814 and the attached valgrind log).
I've been looking up and down through the code, but there is no obvious
problem. E.g. the
On 12/6/05, Leopold Toetsch [EMAIL PROTECTED] wrote:
2) I'm very much inclined to remove the Win32 special casing (see also
r8673)
There are already 2 possibilities to specify the runtime prefix (where
libs are searched).
a) perl Configure --prefix=foo
This sets the built in prefix for
Leo Can you provide dummy subs for the _offs functions and put in a dummy
Leo define for the get_base_reg_no macro that returns some valid register
Leo number.
Andy I'll try something, but it'll be nearly blind guessing -- I don't know
Andy anywhere near enough about JIT or about SPARC assembler
On Sun, 4 Dec 2005, Joshua Hoblitt wrote:
What still needs to be done:
- CLI options need some minor tweaks
I think they need some major design. In particular, it would be
nice to have a documented consistent interface to setting or
unsetting various things. Then, it would be *very* nice
On 11/29/05, via RT jerry gay [EMAIL PROTECTED] wrote:
this will likely require configure, makefile, build, and documentation
modifications. related is moving the tools/* files to the proper
subdirs, and renaming them where appropriate. this should be grouped
with other tools/-related
On 12/6/05, jerry gay [EMAIL PROTECTED] wrote:
On 11/29/05, via RT jerry gay [EMAIL PROTECTED] wrote:
i'm pretty confident all will go well, so this change should be
committed in less than an hour. it only affects the root and languages
makefiles, manifests, and obviously the util/ and
On Dec 6, 2005, at 16:40, Andy Dougherty wrote:
... The structure of the jit_emit.h file is hard to fathom -- it gets
included multiple times by multiple files, and different
implementations
in the jit/*/ directories handle those multiple includes differently.
Yep. Therefore
On Tue, 2005-12-06 at 21:13 +0100, Leopold Toetsch wrote:
If it helps - the t/perl/manifest test hangs on test 3. Looking at the
source, looks like someone intended a diag message to warn that it
would
appear to hang, but the diag doesn't get printed out until after the
fact.
The
On 11/29/05, via RT jerry gay [EMAIL PROTECTED] wrote:
this will likely require configure, makefile, build, and documentation
modifications. this should be grouped with other compiler/-related
modifications.
it did, but they were minor ones. next is imcc/, which i expect to be
a bit more
On Tue, 2005-12-06 at 18:38 -0500, Michael Cummings wrote:
t/perl/manifest..Can't exec svk: No such file or
directory at t/perl/manifest.t line 38.
ok
1/3 skipped: Not a working copy
Not a patch, but a better explanation of the problem. There is a false
assumption in
On Dec 7, 2005, at 0:29, Michael Cummings wrote:
Problem is the diag message warning users that it will take a while
(and
it does - on a p4 with 2 gigs of ram i gave up after a few minutes
On that hardware it certainly shouldn't need minutes to finish. It's
just strange:
$ time perl
On 12/6/05, Michael Cummings [EMAIL PROTECTED] wrote:
On Tue, 2005-12-06 at 18:38 -0500, Michael Cummings wrote:
t/perl/manifest..Can't exec svk: No such file or
directory at t/perl/manifest.t line 38.
ok
1/3 skipped: Not a working copy
Not a patch, but a better
I realize I'm talking to myself at this point (last post, promise), but
my last message failed to explain the paste at the top. On a box without
svk, using the 0.4.0 released tarball, all is fine (t/perl/manifest.t is
skipped/failed quickly). However, if a user has svk installed and
attempts to
From: Bob Rogers [EMAIL PROTECTED]
Date: Sat, 3 Dec 2005 23:11:32 -0500
If you try to call a sub with a :slurpy parameter and give it a :flat
argument, parrot r10337 just hangs, chewing up CPU time . . .
Turns out this is because of premature optimization -- and all
flattening is
20 matches
Mail list logo
