Re: Removing stuff to shareable thingies

[Dan Sugalski]

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:
> > >
> > >  2a) It should be possible, at compile-time, to detect what chunks will be
> > >  needed and perhaps warn the user that they have gone beyond a subset of
> > >  Perl they sought to stay within.
> > >
> > >This is primarily for compiling Perl to be run on embedded devices.
>  
> > I was thinking of generalizing this so that the parser would pass on to
> > the bytecompiler (and then to the execution engine, whatever that may be)
> > that an add-on piece was used.
> 
> That sounds like it fits with my idea.  The question then becomes what is
> considered an "add-on" piece.  I'd like to get very fine-grained with; even
> being able to turn of things as fundamental as tied hashes at compile time.

Well, the bytecode compiler will get all the bytecodes, so it can
presumably do whatever analysis it wants and if it sees bytecode for a
fundamental language feature that isn't supported (string eval, say, or
do/require) then it can yell.
 
On the other hand, it really wouldn't hurt to figure this out and pass on
the info to the compiler unit--if it doesn't get used, that's OK,
something else might later.

> I doubt anyone would have a need to do this except for the embedded device
> developers, but it would be best to be able to tell the embedded device
> developer at compile time that per code won't run because the embedded
> device is so small that it doesn't have the tied-hash support.  ;)

Yup, I agree. Though I can see tied hashes making FurbiePerl easier... :-)

Dan

Re: Removing stuff to shareable thingies

[Bradley M. Kuhn]

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 what chunks will be
> >  needed and perhaps warn the user that they have gone beyond a subset of
> >  Perl they sought to stay within.
> >
> >This is primarily for compiling Perl to be run on embedded devices.
 
> I was thinking of generalizing this so that the parser would pass on to
> the bytecompiler (and then to the execution engine, whatever that may be)
> that an add-on piece was used.

That sounds like it fits with my idea.  The question then becomes what is
considered an "add-on" piece.  I'd like to get very fine-grained with; even
being able to turn of things as fundamental as tied hashes at compile time.

I doubt anyone would have a need to do this except for the embedded device
developers, but it would be best to be able to tell the embedded device
developer at compile time that per code won't run because the embedded
device is so small that it doesn't have the tied-hash support.  ;)

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

[Chaim Frenkel]

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 except within the subroutine. 

With a transaction, all variables touched within the dynamic scope of the
transaction will have to be locked.



> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:

KF> I was thinking about this same problem while reading RFC 130. It seems
KF> like transactions and exceptions are closely related. Should we combine
KF> the two?

KF>   try transaction {
KF>  ...
KF>   }

KF> That's a really interesting extension to exceptions -- code that has
KF> no side-effects unless it finishes. BTW, how useful are transactions on
KF> internal variables if we don't provide I/O transactions too?

KF> Since the "transaction" keyword can only appear after "try", it
KF> doesn't have to appear as a new global keyword.

KF> This type of language feature strikes me as something similar to the
KF> Pascalish "with" proposal -- the "transaction" keyword triggers munging
KF> of the variables used in the following block. Obviously the munging
KF> is very different between these, but if we allow the general concept
KF> of munging the intermediate code (parse tree or OP tree or whatever),
KF> then both "with" and "transation" might be implemented from user code
KF> outside the core.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

the C JIT

[David L. Nicol]

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 full-blown C/C++ JIT.  Since Perl is for
a large part a compatible subset of C I don't see this as unrealistic.

Delaying any post-token parsing of barewords until after looking at
what local declarations are in effect is part of it,  dealing with the
one or two differences in operator precedence that exist is another

(Old precedence semantics unless  new-ism like a declared typed bareword
exists in the current or a surrounding block would be the easiest way to do
it I think)

Typed barewords as an available good syntax would please those who find
perl overpunctuated.

XS would become a more proper part of the language, the line would blur
as we could mix Perl and C freely with very little performance loss due
to late binding except in things that are not known at "compile time"
things which by definition cannot be clarified without run-time inputs.



-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]

Re: RFC 155 - Remove geometric functions from core

[Russ Allbery]

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.  Other times, glibc upgrades have
> gone without a hitch.  It's probably my fault and probably somewhere
> deep in my personal library I'm incorrectly fiddling with stdio
> internals or something, but I just wanted to offer a counter data point
> that doing this sort of this robustly is, indeed, very hard.

It may not be your fault... my understanding is that glibc 2.0 really
didn't do things right, and that glibc 2.1 did break some binary
compatibility to fix some serious bugs.  It's probably only fair to start
holding glibc to this standard from 2.2 and up.

