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
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()
# %()
--- 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
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
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 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
> ..., 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
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 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
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.
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
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/
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
>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 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 {
> >
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 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
[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
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
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
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
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
# 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
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 "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
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
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 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, 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
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
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
# 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 :
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
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
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.
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
> 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
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
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
> > 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
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
# 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
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
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
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
"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.
# 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)
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
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:
> ... 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
> > 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
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
55 matches
Mail list logo
