1:40 p.m.
My feeling is that if this is the sort of thing that can be free, or
nearly free in terms of implementation cost, cool. Otherwise, it's
probably not worth it.
Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org:
I don't see that it is. There hasn't been any clamor for
dynamic
loading of the X11 code for instance, and it would be quite a job
to implement.
The sort of people who don't like X11 (and GUI) code in Emacs are the
ones who tend to not use XEmacs.
My only uses of XEmacs in a fielded commercial setting haven't involved
usage with X11, but it hasn't been a hardship building it without X11
in the first place.
It's hard to believe that the bug count would decrease as a
result
of this, either.
Yup.
2:46 a.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
On Mon, Jan 11, 1999 at 05:40:32AM -0800, SL Baur wrote:
> It's hard to believe that the bug count would decrease as a
result
> of this, either.
Yup.
I looked at the code. Making things like X11 and TTY code loadable is
no more bug-prone than, say, MULE :-) Seriously though, its not as big
a deal as you think it is. We can forsee problems way into the night,
and nothing will change. However, if we actually TRY something, and it
works, why not keep it? I would love to see XEmacs distributed for
all platforms that can support this technology, to have not only the
ability of any external package to add to XEmacs in C, but to have large
portions of XEmacs itself loadable, and installed with the binary.
Just as the user can extend in Lisp, but also gets a standard set of
Lispy things in the dumped emacs, so they can extend in C and have a
standard set of modules that get loaded based on their environment.
With a bit of careful planning (which in reallity makes the code much more
flexible for OTHER changes) we could make large parts of XEmacs optional.
I dont buy the argument that everything that is unused is swapped either.
Most systems have limited swap space, and why waste 20MB in swap if we
only need to waste 5? Why have hundreds of extra shared pages when we really
only need a few? Too often over the last 10 years the trend in programming
has been "oh well, some other technology can cope with the excess, I'll
just do things the easy / quick way". That way lies madness. dBASE-III
shipped on 3 360K floppies. dBASE-V on 18 1.2MB ones. Spot the problem?
Emacs used to be a 700K binary. Now its a 2.6MB image and thats excluding
all of the shared libraries that it loads. We CAN stop this excess.
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
5 a.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
J. Kean Johnston writes:
On Mon, Jan 11, 1999 at 05:40:32AM -0800, SL Baur wrote:
> > It's hard to believe that the bug count would decrease as a result
> > of this, either.
>
> Yup.
I looked at the code. Making things like X11 and TTY code
loadable is no more bug-prone than, say, MULE :-) Seriously
though, its not as big a deal as you think it is. We can
forsee problems way into the night, and nothing will change.
Sorry, but I consider it my job to at least try to foresee problems.
If I take your assertion at face value, the next questions is,
what are we getting that is comparable in value to MULE? Or even
close to comparable? I think you've given us two benefits of
carving up XEmacs into modules. Size and the ability for users
to quickly try different features (Lucid vs. Motif dialogs).
First, let's look at size. I can already compile XEmacs with or
without the features I want, so I can produce a binary with a
size that suits me. 256MB of SDRAM can be purchased for under
US$500. I run XEmacs at home, comfortably, in 32MB of memory.
This is compiled with X, Lucid widgets, database support, and
support for all the image types. And the binary is statically
linked. All this an it runs without swapping in 32Mb of memory.
Even the dirt-cheap eMachine boxes (US$399) ship with 32MB of
memory. If I can run today's XEmacs on a machine that is five
years old (I can and do) and on the cheapest PC's available
today, then I think we're doing all right. So I don't see in-core
memory size as an issue worth addressing, unless its something
we can do easily.
Second, we would have the ability to try different features
quickly. This sounds pretty good, but with what we have today,
there isn't much choice. Lucid vs. Motif is all I can think of.
Except for the dialog boxes and XIM, the Motif stuff is broken,
so at best you'd get to try out some different dialog boxes and
the XIM code (I don't know what XIM does). Would this be worth
the work? On my 266MHz Pentium, a build from scratch takes a
bit under 11 minutes. Given this, trying out a new feature set
isn't much of a hardship.
Using modules as you describe has a very high coolness factor,
but it just seems to lack practicality. I'd be glad to hear
other opinions.
However, if we actually TRY something, and it works, why not
keep it?
Maintenance. Writing it is only the beginning. The new code has
to be worth the effort that it will take to maintain it years
into the future.
5:55 a.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Second, we would have the ability to try different features
Kyle> quickly. This sounds pretty good, but with what we have
Kyle> today, there isn't much choice. Lucid vs. Motif is all I
Kyle> can think of. Except for the dialog boxes and XIM, the
Kyle> Motif stuff is broken, so at best you'd get to try out some
Kyle> different dialog boxes and the XIM code (I don't know what
Kyle> XIM does).
XIM handles non-English input under X Windows, and is most useful with
Oriental ideographic languages. However, XEmacs can also implement XIM
natively through Xlib. That leaves dialogs....
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
7:49 p.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
At 21:00 13/01/99 -0800, Kyle Jones wrote:
Sorry, but I consider it my job to at least try to foresee problems.
I'm with Kyle on this. I think modules are cool but I don't see the point
of reworking stuff for little gain. With or without mule, X - these are
decisions like getting married ... you make them once and stick with them.
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
9:20 p.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
On Thu, Jan 14, 1999 at 07:49:07PM +0000, Andy Piper wrote:
I'm with Kyle on this. I think modules are cool but I don't
see the point
of reworking stuff for little gain. With or without mule, X - these are
decisions like getting married ... you make them once and stick with them.
Suggestion: don't look at the divorce rate statistics :-))
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
9:19 p.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
On Wed, Jan 13, 1999 at 09:00:31PM -0800, Kyle Jones wrote:
First, let's look at size. I can already compile XEmacs with or
without the features I want, so I can produce a binary with a
size that suits me. 256MB of SDRAM can be purchased for under
Kyle, thats the
entire point. *YOU* can compile it that way. To YOUR
tastes. Now consider someone in a different position (like me). I
compile up tons of freeware for distribution to our customers, all
neatly packaged on a few CD's. I cannot know what environment the
software will be run on, I can't known what the end user's tastes
are. On a smaller scale, a sysadmin for a school decides to put
XEmacs on a central box for students to use. Does he make the choice
of what is good, bad, pretty or ugly for all users, or should the
users get the choice? By splitting out things into discrete parts,
you not only reduce the size you give flexibility. And while YOU
may be able to afford 256MB of RAM, spending in dollars, can a user
in Slovenia, or Madagascar or Outer Mongolia afford the same luxury?
With a little effort we can keep all of these disaprate worlds happy.
A power user gets everying including the kitchen sink, and if he
wants it its all preloaded and part of the binary. Lowlier users
get the power of choice, and I cant ever see this as being a Bad Thing,
nor can I see it as a waste of time to explore any avenues which
make this possible.
memory. If I can run today's XEmacs on a machine that is five
years old (I can and do) and on the cheapest PC's available
today, then I think we're doing all right. So I don't see in-core
memory size as an issue worth addressing, unless its something
we can do easily.
Your argument holds true only if that is ALL you are doing. I
refuse to believe that you can run a fully laden XEmacs, have a
compile (or maybe even two) going, have a web server running, and
a few ftp sessions active (a fairly typical scenario on a typical
Linux workstation), all in 32MB of memory. And as for ease of doing,
I remain convinced that it *IS* easy, given that a little bit of code
restructuring and Makefile hackery takes place. Such modifications
just make the source more flexible in other ways anyway, so its a
good thing from that point of view alone.
Second, we would have the ability to try different features
quickly. This sounds pretty good, but with what we have today,
there isn't much choice. Lucid vs. Motif is all I can think of.
TTY versus
X11, redisplay-enabled versus batch (granted batch mode is
not very commonly used, although I do so personally for running some
weird Lisp stuff I have written). Sound support, database support,
an HTML parser (and possibly renderer) written in C. The list is
longer than you make it out to be. In a TYPICAL XEmacs session,
few people will use DBM support. Why weigh the entire executable
down with it? If we make it demand-loadable, the user only pays
the penalty of having it there if they actually need it. Same for
all the other cases.
the work? On my 266MHz Pentium, a build from scratch takes a
bit under 11 minutes. Given this, trying out a new feature set
isn't much of a hardship.
See above about the short-sightedness of what YOU are
able to do
in YOUR environment. I do not mean the word "shortsightedness"
to sound antagonistic, please don't take it that way.
Using modules as you describe has a very high coolness factor,
but it just seems to lack practicality. I'd be glad to hear
other opinions.
Well, as I touched on above, here are some options:
HTML parser, sound, database support (for things other than DBM too),
moving some slow Lisp stuff into loadable C code, etc.
> However, if we actually TRY something, and it works, why not
> keep it?
Maintenance. Writing it is only the beginning. The new code has
to be worth the effort that it will take to maintain it years
into the future.
What I meant by TRYING stuff was to TRY to move existing stuff
into modules, more as a proof of concept than ahything else.
If the changes stay, there is no bigger maintenance overhead than
for them as non-loaded modules. This was by design. I tried to make sure
that a module was, from a source point of view, indistinguishable from
code that was compiled intot he base executable.
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
7:59 a.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
J. Kean Johnston writes:
On Wed, Jan 13, 1999 at 09:00:31PM -0800, Kyle Jones wrote:
> If I can run today's XEmacs on a machine that is five
> years old (I can and do) and on the cheapest PC's available
> today, then I think we're doing all right. So I don't see in-core
> memory size as an issue worth addressing, unless its something
> we can do easily.
Your argument holds true only if that is ALL you are doing. I
refuse to believe that you can run a fully laden XEmacs, have a
compile (or maybe even two) going, have a web server running, and
a few ftp sessions active (a fairly typical scenario on a typical
Linux workstation), all in 32MB of memory.
Well, wait a minute. Just before this paragraph you were talking
about creating a small configuration for poor people in Outer
Mongolia. Now you've got them running a web server? And they
still can only afford 32MB of memory? :)
I'm only half-serious at this point. Obviously you don't
think we're doing enough to support small installations and I
think that we are. We'll just have to disagree on this, I
guess. The Mongolians won't have to wait too much longer for
better hardware. Computers sold three years ago essentially
have depreciated to scrap value today, and those computers can
certainly run XEmacs well. There are charities that accept
old computers and give them to the needy, schools, etc. So I
think the world will be OK.
8:27 p.m.
New subject: BAD BAD bloat (was Re: What to do with modules now ...)
On Thu, Jan 14, 1999 at 11:59:02PM -0800, Kyle Jones wrote:
certainly run XEmacs well. There are charities that accept
old computers and give them to the needy, schools, etc. So I
think the world will be OK.
*LOL* Ok Kyle, lets agree to differ :-)
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
9436
days inactive
9440
days old
8 comments
5 participants
participants (5)
-
Andy Piper -
Kean Johnston -
Kyle Jones -
SL Baur -
Stephen J. Turnbull