- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:20 PM
Subject: RFC 172 (v1) Precompiled Perl scripts.
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>
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
>> bac
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Precompiled Perl scripts.
=head1 VERSION
Maintainer: Slava Pechenin <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 172
Status: Developing
=head1 ABSTRA
On 29 Aug 2000, Russ Allbery wrote:
> I'm not sure I'm completely following what you're arguing for here, but be
> careful not to go too far down the road of duplicating what the dynamic
> loader already knows how to do. There be dragons; that stuff is seriously
> baroque. You really don't want
On 29 Aug 2000, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > It's not unreasonable to expect this sort of feature to possibly be used
> > for more esoteric extensions to the perl core or commonly and heavily
> > used extensions. I wouldn't, for example, want to always loa
David L Nicol <[EMAIL PROTECTED]> writes:
> This is what I was talking about when I suggested the language maintain
> a big list of all the addresses of each function, and after the function
> gets loaded or compiled it is added to the big list, and after this
> stage the placeholder in the op ca
Dan Sugalski <[EMAIL PROTECTED]> writes:
> It's not unreasonable to expect this sort of feature to possibly be used
> for more esoteric extensions to the perl core or commonly and heavily
> used extensions. I wouldn't, for example, want to always load in
> DBD::Oracle or a full complex math libra
On 29 Aug 2000, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > 2) Having a mechanism to automagically load in chunks of executable code
> > only when needed would be nice
>
> It's not clear to me how useful this really is from an internals speed
> standpoint on modern syst
Dan Sugalski <[EMAIL PROTECTED]> writes:
> 2) Having a mechanism to automagically load in chunks of executable code
> only when needed would be nice
It's not clear to me how useful this really is from an internals speed
standpoint on modern systems. It's no longer always true that increasing
th
Dan Sugalski wrote:
>
> 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 resol
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
>
On Tue, Aug 29, 2000 at 07:29:00PM -0400, Uri Guttman wrote:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>
> >> Yup. I think somebody said that mmap() is POSIX. It isn't.
> TC> Are you sure?
>
> TC> http://slacvx.slac.stanford.edu/HELP/POSIX/CALLABLE_FUNCTIONS/MMAP
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Yup. I think somebody said that mmap() is POSIX. It isn't.
TC> Are you sure?
TC> http://slacvx.slac.stanford.edu/HELP/POSIX/CALLABLE_FUNCTIONS/MMAP
TC>The mmap() function maps process addresses to a memory ob
On Tue, Aug 29, 2000 at 05:12:02PM -0600, Tom Christiansen wrote:
> >Yup. I think somebody said that mmap() is POSIX. It isn't.
>
> Are you sure?
Rats, I was wrong. I dug up my copy and mmap(), mlock(), etc are all
in the latest edition of 1003.1.
--
$jhi++; # http://www.iki.fi/jhi/
>Yup. I think somebody said that mmap() is POSIX. It isn't.
Are you sure?
http://slacvx.slac.stanford.edu/HELP/POSIX/CALLABLE_FUNCTIONS/MMAP
The mmap() function maps process addresses to a memory object.
IEEE Std 1003.1b-1993, §12.2.1.
C Format
#include
On Tue, Aug 29, 2000 at 06:43:34PM -0400, Uri Guttman wrote:
> > "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
>
> ST> On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
> >> David L . Nicol <[EMAIL PROTECTED]> writes:
> >> >
> >> >does sysV shm not support the equivalent security as the f
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
ST> On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
>> David L . Nicol <[EMAIL PROTECTED]> writes:
>> >
>> >does sysV shm not support the equivalent security as the file system?
>>
>> mmap() has the file system.
ST> I wasn't aware
(I didn't think to respond to this until I saw a later response from dlux.)
Ken Fox wrote:
>
> try transaction {
> ...
> }
>
> That's a really interesting extension to exceptions -- code that has
> no side-effects unless it finishes.
Well, maybe transaction-enabling variables could
as abigail says, the bug is in line 17 (and that depends on how you
rewrap that text).
:)
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http:/
/--- On Tue, Aug 29, 2000 at 04:18:57PM -0400, John Porter wrote:
| > I was thinking about this same problem while reading RFC 130. It
| > seems
| > like transactions and exceptions are closely related. Should we
| > combine
| > the two?
| > try transaction {
| > ...
| > }
How woul
>>> mmap() has the file system.
>>I wasn't aware that mmap() was part of SysV shared memory.
>It is NOT. It is another (POSIX) way of getting shared memory bewteen
>processes. Even without MAP_SHARED OS will share un-modified pages
>between processes.
...
>SysV IPC is a mess IMHO.
For a go
Sam Tregar <[EMAIL PROTECTED]> writes:
>On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
>> David L . Nicol <[EMAIL PROTECTED]> writes:
>> >
>> >does sysV shm not support the equivalent security as the file system?
>>
>> mmap() has the file system.
>
>I wasn't aware that mmap() was part of SysV share
On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
> David L . Nicol <[EMAIL PROTECTED]> writes:
> >
> >does sysV shm not support the equivalent security as the file system?
>
> mmap() has the file system.
I wasn't aware that mmap() was part of SysV shared memory. My
mistake? It's not on the SysV IP
Ken Fox wrote:
>
> I was thinking about this same problem while reading RFC 130. It seems
> like transactions and exceptions are closely related. Should we combine
> the two?
>
> try transaction {
> ...
> }
>
> That's a really interesting extension to exceptions -- code that has
> no s
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;
David L . Nicol <[EMAIL PROTECTED]> writes:
>
>does sysV shm not support the equivalent security as the file system?
mmap() has the file system.
>
>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_indepen
On Tue, 29 Aug 2000, David L. Nicol wrote:
> does sysV shm not support the equivalent security as the file system?
Well, no, I don't think it does. It supports permissions on individual
segments but it doesn't support anything like directory perimssions. It
might be enough, and it might not be
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
Chaim Frenkel wrote:
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
> SF> Or what about a variable attribute:
>
> SF> my $x : transactional
>
> SF> and making the effect completely lexical? Why would other scopes need to
> SF> see such variables?
>
> You haven't handled the multiple var
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED]
m> whispered:
| Very well, then: I'll save it for an after-the-fact I-TOLD-YOU-SO,
| which, believe it or not, is truly *not* a pleasant thing to be
| able to say.
Tom, we appreciate your constructive comments and your hel
On Tue, Aug 29, 2000 at 12:50:46PM -0600, Tom Christiansen wrote:
> Henry Spencer once used some Larry-code (rn, actually) as a poster-child
> for his "#ifdef Considered Harmful" talk.
I can't argue with that, but actually the bulk of that monstrosity was
Richard-code, it was courtesy of gcc's me
Folks,
I think at this point we've beaten this one to death. The obvious
conclusions seem to be:
1) Removing all functions that do X (whatever X is) may or may not buy us
anything
2) Having a mechanism to automagically load in chunks of executable code
only when needed would be nice
3) It'd b
Henry Spencer once used some Larry-code (rn, actually) as a poster-child
for his "#ifdef Considered Harmful" talk.
--tom
Sam Tregar wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text? Perhaps the first instance of perl sets up some vast shared
> > memory segments and a way for the newcomers to link in to it and look
> > at the modu
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>On Tue, Aug 29, 2000 at 01:46:17AM -, [EMAIL PROTECTED] wrote:
>>
>> This is a build failure report for perl from [EMAIL PROTECTED],
>> generated with the help of perlbug 1.32 running under perl v5.7.0.
>
>Now I tracked this one down (change #689
On Tue, 29 Aug 2000, Sam Tregar wrote:
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text?
> I don't believe you can simply "rearchitect it to make it shared text".
That depends on what the meaning of "it" is. :-)
If "
At 12:02 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Well then. It is impossible to rearchitect it to make it shared
> >text? Perhaps the first instance of perl sets up some vast shared
> >memory segments and a way for the newcomers to link in to it and look
> >at the modules that have been loa
>Well then. It is impossible to rearchitect it to make it shared
>text? Perhaps the first instance of perl sets up some vast shared
>memory segments and a way for the newcomers to link in to it and look
>at the modules that have been loaded, somewhere on this system, and use
>the common copy?
I
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
On Tue, 29 Aug 2000, David L. Nicol wrote:
> Well then. It is impossible to rearchitect it to make it shared
> text? Perhaps the first instance of perl sets up some vast shared
> memory segments and a way for the newcomers to link in to it and look
> at the modules that have been loaded, somewh
David L. Nicol writes:
> This handwringing naysaying is depressing.
Yes, it's depressing to find out there are problems in one's grand
plans. However, I'm very glad that people (including Tom) are
pointing out problems *before* we commit to a course of action.
Nat
Well then. It is impossible to rearchitect it to make it shared
text? Perhaps the first instance of perl sets up some vast shared
memory segments and a way for the newcomers to link in to it and look
at the modules that have been loaded, somewhere on this system, and use
the common copy?
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
43 matches
Mail list logo
