LispOS, LispVM projects?
mato...@acm.org
--
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
Mike McDonald
mato...@acm.org writes:
> What happened?
All talk, no work.
Mike McDonald
mik...@mikemac.com
j...@rebol.com
> In article <71vfvh$gd0$1...@nnrp1.dejanews.com>,
> mato...@acm.org writes:
> > What happened?
>
> All talk, no work.
>
Not true! John Morrison at MAK put a lot of work into a kernel
that was designed to run a VM that could support lisp.
What really happened is that the project petered out at the
beginning of the semester.
~jrm
j...@rebol.com
> In article <m2lnloj...@ivantheterrible.rebol.net>,
> j...@rebol.com writes:
> > mik...@mikemac.com (Mike McDonald) writes:
> >
> >> In article <71vfvh$gd0$1...@nnrp1.dejanews.com>,
> >> mato...@acm.org writes:
> >> > What happened?
> >>
> >> All talk, no work.
> >>
> >
> > Not true! John Morrison at MAK put a lot of work into a kernel
> > that was designed to run a VM that could support lisp.
>
> John Morrison is working on JJOS, a Java OS project. (Unfortunately,
> etherboot doesn't like any of my ethernet cards (even the NE2000 I bought
> specificly for it!) so I haven't been able to play with it much.)
Yes, but he believes this offers a good oportunity to slip lisp in via
the back door. To quote him, `What I really want is a LispM'.
> > What really happened is that the project petered out at the
> > beginning of the semester.
> >
> > ~jrm
>
> LispOS petered out long before this semester started.
The traffic surrounding it dropped dramatically in September of
1997, if I remember correctly.
Mike McDonald
j...@rebol.com writes:
> mik...@mikemac.com (Mike McDonald) writes:
>
>> In article <71vfvh$gd0$1...@nnrp1.dejanews.com>,
>> mato...@acm.org writes:
>> > What happened?
>>
>> All talk, no work.
>>
>
> Not true! John Morrison at MAK put a lot of work into a kernel
> that was designed to run a VM that could support lisp.
John Morrison is working on JJOS, a Java OS project. (Unfortunately,
etherboot doesn't like any of my ethernet cards (even the NE2000 I bought
specificly for it!) so I haven't been able to play with it much.)
> What really happened is that the project petered out at the
> beginning of the semester.
>
> ~jrm
LispOS petered out long before this semester started.
Mike McDonald
mik...@mikemac.com
Lars Lundback
>
> What happened?
>
Reading the LispOS mailing list, and some of the _very_ good remarks on
large software development, in current postings to this newsgroup, tells
you what happened:
Most people forgot to put up their basic goals before discussing
activities.
No one was able to put up a convincing goal that related to the question
Marcus G. Daniels put to the LispOS discussion:
"How is a LispOS supposed to be better than just writing lots
of programs in a Unix/Win95 Lisp, and using libraries like ILU,
etc. to talk to the world? "
And last, no target group for a Lisp OS was identified. But I found this
goal, submitted by Mike McDonald (who could, and should elaborate a bit
more on Why Nothing Happened):
"Personally, I'd like to have a PC LispM because of
sentimental reasons and it fits my personal needs.
But I don't for one second believe there's any chance
of it being a commercial success."
That description fits my own view of a Lisp OS exactly.
Lars Lundback
Rainer Joswig
<era...@eralslk.ericsson.se> wrote:
> "Personally, I'd like to have a PC LispM because of
> sentimental reasons and it fits my personal needs.
I would have use for such a system (which would be with some work,
some years away).
> But I don't for one second believe there's any chance
> of it being a commercial success."
I do.
Martin B. Pomije
(snip)
> No one was able to put up a convincing goal that related to the question
> Marcus G. Daniels put to the LispOS discussion:
>
> "How is a LispOS supposed to be better than just writing lots
> of programs in a Unix/Win95 Lisp, and using libraries like ILU,
> etc. to talk to the world? "
>
> And last, no target group for a Lisp OS was identified. But I found this
> goal, submitted by Mike McDonald (who could, and should elaborate a bit
> more on Why Nothing Happened):
>
> sentimental reasons and it fits my personal needs.
> of it being a commercial success."
>
>
> Lars Lundback
I think that a Lisp based OS could be success, both technically
and commercially.
I use NT and Unix at work, and they both really suck! With NT,
everything is trapped behind the GUI dialog boxes. On top of
everything else, its really shoddy. I can't leave it up for more
than a week without rebooting to reclaim the memory that it has
leaked. And this is on a machine with 64 meg! In Unix,
everything is in open data formats, but it's all incredibly
primitive text streams. And X is shit, in every possible
way.
If an operating system was created from the ground up to avoid
the stupidity of C and the "everything is a stream of bytes"
mentality it could be incredibly easy to manage,configure and
program. Just think, no more idiotic Unix device drivers that
treat every device in the universe like a teletype! A system
storage model based on persistent objects would be a
huge improvement in so many areas.
One big advantage is that the huge amount of complexity and
overhead that is need for processes in C/Unix would just go away.
Everything could be in the same address space, communicating
very efficiently.
By using the techniques of Kali Scheme,you could have programs
automatically take advantage of the parallelism of networked
computers. The network could become one Borg-like entity,
eliminating single points of failure by having RAID style
redundancy of the computations occuring.
The stuff that I have talked about would be either very
difficult or virtually impossible to graft onto Unix.
A Lisp-based OS that used on the Linux development model could
succeed the same way Linux did. Create an OS that runs well on
the most recent batch of hardware declared out of date by M$. By
having it do it's work incredibly reliably without fuss, a lot of
goodwill could be created and people would want to contribute.
--
*********************************************
Semi-encrypted email address: p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_ n_e_t_
All non-solicited commercial email will be billed $500.
Rolf-Thomas Happe
The OSKit is a framework and set of modularized library code together
with extensive documentation. Its goal is to make it easier for OS
developers to create a new OS; to run user code directly on the
hardware, including programming language runtimes; to port an existing
OS to a platform supported by the OS kit; or to enhance an OS to
support a wider range of devices, file system formats, or executable
formats.
From http://www.cs.utah.edu/projects/flux/oskit/html/.
This should help LispOS partisans to retain some hope.
rthappe
Mike McDonald
rth...@leonce.mathematik.uni-freiburg.de (Rolf-Thomas Happe) writes:
> Anyone noticed the Utah OSKit?
Yup, it was discussed last spring on the lispos mailing list. The next
version was suppose to be out any day then. Then the old release disappeared
for a while. Then they reappeared. I'm not sure if anyone has been tracking
it lately.
For those of you interested in that type of thing, there's also the
Exokernel stuff at MIT: http://www.pdos.lcs.mit.edu/exo/
Mike McDonald
mik...@mikemac.com
dste...@my-dejanews.com
rth...@leonce.mathematik.uni-freiburg.de (Rolf-Thomas Happe) wrote:
> Anyone noticed the Utah OSKit?
>
>
> This should help LispOS partisans to retain some hope.
It might be more practical to boot-strap off of an existing OS. CLSH (I hope
I got that right) is a Lisp based shell. I haven't seen or used it, but that
could be used as a shell on Linux instead of bash.
Your next step would be to build a complete desktop and window manager in Lisp
that runs on Linux.
From there, you could start to look at doing the kernal in Lisp.
The reason I suggest this approach is because there is only room for so many
OSs. The first priority should be to cap Windows.
As always, with the possible exception of CLSH, Lisp eq Common Lisp.
Lars Lundback
Well Fernando,
It seems that we have a priority problem in dealing with a Lisp OS. It's
a bit like the hen - egg situation. Which comes first: The applications
that would really benefit, or the OS illuminating a new scene where
applications can thrive?
I share the vision of a personal LispM that my co-responders have.
Having been into programming for the last 30 years, and sniffing around
Lisp for at least 20, I finally decided a year ago to draw my own map of
a personal pure-Lisp platform. The pages you guys you put on the
Internet have been invaluable.
My first motive is simple. I think it's a lot of fun. There are some
others: performance and clarity. To quote a novelist:
".. such was the nature of compromise: A condition that satisfied no
one, but left each with the comforting feeling that others had been done
in too."
I suspect that I have been done in too much. I sense that a Lisp OS
could help in bringing back clarity and performance. Then we'll see.
Regards, Lars
David A. Cobb
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
mato...@acm.org
Lars Lundback <era...@eralslk.ericsson.se> wrote:
> It seems that we have a priority problem in dealing with a Lisp OS. It's
> a bit like the hen - egg situation. Which comes first: The applications
> that would really benefit, or the OS illuminating a new scene where
> applications can thrive?
Well, there were FORTRAN and C compilers for Symbolics, so I guess
it would not be totally heretic to suggest that a C compiler is
needed. Now, a lot of programs that one might want to run (but _not_
maintain!) require more than C, but also a Unix personality, so maybe
it's necessary to look at the thing from a microkernel perspective.
(Who would care about writing a Unix personality on top of Lisp??)
Do any of the available ukerns look good for a lispm? Does it _have_
or is it better for it to be in Lisp, too? If starting from an available
one, what would need to be added (probably nothing removed, if Unix
is to be supported)?
Eventually, if one does not miss anything from Unix, one should
be able to configure the ukern to remove everything that is not
needed by Lisp, if that makes it more efficient, or avoid it altogether.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
CSEM
CH-2007 Neuchatel
Switzerland
-----------== Posted via Deja News, The Discussion Network ==----------
Christopher B. Browne
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, bed...@teal.csn.org on X interfaces.
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Peter Van Eynde
[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. pvan...@debian.org, pvan...@inthan.be
Look in keyservers for PGP key.
John Morrison
Geez, so *this* is where all you guys hang out. Shoulda known.
j...@rebol.com wrote:
>mik...@mikemac.com (Mike McDonald) writes:
>
>> In article <m2lnloj...@ivantheterrible.rebol.net>,
>> j...@rebol.com writes:
>> > mik...@mikemac.com (Mike McDonald) writes:
>> >
>> >> In article <71vfvh$gd0$1...@nnrp1.dejanews.com>,
>> >> mato...@acm.org writes:
>> >> > What happened?
>> >>
>> >> All talk, no work.
>> >>
>> >
>> > Not true! John Morrison at MAK put a lot of work into a kernel
>> > that was designed to run a VM that could support lisp.
>>
>> John Morrison is working on JJOS, a Java OS project. (Unfortunately,
>> etherboot doesn't like any of my ethernet cards (even the NE2000 I bought
>> specificly for it!) so I haven't been able to play with it much.)
>
>Yes, but he believes this offers a good oportunity to slip lisp in via
>the back door. To quote him, `What I really want is a LispM'.
You betcha. I'm thinking, "Trojan Horse."
>
>> > What really happened is that the project petered out at the
>> > beginning of the semester.
Well, er, somewhat embarrassingly, I'm kind of *OLD* for school.
Actually, however, the JVM *is* being written by a student. I'm just
writing the native code which supports it. However, I expect I'll
pitch in to help with the JVM's memory management and bootstrapping
code, and probably also with the first drivers (VGA, keyboard, and IDE
disk).
The reason I haven't released another snapshot of the sources is that
a Day Job Crisis reared its head, and it took about 2 weeks to kill
it. I hope to do more this weekend.
>> >
>> > ~jrm
>>
>> LispOS petered out long before this semester started.
>
>The traffic surrounding it dropped dramatically in September of
>1997, if I remember correctly.
I am somewhat surprised (shocked, really), that so few people have
volunteered (from either the JOS or LispOS communities) to pitch in.
If every line of every email and every web site were code, we'd be
(more or less) done by now. I am hoping that it's nothing I've/we've
said or written. I am hoping that will change once we start managing
the sources via networked CVS instead of monolithic tar/zip files. I
have called for volunteers on both the jos-kernel mailing list (the
archives for which have not been updated in months) and the LispOS
mailing list. If I appealed any harder for volunteers, my dignity
would suffer (and it needs all the help it can get in the best of
circumstances).
Actually, most of the people who responded at all and have been kind
enough to offer advice seem to be participating in this particular
USENET thread.
I hope somebody manages to pull this off even if I don't have s**t to
do with it. I'm getting kind of worried -- most of our newer
programmers seem to think that the only programming environment that
ever existed is the Visual C++ IDE, and a distinct and very vocal
minority are of the Linux Rules School. When discussions of the
relative merits of Windows and UNIX are discussed, their eyes kind of
glaze over when LispMs are mentioned -- do you know how hard it is to
explain Dynamic Windows to either a Microsoft or Linux fanatic? They
don't even know what I'm talking about, and have no idea that LispMs
ever existed.
Oh well. On to more mundane considerations: I'm trying to score a
working LispM with documentation, because I figure this will be much
more efficient (in terms of my effort). Maybe you guys who are going
to the upcoming user's group conference (I'm not going) can prevail
upon SOMEBODY to OK the release of either a band (or something) to go
along with the emulator. Whatever we can get permission to release is
what I should probably be working on.
(If you want to reply to me, please remove the "nospam" from my email
address in the header. Damned spammers.)
-jm
==== John Morrison ==== j...@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
Mike McDonald
j...@nospam.mak.com (John Morrison) writes:
>>> > What really happened is that the project petered out at the
>>> > beginning of the semester.
>
> Well, er, somewhat embarrassingly, I'm kind of *OLD* for school.
> Actually, however, the JVM *is* being written by a student. I'm just
> writing the native code which supports it. However, I expect I'll
> pitch in to help with the JVM's memory management and bootstrapping
> code, and probably also with the first drivers (VGA, keyboard, and IDE
> disk).
>
> The reason I haven't released another snapshot of the sources is that
> a Day Job Crisis reared its head, and it took about 2 weeks to kill
> it. I hope to do more this weekend.
I'm looking forward to the patch! :-) (John's code doesn't like my graphics
card for some reason.)
> Actually, most of the people who responded at all and have been kind
> enough to offer advice seem to be participating in this particular
> USENET thread.
I think there's actually only three people on the LispOS mailing list. The
rest are mailbots!
> I hope somebody manages to pull this off even if I don't have s**t to
> do with it. I'm getting kind of worried -- most of our newer
> programmers seem to think that the only programming environment that
> ever existed is the Visual C++ IDE, and a distinct and very vocal
> minority are of the Linux Rules School. When discussions of the
> relative merits of Windows and UNIX are discussed, their eyes kind of
> glaze over when LispMs are mentioned -- do you know how hard it is to
> explain Dynamic Windows to either a Microsoft or Linux fanatic? They
> don't even know what I'm talking about, and have no idea that LispMs
> ever existed.
I'm glad I'm not the only one having this nightmare!
> Oh well. On to more mundane considerations: I'm trying to score a
> working LispM with documentation, because I figure this will be much
> more efficient (in terms of my effort).
This might be a bit misleading to others. From our private discussions, what
John is really looking for isn't a working machine so much as a working world
load with doecs and source code so that an emulator can be written to run the
world load in. Any of the of MIT CADR, TI Explorer, LMIs, ... would be ideal.
(MIT has agreed in principle to the CADR code but they can't find a copy of
the sources. TI also seems to have misplaced theirs, although they haven't
said whether they'd be willing to release it anyway. LMI has completely
disappeared. Only Symbolics is still around and they're determined to take
their code to the grave with them. Which is a shame even if it's their right
to do so.) So, if anyone has or know someone who has the sources to any of the
older LispMs, please, PLEASE, speek up!
> Maybe you guys who are going
> to the upcoming user's group conference (I'm not going) can prevail
> upon SOMEBODY to OK the release of either a band (or something) to go
> along with the emulator. Whatever we can get permission to release is
> what I should probably be working on.
Mike McDonald
mik...@mikemac.com
Mike McDonald
cbbr...@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
mik...@mikemac.com
Mike McDonald
pvan...@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
mik...@mikemac.com
Rainer Joswig
wrote:
> disappeared. Only Symbolics is still around and they're determined to take
> their code to the grave with them.
Symbolics is still alive and I wouldn't dig a grave.
Open Genera 2.0 is still in the works.
Raymond Toy
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
Mike McDonald
jos...@lavielle.com (Rainer Joswig) writes:
> In article <72i153$3cl$1...@spitting-spider.aracnet.com>, mik...@mikemac.com
> wrote:
>
>> disappeared. Only Symbolics is still around and they're determined to take
>> their code to the grave with them.
>
> Symbolics is still alive and I wouldn't dig a grave.
I think they are terminally ill. Granted, it takes a long time for a company
to die (unless they do something stupid to accelerate it!), so we have some
time to dig the grave. I wish it wasn't so.
> Open Genera 2.0 is still in the works.
Another funny! It's only a little over a year late and counting.
Mike McDonald
mik...@mikemac.com
Mike McDonald
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
mik...@mikemac.com
Kelly Murray
could actually be paid to waste time working on non-profitable stuff,
I proposed a "New Lisp Machine" to this newgroup.
This was right when Linux started to come alive
(I still have floppies with v97 kernels, and I still have
a v98 or 99 Linux running on one of my machines at home.)
I was amazed at the enthusiasm for a clone of 30 year old technology.
There was not much interest in the LispM project back then, so I
wasted my time on other stuff.
A couple years ago, the LispOS came up again, which I believe
was started by a big TCL vs Lisp, bytes vs objects discussion.
The good news is that this time there was more interest,
though the result has been about the same.
Let's hope we get a third concerted effort that makes more progress.
You can ready my view of the issues by reading a collected
archive of my own postings to the mailing list which I
threw together about a year ago.
http://www.intellimarket.com/silkos.html
I think my ideas and approach are sound, and have trouble understanding
why others don't want to pursue it. If you think you have
any insight into the issue, please let me know.
In any case, I continue to pursue my own personal effort,
that perhaps by the time I retire when I'm 65,
might actually be "finished", since that is about 25 years from
now, and Windows2002 written in Java+++ will probably still
be the operating system in use...
-Kelly Murray
Lyman S. Taylor
Mike McDonald <mik...@mikemac.com> wrote:
>In article <joswig-1311...@194.163.195.67>,
> jos...@lavielle.com (Rainer Joswig) writes:
>> In article <72i153$3cl$1...@spitting-spider.aracnet.com>, mik...@mikemac.com
>> wrote:
>> Symbolics is still alive and I wouldn't dig a grave.
>
> I think they are terminally ill.
I didn't save the message from info.slug, but I thought they were in
yet another "Chap. 11" phase. Or was it the slug gateway that
was dying? Or was that just the non open Genera stuff?
>> Open Genera 2.0 is still in the works.
Lisp machine layered on Unix. Hmmm, I wonder if it could run on
Alpha Linux. A "demo version" on a relatively inexpensive alpha linux
box might make so that a least some of those who have only every seen
the Visual C++ IDE would could see something different. :-)
--
Lyman S. Taylor "Twinkie Cream; food of the Gods"
(ly...@cc.gatech.edu) Jarod, "The Pretender"
Pierre Mai
> to do so.) So, if anyone has or know someone who has the sources to any of the
> older LispMs, please, PLEASE, speek up!
IIRC the sources for the BBN Lisp Machines' implementation of CL is
available on the CMU Lisp Repository, a file called bbn_cl.tgz. But
this is mostly Scheme Code IIRRC, since IIRRRC the BBN machines were
Scheme based (somebody who used them might correct me here...).
Regs, Pierre.
--
Pierre Mai <pm...@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
> > 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)...
Rainer Joswig
wrote:
> >> disappeared. Only Symbolics is still around and they're determined to take
> >> their code to the grave with them.
> >
> > Symbolics is still alive and I wouldn't dig a grave.
>
> I think they are terminally ill. Granted, it takes a long time for a company
> to die (unless they do something stupid to accelerate it!), so we have some
> time to dig the grave. I wish it wasn't so.
They are still there and that is enough for me.
> > Open Genera 2.0 is still in the works.
>
> Another funny! It's only a little over a year late and counting.
Progress has been slow but its really getting nearer to being
released. I have seen it running and it's not that bad.
Actually I'm starting to think about DEC Alpha prices. ;-)
Mike McDonald
Kelly Murray <k...@IntelliMarket.Com> writes:
> Back when I worked at the University of Florida, where I could
> could actually be paid to waste time working on non-profitable stuff,
> I proposed a "New Lisp Machine" to this newgroup.
I remember that! I still hold the same position that I did then. (It should
be X based and run on top of some other OS (use the underlying OS as the machine
dependant layer so we don't have to write hideous device drivers.).
> This was right when Linux started to come alive
> (I still have floppies with v97 kernels, and I still have
> a v98 or 99 Linux running on one of my machines at home.)
> I was amazed at the enthusiasm for a clone of 30 year old technology.
> There was not much interest in the LispM project back then, so I
> wasted my time on other stuff.
>
> A couple years ago, the LispOS came up again, which I believe
> was started by a big TCL vs Lisp, bytes vs objects discussion.
> The good news is that this time there was more interest,
> though the result has been about the same.
> Let's hope we get a third concerted effort that makes more progress.
>
> You can ready my view of the issues by reading a collected
> archive of my own postings to the mailing list which I
> threw together about a year ago.
>
> http://www.intellimarket.com/silkos.html
>
> I think my ideas and approach are sound, and have trouble understanding
> why others don't want to pursue it. If you think you have
> any insight into the issue, please let me know.
At the time, you were only letting out precompiled binaries for the Solaris
version of ACL. (I hope I remember the version correctly.) Since most of us
aren't Franz customers (anymore) and we don't have Sun boxes, it had limited
appeal to me. I, personally, am not interested in a HTML based interface. If I
wanted that, I'd join the JOS group. At the minimum, I'd like an X based
equivilant of a Symbolics environment. But that's me.
> In any case, I continue to pursue my own personal effort,
> that perhaps by the time I retire when I'm 65,
> might actually be "finished", since that is about 25 years from
> now, and Windows2002 written in Java+++ will probably still
> be the operating system in use...
>
> -Kelly Murray
I'm still working on my part of the LispOS. Since it's such a bugger, I
might be done in time for your retirement!
Mike McDonald
mik...@mikemac.com
Mike McDonald
In article <72ig8n$6...@pravda.cc.gatech.edu>,
ly...@cc.gatech.edu (Lyman S. Taylor) writes:
> In article <72ie70$gp6$1...@spitting-spider.aracnet.com>,
> Mike McDonald <mik...@mikemac.com> wrote:
>>In article <joswig-1311...@194.163.195.67>,
>> jos...@lavielle.com (Rainer Joswig) writes:
>>> In article <72i153$3cl$1...@spitting-spider.aracnet.com>, mik...@mikemac.com
>>> wrote:
>
>>> Symbolics is still alive and I wouldn't dig a grave.
>>
>> I think they are terminally ill.
>
> I didn't save the message from info.slug, but I thought they were in
> yet another "Chap. 11" phase. Or was it the slug gateway that
> was dying? Or was that just the non open Genera stuff?
Actually, they're no longer in Chap. 11. They were liquidated last Feb. (??)
Two guys who's names I can never remember bought the remains and are pushing
forward with 8.5 for Alphas and XLs.
>>> Open Genera 2.0 is still in the works.
>
> Lisp machine layered on Unix. Hmmm, I wonder if it could run on
> Alpha Linux. A "demo version" on a relatively inexpensive alpha linux
> box might make so that a least some of those who have only every seen
> the Visual C++ IDE would could see something different. :-)
They were going to look into Alpha Linux when they got a chance. The box
maybe cheap but Open Genera 8.3 was expensive.
Mike McDonald
mik...@mikemac.com
Mike McDonald
jos...@lavielle.com (Rainer Joswig) writes:
>> > Open Genera 2.0 is still in the works.
>>
>> Another funny! It's only a little over a year late and counting.
>
> Progress has been slow but its really getting nearer to being
> released. I have seen it running and it's not that bad.
>
> Actually I'm starting to think about DEC Alpha prices. ;-)
You come into an inheritence recently? OpenGenera used to be quite pricey
for an individual. Or do you know of a new price? :-)
Mike McDonald
mik...@mikemac.com
Rainer Joswig
wrote:
> In article <joswig-1411...@194.163.195.67>,
> jos...@lavielle.com (Rainer Joswig) writes:
>
> >> > Open Genera 2.0 is still in the works.
> >>
> >> Another funny! It's only a little over a year late and counting.
> >
> > Progress has been slow but its really getting nearer to being
> > released. I have seen it running and it's not that bad.
> >
> > Actually I'm starting to think about DEC Alpha prices. ;-)
>
> You come into an inheritence recently? OpenGenera used to be quite pricey
> for an individual.
I will not pay myself. ;-)
> Or do you know of a new price? :-)
It's $5000 for a single machine, multiple emulations at the same
time, lots of source, lots of software, ...
Sadly I can tell you that this is ******really******* cheap.
Ask the other vendors, who are offering similar Lisp environments
for Unix. Seems like you have to be a big telecom company or in the
military to be able to afford Lisp development under Unix
with a commercial system.
Rainer Joswig
wrote:
> Actually, they're no longer in Chap. 11. They were liquidated last Feb. (??)
> Two guys who's names I can never remember bought the remains and are pushing
> forward with 8.5 for Alphas and XLs.
>
> >>> Open Genera 2.0 is still in the works.
> >
> > Lisp machine layered on Unix. Hmmm, I wonder if it could run on
> > Alpha Linux. A "demo version" on a relatively inexpensive alpha linux
> > box might make so that a least some of those who have only every seen
> > the Visual C++ IDE would could see something different. :-)
>
> They were going to look into Alpha Linux when they got a chance. The box
> maybe cheap but Open Genera 8.3 was expensive.
It runs under DIGITAL Unix. It would be nice to get rid of
DIGITAL Unix either by replacing it with Linux or
(even better ;-) ) with Open Genera directly.
Unfortunately SPARCs are more popular here.
Rainer Joswig
wrote:
> > Sadly I can tell you that this is ******really******* cheap.
> > Ask the other vendors, who are offering similar Lisp environments
> > for Unix.
>
> Yup, compared to $4000 for CL and CLIM that some vendors charge, it is
a bargain, if
> you have an Alpha!
$4000 for CL ***and*** CLIM? Which vendor is that?
mato...@acm.org
- Evolutionary path to Mach
- I don't care about learning x86 asm
- I'd rather buy the prettiest and most compatible laptop
available : MacOS [X]; *Linux; Windows* on VPC
(Linux and Solaris on VPC, too?)
The only problem is that PPC is still a 32-bit arch
only.
Maybe there could be some marketing interest for
Apple to provide some kind of sponsoring? There are
also lisp-friendly insiders, and the company likes
well-designed things..
Lisp @ Apple - Chapter I: TI Explorer
Lisp @ Apple - Chapter II: Dylan
Lisp @ Apple - Chapter III: Lisp OS?
Lars Lundback
>
> [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
Rainer Joswig
My extension of your list:
Lisp @ Apple - Chapter 0: Coral Lisp
Lisp @ Apple - Chapter Ia: TI Explorer
Lisp @ Apple - Chapter Ib: Symbolics MacIvory
Lisp @ Apple - Chapter II: Macintosh Common Lisp (God's own development
enviroment)
Lisp @ Apple - Chapter III: AppleScript (looks a lot like Lisp
semantically, see SK8Script)
Lisp @ Apple - Chapter IV: Dylan
Lisp @ Apple - Chapter V: Newton (borrows a lot from Lisp)
Lisp @ Apple - Chapter VI: SK8
Lisp @ Apple - Chapter VII: MCL rescued
Lisp @ Apple - Chapter VIII: No more Lisp inside Apple: Cambridge Lab,
Newton Inc. and ATG closed
Lisp @ Apple - Chapter IX: MCL screaming on G3 machines
But I doubt there will be a Chapter X: Lisp OS.
Reason: Apple is very closed. No more Clones. No technical infos for Be.
Atleast you can get some info from the Linux for Mac sources.
If you want to have a Lisp machine on a Mac now: Replace the Finder with MCL.
Should be possible with some additional work (changing the name, setting
some bits).
Then boot. I haven't tried it - yet. ;-)
mato...@acm.org
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:
So, 68, 72, what?
Andi Kleen
mato...@acm.org writes:
> If on Linux, I would go with MkLinux for several reasons:
> - Evolutionary path to Mach
Mach seems to be a complete dead end.
-Andi
Lars Lundback
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
Fernando D. Mato Mira
> If you want to have a Lisp machine on a Mac now: Replace the Finder with MCL.
The idea is to run MacOS, Linux and the LispOS at the same time.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM HTTP: www.csemne.ch
Jaquet-Droz 1 email: mato...@acm.org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
Fernando D. Mato Mira
> mato...@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).
Rainer Joswig
<mato...@acm.org> wrote:
> Rainer Joswig wrote:
>
> > If you want to have a Lisp machine on a Mac now: Replace the Finder
with MCL.
>
> The idea is to run MacOS, Linux and the LispOS at the same time.
How does this work? AFAIK not even MacOS and Linux are able
to run at the same time...
Rainer Joswig
<mato...@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.
Christopher J. Vogt
>
> In article <365075A5...@acm.org>, "Fernando D. Mato Mira"
> <mato...@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/
Rainer Joswig
> > 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.
Christopher Stacy
Jeffrey Mark Siskind
> 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.
CsO
hi
whatever happened to the gnu hurd?
Keith M. Corbett
>(MIT has agreed in principle to the CADR code but they can't find a copy of
>the sources.
Have they contacted the usual suspects? the original spin-off founders?
>TI also seems to have misplaced theirs, although they haven't
I doubt they have the rights to redistribute the MIT and LMI code upon which
they built the Explorer OS.
>said whether they'd be willing to release it anyway. LMI has completely
>disappeared. <snip>
I lost my copies (masters) of the final LMI tapes some time ago. (I turned
out the lights at LMI - twice.) IIRC, when GigaMos folded, there was serious
controversy over who held the assets. Claimants included the founders, a
Japanese investor, the government of Saskatchewan, and employees in
Cambridge and Canada. (I am not making this up.)
>Only Symbolics is still around and they're determined to take
>their code to the grave with them. Which is a shame even if it's their
right
>to do so.) So, if anyone has or know someone who has the sources to any of
the
>older LispMs, please, PLEASE, speek up!
No, no, no, let's not start another thread about copyrights! :>
/kmc
Christopher B. Browne
>Andi Kleen wrote in message ...
>>In article <72ov7j$3jk$1...@nnrp1.dejanews.com>,
>>mato...@acm.org writes:
>>> If on Linux, I would go with MkLinux for several reasons:
>>> - Evolutionary path to Mach
>>Mach seems to be a complete dead end.
Development continues, probably most quickly in the form of the Debian Hurd
project. See <http://www.debian.org>, and look for mailing lists...
It has definitely not progressed *real* fast...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
cbbr...@hex.net - "What have you contributed to Linux today?..."
Harvey J. Stein
> 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
hjs...@bfr.co.il
Fernando D. Mato Mira
> How does this work? AFAIK not even MacOS and Linux are able
> to run at the same time...
But it's still not MacOS X.
MKLinux runs as a user-mode mach thread, so theoretically..
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM HTTP: www.csem.ch
Steven Perryman
>It's $5000 for a single machine, multiple emulations at the same
>time, lots of source, lots of software, ...
>Sadly I can tell you that this is ******really******* cheap.
>Ask the other vendors, who are offering similar Lisp environments
>for Unix. Seems like you have to be a big telecom company or in the
>military to be able to afford Lisp development under Unix
>with a commercial system.
Sadly so.
I have a Sun Ultra at home, but you try getting a Solaris eval copy of
something like Lispworks under the same terms that they entertain for stuff
like PCs or Linux ( $50 or free for the latter) . If they just laugh in your
face, I consider that being as 'polite' ...
Regards,
Steven Perryman
ste...@nortel.co.uk
Mike McDonald
That's been the LispOS group's plan for quite a while now.
Mike McDonald
mik...@mikemac.com
Harvey J. Stein
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".
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?
Lars Lundback
Lars Lundback
>
> 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
Rainer Joswig
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.
Fernando D. Mato Mira
> 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..
Olin Shivers
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
Craig Brozefsky
> 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.
Mike McDonald
Lars Lundback <era...@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.
>
>
> 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
mik...@mikemac.com
Richard Coleman
> > 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
col...@math.gatech.edu
Olin Shivers
> 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
Klaus Schilling
>
> 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
Antti-Juhani Kaijanaho
> 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 % ga...@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.
Larry Hunter
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: hun...@nlm.nih.gov
David Gadbois
> I think you have to have a 64 bit machine, or it's hopeless.
People keep making this point, but I just don't understand it. Last I
heard, the Ivory emulator did some tricks like holding the 8-bit tags
along with the 32-bit pointer value in a single 64-bit register, but
what does that really buy? Is there enough state that register
pressure is an issue? Does that alone give more than, say, a factor
of two in performance?
--David Gadbois
Kalle Niemitalo
> - 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 <to...@stekt.oulu.fi>, http://stekt.oulu.fi/~tosi/
g...@jill.westfalen.de
>How does this work? AFAIK not even MacOS and Linux are able
>to run at the same time...
There might be some solution to that, as soon as Sheepshaver for LinuxPPC
exists :-)
bye, Georg
Lyman S. Taylor
David Gadbois <gad...@lagavulin.cyc.com> wrote:
>Christopher Stacy <cst...@pilgrim.com> writes:
>> I think you have to have a 64 bit machine, or it's hopeless.
>
>People keep making this point, but I just don't understand it. Last I
>heard, the Ivory emulator did some tricks like holding the 8-bit tags
>along with the 32-bit pointer value in a single 64-bit register, but
>what does that really buy?
In short, speed.
[ On a 32 bit machine it isn't "hopeless" , just "slow as molasses" ]
Given that you are trying to emulate a machine with registers larger
than 32 bits. It means not haveing to use 2 registers to "model" 1.
For one this aviods having to do 2 loads get the data and the tag.
As opposed to one load to get both.
two registers one register
load data load data/tag
load tag mask tag into another register
That mask isn't going to have to reach out into the memory hierarchy
to get the data. Load once, use often. :-)
> Is there enough state that register
>pressure is an issue?
Your running an emulator. Register pressure is an issue from the
simply just because of that. You need registers for the emulator
and you need registers for the code being executed.
Secondly, the Symbolics archictecture had a stack cache which also needs
to be emulated. Preferable by registers. So that is consumer also.
I'd be very surprised with there were any underutilized registers
by the Symbolics emulator. It was written in hand tuned assembler.
I'm not sure how they delt with the issues of the symbolics being
Word addresses versus the byte address of the Alpha. [ that part of
one paper isn't on the web. ] I imagine this may be a register
consumer too.
> Does that alone give more than, say, a factor
>of two in performance?
Pushing losts of tuff out to the high levels of the memory hierarchy
typically has much more than a factor of two performance on high
clock rate processors like the Alpha.
--
Lyman S. Taylor "Computers are too reliable to replace
(ly...@cc.gatech.edu) humans effectively."
Commander Nathan Spring, "Starcops"
Tim Bradshaw
> For one this aviods having to do 2 loads get the data and the tag.
> As opposed to one load to get both.
> two registers one register
> load data load data/tag
> load tag mask tag into another register
> That mask isn't going to have to reach out into the memory hierarchy
> to get the data. Load once, use often. :-)
Actually, I think this may not be as much of an issue as all that. If
the data & tag are next to each other in address space, then those two
loads probably come down to a single memory fetch and then a cache
hit. If the cache hit is single-cycle then this may actually execute
as fast as the other case, perhaps depending on pipeline issues.
Of course this assumes a 64-bit+ path to main memory, but I think
everyone has that now (?).
Of course it's still a pain because it's a completely different
implementation, and because of register pressure.
--tim
David Gadbois
> David Gadbois <gad...@lagavulin.cyc.com> wrote:
> >
> >Last I heard, the Ivory emulator did some tricks like holding the
> >8-bit tags along with the 32-bit pointer value in a single 64-bit
> >register, but what does that really buy?
>
> In short, speed.
>
> [On a 32 bit machine it isn't "hopeless" , just "slow as molasses"]
Well, Open Genera 1.0 on a 190MHz 21064 was perfectly usable for
development. More recent 32-bit machines are roughly 4-8 times faster
than that old part, and, more importantly, have bigger caches with
more associativity. So I would expect a 32-bit version of the
emulator to be even more usable, even with a factor of two hit for a
32-bit emulator.
I still don't understand why folks are obsessing over some notion of
absolute performance of the emulator. I mean, jeez, if performance is
an issue, get rid of the emulation first.
> Given that you are trying to emulate a machine with registers larger
> than 32 bits. It means not haveing to use 2 registers to "model" 1.
>
> For one this aviods having to do 2 loads get the data and the tag.
> As opposed to one load to get both.
I gather that the current emulator uses two loads on the Alpha anyway:
The tag bits are stored separately from the contents. The emulation
of the SYS:MEMORY-READ instruction would go something like:
Mask the tag out of the register holding the argument address
Load the contents of the address
Compute the address of the tag
Load the tag
Mask in the tag to the contents
The rational was not wasting 24 bits for every (emulated) word of
memory and to allow for easier (unboxed) communication of values to
the run-time system.
--David Gadbois
Mike McDonald
David Gadbois <gad...@lagavulin.cyc.com> writes:
> ly...@cc.gatech.edu (Lyman S. Taylor) writes:
>> David Gadbois <gad...@lagavulin.cyc.com> wrote:
>> >
>> >Last I heard, the Ivory emulator did some tricks like holding the
>> >8-bit tags along with the 32-bit pointer value in a single 64-bit
>> >register, but what does that really buy?
>>
>> In short, speed.
>>
>> [On a 32 bit machine it isn't "hopeless" , just "slow as molasses"]
>
> Well, Open Genera 1.0 on a 190MHz 21064 was perfectly usable for
> development. More recent 32-bit machines are roughly 4-8 times faster
> than that old part, and, more importantly, have bigger caches with
> more associativity. So I would expect a 32-bit version of the
> emulator to be even more usable, even with a factor of two hit for a
> 32-bit emulator.
And I have to believe it'd beat the pants off of a 36X0 series.
> I still don't understand why folks are obsessing over some notion of
> absolute performance of the emulator. I mean, jeez, if performance is
> an issue, get rid of the emulation first.
Amen!!!! I don't use Genera for speed. (I'm still happy with the preformance
of a 3620 or XL1201. If a 32bit version of OpenGenera could give me that level
of performance, I'd be more than happy!) I use it for all of the functionality
it brings with it.
Mike McDonald
mik...@mikemac.com