Bill Coffman <[EMAIL PROTECTED]> wrote:
> Leo,
> Thanks for your suggestions and comments.
Welcome and thanks to you for looking at that nasty piece of code ;)
> On Wed, 20 Oct 2004 10:35:04 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> Some remargs WRT gen{3,4}.pl:
>> 1) While these prog
Leo,
Thanks for your suggestions and comments.
On Wed, 20 Oct 2004 10:35:04 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Some remargs WRT gen{3,4}.pl:
> 1) While these programs exhibit some worst case register layout it's
>probably not a very typical layout.
Agreed. The idea was to a
At 3:55 PM -0400 10/20/04, Jeff Horwitz wrote:
On Wed, 20 Oct 2004, Dan Sugalski wrote:
Well, actually scary though it may be, my Work Project uses
parrot objects for everything. Whether this is a useful thing or
not's an open question (the language lacks subroutines, for example)
but...
in
On Wed, 20 Oct 2004, Dan Sugalski wrote:
> Well, actually scary though it may be, my Work Project uses
> parrot objects for everything. Whether this is a useful thing or
> not's an open question (the language lacks subroutines, for example)
> but...
in general, anything that can generate bytec
I understand Dan's view that parrot should be 100% self contained, but I
really think its silly to inline CPAN modules into our CVS repository.
I have a compromise solution, which might satisfy Dan.
1. I create a new parrot-external-dependencies CVS repository. All
external dependencies that Dan w
At 3:38 PM -0400 10/20/04, Jeff Horwitz wrote:
> You will, I trust, keep us up to date on all the places where we're
making life difficult? :)
for sure. but it's actually been quite a smooth ride so far. i have a
short list of problems i've had to deal with, and i'll forward them to the
list wh
> You will, I trust, keep us up to date on all the places where we're
> making life difficult? :)
for sure. but it's actually been quite a smooth ride so far. i have a
short list of problems i've had to deal with, and i'll forward them to the
list when i get the chance.
what i'd really like to
Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> mod_parrot now supports authentication handlers.
awesome
> -jeff
leo
At 2:27 PM -0400 10/20/04, Jeff Horwitz wrote:
mod_parrot now supports authentication handlers. i'm planning a release
in the next few days, including a whitepaper on its architecture, but
here's an example of what you can now do.
Wow. That's... cool. And a bit scary. But definitely cool. I could
At 9:09 PM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing
the registers from out of the interpreter structure, which'd leave
us needing two pointers, one for the interpreter struct and one for
the registers.
Ok, short s
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok, short summary of future layout of JIT regs:
item
mod_parrot now supports authentication handlers. i'm planning a release
in the next few days, including a whitepaper on its architecture, but
here's an example of what you can now do. the following handler accepts
any basic authentication with a password of 'squawk' (correpsonding
httpd.conf foll
At 6:13 PM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Right. Any time an actual continuation is created we need to walk
back up the call chain and mark all the pending return
continuations as non-recyclable.
Ok.
If we're not savin
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> reserve %ebp for register frame pointer
s/%ebp/%ebx/
Sorry,
leo
Dan Sugalski wrote:
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Right. Any time an actual continuation is created we need to walk back
up the call chain and mark all the pending return continuations as
non-recyclable.
Ok.
If we're not saving much on the register stacks (and with the switch
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The first is the CPS style chews through continuation objects at a
massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk already.
Yeah, I k
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matthew Walton) writes:
>Austin Hastings wrote:
>> Does this mean that we're done? :)
>
>No, it means Larry's about to stun us with something seemingly bizarre
>and inexplicable which turns out to be a stroke of genius.
This conjured up an ima
Bill Coffman <[EMAIL PROTECTED]> wrote:
> I am currently working on a fix to the large subroutine register
> allocation bug, aka, "massive spilling not yet implemented". The
> problem, is that the register allocation code is complex, and I'm not
> all that familiar with it, or even with working w
Brian Wheeler <[EMAIL PROTECTED]> wrote:
> Sigh. I'll get this right sometime!
Thanks, applied.
leo
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Visual C++ compiles "-0.0" to 0.0, which leads to the error. Attached
> patch will fix this.
Thanks, applied.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The first is the CPS style chews through continuation objects at a
> massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk already.
> A return continuation is a *potential* continuation.
21 matches
Mail list logo
