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
--- 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 STDIO.
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 version
of
# New Ticket Created by Angel Faus
# Please include the string: [perl #819]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=819
Hi Melvin,
This patch does the following things:
- It includes patch #813 from
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
# New Ticket Created by Tanton Gibbs
# Please include the string: [perl #820]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=820
Adds some additional comments to byteorder.c and adds a byteorder.dev file.
Tanton
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 isn't getting
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 odd
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 identifier
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
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 places
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
# New Ticket Created by Tony Payne
# Please include the string: [perl #821]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=821
Updated hanoi.pasm to use the new (correct?) keyed ops.
Basically used trial and
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 assume
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 [Parrot]
It is a
# New Ticket Created by Tony Payne
# Please include the string: [perl #822]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 used
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
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
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #823]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
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 the
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.
But
23 matches
Mail list logo
