RE: Revamping the build system
Hi, > > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > There's nothing really past what make does. The reason for having our own is: > *) Make isn't everywhere (like windows) > *) Make on various platforms has different syntax (VMS, Windows, and Unix > are all different) > *) Not speaking for anyone else, but I find make's gotten rather creaky > a round the edges--after 20+ years presumably we can make things a bit better > *) Having the full power of perl in the build tool should give us a big > boost in utility. (Consider the difference between C macros and Perl source > filters) > *) It'll be really unfamiliar to everyone, which'll stop folks from falling > into old, non-portable habits. If there is going to be a new build tool for perl6, i would suggest using something similar to Ant (http://jakarta.apache.org/ant/) Ant is not suitable for parrot of course (it requires Java) but its design is quite good imho. >From its webpage: > Ant is different. Instead of a model where it is extended with shell based commands, it is > extended using Java classes. Instead of writing shell commands, the configuration files > are XML based calling out a target tree where various tasks get executed. Each task is run > by an object which implements a particular Task interface. It tries to avoid executing shell commands (which is good if you want to be portable to places like Windows) and instead it comes with a predefined set of tasks (remove files, compile, etc..). that can be extended programming your own Task classes. This article: http://www.onjava.com/pub/a/onjava/2001/02/22/open_source.html does a very good job at giving you a feeling of how it works. In my limited expierence, this is something very similar to what we would need for parrot/perl6. Just my half a cent, Angel Faus [EMAIL PROTECTED] vLex.com
RE: Languages in the core source tree?
> 1) Do we put them all in the parrot CVS tree I think it would be good for the languages to be in tree, but I would like to have it under a different mechanism for cvs checkout. In other words, the default cvs checkout of parrot does NOT check out the languages tree, but a separate checkout is required for the languages. > 2) Do we require them to meet the same levels of quality as the core > interpreter? At some point they should need to meet same criteria as the parrot. Right now, I think the priority is parrot and should remain such. I think the language implementations are just an experiment, and should not be held to the same criteria (that should be stated somewhere). However, at some predetermined point, some resources should be redirected to testing and refining all of the subtrees (including docs). Grant M.
Shared objects and handoffs (was Re: Parrot's threading model)
On Tue, 16 Oct 2001, Dan Sugalski wrote: > An interpreter can get access to a shared PMC in another interpreter > only at interpreter clone time, or if explicitly passed in via an (as > yet undetermined) handoff method. One thing I'd really like to be able to do in Parrot/Perl 6 is to be able to take groups of objects and pass them between threads (but not necessarily have them be shared) instead of having several individual mutex-protected objects. Maybe an extension on the compartments idea: Allow a parrot program to declare a new PMC container. Then when the program creates an object you can choose which compartment to stick it into. Then use the undetermined handoff method to move the whole compartment between threads (see below for hadnoff method idea). An access to a compartment that is not held by the current thread would be an error, as would be making references between compartments. Then all you need to implement this is one mutex per compartment that is held by whichever thread "owns" that compartment. You don't even ever have to unlock it if the thread never gives up ownership of the compartment. This would be great for daemons that need to be state-aware since they could store state information in a compartment and pass that compartment to whichever thread is handling it. Also, here's a handoff method idea: Make a (base?) type for object queues. These queues would be shared according to the rules you stated above. Define an enqueue and dequeue method that can move object compartments. Anyway, that's my idea. Now what the Perl 6 semantics would be for all this stuff I have no idea. :-) - D <[EMAIL PROTECTED]>
Minor bugfix to the Artistic-2.0 proposal
I am sure that Larry won't be writing an apocalypse on licensing anytime soon, but in the meantime I was reading over the Artistic-2.0 proposal and noted a minor grammar error in it. I can't update the RFC, but figured I'd post the bugfix here. Attached is a unified diff and a full copy of the changed file. -- bkuhn --- Artistic-2.0.txtSun Oct 1 17:53:16 2000 +++ Artistic-2.0beta5.txt Mon Oct 22 12:29:15 2001 @@ -1,9 +1,9 @@ The Artistic License - Version 2.0beta4, October 2000 + Version 2.0beta5, October 2001 - Copyright (C) 2000, Larry Wall. -Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. + Copyright (C) 2000, 2001 Larry Wall. + Everyone is permitted to copy and distribute verbatim copies +of this license document, but changing it is not allowed. Preamble @@ -110,8 +110,8 @@ the Standard Version. (c) permit and encourage anyone who receives a copy of the Modified - Version permission to make your modifications Freely Available in - some specific way. + Version to make your modifications Freely Available in some + specific way. If Your Modified Version is in turn derived from a Modified Version made by a third party, then You are still required to ensure that Your The Artistic License Version 2.0beta5, October 2001 Copyright (C) 2000, 2001 Larry Wall. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble This copyright license states the terms under which a given free software Package may be copied, modified and/or redistributed, while the Originator(s) maintain some artistic control over the future development of that Package (at least as much artistic control as can be given under copyright law while still making the Package open source and free software). This license is bound by copyright law, and thus it legally applies only to works which the copyright holder has permitted copying, distribution or modification under the terms of the Artistic License, Version 2.0. You are reminded that You are always permitted to make arrangements wholly outside of a given copyright license directly with the copyright holder(s) of a given Package. If the terms of this license impede your ability to make full use of the Package, You are encouraged to contact the copyright holder(s) and seek a different licensing arrangement. Definitions "Package" refers to the collection of files distributed by the Originator(s), and derivatives of that collection of files created through textual modification. "Standard Version" refers to the Package if it has not been modified, or has been modified only in ways suggested by the Originator(s). "Modified Version" refers to the Package, if it has been changed by You via textual modification of the source code, and such changes were not suggested by the Originator(s). "Originator" refers to the author(s) and/or copyright holder(s) of the Standard Version of the Package. "You" and "Your" refers to any person who would like to copy, distribute, or modify the Package. "Distribution Fee" is any fee that You charge for providing a copy of this Package to another party. It does not refer to licensing fees. "Freely Available" means that: (a) no fee is charged for the right to use the item (though a Distribution Fee may be charged). (b) recipients of the item may redistribute it under the same conditions they received it. (c) If the item is a binary, object code, bytecode, the complete corresponding machine-readable source code is included with the item. Permission for Use and Modification Without Redistribution (1) You are permitted to use the Standard Version and create and use Modified Versions for any purpose without restriction, provided that you do not redistribute the Modified Version to others outside of your company or organization. Permissions for Redistribution of the Standard Version (2) You may make available verbatim copies of the source code of the Standard Version of this Package in any medium without restriction, either gratis or for a Distribution Fee, provided that you duplicate all of the original copyright notices and associated
RE: Default values, was RE: the handiness of undef becoming NaN (when you want that)
> > Aaron Sherman wrote > Larry's hubris notwithstanding, I'd like to suggest that > "more", in this > case means "no, it prints nothing". > > This *must* be true, as you don't want: > > @a ^+ @b > > to always return an infinite list. You want it to produce a list with > (as a3 suggested) length max(@a.length,@b.length) OK, now we've got this resolved, I'd like to return the focus back to the original point. @x ^= 0; @x[5]++; does not have problems with NaNs; and does not generate a warning with -w. My suggestion was to extend this to work with hashes, too. something like %x ^= $^_ => 0; or values %x ^= 0; Dave.
Re: Default values, was RE: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 01:36:02PM -0700, David Whipp wrote:
> OK, now we've got this resolved, I'd like to return the focus
> back to the original point.
>
> @x ^= 0;
> @x[5]++;
>
> does not have problems with NaNs; and does not generate a warning
> with -w.
Someone's missing something, and I sure hope it's not me. Let me write
a code sample here:
sub incrind (@ary, $ind) {
@ary[$ind]++
}
Are you suggesting that by adding in "@ary ^= 0", like so:
sub incrind (@ary, $ind) {
@ary ^= 0;
@ary[$ind]++;
}
that @ary[$ind] does not become NaN, even if $ind>@ary.length? If this
is what you're suggesting, I cannot see why it would be the case.
You'll have to enlighten me.
Even with lazy array evaluation, you do LOGICALLY create an array
with the given length, even if the space only gets sucked up after
the fact. If @ary^=0 logically creates an infinitely long array, then
it is a very dangerous operator indeed (but, of course, according to
a3, it will not).
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 04:21:32PM -0400, Aaron Sherman wrote:
> On Mon, Oct 22, 2001 at 08:25:21PM +0100, Piers Cawley wrote:
>
> > > What REALLY worries me is that values that seem to be numbers, but are
> > > in fact garbage ARE going to screw my average up. I dare Perl6 to fix
> > > that for me.
> >
> > It's not going to. Getting NaN as a result in this context should be a
> > *really* big clue that Perl's found some garbage that it didn't
> > understand. If you want to know where then CHECK YOUR VALUES.
>
> You misunderstood me. Yes, you'll get NaN if your garbage happens
> to not look like a number. But, this can give me no more sense of
> security than I had before, since garbage that happens to look like
> a number will still work "correctly".
So ... what do we want Perl's default nummify behaviour to be? Right
now it trys to be smart in that if your string looks like "0xab" or
"12e3", it'll gladly be converted to 171 and 12000 respectively.
I think I'd prefer Perl be generally stupid about how it converts
strings to numbers so that the string "0xab" would get converted to 0
and the string "12e3" would get converted to 12. All other complex
behavior could be done via pragmata or the user could specify
themselves like so:
sub operator:+($nomnum) {
return $1if $nomnum =~ /^(\d+)$/;
return hex($1) if $nomnum =~ /^(0x[0-9a-fA-F]+)$/;
return oct($1) if $nomnum =~ /^(0[0-7]+)$/;
return bin($1) if $nomnum =~ /^(0b[01]+)$/;
return com($1) if $nomnum =~ /^(\d+i)$/;
return NaN;
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: the handiness of undef becoming NaN (when you want that)
Okay, in the (probably forlorn) hope of beating this subject to death,
let me offer a possible (post-A3/E3) position on NaN.
NaN is dead.
Except perhaps under a C pragma of some kind, in which case it
would be a proper IEEE NaN.
C with numerify to zero (it always has; and we always intended
that it still would).
Unary C<+> (and other numeric contexts) will produce C when
attempting to convert non-numeric strings.
To check for numericity of input, you'll write:
$number = +<$fh>
until defined $number;
If you ignore the definedness, the C will just promote to zero
in numeric contexts. So you can add up your column-50 numeric fields with:
$sum += +unpack("@49 A3", $_)
while <$fh>;
and have it ignore non-numeric fields.
Or you can add the fields with:
$sum += +unpack("@49 A3", $_) // die "Bad data: $_"
while <$fh>;
and handle errors with extreme prejudice.
Have I missed anything?
Damian
Re: the handiness of undef becoming NaN (when you want that)
[Oops, I fired off too-early a draft. Here's the full thing...]
Okay, in the (probably forlorn) hope of finally Beating This Subject To Death,
let me offer a (possible) new position on NaN.
NaN is dead. It's not pinin'! It's passed on! This value is no more! It
has ceased to be! It's expired and gone to meet its maker! It's a
stiff! Bereft of life, it rests in peace! If we hadn't nailed it to an
Exegesis, it'd be pushing up the daisies! Its metabolic processes are now
'istory! It's off the twig! It's kicked the bucket, shuffled off its
mortal coil, run down the curtain and joined the bleedin' choir
invisible!! THIS IS AN EX-NaN!!
Except perhaps under a C pragma of some kind, in which case it
would be a proper IEEE Norweigian Blue NaN.
Meanwhile, C will numerify to zero (asit always has; as we always
intended that it still would).
Unary C<+> (and other numeric contexts) will produce C when
attempting to convert non-numeric strings.
To check for numericity of input, you'll write:
$number = +<$fh>
until defined $number;
If you ignore the definedness, the C will just promote to zero
in numeric contexts. So you can add up your column-50 numeric fields with:
$sum += +unpack("@49 A3", $_)
while <$fh>;
and have the summation ignore non-numeric fields.
Or you can add the fields with:
$sum += +unpack("@49 A3", $_) // die "Bad data: $_"
while <$fh>;
and handle errors with extreme prejudice.
Have I missed anything?
Damian
Re: the handiness of undef becoming NaN (when you want that)
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2001 at 07:39:44PM +0100, Piers Cawley wrote:
>
>> Yeah, but it's correct. If you extract something and get garbage then
>> you're going to screw your average up. Admittedly, in 400,000 lines,
>> it's unlikely to shift the average by much, but it will shift it.
>
> No, I'm interpreting unknown values as zero. My average is correct.
> If you want to argue that I should be treating them as something
> else, that's your lookout, but I'm happy with that interpretation.
If you want to interpret unknown values as zero then you can make that
explicit. Which is a good thing, because it makes clarifies the intent
of your code.
> What REALLY worries me is that values that seem to be numbers, but are
> in fact garbage ARE going to screw my average up. I dare Perl6 to fix
> that for me.
It's not going to. Getting NaN as a result in this context should be a
*really* big clue that Perl's found some garbage that it didn't
understand. If you want to know where then CHECK YOUR VALUES.
>> Of course, this is assuming there's no difference between:
>>
>> $total += substr($_, 22, 2); # implicit numification
>>
>> $total += +substr($_, 22, 2); # explicit numification
>
> If we were to decompile the first example, it would not be the same
> as the second? Is there an implied operator here that I'm not seeing?
> How does it behave? According to Larry, unary + forces a numeric
> context, but you're saying that a numeric context can be distinguished
> from a unary +
>
> I'm confused.
No. I'm saying that this may be a possibility. But, frankly, it looks
like scary DWIMmery to me. I'd rather have it return NaN in both
contexts.
>> Which might be controllable via pragma.
>
> As long as the pragma leaves:
>
> perl -nle '$t+=$_;END{print $t}'
>
> alone, I'm OK. If blank lines will cause that to choke, I'm an
> unhappy camper.
>
>> if ($val ne 'NaN') { # Ugly, gets 'round the IEEE thing
>
> sub notnan ($number) {
> return $number >= -Inf;
> }
>
>> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
>> > continue to work.
>>
>> And it will, since it has nothing whatsoever to do with string
>> numification.
>>
>> %x{non_existent}++ # Doesn't do numification. Autovivifies an entry in
>># %x, with value 'undef', which numfies to 0.
>
> Actually, numification of undef was the entry point to this thread,
> so my point remains. If notnan(undef), I'm happy, else I am become
> concerned
Ah yes. That suggestion was so self evidently stupid it slipped my
mind. Though the stuff discussed above is definitely about
numification of strings.
--
Piers
Re: the handiness of undef becoming NaN (when you want that)
On Tue, Oct 23, 2001 at 07:30:00AM +1000, Damian Conway wrote: > To check for numericity of input, you'll write: > > $number = +<$fh> > until defined $number; > > If you ignore the definedness, the C will just promote to zero > in numeric contexts. I'm confused. By the time $number sees the line from the filehandle, it's already been nummified to 0. Does that mean we have "0 but undefined" or something? Shouldn't it be: $number = +($_ = <$fh>) until defined; ? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: the handiness of undef becoming NaN (when you want that)
> > To check for numericity of input, you'll write: > > > > $number = +<$fh> > > until defined $number; > > > > If you ignore the definedness, the C will just promote to zero > > in numeric contexts. > > I'm confused. By the time $number sees the line from the filehandle, > it's already been nummified to 0. No. I'm saying that if you give unary C<+> a string that can't be interpreted as a number, unary C<+> gives you back C. So on "bad" input, $number gets C and the loop repeats. Damian
Re: the handiness of undef becoming NaN (when you want that)
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
>> > > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
>> > > continue to work.
>> >
>> > What is void plus one?
>>
>> Can't we utilize the lazy arrays stuff to make all this work.
>> Out of the box, all entries could default to NaN. But its easy
>> to write
>>
>> @a ^= 0;
>>
>> to change this default. I'm sure this could be extended to work
>> with hashes. I'm not sure what the correct syntax is, though.
>
> Nope.
>
> my @a;
> @a ^= 0;
> print @a
>
> Are you saying that this should print an infinite number of zeros?
Unlikely, since the hyper operator is lazy. I submit it should print
the empty string.
This is all nastiness arising from the bloody stupid suggestion that
undef numify to NaN isn't it?
--
Piers
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 08:25:21PM +0100, Piers Cawley wrote: > > What REALLY worries me is that values that seem to be numbers, but are > > in fact garbage ARE going to screw my average up. I dare Perl6 to fix > > that for me. > > It's not going to. Getting NaN as a result in this context should be a > *really* big clue that Perl's found some garbage that it didn't > understand. If you want to know where then CHECK YOUR VALUES. You misunderstood me. Yes, you'll get NaN if your garbage happens to not look like a number. But, this can give me no more sense of security than I had before, since garbage that happens to look like a number will still work "correctly". Perl cannot find errors in my data, it can only guess badly. Let *me* worry about my data, please and assume that if I asked for a cat to pull my sled, I really wanted a cat to pull my sled, not some much larger member of the cat familly that will turn around and eat my children. Umm, perhaps that metaphor was a tad stretched ;-) -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF "Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew." -Queen/_'39_
Re: Default values, was RE: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 12:23:34PM -0700, David Whipp wrote: > Aaron Sherman wrote > > > > my @a; > > @a ^= 0; > > print @a > > > > Are you saying that this should print an infinite number of zeros? > > > > Quoting Larry on this subject (apocalypse 3, bottom of page 3): "I > can think of other cans of worms this opens, and I'm quite certain > I'm too stupid to think of them all. Nevertheless, my gut feeling > is that we can make things work more like people expect rather > than less. And I was always a little bit jealous that REXX could > have arrays with default values. :-)" Larry's hubris notwithstanding, I'd like to suggest that "more", in this case means "no, it prints nothing". This *must* be true, as you don't want: @a ^+ @b to always return an infinite list. You want it to produce a list with (as a3 suggested) length max(@a.length,@b.length) -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF "Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 07:39:44PM +0100, Piers Cawley wrote:
> Yeah, but it's correct. If you extract something and get garbage then
> you're going to screw your average up. Admittedly, in 400,000 lines,
> it's unlikely to shift the average by much, but it will shift it.
No, I'm interpreting unknown values as zero. My average is correct.
If you want to argue that I should be treating them as something
else, that's your lookout, but I'm happy with that interpretation.
What REALLY worries me is that values that seem to be numbers, but are
in fact garbage ARE going to screw my average up. I dare Perl6 to fix
that for me.
Since when is Perl a language that coddles the user and presents
the One Correct Way To Do It?
> Of course, this is assuming there's no difference between:
>
> $total += substr($_, 22, 2); # implicit numification
>
> $total += +substr($_, 22, 2); # explicit numification
If we were to decompile the first example, it would not be the same
as the second? Is there an implied operator here that I'm not seeing?
How does it behave? According to Larry, unary + forces a numeric
context, but you're saying that a numeric context can be distinguished
from a unary +
I'm confused.
> Which might be controllable via pragma.
As long as the pragma leaves:
perl -nle '$t+=$_;END{print $t}'
alone, I'm OK. If blank lines will cause that to choke, I'm an
unhappy camper.
> if ($val ne 'NaN') { # Ugly, gets 'round the IEEE thing
sub notnan ($number) {
return $number >= -Inf;
}
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > continue to work.
>
> And it will, since it has nothing whatsoever to do with string
> numification.
>
> %x{non_existent}++ # Doesn't do numification. Autovivifies an entry in
># %x, with value 'undef', which numfies to 0.
Actually, numification of undef was the entry point to this thread,
so my point remains. If notnan(undef), I'm happy, else I am become
concerned
> Disagree.
Agree ;-)
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
> > > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > > continue to work.
> >
> > What is void plus one?
>
> Can't we utilize the lazy arrays stuff to make all this work.
> Out of the box, all entries could default to NaN. But its easy
> to write
>
> @a ^= 0;
>
> to change this default. I'm sure this could be extended to work
> with hashes. I'm not sure what the correct syntax is, though.
Nope.
my @a;
@a ^= 0;
print @a
Are you saying that this should print an infinite number of zeros?
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Default values, was RE: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote
> On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
> > > > More, someone has mentioned the %x{$_}++ feature, which
> IMHO, MUST
> > > > continue to work.
> > >
> > > What is void plus one?
> >
> > Can't we utilize the lazy arrays stuff to make all this work.
> > Out of the box, all entries could default to NaN. But its easy
> > to write
> >
> > @a ^= 0;
> >
> > to change this default. I'm sure this could be extended to work
> > with hashes. I'm not sure what the correct syntax is, though.
>
> Nope.
>
> my @a;
> @a ^= 0;
> print @a
>
> Are you saying that this should print an infinite number of zeros?
>
Quoting Larry on this subject (apocalypse 3, bottom of page 3): "I
can think of other cans of worms this opens, and I'm quite certain
I'm too stupid to think of them all. Nevertheless, my gut feeling
is that we can make things work more like people expect rather
than less. And I was always a little bit jealous that REXX could
have arrays with default values. :-)"
Dave.
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 04:27:24PM +0100, Sam Vilain wrote:
> On Fri, 19 Oct 2001 09:27:50 -0400
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > > I am implementing a textbook algo in Perl (the textbook has
> > > it written in C++) and have realized that if undef was to
> > > numericize to NaN instead of 0, there are a lot of uninitialization
> > > errors that would get caught.
> > > use strict vars;
> > > does not recognize use of new array indices as unitialized variables.
> > Yes, but do you really want to break:
> > $z[0] = 50;
> > $z[2] = 20;
> > @x = @y[@z];
>
> In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or
> (@y[50,undef,20]) ?
@y[50,undef,20], which in Perl5 is @y[50,0,20].
I have a great many fears around NaN. I think I should only be able to
get a NaN by:
Directly invoking it (e.g. $x = NaN)
Performing a mathematical operation whose result would
otherwise be an exception (e.g. $x = 1/0)
If there are other means, I'm not thinking of them right now.
Perl's conversion of undefined values and strings to 0 is VERY
USEFUL. I'd really like to avoid breaking it. Yes //, makes it
easier to get over the undef thing, but only a little.
Let's take this code as an example:
while(<>) {
$count++;
$total += substr($_,22,2);
}
printf "Average: %.2f\n", $total/$count;
Right now, if my expected numeric column has garbage in it on the
400,000th line, I treat it as zero and go on, getting a meaningful
result. If that garbage translates to NaN, then I'm going to get
"Average: NaN" as my result? That's just freaky!
More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST continue
to work.
NaN is a nice feature, but I don't think that it should be an EASY
to invoke it.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote:
> Let's take this code as an example:
>
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
>
> Right now, if my expected numeric column has garbage in it on the
> 400,000th line, I treat it as zero and go on, getting a meaningful
> result.
Indeed, you might consider "ignoring garbage" as producing a "meaningful
result", and in the application you envision, that could be extremely useful.
However, in other applications, the fact that there was garbage on the
400,000th line could be critical to determining a serious flaw in the results.
I note that your "ignored garbage" isn't completely ignored: you still count
the line, thusly adjusting your average downward somewhat. Of course if there
are millions of non-garbage lines, the difference will be small, and perhaps,
for your application, irrelevant.
However, if, starting from the 100,000th line through the 600,000th line, all
is garbage, and there are only 700,000 lines, the garbage could have quite a
bias to the results, and you'd never notice by looking at the first few and
last few pages of the report.
> If that garbage translates to NaN, then I'm going to get
> "Average: NaN" as my result? That's just freaky!
Garbage in, garbage out. However, in the case of NaN, at least you can tell
that the output is, indeed, garbage. Silent conversion to zero can bias
results, and it might go undetected.
> More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST continue
> to work.
>
> NaN is a nice feature, but I don't think that it should be an EASY
> to invoke it.
Indeed, NaN is a nice feature; I hope I've shown that for your example there is
a counterexample where it would be helpful to avoid silent conversions of
garbage to zero.
I think both sets of semantics are useful; I'd personally consider your example
a bug, and would rather see code like
while (<>)
{ my $temp = substr($_,22,2);
if ( is_numeric ( $temp ))
{ $count ++;
$total += $temp;
} else
{ $badlines ++;
}
}
printf "Average: %.2f\n", $total/$count;
printf "goodlines: $count badlines: $badlines\n";
for some definition of "is_numeric", possibly checking for the reasonableness
of the range of the input number for the particular application, as well as it
looking like a number.
Yes, it takes a few extra lines to code, but adds a significant amount of
surety to the usefulness of the results.
Clearly my code could be written with or without the existance of the NaN
feature. The existance of and use of the feature of string garbage converting
to NaN allows your code to be used more safely, and when the result is NaN, you
realize the need to convert your code to my code to determine the validity of
your results.
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: the handiness of undef becoming NaN (when you want that)
On Mon, 22 Oct 2001 12:18:16 -0400
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > > $z[0] = 50;
> > > $z[2] = 20;
> > > @x = @y[@z];
> > In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or
> > (@y[50,undef,20]) ?
> @y[50,undef,20], which in Perl5 is @y[50,0,20].
An arbitrary and perhaps confusing decision.
> If there are other means, I'm not thinking of them right now.
> Perl's conversion of undefined values and strings to 0 is VERY
> USEFUL. I'd really like to avoid breaking it. Yes //, makes it
> easier to get over the undef thing, but only a little.
I'm always getting warnings when I do stuff like that in my code.
> Let's take this code as an example:
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
An interesting example. The answer I have in mind:
if (m/^.{21}(\d\d)/) {
$total += $1;
}
> More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> continue to work.
What is void plus one?
I think a pragma for this would be ideal.
Sam.
Re: De NaN-ibus
Hufgo suggested: > :Have I missed anything? > > Code, and docs, for ieee.pm. Other than that, it looks good to me. :) Ah, but that's a SMoP, left as an exercise to the reader. ;-) Damian
RE: Default values, was RE: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote:
> Someone's missing something, and I sure hope it's not me. Let me write
> a code sample here:
>
> sub incrind (@ary, $ind) {
> @ary[$ind]++
> }
>
> Are you suggesting that by adding in "@ary ^= 0", like so:
>
> sub incrind (@ary, $ind) {
> @ary ^= 0;
> @ary[$ind]++;
> }
>
> that @ary[$ind] does not become NaN, even if $ind>@ary.length? If this
> is what you're suggesting, I cannot see why it would be the case.
> You'll have to enlighten me.
I would expect this, yes. However, your code would be pretty useless,
because it would also the array before setting a single element.
Better code woudl be:
my @a1 ^= 0; # array with default values as 0
my @a2 ^= NaN; # array with default values as NaN
incrind(@a1, 90) # @a1[90] == 1
incrind(@a2, 90) # @a2[90] == NaN
The hyperassignment, ^=, does not have any size to expand
to, so it assues infinite size. In effect, it does
@a1 = map {0} (0..Inf);
> Even with lazy array evaluation, you do LOGICALLY create an array
> with the given length, even if the space only gets sucked up after
> the fact. If @ary^=0 logically creates an infinitely long array, then
> it is a very dangerous operator indeed (but, of course, according to
> a3, it will not).
I would expect it to DWIM, just as Larry said :-). In some contexts,
it will have zero length, in others it will be infinite. I think
there is the potential for great pain while we try to get the
correct behaviour. One of the goals of lazy arrays is for (1..Inf)
to be a reasonably safe concept.
Another quote from a3: "I'm of the opinion that a lazy list is a
definition of the default values of an array, and that the actual
values of the array override any default values"
Dave.
RE: the handiness of undef becoming NaN (when you want that)
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
>
>Right now, if my expected numeric column has garbage in it on the
>400,000th line, I treat it as zero and go on, getting a meaningful
>result. If that garbage translates to NaN, then I'm going to get
>"Average: NaN" as my result? That's just freaky!
>
>
And in the spirit of hyper-operators doing the right thing when they expand
lists, perhaps garbage in this:
$product *= substr($_,22,2)
should numerify to 1.
Default numerification based on operator context. The identity value, IIRC.
NaN could be the default default, so to speak.
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should check this E-mail for viruses. The Carphone Warehouse Group PLC makes no
representations as regards the absence of viruses in this E-mail. If you have received
this E-mail in error please notify our ISe Response Team immediately by telephone on +
44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then immediately
destroy this E-mail and any copies of it.
Please feel free to visit our website: http://www.phonehouse.com
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 09:39:50AM -0700, Glenn Linderman wrote:
>
> Indeed, you might consider "ignoring garbage" as producing a "meaningful
> result", and in the application you envision, that could be extremely useful.
>
> However, in other applications, the fact that there was garbage on the
> 400,000th line could be critical to determining a serious flaw in the results.
I see your point, but going from: "you have to error-check to be
sure that the average you get is valid" to "you get NaN and like it"
is a bit steep.
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST continue
> > to work.
> >
> > NaN is a nice feature, but I don't think that it should be an EASY
> > to invoke it.
> Indeed, NaN is a nice feature; I hope I've shown that for your example there is
> a counterexample where it would be helpful to avoid silent conversions of
> garbage to zero.
No, I disagree. You're trying to protect the user from Perl's most useful
feature: coping with strangeness. Giving "your data sucks" as an answer is
a very Python thing to do, and in *that* language, I'd say it's the right
choice. In Perl, I'd expect that:
perl -nle '$t+=substr($_,22,2);END{print $t}'
Will do SOMETHING meaningful. NaN is not meaningful, it's the moral
equivalent of "doh!"
> I think both sets of semantics are useful; I'd personally consider your example
> a bug, and would rather see code like
>
> while (<>)
> { my $temp = substr($_,22,2);
> if ( is_numeric ( $temp ))
> { $count ++;
> $total += $temp;
> } else
> { $badlines ++;
> }
> }
> printf "Average: %.2f\n", $total/$count;
> printf "goodlines: $count badlines: $badlines\n";
Ok, so what does this mean:
0123456789012345678901234567890
Freakazoidr x YYY 28
Samurai Jack rwx NNN 19
Batman Beyond rw YYY 34
Dexter's Lab rwx YYY 55
Cowboy Beebop wx NNN 99
Scoobie Doo rwx YYY 01
Dallasrwx NNNx8x
Dr. Who rwx YYYxx8
Clearly, to us humans, the last two lines have garbage. However, unless
you're planning on changing perl SO MUCH that trailing garbage is also
ignored in string-to-number conversion, you're going to have VERY different
handling of those two lines.
For "Dallas" you get 8, and for "Dr. Who" you get NaN!
Is more error checking good? Yes. Is screwing the user who doesn't
error check the right answer? Not in my Perl programming experience
> Yes, it takes a few extra lines to code, but adds a significant amount of
> surety to the usefulness of the results.
But converting to NaN does *not*.
> Clearly my code could be written with or without the existance of the NaN
> feature. The existance of and use of the feature of string garbage converting
> to NaN allows your code to be used more safely, and when the result is NaN, you
> realize the need to convert your code to my code to determine the validity of
> your results.
Great, sounds-like pragma territory. I could live with a:
use string_to_nan;
I have a hard time living with:
use string_to_zero;
and a NaN default.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
On Mon, Oct 22, 2001 at 05:43:58PM +0100, Sam Vilain wrote:
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > continue to work.
>
> What is void plus one?
According to every Perl book I've ever read, 1. I've yet to run into someone
who finds that a difficult concept when the first hit it in one of my
classes. Take the example of the fairly common uniq function:
require 5;
sub uniq {
my %tmp;
my @ans;
foreach my $e (@_) {
push @ans, $e unless $tmp{$e}++
}
return @ans;
}
or the even more common:
require 5;
while(<>) {
$words{$1}++ if /^(\w+)/;
}
print map {"$_ found $words{$_} times\n"} sort keys %words;
> I think a pragma for this would be ideal.
A pragma that forces questionable strings to NaN in a numeric context
would seem fair. A pragma that gets back the old functionality would
just waste space in every program I write. That doesn't even
mention the command-line:
perl -Mundef_zero -nle ...
Ick.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote: > I see your point, but going from: "you have to error-check to be > sure that the average you get is valid" to "you get NaN and like it" > is a bit steep. "you get NaN and like it" only happens when you put garbage in... and get garbage out. Yes, NaN is garbage. But when it doesn't happen, you would have reasonable confidence that the input is not garbage even _without_ writing the error checking code. So I see the tradeoff as being the following: "Automatic NaN conversions for garbage in" allows me to avoid writing the error checking code for cases where good data is coming in, yet have confidence when I get non-NaN output that the data was good (to the extent that numbers appeared where expected in strings). vs. "Automatic conversion of garbage to zero" allows me to get good results for cases where good data is coming in, but for garbage in I get what you call "meaningful results" without any clue as to whether the meaningful results resulted from .005% garbage, or 99.995% garbage, or any other % garbage. So laziness and automatic NaN conversion allows me to write the simple solution, and if all my assumptions about the data are correct, I get good results. But if they aren't, I get NaN, and know I need to write a more careful program, with more input validity checking. Laziness and zero conversion allows me to produce "meaningful results" with no clue as to just how much meaning they actually have. Unless, of course, I happen to divide by one of those garbage ins, and get a "meaningful" divide by zero error. How do you produce "meaningful results" in that case? > For "Dallas" you get 8, and for "Dr. Who" you get NaN! For the present technique of conversion to zero, is the result for "Dallas" or "Dr. Who" a better result? Is a garbage 0 or a garbage 8 more "meaningful" to you? > Is more error checking good? Yes. Is screwing the user who doesn't > error check the right answer? Not in my Perl programming experience We can agree more error checking is good. It is not clear to me that producing "meaningful results" from garbage in should be considered "screwing the user". I'd call it alerting the user that he has some garbage in, and he needs to enhance his code (or data source) to deal with it to produce what I would call meaningful results -- some statistics on % data valid or some such thing. > > Yes, it takes a few extra lines to code, but adds a significant amount of > > surety to the usefulness of the results. > > But converting to NaN does *not*. I suspect you are reacting here to the probably misreading of my statement above. Note, however, that I did not say that converting to NaN adds usefulness to the results. I said it adds "surety" to the usefulness of the results. When you get NaN, you are very, very sure that something went wrong, as NaN is seldom, if ever, useful as a result. So converting to NaN does add a significant amount of _surety_ to the usefulness of the results. You know then, that the results are not useful, because you had garbage in. > Great, sounds-like pragma territory. I could live with a: > > use string_to_nan; > > I have a hard time living with: > > use string_to_zero; > > and a NaN default. If I had to choose among those, I'd personally prefer to live with the second. However, there are other options, some of which have been mentioned in related threads. The option I like is to have Perl 6 provide a selection of different string methods for extracting the numeric values, for a variety of types of numeric values. For example, one method might accept only integers, another method might allow complex numbers, another method might allow metric suffixes for scaling, another method might allow floating point numbers, another might allow decimal numbers without exponents, another might allow full numeric expression evaluation (numeric constants and operators only). With such an option, you could choose the type of conversion based on the type of data you expect. I could see each of those conversion functions taking an optional parameter defining what to return if the conversion fails... typical values for the parameter might be undef, 0, or NaN... and I'd recommend that omitting the parameter would cause the conversion to return undef easily detectable by code that cares, converts to zero for some cases of meaningful results (when they really might be) and compatible with most cases of not supplying a parameter to a method. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
RE: the handiness of undef becoming NaN (when you want that)
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > continue to work.
>
> What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all entries could default to NaN. But its easy
to write
@a ^= 0;
to change this default. I'm sure this could be extended to work
with hashes. I'm not sure what the correct syntax is, though.
Dave.
Re: the handiness of undef becoming NaN (when you want that)
On Fri, 19 Oct 2001 09:27:50 -0400 Aaron Sherman <[EMAIL PROTECTED]> wrote: > > I am implementing a textbook algo in Perl (the textbook has > > it written in C++) and have realized that if undef was to > > numericize to NaN instead of 0, there are a lot of uninitialization > > errors that would get caught. > > use strict vars; > > does not recognize use of new array indices as unitialized variables. > Yes, but do you really want to break: > $z[0] = 50; > $z[2] = 20; > @x = @y[@z]; In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or (@y[50,undef,20]) ? Sam.
Re: the handiness of undef becoming NaN (when you want that)
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2001 at 04:27:24PM +0100, Sam Vilain wrote:
>> On Fri, 19 Oct 2001 09:27:50 -0400
>> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>>
>> > > I am implementing a textbook algo in Perl (the textbook has
>> > > it written in C++) and have realized that if undef was to
>> > > numericize to NaN instead of 0, there are a lot of uninitialization
>> > > errors that would get caught.
>> > > use strict vars;
>> > > does not recognize use of new array indices as unitialized variables.
>> > Yes, but do you really want to break:
>> >$z[0] = 50;
>> >$z[2] = 20;
>> >@x = @y[@z];
>>
>> In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or
>> (@y[50,undef,20]) ?
>
> @y[50,undef,20], which in Perl5 is @y[50,0,20].
>
> I have a great many fears around NaN. I think I should only be able to
> get a NaN by:
>
> Directly invoking it (e.g. $x = NaN)
> Performing a mathematical operation whose result would
> otherwise be an exception (e.g. $x = 1/0)
>
> If there are other means, I'm not thinking of them right now.
> Perl's conversion of undefined values and strings to 0 is VERY
> USEFUL. I'd really like to avoid breaking it. Yes //, makes it
> easier to get over the undef thing, but only a little.
>
> Let's take this code as an example:
>
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
>
> Right now, if my expected numeric column has garbage in it on the
> 400,000th line, I treat it as zero and go on, getting a meaningful
> result. If that garbage translates to NaN, then I'm going to get
> "Average: NaN" as my result? That's just freaky!
Yeah, but it's correct. If you extract something and get garbage then
you're going to screw your average up. Admittedly, in 400,000 lines,
it's unlikely to shift the average by much, but it will shift it.
Of course, this is assuming there's no difference between:
$total += substr($_, 22, 2); # implicit numification
$total += +substr($_, 22, 2); # explicit numification
Which might be controllable via pragma.
However, it seems to me that having both explicit and implicit
numification of garbage go to NaN is a *good* thing because it will
force you to think about what you're doing with code like this. Maybe
you want garbage to increment the count and numify as zero, so you'd
do:
while (<>) {
my $val = +substr($_, 22, 2);
$count++;
if ($val ne 'NaN') { # Ugly, gets 'round the IEEE thing
$total += $val;
}
}
Or, if you just want to skip that line:
while (<>) {
my $val = +substr($_, 22, 2);
next if $val eq 'NaN';
$count++;
$total += $val;
}
> More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> continue to work.
And it will, since it has nothing whatsoever to do with string
numification.
%x{non_existent}++ # Doesn't do numification. Autovivifies an entry in
# %x, with value 'undef', which numfies to 0.
%x{string} = 'string';
%x{string}++
%x{string} == 'strinh';
> NaN is a nice feature, but I don't think that it should be an EASY
> to invoke it.
Disagree.
Re: [perl6]Re: Resync your CVS...
On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote: > On Tue, 23 Oct 2001, Tom Hughes wrote: > >> In message <[EMAIL PROTECTED]> >> Dan Sugalski <[EMAIL PROTECTED]> wrote: >> >>> On Mon, 22 Oct 2001, Sam Tregar wrote: >>> Fresh checkout won't compile on Redhat Linux 7.1: >>> >>> Damn. It compiled cleanly before I checked it in. I'll patch up again and >>> see what I missed. Probably some odd dependency or timing issue >>> somewhere. (It's emacs fault! Yeah, that's the ticket! :) >> >> I'd already patched it up, so I've just committed my fix... > > Thanks. I swear, if I keep this up I'm going to have to yank my own > checkin privs... :) > > Dan > This is why we have tinderbox... Zach
Re: [perl6]Re: Resync your CVS...
At 05:00 PM 10/22/2001 -0700, Zach Lipton wrote: >On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote: > > > On Tue, 23 Oct 2001, Tom Hughes wrote: > > > >> In message <[EMAIL PROTECTED]> > >> Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> > >>> On Mon, 22 Oct 2001, Sam Tregar wrote: > >>> > Fresh checkout won't compile on Redhat Linux 7.1: > >>> > >>> Damn. It compiled cleanly before I checked it in. I'll patch up again and > >>> see what I missed. Probably some odd dependency or timing issue > >>> somewhere. (It's emacs fault! Yeah, that's the ticket! :) > >> > >> I'd already patched it up, so I've just committed my fix... > > > > Thanks. I swear, if I keep this up I'm going to have to yank my own > > checkin privs... :) > > > > Dan > > >This is why we have tinderbox... What, to automagically yank my checkin privs? Keen! :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Languages in the core source tree?
At 07:15 AM 10/22/2001 -0700, Wizard wrote: > > 1) Do we put them all in the parrot CVS tree > >I think it would be good for the languages to be in tree, but I would like >to have it under a different mechanism for cvs checkout. In other words, the >default cvs checkout of parrot does NOT check out the languages tree, but a >separate checkout is required for the languages. I'll ask Ask and see what we can do for that. > > 2) Do we require them to meet the same levels of quality as the core > > interpreter? >At some point they should need to meet same criteria as the parrot. Right >now, I think the priority is parrot and should remain such. I think the >language implementations are just an experiment, and should not be held to >the same criteria (that should be stated somewhere). However, at some >predetermined point, some resources should be redirected to testing and >refining all of the subtrees (including docs). Yeah, I think you're right here. It'll be one thing when we have fully-working ports of other languages to Parrot but for now most of these should be considered interesting tangents. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Memory management!
Okay folks, a quick heads up. *Any* function in the parrot core that allocates a parrot-managed structure (such as a string or PMC) *must* have a valid interpreter structure hanging around. I'm in the middle of rejigging everything so we can start allocating PMCs & string structures, and properly GC things. It's just *loads* of fun. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Register Window Base Macros
At 06:37 PM 10/19/2001 -0400, Jason Gloudon wrote: >Here is the patch (again) to use the appropriate bitmask determined by >Configure for the different register chunks. Applied. Thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Languages in the core source tree?
On Sun, Oct 21, 2001 at 12:45:14PM -0400, Dan Sugalski wrote: > Okay, we've now got minimal: > > *) Parrot assembly > *) Perl > *) Python > *) JVM > *) Scheme > *) Jako > *) Ruby? (Do we? I can't remember for sure) > > support for Parrot. This is a cool thing, but it brings up the questions: > > 1) Do we put them all in the parrot CVS tree Yes, most definitely yes. > 2) Do we require them to meet the same levels of quality as the core > interpreter? Sort of. Those little languages represent the closest thing to a practical application we have for Parrot at the moment. More importantly, you don't have to be an assembly programmer to use them. As each new feature of Parrot is added, the little languages quickly make use of them. If they're widely distributed (ie. with Parrot) people can quickly make use of the little languages, seeing just how much they can get away with in such a small space. So Parrot and the interpreters will grow in parallel. This means more people beating on Parrot sooner and with more and more varied sticks. However, the author(s) of each individual interpreter should be responsible for their own language. Basically, a mini-pumpinking. This means they *do* have to stand up to the same standards as Parrot because, essentially, they're acting as very practical test cases. If the mini-Scheme interpreter works on Linux but not on VMS, then it's likely exposed a bug inside Parrot. Whether or not a release should be held up because a given language is broken is up to Simon. So yes, put them in the default Parrot tree. Later on when they've matured they can branch off into seperate projects and go their own way. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
Resync your CVS...
I just finished the skeleton of the PMC/string (and soon bigint/bigfloat) allocation system and checked it in. This meant a lot of changes to stuff all over the place. (As a side-effect, we lost the standalone string testing) I think we're now in a position to start dealing with our own memory allocator and PMCs, and I'll start in on that soonish. Please note that until we actually *get* an arena allocation system with GC, parrot will leak. (A lot... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Schedule of things to come
Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03 (and possibly 0.04): *) Scalar PMCs *) Simple I/O *) Multiple interpreter & thread creation *) A simple arena allocation system *) Garbage collection So in the next week or three we should be able to read and write files (gasp!), jam data into and out of real variables, and chew up great gobs of memory while we do it. :) A week or three after that we should stop chewing up the memory, and that'll be A Keen Thing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Resync your CVS...
Fresh checkout won't compile on Redhat Linux 7.1: string.c: In function `string_compare': string.c:161: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:161: too few arguments to function string.c:164: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:164: too few arguments to function make: *** [string.o] Error 1 -sam
Re: Resync your CVS...
On Mon, 22 Oct 2001, Sam Tregar wrote: > Fresh checkout won't compile on Redhat Linux 7.1: Damn. It compiled cleanly before I checked it in. I'll patch up again and see what I missed. Probably some odd dependency or timing issue somewhere. (It's emacs fault! Yeah, that's the ticket! :) Dan
Re: Resync your CVS...
In message <[EMAIL PROTECTED]> Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2001, Sam Tregar wrote: > > > Fresh checkout won't compile on Redhat Linux 7.1: > > Damn. It compiled cleanly before I checked it in. I'll patch up again and > see what I missed. Probably some odd dependency or timing issue > somewhere. (It's emacs fault! Yeah, that's the ticket! :) I'd already patched it up, so I've just committed my fix... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Resync your CVS...
On Tue, 23 Oct 2001, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > On Mon, 22 Oct 2001, Sam Tregar wrote: > > > > > Fresh checkout won't compile on Redhat Linux 7.1: > > > > Damn. It compiled cleanly before I checked it in. I'll patch up again and > > see what I missed. Probably some odd dependency or timing issue > > somewhere. (It's emacs fault! Yeah, that's the ticket! :) > > I'd already patched it up, so I've just committed my fix... Thanks. I swear, if I keep this up I'm going to have to yank my own checkin privs... :) Dan
Re: Ord, v0.3, and ideas on chr
On Tue, Oct 23, 2001 at 03:02:09AM -0400, James Mastros wrote: > + /* FIXME: How should I report this error? If someone's failed to implement ord, that's grounds for a segfault. > 74658072 Not portable. :( > output_is( <<'CODE', <
PackFile_unpack in pdump.c is missing the first arg
I get a the following error when I do a 'make' with a fresh checkout. pdump.c: In function `main': pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 3 of `PackFile_unpack' makes pointer from integ er without a cast pdump.c:63: too few arguments to function `PackFile_unpack' make: *** [pdump.o] Error 1 Host info. [ /home/peterc/parrot/parrot]uname -a Linux goip 2.2.16 #1 Wed Aug 2 20:22:26 GMT 2000 i686 unknown [ /home/peterc/parrot/parrot]gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) It looks like PackFile_pack wants a 'struct Parrot_Interp *interpreter' that it's not getting from pdump.c Just tryin' to help, Peter C.
RE: Revamping the build system
>> Ant is different. Instead of a model where it is extended with shell based
>commands, it is
>> extended using Java classes. Instead of writing shell commands, the
>configuration files
>> are XML based calling out a target tree where various tasks get executed.
>Each task is run
>> by an object which implements a particular Task interface.
Ant is really Java centric, as well as somewhat verbose due to it's
XMLness, if i remember correctly from my brief look at it.
I'm going to propose something (once I have time to write it up
properly[1]) that might look something like this:
[pardon the imaginary filenames]
use PerlBuild;
my @o = Obj( "perl.c",
"string.c",
"george.c",
[ OPTIMIZE => 'MAX',
DEFINE => [qw(USEDEVEL THREADS ITHREADS)]]);
my $so = SharedLib( "libperl", @o, [ SOVERSION => "6.0.0" ]);
InstallFile("/usr/lib/$so", $so );
...
Platform specific defaults would be set somewhere in the build
objects, or in platform classes. The values in the DEFINE example
above would be replaced by something based on some arrgument, the user
wouldn't have to edit the PerlBuildFile, of course.
That's the general idea. Things are built out of objects which talk
to each other, to build a full description of what to make. Once you
have that description, the easy part begins (really), which is getting
the proper order and then executing the commands.[2]
If anyone else is interested in working on the front end, (with this
kind of interface or not) I've got a backend pretty much ready to go.[3]
-R [4]
Footnotes:
[1] Unless this gets shot down now :)
[2] This objecty syntax may seem weird to people used to Make, but a
few weeks of research at $day_job found that it was very hard to
cleanly express cross platform things in a clean Make-like syntax.
Make does lots of things really well, but dealing with platform
specific things in a clean manner isn't one of them.
[3] The current state is that it parses make-like files, does some
simple variable substitutions, and thats it. Not based on any
pre-existing perl make-code. Oh yes, on unix, it supports a simple
parallel building. (i.e. -j)
[4] Abusing footnote-mode, and not totally sold that we can't "make
make" work for us. (Or a subset of it.)
Re: Revamping the build system
On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: > 1) Build minimal perl 6 with default parameters using platform build tool But "platform build tool" is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. -- Britain has football hooligans, Germany has neo-Nazis, and France has farmers. -The Times
Ord, v0.3, and ideas on chr
Hey all.
This is a much nicer implementation of ord, which does it properly as a
string encoding "method".
The only real uglyness I see is the "I have no mouth and I must scream"
problem. I could take a Perl_Interpreter * parameter, but the only reason I
need it is to fire off exceptions.
WARNING: This only implements the encoding method for strnative. This
isn't really so much a problem, since it's impossible to make strings in
other encodings, and I wanted to get this off to see if the style is good
before I figure out utf8 and utf16 versions of this (utf32 should be
trivial). There is a halfharted attempt to make it die cleanly if this
happens, but there's nothing to guarantee that the compiler will put a NULL
there.
Please tell me any problems you see with this.
I don't see what chr() should look like, though. What's the interface to
multiple encodings on the opcode level? I'd like to just say that chr
always creates a utf32 string. String encodings don't have fixed numbers in
a plugable-encoding world (and I assume that's where we're going), so I
can't take an i|ic parameter for that. String encodings are an enum, so I
can't take the name of the encoding as an s|sc parameter. Ideas?
-=- James Mastros
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.17
diff -u -r1.17 core.ops
--- core.ops2001/10/22 23:34:47 1.17
+++ core.ops2001/10/23 06:47:57
@@ -991,6 +991,18 @@
$1 = string_substr(interpreter, $2, $3, $4, &$1);
}
+
+
+=item B(i, s)
+=item B(i, sc)
+
+Set $1 to the codepoint of the first character in $2.
+
+=cut
+
+AUTO_OP ord(i, s|sc) {
+ $1 = string_ord($2);
+}
=back
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
retrieving revision 1.15
diff -u -r1.15 string.c
--- string.c2001/10/22 23:34:47 1.15
+++ string.c2001/10/23 06:47:57
@@ -168,6 +168,24 @@
return (ENC_VTABLE(s1)->compare)(s1, s2);
}
+/*=for api string string_ord
+ * get the codepoint of the first char of the string.
+ * (FIXME: Document in docs/strings.pod)
+ */
+INTVAL
+string_ord(STRING* s) {
+ /* FIXME: How should I report this error?
+* Should I require an interpreter param just so that I can
+* raise an exception properly?
+*/
+ if (ENC_VTABLE(s)->ord != NULL)
+ return (ENC_VTABLE(s)->ord)(s);
+ else {
+ printf("I have no mouth and I must scream: no ord() for encoding %d!\n",
+s->encoding->which);
+ exit(-1);
+ }
+}
+
/*
* Local variables:
* c-indentation-style: bsd
Index: strnative.c
===
RCS file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.19
diff -u -r1.19 strnative.c
--- strnative.c 2001/10/22 23:34:47 1.19
+++ strnative.c 2001/10/23 06:47:57
@@ -105,6 +105,14 @@
return cmp;
}
+/*=for api string_native string_native_ord
+ returns the value of the first byte of the string.
+ */
+INTVAL
+string_native_ord (STRING* s) {
+ return (INTVAL)*(char *)(s->bufstart);
+}
+
/*=for api string_native string_native_vtable
return the vtable for the native string
*/
@@ -118,6 +126,7 @@
string_native_chopn,
string_native_substr,
string_native_compare,
+string_native_ord,
};
return sv;
}
Index: include/parrot/string.h
===
RCS file: /home/perlcvs/parrot/include/parrot/string.h,v
retrieving revision 1.8
diff -u -r1.8 string.h
--- include/parrot/string.h 2001/10/22 23:34:48 1.8
+++ include/parrot/string.h 2001/10/23 06:47:57
@@ -45,6 +45,7 @@
string_iv_to_string_t chopn;/* Remove n characters from the end of a
string */
substr_t substr;/* Substring operation */
two_strings_to_iv_t compare;/* Compare operation */
+string_to_iv_t ord;/* Return the codepoint of the first
+character of the string */
};
struct parrot_string {
@@ -55,7 +56,7 @@
INTVAL strlen;
STRING_VTABLE* encoding;
INTVAL type;
-INTVAL lanugage;
+INTVAL language;
};
@@ -73,6 +74,8 @@
string_substr(struct Parrot_Interp *interpreter, STRING*, INTVAL, INTVAL, STRING**);
INTVAL
string_compare(struct Parrot_Interp *, STRING*, STRING*);
+INTVAL
+string_ord(STRING*);
/* Declarations of other functions */
INTVAL
#! perl -w
use Parrot::Test tests => 1;
output_is( <<'CODE', <
