Re: Threaded Perl bytecode (was: Re: stackless python)

On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote: > I don't see it. > > I would find it extremely akward to allow > > thread 1: *foo = \&one_foo; > thread 2: *foo = \&other_foo; > [...] > > copy the &foo body to a new location. > replace the old

Re: [not quite an RFC] shared bytecode/optree

On Tue, Oct 24, 2000 at 04:41:38PM -0700, Benjamin Stuhl wrote: > It seems to me that one thing that the perl6 bytecode > implementation _should_ do (in the interests of being light > and fast, as well as meshing well with MT) is be > position-independant. Fancy offering a patch to RFC310? -- I

[not quite an RFC] shared bytecode/optree

Firstly, by "bytecode" I mean a .pmc and by "optree" I mean the perl6 VM's internal form that it goes through executing. It seems to me that one thing that the perl6 bytecode implementation _should_ do (in the interests of being light and fast, as well as meshing well with MT) is be position-inde

Re: Perl6 the platform-dependent bits...

At 09:08 PM 10/24/00 +0100, Simon Cozens wrote: >On Tue, Oct 24, 2000 at 02:52:53PM -0500, Garrett Goebel wrote: > > > It's a good idea, but it really Isn't There Yet. > > > > Fair enough... > >Hey, I'm not Dan. There should have been big tags around that >previous mail. Luckily for me, I am. (I

RE: Perl6 the platform-dependent bits...

From: John Porter [mailto:[EMAIL PROTECTED]] > > Garrett Goebel wrote: > > > > I'm sure you won't be surprised by this, but I recall John > > Porter as being a C-- fan. Now why is he being mysteriously silent? > > Nope, wasn't me. Never heard of it until someone brought it > up earlier. I do

Re: Perl6 the platform-dependent bits...

On Tue, Oct 24, 2000 at 02:52:53PM -0500, Garrett Goebel wrote: > > It's a good idea, but it really Isn't There Yet. > > Fair enough... Hey, I'm not Dan. There should have been big tags around that previous mail. -- God gave man two ears and one tongue so that we listen twice as much as we s

Re: Perl6 the platform-dependent bits...

Garrett Goebel wrote: > > I'm sure you won't be surprised by this, but I recall John > Porter as being a C-- fan. Now why is he being mysteriously silent? Nope, wasn't me. Never heard of it until someone brought it up earlier. I do admit, it sounds intriguing. > I just wanted to mention it, a

RE: Perl6 the platform-dependent bits...

From: Simon Cozens [mailto:[EMAIL PROTECTED]] > > On Tue, Oct 24, 2000 at 12:54:26PM -0500, Garrett Goebel wrote: > > Everyone seems to have their favorite laundry list of the > > failings of C, and an accompanying list of complex and/or > > fragile solutions. > > I'm coming to the rapid concl

Re: Perl6 the platform-dependent bits...

On Tue, Oct 24, 2000 at 12:54:26PM -0500, Garrett Goebel wrote: > Everyone seems to have their favorite laundry list of the failings of C, and > an accompanying list of complex and/or fragile solutions. I'm coming to the rapid conclusion that C-- is yours. (complicated and fragile solution.) Whi

RE: Perl6 the platform-dependent bits...

From: Garrett Goebel > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > (Though if someone comes up with a way to make the > > platform-dependent bits really small and isolated I'm all for it) > [mention of C--] > > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > I do

Re: Acceptable speeds (was Re: TIL redux (was Re: What will thePerl6 code name be?))

Most of the time, perl's performance is a total non-issue for me. When it is, I'm generally doing the same things as Dan (ie, things resembling dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to perl6-meta at one point. Here they are again: - You did ask at one point for

Threads vs. Threaded Inlince code (was Re: Threaded Perl bytecode)

along the lines of a perl6 project code name, we run into the name collision of process threads and threaded inline code (TIL). these 2 concepts have nothing to do with each other other than overloading the same word. please be clear which one you are refering to when unless your post is in an em

Re: Threaded Perl bytecode (was: Re: stackless python)

> "JvV" == John van V <[EMAIL PROTECTED]> writes: JvV> If this is the case, the code underlying the treading would utilize normal functions to poll the concurrent event streams and programmers could JvV> choose between the threads and functions depending on their levels of comfort. JvV> Th

Re: Threaded Perl bytecode (was: Re: stackless python)

This thread seems to be winding down fttb**, Judging from the below, perl multithreading [ I am guessing ] is simply syntatic sugar much the same as Koch C++ is a wrapper for regular cc compiler. This sounds nice, > Threading Perl bytecode would be nice about 98% of the time, and > sho

Re: Threaded Perl bytecode (was: Re: stackless python)

> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: >> Wouldn't just the appearance of *foo = \&other_foo, be enough to tell >> the compiler to treat all foo's (or perhaps if there were some dataflow >> analysis some region of code) to use indirection? AT> You're forgetting eval "*foo = \&othe

Re: Special syntax for numeric constants [Was: A tentative list of vtable functions]

At 02:34 PM 10/24/00 +0100, David Mitchell wrote: >Ken Fox <[EMAIL PROTECTED]> wrote: > > David Mitchell wrote: > > > Now of course if we have the luxury of deciding that core perl 'knows' > > > about complex numbers, then of the parser can be made to recognise ... > > > > The core doesn't need t

Re: Special syntax for numeric constants [Was: A tentative list of vtable functions]

Ken Fox <[EMAIL PROTECTED]> wrote: > David Mitchell wrote: > > Now of course if we have the luxury of deciding that core perl 'knows' > > about complex numbers, then of the parser can be made to recognise ... > > The core doesn't need to know -- that was my point. All the core needs > is the bas