I have a clean version that's up to date, and as everybody seems to
be happy with it I'm going to go ahead and commit it now.
Ah-ha! I found a showstopper! Oh, it's a little late for that, isn't it?
:)
Anyways, cd to languages/BASIC, run basic.pl, type LOAD wumpus, and
watch it die on Not a
At 6:16 PM -0400 8/20/02, John Porter wrote:
Dan Sugalski wrote:
I expect a UINTVAL should be sufficient to hold the counter.
Why? Because you don't expect a perl process to run longer
than a couple hours? Or because rollover won't matter?
Rollover won't really matter much, if we're
In message [EMAIL PROTECTED]
Mike Lambert [EMAIL PROTECTED] wrote:
Anyways, cd to languages/BASIC, run basic.pl, type LOAD wumpus, and
watch it die on Not a string!. It could be that basic is using keys in
weird ways, or it could be that the key patch is borked...I haven't looked
? basic.pbc
? merged_basic.pasm
Index: basicvar.pasm
===
RCS file: /cvs/public/parrot/languages/BASIC/basicvar.pasm,v
retrieving revision 1.10
diff -u -r1.10 basicvar.pasm
--- basicvar.pasm 20 Jun 2002 00:05:09 - 1.10
+++
[EMAIL PROTECTED] (Dan Sugalski) writes:
Rollover won't really matter much, if we're careful with how we
document things. Still, a UINTVAL should be at least 2^32--do you
really think we'll have that many GC generations in a few hours?
... but having stuff running for months and months isn't
Raph Levien - http://www.advogato.org/person/raph and
http://www.levien.com/ - talks about bytecode interpreters at
http://www.advogato.org/person/raph/diary.html?start=261
With references to David McCusker
http://treedragon.com/ged/map/ti/newAug02.htm#14aug02-stack-machines
and to Pierre
Mike Lambert wrote:
Just to complete this thread, I have committed the current version of my
COW code, as I promised earlier this week.
Some final 5000 life results from my system, and a few improvements
I believe are still possible:
Before COW: 172 seconds
After COW: 121 seconds
A 30%
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #16689]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16689
Freshly checked out parrot moans a lot:
cc: Info: ./include/parrot/string.h,
At 09:49 PM 8/20/2002 -0700, Sean O'Rourke wrote:
This is what you'll need. It uses dlopen(), and is likely Bad in a number
of other ways, but if you're on a fairly normal UNIX, it should allow imcc
to grok what P6C produces for regexes.
Sean, I'm replying publicly because I'd like to hear
# New Ticket Created by Daniel Grunblatt
# Please include the string: [perl #16690]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16690
This patch disables running the tests in t/src under a make testj.
Apart from
I've sent this message before, but Piers was kind
enough to point out that the CGI script I'm forced to
use to send mail does not readably format my messages,
increasing the likelyhood that they are ignored. So
here's a repost that's (hopefully) better to read.
I'm wondering about how the sigil-invariance rule interacts with
attributes.
class Foo {
attr $bar;
attr bar;
method baz {
return .bar[$.bar]; # sigils disambiguate
}
method frob ($self:) {
return $self.bar[$self.bar]; # uh-oh
}
}
Is this
Replying to myself because I forgot to include these files...
/s
anyop.tgz
Description: Binary data
On Wed, 21 Aug 2002, Angel Faus wrote:
About the implementation, I think we will need the following metadata about
each op:
i) the opcode, and the op name.
ii) the type of arguments, including in/out/etc..
Both of these are available, though there currently isn't an efficient
interface to
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #16689]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16689
Freshly checked out parrot moans
Yay! The COW has landed! All praise the newly bovine Parrot! (Now
THAT's an odd image... gimp, anyone?)
Favorite quote from the patch:
+ /* Buffer's memory data is in this header's header pool's memory pool */
Many thanks to Peter and Mike for implementing this and pushing it all
the way
On Wed, 21 Aug 2002 18:02:51 +0200 Angel Faus [EMAIL PROTECTED] wrote:
I think we all agree that since parrot can have dynamic oplibs (and core
parrot has hundreds of ops), imcc needs some way to directly express them.
The idea of having parrot ops be included as such, and imcc directives be
On Wed, Aug 21, 2002 at 02:10:22PM +0200, Peter Gibbs wrote:
Mike Lambert wrote:
If you don't mind, please feel free to continue your work on parrot-grey.
The problem arises with trying to do new experimental development,
which still keeping sufficiently in sync with cvs parrot that I can do
At 9:03 AM -0400 8/21/02, Mike Litherland wrote:
I'd have to concur. I'm working on an integration engine entirely
in Perl and expect many processes to stay up for months under heavy
IO loads. I hope^H^H^H^Hhave confidence that p6 will be a major
boon to my efforts, not a hindrance. :-)
At 2:58 AM -0400 8/21/02, Mike Lambert wrote:
At 6:16 PM -0400 8/20/02, John Porter wrote:
Dan Sugalski wrote:
I expect a UINTVAL should be sufficient to hold the counter.
Why? Because you don't expect a perl process to run longer
than a couple hours? Or because rollover won't
On Wed, Aug 21, 2002 at 10:05:57AM -0400, Melvin Smith wrote:
Sean, I'm replying publicly because I'd like to hear other opinions than
mine, yours, Angel's and Leopold's.
Can I respectfully request that you guys make a lot more of your
discussions public? languages/imcc and languages/perl6
Can I respectfully request that you guys make a lot more of your
discussions public? languages/imcc and languages/perl6 are very major
components, and they have been very little discussed on-list. imcc
Sure, I have no problem with it. At one
time someone suggested making a separate
list for
Trey wrote:
I'm wondering about how the sigil-invariance rule interacts with
attributes.
class Foo {
attr $bar;
attr bar;
method baz {
return .bar[$.bar]; # sigils disambiguate
}
method frob ($self:) {
return $self.bar[$self.bar]; #
Sure, I have no problem with it. At one
time someone suggested making a separate
list for Parrot compilers, so I took it as
a hint that maybe we were spamming.
I am all for the creation of a new list for stuff such as imcc, and perl6
compilers. ([EMAIL PROTECTED]?)
So people interested
You _would_ think so, wouldn't you? :)
Personally I've been a little disappointed
in the involvement(interest) of late.
-Melvin
I wonder how many interested observers of this list there are like myself. I
only wish I had the time experience/skill/knowledge to contribute.
Keep up the good
You _would_ think so, wouldn't you? :)
Personally I've been a little disappointed
in the involvement(interest) of late.
-Melvin
I wonder how many interested observers of this list there are like
myself. I only wish I had the time experience/skill/knowledge to
contribute.
Keep up the
Reading through the latest version of string.c, pondering the
best way to integrate the grey and (what colour is cvs parrot?)
versions, I came across the following line in unmake_COW:
s-buflen = s-strlen;
which got be a little confused - I seem to recall buflen as being
in bytes, and
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
ie the classic
{ my $fh = IO::File-new(...); }
I know there's been lots of discussion on this over the months,
At 2:35 PM -0400 8/21/02, John Porter wrote:
Angel Faus wrote:
I am all for the creation of a new list for stuff such as imcc, and perl6
compilers. ([EMAIL PROTECTED]?)
I wonder if maybe perl6-internals should have been named parrot, anyway.
That would've required a bit of time-travel, as
On Wed, Aug 21, 2002 at 08:25:10PM +0100, I wrote:
In this Brave New World of DOD and GCC, what guarantees (if any)
s/GCC/GC/
What with PMC, PDD, COW etc, I have TLA on the brain.
:-)
--
Nothing ventured, nothing lost.
c) imcc becomes a middle level language.
I never meant it to be an assembler. In practice
intermediate languages provide other constructs
such as aggregate type definition that are not
available in the assembler.
type i : packed int[32]
type r : record { foo : int, bar : string }
This
Melvin Smith wrote:
Sean, I'm replying publicly because I'd like to hear other opinions than
mine, yours, Angel's and Leopold's.
I'll answer here to Melvin's mail, but I'll try to make a summary of all
point's taken in this thread + some more.
I still prefer infix notation to prefix
Leopold Toetsch wrote:
I don't understand why it is so hard to adopt. imcc is supposed to be
a step closer to higher level languages, which is why I went that way.
No problem here, it is called _intermediate_ ..., which is a worthful
step in code generation, but - as always - there is a
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
features, therefore
Trey wrote:
I'm wondering about how the sigil-invariance rule interacts with
attributes.
class Foo {
attr $bar;
attr bar;
method baz {
return .bar[$.bar]; # sigils disambiguate
}
method frob ($self:) {
return $self.bar[$self.bar]; #
Brent Dax wrote:
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
On Wed, Aug 21, 2002 at 04:17:30AM -0400, Mike Lambert wrote:
Just to complete this thread, I have committed the current version of my
COW code, as I promised earlier this week.
Did you try running tests with GC_DEBUG on? I get numerous failures.
Here's a patch with a couple of fixes (not all
At 05:44 PM 8/21/2002 -0400, John Porter wrote:
The outstanding question is, Is imcc a part of the parrot system?
When compiler writers target parrot, do we really want them to target imcc?
I have a feeling some of you would answer yes to that question all too
My answer is yes, not because I
At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
No; but statements like imcc MUST provide access to ALL of parrot's
(still very dynamic) feature set and discussions of imcc syntax
naturally lead to questions of imcc's role in the parrot project.
E.g. will the perl6 compiler target imcc?
Good
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote:
So please, first, let's consider the status quo, not the future.
Agree.
_SV_s1 = clone $P1
I've considered changing '=' to mean clone, and add ':=' to imply set.
What do you think?
-Melvin
On Wed, 21 Aug 2002, Melvin Smith wrote:
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote:
_SV_s1 = clone $P1
I've considered changing '=' to mean clone, and add ':=' to imply set.
What do you think?
Heh. What's the universal sign for assign (as opposed to clone or
set)? Since
On Wed, 21 Aug 2002 [EMAIL PROTECTED] wrote:
Can I respectfully request that you guys make a lot more of your
discussions public?
I'd like to dispel rumors of a vast off-list conspiracy. I've been taking
and discussing patches to languages/perl6 from a couple of people (hi,
Leo) off-list,
Sean O'Rourke wrote:
However, if we already have a working register
allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an Tcl-to-parrot compiler
(for (hypothetical) example), I
Melvin Smith wrote:
Good question. The problem is, there is no one but us to answer
that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that Larry,
or at least Damian, might have something very
On Wed, 21 Aug 2002, 'John Porter' wrote:
Sean O'Rourke wrote:
However, if we already have a working register
allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
I usually tend to do so, but I'm not sure
At 10:59 PM 8/21/2002 -0400, 'John Porter' wrote:
Sean O'Rourke wrote:
However, if we already have a working register
allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an
At 11:02 PM -0400 8/21/02, 'John Porter' wrote:
Melvin Smith wrote:
Good question. The problem is, there is no one but us to answer
that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that
On Thursday 22 August 2002 01:24, Melvin Smith wrote:
for HLL compilers targeting parrot. If y'all want to consider imcc
as just another member of that class, fine! But if we tell compiler
writers You should target imcc, not parrot directly, then imcc
is clearly in a class by itself.
Lets
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
From the straight GC perspective, none. There might be workarounds at
higher-levels, however.
ie the classic
{ my
At 1:20 AM -0400 8/22/02, Jeff wrote:
Contrary to rumor I didn't do this to push my 'bytes added' count past
Simon or Dan :)
One important safety tip for the bandwidth-impaired. Add the -z3 flag
to your cvs updates, like so:
cvs -z3 update
That'll use gzip compression on the data stream,
Reading through the latest version of string.c, pondering the
best way to integrate the grey and (what colour is cvs parrot?)
versions, I came across the following line in unmake_COW:
s-buflen = s-strlen;
which got be a little confused - I seem to recall buflen as being
in bytes,
On Jeudi 22 Août 2002 04:59, 'John Porter' wrote :
And no one
has suggested that HLL compiler writers shoudl emit befunge.
Yet. :-)
Since we're talking about this, I have a suggestion... :o)
Jerome
--
[EMAIL PROTECTED]
Jeff wins the Who took all the inodes? prize for 2002.
-Melvin
At 1:55 AM -0400 8/22/02, Melvin Smith wrote:
Jeff wins the Who took all the inodes? prize for 2002.
And he's not even committed the data yet...
--
Dan
--it's like this---
Dan Sugalski
54 matches
Mail list logo
