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 releva
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 fr
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 pl
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
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.
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)
>> Lo
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 te
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
>
>>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
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
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 perf
>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
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 w
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, jus
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)
every
[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 reall
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
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
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 poss
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 ac
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 o
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 yo
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 th
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
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_
>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 rel
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 particula
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 e
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
> "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 whic
>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'
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
>not
> "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 t
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
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
> 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
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. Per
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 di
>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
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 re
>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
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
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
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 t
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
> >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 langu
>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
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
> 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 k
--- "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
>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, imp
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
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 performan
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 m
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 su
>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
> >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'
>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 th
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
|
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
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 h
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 a
>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
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 de
>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
>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
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(),
>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
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 exte
>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 sma
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
71 matches
Mail list logo
