Piers Cawley <[EMAIL PROTECTED]> wrote:
> Don't trace system areas in sweep ops
> through holes in the C stack (hmm... if anyone has a good drawing of
> this?)).
I don't know if its a good one, but my original posting about that
problem had some ASCII graphics (in this thread):
Subj
On Tue, 5 Aug 2003, Piers Cawley wrote:
> Approaching Python
> Discussions (and coding) of the Parrot implementation of Python
> continued this week. Michal Wallace is working on taking a preexisting
> (but incomplete, it's a proof of concept only) python parse tree ->
Wow, after re
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Okay, okay, PONIE really stands for 'Perl On New Internal Engine'.
That's that what they say. Actually it was: "PONIEPONIE":
"Perl5 Obsoletes Nasty Internals Entirely:
Parrot Occupies Numerous Interpreters Everywhere"
But that was to bulky. Or too many
Piers Cawley writes:
> is static?
> Discussion of static/state variables continued. Arcadi Shehter wondered
> if it made sense to attach "but" properties to closures. I confess I
> didn't really understand what he was driving at. Austin Hastings and
Actually, I was confused , thi
On Monday, March 31, 2003, at 10:15 AM, Jonathan Scott Duff wrote:
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
"present but undefined" and "not pr
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
> I'm still hoping rather desperately for a if-uninitialized op in
> general, even if only for hashes, because the difference between
> "present but undefined" and "not present" is rather crucial for some
> common algorithms.
Ca
On Monday, March 31, 2003, at 07:39 AM, Piers Cawley wrote:
Argument initializations
Michael Lazzaro summarized the various different and proposed
assignment
operators available in Perl 6, including a proposed "::=" for 'only
assign to uninitialized variables'. Michael wondered how
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>
> PC> To do that you need to declare the parameter with "is
> PC> copy". Uri noted that he really should keep his finger off
> the
> PC> send button until he's read the whole 'm
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
PC> To do that you need to declare the parameter with "is
PC> copy". Uri noted that he really should keep his finger off the
PC> send button until he's read the whole 'megilla', whatever one
PC> of those is.
it is appr
TLA = Three Letter Acronymn
- Original Message -
From: "Paul" <[EMAIL PROTECTED]>
To: "Leopold Toetsch" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, March 1
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Piers Cawley wrote:
> > Coroutines end and DFG
> > Nobody explained what DFG stands for.
>
> It's a commonly used TLA standing for Data Flow Graph, which
> accompanies the CFG (Control Flow Graph). Both are necessary
> for register allocation
Piers Cawley wrote:
Coroutines end and DFG
Nobody explained what DFG stands for.
It's a commonly used TLA standing for Data Flow Graph, which accompanies
the CFG (Control Flow Graph). Both are necessary for register allocation.
leo
Dan Sugalski wrote:
At 8:54 AM +0100 2/28/03, Leopold Toetsch wrote:
I see that limitation. But currently we have a high overhead JIT. The
problem is not so much program run time, but load time.
Damn. Okay, what sort of metadata would be appropriate to aid in this?
If it means having the assem
At 8:54 AM +0100 2/28/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... And with that limitation, I'd rather have a lower-overhead JIT
with a win for the shorter programs than a high-overhead one with a
win for long-running programs.
I see that limitation. But currently we have a high overhead
Dan Sugalski wrote:
... And with that
limitation, I'd rather have a lower-overhead JIT with a win for the
shorter programs than a high-overhead one with a win for long-running
programs.
I see that limitation. But currently we have a high overhead JIT. The
problem is not so much program run ti
At 12:41 PM -0500 2/26/03, Jason Gloudon wrote:
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote:
Dan -- you might be interested in
http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX
Research wants to be free:
http://www-hydra.stanford.edu/publications/JVM02.pd
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote:
> Dan -- you might be interested in
> http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX
Research wants to be free:
http://www-hydra.stanford.edu/publications/JVM02.pdf
--
Jason
First off, thanks to our relentless..., er, tireless summarizer for
continuing to digest and clarify our wandering discussion.
On Tue, 25 Feb 2003, Piers Cawley wrote:
> Using IMCC as JIT optimizer
> Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is
> still faster
[EMAIL PROTECTED] wrote:
...but Leo seem to think that...
I agree with the policy of referring to Leo in the plural.
Regards,
-- Gregor
We thank you
leo, me, myself & I,
Leopold
> ...but Leo seem to think that...
I agree with the policy of referring to Leo in the plural.
Regards,
-- Gregor
At 11:40 PM +0100 2/14/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW.
Nice ;-)
And not even my choice, but who am I to argue, right? :)
--
Dan
--"it's like this"---
Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW.
Nice ;-)
leo
At 9:02 PM + 2/14/03, Nicholas Clark wrote:
On Fri, Feb 14, 2003 at 03:45:20PM -0500, Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW. I have this nagging
feeling we'll be able to muster something that'll run on it... :)
Are we free to use whichever runops core we fe
On Fri, Feb 14, 2003 at 03:45:20PM -0500, Dan Sugalski wrote:
> The challenge system is x86 Linux with GCC, FWIW. I have this nagging
> feeling we'll be able to muster something that'll run on it... :)
Are we free to use whichever runops core we feel like?
Nicholas Clark
At 4:17 PM +0100 2/11/03, Leopold Toetsch wrote:
[EMAIL PROTECTED] wrote:
The 2004 Performance challenge
Dan announced that he'd made a bet with Guido van Rossum that Parrot
would be faster at executing a pure python benchmark
You missed the pie as part of the penalty, though tha
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>> The 2004 Performance challenge
>> Dan announced that he'd made a bet with Guido van Rossum that Parrot
>> would be faster at executing a pure python benchmark
>
>
> [ ... ]
>
>
>> For some reason nobody comme
[EMAIL PROTECTED] wrote:
The 2004 Performance challenge
Dan announced that he'd made a bet with Guido van Rossum that Parrot
would be faster at executing a pure python benchmark
[ ... ]
For some reason nobody commented on this.
The CGP runloop was the comment ;-)
Thanks f
On Tue, 2003-01-28 at 06:34, Piers Cawley wrote:
> Compiling to Parrot
> K Stol is looking for a final project for his Bachelor's degree and
> would like to implement some language targeting Parrot and asked for
> suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested
On Tuesday, December 24, 2002, at 02:55 AM, Piers Cawley wrote:
Apparently part of the problem is that the undef function isn't
fully defined.
Well, isn't that sort-of the point?
:-)
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]
Deborah Ariel Pickett wrote:
> Assuming that semicolon is no longer going to be a supercomma in these
> situations, does that mean that we C addicts can have C back to do
> the kinds of loops that we mean when we say "for loops"?
I hope not.
> I really don't much like the C keyword.
>
> for (
> Supercomma!
> [snip]
> Larry then confessed that he was thinking of changing the declaration of
> parallel for loops from:
> for @a ; @b ; @c - $a ; $b ; $c {...}
> to something like:
> for parallel(@a, @b, @c) - $a, $b, $c {...}
Assuming that semicolon is no longer goi
Piers Cawley writes:
>
> FMTWYENTK about ":="
> Bravely declining to expand the acronym in his subject, arcardi posted a
> summary of his current understanding of the behavior of ":=", the
its "far more then what you ever need to know"
and after Damian Conway answer it becomes JEOWY
32 matches
Mail list logo
