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 l
? 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
+++ basicvar
[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
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 Phane
Tom Hughes wrote:
> Index: basicvar.pasm
> ===
...
> Index: instructions.pasm
> ===
...
Fixes the bug, and wumpus plays yet again.
Applied, thanks.
Mike Lambert
Just to complete this thread, I have committed the current version of my
COW code, as I promised earlier this week. Below is my response to Peter's
most recent email.
> > Note that the comparison against parrot-grey is not
> > exactly fair, because it dodn't use system stackwalking.
>
> Note that
Mike Lambert wrote:
> Anyways, cd to languages/BASIC, run basic.pl, type "LOAD wumpus", and
> watch it die on "Not a string!".
Tracing this beast down, needs attached patch, to cut displayed arg strings.
BTW trace.c nether frees this escaped string.
The last instruction executed is:
PC=1457;
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% imp
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. :-)
Mike
>>> Ask Bjoern Hansen <[EMAIL PROTECTED]> 08/21/
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #16689]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16689 >
Freshly checked out parrot moans a lot:
cc: Info: ./include/parrot/string.h, line
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 ot
# New Ticket Created by Daniel Grunblatt
# Please include the string: [perl #16690]
# in the subject line of all future correspondence about this issue.
# 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 that
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
> I still prefer infix notation to prefix notation for an intermediate
> language. 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.
Hi,
I think we all agree that since parrot can have dynamic oplibs
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
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=16689 >
>
>
>Freshly checked out parrot mo
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 throug
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
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 ca
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
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 Pa
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.ba
Piers Cawley wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
>>Multiple inheritance will be:
>>
>> class Derived is Base1 is Base2
>>
>>or possibly:
>>
>> class Derived is Base1 Base2
>
>
> How about class Derived is all(Base1, Base2);
Close, but no cigar. You meant:
cl
>
> 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 interes
At 8:05 PM +0200 8/21/02, Angel Faus wrote:
> >
>> 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
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.
By being less overtly perl-centric, and thus more HLL-neutral, we could
have gotten more direc
> 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
>> 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.
>
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 str
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,
bu
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
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 }
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 no
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
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 IMCC
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.ba
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 Pa
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 becau
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?"
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
On Wed, 21 Aug 2002, Melvin Smith wrote:
> 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 proje
On Wed, 21 Aug 2002, Leopold Toetsch wrote:
> Melvin Smith wrote:
> > I still prefer infix notation to prefix notation for an intermediate
> > language.
>
> The current infix notation is fine. It makes intermediate code, and
> perl6 IMCC code generation more readable.
>
> Sean (IMHO) is not trying
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 mig
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
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 t
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 itsel
> 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
>
>
The mass of ICU code that's been added to Parrot. It's taking an
amazingly long time to import, and I'm apologizing profusely in advance
for this massive import. However, one of our goals -is- to do Unicode
out of the gate, and the easiest way to do this is adapt the ICU library
for our own nefari
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 by
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
> 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% improvement in performance is not too bad, I suppose.
> Well done Mike!
Thanks!
> CVS/COW with stack pointer alignment = four: 93 sec
[EMAIL PROTECTED] (Jeff) writes:
> The subject pretty much says it all. The format pretty much corresponds
> to the upcoming Exegesis. Major changes were to the modifiers, and a few
> syntax changes in the depths.
I've started rewriting my Shishi P6 RE module since it was becoming
way too clutter
65 matches
Mail list logo