Perl *should* have a *much* easier task than glibc, given that our
interface is positively tiny compared to the entire C library.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 155 - Remove geometric functions from core

[Bryan C . Warnock]

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 that.
> 
> 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.

One of the off-the-cuff suggestions I sent in to one of the myriad
polls for "fixing Perl", is that the bulk of Perl should be written in
the XS replacement.  This would force a two-pass build of perl, of
course - the first pass to build the XSR, and the second to build perl
itself.  But the advantage was that it would really solidify the
internals interface.  And give you your test suite above.  :-)

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 155 - Remove geometric functions from core

[Nick Ing-Simmons]

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_indepenant_byte_code",O_RDONLY);
>>struct stat st;
>>fstat(fd,&st);
>>code_t *code = mmap(NULL,st.st_len,PROT_READ,MAP_SHARED,fd,0);
>>close(fd);
>
>Don't forget the fixup work that needs to be done afterwards. Loading the 
>library into memory's only the first part--after that the loader needs to 
>twiddle with transfer vectors and such so the unresolved calls into the 
>routines in the newly loaded library get resolved.

I finessed the "fixup work" by saying "position independant byte code".
The fixups break the shareability of the pages which is why you compile
shared libs -fPIC. So we should strive to have minimal fixups and 
collect them in one place (which vtables do very nicely).


-- 
Nick Ing-Simmons

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

[Nick Ing-Simmons]

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 Ing-Simmons

Re: a garbage collection book

[Dan Sugalski]

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 hashes (which creates a lot of garbage itself for 
> > biggish things), I wonder how much perl 5's performance could be boosted 
> > with some relatively minor changes to GC & list handling.
> 
> Well, for a rough estimate try:
> 
> sv.h:
>   #undef SvREFCNT_inc
>   #define SvREFCNT_inc(sv)
>   #undef SvREFCNT_dec
>   #define SvREFCNT_dec(sv)

I'm not sure how exact that'll be, since we'll incur a lot of extra memory
allocation overhead, but it ought to give a good seat-of-the-pants figure.

I'll give it a shot and see what we're looking at for numbers. (Might be a
while, so if anyone else wants to try, that'll be great)

Dan

Re: RFC 155 - Remove geometric functions from core

[Dan Sugalski]

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 forever; the theory is
> > that upgrading libc should never break a working application even if the
> > ABI changes.  I'm not familiar with the exact details of how symbol
> > versioning works, but as I understand it, this is what it lets you do.
> 
> 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.  Other times, glibc upgrades have gone
> without a hitch.  It's probably my fault and probably somewhere deep in my
> personal library I'm incorrectly fiddling with stdio internals or
> something, but I just wanted to offer a counter data point that doing
> this sort of this robustly is, indeed, very hard.

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 that.

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.

dan

Re: a garbage collection book

[Joshua N Pritikin]

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 things), I wonder how much perl 5's performance could be boosted 
> with some relatively minor changes to GC & list handling.

Well, for a rough estimate try:

sv.h:
  #undef SvREFCNT_inc
  #define SvREFCNT_inc(sv)
  #undef SvREFCNT_dec
  #define SvREFCNT_dec(sv)

-- 
May the best description of competition prevail.
  (via, but not speaking for Deutsche Bank)

Re: RFC 155 - Remove geometric functions from core

[Andy Dougherty]

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 never break a working application even if the
> ABI changes.  I'm not familiar with the exact details of how symbol
> versioning works, but as I understand it, this is what it lets you do.

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.  Other times, glibc upgrades have gone
without a hitch.  It's probably my fault and probably somewhere deep in my
personal library I'm incorrectly fiddling with stdio internals or
something, but I just wanted to offer a counter data point that doing
this sort of this robustly is, indeed, very hard.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: RFC 146 (v1) Remove socket functions from core

[Dan Sugalski]

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 persistent interpreter anyway--for ones
> > fired up fresh it doesn't matter, since they won't have anything loaded to
> > start.
>
>
>Still, if there was some networking code at the beginning but only the
>beginning, and othe code later, explicitly marking the now-unreachable
>code as recyclable could be a win, if it isn't much trouble.  But that's
>what LRU paging does anyway -- what platfoms are we talking about, that
>don't have LRU paging?

The Palm, WinCE (I think), various embedded devices (I don't think my car 
has a LRU paging scheme, for example), depending on how the translation 
goes a JVM port might not...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 146 (v1) Remove socket functions from core

