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:
> 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
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:
> 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
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.
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
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
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
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
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, 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 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
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
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: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
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 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
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
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 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
> 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 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
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
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>
> "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>
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
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
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.
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
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
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
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 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
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
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:
> 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
36 matches
Mail list logo
