Re: New Perl rewrite - embedded Perl

Matthew Gillman wrote: > Dear All > > I wrote a large C++ program which used embedded Perl. Later, this was changed to >embedded Python. The reasons for this included: > > 1) Python allows you to pass a pointer to an object from C/C++ to the embedded >Python interpreter, wheras Perl makes you p

Re: New Perl rewrite - embedded Perl

>Perlsonally, I don't think mod_perl is a success story, the main problem >is perl interpreter is too big and need so much memory, so build apache >interpreter makes apache couldn't run fast as it should be. Size doesn't matter. CF a "browser". And a VM system. >I suggest Perl6 can give us a

Re: New Perl rewrite - embedded Perl

Tom Christiansen wrote: > >Perlsonally, I don't think mod_perl is a success story, the main problem > >is perl interpreter is too big and need so much memory, so build apache > >interpreter makes apache couldn't run fast as it should be. > > Size doesn't matter. CF a "browser". And a VM system

Re: New Perl rewrite - embedded Perl

>are put in "main" directory. I woud like Perl6 do the same thing, leave >etc stuff >outside of core. We've been down this route. It doesn't help the way you think it does. These are merely wafer-thin wrappers about syscalls. It's Perl's complete infrastructure support system you're seeing, a

Perl Implementation Language

I think it's about time we decided what compiler we want to hand perl's source to, and what language we want to implement perl in. Currently I'm thinking C for the target compiler just because of its ubiquity. I am *not* particularly advocating for C as a spiffy language. Nor against, for that

Re: New Perl rewrite - embedded Perl

Tom Christiansen writes: > We've been down this route. It doesn't help the way you think it does. > These are merely wafer-thin wrappers about syscalls. It's Perl's > complete infrastructure support system you're seeing, and that you > will not reduce. Actually, if we can split compiler from r

Re: New Perl rewrite - embedded Perl

At 11:40 AM 9/11/00 -0600, Nathan Torkington wrote: >Tom Christiansen writes: > > We've been down this route. It doesn't help the way you think it does. > > These are merely wafer-thin wrappers about syscalls. It's Perl's > > complete infrastructure support system you're seeing, and that you > >

Re: RFCs for thread models

At 11:59 AM 9/10/00 -0700, Benjamin Stuhl wrote: >--- Chaim Frenkel <[EMAIL PROTECTED]> wrote: > > Now where > > sub recursive() { my $a :shared; ; return > > recursive() } > > would put $a or even which $a is meant, is left as an > > excersize > > for someone brighter than me. > >%P6-E-

Re: RFCs for thread models

Steven W McDougall <[EMAIL PROTECTED]> writes: >1. All threads execute the same op tree > >Consider an op, like > > fetch(b) > >If you actually compile a Perl program, like > > $a = $b > >and then look at the op tree, you won't find the symbol "$b", or "b" >anywhere in it. But

Re: RFCs for thread models

Steven W McDougall <[EMAIL PROTECTED]> writes: > >My point is that we can't work with guesses and exercises. >We need a specific, detailed proposal that we can discuss and >evaluate. I'm hoping that someone will submit an RFC for one. Start with perl5.6.0's ithreads model. -- Nick Ing-Simmons

Re: Perl Implementation Language

Dan Sugalski wrote: > If anyone's got any arguments in a particular direction, now would be the > time. Once we're done wrangling, we'll start in on the features we need to > write into the PIL translator, and get implementation of that started. > > Dan

Re: one question about vtbls

Benjamin Stuhl <[EMAIL PROTECTED]> writes: >I have one question about vtbls that I have not been able >to figure out an answer to: > > How does using a vtbl get rid of the switch(sv->sv_flags) >with multi-valued scalars running around? That is, how does >one write a vtbl function that can cope wi

Re: Perl Implementation Language

At 01:23 PM 9/11/00 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > If anyone's got any arguments in a particular direction, now would be the > > time. Once we're done wrangling, we'll start in on the features we need to > > write into the PIL translator, and get implementation of that sta

Re: Perl Implementation Language

On Mon, Sep 11, 2000 at 02:39:14PM -0400, Dan Sugalski wrote: > At 01:23 PM 9/11/00 -0500, David L. Nicol wrote: > >Dan Sugalski wrote: > > > > > If anyone's got any arguments in a particular direction, now would be the > > > time. Once we're done wrangling, we'll start in on the features we need

Re: Perl Implementation Language

At 08:19 PM 9/11/00 +0100, Simon Cozens wrote: >On Mon, Sep 11, 2000 at 02:39:14PM -0400, Dan Sugalski wrote: > > At 01:23 PM 9/11/00 -0500, David L. Nicol wrote: > > >Dan Sugalski wrote: > > > > > > > If anyone's got any arguments in a particular direction, now would > be the > > > > time. Once

Re: New Perl rewrite - embedded Perl

ye, wei <[EMAIL PROTECTED]> writes: > Yes, I agree with you that Perl kernel is too big to embed into other > program. You do? I don't. INN has been embedding Perl for years, quite successfully. -- Russ Allbery ([EMAIL PROTECTED])

Re: New Perl rewrite - embedded Perl

On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote: > ye, wei <[EMAIL PROTECTED]> writes: > > > Yes, I agree with you that Perl kernel is too big to embed into other > > program. > > You do? I don't. INN has been embedding Perl for years, quite > successfully. There's embedding and

Re: New Perl rewrite - embedded Perl

At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote: >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote: > > ye, wei <[EMAIL PROTECTED]> writes: > > > > > Yes, I agree with you that Perl kernel is too big to embed into other > > > program. > > > > You do? I don't. INN has been embeddin

Re: Perl Implementation Language

On Mon, Sep 11, 2000 at 04:01:53PM -0400, Dan Sugalski wrote: > Are you thinking of something along the lines of FORTH or PostScript? Or > something else? Something else. Forth and PostScript are languages which are implemented through stacks; I'm talking about a language designed for manipulati

Re: Perl Implementation Language

On Mon, Sep 11, 2000 at 01:09:41PM -0400, [EMAIL PROTECTED] wrote: > Currently I'm thinking C for the target compiler just because of its > ubiquity. I don't think it matters much. Any language similar to C (or C itself) is fine. The ticklish part is garbage collection, exceptions, and the for

Re: Perl Implementation Language

At 09:26 PM 9/11/00 +0100, Simon Cozens wrote: >On Mon, Sep 11, 2000 at 04:01:53PM -0400, Dan Sugalski wrote: > > Are you thinking of something along the lines of FORTH or PostScript? Or > > something else? > >Something else. Forth and PostScript are languages which are implemented >through stacks

Re: New Perl rewrite - embedded Perl

I just subscribed this minute... > >There's embedding and there's embedding. Embedding in an UNIX server > >is different than from embedding in a RTOS microcontroller. We're getting very close to blurring the line between microcontrollers and servers. In the next few years the palm tops will h

Re: New Perl rewrite - embedded Perl

On Mon, Sep 11, 2000 at 09:36:19PM -, John van V wrote: > > I just subscribed this minute... > > > >There's embedding and there's embedding. Embedding in an UNIX server > > >is different than from embedding in a RTOS microcontroller. > > > We're getting very close to blurring the line bet