Dan Sugalski wrote:
At 12:58 PM 8/29/00 -0500, Fisher Mark wrote:
Although Perl interpretation is divided into several passes (parser/lexer,
optimizer, tree/bytecode runner), all these passes are grouped together in
one binary. Under some memory-constrained conditions, it could be better if
Fisher Mark wrote:
How small do we really need to go? Are we looking at implementing Perl for
microcontrollers, or are we only worrying about Perl for PDAs?
On the other hand, microcontrollers still don't have a lot of RAM, at least
as compared to PDAs.
I heard that a major mobile
RANDOM THOUGHT (please don't hurt me):
What about allow a 'daemon-mode'? This might be really not an option, but it
could be beneficial in a sense that there would be one core, and any other
instances would be spawned child processes?
Does that make any sense? Mind you, it's still early.
Grant M.
David L . Nicol [EMAIL PROTECTED] writes:
Nick Ing-Simmons wrote:
We need to distinguish "module", "overlay", "loadable", ... if we are
going to get into this type of discussion. Here is my 2ยข:
Module - separately distributable Perl and/or C code. (e.g. Tk800.022.tar.gz)
Loadable - OS
How small?
I'd like to get barebones Perl and Linux on a 1.44MB floppy...
If it is currently possible, I'd like to know... Perhaps someone has already
created such a single disk linux distro?
Garrett
P.S. I know one group of developers who'd be interested in putting Perl on a
microcontroller.
Bradley M. Kuhn wrote:
For the world of the JVM port, it's imperative that hooks be
provided so
that the front-end can be run independently, and a different
back-end can be
run (to emit bytecode of some sort).
All this also dovetails nicely with the mass-market world of embedded
devices,
Something for the reference shelf:
Garbage Collection
Algorithms for Automatic Dynamic Memory Management
Richard Jones Raphael Lins
John Wiley and Sons, 1996
ISBN-0-471-94148-4
Still haven't had time to delve into it but from a quick browse it looks
On Wed, Aug 30, 2000 at 12:19:35PM -0400, Uri Guttman wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Introduction
JH The Classical Algorithms (refcounting, mark-and-sweep, copying)
JH Reference Counting (several variants)
JH
At 11:13 PM 8/29/00 -0400, Michael Maraist wrote:
Most of what this RFC (and reply) addresses is sort of up in the air, but I
wanted to address one point here.
The way python works is that in the library tree, it looks for any of the
following:
.py, pyc, and .so.
You can probably guess what's
At 08:05 AM 8/30/00 -0500, Garrett Goebel wrote:
How small?
I'd like to get barebones Perl and Linux on a 1.44MB floppy...
That, I think, is unlikely to happen. Heck, you're hard-pressed to get
linux alone on a 1.44M floppy these days...
CD? Sure. Zip disk? Yeah, works. Maybe (just maybe) on
For security reasons, I'd much rather the compiled version of anything that
goes into the perl tree be done only at module install time with perhaps
some mechanism to explicitly build (or rebuild) a bytecompiled version.
Automagically dropping things into places that should be secure
At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
2) Having a mechanism to automagically load in chunks of executable code
only when needed would be nice
I would take this one a bit further:
2a) It should be possible, at compile-time, to detect what chunks will be
On Wed, Aug 30, 2000 at 12:33:53PM -0400, Dan Sugalski wrote:
At 08:05 AM 8/30/00 -0500, Garrett Goebel wrote:
How small?
I'd like to get barebones Perl and Linux on a 1.44MB floppy...
That, I think, is unlikely to happen. Heck, you're hard-pressed to get
linux alone on a 1.44M floppy
At 07:37 PM 8/29/00 -0700, Russ Allbery wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
On 29 Aug 2000, Russ Allbery wrote:
I'd love to see Perl aggressively take advantage of new capabilities in
dynamic loaders, though. Among other things, I'll point out that
symbol versioning is the way
At 11:10 AM 8/30/00 -0500, Jarkko Hietaniemi wrote:
Something for the reference shelf:
Garbage Collection
Algorithms for Automatic Dynamic Memory Management
Richard Jones Raphael Lins
John Wiley and Sons, 1996
ISBN-0-471-94148-4
Still haven't had
At 01:04 PM 8/30/00 -0500, David L. Nicol wrote:
Nick Ing-Simmons wrote:
David L . Nicol [EMAIL PROTECTED] writes:
"overlay" is reminiscent of old IBM machines swapping parts of the
program out because there isn't enough core.
Which is exactly why I chose it - the places these things
Dan Sugalski wrote:
Oh, and then they will be unloaded if we need the space for something
else. I understand now, thanks.
Well, probably not, though that could be reasonable for a particular
platform. It's only relevant for a persistent interpreter anyway--for ones
fired up fresh it
At 01:26 PM 8/30/00 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
Oh, and then they will be unloaded if we need the space for something
else. I understand now, thanks.
Well, probably not, though that could be reasonable for a particular
platform. It's only relevant for a
On Tue, 29 Aug 2000, Russ Allbery wrote:
Not a big deal, and that's certainly doable. But it's possible to do more
than that if you really want to. The glibc folks have decided to comment
to nearly full binary compatibility for essentially forever; the theory is
that upgrading libc should
On Wed, Aug 30, 2000 at 01:15:39PM -0400, [EMAIL PROTECTED] wrote:
I didn't realize until I read through parts of this exactly how much time a
refcounting GC scheme took. Between that and perl 5's penchant for
flattening arrays and hashes (which creates a lot of garbage itself for
biggish
On Wed, 30 Aug 2000, Andy Dougherty wrote:
On Tue, 29 Aug 2000, Russ Allbery wrote:
Not a big deal, and that's certainly doable. But it's possible to do more
than that if you really want to. The glibc folks have decided to comment
to nearly full binary compatibility for essentially
On Wed, 30 Aug 2000, Dan Sugalski wrote:
I think we can pull this off if we're careful and draw really strict lines
about what is and isn't public stuff. It's not easy, and it will mean
we'll have to have some reference executables in a test suite for
verification, but I think we can manage
Andy Dougherty [EMAIL PROTECTED] writes:
I'm sure the glibc folks indeed work very hard at this and are largely
successful. I also know, however, that over the past couple of years or
so, I've had to recompile nearly all of my applications on several
occasions when I've upgraded glibc.
You are now biting off quite a bit. This is the generic problem that
all database systems have to do to handle transactions.
I believe that this will increase the deadlock possibilities. Without
a transaction, it might have been possible to get in and out of a subroutine
without holding the lock
Dan Sugalski [EMAIL PROTECTED] writes:
What I'm
thinking of specifically could be used to yank the functions out of the
base perl binary (which is sort of where it started) but doesn't actually
have to be used that way on any particular platform. (Or, rather, probably
will, but just reference a
25 matches
Mail list logo
