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 an
> 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 r
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
t
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 c
> > 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
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 some
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
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
th
[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 a
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 mu
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
> > 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 see
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 t
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 shoul
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 th
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 u
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 defau
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.
> >
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 i
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,00
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
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
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) {
>
> 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 a
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
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
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
> > 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.
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 g
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 reali
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
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 wr
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 ou
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 prope
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"--
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
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
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 file
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
incompa
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! :)
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
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 pa
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', <
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: p
>> 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
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
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.
47 matches
Mail list logo
