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
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 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 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
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
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
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 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
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
>>> 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
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
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
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
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
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
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> But if perl6 bytecode does not need to be modified to be used
I'd assume that.
-- Johan
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 b
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
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
Tom Christiansen <[EMAIL PROTECTED]> writes:
>
>Disastrously, you will then also lose the shared text component,
>which is what makes all this cheap when Perl loads.
But we can on modern OSes have shared data too.
>Since the
>modules will have to be pasted in the data segment of each process
>
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,
>
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)
>
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 pul
>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 subm
Tom Christiansen writes:
> Your coquettish plot to reveal the desperate yearning of your
> nethermost alimentary canal for multiply redundant new egresses is
> neither charming nor
And that's offensive. Please act like a grown-up. Stephen cast the
first stone, but that's no excuse for you to re
Stephen P. Potter writes:
> =head1 TITLE
>
> Perl is Tom's private domain.
That's unproductive.
Nat
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
>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 can guarantee you that it will
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 anythin
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 per
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
> functi
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 agains
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
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 anyt
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 still contin
>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
not--
At 09:39 AM 8/25/00 -0700, Larry Wall wrote:
>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. :-)
You'll notic
At 09:38 AM 8/25/00 -0700, 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.
Hey, look! A good reason! :)
At 10:52 AM 8/25/00 -0600, 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 t
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
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 what
>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.
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,
>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 pe
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 P
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
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.
Perl
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
>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
At 10:53 AM 8/25/00 -0400, [EMAIL PROTECTED] wrote:
>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
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 remove
>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 forg
>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 La
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 mos
Lightning flashed, thunder crashed and Michael G Schwern <[EMAIL PROTECTED]> wh
ispered:
| However, since those funtions take up about 200 lines in the core, are
| very stable and relatively easy to document, what do we win by
| removing them?
|
| PS The idea of adding acos, asin and tan is good
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,
>A friend pointed out, technically most are trigonometric functions,
>not geometric. atan2, cos, sin, acos, asin and tan are all trig.
>exp, log, sqrt are... just math I guess.
>So I suppose the proposed module would be Math::Trig or some such. Or
>maybe, as the source code suggests, Math::High
A friend pointed out, technically most are trigonometric functions,
not geometric. atan2, cos, sin, acos, asin and tan are all trig.
exp, log, sqrt are... just math I guess.
So I suppose the proposed module would be Math::Trig or some such. Or
maybe, as the source code suggests, Math::High:Falu
74 matches
Mail list logo