[David L. Nicol]

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 doesn't matter, since they won't have anything loaded to
> start.


Still, if there was some networking code at the beginning but only the
beginning, and othe code later, explicitly marking the now-unreachable
code as recyclable could be a win, if it isn't much trouble.  But that's
what LRU paging does anyway -- what platfoms are we talking about, that
don't have LRU paging?



-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   Subroutine one-arg, him called no-arg, get $_-arg.  Ug.

Re: RFC 146 (v1) Remove socket functions from core

[Dan Sugalski]

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 makes sense are
> > on little machines where memory is a premium.
> >
> > our add-ons are going to be loaded on need
> > by the parent and only depend on the parent.
>
>
>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 doesn't matter, since they won't have anything loaded to 
start.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 146 (v1) Remove socket functions from core

[David L. Nicol]

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 memory is a premium.
> 
> our add-ons are going to be loaded on need
> by the parent and only depend on the parent.


Oh, and then they will be unloaded if we need the space for something
else.  I understand now, thanks.

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   Subroutine one-arg, him called no-arg, get $_-arg.  Ug.

Re: a garbage collection book

[Dan Sugalski]

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 time to delve into it but from a quick browse it looks
>really good and my heavily-into-LISP-boss recommends it.

Got it, and I'm about halfway through. (Along with a half-dozen other 
books...) It makes a lot of sense so far, and if the non-pausing GC stuff 
(that I haven't gotten to) in the back half of the book pans out for perl, 
we may get a good performance win just from that.

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 things), I wonder how much perl 5's performance could be boosted 
with some relatively minor changes to GC & list handling.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 155 - Remove geometric functions from core

[Dan Sugalski]

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 that things like libc manage to be
> >> backward compatible while still changing things, and we should probably
> >> seriously consider using symbol versioning in a shared libperl.so as a
> >> means to provide that much desired and extremely difficult to implement
> >> stable API for modules and the XS-equivalent.
>
> > This is where my lack of strange Unix knowledge comes to the fore. Is
> > this really a problem? It seems to me to be a standard sort of thing to
> > be dealing with. (OTOH, my platform of choice has 20-year-old
> > executables as part of its test suite and a strong engineering bent, so
> > I may be coming at things from a different direction than most folks)
>
>Well, it depends on what your goals are, basically.  For most shared
>libraries, people don't take the trouble.

That's OK--we will. :)

>Basically, no matter how well you design the API up front, if it's at all
>complex you'll discover that down the road you really want to *change*
>something, not just add something new (maybe just add a new parameter to a
>function).  At that point, the standard Perl thing up until now to do is
>to just change it in a major release and require people to relink their
>modules against the newer version.  And relink their applications that
>embed Perl.

It's just hit me why VMS' system service interface has managed to handle 
this as well as it has over the years. Unfortunately one of the things that 
helped it's longevity is rather inconvenient for the average C programmer.

I'll write up something more concrete once I've batted it around some in my 
brain, and we can see if I'm off-base or, if not, whether it's worth it.

>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 never break a working application even if the
>ABI changes.  I'm not familiar with the exact details of how symbol
>versioning works, but as I understand it, this is what it lets you do.
>Both the old and the new symbol are available, and newly built
>applications use the new one while older applications continue to use the
>previous symbol.  That means that all your older binary modules keep
>working, and if your applications that embed Perl are linked dynamically,
>you can even upgrade Perl underneath them without having to rebuild them.
>
>I'm not sure it's worth the trouble, but it's something to consider.

I'm sure it is. I really, *really* want long-term binary compatibility.

Luckily for us, perl may end up with a reasonably small external API, 
which'll make life easier.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

[Jarkko Hietaniemi]

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 these days...

QNX can fit a multithreading memoryprotected POSIX-compliant OS with a
TCP/IP stack, a GUI, a shell (I think), and a web browser on a 1.b44 MB
floppy.  Not a joke: http://www.qnx.com/demodisk/

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Removing stuff to shareable thingies

[Dan Sugalski]

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
>  needed and perhaps warn the user that they have gone beyond a subset of
>  Perl they sought to stay within.
>
>This is primarily for compiling Perl to be run on embedded devices.

I was thinking of generalizing this so that the parser would pass on to the 
bytecompiler (and then to the execution engine, whatever that may be) that 
an add-on piece was used.

