Re: RFC 146 (v1) Remove socket functions from core
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
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
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
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: how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)
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
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.
how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)
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: RFC 146 (v1) Remove socket functions from core
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. 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." If a dependent module knows what it depends on, that module can be loaded on demand for the dependent one. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Yum, sidewalk eggs!
RE: RFC 146 (v1) Remove socket functions from core
>>BTW, I have access to Rational Software's Quantify (and PureCoverage and >>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. > >If you want to get "in the mood" it would be good to fire it up on >(say) perl5.6.0 and see where the hot-spots are. Planning on it as part of my upcoming perlhack doc patch on tools for debugging/testing perl. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
RE: RFC 146 (v1) Remove socket functions from core
Fisher Mark <[EMAIL PROTECTED]> writes: >>Leaping to conculusions based on no tests at all is even worse... >> >>Will anyone bite the bullet and write the "Internals Decisions should >>be based on actual tests on multiple platforms" RFC ? > >BTW, I have access to Rational Software's Quantify (and PureCoverage and >Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. If you want to get "in the mood" it would be good to fire it up on (say) perl5.6.0 and see where the hot-spots are. >=== >Mark Leighton Fisher[EMAIL PROTECTED] >Thomson Consumer ElectronicsIndianapolis IN >"Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_ -- Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
It's been strongly indicated that removing sockets (as well as any other Perl functions that are little but wrappers around libc calls) will not meaningfully reduce the size of Perl nor increase its speed. Various VM issues have been discussed, including risks of deadly embrace and egregious performance problems resulting from the running of numerous instantiations on some architectures. A simple run-once test on a single target platform, or even several, will not bring these matters to light. but this will all have to be addressed in exploring what can or cannot be done. That leaves the deceptively appealing argument that "it will be easier to port Perl without them". This is trotted out as a strong argument, but in fact, it is the weakest amongst them. That's because it is not at *all* true! Why? Because HAS_SOCKET already takes care of that for sockets. If the system has them, then they're compiled in. If it doesn't, then trying to call that function raises an exception at run-time. You do not make the perl binary more portable by getting rid of sockets. The build process already considers their availability. And you do not make Perl scripts more portable, either, because if sockets aren't available, that socket-diddling script is doomed anyway. At last check, the following built-in functions in theory can, on various unfriendly systems, raise "unimplemented" exceptions: alarm bind chown chroot closedir connect crypt dbmclose dbmopen fcntl flock fork getgrent getgrgid getgrnam gethostbyaddr gethostbyname gethostent getlogin getnetbyaddr getnetbyname getnetent getpeername getpgrp getppid getpriority getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid getservbyname getservbyport getservent getsockname getsockopt ioctl kill link listen lstat msgctl msgget msgrcv msgsnd open opendir pipe readdir readlink readpipe recv rewinddir seekdir select semctl semget semop send setpgrp setpriority setsockopt shmctl shmget shmread shmwrite shutdown socket socketpair symlink syscall telldir times truncate umask utime wait waitpid There may be other justifications for doing so, but contrary to popular belief, migrating these functions into modules will *not* affect the portability of either perl the program or of one's Perl scripts. So this portability talk should not be used to justify the act--it's a red herring. The /usr/bin/perl binary itself already detects and/or emulates the underlying functions at build time, so it is neither more nor less portable, and the scripts themselves have little recourse if something critical isn't there. If they care, they can always test for this either via %Config::Config or, perhaps, through the old C strategy. Perhaps something clearer could be devised there, like perhaps C (or would that be defined?). Seems to me Nick said something about making all these builtins work just like real functions, and that should follow. This requires a bit of -internals work though, more than it does -language work. Well, unless we wanted use CORE qw/socket bind connect listen/; to do the exists() test on all those. I know that I've long wished for POSIX to, at import time, verify that the things asked for were actually there, as at this time, it doesn't tell you up front at compile-time, even with the import, but not till way later upon calling the function. This, too, will require -internals changes if it is to be addressed. --tom
RE: RFC 146 (v1) Remove socket functions from core
>Leaping to conculusions based on no tests at all is even worse... > >Will anyone bite the bullet and write the "Internals Decisions should >be based on actual tests on multiple platforms" RFC ? BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 146 (v1) Remove socket functions from core
Michael G Schwern <[EMAIL PROTECTED]> writes: >Like all other optimizing attempts, the first step is analysis. >People have to sit down and systematically go through and find out >what parts of perl (and Perl) are eating up space and speed. The >results will be very surprising, I'm sure, but it will give us a >concrete idea of what we can do to really help out perl's performance. > >There should probably be an RFC to this effect, and I'm just visiting >here in perl6-language so I dump it on somebody else. Alan Burlison <[EMAIL PROTECTED]> writes: >Drawing conclusions based on a single test can be >misleading. Leaping to conculusions based on no tests at all is even worse... Will anyone bite the bullet and write the "Internals Decisions should be based on actual tests on multiple platforms" RFC ? -- Nick Ing-Simmons
RE: RFC 146 (v1) Remove socket functions from core
Al Lipscomb <[EMAIL PROTECTED]> writes: >I wonder if you could arrange things so that you could have statically >linked and dynamic linked executable. Kind of like what they do with the >Linux kernel. When your installation is configured in such a way as to make >the dynamic linking a problem, just compile a version that has (almost) >everything bolted in. Otherwise compile the features as modules. If we make it possible to move socket or math functions out of execuable into "overlays" then there will always be an option NOT to do that and build one executable - (and that will probably be the default!). 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. Tk has these "overlays" - I think DBI has something similar. perl5 itself does not as such (although POSIX.so is close). _I_ would like to see RFC 146 mutate into or be replaced by an RFC which said perl should have a mechanism to allow parts of functionality to be split out into separate binary (sharable) files. -- Nick Ing-Simmons
RE: RFC 146 (v1) Remove socket functions from core
I wonder if you could arrange things so that you could have statically linked and dynamic linked executable. Kind of like what they do with the Linux kernel. When your installation is configured in such a way as to make the dynamic linking a problem, just compile a version that has (almost) everything bolted in. Otherwise compile the features as modules.
Re: RFC 146 (v1) Remove socket functions from core
[EMAIL PROTECTED] wrote: > Dynamic loading can be noticeably slow if you are loading something > via NFS. In addition the PIC code and jump tables used for dynamic > linking result in a 10-15% slowdown in execution speed on SunOS and > Solaris (at least in my experiments). Not what I'd call really slow, but > we've complained vigorously about smaller slowdowns. This is probably all true. However what you are not taking into account is the overall improvements in system performance due to the fact that the shared libraries are only held in memory once (yes I know some bits of a .so may not be shared, but most of it is). Paging involves disks, and they are orders of magnitude slower than the dynamic linking overhead. Repeat the excercise with a couple of hundred concurrent copies of your test. Drawing conclusions based on a single test can be misleading. -- Alan Burlison
Re: RFC 146 (v1) Remove socket functions from core
Dan Sugalski wrote: > This is actually one of the spots I'm hoping to pick up a win from--if the > only code that links against the system socket library is in the code > that's not loaded by default, then that means one fewer system library to load. > > Granted, odds are the library's in memory already, but we don't have to map > it, and we don't need to do symbol resolution, and we generally just don't > need to mess with it. Most modern runtime linkers do lazy linking, so references aren't resolved until called. On Solaris the runtime linker patches itself in to the PLT, so that the first time a function is called it is resolved. Uncalled functions aren't linked. I think you'll be dissapointed by the difference. > Big win? No. Small one. But for code that just rips through a disk file or > something piped in on stdin, it might mean a few milliseconds shaved off > startup. You already have this win: # Force symbol resolution on startup $ LD_BIND_NOW=1 ptime perl -e 'exit(0)' real0.029 user0.021 sys 0.007 # Default lazy linking $ ptime perl -e 'exit(0)' real0.019 user0.010 sys 0.007 Alan Burlison
Re: RFC 146 (v1) Remove socket functions from core
On Fri, Aug 25, 2000 at 09:12:19AM -0400, Dan Sugalski wrote: > At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: > >Isn't dynamic loading really slow? > > Not particularly, at least not as far as I know. There's some extra cost in > finding the library and loading it that you wouldn't pay if you were linked > directly to it, but AFAIK that's about it. Dynamic loading can be noticeably slow if you are loading something via NFS. In addition the PIC code and jump tables used for dynamic linking result in a 10-15% slowdown in execution speed on SunOS and Solaris (at least in my experiments). Not what I'd call really slow, but we've complained vigorously about smaller slowdowns. -- Ed Mooring
Re: RFC 146 (v1) Remove socket functions from core
Well, *that* was certainly an interesting evening of emails to wade
through tonight.
On Fri, 25 Aug 2000, Dan Sugalski wrote:
> Bingo! That's it in a nutshell. And every single thing that could possibly
> need to be figured out would be done ahead of time so there's as little
> overhead as possible. (I'm even pondering the possibility of jamming the
> table with the potential functions and their associated information into a
> shareable image so we don't even need to parse a text file--it's already
> predigested and available)
>
Picking a random entry location for some -internals work, and Dan's post
wins.
To expand (or condense) a couple of other suggestions (read
these with an implicit question mark on the end) - perl should have a
master index that it reads in on startup. This index would/could
contain easy-to-digest locational information for perl - a combo
super-stash and manifest, all-in-one.
It would record something like (only, of course, this is English):
CODE,grep,CORE,{other info?}
CODE,cos,Math::Trig::cos,{other info?}
PACKAGE,Math::Trig,/usr/local/perl/lib/.../.../.../Trig.so,1.2
OTHER TYPES?
Perl does a quick look-up here for (unresolved symbol) package
determination (and maybe quick package location resolution, etc, etc.)
which it would pull-in automagically. (Run-time overloading of
opcodes?)
Modules could define what functions, etc, would be manifested, which
would ultimately be a make arg. (As you don't want to throw
*everything* in the manifest.) The base functions from Perl 5 would be
manifested during the Perl 6 build automatically. Later versions,
modules, etc, could overwrite the manifest/index to force a new version.
(Which could be very fuggly later on in life.)
package Math::Trig;
...
@INDEX = qw/sin cos tan asin acos atan/;
...
1;
Whammo 34> make install
Installing Math::Trig to /usr/lib/perl/.../.../.../
(but no manifest, so use Math::Trig would be required.)
Whammo 35> make index
Updating /usr/lib/perl/plidx.so with Math::Trig
Auto-use for sin cos tan asin acos atan.
And later.
package MyMath::Trig;
...
@INDEX = qw/sin cos tan/;
...
1;
Whammo 334> make install
Installing MyMath::Trig to /usr/lib/perl/.../.../.../
(but no manifest, so use MyMath::Trig would be required, and a simple
'sin' or 'cos' would invoke the Math::Trig versions.)
Whammo 335> make index
Updating /usr/lib/perl/plidx.so with MyMath::Trig
Auto-use for sin cos tan.
So now a bare 'sin' or 'cos' would invoke MyMath::Trig::sin or ::cos,
but still leave Math::Trig::atan and ::asin.
A 'use Math::Trig' or 'use MyMath::Trig' would follow the regular rules
of exporting, etc. (No export, look for the default.)
There are a couple other uses I can think of something like this for,
but the grand question is.
Is this (what|one of the things) we're talking about?
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 146 (v1) Remove socket functions from core
At 07:45 PM 8/25/00 +, Nick Ing-Simmons wrote: >The issue would be if you did two searches - one for Socket.so and then >_that_ had to go look for libsocket.so >So if the code is really just a thin wrapper on the system library then >taking it out will be a (small) performance hit. This is actually one of the spots I'm hoping to pick up a win from--if the only code that links against the system socket library is in the code that's not loaded by default, then that means one fewer system library to load. Granted, odds are the library's in memory already, but we don't have to map it, and we don't need to do symbol resolution, and we generally just don't need to mess with it. Big win? No. Small one. But for code that just rips through a disk file or something piped in on stdin, it might mean a few milliseconds shaved off startup. 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
At 08:29 PM 8/25/00 +, Nick Ing-Simmons wrote: >Benjamin Stuhl <[EMAIL PROTECTED]> writes: > >AUTOLOAD searches are not cheap either. It can take a lot > >of stat() calls to even _find_ the correct module, much > >less load it. The average math function in the perl5 core > >is about 13 lines of C code. Eviscerating it out of the > >core would accomplish nothing. > >And that is _NOT_ what is being proposed. >What I envisage is more like "overlays" of the 16-bit era - >tightly coupled binaries which are stored alongside 'perl' >in what ever place is the "easiest to find" way for the platform. Bingo! That's it in a nutshell. And every single thing that could possibly need to be figured out would be done ahead of time so there's as little overhead as possible. (I'm even pondering the possibility of jamming the table with the potential functions and their associated information into a shareable image so we don't even need to parse a text file--it's already predigested and available) 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
At 09:28 PM 8/25/00 +0200, Bart Lateur wrote: >On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote: > > >Code you don't call won't eat up any cache space, nor crowd > >out some other code. And if you do call it, well, it ought to be in the > cache. > >Probably a stupid question... But can't you group the code for the most >often used constructs? So that, if one of those things is loaded in the >cache, the others are in there with it? Sure, and as Nick's already said, perl 5 did that. How much of a win grouping is depends on the chunks fetched into cache. Data usually goes into the processor cache in small pieces--8 or 16 bytes at a time. The off-chip cache usually is loaded in larger pieces, but the size of those depends on the processor you're talking about. Given the size of many of perl 5's opcode functions, I'm not sure grouping's really a win for code. That may change some for perl 6, though. 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
Bart Lateur <[EMAIL PROTECTED]> writes: >On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote: > >>Code you don't call won't eat up any cache space, nor crowd >>out some other code. And if you do call it, well, it ought to be in the cache. > >Probably a stupid question... But can't you group the code for the most >often used constructs? We can - and we will once we know what the "often used constructs" will be in perl6. Larry started will with pphot.c in perl5 - but over the years the bells and whistles have got tacked on where it seemed easiest and now perl5 needs a re-write to clean it up - perl6 will be that thing but while perl5 runs a language called Perl5, perl6 (being defined here) will run a language called Perl6 - being defined on [EMAIL PROTECTED] >So that, if one of those things is loaded in the >cache, the others are in there with it? That is the first approximation to what happens - but it is a start... > >If all the less needed stuff is more at the back of the executable, it >wouldn't even have to be loaded, most of the time. > >Besides, I'm more worried about unnecessarily loading 600k from disk, >than from main memory to cache. For short-lived scripts, this loading >overhead could be quite significant. Most mordern (and sane) OSes will keep "useful" pages in memory till they need them for something else. This would be _the_ win for true byte-compiled (not modified at runtime) scripts/modules - those pages would not be re-loaded either. -- Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>
>It probably would. Dynamic loading is not cheap, and having
>to do a dlopen() and a dlsym() (or a LoadLibrary() and a
>GetProcAddress()) to find out the square root of 2 is not
>my idea of a _useful_ lightweight programing language.
But if you add -lm to your perl link line then ld.so will
do almost exactly that for every run of perl even if it does not
do any sqrt()s. (Well actually only the dlopen() - the dlsym()
is done by a stub function...)
...
>
>AUTOLOAD searches are not cheap either. It can take a lot
>of stat() calls to even _find_ the correct module, much
>less load it. The average math function in the perl5 core
>is about 13 lines of C code. Eviscerating it out of the
>core would accomplish nothing.
And that is _NOT_ what is being proposed.
What I envisage is more like "overlays" of the 16-bit era -
tightly coupled binaries which are stored alongside 'perl'
in what ever place is the "easiest to find" way for the platform.
So when you see your 1st sqrt the stub function table does
in (C/perl hybrid pseudo code):
mathtable = (mathtable_t) dlsym(dlopen("$^X.math.pld"),"mathFunctions");
return (mathtable.sqrt)(@_);
_Iff_ this perl has not got them "linked in".
>
>Slowing perl down and forcing everyone to add 5 "use"
>statements to the top of every program to get any useful
>features would neither make it more useful or more fun.
This is the _INTERNALS_ list - "use" statements don't live here.
--
Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
Benjamin Stuhl <[EMAIL PROTECTED]> writes: > >There's also the issue that _each_ symbol must be requested >manually and stored somewhere (in a MT-safe manner, of >course), That is not the right way to do it. (I have seen the Tcl loader and I think it is ugly.) The loadable would export _one_ symbol - that of a table of functions. (Which is what DBI and Tk do and have since perl5.001m or so...) -- Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
>Besides, I'm more worried about unnecessarily loading 600k from disk, >than from main memory to cache. For short-lived scripts, this loading >overhead could be quite significant. Why should that matter? Your kernel's VM system should compensate. It's not like running a 3-line program really reloads all those text pages. I think we're all past the chmod +t days. % repeat 20 time perl -e 0 0.000u 0.018s 0:00.01 100.0%0+0k 0+0io 0pf+0w 0.006u 0.012s 0:00.00 0.0% 0+0k 0+0io 0pf+0w 0.006u 0.013s 0:00.01 100.0%0+0k 0+0io 0pf+0w 0.020u 0.000s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.000u 0.020s 0:00.01 200.0%0+0k 0+0io 0pf+0w 0.006u 0.013s 0:00.02 50.0% 0+0k 0+0io 0pf+0w 0.006u 0.013s 0:00.01 100.0%0+0k 0+0io 0pf+0w 0.009u 0.009s 0:00.01 0.0% 0+0k 0+0io 0pf+0w 0.010u 0.010s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.000u 0.020s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.006u 0.013s 0:00.01 100.0%0+0k 0+0io 0pf+0w 0.010u 0.010s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.000u 0.019s 0:00.02 50.0% 0+0k 0+0io 0pf+0w 0.010u 0.010s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.010u 0.010s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.013u 0.006s 0:00.02 50.0% 0+0k 0+0io 0pf+0w 0.006u 0.013s 0:00.01 100.0%0+0k 0+0io 0pf+0w 0.000u 0.020s 0:00.02 100.0%0+0k 0+0io 0pf+0w 0.009u 0.009s 0:00.00 0.0% 0+0k 0+0io 0pf+0w 0.000u 0.020s 0:00.02 100.0%0+0k 0+0io 0pf+0w --tom
Re: RFC 146 (v1) Remove socket functions from core
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: >>Dan Sugalski writes: >> > One of the current plans is for the parser to have access to a list of >> > functions that trigger autoloading modules. >> >>Isn't dynamic loading really slow? > >Not particularly, at least not as far as I know. There's some extra cost in >finding the library and loading it that you wouldn't pay Unless you really messup the search it will be comparable to the search system does (LD_RUN_PATH etc.) to find "linked in" dynamic libraries. The issue would be if you did two searches - one for Socket.so and then _that_ had to go look for libsocket.so So if the code is really just a thin wrapper on the system library then taking it out will be a (small) performance hit. But it does mean we can plug in IPv7 in a twinkling, or a stub that re-directs network traffic via the Furbie's infra-red link to the toaster... -- Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
Nathan Torkington wrote: > > moving getprotobyname() >to a module isn't the same as moving open(). And it can be transparent, if it isn't already. Why does perl need to be monolithic? I thought I selcted to build as shared libraries, splitting that into several shared libraries might be entirely painless. So if my program has getprotobyname in it clarifying that token will take a moment, but then all the other weird socket calls will be there to use. How about automatic library search before syntax error? -- David Nicol 816.235.1187 [EMAIL PROTECTED] safety first: Republicans for Nader in 2000
Re: RFC 146 (v1) Remove socket functions from core
On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote: >Code you don't call won't eat up any cache space, nor crowd >out some other code. And if you do call it, well, it ought to be in the cache. Probably a stupid question... But can't you group the code for the most often used constructs? So that, if one of those things is loaded in the cache, the others are in there with it? If all the less needed stuff is more at the back of the executable, it wouldn't even have to be loaded, most of the time. Besides, I'm more worried about unnecessarily loading 600k from disk, than from main memory to cache. For short-lived scripts, this loading overhead could be quite significant. -- Bart.
Re: RFC 146 (v1) Remove socket functions from core
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes: CF> I made the suggestino a while back, that if this is true for core. It CF> might be feasible for non-core modules (assuming some sort of registry) CF> so that an implicit use might be performed. i am proposing such a registry which is a pragma you use to load in groups of namespaces just like with @IMPORT_OK and :standard groupings. this serves 2 purposes, it tells the compiler which names are to be placed in the function symbol table. the name groups could be 'sockets', 'math', etc. and it may optionally load them from a library (which could be in multiple forms). so with one simple pragma we can simplify the namespace and still get full backwards compatibility support. and we can control how real code is loaded on an as needed basis. a given perl binary could be created with various parts designated as always in and others are dynamically loaded. this can be done at build time or even at run time with some special startup file which could be triggered by a command line option. 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
Re: RFC 146 (v1) Remove socket functions from core
>I'm not sure that we are talking about the same thing. Probably not. >So if socket() is removed from the core (the executable). Perl upon >noticing a socket() without a user specified use that might override >it. Will transparently make it available along with all the associated >constants. I've read these all as "remove from CORE::", which is seriously scarier. This is rather different. I don't see why anyone would care, module performance, whether for example using dbmopen autoloads Any_DBMFile or whatnot. Just try reading through the last N-thousand of these messages. Things blend together, and the overall impression is one of, well... you'll have to draw your own conclusions. --tom
Re: RFC 146 (v1) Remove socket functions from core
At 02:48 PM 8/25/00 -0400, Chaim Frenkel wrote: >My understanding of -internals (and Dan) is that all the current perl >(or whatever Larry leaves) will continue to be there. It is an internals >issue where it really lives. > >So if socket() is removed from the core (the executable). Perl upon >noticing a socket() without a user specified use that might override >it. Will transparently make it available along with all the associated >constants. This is the case, yep. >I made the suggestino a while back, that if this is true for core. It >might be feasible for non-core modules (assuming some sort of registry) >so that an implicit use might be performed. Yup, that's what I'm thinking of as well. It might as well be available to everyone if it's available to the core. (And yes, I'm ignoring versioning issues here too... :) I think it's time for me to go missing for a while and finish the RFC that details what I'm thinking about for this... 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
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> Perl is *not* fun when it supplies nothing by default, the way C does(n't). TC> If you want a language that can do nothing by itself, fine, but don't TC> call it Perl. Given these: I'm not sure that we are talking about the same thing. My understanding of -internals (and Dan) is that all the current perl (or whatever Larry leaves) will continue to be there. It is an internals issue where it really lives. So if socket() is removed from the core (the executable). Perl upon noticing a socket() without a user specified use that might override it. Will transparently make it available along with all the associated constants. If a performance hit arises, then -internals will address the issue. But nothing in the language will change. I made the suggestino a while back, that if this is true for core. It might be feasible for non-core modules (assuming some sort of registry) so that an implicit use might be performed. (I'm ignoring the problems of multiple versions or multiple conflicting routines of the same name.) Are we still far apart? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 146 (v1) Remove socket functions from core
Fisher Mark writes: : > For instance, if I'm running Perl on my Palm, I'd just as soon that : > index() were implemented in Perl using repeated substr() comparisons. : : How small do we really need to go? It's not so much a matter of small as a matter of pluggable. But small will continue to be important. I think microcontrollers will keep getting smaller and smaller physically, which will tend to keep down the amount of memory they can have. In 20 years we may have nanocomputers that are limited to 2 megs... But the pluggable is important for scaling up as well. Consider pluggable string methods for multiple string encodings. A small Perl might just coerce all encodings into utf8 or utf16 or whatever. A medium Perl might put separate implementations for several different string types, and use a common intermediate type such as utf8 or utf16 for conversions. A large Perl might put in a complete crossbar that can convert any string type directly to any other. All hand coded in assembler for the Pentium 18. Larry
Re: core wars (was Re: RFC 146 (v1) Remove socket functions from core)
At 02:06 PM 8/25/00 -0400, Uri Guttman wrote: >i like that. but is that only platform implementation specific? i see a >possibility of requesting (via a pragma) an alternative implementation of >binary (see i used the new term!). I'd like to get overridable opcode functions and function functions into perl 6. Whether (or how) that happens depends mainly on the speed penalty the overriding costs. 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
> For instance, if I'm running Perl on my Palm, I'd just as soon that > index() were implemented in Perl using repeated substr() comparisons. 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? The difference is that PDAs are now shipping with much greater amounts of memory than they first started with. For example, my 2-year-old Palm III only had 2M of RAM, which isn't much RAM when perl consumes around 1M or so. But my new Handspring Visor comes with 8M, which looks much more reasonable for perl (and Perl). On the other hand, microcontrollers still don't have a lot of RAM, at least as compared to PDAs. I think there are a number of microcontrollers sold today that don't ship with even 1M of RAM or ROM, although there are multi-Meg microcontrollers now. And on the gripping hand -- well, that's Larry's, anyway. Just my $0.02US. Mark Leighton FisherThomson Consumer Electronics [EMAIL PROTECTED] Indianapolis, IN, USA "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 146 (v1) Remove socket functions from core
Tom Christiansen writes: : >Hard things should be easy, easy things should be trivial. We should try : >to keep the stuff that is commonly used in the core (excluding OS : >dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(), : >for instance). : : That's their problem. Perl is extremely useful to Unix systems : programmers and administrators. They are the target audience : that Perl was initially written for, whom it was made famous by, : and you will find that it continues to be very important to us. : If you relegate us to take a back seat behind a mob of Billduhs, : then you have betrayed your history and really pissed a lot of : people off. Please don't monger these fears. I am a Unix systems administrator. I don't see much of a problem leaving getpwent in the core language but out of the core implementation. The issue of preserving the semantics of one-liners is a known design constraint. We are now beating a dead unicorn. Please move it to the -language list. Larry
core wars (was Re: RFC 146 (v1) Remove socket functions from core)
i cc'ed to language as this issue spans then as well as internals. > "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> We're fighting multiple definitions of "core" here. Please distinguish LW> the core of the language from the core of the implementation--they're LW> two entirely different things. What we're attempting to do here is LW> make it *not matter* whether something is in the core implementation or LW> not. This gives us a great deal of freedom in how to implement the LW> core of the language. the language vs. implementation core confusion has hit before. could we come up with better terms which are not so overloaded? i suggest we drop the use of core altogether for now and pick new terms. here are some ideas: the Perl language base features the perl binary/image/executable/main i would use object but that is WAY too overloaded. i am sure we can pick a pari of terms which are short and reflect our usage. we have too much linguistic power on these lists to fight over core vs. core. LW> This should all be transparent at the language level. Certainly LW> index() will continue to be supported in the core language. But it LW> almost certainly belongs outside the core implementation. i like that. but is that only platform implementation specific? i see a possibility of requesting (via a pragma) an alternative implementation of binary (see i used the new term!). something like this: use library qw(Quantum::sort) ; which would load the sort implementation with damian's constant time sort and overload the sort function as well. my advanced I/O rfc (to be released soon) uses something like that to appease the language minimalists (sockets out of base language) and the binary minimalists (sockets loaded as desired). 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
Re: RFC 146 (v1) Remove socket functions from core
>I would like to see a set of "requirements" that make Perl what it is. >I think we all have a vague idea of what makes Perl great, but I'm also >sure there's a lot of variation. With a SHORT list of requirements, it >becomes much easier to address some of these issues that are radical >changes to the language. That's a very good idea. Many if not most of these radical "let's make a new language" postings mostly just keep making Python and Java look better and better. If you strip out the Perlishness from Perl, there's really no reason to bother with the language anymore. --tom
Re: RFC 146 (v1) Remove socket functions from core
Joe McMahon writes: : On Thu, 24 Aug 2000, Stephen P. Potter wrote: : : > I have several RFCs I need to write about removing certain functionality : > out of the core (math functions, IPC, networking, "user"). I don't want to : > go too overboard. I don't know that we want to go so far as to remove : > printing and such. It might be nice to generalize some functions (like the : > discussion with open() that happened awhile back). : : Hard things should be easy, easy things should be trivial. We should try : to keep the stuff that is commonly used in the core (excluding OS : dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(), : for instance). In my opinion, Perl6 should still be a language in which : it is easy to write powerful and useful programs on the command line. We're fighting multiple definitions of "core" here. Please distinguish the core of the language from the core of the implementation--they're two entirely different things. What we're attempting to do here is make it *not matter* whether something is in the core implementation or not. This gives us a great deal of freedom in how to implement the core of the language. For instance, if I'm running Perl on my Palm, I'd just as soon that index() were implemented in Perl using repeated substr() comparisons. Yes, that's slower than the C implementation, but the representation is much more compact, and might have a hope of getting shoehorned into a small memory. A Perl distribution might implement index() much as it does now in portable (more-or-less) C. A distribution intended for a high-powered server of known architecture might substitute in a hand-coded assembler version of index(). A JVM implementation might call out to some core JVM routine. An .NET implementation might delegate indexing to some object running on index.microsoft.com. :-) This should all be transparent at the language level. Certainly index() will continue to be supported in the core language. But it almost certainly belongs outside the core implementation. Larry
Re: RFC 146 (v1) Remove socket functions from core
>Hard things should be easy, easy things should be trivial. We should try >to keep the stuff that is commonly used in the core (excluding OS >dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(), >for instance). That's their problem. Perl is extremely useful to Unix systems programmers and administrators. They are the target audience that Perl was initially written for, whom it was made famous by, and you will find that it continues to be very important to us. If you relegate us to take a back seat behind a mob of Billduhs, then you have betrayed your history and really pissed a lot of people off. --tom
Re: RFC 146 (v1) Remove socket functions from core
At 01:34 PM 8/25/00 -0400, Joe McMahon wrote: >In my opinion, Perl6 should still be a language in which >it is easy to write powerful and useful programs on the command line. A very nice opinion it is, too. I fully agree. It lies, however, within the purview of the -language list, not -internals... 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
On Thu, 24 Aug 2000, Stephen P. Potter wrote: > I have several RFCs I need to write about removing certain functionality > out of the core (math functions, IPC, networking, "user"). I don't want to > go too overboard. I don't know that we want to go so far as to remove > printing and such. It might be nice to generalize some functions (like the > discussion with open() that happened awhile back). Hard things should be easy, easy things should be trivial. We should try to keep the stuff that is commonly used in the core (excluding OS dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(), for instance). In my opinion, Perl6 should still be a language in which it is easy to write powerful and useful programs on the command line. --- Joe M.
Re: RFC 146 (v1) Remove socket functions from core
Tom Christiansen wrote: > > >I don't understand this desire to not want anything to change. > > You misread. > > >This is an > >opportunity to clean up the language, make it more useable, and more fun. > >I would have a lot more fun if perl were a better performer and if it was > >easy for me to expand it, contract it, reshape it, improve it, etc. > > Bah. You start from false premises, and go on to fantasize > bucolically about motherhood and apple pie. > > You will *not* improve the performance of the inner interpreter > loop by having fewer opcodes to switch on. Whether the number is > 20 or 200, it's the same thing--*think* aboutit. Furthermore, It's > been demonstrated that this supposed "gain", including in size, is > negligible. I have yet to see one iota of justification for denuding > perl of its math functions. If math functions should be removed, > then so too string functions. And that binmode silliness is in > line before any of them, since it's absolutely useless because I > never use it. > > See what I mean? > > Perl is *not* fun when it supplies nothing by default, the way C does(n't). > > If you want a language that can do nothing by itself, fine, but don't > call it Perl. Given these: > > * Scalar manipulation > * Regular expressions and pattern matching > * Numeric functions > * Array processing > * List processing > * Hash processing > * Input and output > * Fixed-length data and records > * Filehandles, files, and directories > * Flow of program control > * Scoping > * Miscellaneous > * Processes and process groups > * Library modules > * Classes and objects > * Low-level socket access > * System V interprocess communication > * Fetching user and group information > * Fetching network information > * Time > > Your brain-damaged Perl would likely end up having nothing in it but these: > > * Flow of program control > * Scoping > > Anything else would be fobbed off into back-of-the-bus modules. > > But I tell you this: your whole language will get fobbed off as > a pain in the royal ass. > > Since day 1, perl has been useful because it's had so much in it. > You don't want a language with a whole bunch of the commonly needed > functions *already* in it, fine -- but it's not going to be perl, > and it's not going to be useful. > > --tom I would like to see a set of "requirements" that make Perl what it is. I think we all have a vague idea of what makes Perl great, but I'm also sure there's a lot of variation. With a SHORT list of requirements, it becomes much easier to address some of these issues that are radical changes to the language. Here are some possibilities for inclusion in such a list: native pattern matching; list manipulation aweswome text processing. It's application glue (thanks Tim) Is this an reasonable idea? and a reasonable start? -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 146 (v1) Remove socket functions from core
At 11:55 AM 8/25/00 -0400, Michael Maraist wrote: > > You will *not* improve the performance of the inner interpreter > > loop by having fewer opcodes to switch on. Whether the number is > > 20 or 200, it's the same thing--*think* aboutit. > >Well, not strictly true. Though the raw code will not switch any faster, >the bloat of the core will hurt you with non-locality, through cache misses, >or worse memory-paging. That, as they say, turns out not to be the case, at least not in the general case. Code you don't call won't eat up any cache space, nor crowd out some other code. And if you do call it, well, it ought to be in the cache. Now there are issues--if we have an indirect function table, it makes sense for the pointers for functions called in succession be close to one another to get a win from cache prefetching, but reasonable ordering of functions in the array (if we even have one) takes care of that. >So long as auto-loading (for legacy functions) makes it transparent, the >usefulness will not decrease one bit. The only things that are affected are >the performance (which depends on how old-op-code auto-loading is achieved), >and what happens when you ship the perl executable without any libraries >(which I've had to do on occasion). Performance is king and queen here. Anything that slows performance down without a big functional win will go. 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
> >I don't understand this desire to not want anything to change.
>
> You misread.
I sympathise. There are definate goals and focuses that each language is
built around.. Change these too much, and you have a different language,
while at the same time, alienating the people that chose that language
because of those met goals.
Perl is fun, functional, and efficient. I can artistically scuplt a program
in one line at the command prompt and do things that wield incredible power,
and feel an incredible sence of happiness. While at the same time, I can
write a massive program, and not have to worry about many of the mundane
details that we learn in algorithms / data-structures.
> >This is an
> >opportunity to clean up the language, make it more useable, and more fun.
> >I would have a lot more fun if perl were a better performer and if it was
> >easy for me to expand it, contract it, reshape it, improve it, etc.
> You will *not* improve the performance of the inner interpreter
> loop by having fewer opcodes to switch on. Whether the number is
> 20 or 200, it's the same thing--*think* aboutit.
Well, not strictly true. Though the raw code will not switch any faster,
the bloat of the core will hurt you with non-locality, through cache misses,
or worse memory-paging. A highly tuned 50K core interpreter will do much
better than a 500K list of regularly used libraries. Essentially, it should
be possible to perform profiling on suites of programs to find out what is
really most needed, and only allow them in the core. The rest could be
delegated to slower dynamic linking or outer-edge statically linked code.
It's the general idea of RISC, of course. I have no real backing to say
that this would actually improve performance, nor that it would even be
possible to stream-line the core of perl any further.. Hell, C++ is only
going to make the situation worse (performance lost to fun of development,
which is acceptible). Typically, when the core does nothing more than
handle basic flow, and memory management, you can have a rock-solid kernel.
If you can build out apon this (all op codes seem identical, beit built-in
through statically compiled extensions, or linked in), then you will have a
much more solid development base. This is the advantage of C, python, java,
etc. Their extensions feel just like built-ins. Granted, perl has come a
long way with giving keyword power to user-defines.
> Furthermore, It's
> been demonstrated that this supposed "gain", including in size, is
> negligible. I have yet to see one iota of justification for denuding
> perl of its math functions.
I would agree that math function should not be compromised. If dynamically
linking them seriously decreases performance, then we're going to see a
massive slow-down in operation, since some crazed programmers actually like
performing fast fourier transforms. Getting a 20-30% slow-down is not going
to be well accepted (I'm guessing at the over-head of dynamic linking; I
just hear how bad it is). As above, however, I don't see a problem with
keeping them statically linked, so long as they're not part of the core.
> If math functions should be removed,
> then so too string functions. And that binmode silliness is in
> line before any of them, since it's absolutely useless because I
> never use it.
As in all things in life.. Moderation.. Profiling should decide what
compromises clean-ness of code for the benifit of optimization. Many string
operations are close to memory management, such as array modification,
string concatenation, simple assignment, references.. I would advocate that
they be part of the memory management system, and thus part of the core.
> Perl is *not* fun when it supplies nothing by default, the way C
does(n't).
I hear ya. Dynamic memory management (garbage collection, dynamic arrays,
etc), powerful string operations, powerful datatypes, etc. These are what
attract me to perl the most.. Not so much readily available socket
functions. Sure having java.util.* built into java would make it easier to
use out of the box, but it's more to learn about the internals, especially
since they may change over time. I can more easily walk the lib-tree and
read pod-files about each library to learn what I can do.
>
> If you want a language that can do nothing by itself, fine, but don't
> call it Perl. Given these:
>
> * Scalar manipulation
> * Regular expressions and pattern matching
At the very least, built-in reg-ex's allows the compiler to make incredible
optimizations which it simply wouldn't be able to do if it were a function
call:
$str =~ s/${var} xxx \s xxx/ abs( $1 ) /xegso;
would have to be:
$reg_ex = gen_regex_replace( expr => "${var} xxx \s xxx", subs =>
"abs( $1 )", modifiers => "xegso" );
apply_reg_ex( regex => $reg_ex, str => $str );
It would be non-trivial to get a compiler to efficiently handle this.. Thus,
I don't support any removal of expressions. I definately don't support
maki
RE: RFC 146 (v1) Remove socket functions from core
>Perl is *not* fun when it supplies nothing by default, the way C does(n't). >If you want a language that can do nothing by itself, fine, but don't >call it Perl. Given these: I agree! Removing some of the things mentioned would turn Perl into an environment well suited for computer science projects, but a hard sell as a tool to get a job done. Let me take a look in my c:\\work directory for a second Just as I thought most (80%) are less than 1k in size. All but one huge 5k program are 2k or less. Yet these small (20 lines or less) programs have been credited with saving hundreds of man hours of administrative effort. While it would not be a HUGE effort for me to add five to ten lines of "use X" and insert some "X::" into these scripts, what do I gain by that change? If there is an argument to take math functions etc out of the core to improve speed (and I doubt it is a good one) then there would need to come up with a "magic" autoloader to allow the environment to continue to remain terse and powerful. I wish there was just a way to say "use everything" and have the modules loaded when encountered (i.e. WIN32::ADMINMISC ). >From a purist standpoint the first two functions to go should be split() and chomp(). They should be moved to a special string library. Then regex stuff should become functions in another. Pretty soon we have a nice clean butter knife of an environment instead of a "Swiss Army Chainsaw".
Re: RFC 146 (v1) Remove socket functions from core
At 06:27 AM 8/25/00 -0700, Benjamin Stuhl wrote: > > At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: > > >Dan Sugalski writes: > > > > One of the current plans is for the parser to have > > access to a list of > > > > functions that trigger autoloading modules. > > > > > >Isn't dynamic loading really slow? > > > > Not particularly, at least not as far as I know. There's > > some extra cost in > > finding the library and loading it that you wouldn't pay > > if you were linked > > directly to it, but AFAIK that's about it. > > > > Dan > >There's also the issue that _each_ symbol must be requested >manually and stored somewhere (in a MT-safe manner, of >course), rather than having the loader resolve everything >in one pass. Far, *far* too much work. We request one function from the library, which is some bootstrap code that handles installing the pseudo-op functions in that library into a vector table somehwere, and we make sure that darned near everything we need to know about the library's built for us in advance. This scheme may ultimately not be worth it for things like the math functions, and that's fine. It doesn't, however, need to be particularly expensive. 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
> At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: > >Dan Sugalski writes: > > > One of the current plans is for the parser to have > access to a list of > > > functions that trigger autoloading modules. > > > >Isn't dynamic loading really slow? > > Not particularly, at least not as far as I know. There's > some extra cost in > finding the library and loading it that you wouldn't pay > if you were linked > directly to it, but AFAIK that's about it. > > Dan There's also the issue that _each_ symbol must be requested manually and stored somewhere (in a MT-safe manner, of course), rather than having the loader resolve everything in one pass. -- BKS __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
Re: RFC 146 (v1) Remove socket functions from core
--- "Stephen P. Potter" <[EMAIL PROTECTED]> wrote: > Lightning flashed, thunder crashed and Tom Christiansen > <[EMAIL PROTECTED] > m> whispered: > | Unless that's done completely transparently, you'll > pretty much screw the > | pooch as far as "Perl is the Cliff Notes of Unix" > notion. Not to > | mention running a very strong risk of butchering the > performance. > > I don't think there is any ruling from Larry that perl > must remain the > "Cliff Notes of Unix." In fact, there seems to be a bit > of a concerted > effort (partly suggested by Larry, IIRC) to make perl > *less* Unix-centric > and more friendly for other environments. > > I'm not concerned with performance, per se. I have > confidence in the > people who will actually write the code to take care of > that issue. > Performance will be a factor in deciding whether this can > be implemented or > not. If performance will suffer unacceptably, then this > won't get > implemented. It probably would. Dynamic loading is not cheap, and having to do a dlopen() and a dlsym() (or a LoadLibrary() and a GetProcAddress()) to find out the square root of 2 is not my idea of a _useful_ lightweight programing language. > | I don't understand this desire to eviscerate Perl's > guts. Having > | everything you want just *there* is part of what's made > Perl fast, > | fun, and successful. Good luck on preserving all > three. > > This desire stems from having a wonderful mechanism for > making the core > more lightweight (hopefully improving performance) called > loadable > modules. Larry designed this feature for a reason, and > has been saying > since the early perl5 alphas that we could/should migrate > some things out > of the core. I'm simply suggesting all the parts that I > think reasonably > go together than could be migrated. They can still be > "there", just in a > module. If the AUTOLOAD stuff that is being discussed > works out, you won't > even know the internals have changed. AUTOLOAD searches are not cheap either. It can take a lot of stat() calls to even _find_ the correct module, much less load it. The average math function in the perl5 core is about 13 lines of C code. Eviscerating it out of the core would accomplish nothing. > I don't understand this desire to not want anything to > change. This is an > opportunity to clean up the language, make it more > useable, and more fun. Slowing perl down and forcing everyone to add 5 "use" statements to the top of every program to get any useful features would neither make it more useful or more fun. > I would have a lot more fun if perl were a better > performer and if it was > easy for me to expand it, contract it, reshape it, > improve it, etc. > > -spp -- BKS __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
Re: RFC 146 (v1) Remove socket functions from core
>I don't understand this desire to not want anything to change. You misread. >This is an >opportunity to clean up the language, make it more useable, and more fun. >I would have a lot more fun if perl were a better performer and if it was >easy for me to expand it, contract it, reshape it, improve it, etc. Bah. You start from false premises, and go on to fantasize bucolically about motherhood and apple pie. You will *not* improve the performance of the inner interpreter loop by having fewer opcodes to switch on. Whether the number is 20 or 200, it's the same thing--*think* aboutit. Furthermore, It's been demonstrated that this supposed "gain", including in size, is negligible. I have yet to see one iota of justification for denuding perl of its math functions. If math functions should be removed, then so too string functions. And that binmode silliness is in line before any of them, since it's absolutely useless because I never use it. See what I mean? Perl is *not* fun when it supplies nothing by default, the way C does(n't). If you want a language that can do nothing by itself, fine, but don't call it Perl. Given these: * Scalar manipulation * Regular expressions and pattern matching * Numeric functions * Array processing * List processing * Hash processing * Input and output * Fixed-length data and records * Filehandles, files, and directories * Flow of program control * Scoping * Miscellaneous * Processes and process groups * Library modules * Classes and objects * Low-level socket access * System V interprocess communication * Fetching user and group information * Fetching network information * Time Your brain-damaged Perl would likely end up having nothing in it but these: * Flow of program control * Scoping Anything else would be fobbed off into back-of-the-bus modules. But I tell you this: your whole language will get fobbed off as a pain in the royal ass. Since day 1, perl has been useful because it's had so much in it. You don't want a language with a whole bunch of the commonly needed functions *already* in it, fine -- but it's not going to be perl, and it's not going to be useful. --tom
Re: RFC 146 (v1) Remove socket functions from core
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: >Dan Sugalski writes: > > One of the current plans is for the parser to have access to a list of > > functions that trigger autoloading modules. > >Isn't dynamic loading really slow? Not particularly, at least not as far as I know. There's some extra cost in finding the library and loading it that you wouldn't pay if you were linked directly to it, but AFAIK that's about it. 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
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] m> whispered: | Unless that's done completely transparently, you'll pretty much screw the | pooch as far as "Perl is the Cliff Notes of Unix" notion. Not to | mention running a very strong risk of butchering the performance. I don't think there is any ruling from Larry that perl must remain the "Cliff Notes of Unix." In fact, there seems to be a bit of a concerted effort (partly suggested by Larry, IIRC) to make perl *less* Unix-centric and more friendly for other environments. I'm not concerned with performance, per se. I have confidence in the people who will actually write the code to take care of that issue. Performance will be a factor in deciding whether this can be implemented or not. If performance will suffer unacceptably, then this won't get implemented. | I don't understand this desire to eviscerate Perl's guts. Having | everything you want just *there* is part of what's made Perl fast, | fun, and successful. Good luck on preserving all three. This desire stems from having a wonderful mechanism for making the core more lightweight (hopefully improving performance) called loadable modules. Larry designed this feature for a reason, and has been saying since the early perl5 alphas that we could/should migrate some things out of the core. I'm simply suggesting all the parts that I think reasonably go together than could be migrated. They can still be "there", just in a module. If the AUTOLOAD stuff that is being discussed works out, you won't even know the internals have changed. I don't understand this desire to not want anything to change. This is an opportunity to clean up the language, make it more useable, and more fun. I would have a lot more fun if perl were a better performer and if it was easy for me to expand it, contract it, reshape it, improve it, etc. -spp
Re: RFC 146 (v1) Remove socket functions from core
Dan Sugalski writes: > One of the current plans is for the parser to have access to a list of > functions that trigger autoloading modules. Isn't dynamic loading really slow? If they're going to incur the penalty of dynamic loading, you might as make them request that slowdown by 'use'ing the module. The alternative is that they memorize a long list of functions, some of which are slow and some of which aren't. Nat
Re: RFC 146 (v1) Remove socket functions from core
At 03:34 PM 8/24/00 -0600, Tom Christiansen wrote: > >I have several RFCs I need to write about removing certain functionality > >out of the core (math functions, IPC, networking, "user"). I don't want to > >go too overboard. I don't know that we want to go so far as to remove > >printing and such. It might be nice to generalize some functions (like the > >discussion with open() that happened awhile back). > >Unless that's done completely transparently, you'll pretty much screw the >pooch as far as "Perl is the Cliff Notes of Unix" notion. Not to >mention running a very strong risk of butchering the performance. One of the current plans is for the parser to have access to a list of functions that trigger autoloading modules. If, for example, it sees shmget(), that'll trigger the loading of the SysV::SharedMem module. (Or whatever module it lives in) There'll be a magic registry somewhere that can get added to when a module is installed--think of it as @EXPORT on steroids. (You don't even have to use the module to get it loaded, as the mere mention of a name summons it. We'll probably have to come up with some name that has the acronym "hastur" or something...) One of the other plans is to provide a way for people to write op-level functions that run at near-op speed. (The difference being an extra pointer deref, most likely) We want calling XS functions to be snappy too, of course, but this is a level deeper. Less safe and more prone to breakage from version to version of perl, but that's the risk you take when working under the hood. >I don't understand this desire to eviscerate Perl's guts. I do. I just don't understand the desire on the part of other people. ;-) 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
>Perhaps it would be better to have Perl support all of perlfunc(1) in the >core still, but allow users to turn subsets off? >Or, perhaps the core functions could be syntactic sugar for access to >modules, and have a transformation happen automagically in the parser? (My >gut says "here there be dragons", but they don't seem like dragons that are >unslayable.) One might consider making CORE:: a real-er namespace. In Python, for example, with its semi-numbskulled non-nesting scoping levels, you still have three resolutions: builtins (read: CORE), package, and local. These are all fully-fledged namespaces, and you could store something in the builtins if you wanted. Somewhat like CORE::GLOBAL. Right now, of course, you can't usefully do much with \&CORE::dbmopen, for example. But if you could, perhaps more would be feasible. However, I feel that I may run the risk of violating the following: "We do not define Perl as an improved version of some other language. Nor do we define Perl as the next universal language. We're not trying to make Perl a better language than C++, or Pyuthon, or Java, or JavaScript. We're trying to make Perl a better language than Perl. That's all." --Larry Wall in his 1999 State of the Onion Address But if I am doing so, then it is not without ample precedent in this and related threads. :-( --tom
Re: RFC 146 (v1) Remove socket functions from core
> >I admire micro-kernel-type systems. C and Java give you no functions out of > >the box. Keywords are just that, keywords. I believe python is like this > >as well. The idea being that everything has to come from a module.. This > >limits how much a new developer has to learn, and it doesn't pollute the > >global name-space pool. Tom Christiansen wrote: > A very long time ago, when Perl first came out, people would try to make > Perl "just like C". That today the impetus is toward Java is still really > the same story. Fortunately, Larry didn't do it then, and I don't see it > happening now. I would like to chime in quickly on this thread to note that having lots of stuff in the global namespace/core is not a problem from the "JVM port camp". I went down this road when I started working on the JVM port saying to myself: "Darn it, if the Perl core was just smaller, this would be so much easier." I decided then that the JVM port must be done in subsets. (One reason being that if you want to target a tiny embedded JVM in a wrist-watch, you can't ever really have all of Perl anyway). I see the Perl->JVM compiler having a list of well-documented options that say: "Ok, if you want this set of core features turned off, then use this option". To make this possible, the internals simply need a way via an API for a back-end porter to tell the front-end that certain keywords are forbidden. That way, the user can get messages like: "Sorry, you told me on the command line you wouldn't use core socket support, but you appear to have done so in the program. Thus, your compile failed." And, the more we of these we can catch at compile time, the better. Shouldn't be too hard, I don't think. Perhaps it would be better to have Perl support all of perlfunc(1) in the core still, but allow users to turn subsets off? Or, perhaps the core functions could be syntactic sugar for access to modules, and have a transformation happen automagically in the parser? (My gut says "here there be dragons", but they don't seem like dragons that are unslayable.) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: RFC 146 (v1) Remove socket functions from core
>I have several RFCs I need to write about removing certain functionality >out of the core (math functions, IPC, networking, "user"). I don't want to >go too overboard. I don't know that we want to go so far as to remove >printing and such. It might be nice to generalize some functions (like the >discussion with open() that happened awhile back). Unless that's done completely transparently, you'll pretty much screw the pooch as far as "Perl is the Cliff Notes of Unix" notion. Not to mention running a very strong risk of butchering the performance. I don't understand this desire to eviscerate Perl's guts. Having everything you want just *there* is part of what's made Perl fast, fun, and successful. Good luck on preserving all three. --tom
Re: RFC 146 (v1) Remove socket functions from core
Lightning flashed, thunder crashed and "Michael Maraist" whispered: | >From this, socket, and virtually all IPC methods should go the wayside. | This includes pipes, shell environment ops ( the get and set functions ), | and even the file-io (open, close, and possibly even printf, sprintf). At | this point, it gets a little hairy, since arguably, everybody wants print | and <>. I would suppose that most want open as well. My personal taste is | to use IO::File, but that's just me. I have several RFCs I need to write about removing certain functionality out of the core (math functions, IPC, networking, "user"). I don't want to go too overboard. I don't know that we want to go so far as to remove printing and such. It might be nice to generalize some functions (like the discussion with open() that happened awhile back). -spp
Re: RFC 146 (v1) Remove socket functions from core
At 07:28 PM 8/24/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >*) It makes optionalizing (now there's a good word... :) the functions > >easier for platforms that just don't have 'em. Like, say, the Palm, or > >embedded gadgets. (Most teddy bears aren't likely to come with a network > >stack...) > >Most everything will have a network stack if you believe the hype. Being the cynical sort I am (one of the handy side-effects of sysadminhood... :), I'll believe that when I see it work. :) >When a Palm "is" a WAP Phone it will have one, and while Teddy Bears may >not I am sure Furbie-II will... I'm picturing a WAP-enabled cellular furbie with an R2D2-style projector thingie for the video. It's not a pretty sight... 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
Dan Sugalski <[EMAIL PROTECTED]> writes: > >*) It makes optionalizing (now there's a good word... :) the functions >easier for platforms that just don't have 'em. Like, say, the Palm, or >embedded gadgets. (Most teddy bears aren't likely to come with a network >stack...) Most everything will have a network stack if you believe the hype. When a Palm "is" a WAP Phone it will have one, and while Teddy Bears may not I am sure Furbie-II will... -- Nick Ing-Simmons
Re: RFC 146 (v1) Remove socket functions from core
At 11:38 AM 8/24/00 -0600, Tom Christiansen wrote: > >At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote: > >> >Remove socket functions from core > >> > >>Why? What is the justification? I can think of some, but you > >>haven't given them. > > >There are a number of good reasons to do this from an internals standpoint, > >enough that I'd like to do it. > >Is one allowed to know that number, and those reasons? :-) Nope, it's a secret! :-P Seriously, they are: *) Fewer opcodes to deal with. Fewer opcodes means fewer cases to deal with, and a potentially smaller (and more cache-coherent) dispatch table *) Easy upgradability. To fix any issues with these functions as they currently exist means replacing perl. If they're a module of sorts, there can be a simple plug-in upgrade. *) It makes optionalizing (now there's a good word... :) the functions easier for platforms that just don't have 'em. Like, say, the Palm, or embedded gadgets. (Most teddy bears aren't likely to come with a network stack...) *) Easy extension. Which is an extension of easy upgradeability, I suppose, but if you wanted to open, say, NetWare connections, or IPv6 connections, with the current interface it'd be nice to be able to do this without rebuilding perl. 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
>I admire micro-kernel-type systems. C and Java give you no functions out of >the box. Keywords are just that, keywords. I believe python is like this >as well. The idea being that everything has to come from a module.. This >limits how much a new developer has to learn, and it doesn't pollute the >global name-space pool. Though I would advocate OO interfaces to >everything, I'm sure that it would defeat a lot of perl's flexibilty, and so A very long time ago, when Perl first came out, people would try to make Perl "just like C". That today the impetus is toward Java is still really the same story. Fortunately, Larry didn't do it then, and I don't see it happening now. Perl is not into minimalism or non-redunancy: diagonals and all, eh? And I don't see objects ever becoming in Perl the Way, the Truth, and the Light without which no man cometh unto his data, for that would be too dictatorial in its Thou-Shalt-nesses. We've already got lots of those sorts of languages, as you have noted. They're a long, long ways from what I would call "fun", an essential element of Perl that doesn't get mentioned enough. But we shall see; perhaps Larry will get a new religion and set about changing the world in a radically different fashion than his previous style. --tom
Re: RFC 146 (v1) Remove socket functions from core
I would actually further this sort of activity. I admire micro-kernel-type systems. C and Java give you no functions out of the box. Keywords are just that, keywords. I believe python is like this as well. The idea being that everything has to come from a module.. This limits how much a new developer has to learn, and it doesn't pollute the global name-space pool. Though I would advocate OO interfaces to everything, I'm sure that it would defeat a lot of perl's flexibilty, and so I'd support the simple Exporter method. >From this, socket, and virtually all IPC methods should go the wayside. This includes pipes, shell environment ops ( the get and set functions ), and even the file-io (open, close, and possibly even printf, sprintf). At this point, it gets a little hairy, since arguably, everybody wants print and <>. I would suppose that most want open as well. My personal taste is to use IO::File, but that's just me. Since these are just hooks into standard C libraries, I don't think that they really take up any room. But it is hard to justify keeping some of these less used features while taking out others (like FORMAT). -Michael
Re: RFC 146 (v1) Remove socket functions from core
>up with a better model than the C/Unix like way things are now. Having
>sockets in the core makes as much sense as having the ability to open and
>read disk files (early Pascal anyone?) in todays world of networked
>computers.
>From what Larry's said about making open work on URLs, he's
in you camp. :-)
>Being able to use them as easy as files would be the real goal:
>open(F,"\\server.yourdomain.net:2001");
>while()
> {
> }
>close(F);
>The double slash giving a clue that this is a socket.
I see only a backslash, not a pair of slashes. :-)
--tom
RE: RFC 146 (v1) Remove socket functions from core
>No idea what the internals reasons are. Here are my reasons:
It would be a good idea to work over the way sockets are used and maybe come
up with a better model than the C/Unix like way things are now. Having
sockets in the core makes as much sense as having the ability to open and
read disk files (early Pascal anyone?) in todays world of networked
computers.
Being able to use them as easy as files would be the real goal:
open(F,"\\server.yourdomain.net:2001");
while()
{
}
close(F);
The double slash giving a clue that this is a socket.
Re: RFC 146 (v1) Remove socket functions from core
Tom Christiansen writes: > >There are a number of good reasons to do this from an internals standpoint, > >enough that I'd like to do it. > > Is one allowed to know that number, and those reasons? :-) No idea what the internals reasons are. Here are my reasons: * the current socket(), bind(), connect() etc are based VERY closely around C, to the point of requiring C structures that are binary data which you have to build using a separate module. So if you're using them, you *already* load a module. Just put the bloody things into that module. You wouldn't lose anything over how it's done now. * they take magic constants, just like the C function, that are mostly the same. You know the difference between PF_INET and AF_INET, I know the difference, but many people do not. And they shouldn't have to. IO::Socket is a good start at Doing It Right instead of Doing The Old Way With Lots of Constants And Arguments. * the get*by* for networking stuff (hosts,services,etc) are so rarely used they should be moved out. Yes, it's only a small win. But every byte counts towards a smaller Perl, and moving getprotobyname() to a module isn't the same as moving open(). Nat
Re: RFC 146 (v1) Remove socket functions from core
>At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote: >> >Remove socket functions from core >> >>Why? What is the justification? I can think of some, but you >>haven't given them. >There are a number of good reasons to do this from an internals standpoint, >enough that I'd like to do it. Is one allowed to know that number, and those reasons? :-) --tom
Re: RFC 146 (v1) Remove socket functions from core
At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote: > >Remove socket functions from core > >Why? What is the justification? I can think of some, but you >haven't given them. There are a number of good reasons to do this from an internals standpoint, enough that I'd like to do it. From an externals standpoint, though... I've yet to hear a compelling reason to require a "use thingies;" to yank 'em in. That being the case, I've a scheme that makes them external as far as the internals are concerned, but internal as far as the externals are concerned. Best of both worlds, more or less. 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
>Remove socket functions from core Why? What is the justification? I can think of some, but you haven't given them. In general, the misplaced zealotry to strip Perl down into someting where nothing is predefined is hardly a good investment. It's not like it will make anything appreciably smaller or faster, as previous studies have already proven. There's no need to have Perl become a language with merely seven keywords and everything else requires loading a million libaries for. You have but to look at Forth or Tcl or Python for how much that is. Perl has always had a lot of functionality predefined. Why would you want to break that?? --tom
Re: RFC 146 (v1) Remove socket functions from core
On Thu, Aug 24, 2000 at 03:43:41PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Remove socket functions from core > > =head1 VERSION > > Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> > Date: Aug 24 2000 > Mailing List: [EMAIL PROTECTED] > Version: 1 > Number: 146 > > =head1 ABSTRACT > > Move the socket functions (C, C, etc) from the core language > to a loadable module. Agreed. While doing this, add sendmsg() and recvmsg() (at last). (And think about IPv6 (see Socket6 in CPAN)) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
RFC 146 (v1) Remove socket functions from core
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove socket functions from core =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 146 =head1 ABSTRACT Move the socket functions (C, C, etc) from the core language to a loadable module. =head1 DESCRIPTION Several of the socket functions have already started to migrate from the core to a module. This RFC is proposing that all the socket functions should move to the Socket.pm module and require a "use Socket;" in order to function in perl 6. The specific functions that would be covered under this proposal are: =over =item C =item C =item C =item C =item C =item C =item C =item C =item C =item C =item C =item C =item C =back =head1 IMPLEMENTATION Move code for socket functions to Socket.pm, requyire "use Socket" to enable use of socket functions. =head1 REFERENCES L L
