Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.223
diff -u -r1.223 MANIFEST
--- MANIFEST 23 Sep 2002 00:11:18 - 1.223
+++ MANIFEST 23 Sep 2002 23:19:34 -
@@ -35,6 +35,7 @@
classes/perlundef.
On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> In a message dated 24 Sep 2002, Aaron Sherman writes:
> > This is because push is
> > almost certainly defined as:
> >
> > sub push(@target, *@list) { ... }
>
> That should be
>
> sub push(@target is rw, *@list);
Well, yes, but that wa
[EMAIL PROTECTED] (Aaron Sherman) writes:
> say that array refs behave the same as arrays in every way *except* as
> pertains to list flattening, and in that case, explicit flattening is
> required, otherwise the ref is kept in the flattened array.
Another blow to regularity. :(
--
buf[
[EMAIL PROTECTED] (Aaron Sherman) writes:
> > If we have to resort to much magic to get these right, we're pretty much
> > doomed from the outset.
>
> You have that upside-down. Because this is so fundamental, it's worth a
> great deal of magic to make it "seem right" in as many contexts as
> pos
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17560 >
It's used by stat.h on Darwin, at least.
diff -d -u -r1.13 imc.h
--- imc.h 22 Se
On Mon, 23 Sep 2002, Leopold Toetsch wrote:
> Josef Hook wrote:
>
> >
>
> >>Congrats to you too. So, should I start maintaining a birthday
> >>database for the summaries? Probably not.
> >>
> >
> > 23 on 26th :-)
>
>
> Congrates to you too. Let's store these dates in MultiArray ;-)
>
> T
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
> Sean O'Rourke (via RT) wrote:
>
> > What happens if you presize the PerlArray to its final size
>
> Then it is of course faster, but this is not a real world proposal IMHO,
The real-world version would increase the array's allocation by some fixed
mu
On Tue, Sep 24, 2002 at 11:30:57AM +0100, Simon Cozens wrote:
> At any rate, I do wish we'd stop kidding ourselves that Perl 6 is at all
> going to be "cleaned up" or "regular"; I bet it'll end up with more edge
> cases and special exceptions than Perl 5.
Simon, Perl 6 *will* be more "regular" as
On 24 Sep 2002 05:21:37 -0400, Aaron Sherman wrote:
> On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> > sub push(@target is rw, *@list);
>
> Well, yes, but that wasn't the point. The C<*@list> will force array
> flattening, thus
>
> push @a, [1,2,3], 4;
>
> will (according to Larry's
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17561]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17561 >
Makes things compile, you know.
--- imcc.y 22 Sep 2002 17:38:47 - 1.22
+
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17562]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17562 >
(gdb) run basic.pbc
Starting program: /home/simon/cvs/parrot/parrot basic.pbc
Ready
L
According to Trey Harris:
> According to Larry,
> $a = (1,2,3);
> is equivalent to
> $a = [1,2,3];
> because they're both equivalent to
> $a = scalar(1,2,3)
But that's the bit we're arguing about. If you allow
$a = (1,2)
then what about
$a = (1)
? And if someone says that I have
In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
> According to Trey Harris:
> > According to Larry,
> > $a = (1,2,3);
> > is equivalent to
> > $a = [1,2,3];
> > because they're both equivalent to
> > $a = scalar(1,2,3)
>
> But that's the bit we're arguing about. If you allow
>
On Tue, 2002-09-24 at 10:27, Peter Haworth wrote:
> On 24 Sep 2002 05:21:37 -0400, Aaron Sherman wrote:
> > On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> > > sub push(@target is rw, *@list);
> >
> > Well, yes, but that wasn't the point. The C<*@list> will force array
> > flattening, thus
>
At 11:07 AM -0400 9/24/02, Trey Harris wrote:
>
>*shrug* Regardless of whether we like it, what Larry said is true unless
>and until he invokes Rule 2. And unless he invokes Rule 2,
>C is equivalent to C<[1,2,3]>.
Then perhaps, rather than fretting over the unpleasant consequences
of the curren
I don't know, if this is a possible way to go, nor how portable the
malloc code really is - anyway I did hack together parrot with malloc.c
from http://gee.cs.oswego.edu/dl/html/malloc.html.
s also http://www.cs.utexas.edu/users/oops/papers.html.
The whole resource.c is replaced by calls to cal
Already in #17537
leo
Sean O'Rourke wrote:
> On Tue, 24 Sep 2002, Leopold Toetsch wrote:
>
>>Sean O'Rourke (via RT) wrote:
> The real-world version would increase the array's allocation by some fixed
> multiple, e.g. double its size, which would still improve things from O(n)
> to O(log n) reallocations. I suspect
Simon Cozens (via RT) wrote:
> # New Ticket Created by Simon Cozens
> # Please include the string: [perl #17560]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17560 >
>
>
> It's used by stat.h on Darwin, at least.
A
On Mon, 23 Sep 2002, Leopold Toetsch wrote:
> Attached patch fixes all currently known problems WRT imcc/perl6.
>
> imcc 0.0.9 is rather fresh, so there are problems coming from different
> platforms which I can't test, but I'm sure, we will solve these.
Ok, I applied this and (after shuffling
On Tue, 2002-09-24 at 11:07, Trey Harris wrote:
> In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
> > then what about
> >
> >$a = (1)
> >
> > ? And if someone says that I have to write:
> >
> >$a = (1,)
> >
> > then I am going on the warpath. That Way Lay Python.
I would *
In a message dated 24 Sep 2002, Aaron Sherman writes:
> That doesn't really work. Because now you introduce the case where:
>
> $x = (1,2,3);
> @y = (1,2,3);
> $z = [1,2,3];
> push @a, $x, @y, $z, (1,2,3), [1,2,3];
>
> Behaves in ways that will take hours to explain to newb
On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> Again, we're wading into the waters of over-simplification. Let's try:
>
> sub foo1(){ my @foo=(1,2,3); return @foo; }
> sub foo2(){ my $foo = [1,2,3]; return $foo; }
> sub foo3(*@list) { print @list.length,
In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes:
> On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> > Again, we're wading into the waters of over-simplification. Let's try:
> >
> > sub foo1(){ my @foo=(1,2,3); return @foo; }
> > sub foo2(){ my $foo
On Tue, Sep 24, 2002 at 12:14:10PM -0400, Trey Harris wrote:
> In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes:
>
> > On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> > > Again, we're wading into the waters of over-simplification. Let's try:
> > >
> > > sub
> > In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
>
> > > then what about
> > >
> > >$a = (1)
> > >
> > > ? And if someone says that I have to write:
> > >
> > >$a = (1,)
> > >
> > > then I am going on the warpath. That Way Lay Python.
You _can_ write that, but you don't
Andy Dougherty wrote:
> On Mon, 23 Sep 2002, Leopold Toetsch wrote:
> ./imcc examples/sample.imc
This doesn't even compile on my computer.
Please try:
$ cd ../perl6
$ per6 --test [-r]
HTH
leo
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
> Sean O'Rourke wrote:
> > If we expect these (especially shift) to be as frequent as push/pop, and
> > we want fast indexing as well, then maybe something like the SGI STL
> > implementation of a dequeue (dequeueue?) would be best: keep an array of
> >
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
> Andy Dougherty wrote:
>
> > On Mon, 23 Sep 2002, Leopold Toetsch wrote:
>
> > ./imcc examples/sample.imc
>
> This doesn't even compile on my computer.
I'm away from parrot-source at the moment, but if sample.imc breaks, that
sounds like a bug.
/s
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
> Please try:
>
> $ cd ../perl6
> $ per6 --test [-r]
Ok, but that fails spectacularly due to the same imcc core dump. Here are
the uninformative results:
$ ./perl6 --test
Test details:
t/builtins/array.t2/3
t/builtins/string.t...1/4
Stop
Ups, something went wrong with my last mail, the explaining text was
chopped off. Ok here its again.
Hi,
I just got functions running in scheme.
It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to
reimplement some functions to get it compile, did I get them right?)
P31 alwa
It seems that the fundamental problem is the dichotomy between
a scalar, and a list of 1 elem. Thus, we want
$a = 7
to DWIM, whether I mean a list, or a scalar. Seems to me that
the best way to solve a dichotomy is to declare it to not to
be one: a scalar *IS* a list of one element. The only t
On Tue, Sep 24, 2002 at 11:47:16AM -0700, David Whipp wrote:
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
>
> $a = 7
>
> to DWIM, whether I mean a list, or a scalar. Seems to me that
> the best way to solve a dichotomy is to d
On Tue, 2002-09-24 at 14:47, David Whipp wrote:
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
After the first couple of messages, that was really no longer *my*
concern, but I can't speak for others. My concern was mostly that
par
On Tue, 24 Sep 2002, Sean O'Rourke wrote:
> I'm away from parrot-source at the moment, but if sample.imc breaks, that
> sounds like a bug.
Well yes, but ... Leopold's trying to iron out various possibly-platform-
dependent wrinkles in his recent major imcc upgrades, and I was trying out
a not-y
> The whole resource.c is replaced by calls to calloc/realloc (res.c),
> add_free_buffer does free().
I think that's the problem right there. What exactly are you changing
to use this new calloc/malloc implementation? One approach is to modify
memory.c to use the new versions, although since parr
The problem is much smaller than that, actually.
10 LET T$=CHR(65)+CHR(66)+CHR(67)
20 PRINT T$
30 LET A$=RIGHT(T$, 1)
40 QUIT
The problem vanishes if any of the following happen:
* T$ is constructed with a string assignment (LET T$="ABC")
* The PRINT statement is removed
* The LET A$= stateme
On 24 Sep 2002, Juergen Boemmels wrote:
> I just got functions running in scheme.
>
> It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to
> reimplement some functions to get it compile, did I get them right?)
Hopefully it will be easy to reconcile our different versions (and w
> 2. Scalar assignment.
>
> my $a;# 1.
> $a = X;
>
> my $a;# 3.
> ($a) = X;
>
> These should all do the same thing, regardless of X.
Consider:
$a = (1);
and
($a) = (1);
> 5. Assignment to arrays and lists.
>
> $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
In a message dated Tue, 24 Sep 2002, Mike Lambert writes:
> Consider:
> $a = (1);
> and
> ($a) = (1);
Yes? They both do the same thing--set $a to 1. It looks like the bottom
one is a list assigned to a list, but that might be optimized out, as it
doesn't matter.
> > 5. Assignment to arrays an
Folks,
Larry is mostly out of touch this week, so working ourselves into a
fury over a potential design issue is probably a bit
counterproductive.
Perhaps someone can put together a statement of the problem and post
it, and we can leave the discussion for a bit, both to give larry
time to ge
> From: Jonathan Scott Duff
> > $b = 7, 6, 5
> > @b = 7, 6, 5
> >
> > Again, both create identical objects, under different
> > interfaces. But now we have a problem with +$b: what should
> > this mean? To be consistant with +$a (above), I would
> > suggest that it simply returns the sum of
Mike Lambert wrote:
>>The whole resource.c is replaced by calls to calloc/realloc (res.c),
>>add_free_buffer does free().
>>
>
> I think that's the problem right there. What exactly are you changing
> to use this new calloc/malloc implementation? One approach is to modify
> memory.c to use the n
Sean O'Rourke wrote:
> On Tue, 24 Sep 2002, Leopold Toetsch wrote:
>
>>Sean O'Rourke wrote:
>>Exactly this is, what my recent patch actually did: list->chunk_list
>>holds pointers to chunks, an index lookup is one "div" more expensive
>>then in array.
>>
> It's not in #17549. Is it in an earl
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17569]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17569 >
This is an update/bugfix
- t/src/intlist.t was missing
- find_chunk was partly wrong
On Tue, 24 Sep 2002, Mike Lambert wrote:
> >
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
>
> $a = (1) should then do $a = [1], according to the above.
>
> This implies that:
>
> ($a) = (1) implies that $a is [1], something I don't particularly agree
> with.
You may be missing the chang
=head1 TITLE
Square brackets are the only list constructor
=head1 VERSION
Maintainer: Luke Palmer <[EMAIL PROTECTED]>
Date: 24 Sep 2002
Number: 362 (?)
Version: 1
=head1 ABSTRACT
This RFC responds to the fury on perl6-language about the redundancy of
parentheses and brackets with res
# New Ticket Created by Steve Fink
# Please include the string: [perl #17573]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17573 >
- In imcc.y:main(), the stacktop was being set to an uninitialized
value, making stackw
On Mon, Sep 23, 2002 at 07:41:09PM +, Leopold Toetsch wrote:
> # New Ticket Created by Leopold Toetsch
> # Please include the string: [perl #17537]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17537 >
>
>
> Attac
Sorry about the late reply to this. I wrote up the first 2/3
immediately after seeing Josef's message, but got sidetracked by Real
Life. Then when I came back to it, I noticed that it had already
exceeded the length threshold that usually means I'm rambling
incoherently. And I probably am, so you
Steve Fink (via RT) wrote:
> - In imcc.y:main(), the stacktop was being set to an uninitialized
> value, making stackwalking sometimes *really* slow, sometimes crash,
> and sometimes work perfectly fine.
Yes, already fixed
> - My bison does not accept actions that do not end in a semicol
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17578]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17578 >
This patch obsoletes all previous imcc 0.0.9 patches and contains all
current fixes
52 matches
Mail list logo
