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
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
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
Sorry, I was being too terse in my original message, I guess some of the
meaning got lost.
When I said:
> > If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> > then how do you impose hash context onto something without doing the
> > copy?
What I meant to say was:
> > Spea
On Tuesday 16 July 2002 01:01 am, Deborah Ariel Pickett wrote:
> If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> then how do you impose hash context onto something without doing the
> copy?
%{} forces hash context. What else could it do?
%{ foo() } calls foo() in hash c
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
> > Using %(...) to create a hashref, as { ... } does in Perl5, would go
> > against all that, because the purpose of making a hashref is to
> > *reference* something. Now a unary % operator/sigil/prefix might mean
> > referencing, or it might mean dereferencing, depending on whether the
> > symb
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
Trey Harris wrote:
> Yes. This is my fear of hyperoperation being the default for normal
> aggregates. Loops--and large, multiply-nested, potentially-infinite
> ones--can spring out of code that doesn't look loopy at all. Erm... you
> know what I mean. :-)
>
> Karl, do you have any objection
On Tue, 16 Jul 2002, Deborah Ariel Pickett wrote:
> > I still have my vote on %() as a hash constructor in addition to {}. :)
>
> The problem I see with that is that % as a prefix implies a
> *dereferencing*, though years of Perl5 conditioning like this:
> %{ $mumble } = return_a_hash();
> p
> I still have my vote on %() as a hash constructor in addition to {}. :)
The problem I see with that is that % as a prefix implies a
*dereferencing*, though years of Perl5 conditioning like this:
%{ $mumble } = return_a_hash();
print_hash( %{ $mumble } );
(Yes, the braces are optional; I'm
David Whipp:
# Brent Dax wrote:
# > $href = hash { %hash }; #B
#
# Why the curlies? if C is a function (ctor), then surely
# these should be parentheses. In this context, parentheses are
# optional, so this could be written
#
#$href = hash %hash;
C is not a function. It's a keyword
Brent Dax wrote:
> $href = hash { %hash }; #B
Why the curlies? if C is a function (ctor), then surely these should
be parentheses. In this context, parentheses are optional, so this could be
written
$href = hash %hash;
Dave.
On Monday 15 July 2002 11:22 pm, Deborah Ariel Pickett wrote:
> Besides, does
> $hashref = some_function_returning_a_hash()
> make $hashref simply refer to the result of the function, or does it
> make $hashref refer to a hash containing a *copy* of the result of the
> function? If Perl6 is
Deborah Ariel Pickett:
# > > ..., and someone pointed out that it had a problem
# > > with code like "{ some_function_returning_a_hash()
# }". Should it give a
# > > closure? Or a hash ref? ...
# > Oh, well now that it's stated this way... (something went
# wrong in my
# > brain wh
# 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 :
Back to this again . .
> > ..., and someone pointed out that it had a problem
> > with code like "{ some_function_returning_a_hash() }". Should it give a
> > closure? Or a hash ref? ...
> Oh, well now that it's stated this way... (something went wrong in my
> brain when I read the
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
In a message dated Mon, 15 Jul 2002, Brent Dax writes:
> With explicit, you just get the result of Inf ** 2 (which presumably is
> still Inf) in $bar. Perhaps neither is what you want, but at least it
> doesn't take forever to run.
Yes. This is my fear of hyperoperation being the default for no
Karl Glazebrook:
# On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote:
#
# > On Mon, 15 Jul 2002, Luke Palmer wrote:
# >
# >> On Mon, 15 Jul 2002, Karl Glazebrook wrote:
# >>
# >>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
# >>
# >> That would not be very pretty, indeed
At 2:09 PM -0400 7/15/02, Karl Glazebrook wrote:
>
>>On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote:
>>Sure, that's always an option. I think Perl has a lot going for it other
>>than the way vectorization happens, and with the ability to define your
>>own array behavior, you can prett
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
[several replies flattened into one]
On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote:
> On Mon, 15 Jul 2002, Luke Palmer wrote:
>
>> On Mon, 15 Jul 2002, Karl Glazebrook wrote:
>>
>>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>>
>> That would not be very pretty, ind
On Mon, 2002-07-15 at 11:29, Karl Glazebrook wrote:
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> (or would it be ^sqrt() ?) - This looks like sendmail :-)
I would imagine that non-binary operators would simply have a hyper-form
(which could
On Mon, 15 Jul 2002, Luke Palmer wrote:
> On Mon, 15 Jul 2002, Karl Glazebrook wrote:
>
> > @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> That would not be very pretty, indeed. It would also not be very
> efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty,
On Fri, 2002-07-12 at 13:22, Thomas A. Boyer wrote:
> Aaron Sherman wrote:
> > An example:
> >
> > $pid = fork() // -1;
> > if $pid < 0 {
> > # error ...
> > } else unless $pid {
> > # Parent
> > } else if $pid > 0 {
> > # Child
> > } else {
> >
>Karl Glazebrook <[EMAIL PROTECTED]> disgusted:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>[Stuff]
>If I was forced to write vector code like this I *WILL* give up on perl,
>and resort to Numerical
>Python or IDL instead.
>
You can always use the map and foreach lik
On Mon, 15 Jul 2002, Karl Glazebrook wrote:
> In Apocalypse 2 Larry Wall wrote:
>
> > RFC 082: Arrays: Apply operators element-wise in a list context
> >
> > APL, here we come... :-)
> >
> > This is by far the most difficult of these RFCs to decide, so I'm going
> > to be doing a lot of thinkin
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
In Apocalypse 2 Larry Wall wrote:
> RFC 082: Arrays: Apply operators element-wise in a list context
>
> APL, here we come... :-)
>
> This is by far the most difficult of these RFCs to decide, so I'm going
> to be doing a lot of thinking out loud here. This is research--or at
> least, a search.
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
> ..., and someone pointed out that it had a problem
> with code like "{ some_function_returning_a_hash() }". Should it give a
> closure? Or a hash ref? ...
Oh, well now that it's stated this way... (something went wrong in my
brain when I read the actual message) It returns a clos
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
On Monday 15 July 2002 07:52 am, Brent Dax wrote:
> Ashley Winters:
> # > You've got a point. There's an easy way to say "I want a sub":
> # >
> # > my $sub = -> { ... }
> # >
> # > But I can't think of a similarly punctuation-intensive way
> # to say "I
> # > want a hash." (someone please step
--- 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
Ashley Winters:
# > You've got a point. There's an easy way to say "I want a sub":
# >
# > my $sub = -> { ... }
# >
# > But I can't think of a similarly punctuation-intensive way
# to say "I
# > want a hash." (someone please step in and correct me).
#
# I nominate:
#
# $() == scalar()
# %()
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
55 matches
Mail list logo
