Autrijus Tang wrote:
After a IRC meeting with Leo, I've outlined my roadmap of how to make the three
compiler backends in Pugs to work in concert to provide a much faster evaluator:
http://use.perl.org/~autrijus/journal/23890
Note that existing code in the Eval monad need not be rewritten; also
Leopold Toetsch wrote:
Original Message
Subject: a warning and a failure for parrot in Tru64
Date: Thu, 31 Mar 2005 20:41:30 +0300
From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
To: Leopold Toetsch <[EMAIL PROTECTED]>
cc: Warning: pylist.pmc, line 601: In this statement, the referen
Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot
is compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hoped that it
would work, but to stop t
# New Ticket Created by Nick Glencross
# Please include the string: [perl #34637]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34637 >
A small patch to:
* Give Jens credit for yesterday's enhancements (I think that I'
Hi all,
I am still working on PAPAgei - the PAscal for PArrot
compiler which is my final year project at I.T.
Carlow.
My (tentative) approach is to use PRD for parsing and
taking Dan's article on building a compiler for parrot
as a guide, I wanted to build an ISO pascal compiler
starting with a v
At 06:33 AM 4/1/2005, Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot is
compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hoped that it woul
On Thu, Mar 31, 2005 at 12:41:43PM -0500, Matthew Zimmerman wrote:
> One possibility is attached.
Thanks, applied.
Nicholas Clark
On Thu, 31 Mar 2005, Leopold Toetsch wrote:
We gonna switch to SVN soon.
3) If no one utters a killer argument against, we'll switch to SVN
I tried svn again. I'm happy to report it worked much better than it did
the last time I tried it. For one thing, it actually compiled for me.
It's still
On Thu, Mar 31, 2005 at 06:13:57PM +0200, Leopold Toetsch wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch writes:
> >> But with one more indirection a PIC-like scheme can work with
> >> read-only bytecode too (probably). E.g. the assembler emits instead
> >> of the proposed:
> >
MrJoltCola wrote:
At 06:33 AM 4/1/2005, Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot
is compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was
Just a quick question:
Is there currently any method of determining the depth of the lexical
scope pad stack? None of the ops in var.pod seem to be able to provide
that information at the moment...
Cory
Is there currently any method of determining the depth of the lexical scope
pad stack? None of the ops in var.pod seem to be able to provide that
information at the moment...
Actually, I suppose I should clarify what I want to get at here, which is
when lexical pads popped off the stack. Am I
Attached is my make test output from my laptop running Fedora Core 3
x86_64bit: makeTest.txt
Is there any other way I can help?
Jay Scherrer
On Fri, 2005-04-01 at 11:24 -0500, MrJoltCola wrote:
> At 06:33 AM 4/1/2005, Nick Glencross wrote:
>
> >Having never had access to a Tru64 system, does tha
13 matches
Mail list logo