[I'm a stranger here myself]
Sounds like what is needed is someone to "own" the project for longer than
a school year. Put all artifacts under GPL and let the community at it.
Better would be a Godfather like Linus to create something coherent. Would
Lars care to volunteer?
No-one involved is likely to get rich on it. Is Linux a "commercial
success?" Maybe not, but it's absolutely a gem. Just plain intellectual
satisfaction has to count for something, or we should all surrender to The
Emperor Bill.
/David
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Christopher B. Browne
Subject: Re: LispOS, LispVM projects?
Date:
Message-ID: <72gedi$960$3@blue.hex.net>
Probably there's a need for people to be willing to compromise with
what they might ultimately want, and see about building something that
would be usable now.
Oberon, Smalltalk, and Forth have all "suffered" from trying to create
complete environments that turn out to be largely incompatible with
what others want; the process of building a useful "Lisp Environment"
might first of all mandate running it atop some other system such as
Linux or one of the BSD family.
Consider that this buys you:
a) A useful set of existing tools;
b) The ability to allow others to be responsible for much of the
underlying structure.
The latter is rather important particularly from a hardware
perspective, as there are a *serious pile* of funky devices coming out
on an ongoing basis, likely too many for a small group to track.
The OSKit approach was to build a system that could use device drivers
from Linux, FreeBSD, and possibly NetBSD; while this does gain the
benefit of being able to build up whatever memory management policy
you might want, the process of simply tracking device drivers may
represent a substantial effort, regardless of whether this provides
(directly) any real utility.
Add to this the question of whether you want to have graphical
infrastructure, and this just adds to the job of trying to build
feasible system configurations. For instance, yesteryear's "Matrox
Millennium" gets replaced by the "Millennium II" which is no longer
readily available, replaced by the "Matrox Millennium G300 AGP," which
requires some special handling as it integrates deeply with an IA-32
motherboard.
This sounds like gratuitous "citing of technical details;" it is
merely one example of the rapidity with which hardware vendors have
been cycling through product revisions, and is a real problem.
An OS design may work nicely today with what is available now.
Unfortunately, getting that same hardware next year may be
problematic. Which applies quite intensely to graphical and printer
hardware, somewhat less so to disk controllers and other disk
hardware, less so to NICs, and rather less to CPUs. For the most
part, new CPUs have *added* instructions; old code may not take
advantage of the new stuff, but at least still works.
The "best you can get" may be to build an environment on top of one of
(setf underlying-os-list '(Linux FreeBSD OpenBSD NetBSD)), using one
of (setf underlying-graphics-infrastructure-list '(X GGI)).
It may be not ideal particularly with respect to the handling of
memory allocation, where I expect that it would be preferable for
there to be a few large memory pools that are used globally, and GCed
globally. Ditto for the handling of namespaces, and I don't think I'm
quite competent to evaluate what would be the *next* problem with
having UNIX as the underlying infrastructure.
It seems likely to me nonetheless that trying to build a Lisp
environment atop a UNIX-like system (thus benefiting from their
ongoing efforts) is more likely to provide a useful result useful on
into decades to come than an attempt to build a kernel that will
require substantial maintenance just to keep it supportable.
Oh yes, the *other* benefit is that building something atop one of
those systems means that there is the possibility of allowing
aficionados of those systems to try out "LispEnv" without having to
commit to building a machine expressly for the purpose...
--
"The only ``intuitive'' interface is the nipple. After that, it's all
learned." -- Bruce Ediger, ·······@teal.csn.org on X interfaces.
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
On 13 Nov 1998 05:00:34 GMT, Christopher B. Browne wrote:
[A lot of comments that I agree with snipped]
>The "best you can get" may be to build an environment on top of one of
>(setf underlying-os-list '(Linux FreeBSD OpenBSD NetBSD)), using one
>of (setf underlying-graphics-infrastructure-list '(X GGI)).
>
>It may be not ideal particularly with respect to the handling of
>memory allocation, where I expect that it would be preferable for
>there to be a few large memory pools that are used globally, and GCed
>globally. Ditto for the handling of namespaces, and I don't think I'm
>quite competent to evaluate what would be the *next* problem with
>having UNIX as the underlying infrastructure.
The memory-handling problem is just a manpower problem: there is
no fundamental problem with making a kernel module to implement a
lisp-machine-like interface besides Linux. It already does this
for the emulation of iBCS binaries, and FreeBSD does something similar
for Linux-emulation. Both do DOS emulation as far as I know.
It is just the trivial problem that somebody has to sit down and
write it.
Until this happens, we can already start working on other, easier,
things. Like CLIM, Plob! for CMUCL, fixing the remaining compiler
and performance problems etc.
I don't really understand why people don't see that 90% of a
LispOS-on-top-of-Unix is already there :-(. Do all those people who
want to design the chip first realise how many man-years went into
CMUCL, CLX, Hemlock etc?
>Oh yes, the *other* benefit is that building something atop one of
>those systems means that there is the possibility of allowing
>aficionados of those systems to try out "LispEnv" without having to
>commit to building a machine expressly for the purpose...
Hear, hear!
Groetjes, Peter
--
It's logic Jim, but not as we know it. ········@debian.org, ········@inthan.be
Look in keyservers for PGP key.
In article <·······················@mail.inthan.be>,
········@mail.inthan.be (Peter Van Eynde) writes:
> Until this happens, we can already start working on other, easier,
> things. Like CLIM, Plob! for CMUCL, fixing the remaining compiler
> and performance problems etc.
ROTFL!! Easier things? CLIM? Haven't read the spec, have you? :-) It's 364
pages and is available in HTML form from
http://www.mikemac.com/mikemac/index.html if anyone's interested or is having
trouble sleeping.
OK, where's CMUCL 18B for Linux?
Mike McDonald
·······@mikemac.com
>>>>> "Mike" == Mike McDonald <·······@mikemac.com> writes:
Mike> OK, where's CMUCL 18B for Linux?
Anything wrong with the experimental versions (once I upload mine)?
It's got everything that 18b has plus long-floats.
Ray
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> writes:
>>>>>> "Mike" == Mike McDonald <·······@mikemac.com> writes:
>
> Mike> OK, where's CMUCL 18B for Linux?
>
> Anything wrong with the experimental versions (once I upload mine)?
> It's got everything that 18b has plus long-floats.
>
> Ray
Yah, they're not the released version! It doesn't match the other ports,
such as exists. That's whole reason for having "releases", having the same
feature set in all of them. (And, I can't build 18B releases for HP-UX and
DEC-OSF from a non 18B image.) Why bother snapshotting the sources if no
one's going to build that snapshot?
Mike McDonald
·······@mikemac.com
In article <············@blue.hex.net>,
········@news.brownes.org (Christopher B. Browne) writes:
> Probably there's a need for people to be willing to compromise with
> what they might ultimately want, and see about building something that
> would be usable now.
>
> Oberon, Smalltalk, and Forth have all "suffered" from trying to create
> complete environments that turn out to be largely incompatible with
> what others want; the process of building a useful "Lisp Environment"
> might first of all mandate running it atop some other system such as
> Linux or one of the BSD family.
This was proposed more than a year ago. Unfortunately, a large number of the
list members think they want to do low level kernel things. Unfortunately, a
lack of knowledge of both LispMs and kernels is abundant.
> This sounds like gratuitous "citing of technical details;" it is
> merely one example of the rapidity with which hardware vendors have
> been cycling through product revisions, and is a real problem.
This is the reality of the PC world. Wishing otherwise won't change it.
> The "best you can get" may be to build an environment on top of one of
> (setf underlying-os-list '(Linux FreeBSD OpenBSD NetBSD)), using one
> of (setf underlying-graphics-infrastructure-list '(X GGI)).
For 90% of a "Lisp OS", it shouldmatter what the underlying OS is. Most of
it should be written in plain ole Common Lisp. (Underlying window system does
have more of an impact though.)
> It seems likely to me nonetheless that trying to build a Lisp
> environment atop a UNIX-like system (thus benefiting from their
> ongoing efforts) is more likely to provide a useful result useful on
> into decades to come than an attempt to build a kernel that will
> require substantial maintenance just to keep it supportable.
AMEN!
> Oh yes, the *other* benefit is that building something atop one of
> those systems means that there is the possibility of allowing
> aficionados of those systems to try out "LispEnv" without having to
> commit to building a machine expressly for the purpose...
AMEN! AMEN!
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> > The "best you can get" may be to build an environment on top of one of
> > (setf underlying-os-list '(Linux FreeBSD OpenBSD NetBSD)), using one
> > of (setf underlying-graphics-infrastructure-list '(X GGI)).
>
> For 90% of a "Lisp OS", it shouldmatter what the underlying OS is. Most of
> it should be written in plain ole Common Lisp. (Underlying window system does
> have more of an impact though.)
It seems that the GGI is currently starting to establish itself as the
low-level graphics interface for Linux (and others?), with X & others
to be layered on top of this. So basing the Windowing System on GGI
would probably allow you to reap the benefits of the graphics-device
drivers for GGI being implemented by others (including possibly the
manufacturers themselves), whilst leaving you much lee-way in the
Windowing System, since GGI is very low-level (if you don't use
libGGI, you get even more low-level access, if that should be needed,
IIRC). Also with the GGI, it might be possible to let X and direct
CLIM/LispOS coexist on the same computer (either on the same, or
different displays, since GGI is supposed to support multi-headed
operation), which would probably be very useful in the beginning, as
it let's you continue to use Emacs&Co. until you have native
replacements...
And maybe there'll be (or is already) some way to mix&match X and GGI
applications in one desktop, so you could even deploy applications
easily to run in other people's desktops...
There's also the Berlin effort, which is more high-level and CORBA
based, but maybe they have low-level access hatches (it's GGI based
IIRC)...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai <····@acm.org> writes:
> It seems that the GGI is currently starting to establish itself as the
> low-level graphics interface for Linux (and others?), with X & others
> to be layered on top of this. So basing the Windowing System on GGI
> would probably allow you to reap the benefits of the graphics-device
> drivers for GGI being implemented by others (including possibly the
> manufacturers themselves), whilst leaving you much lee-way in the
> Windowing System, since GGI is very low-level (if you don't use
> libGGI, you get even more low-level access, if that should be needed,
> IIRC).
Good idea. We waited for Flux to come out. Now let's wait for GGI to
establish itself. If we plan it right, we can spend all our time
waiting for the right software & will never have to code anything.
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
In article <··············@blinky.bfr.co.il>,
·······@bfr.co.il (Harvey J. Stein) writes:
> Pierre Mai <····@acm.org> writes:
>
> > It seems that the GGI is currently starting to establish itself as the
> > low-level graphics interface for Linux (and others?), with X & others
> > to be layered on top of this. So basing the Windowing System on GGI
> > would probably allow you to reap the benefits of the graphics-device
> > drivers for GGI being implemented by others (including possibly the
> > manufacturers themselves), whilst leaving you much lee-way in the
> > Windowing System, since GGI is very low-level (if you don't use
> > libGGI, you get even more low-level access, if that should be needed,
> > IIRC).
>
> Good idea. We waited for Flux to come out. Now let's wait for GGI to
> establish itself. If we plan it right, we can spend all our time
> waiting for the right software & will never have to code anything.
That's been the LispOS group's plan for quite a while now.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <··············@blinky.bfr.co.il>,
> ·······@bfr.co.il (Harvey J. Stein) writes:
> > Pierre Mai <····@acm.org> writes:
> >
> > > It seems that the GGI is currently starting to establish itself as the
> > > low-level graphics interface for Linux (and others?), with X & others
> > > to be layered on top of this. So basing the Windowing System on GGI
> > > would probably allow you to reap the benefits of the graphics-device
> > > drivers for GGI being implemented by others (including possibly the
> > > manufacturers themselves), whilst leaving you much lee-way in the
> > > Windowing System, since GGI is very low-level (if you don't use
> > > libGGI, you get even more low-level access, if that should be needed,
> > > IIRC).
> >
> > Good idea. We waited for Flux to come out. Now let's wait for GGI to
> > establish itself. If we plan it right, we can spend all our time
> > waiting for the right software & will never have to code anything.
>
> That's been the LispOS group's plan for quite a while now.
The smart thing is to develop the (portable) CL apps necessary to give
a lisp-machine personality on top of unix. If you do this, then you
cut out the necessity of:
- Choosing which Common Lisp implementation to use.
- Choosing which unix to implement on top of.
- Writing device drivers/PCI crap/... for all the different kinds of
hardware out there.
This allows getting a sort of user level lisp machine feel as soon
as possible. It's also necessary anyway even if you're going to have
lisp from the metal up - little of the work would be thrown away. At
some low level you'd just rip out the cl/unix layer & plug in a
cl/lispos layer. It'll also give the maximum spread for the apps -
the system will be largely able to run on lispos or on unix & under a
variety of Common Lisp implementations.
The problem is that the *sexy* thing to do is to boot your machine
directly into the lisp interpreter, set lisp breakpoints in the tcp
stack, ... However, to do this you also have to settle on a class of
hardware, a particular Common Lisp implementation which will have to
be hacked to deal with the low level sorts of things needed inside the
kernel, ... Hell, once you've stuck yourself with needing a
particular Common Lisp implementation, you might as well even consider
one of the more modern Scheme implementations (like rscheme).
Now you even get to discuss whether the Common Lisp (or scheme)
compiler should produce C code which gets compiled by a C compiler
(i.e. - hybrid unix system) or whether it must produce machine code
(i.e. - pure lisp system, aka hellish to port system).
So, everyone wants to start with the sexy stuff & no one's willing to
do the apps, so the project's dead. Not that the sexy route is
impossible. After all, Linux was able to get from 0 to many full
fledged systems in ~8 years. However, lispos is a bigger project.
Linux was just kernel - compiler, libs, apps & a "well" defined kernel
interface already existed. Lispos is a much bigger project - it needs
the apps, everyone's still arguing about kernel & system interfaces,
and if you're going to do a pure lisp system you need some serious
compiler work too.
The sexy route could work *if* a couple of people just made the
decisions themselves & did it. But, like I said, "if".
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
Harvey J. Stein wrote:
>
> The smart thing is to develop the (portable) CL apps necessary to give
> a lisp-machine personality on top of unix.
To Messrs Coleman and McDonald:
When scanning the LispOS mail archive, I saw that this approach is
already being taken care of. Solution: CMUCL on top of Unix, don't
expect any fast results. Coleman to start this, McDonald to do that. The
postings were dated somewhere around april 98?, anyway at least half a
year ago.
Is this thing still being done?
Lars Lundback
> > The smart thing is to develop the (portable) CL apps necessary to give
> > a lisp-machine personality on top of unix.
>
> To Messrs Coleman and McDonald:
>
> When scanning the LispOS mail archive, I saw that this approach is
> already being taken care of. Solution: CMUCL on top of Unix, don't
> expect any fast results. Coleman to start this, McDonald to do that. The
> postings were dated somewhere around april 98?, anyway at least half a
> year ago.
>
> Is this thing still being done?
Different people are still working on bits and pieces. The various
CL implementations (CMU CL) continue to improve.
Unfortunately, between work and other things (getting married, etc),
I have not been able to put as much time in it, as I had wanted.
Such is life.
--
Richard Coleman
·······@math.gatech.edu
Lars Lundback wrote:
>
> When scanning the LispOS mail archive, I saw that this approach is
> already being taken care of.
The URL:s are:
http://cathcart.sysc.pdx.edu/lispos/ml/os/thread/msg02265.html
and a follow-up:
http://cathcart.sysc.pdx.edu/lispos/ml/os/thread/msg02275.html
/Lars
In article <·················@eralslk.ericsson.se>,
Lars Lundback <·······@eralslk.ericsson.se> writes:
> Harvey J. Stein wrote:
>>
>
>> The smart thing is to develop the (portable) CL apps necessary to give
>> a lisp-machine personality on top of unix.
>
> To Messrs Coleman and McDonald:
>
> When scanning the LispOS mail archive, I saw that this approach is
> already being taken care of. Solution: CMUCL on top of Unix, don't
> expect any fast results. Coleman to start this, McDonald to do that. The
> postings were dated somewhere around april 98?, anyway at least half a
> year ago.
>
> Is this thing still being done?
>
> Lars Lundback
I'm still working on my end. In between getting engaged, getting dumped, ...
Mike McDonald
·······@mikemac.com
In article <··············@blinky.bfr.co.il>, ·······@bfr.co.il (Harvey J.
Stein) wrote:
> This allows getting a sort of user level lisp machine feel as soon
> as possible. It's also necessary anyway even if you're going to have
> lisp from the metal up - little of the work would be thrown away. At
> some low level you'd just rip out the cl/unix layer & plug in a
> cl/lispos layer. It'll also give the maximum spread for the apps -
> the system will be largely able to run on lispos or on unix & under a
> variety of Common Lisp implementations.
>
> The problem is that the *sexy* thing to do is to boot your machine
> directly into the lisp interpreter, set lisp breakpoints in the tcp
> stack, ... However, to do this you also have to settle on a class of
> hardware, a particular Common Lisp implementation which will have to
> be hacked to deal with the low level sorts of things needed inside the
> kernel, ... Hell, once you've stuck yourself with needing a
> particular Common Lisp implementation, you might as well even consider
> one of the more modern Scheme implementations (like rscheme).
...
> So, everyone wants to start with the sexy stuff & no one's willing to
> do the apps, so the project's dead.
A couple of guys are maintaining the portable web server.
They are interested in having more common ground in the source
(streams, locks, processes, TCP/IP). If you have stuff
to contribute - do it. See also the list of possible projects.
Others are maintaining CMU CL and CLisp.
Don't talk. Write code.
--
http://www.lavielle.com/~joswig
From: Fernando D. Mato Mira
Subject: Lisp through the back door (was: LispOS, LispVM projects?)
Date:
Message-ID: <3652A46A.5F469C66@acm.org>
Harvey J. Stein wrote:
> The smart thing is to develop the (portable) CL apps necessary to give
> a lisp-machine personality on top of unix.
Yes. The project is huge, conflictive, and worse, the few people interested
are are too busy with their jobs. We need to build developer mindshare.
One thing that might work could be:
- Somebody creates an RPM for scsh, so Linux distributions start bundling as a
basic tool.
- Somebody developes a `lambdaconf' in scsh that beats the heck out of Autoconf
(imagine having config test
libraries so that people wouldn't need to go ripping off tests from this and
that
configure.in file!).
- People start using lambdaconf and that motivates some to maintain scsh.
- Some start writing scsh scripts for other purposes.
- Newcomers (including VB types) start seeing all those parens in scripts coming
with different apps,
and think that's some quite usual Unix thing, and they buy into it.
- Some people want to start writing real programs with a real compiler. More
compiler maint.
- Now they need FFIs to libraries.
- Now they want _real_ lisp libraries.
- Now they think C,C++,*x sucks and want a Lisp OS (better yet, they want
Lisp/Java/Smalltalk/Eiffel-oriented _hardware_)
It wouldn't hurt either if some Lisp guerrillas created their own Linux distro
where all sh scripts are incrementally migrated to scsh. Some are so trivial
anybody could contribute one in the 5 minutes before dinner gets ready..
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM HTTP: www.csem.ch
Jaquet-Droz 1 email: ········@acm.org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
From: "Fernando D. Mato Mira" <········@acm.org>
Subject: Lisp through the back door (was: LispOS, LispVM projects?)
Newsgroups: comp.lang.lisp,comp.lang.scheme
One thing that might work could be:
- Somebody creates an RPM for scsh, so Linux distributions start bundling
as a basic tool.
From time to time people like Fernando ask about copyright info & putting scsh
on some Linux distribution or another. So let me pass on some interesting news
and also make a little statement about copyright.
The news:
Jonathan Rees came by my office yesterday and mentioned that he and Kelsey
were close to getting Scheme48's copyright massively liberalised -- up to
BSD or X levels. So that would make life a lot easier for flooding the world
with Scheme48 bits.
Scsh Copyright:
The source files to scsh are usually copyright "Olin Shivers", or the other
main author (usually Carlstrom, Albertz, or Fisher), or sometimes just
"The Scheme Underground" -- whatever that might be. I have, to date, retained
full rights on the source. Let me explain why.
It's not because I think it's going to make me a lot of money.
I'm delighted for people to steal the source or the design or the underlying
ideas. That is why I wrote the thing. I give real Scheme implementors, such as
Jim Blandy, major encouragement to do exactly this. See my essay on "the 80%
problem" at the beginning of my SRE spec & tutorial for the attitudes behind
this:
http://www.ai.mit.edu/~shivers/sre.txt
I've kept tight control of scsh to date because I am afraid some bozo is going
to come along, make a few "improvements" to the design, which will in fact be
deep screwups, call it "scsh++" or "gnu scsh" or something, and release it. In
short, I'm trying to control the *name* "scsh."
I've had bad experiences before. When you say m-x shell or m-x run-scheme or
basically run any process in an emacs buffer, you run code I wrote for emacs,
a package called "comint.el". When the FSF adopted comint.el, RMS threw out
several of the most useful history-search commands, then another FSF hacker
went in and tweaked some of the other commands (this wasn't Simon Marshall; it
was a predecessor of his). Then the package accreted an enormous amount of
hairy auxiliary code that added a lot of fragile machinery to the design --
code I had made a point of *not* adding over the course of several years. I
had carefully tuned that package so that all the pieces *fit together* in nice
ways; these tweaks destroyed that. As a result, I've never had a satisfying
process-in-a-buffer experience since the gnu project adopted my source. Until
the day comes when I decide to grit my teeth, and dive back into that mess of
code for a solid week, I just have to grin and bear it.
I've seen "improvements" to scsh along the same lines -- changes that aren't
sensitive to the distinction between syntax (notation), and data structure.
I've had arguments with RMS that make clear he and I have fundamental
disagreements about exactly this issue. I really don't want to see scsh go
the same road.
Now, you may think this puts me in the "cathedral" camp, vs the "bazaar" camp,
and that is somewhat true. Good design is very hard -- hard for me,
anyway. Quality source code is rare. People who worry about security and
robustness run "cathedral" systems such as FreeBSD or NetBSD, rather than
Linux. But note that "cathedral" development groups are usually much more open
than one would infer from Raymond's simplistic distinction -- the FreeBSD
group, for example, puts their whole source tree up for network CVS access,
and have stated that anyone who makes a serious change to the source will be
given write access to the repository.
On the other hand, in over five years, I've had exactly one guy who popped
up off the net and volunteered to hack scsh... actually do it. And many have
started. No one has ported scsh to another Scheme platform, although many are
interested. If a serious Scheme implementor ever does a complete port of the
scsh Unix API to another platform, I am not going to let the source copyright
stand in his way.
I'm not committed to the current copyright strategy. I've never said "no" to
anyone who was nice enough to actually ask for permission to do anything at
all with scsh, commercial or otherwise. I'd be happy to entertain alternate
strategies. If you think the current copyright is a barrier to your getting
something done, you are almost certainly mistaken.
So, back to Fernando's post:
- Somebody developes a `lambdaconf' in scsh that beats the heck out of
Autoconf (imagine having config test libraries so that people wouldn't
need to go ripping off tests from this and that configure.in file!).
- People start using lambdaconf and that motivates some to maintain scsh.
- Some start writing scsh scripts for other purposes.
- Newcomers (including VB types) start seeing all those parens in scripts
coming with different apps, and think that's some quite usual Unix
thing, and they buy into it.
Yeah, a Scheme autoconf would be nice. As would a scsh knockoff of make(1).
Boy, I hate make for its horrible syntax. A good macro and some auxiliary
support routines would do it. You already have the process notation for
describing the commands to execute -- stuff like (cc ,@flags ,from -o ,to).
It wouldn't hurt either if some Lisp guerrillas created their own Linux
distro where all sh scripts are incrementally migrated to scsh. Some are
so trivial anybody could contribute one in the 5 minutes before dinner
gets ready..
I have rewritten a lot of the /etc scripts in my linux box in scsh -- mostly
ppp, dhcp, and pcmcia stuff; boy, is it pleasant.
Of course, you'd have to put a self-contained scsh with a statically-linked
heap in /bin so the really basic, hindbrain scripts could run -- but that's
no big deal.
David Fisher and I developed a lot of useful technology for doing this kind of
thing last summer, including an argv[] switch-parser, and an expect(1)
macro. I haven't released this, and probably won't until after I've rolled out
a huge chunk of more-basic stuff I've done lately -- the new regexp system,
and the new list, vector, string, sort, etc. libraries I'm proposing as
SRFIs. But we'll get it out.
-Olin
Olin Shivers <·······@lambda.ai.mit.edu> writes:
> Jonathan Rees came by my office yesterday and mentioned that he and Kelsey
> were close to getting Scheme48's copyright massively liberalised -- up to
> BSD or X levels. So that would make life a lot easier for flooding the world
> with Scheme48 bits.
Oh so sweet. Scheme48 is such a divine implementation, not to
belittle other implementors mind you. Would this allow you to remove
the notification requirement for commercial use from scsh, and if so
would you plan on removing that? It's hard to get mgmt types to
invest in something which they cannot outright puchase the rights to
use commercially, or have a garuntee that they can use it
commercially.
> I'm not committed to the current copyright strategy. I've never said "no" to
> anyone who was nice enough to actually ask for permission to do anything at
> all with scsh, commercial or otherwise. I'd be happy to entertain alternate
> strategies. If you think the current copyright is a barrier to your getting
> something done, you are almost certainly mistaken.
Oh, BTW someone has done a port of scsh to guile, but I'm not sure
how complete it is. If something like this could be placed under GPL,
provided it used a different name possibly, it would make scsh much
more attractive to alot of people working on projects like Debian.
Presently it is relegated to the non-free bin, which means that I
can't use it for some of the infrastruture projects I am interested
in. If scsh itself could be given a copyright which satisfies the
Debian definition of free, then considering the possibly changes to
the scheme48 copyright, I could use it straight up in these
situations.
Perhaps there is some way to preserve the integrity of the name "scsh"
and still have a copyright which allows free source modification and
unrestricted use commercial or otherwise? It's obviously completely
your decision, and I don't mean to imply you have any moral or civic
responsibility to liberalize the license in that way.
> Perhaps there is some way to preserve the integrity of the name "scsh"
> and still have a copyright which allows free source modification and
> unrestricted use commercial or otherwise?
I believe this is the general intent of Raymond's "Artistic License"
(cute name). I'll work something out.
-Olin
Olin Shivers <·······@lambda.ai.mit.edu> writes:
>
> I believe this is the general intent of Raymond's "Artistic License"
> (cute name). I'll work something out.
Isn't the AL Larry Wall's work?
Klaus Schilling
Craig Brozefsky <·····@onshore.com> writes:
> Perhaps there is some way to preserve the integrity of the name "scsh"
> and still have a copyright which allows free source modification and
> unrestricted use commercial or otherwise?
Of course there is. The name can be trademarked. Look at TeX, for
example. The code is in the public domain (sort of), but the name is
strictly restricted to those programs that pass the TRIP test.
Copyright is a foolish way to protect a name; it just does not work.
It protects that code base, but it does not restrict the use of the
name by other code bases.
Antti-Juhani
--
%%% Antti-Juhani Kaijanaho % ····@iki.fi % http://www.iki.fi/gaia/ %%%
NOTE: I am migrating to a new setup. There may still be problems with
my mail/news headers, so *please* trust the above addresses more than
the addresses in the headers. I hope I'll get this working ASAP.
From: Kalle Niemitalo
Subject: Re: Lisp through the back door (was: LispOS, LispVM projects?)
Date:
Message-ID: <iznr9uwddc5.fsf@stekt41.oulu.fi>
"Fernando D. Mato Mira" <········@acm.org> writes:
> - Somebody developes a `lambdaconf' in scsh that beats the heck out of Autoconf
> (imagine having config test
> libraries so that people wouldn't need to go ripping off tests from this and
> that
> configure.in file!).
The `aclocal' program, which is part of GNU automake, grabs tests from
such libraries.
I'd still be interested in seeing a `lambdaconf' -- with Scheme,
quoting wouldn't be such a nightmare as it is with m4.
--
Kalle Olavi Niemitalo <····@stekt.oulu.fi>, http://stekt.oulu.fi/~tosi/
David A. Cobb wrote:
>
> [I'm a stranger here myself]
>
> Sounds like what is needed is someone to "own" the project for longer than
> a school year. Put all artifacts under GPL and let the community at it.
>
> Better would be a Godfather like Linus to create something coherent. Would
> Lars care to volunteer?
>
> No-one involved is likely to get rich on it. Is Linux a "commercial
> success?" Maybe not, but it's absolutely a gem. Just plain intellectual
> satisfaction has to count for something, or we should all surrender to The
> Emperor Bill.
>
> /David
Ahum.
I discovered the LispOS mailing list only recently. Some of the
respondents referred to themselves as "old Lisp farts". Delete "Lisp"
from that, and I fit nicely. The role of a Godfather is not difficult,
or burdening, since the most that can be expected is benevolence, active
interest, and knowing that one should never be condenscending. It's
rather the other way around; some have learnt that enthusiasm and
we-need-some-action are just as important.
I chose the LispOS subject because I thought it might serve as a focal
point, when discussing what may be missing in the currently available
environments. And this thread has some very good responses; several
observe that the starting level must be set right, when implementing an
extended Lisp environment.
Of course the starting level must be reasonably high. Existing driver
software, Unix, OS-kits, CMUCL and Hemlock, X11, (no one mentioned
Windows? haha) have been identified as components that could be used.
This approach, however, has been available, and has been used for a long
time. Anyone can pull down a free Lisp, with integrated graphic
functions, and start doing Lisp'ish things. Object modules for database
connections can be added. Etc. But a really new application-development
situation does not seem to be there.
This is the time to correct me: I think I still see the same _kind_ of
GUI widgets, the same _kind_ of object-archiving problems, the same need
to connect to subsystems that were not originally designed for this
purpose. The efficience issues _still_ keep popping up.
A LispOS discussion could at least clean the plate. Was not the most
attractive features of a LispM that it had all the needed basic
functionality inside, not glued to the outside? I suggest that there are
three main components that need some thinking:
- The object system tied directly to disk storage/file systems,
- GUI functions designed to support "intelligent" UI directly,
- Memory management directly supporting these two above.
One immediate solution is to fit one CL implementation, one graphics
kit, one OOD into one box. But isn't that what the commercial firms have
done, more or less? Then it should be fairly easy to whip up the killer
application the Lisp community seems to need.
Perhaps the simple answer is that it's no fun to lug those huge old
modules around? Perhaps Java got the enthusiastic response, merely
because it was perceived as new and exciting?
Ahum.
Lars
There's many differing points of view on how
to approach this thing, but I guess we all agree
in one thing: we will have no real lisp machine
or first-class citizenship while we keep stuck
with these dumb 32 and 64 bit CPUs.
Maybe while we discuss the high level things,
we should join these guys to start building what
we really want:
http://f-cpu.tux.org/
So, 68, 72, what?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
CSEM
CH-2007 Neuchatel
Switzerland
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
········@acm.org wrote:
>
> There's many differing points of view on how
> to approach this thing,
There certainly are. I just downloaded the entire mail archive, to see
if I can do some simple sorting. Some guys have said some really good
things on the approach angle. It seems however, that their views were
soon ripped apart and inspected down to the lowermost technical levels.
Not very constructive if you feel that consensus must be reached as to
_why_ one does this at all. I want to have the constructive, general
views in a separate folder. Excuse, in a separate, persistent object.
> but I guess we all agree
> in one thing: we will have no real lisp machine
> or first-class citizenship while we keep stuck
> with these dumb 32 and 64 bit CPUs.
>
> Maybe while we discuss the high level things,
> we should join these guys to start building what
> we really want:
>
> http://f-cpu.tux.org/
>
> So, 68, 72, what?
>
I guess you lost me there. Unless you are hinting at "an open,
collaborative environment"? Yes, perhaps citizenship, ie the sense of
belonging in an effort to bring out a future Lisp environment, is
missing?
/Lars
From: Fernando D. Mato Mira
Subject: Re: tagged CPU (was: LispOS, LispVM projects?)
Date:
Message-ID: <365075A5.3FBC8A8B@acm.org>
Lars Lundback wrote:
> ········@acm.org wrote:
>
> > but I guess we all agree
> > in one thing: we will have no real lisp machine
> > or first-class citizenship while we keep stuck
> > with these dumb 32 and 64 bit CPUs.
>
> I guess you lost me there. Unless you are hinting at "an open,
> collaborative environment"? Yes, perhaps citizenship, ie the sense of
> belonging in an effort to bring out a future Lisp environment, is
> missing?
I meant Lisp is a second-class citizen in stock hardware.
Think `30-bit fixnum'
BTW, I saw the other day this letter published in SIGPLAN about
floating point in CL, and ACL 5.0 beta was running some Gabriel benchmarks
w/o declarations at the same speed as a 1985 Symbolics!
I guess I now understand how some people still can bear running those
machines (it took me just a couple of days of slow pop-up menus and
S-Geometry
wireframes to just go for SGI back in '90).
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM HTTP: www.csemne.ch
Jaquet-Droz 1 email: ········@acm.org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
In article <·················@acm.org>, "Fernando D. Mato Mira"
<········@acm.org> wrote:
> I meant Lisp is a second-class citizen in stock hardware.
>
> Think `30-bit fixnum'
>
> BTW, I saw the other day this letter published in SIGPLAN about
> floating point in CL, and ACL 5.0 beta was running some Gabriel benchmarks
>
> w/o declarations at the same speed as a 1985 Symbolics!
This would really surprise me. Usually current Lisps are quite a bit
faster. My MCL compiles CL-HTTP in two minutes. I don't
know how many hours a 1985 Symbolics would need.
ACL numbers on a SGI R4000, Irix 6.2, stol^h^h^h^htaken from a recent Usenet
posting. I added the numbers of my laptop and of a Symbolics NXP1000.
Genera 8.3 acl 5.0 opt MCL 4.2/PBG3 292Mhz/MacOS 8.5
---------- ----------- -----------------------------
BOYER 3.333 BOYER 1.410 BOYER 0.434
BROWSE 4.567 BROWSE 1.250 BROWSE 0.586
CTAK 1.526 CTAK 0.100 CTAK 0.024
DDERIV 1.125 DDERIV 0.500 DDERIV 0.178
DERIV 0.988 DERIV 0.470 DERIV 0.162
DESTRU 0.568 DESTRU 0.100 DESTRU 0.056
DIV2 1.231 DIV2 0.480 DIV2 0.176
FFT 6.927 FFT 0.050 FFT 1.472
PUZZLE 1.442 PUZZLE 0.210 PUZZLE 0.593
STAK 1.088 STAK 0.210 STAK 0.024
TAK 0.093 TAK 0.120 TAK 0.092
TAKL 1.072 TAKL 0.100 TAKL 0.072
TAKR 0.098 TAKR 0.038 TAKR 0.014
TRAVERSE 9.458 TRAVERSE 1.270 TRAVERSE 0.781
TRIANG 33.350 TRIANG 2.900 TRIANG 2.879
The Symbolics is a NXP 1000 running Genera 8.3 with 8MW memory
on an Ivory rev4A microprocessor.
--
http://www.lavielle.com/~joswig
From: Christopher J. Vogt
Subject: Re: tagged CPU (was: LispOS, LispVM projects?)
Date:
Message-ID: <36509475.93D27653@computer.org>
Rainer Joswig wrote:
>
> In article <·················@acm.org>, "Fernando D. Mato Mira"
> <········@acm.org> wrote:
>
> > I meant Lisp is a second-class citizen in stock hardware.
> >
> > Think `30-bit fixnum'
> >
> > BTW, I saw the other day this letter published in SIGPLAN about
> > floating point in CL, and ACL 5.0 beta was running some Gabriel benchmarks
> >
> > w/o declarations at the same speed as a 1985 Symbolics!
>
> This would really surprise me. Usually current Lisps are quite a bit
> faster. My MCL compiles CL-HTTP in two minutes. I don't
> know how many hours a 1985 Symbolics would need.
>
> ACL numbers on a SGI R4000, Irix 6.2, stol^h^h^h^htaken from a recent Usenet
> posting. I added the numbers of my laptop and of a Symbolics NXP1000.
>
> Genera 8.3 acl 5.0 opt MCL 4.2/PBG3 292Mhz/MacOS 8.5
> ---------- ----------- -----------------------------
>
> [...]
> FFT 6.927 FFT 0.050 FFT 1.472
Lies, damned lies, and benchmarks! First, your time for ACL above is
optimized, where as the comment above by Fernando specificly stated
"w/o declarations". Secondly, I don't have a Lispm handy, but the
time for fft on a symbolics 3600(w/ FPU)! as published by Gabriel is 3.87
seconds. On my 133MHZ Pentium using ACL 5.0B I got a time of 3.33 seconds.
I also have timings from years ago on an XL400 w/ Genera 8.1.1 showing
equivalent performance to the 3600(w/ FPU).
The point I was trying to make in my paper was that using Lisp with
declarations you can get FP performance similar to C, Java etc. however,
without declartions it is only about as fast as 10 year old Symbolics
technology (a 133MHZ Pentium is probably about 100x a Symbolics 3600:
about 25x in click time and about 4x in architectural improvements).
Anyone who is interested, and doesn't get SIGPLAN Notices can read the
paper here: http://members.home.net/vogt/fft-paper.html
> [...]
>
> The Symbolics is a NXP 1000 running Genera 8.3 with 8MW memory
> on an Ivory rev4A microprocessor.
>
> --
> http://www.lavielle.com/~joswig
--
Christopher J. Vogt - Computer Consultant - Solving hard problems since 1979
http://members.home.com/vogt/
In article <·················@computer.org>, ····@computer.org wrote:
> > ACL numbers on a SGI R4000, Irix 6.2, stol^h^h^h^htaken from a recent Usenet
> > posting. I added the numbers of my laptop and of a Symbolics NXP1000.
> >
> > Genera 8.3 acl 5.0 opt MCL 4.2/PBG3 292Mhz/MacOS 8.5
> > ---------- ----------- -----------------------------
> >
> > [...]
> > FFT 6.927 FFT 0.050 FFT 1.472
>
> Lies, damned lies, and benchmarks! First, your time for ACL above is
> optimized, where as the comment above by Fernando specificly stated
> "w/o declarations". Secondly, I don't have a Lispm handy, but the
> time for fft on a symbolics 3600(w/ FPU)! as published by Gabriel is 3.87
> seconds.
The NXP 1000 does not have a FPU, though. I guess an Ivory
with FPU should be faster.
> The point I was trying to make in my paper was that using Lisp with
> declarations you can get FP performance similar to C, Java etc. however,
> without declartions it is only about as fast as 10 year old Symbolics
> technology (a 133MHZ Pentium is probably about 100x a Symbolics 3600:
> about 25x in click time and about 4x in architectural improvements).
;-)
> Anyone who is interested, and doesn't get SIGPLAN Notices can read the
> paper here: http://members.home.net/vogt/fft-paper.html
Thanks for the pointer.
--
http://www.lavielle.com/~joswig
From: Jeffrey Mark Siskind
Subject: Re: tagged CPU (was: LispOS, LispVM projects?)
Date:
Message-ID: <yq7ogq7au2g.fsf@qobi.nj.nec.com>
> The point I was trying to make in my paper was that using Lisp with
> declarations you can get FP performance similar to C, Java etc. however,
> without declartions it is only about as fast as 10 year old Symbolics
> technology (a 133MHZ Pentium is probably about 100x a Symbolics 3600:
> about 25x in click time and about 4x in architectural improvements).
Well, if you use the Stalin compiler for Scheme you can get FP performance
comparable to (and sometimes much better than) C *without* declarations.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
In reply to Rainer Joswig's comment:
ACL numbers on a SGI R4000, Irix 6.2, stol^h^h^h^htaken from a recent Usenet
posting. I added the numbers of my laptop and of a Symbolics NXP1000.
Genera 8.3 acl 5.0 opt MCL 4.2/PBG3 292Mhz/MacOS 8.5
---------- ----------- -----------------------------
[...]
FFT 6.927 FFT 0.050 FFT 1.472
Christopher Vogt said:
Lies, damned lies, and benchmarks! First, your time for ACL above is
optimized, where as the comment above by Fernando specificly stated "w/o
declarations".
I was involved in the ACL/SGI benchmark above. The "optimization" was just
doing a (declaim (optimize (speed 3) (safety 0) (debug 0))), not actually
putting declarations in the code. Otherwise, it was the "pure" Gabriel
code.
Part of it is likely the SGI's blazing FP.
Larry
--
Lawrence Hunter, PhD.
National Library of Medicine phone: +1 (301) 496-9303
Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673
Bethesda. MD 20894 USA email: ······@nlm.nih.gov