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 bett
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 te
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
needed and perhaps warn the user that they have go
/--- On Tue, Aug 29, 2000 at 06:33:41PM -0400, John Porter wrote:
| $x = 0;
|
| sub side {
| $x = 1;
| }
|
| trans {
| local $x;
| side();
| print "x=$x\n"; # should print 1
| die;
| }
|
| print "x=$x\n"; # should print 0
|
| Personally, I'd rather see transaction-ena
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.
On 28 Aug 2000, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Remove mathematic and trigonomic functions from core binary
$RFC[155] =~ s/trigonomic/trigonometric/g;
Cheers,
Philip
--
Philip Newton <[EMAIL PROTEC
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)
>> Lo
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
devic
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
real
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> Introduction
JH> The Classical Algorithms (refcounting, mark-and-sweep, copying)
JH> Reference Counting (several variants)
JH> Mark-Sweep (ditto)
JH> Mark-Compact (ditto)
JH> Copying (various strategies)
JH>
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 wh
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) o
> 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 wi
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
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 version
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
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 makes sense are
> on little machines where
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 pl
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 fr
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 releva
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 shou
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
> biggi
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 essenti
On Wed, 30 Aug 2000, Joshua N Pritikin wrote:
> 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 has
Garrett Goebel <[EMAIL PROTECTED]> writes:
>How small?
>
>I'd like to get barebones Perl and Linux on a 1.44MB floppy...
>
>If it is currently possible,
I was possible. At first Perl Conference there was a ZigZag app demoed
which came as console-only linux + perl + app. on one floppy.
--
Nick
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 07:32 PM 8/29/00 +, Nick Ing-Simmons wrote:
>>David L . Nicol <[EMAIL PROTECTED]> writes:
>> >
>> >Did I not just describe how a .so or a DLL works currently?
>>
>>And behind the scenes that does something akin to:
>>
>>int fd = open("file_of_posn_i
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 man
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 wrote:
> At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn 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 wha
On Wed, 30 Aug 2000, Bradley M. Kuhn wrote:
> Dan Sugalski wrote:
> > At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn 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:
> > >
> >
Dan Sugalski wrote:
> I do want to have a set of C/XS/whatever sources as part of the test suite
> as well--right now perl's test suite only tests the language, and I think
> we should also test the HLL interface we present, as it's just as
> important in some ways.
I want to see Perl become a f
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 refer
36 matches
Mail list logo
