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
On Wed, 2005-12-07 at 02:18 +0100, Leopold Toetsch wrote:
> On Dec 7, 2005, at 0:29, Michael Cummings wrote:
>
> On that hardware it certainly shouldn't need minutes to finish. It's
> just strange:
> This is on a PowerBook G4 with 1.2 GHz - certainly not a fast system,
> ~7 seconds for the test
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 run
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, b
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 -Ilib
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 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 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.
>
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 jit/skeleton/ji
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 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 mod
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
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 assemb
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 pre
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 invalid
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 <
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);
> >
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 o
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 Pyth
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:
perl
# 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 (
21 matches
Mail list logo