Andy Lester wrote:
I guess I don't see the need to document a standard C behavior with a
macro.
If you had read all the way through the message, you would see that the
biggest benefit is the ability to hang debugging hooks off the macro.
We have a number of these kinds of debugging hooks t
On Wed, Jun 20, 2007 at 10:38:08PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>On Wed, Jun 20, 2007 at 09:41:00PM -0400, Bob Rogers wrote:
>>Patrick R. Michaud wrote:
>>> My first question is "How do I add a class method?" -- i.e.,
>>> a
On Wednesday 20 June 2007 19:02:43 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/docs/pdds/pdd15_objects.pod
> -Ruby: Ruby has meta classes. It would be nice if classes were objects in
> Parrots OO model. +Ruby: Ruby has meta-classes. It would be nice if
> classes were objects in +Parrot's OO
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 20 Jun 2007 21:02:54 -0500
On Wed, Jun 20, 2007 at 09:41:00PM -0400, Bob Rogers wrote:
>From: Jonathan Worthington <[EMAIL PROTECTED]>
>Date: Thu, 21 Jun 2007 00:05:00 +0100
>
>Hi,
>
>Patrick R.
On Wed, Jun 20, 2007 at 09:41:00PM -0400, Bob Rogers wrote:
>From: Jonathan Worthington <[EMAIL PROTECTED]>
>Date: Thu, 21 Jun 2007 00:05:00 +0100
>
>Hi,
>
>Patrick R. Michaud wrote:
>> My first question is "How do I add a class method?" -- i.e.,
>> a method that operates
Author: rgrjr
Date: Wed Jun 20 19:02:42 2007
New Revision: 19204
Modified:
trunk/docs/pdds/pdd15_objects.pod
Log:
* docs/pdds/pdd15_objects.pod:
+ Fix typo, canonicalize "meta-classes".
Modified: trunk/docs/pdds/pdd15_objects.pod
===
From: Jonathan Worthington <[EMAIL PROTECTED]>
Date: Thu, 21 Jun 2007 00:05:00 +0100
Hi,
Patrick R. Michaud wrote:
> My first question is "How do I add a class method?" -- i.e.,
> a method that operates on a class instance as opposed
> to an object instance of that class . .
On Thu, Jun 21, 2007 at 12:08:33AM +0100, Jonathan Worthington wrote:
> Patrick R.Michaud (via RT) wrote:
> >The 'setline' opcode doesn't do what I expect it to do, which
> >is to associate runtime errors with lines in HLL source.
>
> Currently HLL debug info stuff is spec'd, but not implemented.
Patrick R.Michaud (via RT) wrote:
The 'setline' opcode doesn't do what I expect it to do, which
is to associate runtime errors with lines in HLL source.
Currently HLL debug info stuff is spec'd, but not implemented. Well, OK,
the storage of it in bytecode is spec'd, the exact PIR syntax for i
Hi,
Patrick R. Michaud wrote:
My first question is "How do I add a class method?" -- i.e.,
a method that operates on a class instance as opposed
to an object instance of that class. Ideally the answer
would contain explanations/examples for defining such
methods in PIR and also as PMC methods.
Hi,
Allison Randal wrote:
It looks like every low-level PMC is creating a proxy object for
itself and these proxies are stored in the interpreter global
parrot_interp_t.
That's what's implemented, yes. I pondered hanging them off the v-table
too. That's perhaps more desirable.
I intended tha
I'm starting to work on pdb for fixing bugs, segfaults and so, and maybe
implement new commands listed in TODO.
I noticed that command arguments does not support spacing between command
and argument. I have written a small patch that uses nextarg() for getting
command arguments. This means that no
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #43266]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43266 >
There are several language implementations that use the
Perl5 Parrot::Test::lang
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #43269]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43269 >
The 'setline' opcode doesn't do what I expect it to do, which
is to associate runt
Resolved in r19164, feel free to re-open if you find any problems.
Best regards,
./smash
On Wednesday 20 June 2007 12:39:08 [EMAIL PROTECTED] wrote:
> Modified: trunk/lib/Parrot/Test.pm
> ===
>=== --- trunk/lib/Parrot/Test.pm(original)
> +++ trunk/lib/Parrot/Test.pmWed Jun 20 12:39:06 2007
> @@ -411,6 +41
On 6/20/07, Andy Lester <[EMAIL PROTECTED]> wrote:
My point is that
*d = *s;
is no more a weird cryptic construct than
n++;
or
while (*s)
*d++ = *s++;
for that matter.
That's a very good point. As you said in the original message, all you need is
*dest = *src;
since the c
On Jun 20, 2007, at 1:05 PM, Mark J. Reed wrote:
Incrementing a var is much less likely to have unpredictable effects
due to modifying the wrong memory. Sure, x might be a pointer, and
things might gang agley there, but pointers getting set to the wrong
type of pointee is a pretty common probl
On 6/20/07, Andy Lester <[EMAIL PROTECTED]> wrote:
I guess I don't see the need to document a standard C behavior with a
macro. We don't have
#define inc(x) (x)++
do we?
Incrementing a var is much less likely to have unpredictable effects
due to modifying the wrong memory. Sure, x might
On Jun 20, 2007, at 11:50 AM, Allison Randal wrote:
I wasn't entirely happy with either option, so I asked around a bit
for other ideas. I like the macro approach below, it gives us both
self documentation and better checking for the size of the two
structs.
I guess I don't see the need
I wasn't entirely happy with either option, so I asked around a bit for
other ideas. I like the macro approach below, it gives us both self
documentation and better checking for the size of the two structs.
Allison
Original Message
From: Nick Forrette <[EMAIL PROTECTED]>
To:
On Jun 20, 2007, at 11:23 AM, chromatic wrote:
Alternately, we could hoist this macro into a header, rename it
back to MAX,
and define it only if no system header defines MAX. I think it's
in math.h,
but I'm not positive.
It's that "I'm not positive" that scares me, because on the BSD bo
On Wednesday 20 June 2007 07:57:15 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/inter_call.c
>
> Log:
> Changed MAX to PARROT_MAX to avoid conflicts with any existing MAX
> Modified: trunk/src/inter_call.c
> ===
>=== -
bignum.c seems to be entirely unused. Everything builds just fine
without it. There are many lint errors in it, such as int functions
returning with "return;" and no value.
Can we throw it away? Move it somewhere out of the way?
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => A
Greetings,
On Mon Jun 18 16:57:45 2007, chromatic at wgz.org wrote:
> Per the note in src/string.c around line 509:
>
> /* XXX This is identical to string_from_cstring and should be removed */
> PARROT_API
> STRING *
> string_from_const_cstring(Interp *interp,
>
# New Ticket Created by Allison Randal
# Please include the string: [perl #43261]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43261 >
The PMC src/pmc/stmvar.pmc currently shows up in the package information
as "XXX".
<
On Tue, Jun 19, 2007 at 10:53:07PM -0700, Allison Randal wrote:
> Jonathan Scott Duff wrote:
> >
> >- Misc:
> > + Updated Parrot distribution to Artistic License 2.0, from dual
> >Artistic 1/GPL license.
> >
> > Does this mean that Parrot is no longer dual licensed?
>
> Yes. Under
27 matches
Mail list logo
