Re: New Perl rewrite - embedded Perl

- Original Message - From: "Dan Sugalski" <[EMAIL PROTECTED]> > > >If more speed is needed, make the part that's currently too slow > >_simpler_, not _more_complex_. > > I think you'll find it rather more useful to make the part that's currently > too slow *faster*, rather than more or les

Re: New Perl rewrite - embedded Perl

At 10:07 AM 9/13/00 -0400, Bennett Todd wrote: >2000-09-13-03:29:16 Hildo Biersma: > > Some would argue that a better design is required. Apache 2.0 will > > use a mixed thread/process model, and mod_perl 2.0 will run > > selected threads within one process, precisely to alleviate these > > proble

Re: New Perl rewrite - embedded Perl

At 03:49 PM 9/13/00 +, John van V wrote: >I'm really entranced by the prospect of sending frozen structures >including anonymous subs to to remote devices like out on Mars or Pittsburgh. With full lexical scope along with it? You're not alone... :) Da

Re: New Perl rewrite - embedded Perl

2000-09-13-13:56:07 John van V: > 2000-09-12-20:35:32 Bennett Todd: > > The exact same design targets --- really really fast, teensy > > memory footprint --- that define the microcontroller embedded > > market, also define the entry to these roles on the biggest > > servers. > > I'm not sure what

Re: New Perl rewrite - embedded Perl

On Tue, 12 Sep 2000 20:35:32 -0400, Bennett Todd <[EMAIL PROTECTED]> wrote : > I don't even want to embed the current perl in mutt; I'd love to > have a scripting and extension language embedded in there, but not > one that's bigger than all the rest of the application. A couple years ago I wr

Re: New Perl rewrite - embedded Perl

> > Tom Christiansen wrote: > > > It [miniperl] isn't substantially smaller, so that does you no good. > The socket library seems to be the poster child for what to leave > out, but that's a weak argument ... it would make sense to design a > miniperl that can dynamically load the "expensiv

Re: New Perl rewrite - embedded Perl

2000-09-13-03:29:16 Hildo Biersma: > Some would argue that a better design is required. Apache 2.0 will > use a mixed thread/process model, and mod_perl 2.0 will run > selected threads within one process, precisely to alleviate these > problems. So it's not necessarily perl's fault... Some would

Re: New Perl rewrite - embedded Perl

Bennett Todd wrote: > > I think the complaint about mod_perl's weight bears looking at, > despite the success of the INN embedding. One invocation of INN is > likely to do a sufficiently heroic amount of work that the weight > and bulk of a perl in there may well not hurt a bit. > > A single htt

Re: New Perl rewrite - embedded Perl

Bennett Todd <[EMAIL PROTECTED]> writes: > I think the complaint about mod_perl's weight bears looking at, despite > the success of the INN embedding. One invocation of INN is likely to do > a sufficiently heroic amount of work that the weight and bulk of a perl > in there may well not hurt a bit

Re: New Perl rewrite - embedded Perl

2000-09-11-16:23:20 Dan Sugalski: > At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote: > >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote: > > > INN has been embedding Perl for years, quite successfully. > > > >There's embedding and there's embedding. Embedding in an UNIX server > >

Re: New Perl rewrite - embedded Perl

"ye, wei" wrote: > Tom Christiansen wrote: > > It [miniperl] isn't substantially smaller, so that does you no good. The socket library seems to be the poster child for what to leave out, but that's a weak argument. If Perl 6 gets all the functionality requested by Damian or the PDL folks, it woul

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

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

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: 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

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

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: 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

>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

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

>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

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

At 09:40 PM 9/9/00 +0100, Matthew Gillman wrote: >Basically, my comment is that a lot of commercial applications seem to be >mixing and matching languages together (like C++ and Perl), so it would be >really great if the issues such as Purify errors for embedded Perl were >addressed (I realise