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
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, 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.
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?
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, somewhere
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'd
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 loaded,
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 modules that
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 help
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
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 =
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;
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 IPC man
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 shared memory.
It is
"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 that mmap() was part
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 file system?
"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
TCThe mmap() function maps process addresses to a memory object.
i
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 can be
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 to
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
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
bytes
microperl, which has almost nothing os dependent (*) in it 1212416
shared libperl 1277952 bytes + perl 32768 bytes1310720
dynamically linked perl
On Sun, Aug 27, 2000 at 08:37:38PM +, Nick Ing-Simmons wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
bytes
microperl, which has almost nothing os dependent (*) in it 1212416
shared libperl 1277952 bytes + perl 32768
Lightning flashed, thunder crashed and Steve Fink [EMAIL PROTECTED]
whispered:
| Depends on your definition of "module". Many people seem to be assuming
| "module" eq "shared library".
Yes, exactly. I use module as a generic term for something other than the
main perl binary itself, a black
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if you yank most
That's the basic goal behind my RFCs for moving things to modules. In
general, I hope to make the language cleaner, easier to learn and use, and
easier to extend.
"Clean"? What is "clean"? Huh? And since when has Perl ever been
supposed to be "clean"? I've got plenty of quotage from
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if you yank most of the functions
under discussion. (They're generally trivial wrappers around library calls,
with very little code involved)
Thaniks -- I wish people wouldn't forget
Dan wrote:
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if
Or, more succinctly, we're not going to screw with perl without a *darned*
good reason.
This is the most beautiful thing I've read in days.
--tom
Dan Sugalski writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Larry
Dan Sugalski wrote:
Or, more succinctly, we're not going to screw with perl without a *darned*
good reason.
Well, in the big picture, we *are* screwing with perl, and we know
that we have darned good reason to.
But to apply this metric to every fine-grained aspect of perl5 is silly.
Perl6
Tom Christiansen writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
:
: This is the most beautiful thing I've read in days.
Bear in mind there are lots of darned good reasons. :-)
Larry
Larry Wall wrote:
Dan Sugalski writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Man; leave it to Larry to say the right thing, in the best way. :-)
--
John
But to apply this metric to every fine-grained aspect of perl5 is silly.
Perl6 should be a well-designed, consistent, integrated opus.
If it goes against the grain of perl6's design to have system-specific
system calls built in, then they shouldn't be built in, regardless of
how it was in perl5.
Tom Christiansen wrote:
But to apply this metric to every fine-grained aspect of perl5 is silly.
Perl6 should be a well-designed, consistent, integrated opus.
If it goes against the grain of perl6's design to have system-specific
system calls built in, then they shouldn't be built in,
Well, duh. So what? Did you really miss my point by so many furlongs?
Whatever.
You'll take my fork when you pry it out of my cold, dead hands.
Perl will ship with fork. But maybe in a loadable library, eh?
More of this nonsense, eh? I just fail to understand the urge
to eviscerate. Why
You don't beneficially make Perl any more anything by ghettoizing
its useful systems functionality. You certainly don't make it
more "portable". I still can't use any of my myriad useful systems
hackery script if I try to run them on CP/M, and you aren't going to
change that one whit. So
Tom Christiansen wrote:
Why don't we just say that Perl isn't for
systems work anymore, and remove everything that diddles $!,
or $?, or anything that might call anything from the C library.
As in "remove mountains", yes.
--
John Porter
We're building the house of the future
If the behind-the-scenes shenanigans are invisible and performance is at
worst acceptable, does it really matter how things are implemented?
So long as you can still say things like
perl -le 'print scalar getpwuid(1)'
and that script still continue to work unaltered, then I suppose
Tom Christiansen writes:
: More of this nonsense, eh?
Please don't use fighting words in here.
: I just fail to understand the urge to eviscerate. Why don't we just
: say that Perl isn't for systems work anymore, and remove everything
: that diddles $!, : or $?, or anything that might call
At 11:36 AM 8/25/00 -0600, Tom Christiansen wrote:
If the behind-the-scenes shenanigans are invisible and performance is at
worst acceptable, does it really matter how things are implemented?
So long as you can still say things like
perl -le 'print scalar getpwuid(1)'
and that script
Larry Wall writes:
Tom Christiansen writes:
: More of this nonsense, eh?
Please don't use fighting words in here.
On the subject of fighting words, I owe everyone an apology for my
language on the subject of Perl being the only thing that can parse
Perl. I've been banging my head against
On Fri, Aug 25, 2000 at 09:12:32AM -0400, Stephen P. Potter wrote:
Lightning flashed, thunder crashed and Michael G Schwern [EMAIL PROTECTED] wh
ispered:
| PS The idea of adding acos, asin and tan is good.
You just answered your own question. It is very difficult to add new
functions to
On Fri, Aug 25, 2000 at 09:20:53AM -0400, Dan Sugalski wrote:
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5.
Lightning flashed, thunder crashed and Tom Christiansen [EMAIL PROTECTED]
m whispered:
| More of this nonsense, eh? I just fail to understand the urge
| to eviscerate. Why don't we just say that Perl isn't for
| systems work anymore, and remove everything that diddles $!,
| or $?, or anything
Your coquettish plot to reveal the desperate yearning of your nethermost
alimentary canal for multiply redundant new egresses is neither charming nor
subtle--nor even innovative. Although it would be no great trouble for me
to don the vestments and sharpen the cutlery to serve as haruspex for so
Stephen P. Potter writes:
=head1 TITLE
Perl is Tom's private domain.
That's unproductive.
Nat
And that's offensive.
What's offensive to one person is amusing to the next.
Please act like a grown-up. Stephen cast the
first stone, but that's no excuse for you to reply with a boulder.
Sure it is: when a hoodlum jumps you with a knife, there's no reason
to roll over and quietly submit
Tom Christiansen writes:
: Please act like a grown-up. Stephen cast the
: first stone, but that's no excuse for you to reply with a boulder.
:
: Sure it is: when a hoodlum jumps you with a knife, there's no reason
: to roll over and quietly submit to the death of a thousand cuts.
: No, you pull
Tom Christiansen writes:
further abuse as the next bandit decides to chew on you. As nobody
else said mum about that scat, I took care of it myself.
90 minutes passed on a Friday night. That doesn't mean it wasn't
going to be dealt with.
(hint: grown-ups would apologise at this point)
I'm
Tom Christiansen wrote:
So ripping all this 'cruft' would save us about 100-160 kB, still
leaving us with well over a 1MB-plus executable. It's Perl itself
that's big, not the thin glue to the system functions.
Moreover, if you rip out that 100-160 kb, allocating it to modules,
then I
52 matches
Mail list logo
