Re: What the heck is: timely destruction

2003-08-18 Thread Bennett Todd
2003-08-18T13:52:50 K Stol: > After reading most of the messages on timely destruction, I still > don't quite understand what it is. If someone has a spare minute > free, could you please explain? The other explanations certainly have formality to commend them, but somehow they didn't make clear t

Re: What the heck is: timely destruction

2003-08-19 Thread Bennett Todd
Is the destruction going to be timely enough for IO::File->new(">foo")->print("foo\n"); print `cat foo`; to behave predictably? -Bennett pgp0.pgp Description: PGP signature

Re: Why we're here

2000-08-02 Thread Bennett Todd
(Migrated from bootstrap) 2000-07-24-10:17:54 Dan Sugalski: > Perl 6 will most *definitely* be an embedded perl. Easy and clean > embedding is one of my primary goals. A small core with extended > functionality provided by non-core things is a secondary one. (And > one very much dependent on the

Re: GC

2000-08-05 Thread Bennett Todd
2000-08-02-19:43:57 Simon Cozens: > Ref counting isn't garbage collection. Ref counting is fine garbage collection. > http://www.jwz.org/doc/gc.html If perl6 were to want to try and rise to the level of jwz's design aesthetics, I'd say we oughta save ourselves a lot of work and abandon it now.

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread Bennett Todd
Tom Christiansen <[EMAIL PROTECTED]> writes: > Keywords that *cannot* be overridden are chop, defined, delete, do, > dump, each , else, elsif, eval, exists, for, foreach, format, glob, > goto, grep, if, keys, last, local, m, map, my, next, no, package, > pop, pos, print, printf, prototype, push, q

Re: New Perl rewrite - embedded Perl

2000-09-12 Thread Bennett Todd
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

2000-09-13 Thread Bennett Todd
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

2000-09-13 Thread Bennett Todd
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 > >

Re: RFC 313 (v1) Perl 6 should support I18N and L10N

2000-09-26 Thread Bennett Todd
2000-09-26-08:10:54 Webmaster: > Simon Cozens [EMAIL PROTECTED] Wrote: > >Perl 6 needs some kind of internationalisation and therefore message > >catalogue support. Really needs, with great urgency. > > Doesn't RFC 85 address this to some extent? By offering up 'error codes' > can't the programme

Re: Design

2000-11-02 Thread Bennett Todd
2000-11-02-17:30:56 Nathan Torkington: > Here are the things to order, in my order: > > Robustness > Portability > Maintainability > Testability > Reusability > Speed > Simplicity > Size A couple of negligible wibbles to toss in: would it make sense to separate "Simplicity" into

Markup wars (was Re: Proposal for groups)

2000-12-05 Thread Bennett Todd
2000-12-05-13:02:56 Nathan Torkington: > I say that the person who *does* the work deserves the right to > choose what format it is in. So long as we can make navigable > webpages out of it, that person can write on a Commodore 64 for > all I care. Would you accept a restatement of: as long as wh

Re: Speaking of signals...

2001-01-03 Thread Bennett Todd
2001-01-03-21:43:39 Dan Sugalski: > I think one of the things we might want to do is figure out what people use > signals for [...] The big one I can think of is interrupting > timers. [...] (Excepting I/O signalish things, which will get > handled elsewhere) How about, goosing long-lived daemon