If the execution engine's really a perl->Java translator, the info could be 
used to load in some sort of extra code or library. If the execution 
engine's a targeted bytecode saver, it could warn that the extras aren't 
available. If the execution engine's just the execution engine then, well, 
presumably it'd load in the code. :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 172 (v1) Precompiled Perl scripts.

[Jarkko Hietaniemi]

> 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 worries me. 
> (And yes, I realize that you'd need write access to the directory to do it, 
> so you're already vulnerable and all that, but... just because we hand 
> someone a gun doesn't mean we need to load it and point it somewhere as well)

Hey, we'll just make perl suid root by default so that it can safely
compile every .p[lm] file into .p[lm]c files!!!  Hey, why are all you
looking at me like that...?

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

[Dan Sugalski]

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 those 2.88M 
floppies. (Did anyone but DEC ('scuse me, TCFKAD) ship gadgets with those 
on 'em?) But I think you're pushing it for 1.44M.

Possibly just the bare execution engine would fit--that may be doable. (You 
might lose all the tack-on bits we've been wrangling over, as well as the 
lexer (and thus string eval, do, and require) and any dynaloaded pieces, 
but...)

>P.S. I know one group of developers who'd be interested in putting Perl on a
>microcontroller. -Right now, they seem to think they'll have to use Python.

I'd love to have perl fit in a microcontroller environment. I'm also *real* 
up for a good perl->java translator. (A good friend I used to work for's 
using JPython instead of perl because they need a good portable 
self-contained GUI thingie. I am officially Annoyed about that... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 172 (v1) Precompiled Perl scripts.

[Dan Sugalski]

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 what.  If only the .py was found, it
>immediately writes out the .pyc when it finishes compiling.  This happens
>every time (unless it can't write to the directory).

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 worries me. 
(And yes, I realize that you'd need write access to the directory to do it, 
so you're already vulnerable and all that, but... just because we hand 
someone a gun doesn't mean we need to load it and point it somewhere as well)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: a garbage collection book

[Jarkko Hietaniemi]

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> Mark-Sweep (ditto)
>   JH> Mark-Compact (ditto)
>   JH> Copying (various strategies)
>   JH> Generational Garbage Collection (you know the drill)
>   JH> Incremental and Concurrent Garbage Collection (...)
>   JH> Garbage Collection for C
>   JH> Garbage Collection for C++
>   JH> Cache-Conscious Garbage Collection
>   JH> Distributed Garbage Collecion
> 
> sounds like a bunch of garbage to me. 
> 
> 

You have such a dirty mind.

> uri
> 
> -- 
> Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
> SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
> The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
> The Best Search Engine on the Net  --  http://www.northernlight.com

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: a garbage collection book

[Uri Guttman]

> "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>   Generational Garbage Collection (you know the drill)
  JH>   Incremental and Concurrent Garbage Collection (...)
  JH>   Garbage Collection for C
  JH>   Garbage Collection for C++
  JH>   Cache-Conscious Garbage Collection
  JH>   Distributed Garbage Collecion

sounds like a bunch of garbage to me. 



uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

a garbage collection book

[Jarkko Hietaniemi]

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
really good and my heavily-into-LISP-boss recommends it.  Contents:

Introduction
The Classical Algorithms (refcounting, mark-and-sweep, copying)
Reference Counting (several variants)
Mark-Sweep (ditto)
Mark-Compact (ditto)
Copying (various strategies)
Generational Garbage Collection (you know the drill)
Incremental and Concurrent Garbage Collection (...)
Garbage Collection for C
Garbage Collection for C++
Cache-Conscious Garbage Collection
Distributed Garbage Collecion

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

RE: Optional Separate Programs for Interpreter Passes

[Fisher Mark]

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, where almost all copies of the device have only the compiled code.
Only the developers ever have the source, the parser/lexer, etc. in a
device.  The rest of us with our TVs, VCRs, and so on have only compiled
code in our devices.  And, I expect to see more and more microcontrollers
come with a JVM (or have a JVM readily available).  So a perl that can
compile down to JVM bytecode would be a big win in the embedded world.

Mark Leighton FisherThomson Consumer Electronics
[EMAIL PROTECTED] Indianapolis, IN, USA
"Display some adaptability."  -- Doug Shaftoe, _Cryptonomicon_

RE: how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)

[Garrett Goebel]

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. -Right now, they seem to think they'll have to use Python.

From: Bradley M. Kuhn [mailto:[EMAIL PROTECTED]]
> 
> 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 telephone manufacturer might be 
> putting a JVM chip in one of their future models.
> 
> I would like to be able to compile Perl programs to JVM so 
> that they can run on such a device.  I don't know if that's
> as small as a what you mean by microcontrollers, but it's
> still pretty small (probably smaller than a PDA, since RAM
> on the phone will be taken up by lots of phone-related
> stuff :).

Re: RFC 146 (v1) Remove socket functions from core

[Nick Ing-Simmons]

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 loadable binary e.g. Tk.so or Tk.dll
>> Overlay  - Tightly coupled ancillary loadable which is no use without
>>its "base"  - e.g. Tk/Canvas.so which can only be used
>>when a particular Tk.so has already be loaded.
>
>I know I've got helium Karma around here these days but I don't like
>"overlay" it 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 memory is a premium. 

>Linux modules have
>dependencies on each other and sometimes you have to load the more basic
>ones first or else get symbol-undefined errors.  So why not follow
>that lead and call Overlays "dependent modules."

A. Name is too long.
B. That does not have same "feel" as what we have.

>
>If a dependent module knows what it depends on, that module can be
>loaded on demand for the dependent one.

But - like old-style overlays our add-ons are going to be loaded on need
by the parent and only depend on the parent.

e.g. perl discovers it needs to getpwuid() do it loads the thing
that has those functions.

We are not going to be in the middle of getpwuid() and decide we need perl...


-- 
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.

Re: RFC 155 (v2) Remove mathematic and trigonomic functions fromcore binary

[Philip Newton]

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 PROTECTED]>

Re: Removing stuff to shareable thingies

[Grant M.]

 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 chunk of code already loaded in)

Is this thing working? I've been making suggestions regarding this for about
a month now. I actually started an RFC on it, but never heard a word back
about it.

It really can have a 'dual' functionality. Static Build or DSO. Potentially,
there can even been a combination version (see my email of 8/28/00), with
some libraries static, and others DSO. This would allow a core functionality
required by the installation, while still allow the extended functionality
needed to run applications not originally expected in the installation. In
my estimation, it could possibly allow for better system tuning, and
potentially allow for higher security in sensitive areas (i.e.,
'uncertified' libraries could be left off the list based upon a
'' directive in the configuration?).

If the designers of Perl wish to make it a successful 'platform independent'
language, then it really needs to be as flexible as possible. This means the
ability to allow the implementor to decide what's the right way in their
particular instance, and although that may not be the 'recommended' way,
then who are we to tell them that they are wrong. I started as an embedded
systems developer for the 8051, and I know full well what sorts of
limitations a system like that has. And don't kid yourselves, there are
still alot of those systems still chugging away.

Grant M.

Re: Removing stuff to shareable thingies

[Grant M.]

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.

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

[dLux]

/--- 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-enabling requested on
| a per-variable basis.

I prefer that syntax too...

\---

Anyway, think  "local" and "trans"  as _different_, because  these are
for _different_  purposes, and  may the  programmer get  confused. For
example, he cannot use _real_ local variables in a transaction...

dLux
--
mailto:[EMAIL PROTECTED] icq:30329785

Re: Removing stuff to shareable thingies

[Bradley M. Kuhn]

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 gone beyond a subset of
 Perl they sought to stay within.

This is primarily for compiling Perl to be run on embedded devices.
 

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature

how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)

[Bradley M. Kuhn]

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 telephone manufacturer might be putting a JVM
chip in one of their future models.

I would like to be able to compile Perl programs to JVM so that they can run
on such a device.  I don't know if that's as small as a what you mean by
microcontrollers, but it's still pretty small (probably smaller than a PDA,
since RAM on the phone will be taken up by lots of phone-related stuff :).

Of course, all of Perl couldn't be supported, but I'd like to be able to
define a subset of Perl that is permitted, and tell the developer at compile
time that they have stepped out of the subset (see my other post on another
thread for more stuff about that).

My hope is that the perl6 (note case) will be able to provide me the hooks
I'd need to do that.

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature

Re: Optional Separate Programs for Interpreter Passes

[Bradley M. Kuhn]

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
> >each pass ran as its own program, passing the transformed data onto the next
> >pass similarly to the way compilers usually work. 

> 
> This is a good idea, and I've had fuzzy thoughts along this line (more or 
> less) myself. There's a proto-RFC in the works.

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).

This is done in perl5 by STOP blocks, and the mechanism is rather hokey.  I
don't care much myself *how* it is done here, but something non-hokey would
be good.  ;)


-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature