My suggestion is to add on vtable.tbl comment like
void set_integer_native(INTVAL value) # example: set P0, I0
void set_number_native(FLOATVAL value) # example: set P0, N0
and so on. Of course the content of the comment can be more descritive.
Then, I changed parse_vtable and genclass.pl to c
> > Um, I don't think it's right to *always* do the comparison
> > floating point. Specifically, if both operands are ints,
> > the comparison should be int.
>
> I thought about this, but all it buys you is a few bits of precision when
> your ints and floats are both 64-bit, and slower comparison
Sean O'Rourke wrote:
> ... all it buys you is a few bits of precision when your ints
> and floats are both 64-bit, and slower comparisons all the time.
> IMHO it's a wash, so I did it this way.
I would point out that integers have infinite precision.
More than a few bits' difference, I'd say.
B
On Mon, 15 Jul 2002, John Porter wrote:
> Sean O'Rourke wrote:
> > NOTE: this may be part of the monster-patch to fix the over-agressive
> > string GC (814), but it's much more palatable in this form.
> > PerlInt's
> > cmp() method was backwards, and would truncate floats on the other
> > side of
Sean O'Rourke wrote:
> NOTE: this may be part of the monster-patch to fix the over-agressive
> string GC (814), but it's much more palatable in this form.
> PerlInt's
> cmp() method was backwards, and would truncate floats on the other
> side of the comparison.
> This patch always uses floating
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #823]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=823 >
NOTE: this may be part of the monster-patch to fix the over-agressive
string GC (814)
The short version: This is intended to be the "cleaned up to check into
the Parrot tree" version Dan mentioned, so now would be a good time to
yell if you have problems with it. The documentation is much better (or
at least larger) than that in the previous version. You _will_ run into
bugs, but
"David M. Lloyd" wrote:
> Do we really want *two* inheritance trees per object
> in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance, and that's something
we have control
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote:
> >It's also unnecessary. It isn't like there aren't perfectly good
> >alternatives--what's wrong with "Parrot__"?
>
> Well, what's wrong with Parrot_ ?
There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*.
A good thing
# New Ticket Created by Tony Payne
# Please include the string: [perl #822]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=822 >
I set off to try to increase the coverage of parrot_coverage and right away
tripped into
At 11:08 AM 7/15/2002 -0700, Damien Neil wrote:
>On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> > >The last four are reserved by various C and C++ standards.
> >
> > I always hear this, but in real life it is never much of a problem.
> > Especially
> > with a namespace like [Parro
At 11:18 AM 7/15/2002 -0700, Damien Neil wrote:
>On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
> > 1) Async support. The IO system needs to be asynchronous and re-entrant
> > at the core, whether by threads or by use of the platform's async support.
> > Other things like callbacks
# New Ticket Created by Tony Payne
# Please include the string: [perl #821]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=821 >
Updated hanoi.pasm to use the new (correct?) keyed ops.
Basically used trial and error :
On Wed, 10 Jul 2002, Dan Sugalski wrote:
> >What bothers me is this: the programmer needs to be able to predict
> >what the machine is going to do with the code she gives it.
> >And predicting how the machine is going to resolve the multimethod
> >call could be, in any but trivial cases, far too
At 05:25 AM 7/16/2002 +0200, Angel Faus wrote:
>Hi Melvin,
>
>This patch does the following things:
>
> - It includes patch #813 from Sean O'Rourke
>
> - It fixes another bug in spill(), who was generating bad code
>
> - It adds a bunch of work using the control-flow graph, analyzing the
>exact
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
> 1) Async support. The IO system needs to be asynchronous and re-entrant
> at the core, whether by threads or by use of the platform's async support.
> Other things like callbacks assume other features of Parrot to be finished,
> like
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> >The last four are reserved by various C and C++ standards.
>
> I always hear this, but in real life it is never much of a problem.
> Especially
> with a namespace like [Parrot]
It is a good idea to avoid using the reserved identif
On Mon, 15 Jul 2002, Ashley Winters wrote:
> PDD02: Common vtable format for all variables
> Nice.
I should be able to answer some of these.
> Question: Why is the key param for keyed_int vtable functions a pointer?
> Considering I have to implement all those functions to add a PMC...
> seems o
On Fri, 12 Jul 2002, John Porter wrote:
>
> > >Which IRC network, which channel?
> >
> > I use irc.pobox.com, you can also try irc.rhizomatic.net
> > Channel is #parrot
>
> Problem I have with irc (besides the fact that I don't, can't and won't
> use it) is that all the good stuff that flows by i
# New Ticket Created by "Tanton Gibbs"
# Please include the string: [perl #820]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=820 >
Adds some additional comments to byteorder.c and adds a byteorder.dev file.
Tanton Gi
Brent Dax writes:
>[EMAIL PROTECTED]:
># Good stuff. Didn't you also send out a draft PDD about how
># types should
># be named and managed in parrot at one point? I, for one,
>
>At one point I sent out a patch to PDD7 that handled type naming.
(I don't know what happened to this specific pa
# New Ticket Created by Angel Faus
# Please include the string: [perl #819]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=819 >
Hi Melvin,
This patch does the following things:
- It includes patch #813 from Sean O'R
Paul Kienzle:
# On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
# > On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > > -C library wrappers: This is Parrot's version of the
# function, so
# > > it makes sense to prefix it with Parrot_.
# > >
# > > The third category I can se
Well... emacs does not recognize .pmc files as any kind of known type.
I suggest to add a -*- c -*- comment on the generated files. For that, a
simple line can be added on genclass.pl:
Index: genclass.pl
===
RCS file: /cvs/public/
At 5:24 AM -0500 7/15/02, Steve Purkis wrote:
>On Sun, 14 Jul 2002, Dan Sugalski wrote:
>
>> At 9:36 PM -0500 7/13/02, Steve Purkis wrote:
>> >Hi,
>> >
>> >I was inspired by Time::HiRes to create 2 new simple ops for parrot:
>> >usleep(int), and sleep(num), to behave a bit more like the float
On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
> On Monday 15 July 2002 02:25 am, Brent Dax wrote:
> > -C library wrappers: This is Parrot's version of the function, so it
> > makes sense to prefix it with Parrot_.
> >
> > The third category I can see having a prefix of plat_ (fo
I forgot to ask, should i make a patch in this stage early stage or should
i wait until i got the memory stuff added?
/Josef
On Sun, 14 Jul 2002, Dan Sugalski wrote:
> At 9:36 PM -0500 7/13/02, Steve Purkis wrote:
> >Hi,
> >
> >I was inspired by Time::HiRes to create 2 new simple ops for parrot:
> >usleep(int), and sleep(num), to behave a bit more like the float version
> >of the time op.
> >
> >I've attached a patch m
I have successfully written and read an 8x8 matrix.
I will start writing some documentation.
Current code lacks a proper representation of a matrix ( it doesnt have a
matrix structure ) , it works directly in a Buffer structure. I really
need some people to discuss ideas with before deciding the
--- Josh Wilmes <[EMAIL PROTECTED]> wrote:
> IMHO, all IO in parrot should go through PIO, so
> file descriptors should
> not be used at all.
>From io.ops:
"This will go away when print ops are all migrated to
use ParrotIO instead of STDIO. Right now ParrotIO is
not stable enough to replace STDI
Hi!
Some simple (some other not so simple) suggestions to do on current
parrot source:
- make 'genclass.pl' put on the first line of the pmc file something
like '-*- c -*-' in a comment, to tell emacs we are editing c code.
- make 'genclass.pl' put a sample line of Parrot in comment before each
31 matches
Mail list logo
