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
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
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
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
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.
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
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
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
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
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
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
[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
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
--- "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
|
cut
Perl is *not* fun when it supplies nothing by default, the way C does(n't).
cut
If you want a language that can do nothing by itself, fine, but don't
call it Perl. Given these:
cut
I agree!
Removing some of the things mentioned would turn Perl into an environment
well suited for computer
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
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
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
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
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
"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
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
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
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
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
Come on Tom take it easy on us poor admins who have to live in the "Billduh"
world.
So long as such folks do nothing that will hurt those of us who
have no trek with such, then live and let live. But when Billness
starts biting those who won't have anything to do with it causing strange
Amen.
-Original Message-
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 25, 2000 3:09 PM
To: Lipscomb, Al
Cc: Joe McMahon; Stephen P. Potter; Michael Maraist;
[EMAIL PROTECTED]; 'Larry Wall'
Subject: Re: RFC 146 (v1) Remove socket functions from core
Come
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
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.
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
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
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_
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
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
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,
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
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
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
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
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
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
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
Lightning flashed, thunder crashed and "Michael Maraist" maraism@ironhilltechn
ology.com 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
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
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
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
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
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
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
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
51 matches
Mail list logo
