I have a fix which currently suits my need. But the real problem, like
you said in IRC is to eventually merge the
PGE and the rakudo implementations of protoobjects.
I note that S12 that .WHAT and .WHO should return objects that
stringifies to strings and not directly strings
like in PGE implementa
chromatic wrote:
> I prefer this patch. It fixes the problem closer to its source. Does it work
> for you?
Yes, that works for me. However the fix does not get exercised without
the new test case (or something similar) added in the original patch.
Thanks!
Tom
On Tue, May 6, 2008 at 7:42 AM, chromatic <[EMAIL PROTECTED]> wrote:
> I prefer this patch. It fixes the problem closer to its source. Does it
> work
> for you?
Works for me, but I wonder if the set_string_native function still
needs the fix, or an assertion about a forbidden combination of
On Fri, May 02, 2008 at 02:16:01AM -0500, Patrick R. Michaud wrote:
> > When you try to invoke a sub that doesn't exist, Parrot currently gives the
> > unhelpful error message "Null PMC access in invoke()". Sometimes you can
> > figure out what's wrong given the backtrace. Often you can't.
> >
In r27351 I've added code to PCT to check for non-existent subs and
throw an exception at the point of the call. So, the problem is
"solved" for PCT-based languages, at least.
It still doesn't help with the case of non-existent sub names in PIR,
though, for which I recommend something along the l
On Tuesday 06 May 2008 11:03:08 Patrick R. Michaud via RT wrote:
> It still doesn't help with the case of non-existent sub names in PIR,
> though, for which I recommend something along the lines of the patch
> described by chromatic in
> http://groups.google.com/group/perl.perl6.internals/msg/7343
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). So
> perhaps the change chromatic made didn't actually fix it . . .
Are you still seeing breakage?
Yes, PDD 19 can talk about 'subroutines' rather than 'compilation
units'. (I just did a quick skim of the file, and a simple search and
replace changing 'compilation unit' to 'subroutine' will work fine.)
In imcc.y, change 'compilation_unit' and 'compilation_units' to
something more general like '
On Tuesday 06 May 2008 12:52:35 [EMAIL PROTECTED] wrote:
> Author: allison
> Date: Tue May 6 12:52:34 2008
> New Revision: 27357
>
> Log:
> [pdd25cx]
> * Several header changes from rerunning 'make headerizer'.
>
> Modified: branches/pdd25cx/compilers/imcc/optimizer.c
> =
Will Coleda wrote:
On Tue, May 6, 2008 at 1:23 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
The goal for 1.0 is to ship languages separately from parrot; Can we
get a brief summary of what sort of licensing/copyright issues apply
when the languages are removed from perl.org repository?
My simp
On Fri, Oct 5, 2007 at 10:50 PM, via RT Paul Cochrane
<[EMAIL PROTECTED]> wrote:
> In src/debug.c:PDB_cond() there is the todo item:
>
> /* XXX Does /this/ have to do with the fact that PASM registers used to
> * have
> * maximum of 2 digits? If so, there should be a while loop, I think.
>
This ticket is too vague.
There are plenty of specific PDB tickets already; those will serve.
Rejecting ticket.
On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
> On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
>
> > i'm having trouble on x86_64. when running a 32bit parrot, i get
> > occasional deadlock at the OS level, after Parrot_exit. when running a
> > 64bit parrot, it segfaults within Parrot_
On Tue Nov 13 19:01:07 2007, [EMAIL PROTECTED] wrote:
> ---
> osname= freebsd
> osvers= 6.2-stable
> arch= sparc64-freebsd
> cc= cc
> ---
> Flags:
> category=install
> severity=high
> ack=no
> ---
> Parrot 0.4.17r22818
> freebsd 6.2-sparc64 gcc 4.3
>
> I have the output of th
On Tue May 06 13:31:40 2008, [EMAIL PROTECTED] wrote:
> Will Coleda wrote:
> > On Tue, May 6, 2008 at 1:23 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> >> The goal for 1.0 is to ship languages separately from parrot; Can we
> >> get a brief summary of what sort of licensing/copyright issues apply
On Tue May 06 17:15:39 2008, coke wrote:
>
> If the patch is applied, can we close this ticket?
>
No. I only figured out how to keep track of files generated during
configuration, not during build. We need some of what, IIRC, particle
termed "makefile trickery" to keep track of files generat
Removing this config step class does not appear to have caused any smoke
failures. Resolving teicket.
On Sunday 27 April 2008 18:08:08 Mark Glines wrote:
> In the future, INTVAL will probably be 128 bits for some platforms.
> I'd really like to see a set of fixed-width types (similar to what p5
> has for pack and unpack), so you have the option of "native int" or
> "exactly 32 bits" or whatever yo
On Friday 25 April 2008 10:49:19 Andy Dougherty wrote:
> Ok. Fixed. This version avoids both type-punning and cast alignment
> warnings by declaring the 'data' element of a Stack_Chunk_t to be
> of type Stack_Entry_t, since that's the only way it is ever used,
> at least as far as I could tell.
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
> I'm not wedded to splitting them up as much as I did. In fact, I'd be
> fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this was his preference, saying also
that this arrangement "solves ano
From: "chromatic via RT" <[EMAIL PROTECTED]>
Date: Tue, 06 May 2008 12:18:19 -0700
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). S
I think this ticket is ready to be closed. A lot of the PMC_* items
were likely fixed as part of the pdd15oo change, and the problem I cited
has apparently been fixed.
Pm
On Tuesday 06 May 2008 19:26:46 Geoffrey Broadwell wrote:
> On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
> > I'm not wedded to splitting them up as much as I did. In fact, I'd be
> > fine with core.in, opengl.in, and misc.in. Better for you?
>
> chromatic confirmed on IRC that t
23 matches
Mail list logo
