On Sun Jul 20 17:52:49 2008, [EMAIL PROTECTED] wrote:
> On Sunday 20 July 2008 17:37:28 James Keenan via RT wrote:
>
> > If no one currently has any more ideas on the subject of this
> ticket, I
> > will close it.
>
> Running it less frequently -- over all PMCs at once -- would speed it
> up,
I
In the course of working on tests for this and other configuration step
classes in the 'parallel' branch in SVN, I had occasion to note that
this is the only one of 60+ config steps which displays certain verbose
output only when '--verbose=2' is called on the command line:
53-print " ($genera
I've added references to 7 tickets opened last year focusing on tests
for the 'gen' step classes.
As part of my work on this ticket in the 'parallel' branch, I have
finally begun writing some basic tests for the 'gen' configuration
steps: config/gen/*.pm. These steps -- which are the final
configuration steps -- primarily look data up in source files, files
generated earlier in the configurati
On Thu May 15 10:24:00 2008, julianalbo wrote:
> On Thu, Oct 25, 2007 at 5:28 PM, via RT Paul Cochrane
> <[EMAIL PROTECTED]> wrote:
>
> > # XXX
> > # in plain functional run-loop result is 999
> > # other run-loops report 998
> > # TODO investigate this after interpreter strtup is done
> > # see a
On Fri, 2008-07-25 at 22:18 +0200, Peter Gibbs wrote:
> typedef HUGEINTVAL(*sprintf_getint_t) (PARROT_INTERP,INTVAL,
> SPRINTF_OBJ *);
>
> So, since obj->getint returns a HUGEINTVAL, I gave it one to store the
> result in.
Fair enough, that's good enough for me.
> As to why sprintf_obj is
- Original Message -
From: "Will Coleda" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 25, 2008 10:31 PM
Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
On Fri, Jul 25, 2008 at 4:23 PM, Peter Gibbs via RT
<[EMAIL PROTECTED]> wrote:
- Original Messa
On Fri, Jul 25, 2008 at 4:23 PM, Peter Gibbs via RT
<[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: "Christoph Otto" <[EMAIL PROTECTED]>
> To:
> Sent: Friday, July 25, 2008 6:43 PM
> Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
>
>
>> Will Coleda wrote:
>>>
>>>
- Original Message -
From: "Christoph Otto" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 25, 2008 6:43 PM
Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
Will Coleda wrote:
Once we get a core parrot test for this, we can close out the ticket.
Thanks!
I tried writing
- Original Message -
From: "Geoffrey Broadwell" <[EMAIL PROTECTED]>
To: "Peter Gibbs" <[EMAIL PROTECTED]>
Cc: "Christoph Otto" <[EMAIL PROTECTED]>;
Sent: Friday, July 25, 2008 6:09 PM
Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
On Fri, 2008-07-25 at 13:40 +0200, Peter
On Thu, Jul 24, 2008 at 11:05:28PM -0700, Christoph Otto via RT wrote:
> From what I can tell, t/src/list.t was deleted or moved sometime after
> r22464. Searching for some of the more unique-looking strings in that
> revision of the file (
> http://www.parrotvm.org/svn/parrot/checkout/trunk/t/sr
On Sat Dec 08 18:24:17 2007, petdance wrote:
>
> In intlist_get(), we call list_get() which can return a NULL.
>
> Then, the result is checked against -1, and then
> dereferenced.
>
> I suspect that check against -1 should actually be a
> check against NULL, but don't know enough to prove it
On Thu Jun 05 19:07:49 2008, coke wrote:
> We can always improve the diagnostic emitted by the PMC compiler.
> Mismatched strings are going to be an issue whether they're in a
> CONST_STRING declaration or just an assignment to char *.
>
> So, no, it's not worth fixing up c2str.pl, IMO.
So if it
On Wed Oct 24 12:53:42 2007, pcoch wrote:
> In t/src/list.t there is the todo item:
>
> # TODO
>
> which says much in little i.e.: improve the test coverage of the list_*
> functionality.
>From what I can tell, t/src/list.t was deleted or moved sometime after
r22464. Searching for some of the m
Will Coleda wrote:
Not only that does that avoid the segfault, the tcl spec test
equivalent to the first test passes. Woot.
The second is still failing, but probably due to unicode issues - but
it's now just failing, not segfaulting.
Once we get a core parrot test for this, we can close out th
On Fri, 2008-07-25 at 13:40 +0200, Peter Gibbs wrote:
> +HUGEINTVAL num;
Does this really need to be a HUGEINTVAL? Why is INTVAL not sufficient?
-'f
On Fri, Jul 25, 2008 at 9:25 AM, Michael Peters via RT
<[EMAIL PROTECTED]> wrote:
> Will Coleda (via RT) wrote:
>
>> Can we get the tag information included in the RSS summary articles?
>
> Absolutely. Try to wget
> http://smolder.plusthree.com/app/public_projects/feed/8/failed and you
> can see th
Will Coleda (via RT) wrote:
Can we get the tag information included in the RSS summary articles?
Absolutely. Try to wget
http://smolder.plusthree.com/app/public_projects/feed/8/failed and you
can see them there now.
--
Michael Peters
Plus Three, LP
On Fri, Jul 25, 2008 at 2:25 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Jun 05 19:07:49 2008, coke wrote:
>
>> We can always improve the diagnostic emitted by the PMC compiler.
>> Mismatched strings are going to be an issue whether they're in a
>> CONST_STRING declaration or just
On Fri, Jul 25, 2008 at 7:40 AM, Peter Gibbs <[EMAIL PROTECTED]> wrote:
>
> - Original Message - From: "Christoph Otto" <[EMAIL PROTECTED]>
> To:
> Sent: Friday, July 25, 2008 10:29 AM
> Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
>
>
>> Will Coleda (via RT) wrote:
>>>
>>>
- Original Message -
From: "Christoph Otto" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 25, 2008 10:29 AM
Subject: Re: [perl #57260] [BUG] Segfaults in sprintf opcode
Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda # Please include the string:
[perl #57260]
# in the
Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #57260]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57260 >
Tripped over these trying to run some spec tests for Tcl. I
22 matches
Mail list logo