On May 16, 2007, at 7:21 PM, James Keenan (via RT) wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #42975]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42975 >
One of the tests in t/tools/o
On Tuesday 15 May 2007 12:10:09 Mike Mattie wrote:
> This patch adds const qualifiers to string_cstring_free , and mem_sys_free.
> In reviewing other commits to the parrot tree I noticed that authors were
> dropping const qualifiers because it was generating warnings when they
> passed their point
On 5/17/07, via RT Jerry Gay <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42974]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42974 >
it looks like the register alligato
# New Ticket Created by James Keenan
# Please include the string: [perl #42975]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42975 >
One of the tests in t/tools/ops2pmutils/08-sort_ops.t has begun to fail.
[li11-226:parr
On Tuesday 01 May 2007 12:12:35 Kevin Tew wrote:
> This week's file of the week is:
> src/object.c
>
> As Allison says below, no patch is to small.
> typo fixes, spelling fixes, documentation welcome, as well as code
> refactorings.
I missed it last week, but create_deleg_pmc_vtable() has some aw
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42974]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42974 >
it looks like the register alligator is eating integers in this code:
.const int TESTS = 2
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #42968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42968 >
In r18267, pre Parrot 0.4.11, Jonathan deprecated following opcodes:
adddoes,
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #42969]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42969 >
In r18267, pre Parrot 0.4.11, Jonathan deprecated following :vtable methods:
vo
On Wed, 16 May 2007, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
In src/debug.c, for handling user input, I don't see any particular
advantage to the macro version. The f
On Wed, May 16, 2007 at 09:36:48AM -0700, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
Yes, sorry, I sort of missed that part.
Er. I don't know. One deserves to die.
Nichol
On 5/16/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 08:45:04AM -0700, jerry gay wrote:
> here's a macro to move to the next argument (kjs mentioned in an
> earlier thread that this isn't a descriptive name)
>
> /* na(c) [Next Argument (Char pointer)]
> *
> * Moves t
On Wed, May 16, 2007 at 08:45:04AM -0700, jerry gay wrote:
> here's a macro to move to the next argument (kjs mentioned in an
> earlier thread that this isn't a descriptive name)
>
> /* na(c) [Next Argument (Char pointer)]
> *
> * Moves the pointer to the next argument in the user input.
>
here's a macro to move to the next argument (kjs mentioned in an
earlier thread that this isn't a descriptive name)
/* na(c) [Next Argument (Char pointer)]
*
* Moves the pointer to the next argument in the user input.
*/
#define na(c) { \
while (*c && !isspace((int) *c)) \
c
On 16 May 2007, at 15:20, Andy Armstrong wrote:
More pedantically bitwise & and | are guaranteed to evaluate both
arguments.
And as you say they don't constitute a sequence point[1] so the order
of evaluation of the arguments is undefined.
[1] http://en.wikipedia.org/wiki/Sequence_point
-
On 16 May 2007, at 15:11, jerry gay wrote:
it's bitwise AND where order isn't guaranteed--i'm pretty sure that's
the point of confusion.
More pedantically bitwise & and | are guaranteed to evaluate both
arguments.
Logical && and || are guaranteed to short circuit completely reliably.
--
An
On 16 May 2007, at 15:14, Klaas-Jan Stol wrote:
Actually, I was taught when learning Java, and assumed (yes, I
know) it
might have been the case for C. Anyway, please don't forget the other
comments :-) This one was trivial ;-)
Well - just so you know - it's as wrong for Java as it is for
On 5/16/07, Andrew Dougherty <[EMAIL PROTECTED]> wrote:
On Wed, 16 May 2007, Klaas-Jan Stol wrote:
> hi,
> I've been studying the code in the fotw: debug.c and below are my comments,
> if they're of any interest. Feel free to neglect, I'm kinda picky.
>
> 1.
>while (*command && (isalnum((int
On 5/16/07, jerry gay <[EMAIL PROTECTED]> wrote:
On 5/16/07, Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 16 May 2007, Klaas-Jan Stol wrote:
>
> > hi,
> > I've been studying the code in the fotw: debug.c and below are my
comments,
> > if they're of any interest. Feel free to neglect, I'
On Wed, 16 May 2007, Klaas-Jan Stol wrote:
> hi,
> I've been studying the code in the fotw: debug.c and below are my comments,
> if they're of any interest. Feel free to neglect, I'm kinda picky.
>
> 1.
>while (*command && (isalnum((int) *command) || *command == ',' ||
>*command == ']
hi,
I've been studying the code in the fotw: debug.c and below are my comments,
if they're of any interest. Feel free to neglect, I'm kinda picky.
1.
while (*command && (isalnum((int) *command) || *command == ',' ||
*command == ']'))
I'm not 100% sure, but:
I've always been taught that
The results of my first post in this thread were probably caused by
the fact that some files were not updated correctly (I am new to
revision control). Both Allison's and Alek's patches have in fact the
same effect.
But the problem that I stated in my second post and the proposed
solution are val
A couple of questions:
1: Only two pmcs have the const_too flag SArray and ParrotLibrary.
This seems redundant given that all pmcs except abstract, singleton, and
const_too pmcs get a read only variant of the vtable. Is there any
reason, why we can't get rid of the const_too flag and just u
On Sun, 13 May 2007 22:46:15 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
> Hello,
>
[snip]
Here is a revised version of library.c . still not at the compile stage but I
think that the
implementation is now verifiable to the search algorithm by review. This is
pretty close to what
I would cal
23 matches
Mail list logo
