(I'm having software problems and apologize for any duplicates of this
message.)
On a semi-regular basis people post messages to newsgroups and various
web-things on the topics of Lisp/Scheme Machines and Lisp/Scheme based
OSes. I have seen scattered posts about the following topics:
1. Maintaining, hacking, trading of Symbolics, TI, LMI and MIT lispm's.
2. Emulation of actual old Lisp machines.
3. Reviving of actual old Lisp OSes.
4. Building new (physical) Lisp/Scheme machines.
5. Writing new Lisp/Scheme OSes.
Without trying to suggest that Yet Another Project should be started
Real Soon Now, I thought it might make a certain amount of sense to set up
a newsgroup or mailing list specifically about Lisp Machines and Lisp OSes,
inclusive of scheme of course. I think it's a reviving theme, and both
retrocomputing and new design posts tend to generate quite some traffic.
Any thoughts? I don't have a clue if there's enough interest in this. Should
I forget about it, should I set up a majordomo list on my favourite
university server, or are people in the mood for a comp.os.lisp?
P.S. I set Followup-To to comp.lang.scheme arbitrarily, to avoid getting
yelled at for excessive cross-posting. I don't want to imply that scheme is
The Way To Go (although of course I secretly think so, mwahaha.)
--
/jaap
Jaap Weel <··········@caltech.edu> wrote in message news:<············@naig.caltech.edu>...
> (I'm having software problems and apologize for any duplicates of this
> message.)
>
> On a semi-regular basis people post messages to newsgroups and various
> web-things on the topics of Lisp/Scheme Machines and Lisp/Scheme based
> OSes. I have seen scattered posts about the following topics:
>
> 1. Maintaining, hacking, trading of Symbolics, TI, LMI and MIT lispm's.
> 2. Emulation of actual old Lisp machines.
> 3. Reviving of actual old Lisp OSes.
> 4. Building new (physical) Lisp/Scheme machines.
> 5. Writing new Lisp/Scheme OSes.
>
> Without trying to suggest that Yet Another Project should be started
> Real Soon Now, I thought it might make a certain amount of sense to set up
> a newsgroup or mailing list specifically about Lisp Machines and Lisp OSes,
> inclusive of scheme of course. I think it's a reviving theme, and both
> retrocomputing and new design posts tend to generate quite some traffic.
>
> Any thoughts? I don't have a clue if there's enough interest in this. Should
> I forget about it, should I set up a majordomo list on my favourite
> university server, or are people in the mood for a comp.os.lisp?
>
> P.S. I set Followup-To to comp.lang.scheme arbitrarily, to avoid getting
> yelled at for excessive cross-posting. I don't want to imply that scheme is
> The Way To Go (although of course I secretly think so, mwahaha.)
It should be either:
comp.os.symbolic
comp.arch.symbolic
comp.lang.arch
Because Lisp/Scheme machines are symbolic computers. They operate on
symbols not numbers.
And, machine architectures for languages are common in other language
groups as well.
Looking for hardware: turned up posts in Apl Forth, etc.
Comp.lang.arch or comp.arch.lang could handle topics such as those.
You might even want to make groups such as:
comp.lang.arch.scheme comp.lang.arch.lisp comp.lang.arch.functional
comp.lang.arch.symbolic
"Jaap Weel" <··········@caltech.edu> wrote in message
·················@naig.caltech.edu...
> (I'm having software problems and apologize for any duplicates of this
> message.)
>
> On a semi-regular basis people post messages to newsgroups and various
> web-things on the topics of Lisp/Scheme Machines and Lisp/Scheme based
> OSes. I have seen scattered posts about the following topics:
>
> 1. Maintaining, hacking, trading of Symbolics, TI, LMI and MIT lispm's.
> 2. Emulation of actual old Lisp machines.
> 3. Reviving of actual old Lisp OSes.
> 4. Building new (physical) Lisp/Scheme machines.
> 5. Writing new Lisp/Scheme OSes.
>
> Without trying to suggest that Yet Another Project should be started
> Real Soon Now, I thought it might make a certain amount of sense to set up
> a newsgroup or mailing list specifically about Lisp Machines and Lisp
OSes,
> inclusive of scheme of course. I think it's a reviving theme, and both
> retrocomputing and new design posts tend to generate quite some traffic.
>
> Any thoughts? I don't have a clue if there's enough interest in this.
Should
> I forget about it, should I set up a majordomo list on my favourite
> university server, or are people in the mood for a comp.os.lisp?
>
> P.S. I set Followup-To to comp.lang.scheme arbitrarily, to avoid getting
> yelled at for excessive cross-posting. I don't want to imply that scheme
is
> The Way To Go (although of course I secretly think so, mwahaha.)
I had written an os for my lang before (it is related to scheme, a lot of
scheme code should work on it).
I had gotten about to the early gui phase, did not have networking or such
written though...
it is still available on my older site:
http://bgb1.hypermart.net/
not sure how recent it is though. I had stopped working on os though as I
was running out of ideas, though a lot of the source has been reused.
I have not been reading this group much recently... for a while I had been
focusing on other non-lang-related issues...
On Mon, 14 Apr 2003 00:22:40 -0700, Jaap Weel <··········@caltech.edu>
wrote:
> On a semi-regular basis people post messages to newsgroups and various
> web-things on the topics of Lisp/Scheme Machines and Lisp/Scheme based
> OSes. I have seen scattered posts about the following topics:
[...]
> Real Soon Now, I thought it might make a certain amount of sense to set up
> a newsgroup or mailing list specifically about Lisp Machines and Lisp OSes,
> inclusive of scheme of course. I think it's a reviving theme, and both
A mailing list for discussing such issues is already available. See
www.tunes.org.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> A mailing list for discussing such issues is already available. See
> www.tunes.org.
If you refer to the LispOS list, it has been closed in 1999. See
<http://lists.tunes.org/archives/lispos/1999-February/002516.html>
Regards
Henrik
Henrik Motakef <··············@web.de> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>> A mailing list for discussing such issues is already available. See
>> www.tunes.org.
>
> If you refer to the LispOS list, it has been closed in 1999. See
> <http://lists.tunes.org/archives/lispos/1999-February/002516.html>
I think he refers to the LispM list:
http://lists.tunes.org/mailman/listinfo/lispm
As for a lispos list, I suppose I could open a list,
if there was sufficient pressure to.
Those who'd like to subscribe, please send me mail.
If there are enough of you, I'll do it.
But I think that at this point, most of what needed to be said was said,
and what remains is a SMOP.
http://catb.org/~esr/jargon/html/entry/SMOP.html
Hence, I think that what is needed at this point is a few people committed
to coding. Start by producing a good design or a good kernel of code,
and other people will follow you. If you're looking for someone to host
your effort, Sourceforge and/or the TUNES project will happily provide
internet service infrastructure.
That said, comp.lang.lisp, the LispM and SLUG mailing-list ought to be
enough to ask about generic Lisp Machine information.
On the TUNES and ll1 mailing-list and other such places, you will find
information for general system design.
For actual coding, you're mostly on your own.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
I don't program enough to be called a "programmer", and I don't unprogram
enough to be called a "non-programmer". So I'm a non-non-programmer, which,
in intuitionnistic logic, is not the same as a programmer. -- Far�
On Wed, 16 Apr 2003 22:03:38 +0200, Francois-Rene Rideau <····@tunes.org>
wrote:
> Henrik Motakef <··············@web.de> writes:
> > Paolo Amoroso <·······@mclink.it> writes:
> >> A mailing list for discussing such issues is already available. See
> >> www.tunes.org.
[...]
> I think he refers to the LispM list:
> http://lists.tunes.org/mailman/listinfo/lispm
Yes, I was referring to this list.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In the last exciting episode, Sander Vesik <······@haldjas.folklore.ee> wrote:
> I think its a bit worse than 'not sustainable level of interest' -
> it hasn't reached the stage where a failed project would leave
> enough stuff around that the next would have a lower barrier to
> success...
Indeed.
Numerous "LispOS" projects have come and disappeared over the years.
At this point, the only approach viable enough to "leave anything
behind" is the one that involves running the system atop one of the
"free Unix variants," so that someone else is responsible for
implementing support for various graphics and disk hardware.
The approach that could lead to building a whole OS would be to build
compiler tools generating ELF binaries, as that could lead to being
able to replace GCC by a Lisp compiler of some sort. Of course, it
still begs the question of what CPU architectures to look at; it would
be unfortunate to discover that the system was unusable on x86-64 or
IA-64 or whatever might prove popular next year...
--
output = ("cbbrowne" ·@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/lisposes.html
A Linux machine! because a 486 is a terrible thing to waste!
-- <···@wintermute.ucr.edu> Joe Sloan
I'd choose a Lisp based OS over Windows.
We'd have to start the Lisp OS in small pieces. We can't
expect to make a Lisp OS over night.
Some pieces that are needed:
Web-Server (CL-HTTP)
Sockets(ACL or Berkley Sockets in Lisp are avail.)
Disk Access(I don't know of any.)
Video Card Access+
Windowing(Lisp based OpenGL, and McCLIM
are a good start.)
I/O (a lot of work would need to get done.)
EMACS could be ported from ELISP to
ANSI CL to produce a ZMACS style
LISPM editor. :)
A lot of the network interfaces have
already been written in ANSI CL.
We need a SCSI or IDE interface,
better I/O and were off to a good
start.
When McCLIM is finished we'll
have a good start on Lispm-style
windowing.
It's not as big a project as it first
seems if you break it down into
pieces.
Who knows, we might even have
all the pieces needed--if somebody
would put them all together and
make them work to get her.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> I'd choose a Lisp based OS over Windows.
choose Unix over windows, it is something
that exists now and is in good working
order. I like/use freebsd.
>
> We'd have to start the Lisp OS in small pieces. We can't
> expect to make a Lisp OS over night.
>
> Some pieces that are needed:
>
> Web-Server (CL-HTTP)
> Sockets(ACL or Berkley Sockets in Lisp are avail.)
you can use the api as a guide but you must
still build the entire networking stack. and
support for a reasonable number of network
cards. This is a lot of work and specialized
work that it will take a good deal of time
to just come up to speed on.
> Disk Access(I don't know of any.)
file systems are much like network stacks,
lot of specialized and hard work.
> Video Card Access+
you are doomed here. Look at the
number of cards supported by X and
pick 10% and implement drivers for
them. Then you must maintain them
and add new cards also.
> Windowing(Lisp based OpenGL, and McCLIM
> are a good start.)
> I/O (a lot of work would need to get done.)
>
> EMACS could be ported from ELISP to
> ANSI CL to produce a ZMACS style
> LISPM editor. :)
Erik N said it would take him about 1 year
(+- 6months) to implement emacs in CL to
the point where it would be usable as an emacs.
Erik if I misquoted you please come back and
correct me.
>
> A lot of the network interfaces have
> already been written in ANSI CL.
You are talking about the layer 4+ stuff,
http, soap, ftp, snmp ... right? layer
1-3 is gonna be a real problem though
>
> We need a SCSI or IDE interface,
> better I/O and were off to a good
> start.
I have no idea what ugly things lurk here,
but I am sure they are there.
>
> When McCLIM is finished we'll
> have a good start on Lispm-style
> windowing.
McCLIM runs on top of X, what are you going
to do about X?
>
> It's not as big a project as it first
> seems if you break it down into
> pieces.
I would guess it is actually much worse.
Remember you also have to get all these
things playing well together.
>
> Who knows, we might even have
> all the pieces needed--if somebody
> would put them all together and
> make them work to get her.
This is why you have companies and VC money to
get/keep them running so you can bring it to
market and keep it there.
my personal experience in estimating
goes something like this:
phase 1: That does not look so hard. I was
usually off by at least 1 power of ten in the
amount of time it would take
phase 2: That does not look so hard, but I know
I cannot estimate worth a dam on big projects
so add at least one 0 to the time needed
phase 3: I can come up with a reasonable
guess. I am still working on phase 3, most
of the time.
marc
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Marc Spitzer <········@optonline.net> writes:
> Erik N said it would take him about 1 year
> (+- 6months) to implement emacs in CL to
> the point where it would be usable as an emacs.
An unrelated datapoint...
I ported Zmacs to CL at Symbolics in 1992. It was able to have it loaded
at the same time as Zmacs (it set itself up on Select Epsilon rather than
Select E) and had some pretty sophisticated parts working but was only
spot-tested. I seem to recall that Tags Multiple Query Replace From Buffer
worked, since that was one of my favorite 'complicated' functions.
It still had a dependency on the TV/DW window system for display, and I
had planned to change that to CLIM, but I was laid off before I was able
to start in on that.
I did the project mostly because Dave Moon had told me it was
impossible and I hate it when people say that. He had cited the
problems of array leaders and of special instance variables as too
integrated into Zmacs to get past in CLOS, but I found workarounds
that worked fine. A general purpose translation of these is hard, but
special-purpose translations of the specific situations that mattered
was pretty straightforward.
This all took place in the latter days of Symbolics, when most all of
the company's effort was singularly focused on the VLM (Virtual Lisp
Machine, later OpenGenera) and was never offered as a product. (I was
afraid that OpenGenera wouldn't be successful in saving the company
and wanted a fallback product. Management was annoyed at me for
wasting my time on such things, but then again, it was my time to
waste--I was already working overtime just doing ANSI CL work, and
this was 'just for fun' in between cycles to relax me.)
The intellectual property belongs to Symbolics, but it's in my
personal directory ( S:>kmp>tres> ) on the Symbolics backup tapes if
the Symbolics sources are ever purchased by anyone from their current
owner, or if that owner is ever convinced to pursue it. The system is
named TRES (Tres Replaces Eine's Successor).
In comp.lang.scheme Marc Spitzer <········@optonline.net> wrote:
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
>
>>
>> We'd have to start the Lisp OS in small pieces. We can't
>> expect to make a Lisp OS over night.
>>
>> Some pieces that are needed:
>>
>> Web-Server (CL-HTTP)
>> Sockets(ACL or Berkley Sockets in Lisp are avail.)
>
> you can use the api as a guide but you must
> still build the entire networking stack. and
> support for a reasonable number of network
> cards. This is a lot of work and specialized
> work that it will take a good deal of time
> to just come up to speed on.
It would be madness to. One should just use the existing
BSD stack. Building a quality TCP/IP stack from scratch
is a major undertaking, easily as complex as an initial
version for the rest of it.
>
>> Disk Access(I don't know of any.)
>
> file systems are much like network stacks,
> lot of specialized and hard work.
>
But unlike network, you don't have interoprability
problems from day one. so you could start with a simple
FAT style one, and then go to a primitive UFS style thing
and then go somewhere else.
>> Video Card Access+
>
> you are doomed here. Look at the
> number of cards supported by X and
> pick 10% and implement drivers for
> them. Then you must maintain them
> and add new cards also.
But this is not really critical - you can even start
with a serial console (support for which is a bonus
anyways), and stay in a text only mode for a good while.
IMHO its a mistake to *start* with teh mixing of the OS
and graphics layers.
>
>> Windowing(Lisp based OpenGL, and McCLIM
>> are a good start.)
>> I/O (a lot of work would need to get done.)
>>
>> EMACS could be ported from ELISP to
>> ANSI CL to produce a ZMACS style
>> LISPM editor. :)
>
> Erik N said it would take him about 1 year
> (+- 6months) to implement emacs in CL to
> the point where it would be usable as an emacs.
>
> Erik if I misquoted you please come back and
> correct me.
I understand a lot of people will disagree, but
native, full-reworked emacs should not be on the
critical or even necessary path for an os project.
Especially when other issues like "exactly how
will we get to a self hosted system that can run
a trivial program like the 'ls' equivalent for the
system" are very much unclear.
>>
>> We need a SCSI or IDE interface,
>> better I/O and were off to a good
>> start.
>
> I have no idea what ugly things lurk here,
> but I am sure they are there.
You will need a whole bunch of drivers, which will
need to deal with various issues like different PIO
modes, different DMA modes, ATAPI devices, different
drives supporting different subsets and so on. Not
exactly a trivial thing to write from scratch.
>> When McCLIM is finished we'll
>> have a good start on Lispm-style
>> windowing.
>
> McCLIM runs on top of X, what are you going
> to do about X?
Just support X? I mean really - given the chance of doing
Xserver with DRI etc from scratch and just wrapping
it in a compat layer, the answer seems to be pretty easy...
>
>>
>> It's not as big a project as it first
>> seems if you break it down into
>> pieces.
>
> I would guess it is actually much worse.
> Remember you also have to get all these
> things playing well together.
I don't think it becomes worse - it just displays the size
of the undertaking much more clearly. If one would draw up
a spreadsheet for the subtasks of i/o subsystem and networking,
one would see the enormity of those tasks and the benefits of
reusing existing solutions more clearly.
>
>>
>> Who knows, we might even have
>> all the pieces needed--if somebody
>> would put them all together and
>> make them work to get her.
>
> This is why you have companies and VC money to
> get/keep them running so you can bring it to
> market and keep it there.
>
> my personal experience in estimating
> goes something like this:
>
> phase 1: That does not look so hard. I was
> usually off by at least 1 power of ten in the
> amount of time it would take
Well, my estimate is probably as bad quality wise for
stage 1 as yours and my stage 1 estimate is 20 people
x 1 year of full-time work. And these will need to be people
who have large amounts of experience of OS programming,
don't dissapear mid-waythrough the project, etc.
>
> phase 2: That does not look so hard, but I know
> I cannot estimate worth a dam on big projects
> so add at least one 0 to the time needed
>
> phase 3: I can come up with a reasonable
> guess. I am still working on phase 3, most
> of the time.
>
>
> marc
--
Sander
+++ Out of cheese error +++
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <uznly3cau.fsf@dtpq.com>
>>>>> On Wed, 7 May 2003 15:58:48 +0000 (UTC), Sander Vesik ("Sander") writes:
Sander> In comp.lang.scheme Marc Spitzer <········@optonline.net> wrote:
>> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
>>
>>>
>>> We'd have to start the Lisp OS in small pieces. We can't
>>> expect to make a Lisp OS over night.
>>>
>>> Some pieces that are needed:
>>>
>>> Web-Server (CL-HTTP)
>>> Sockets(ACL or Berkley Sockets in Lisp are avail.)
>>
>> you can use the api as a guide but you must
>> still build the entire networking stack. and
>> support for a reasonable number of network
>> cards. This is a lot of work and specialized
>> work that it will take a good deal of time
>> to just come up to speed on.
Sander> It would be madness to.
It depends what you think a "Lisp OS" is supposed to be.
The Lisp Machine operating system was completely written
in Lisp; it did not sit atop any other operating system.
It was about 100 man-years of work (all by super wizards).
······@dtpq.com (Christopher C. Stacy) wrote ...
> It depends what you think a "Lisp OS" is supposed to be.
> The Lisp Machine operating system was completely written
> in Lisp; it did not sit atop any other operating system.
> It was about 100 man-years of work (all by super wizards).
Too bad this didn't take off. Too bad the stock hardware of the day
wasn't up to support it's performance requirements. Just imagine,
instead of Windoze, a Lisp OS had managed to conquer just about every
desktop.
The world would be a much different place today.
Entire sections of our modern language wouldn't exist: blue screen of
death, reboot, my computer crashed, reinstall, the computer ate my
homework, downtime, Microsoft Certified Idiot er Engineer, the system
is down, year 2000 compliant, Where do you want to go today, computer
glitch, Y2K, C#, .NET, ...
People using computers would actually get some work done. People
fixing computers today would be working for McDonalds making burgers
instead.
Oh what a wonderful world it would be ....
;-)
rgds
bk
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
wrote in message ························@news01.roc.ny.frontiernet.net...
>
> I'd choose a Lisp based OS over Windows.
>
> We'd have to start the Lisp OS in small pieces. We can't
> expect to make a Lisp OS over night.
LispOS -- Yet Again...
I removed c.l.scheme.
Most of the complaints against "LispOS from scratch" focus on the vast
problem of hardware.
I'd like to address that for a minute.
First let me say that I agree that the whole hardware layer is difficult,
and wide ranging because of all the products on top of badly implemented
standards.
But, it's not like any of this has to be "created", it mostly needs to be
"ported". It's all been done before.
Also, there is nothing that says this stuff has to be top-of-the-line
implementations on the first day!
An example is IDE. IDE, basic, low end IDE is absolutely brain dead to
implement. It really is. A couple of IO ports for addresses and commands,
and another couple to read/write the data. No DMA, no nothing. It's
limiting, like to 512MB or 2GB maybe, but it is truly simple to do.
FAST IDE gets much more complicated, but basic, usable "Get me data to and
from the harddrive" is really pretty simple.
There is no need to support the vast array of network cards either. My
understanding is that "NE2000" compliant is pretty darn generic and covers a
wide variety of cards, or pick one or two (like the popular 3COM card).
Those interested in the project will buy the appropriate $15 card.
Graphics cards are vastly complex today mostly because of all of the
acceleration and whatnot. Then, well, don't do that! It is unclear to me the
details of getting a graphics card into 1K x 768 and either 8 or 16 bit
color framebuffer mode, but it seems most every card can do it. And once set
up, the mechanism should be very similar.
If all else fails I KNOW you can get it into 640x480. That's "free".
Basic TCP/IP is not necessarily trvial, but there are several good examples
of the stack. There are several examples of getting the stack to run via
SLIP, etc. Again, your 1GB net card is probably not going to work today, but
ANY networking, like 1-2MB/s over a generic ethernet card with a slow, yet
straighforward driver using a bloated, yet functional IP stack will do the
job.
As for a filesystem, like someone else mentioned, steal FAT or steal FFS or
ISO 9660 so you can mount (IDE) CD-ROMs.
The whole point is that once you get a functional, self hosting system, the
rest is "simply" detail. The rest can grow incrementally. But until you get
a self hosting system, even if it only runs on limited hardware, you can't
get any community support at all.
Another benefit of using basic loweset common denominator hardware, is that
perhaps the first try should be done on an emulator rather than real
hardware.
The only nut really missing is a native Lisp compiler, and it seems to me
that CMUCL is the only choice there as a foundation unless you're starting
completely from scratch. With CMUCL, you get Hemlock which is EMACs enough
to give a solid leap forward.
That to me is the "hard part", porting the compiler.
What's the minimum "real" memory requirement for CMUCL to build itself.
64MB? 128? 256?? Memory we have, so even a VM can come later in the game. I
assume CMUCL has some kind of assembler built in to it.
Regards,
Will Hartung
(·····@msoft.com)
> >
> > I'd choose a Lisp based OS over Windows.
> >
> > We'd have to start the Lisp OS in small pieces. We can't
> > expect to make a Lisp OS over night.
>
> LispOS -- Yet Again...
>
> I removed c.l.scheme.
>
> Most of the complaints against "LispOS from scratch" focus on the vast
> problem of hardware.
>
> I'd like to address that for a minute.
>
> First let me say that I agree that the whole hardware layer is difficult,
> and wide ranging because of all the products on top of badly implemented
> standards.
>
quite agreed. as noted below a "common demominator" approach is possible.
> But, it's not like any of this has to be "created", it mostly needs to be
> "ported". It's all been done before.
>
but it is annoying (comming from an os dev standpoint).
there were some attempts at standardized drivers, but they (in my mind) came
out as horridly complex, and there is little support for them as of yet.
likely this partly because os coders are afraid of having to implement the
complexity of the interfaces, and the "use a prebuilt driver-interface lib"
idea probably doesn't fly that well either.
> Also, there is nothing that says this stuff has to be top-of-the-line
> implementations on the first day!
>
> An example is IDE. IDE, basic, low end IDE is absolutely brain dead to
> implement. It really is. A couple of IO ports for addresses and commands,
> and another couple to read/write the data. No DMA, no nothing. It's
> limiting, like to 512MB or 2GB maybe, but it is truly simple to do.
>
or you can just default to using lba devices. this fails on older drives,
but most everything (including some old 600-800MB drives) supports lba
anymore.
lba is not difficult to use compared with chs, as it is mostly either a flag
or different command code (I have since forgotten) and reinterpreting the
chs coords as a single 28bit num (more modern drives allow you to write the
values twice in order to get a 36bit num, but I don't remember the
details...).
> FAST IDE gets much more complicated, but basic, usable "Get me data to and
> from the harddrive" is really pretty simple.
>
yep.
> There is no need to support the vast array of network cards either. My
> understanding is that "NE2000" compliant is pretty darn generic and covers
a
> wide variety of cards, or pick one or two (like the popular 3COM card).
> Those interested in the project will buy the appropriate $15 card.
>
yes, but still a number of cards are not ne2k complient as well...
> Graphics cards are vastly complex today mostly because of all of the
> acceleration and whatnot. Then, well, don't do that! It is unclear to me
the
> details of getting a graphics card into 1K x 768 and either 8 or 16 bit
> color framebuffer mode, but it seems most every card can do it. And once
set
> up, the mechanism should be very similar.
>
> If all else fails I KNOW you can get it into 640x480. That's "free".
>
640x480x16 color.
mode-x: 320x240, 512x384, ... 256 color.
any vga compatible card can do these.
almost any modern card comes with "vesa" compatibility, which is
supprisingly rarely used.
as noted the problems with vesa are that it has no acceleration and is
annoyingly slow. if one wants to have reasonably wide-based card support
they have to access vesa via real or vm86 mode.
there are protected mode interfaces: a 16bit one in vbe2.0 and a 32bit one
in vbe3.0. a problem here is that vbe2.0 limits one to video cards newer
than about 1995, and 3.0 to about 1998 or 1999 I think.
vesa lists the various modes and color depths the card can do, thus you can
use nearly any mode the card can support.
> Basic TCP/IP is not necessarily trvial, but there are several good
examples
> of the stack. There are several examples of getting the stack to run via
> SLIP, etc. Again, your 1GB net card is probably not going to work today,
but
> ANY networking, like 1-2MB/s over a generic ethernet card with a slow, yet
> straighforward driver using a bloated, yet functional IP stack will do the
> job.
>
yes.
I had started to write this when I had been working on an os. I had lacked a
net card that would work in my test computer (I do not have any extra pci
ethernet cards extra right now), instead I was trying to get ppp to work.
I was having problems with this, as far as I could tell the linux pppd was
not (in general, or not consistently) following rfc 1661/1662...
> As for a filesystem, like someone else mentioned, steal FAT or steal FFS
or
> ISO 9660 so you can mount (IDE) CD-ROMs.
>
did my own fat driver.
fat is not complicated enough to really justify trying to steal it from
another os.
> The whole point is that once you get a functional, self hosting system,
the
> rest is "simply" detail. The rest can grow incrementally. But until you
get
> a self hosting system, even if it only runs on limited hardware, you can't
> get any community support at all.
>
yep.
an important problem with my system was that it was neither cl or a very
"standardized" scheme.
I had let it die as no one had seemed to care or wanted to talk to me about
it...
I am continueing effort in userspace (albeit now with a large portion of the
quake engine stuck on the side being a "dead horse"...).
one can much more readily try things out in userspace without having to keep
a "raw hardware" version working. annoying is that a lot of recent efforts
will end up requiring a bit to be written before I can get it back onto raw
hardware as well...
> Another benefit of using basic loweset common denominator hardware, is
that
> perhaps the first try should be done on an emulator rather than real
> hardware.
>
understood.
> The only nut really missing is a native Lisp compiler, and it seems to me
> that CMUCL is the only choice there as a foundation unless you're starting
> completely from scratch. With CMUCL, you get Hemlock which is EMACs enough
> to give a solid leap forward.
>
> That to me is the "hard part", porting the compiler.
>
I had written my own system, albeit it was interpreted.
performance wasn't a big enough issue to dictate writing a "real" compiler
(spitting out machine code to be run), rather I had just put some amount of
effort into optimizing the interpreter...
> What's the minimum "real" memory requirement for CMUCL to build itself.
> 64MB? 128? 256?? Memory we have, so even a VM can come later in the game.
I
> assume CMUCL has some kind of assembler built in to it.
>
it is not too difficult to write a ram counter (or fetch the ram count from
the bios). many systems should have plenty of ram to play with (my current
test computer has 128...).
Martha Stewart called it a Good Thing when"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>wrote:
> I'd choose a Lisp based OS over Windows.
>
> We'd have to start the Lisp OS in small pieces. We can't
> expect to make a Lisp OS over night.
>
> Some pieces that are needed:
>
> Web-Server (CL-HTTP)
This is surely the easiest piece, seeing as how people keep writing
web servers in all sorts of languages. There's one written in
Postscript. (I crap thee not.
http://wwwtcs.inf.tu-dresden.de/~godisch/debian/pshttpd/)
> Sockets(ACL or Berkley Sockets in Lisp are avail.)
> Disk Access(I don't know of any.)
> Video Card Access+
> Windowing(Lisp based OpenGL, and McCLIM
> are a good start.)
> I/O (a lot of work would need to get done.)
I would think the "theoretically feasible" approach to be to do
something akin to what the GnuSTEP people did; you start with
Free-Unix+X, and come up with an architecture atop that that permits
you to replace components with Lisp-based ones as they come available.
In the case of GnuSTEP, they started by building DGS atop X, and hope
to ultimately replace that with something "more to their taste."
> EMACS could be ported from ELISP to ANSI CL to produce a ZMACS style
> LISPM editor. :)
You are on bad drugs, you realize? :-)
> A lot of the network interfaces have already been written in ANSI
> CL.
> We need a SCSI or IDE interface, better I/O and were off to a good
> start.
Hmm? And maybe a memory manager?
> When McCLIM is finished we'll have a good start on Lispm-style
> windowing.
That's only any good when it has a substrate on which to run.
> It's not as big a project as it first seems if you break it down
> into pieces.
On the one hand, there are rather a lot of pieces.
On the other hand, people that start these projects with the idea "Oh,
I'll hack on it for six months and it'll be done" are just foolish.
On the gripping hand, unless the project /does/ get decomposed in this
manner, it is liable to either get designed to be too big or too
small, and be doomed from the onset.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www3.sympatico.ca/cbbrowne/lisposes.html
"There isn't any reason why Linux can't be implemented as an
enterprise computing solution. Find out what you've been missing
while you've been rebooting Windows NT." - Infoworld
Martha Stewart called it a Good Thing when"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>wrote:
> I'd choose a Lisp based OS over Windows.
>
> We'd have to start the Lisp OS in small pieces. We can't
> expect to make a Lisp OS over night.
>
> Some pieces that are needed:
>
> Web-Server (CL-HTTP)
This is surely the easiest piece, seeing as how people keep writing
web servers in all sorts of languages. There's one written in
Postscript. (I crap thee not.
http://wwwtcs.inf.tu-dresden.de/~godisch/debian/pshttpd/)
> Sockets(ACL or Berkley Sockets in Lisp are avail.)
> Disk Access(I don't know of any.)
> Video Card Access+
> Windowing(Lisp based OpenGL, and McCLIM
> are a good start.)
> I/O (a lot of work would need to get done.)
I would think the "theoretically feasible" approach to be to do
something akin to what the GnuSTEP people did; you start with
Free-Unix+X, and come up with an architecture atop that that permits
you to replace components with Lisp-based ones as they come available.
In the case of GnuSTEP, they started by building DGS atop X, and hope
to ultimately replace that with something "more to their taste."
> EMACS could be ported from ELISP to ANSI CL to produce a ZMACS style
> LISPM editor. :)
You are on bad drugs, you realize? :-)
> A lot of the network interfaces have already been written in ANSI
> CL.
> We need a SCSI or IDE interface, better I/O and were off to a good
> start.
Hmm? And maybe a memory manager?
> When McCLIM is finished we'll have a good start on Lispm-style
> windowing.
That's only any good when it has a substrate on which to run.
> It's not as big a project as it first seems if you break it down
> into pieces.
On the one hand, there are rather a lot of pieces.
On the other hand, people that start these projects with the idea "Oh,
I'll hack on it for six months and it'll be done" are just foolish.
On the gripping hand, unless the project /does/ get decomposed in this
manner, it is liable to either get designed to be too big or too
small, and be doomed from the onset.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www3.sympatico.ca/cbbrowne/lisposes.html
"There isn't any reason why Linux can't be implemented as an
enterprise computing solution. Find out what you've been missing
while you've been rebooting Windows NT." - Infoworld
"Christopher Browne" <········@acm.org> wrote in message
···················@ID-125932.news.dfncis.de...
>
> You are on bad drugs, you realize? :-)
>
Bad Drugs feel Oh so good, and make coding much much
more tolerable. :D (j/k) lol
But seriously,
MIT must have released the source to the CADR--once we get
an emulator as a starting point, it will be easier to build on it rather
than starting from scratch.
I wrote several people at MIT, and it looks promising that
some of the old Lispm sources might be/ or may have been
already released
--eager for some Lispers to download them and start hacking.
Click, click, click.
If anyone knows where 2 find Lispm sources that have been
made freely avail. please do us all a favor and tell us where
thay are.
Good bye 'blue screens'; hello Functional/OO OS ;)
Coredumps hahahahahahahahahahahahahaha
from now on we'll get
Error: Stack overflow in Compiled Function Tree-Copy
Select from
A):bort to top level
R):esume with a larger stack
I):nspect the code
D):ebuger
Enter Selection: R<ret>
etc. :)
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ullx0dcku.fsf@dtpq.com>
>>>>> On Wed, 21 May 2003 00:22:17 GMT, Franz Kafka ("Franz") writes:
Franz> "Christopher Browne" <········@acm.org> wrote in message
Franz> ···················@ID-125932.news.dfncis.de...
>>
>> You are on bad drugs, you realize? :-)
>>
Franz> Bad Drugs feel Oh so good, and make coding much much
Franz> more tolerable. :D (j/k) lol
Franz> But seriously,
Franz> MIT must have released the source to the CADR
By "released" I am guessing that you mean "made available
to the public for no charge". Why "must" MIT have that?
MIT commercially licensed that software for big bucks.
It is quite possible that they might have decided some time
in the past 24 years to change their policy and give it away,
perhaps because they feel it has no real commercial value.
(And I would agree.)
(Speaking of which, please bear in mind that when people
talk about "the Lisp Machine" and all its features, often
they are refering to Symbolics Genera. That has a *lot*
more features in it that the ancient CADR version of software.
Symbolics Genera is definitely not free; it's still being sold.)
Franz> I wrote several people at MIT, and it looks promising that
Franz> some of the old Lispm sources might be/ or may have been
Franz> already released
First you say it "must" have happened, then you say that you asked,
and someone at MIT told you something. But you don't say who you
asked, or what they told you. Who did you ask? What did they say?
Franz> --once we get an emulator as a starting point, it will be
Franz> easier to build on it rather than starting from scratch.
Based on what I know about that code, and about all the
improvements that were made to that code (that you won't have),
and about LispM emulators, and operating systems...
I'm not so sure that it will be easier to do it that way.
Franz> If anyone knows where 2 find Lispm sources that
Franz> have been made freely avail. please do us all a
Franz> favor and tell us where thay are.
I thought you were going to tell us.
Seriously.
"Christopher C. Stacy" <······@dtpq.com> wrote in message
··················@dtpq.com...
>
>First you say it "must" have happened, then you say that you asked,
>and someone at MIT told you something. But you don't say who >you asked,
or what they told you. Who did you ask? What did they say?
>
I asked Tom Knight awhile ago, and he gave me a this link
http://www.ai.mit.edu/people/tk/tk-sm-79.pdf
It has information about the Lispm.
Since he invented the Lispm; I think he can decide what he wants to do with
the sources. (I don't know if he released them--they may be in the public
domain, or under the MIT/X Licence. & most of the people I spoke with want
the code released, they might be some people who don't want them released
but the people I talked to, not everybody at MIT, wanted them released.)
He said that he'd check about releasing the sources--however,
the sources might have been lost. He was also unsure weather MIT
would release the sources but he thought they they were released
the same way as EMACS, and X Windows was.
I am not sure if MIT released the sources, or for that matter
even had the sources.
I could be wrong about them being released.
But, I get the feeling that people want the sources to be released, or might
have already released them--but the sources are lost.
If someone could recover them--I don't know--someone from MIT's AI Lab would
have to post a definitive answer.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> I asked Tom Knight awhile ago [...] Since he invented the Lispm; I think
> he can decide what he wants to do with the sources.
I don't know the details of who does control things, so I won't
comment on the actual situation without more information.
But independent of this situation, the assertion on its face appears
to be that knowing only who the physical content creator is gives you
sufficient information to conclude who controls the resulting content
legally. If so, I just want to say that this reflects a profound lack
of understanding of the intricacies of intellectual property law.
Moreover, coming back to the specific situation, the only other useful
piece of information I can add is that what makes the Lisp Machine valuable
is that it is the product of a large number of people collaborating on
the hardware AND software. It is no single person's effort. The idea
that some single person among that set can control the entire use of all
of that software is also highly questionable. The only way I can think of
that one person can control it is by buying it.
> He said that he'd check about releasing the sources--however,
> the sources might have been lost. He was also unsure weather MIT
> would release the sources but he thought they they were released
> the same way as EMACS, and X Windows was.
This is a hint that he'd have to "get permission" from MIT. MIT in turn
would have to check who it had written contracts with. As you can see,
there are multiple people involved. It's not "Tom's stuff". Tom was
just offering to act as facilitator in making some inquiries.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
writes:
>
> This is a hint that he'd have to "get permission" from MIT. MIT in turn
> would have to check who it had written contracts with. As you can see,
> there are multiple people involved. It's not "Tom's stuff". Tom was
> just offering to act as facilitator in making some inquiries.
>
I didn't want to post that Tom was looking into the matter, but
Christopher C. Stacy wanted to know who at MIT I was talking
to.
I guess it was to make sure I actually spoke to someone and was
not just Trolling to get people to work on the OS.
If MIT does release sources it will be for an older version, and
not for Genera or any other prop. source code--at least I don't
think it will be.
It's just because of how good the Lispm virtual memory system
was back in it's days, 8 Megs of Phyisical memory produced
100+ Meg of Virtual Memory.
I'd just hate to see the Lispm technology lost because of politicing.
I'd also love it if an MIT rep. would post MIT's offical position about the
issue here--this would resolve alot of legal issues that so many people have
been raising.
However, it seems to me--from talking to people @ MIT that most of the
people there don't even know what the Lispm was :( let alone who ones what,
or what will be/has been released.
I'm trying to add gas to the fire, to keep the emulator projects burning. So
what if a few flames get on usenet ;) because of
my efforts. :)
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> I'd also love it if an MIT rep. would post MIT's offical position
> about the issue here--this would resolve alot of legal issues that
> so many people have been raising.
For exactly this reason, don't expect them to do it. Competent people
rarely if ever expose their legal position in advance when money is on
the line. It's like showing someone else your poker hand. It totally
undercuts your negotiating position. Unless MIT has actively given up
on the value of this (and I seriously doubt that), I think you are being
naive in your expectation that this will happen.
> However, it seems to me--from talking to people @ MIT that most of the
> people there don't even know what the Lispm was
MIT is not a single thing. It is a bunch of people working on a bunch of
different things. If you call the US White House and find whoever you
happened to catch on the phone to be unaware of everything they've spent
US Budget on, would you be surprised? Just asking the question is asking
whoever you are talking to to expend resources...
> I'm trying to add gas to the fire, to keep the emulator projects burning.
Hmmm. I agree with your choice of metaphor, since I was visualizing a
camp fire and flames leaping out to burn those who have gathered to
cook hot dogs over it. I see this as an activity requiring more care
than I see you giving it. Just my personal opinion.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
>
> For exactly this reason, don't expect them to do it. Competent people
> rarely if ever expose their legal position in advance when money is on
> the line. It's like showing someone else your poker hand. It totally
> undercuts your negotiating position. Unless MIT has actively given up
> on the value of this (and I seriously doubt that), I think you are being
> naive in your expectation that this will happen.
>
It's this kind of attitude that is making it not so desirable for people to
work on Lisp Machine Emulators.
If some one at MIT--I sent an other letter--would clear this up it would
make the issue more clear.
I think BSDing, GPLing, or FSFing the Lispm code would be a benefit to the
Lisp community, I hope I am met by more help by people @ MIT than your
response would indicate.
It seems to me like it would be in MIT's interests as an educational
institution to spread info. about the Lispm around. Most people don't even
know what one is--if they were used more MIT would get a larger name
recognition and maybe a lot more contracts to do more research, esp. when
people realize how powerful, in programmer productivity, the Lisp Machines
were.
Are you fighting the rebirth of the Lispm because it might hurt the sales of
commercial Lisp systems, or for some other reason? I'd think that more
people in the Lisp community, if they could remember how it was to use a
Lispm, would want to see them back.
From: Joe Marshall
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <8yt0f6gj.fsf@ccs.neu.edu>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> >
> > For exactly this reason, don't expect them to do it. Competent people
> > rarely if ever expose their legal position in advance when money is on
> > the line. It's like showing someone else your poker hand. It totally
> > undercuts your negotiating position. Unless MIT has actively given up
> > on the value of this (and I seriously doubt that), I think you are being
> > naive in your expectation that this will happen.
>
> It's this kind of attitude that is making it not so desirable for people to
> work on Lisp Machine Emulators.
Kent is someone who has experienced first-hand a Lisp Machine company
going down the drain. I doubt it is an experience he wants to
repeat. I imagine that he is offering his honest and realistic
opinion in the hopes that it will help others avoid the same
experience.
But if you *really* want to build a lisp machine emulator, go ahead.
More power to you. Just don't expect very much enthusiasm from those
of us already burnt.
> It seems to me like it would be in MIT's interests as an educational
> institution to spread info. about the Lispm around. Most people don't even
> know what one is--if they were used more MIT would get a larger name
> recognition and maybe a lot more contracts to do more research, esp. when
> people realize how powerful, in programmer productivity, the Lisp Machines
> were.
Have you suggested this to MIT? I'm sure they'd love to make a name
for themselves in the Comp. Sci. community. Over time they could even
establish a reputation for innovation! Even one that goes beyond
computer science! Who knows where this could lead?
> Are you fighting the rebirth of the Lispm because it might hurt the sales of
> commercial Lisp systems, or for some other reason? I'd think that more
> people in the Lisp community, if they could remember how it was to use a
> Lispm, would want to see them back.
I, for one, (and I bet Kent, too) would *love* to have a `modern' lisp
machine. But I'd like to get one without the politics.
Joe Marshall <···@ccs.neu.edu> writes:
> But if you *really* want to build a lisp machine emulator, go ahead.
> More power to you. Just don't expect very much enthusiasm from those
> of us already burnt.
The issue of being burnt in the past is less important to me than the
possibility of being burnt in the future as a result of this.
Surely we cannnot keep him from doing this. But I predict that if
the project were to "succeed" and to be combined with 20-year-old sources,
I predict we'd hear a lot about how slow and featureless and out-of-date
Lisp is, and that we'd all suffer negative, not positive, public relations
impact.
> I, for one, (and I bet Kent, too) would *love* to have a `modern' lisp
> machine. But I'd like to get one without the politics.
I'd like to have Genera on modern hardware to use.
I'd like to have an older system for the same reason I still have the teddy
bear I had when I was 5 -- it just feels good and reminds me of happy times
past.
I don't think I'd get serious work done on an emulated cadr. I think
work done on that would be work taken away from work on native systems,
whether they be commercial systems like Corman or Digitool or Franz or
Xanalys or freeware such as cmu cl, gcl, clisp, or whatever.
Kent M Pitman <······@world.std.com> writes:
> I don't think I'd get serious work done on an emulated cadr. I think
> work done on that would be work taken away from work on native systems,
> whether they be commercial systems like Corman or Digitool or Franz or
> Xanalys or freeware such as cmu cl, gcl, clisp, or whatever.
I agree with Kent (all caveats regarding my newbe status applied). I
think there is a much more productive way to go.
The above mentioned Lisp systems should indeed be developed further as
they are now. And those that were missed. Lisp is not a dead
language or the end product for discovering the perfect language. The
same applies to development environments, etc.
I think a model to follow for a new LispM/LispOS would be something
very similar to the GNU Project. Set aside the license used by GNU.
I'm just talking about the technical approach. There are now a decent
number of Lisp development environments. That is the first step. The
first step for GNU was Emacs + GCC.
The GNU Project intended to create a purely Free OS, tools, and
applications that would run on affordable hardware. It took a long
time, but I think we can all agree that the project achieved that
goal. Following GNU's footsteps would probably result in success.
GNU came up with BASH (plus support libs like readline). That became
a popular shell to use on Unix systems long before the GNU project had
a kernel available (Linux is not even part of GNU).
For the X Window System, there are numerous desktop environments
available. For Windows and Mac, you are stuck (more or less) with
their standards. This is not really a problem. Java has had limited
success with running a GUI on all three systems. I suspect Lisp could
be used to fit right in with the native windowing system used on a
machine that it has been ported to.
It's really a question of incrementalizm. You start with basic tools
that look native to the target environment. That job is well
underway. Commercial Lisps are there. Or so I hear. I must confess
that when I programmed C++ for Win32, I really enjoyed working with
the VC++ IDE. That was a while ago, and I am sure Microsoft has made
even greater strides since then.
Lisp has an ANSI standard. What a great leaping off point that is!
Using ANSI CL, you can develop the tools and applications that are
important to you. For those who want to have LispMs back, those tools
would be the ones available to you on those machines. They can all
run on top of the existing operating systems. If you stick to ANSI
CL, your software is portable to ANSI compliant environments.
While Windows and Mac OS X have you locked into a GUI, Unix gives you
far more freedom. Yes, there are two big dogs on the block (KDE &
GNOME). There are also a lot of little dogs. No matter. Build
something better, and people will come. Mac OS X even has an X11
interface for running X11 apps. It works pretty darn well for a
beta. You can keep the X11 protocol support via the wire protocol for
remote apps and xlib.so for local apps and have a more modern GUI
environment that has better access to the hardware (for speed,
naturally).
POSIX is important for legacy Unix apps. I see no difficulty in
supporting that when someone decides to go pure Lisp. You really
don't want to throw away libc and other libs. Not until you have Lisp
replacements that are C callable.
Want to build a LispM? Don't do it with hardware. Do it with
software. Build world-class dev environments that will produce easily
instaled end products. Interface well with legacy systems. Take one
step at a time.
Whether it ever makes sense to build a hardware LispM again is
irrelevent. Modern machines are fast. If you build all the things I
have talked about in Lisp, then maybe hardware will be created to
provide an assist. However, I doubt it will be necessary. I think
hardware should be kept as simple and fast as possible. The compilers
should take full advantage of the hardware by having knowledge of it.
Tying the two together is a mistake, IMO, because not everyone will
enjoy Lisp. Also, Lisp will likely continue to evolve to be even more
powerful than it is now. So will scripting languages like Python,
Ruby, et al.
The bottom line is the language and development environment are ways
for the programmer to get things done. Developer time is more
expensive than runtime in general. Compilers can be created to give a
best of both worlds approach by taking the high level code created by
programmers and generating the best machine code possible. That is
what the tools are for. The idea is to boost programmer productivity
while producing acceptably fast code for the machine.
I didn't mean to ramble on so much. I'm sure people will have flames
for me. Go ahead. I have asbestos underwear.
--
(describe 'describe)
David Steuber <·············@verizon.net> writes:
> Following GNU's footsteps would probably result in success.
I am not so sure. The GNU project had (and has) some major advantages
compared to others, in particular :
1. An excellent programmer who was willing to work more than full
time for essentially nothing (RMS).
2. An existing specification and a prototype implementation (Unix)
available to many members of the target audience.
3. A strategy that put the wide knowledge of the specification ahead
of technical merit in importance. RMS knew very well how to
write a very good OS but (as far as I can tell) deliberately
chose an inferior system so that more people could contribute.
--
Robert Strandh
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
>
> I, for one, (and I bet Kent, too) would *love* to have a `modern' lisp
> machine. But I'd like to get one without the politics.
>
That's what I'm trying to do :)
It's the polticing that is killing the Lisp-spirit :( not the lang.
I'm not trying 2 |3 hard on Kent, I just want 2 keep Lisp alive,
and maybe even attract new blood 2 Lisp.
I have e-mailed MIT; I hope they respond favoriably--I hope
they realize the good PR that would come out of an opensource
Lispm, hopefully without 2 much politics attached.
From: Tim Bradshaw
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ey365o3286l.fsf@cley.com>
* Franz Kafka wrote:
> It's the polticing that is killing the Lisp-spirit :( not the lang.
In fact, it's the endless sitting around waiting for someone to
recreate some semi-mythical golden age when you should be writing
something *new*.
I now see that the Lisp community is like the free software community
taken to the logical extreme. The free software community has
laboured for 20 years, and come up with ... a Unix clone, and several
fairly functional Windows clones which interface to it. Well, at
least people want Unix machines and Windows machines, so while this is
depressing in terms of all that wasted effort at least it's not
commercially mad.
Large parts of Lisp community seem to want to to labour (or, in fact,
wants someone *else* to labour) for 20 years to reproduce ... Genera
and ITS. Not only totally lacking in imagination, but lazy (`let's
whine and whine and whine until someone releases the source), and a
commercial dead end.
Why can't we create something *new* instead? Sure Genera (I know) and
ITS (I assume) were great (Unix is fine too, and Windows is at least
habitable), but can't we, please, *move on* now, and make something
new?
--tim
Centuries ago, Nostradamus foresaw when Tim Bradshaw <···@cley.com> would write:
> Large parts of Lisp community seem to want to to labour (or, in fact,
> wants someone *else* to labour) for 20 years to reproduce ... Genera
> and ITS. Not only totally lacking in imagination, but lazy (`let's
> whine and whine and whine until someone releases the source), and a
> commercial dead end.
In the case of ITS, you can combine:
a) A PDP-10 emulator <http://www.inwap.com/pdp10/emulators/>
with
b) ITS images <http://www.cosmic.com/u/mirian/its/files/>
to actually
c) Build ITS atop an emulator...
<http://www.cosmic.com/u/mirian/its/itsbuild.html>
Which means that the irritating Unix Haters folk that worship ITS as
the One True Operating System have no excuse for not using it...
--
output = reverse("gro.mca" ·@" "enworbbc")
http://www.ntlug.org/~cbbrowne/oses.html
There are many intelligent species in the universe. They are all
owned by cats.
From: Joe Marshall
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <vfw3cb3r.fsf@ccs.neu.edu>
Christopher Browne <········@acm.org> writes:
>
> Which means that the irritating Unix Haters folk that worship ITS as
> the One True Operating System have no excuse for not using it...
They haven't gotten MacLisp running on it yet.
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <u1xyqudd6.fsf@dtpq.com>
>>>>> On 22 May 2003 10:25:12 -0400, Joe Marshall ("Joe") writes:
Joe> Christopher Browne <········@acm.org> writes:
>>
>> Which means that the irritating Unix Haters folk that worship ITS as
>> the One True Operating System have no excuse for not using it...
Joe> They haven't gotten MacLisp running on it yet.
Well, I don't know who "they" is supposed to be, but there
was a problem that the original distribution of the disk image
filesystem for ITS had a bunch of files that were corrupted.
When the trashed files were replaced with the real files,
MACLISP works fine.
From: Joe Marshall
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <8ysydc4p.fsf@ccs.neu.edu>
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 22 May 2003 10:25:12 -0400, Joe Marshall ("Joe") writes:
>
> Joe> Christopher Browne <········@acm.org> writes:
> >>
> >> Which means that the irritating Unix Haters folk that worship ITS as
> >> the One True Operating System have no excuse for not using it...
>
> Joe> They haven't gotten MacLisp running on it yet.
>
> Well, I don't know who "they" is supposed to be, but there
> was a problem that the original distribution of the disk image
> filesystem for ITS had a bunch of files that were corrupted.
> When the trashed files were replaced with the real files,
> MACLISP works fine.
I guess I saw something about the older distribution.
I'll have to poke around and see if I can't get it running.
Thanks a lot, cbbrowne. Now I have yet *another* thing on which to
waste my time.
After takin a swig o' Arrakan spice grog, Joe Marshall <···@ccs.neu.edu> belched out...:
> I guess I saw something about the older distribution.
> I'll have to poke around and see if I can't get it running.
>
> Thanks a lot, cbbrowne. Now I have yet *another* thing on which to
> waste my time.
Glad to be of service :-).
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','ntlug.org').
http://www3.sympatico.ca/cbbrowne/wp.html
"We English-speaking peoples should keep hold of the essential fact
about foreign languages: They exist to make us laugh."
-- John Derbyshire
Christopher Browne <········@acm.org> writes:
> Centuries ago, Nostradamus foresaw when Tim Bradshaw <···@cley.com> would write:
> > Large parts of Lisp community seem to want to to labour (or, in fact,
> > wants someone *else* to labour) for 20 years to reproduce ... Genera
> > and ITS. Not only totally lacking in imagination, but lazy (`let's
> > whine and whine and whine until someone releases the source), and a
> > commercial dead end.
>
> In the case of ITS, you can combine:
> a) A PDP-10 emulator <http://www.inwap.com/pdp10/emulators/>
> with
> b) ITS images <http://www.cosmic.com/u/mirian/its/files/>
> to actually
> c) Build ITS atop an emulator...
> <http://www.cosmic.com/u/mirian/its/itsbuild.html>
>
> Which means that the irritating Unix Haters folk that worship ITS as
> the One True Operating System have no excuse for not using it...
(I should self-identify as a contributor to the unix-haters mailing list,
which community launched the Unix Haters book. So I guess I must be one
of those irritating folks...)
Actually, they (we) didn't worship ITS per se, but the way of life it
represents. Dick Gabriel talks about this issue in his criticisms of
"The Right Thing", etc. I won't try to resummarize here. But it is
easy to argue that the extension of the ITS way went into the Lisp Machine,
since the very people who worked on ITS moved on to the Lisp Machine as
a group. So for the same reasons I wouldn't go back to the early LispM,
especially emulated, to get work done -- only for nostalgia -- I also
wouldn't go back to ITS.
And, to an extent, it has been not wholly incorrectly argued that systems
like Lisp on stock hardware have taken on a latter day role as a kind of
insulation from the operating system, providing as a natural effect of its
capability of layering abstractions, a way of digging yourself out of direct
contact with the operating system, so that the fact of using the host
operating system is ameliorated by Lisp's portable tools. (Not to say that
some other languages don't also do this. HyperTalk and HyperCard, for
example, was intended originally as a stealth path to replacing the Finder
shell on the Mac, I believe. Had it succeeded, I think the next step might
have been to change the underlying operating system to focus on its needs,
as Windows has focused on supporting _its_ browser.)
Incidentally, I've heard some call Emacs a similar tool. Some ITS refugees
faced with using TOPS-20 were not happy with it, but Emacs offered refuge
and really one hardly ever had to come out of it because one could live in
that cave pretty much all the time, using the occasional shell buffer within
Emacs for sometimes service operations like invoking Lisp before continuing
to use it within Emacs. As the proponents of Emacs continued to make gnu,
an interesting schism occurred wherein some of us use Emacs preciseliy to
escape the need to interact directly with the operating system upon which
Emacs often sits (Linux) ... even though it's the same people maintaining
both.
And, btw, I've been back to the ITS world and I've realized that what I
_really_ miss about it more than anything else was how much I felt aware of
other people around me, like in a MOO, back when it thrived. My dominant
feelign when we moved on to Tops-20 and VAX and so on after the ITS systems
went away was one of programming "with blinders on". No way to sense
friends coming and going. That feeling came back a bit later when Symbolics
created its converse system, unix created zephyr and newsgroups, and AOL
created instant messenger, and so on. But MOO is really the closest in
ideal to ITS by being a more coherent interactive programming and e-Living
space than these others. And MOO is not entirely unlispy either, since it
was done by Pavel Curtis, who had Lisp background (and, incidentally,
contributed to the CL error system design discussions). It's well worth a
look for people looking to expand their idea of what a programming space can
be.
The point of this rant, though, is to say that a great deal of good has
come from carrying the banner for that curious old operating system, and
making sure its ideas did not just die, regardless of how irritating that
has been to some people along the way.
From: Tim Bradshaw
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ey3wugi4nkz.fsf@cley.com>
* Kent M Pitman wrote:
> The point of this rant, though, is to say that a great deal of good
> has come from carrying the banner for that curious old operating
> system, and making sure its ideas did not just die, regardless of
> how irritating that has been to some people along the way.
Yes, of course I didn't mean that the ideas should be forgotten. What
annoys me is the seemingly endless attempts to blindly recreate some
lost nirvana, usually by people who didn't actually experience these
systems in the first place. I'm all in favour of remembering the
lessons of these systems, and trying to take them forward (I *really*
want a presentation system that works as well as Genera's, which the
CLIM one failed dismally to do in my experience, and nothing else that
I know has even attempted), but they do need to be taken forward:
reimplementing an 80s-style LispM, microcoded processor and all,
*using the original MIT code* even is really, well, uninteresting to
me. Of course, I may just be weird - a lot of people seem to think
that recreating *UNIX*, deficiencies and all, is something that is
somehow going to change the world.
--tim
Tim Bradshaw <···@cley.com> writes:
...
> Yes, of course I didn't mean that the ideas should be forgotten. What
> annoys me is the seemingly endless attempts to blindly recreate some
> lost nirvana, usually by people who didn't actually experience these
> systems in the first place. I'm all in favour of remembering the
> lessons of these systems, and trying to take them forward (I *really*
> want a presentation system that works as well as Genera's, which the
> CLIM one failed dismally to do in my experience, and nothing else that
> I know has even attempted), but they do need to be taken forward:
Could you expand on that? What are the differences between the
presentation system in Genera and presentations in CLIM?
Tim
From: Tim Bradshaw
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ey3smr6uklq.fsf@cley.com>
* Timothy Moore wrote:
> Could you expand on that? What are the differences between the
> presentation system in Genera and presentations in CLIM?
Mostly that the Genera ones worked seamlessly and fast, while anything
to do with CLIM was always slow & buggy in my experience of it.
--tim
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <u3cj56h8i.fsf@dtpq.com>
>>>>> On 23 May 2003 09:34:57 +0100, Tim Bradshaw ("Tim") writes:
Tim> * Timothy Moore wrote:
>> Could you expand on that? What are the differences between the
>> presentation system in Genera and presentations in CLIM?
Tim> Mostly that the Genera ones worked seamlessly and fast, while anything
Tim> to do with CLIM was always slow & buggy in my experience of it.
CLIM computed and rendered presentations twice as fast as
Dynamic Windows (due to a horrible design bug in DW that
made it do everything twice). Maybe the slowness was coming
from somewhere else, not CLIM per se? Or maybe there was some
special facility in CLIM, not used by most applications,
that had not been optimized.
I remember when DW first came out, and the system was damn
near unusable. Symbolics tried to tell us that we needed
to upgrade all our machines (which were already very well
configured) with additional memory. Our cost would have
been over a million dollars.
Tim Bradshaw wrote:
>
> * Timothy Moore wrote:
>
> > Could you expand on that? What are the differences between the
> > presentation system in Genera and presentations in CLIM?
>
> Mostly that the Genera ones worked seamlessly and fast, while anything
> to do with CLIM was always slow & buggy in my experience of it.
Was the slowness and 'buggyness' due to the design of CLIM's presentation
system? Or was it an implementation issue?
Is there some place where we can find out more about Genera's presentation
system?
I've been studying the CLIM specification for quite some time now and I think
it's a lovely design, very much in the 'Lisp spirit'. But some people whose
opinion I respect a lot (like you and Scott McKay) keep saying that there are
problems with CLIM and that 'it's not worth the trouble'.
I keep wondering what those problems and 'trouble' might be. The comments I've
seen in the last couple of years haven't convinced me that there are serious
problems in CLIM's design. Then again, I've never written any big & serious
CLIM program, so maybe I just missed all the pitfalls.
When you say that CLIM is not worth the trouble (as you recently did on the
Lispworks mailing list, IIRC), is this because you think that CLIM's design
somehow misses the point? Or are you just unhappy with the available
implementations?
If it's just the implementations, I'm afraid I would agree with you:
- Xanalys seems to be more interested in their CAPI than in CLIM, which
is a real pity since CAPI misses interesting and useful CLIM concepts
like extended output streams and presentations.
- McClim has a license that effectively forbids distributing CLIM-
applications that are developed with a commercial compiler.
- Franz' runtime licensing schemes make their CLIM unaffordable for
small companies like mine.
But if you think there's something wrong with CLIM's design, I would
appreciate it very much if you could explain what you don't like about
it.
Thanks.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Tim Bradshaw wrote:
> >
> > * Timothy Moore wrote:
> >
> > > Could you expand on that? What are the differences between the
> > > presentation system in Genera and presentations in CLIM?
> >
> > Mostly that the Genera ones worked seamlessly and fast, while anything
> > to do with CLIM was always slow & buggy in my experience of it.
>
> Was the slowness and 'buggyness' due to the design of CLIM's presentation
> system? Or was it an implementation issue?
No. The design of Genera's Dynamic Windows (DW) was initially
HORRIBLY slow and nearly lost all the customers. It was terribly,
terribly bad for the entire first release of it, which I think was
Genera 7.0. But it got better through use and customers miraculously
stuck it out because they wanted the features it offered.
CLIM's design was actually less general than DW's, intended to provide
less functionality in order to allow it to be lots faster in many more
cases than DW, exactly so that it could run without hardware and operating
system assist.
Scott McKay could probably comment more on why CLIM has never been as
robust as DW. My recollections on this are vague and possibly more faulty
than some of my ANSI CL recollections. Nevertheless, I'd be the reasons
are these:
- Raw Human Resources.
It was never staffed as well as the DW team. LOTS of resources
went into designing DW, and probably even more into fixing it
once deployed. It was central to the Genera product.
By contrast, CLIM was an add-on, and the resources for it were
distributed over multiple platforms, and sometimes not shared among
vendors.
- Usage Testing.
CLIM was used by a tiny fraction of the people who used DW. In many
cases, the users divided into two classes: (a) people who had used DW
for a long time and understood its concepts, but were not seriously
motivated to relive the initial DW rollout again with CLIM.
(CLIM was not well-integrated with Genera. It was an add-on there.
It fought with the native window system and did not integrate with
many of its tools.) (b) people who had never used DW and were afraid
of CLIM because they'd never seen anything like it, so they didn't know
how to use it or what to expect, so mostly didn't test it as thoroughly.
There wer probably a few in between, but I bet not many.
(After the first release) when DW went into the debugger, the debugger
was still running DW and the system didn't recursively grind to a halt.
It was remarkably robust. Forcing an error break in the presentation
system was, in fact, one of the best ways to learn about how it worked.
From there, you could click on things and find out what they did, and
you could hit c-E in the debugger to edit the source for things.
DW was integrated with the Lisp Listener. CLIM had to run in other
windows. At old-Harlequin, Scott McKay made a CLIM that ran a Lisp Listener
based on CLIM for development. This wasn't ever sold, I think. It had
a lot of problems. DW had a well-integrated pointer model that allowed
you to mouse on ranges of text or on displayed whole items and copy them
into other windows. CLIM's default set of mouse operations was much more
impoverished and cutting/pasting information back and forth between CLIM
and non-CLIM windows was much harder.
- Documentation.
The only really good user doc came from Symbolics, and was expensive.
I believe the manual was $100. At the time, this seemed too much for
some to pay. Now that document is rare to obtain, but is still reputed
to be the best. I don't have a copy. Other vendor doc was reputedly much
poorer. I think competent reference doc is available, but that doesn't
help. It's possible, too, that the Symbolics doc is for CLIM 1.0, not 2.0,
and so documents the old way of doing things, prior to the stuff that did
all the integration with native look and feel.
- Underlying Platform.
Many people involved in CLIM's design (by which I don't mean just Symbolics
employees, but also the folks at ILA, who were seeming to head the proejct)
were working on Genera and I think only doing superficial testing on other
platforms. Some of the main problems relate to the handling of
multitasking, and the absence of the Genera LETF operator (dynamic bind
of arbitrary cells, not just special variables) means that on standard
hardware, the use of multitasking worked poorly.
- Fonts vs other graphics
CLIM relies on stretching things, but it wasn't very well implemented in
the implementations I've seen to stretch fonts and graphics compatibly.
As a consequence, there is it doesn't always stretch fonts the same as it
stretches graphics, or even at all. (There's an allowance forthis in the
spec, but relying on fonts to stretch is dangerous for users, and not
expecting it to happen looks lousy for applications.) But even then,
easy access to fonts on a multi-platform situation is hard. [This is a
pity because there's so much else to CLIM that one little detail like this
shouldn't have the right to be so harmful.] It's possible that this is
just a bug that is fixed in some modern versios of CLIM, btw; please don't
quote me out of context on this paragraph. My knowledge is 10 years out
of date, but is merely explaining the CLIM/DW split.
- Graphics and Windowing Model
I'm the most blurry on this paragraph because I've pieced it together
mostly from recollections of conversations, not from actual experience.
Don't lean too heavily on the facts I offer here, but rather listen to
the 'shape' of what I'm saying--I think I've got the shape of the problem
right even if the actual details of what I'm saying are slightly off...
CLIM makes various assumptions about the way that graphics work in the
lowlevel that I think have been found to be at odds with the way native
graphics systems work, so that even though it has tremendous power, it's
hard to offer all of that power directly. My recollection is that native
graphics tends to work by establishing pens with various qualities and
then drawing with them; whereas CLIM tends to decode the drawing attributes
on a per-call basis. I think there are maybe also some issues to do with
managing callbacks for redraw due to occluding windows that are an issue.
The click protocol for CLIM is also stream-based; deciding what is going
to be mouse sensitive is often an issue of being in an input wait. (One
can create 'panic buttons' that aren't that way, but it's not the intended
mode.) This in turn fights the event-driven 'browser model' (which didn't
exist when CLIM came out). A lot of what DW/CLIM did was futuristic back
when it came out, and freaked people out. People panicked at the idea of
a widget with a scrollbar that itself was on a page that was scrolling so
that half a scroll-bar appeared in view. This is now commonplace due to
browsers. Lisp/DW/CLIM's public relations resources were insufficient
to push for acceptance originally, just as they were for GC pre-Java, but
had they come at a different time the situation would have been utterly
different.
> I've been studying the CLIM specification for quite some time now
> and I think it's a lovely design, very much in the 'Lisp
> spirit'. But some people whose opinion I respect a lot (like you and
> Scott McKay) keep saying that there are problems with CLIM and that
> 'it's not worth the trouble'.
>
> I keep wondering what those problems and 'trouble' might be. The
> comments I've seen in the last couple of years haven't convinced me
> that there are serious problems in CLIM's design. Then again, I've
> never written any big & serious CLIM program, so maybe I just missed
> all the pitfalls.
Google. There is more information that's already been discussed than
you are finding and it's not our responsibility to repeat ourselves.
> When you say that CLIM is not worth the trouble (as you recently did
> on the Lispworks mailing list, IIRC), is this because you think that
> CLIM's design somehow misses the point? Or are you just unhappy with
> the available implementations?
I think at this point the answer is "both".
Scott did substantial redesign when doing DUIM and keeps insisting that
anyone with a serious interest in the answer should compare those two.
Maybe someone will get ambitious and do a comparative report on these
as an academic paper or public service.
> If it's just the implementations, I'm afraid I would agree with you:
> - Xanalys seems to be more interested in their CAPI than in CLIM, which
> is a real pity since CAPI misses interesting and useful CLIM concepts
> like extended output streams and presentations.
> - McClim has a license that effectively forbids distributing CLIM-
> applications that are developed with a commercial compiler.
> - Franz' runtime licensing schemes make their CLIM unaffordable for
> small companies like mine.
I doubt either Xanalys or Franz want you to use CLIM mostly because it's
very expensive to support and not for any fault of their own. One pushes
its other products heavily and the other just says it'll charge you a lot
if you use CLIM, but it all amounts to the same. The community keeps saying
it wants to keep CLIM alive. It does have some cool features that people
can learn from. But if you can get away with a more native approach like
Xanalys' CAPI or Franz' Common Windows (or whatever it's called), you should
do that.
> But if you think there's something wrong with CLIM's design, I would
> appreciate it very much if you could explain what you don't like about
> it.
The information is there in public. You should dig more if you care and
report back. The experts on it have moved on to other things. That's what
experts do. They save you the time of reliving their life experience by
summarizing. You can either take that advice or not. But every time they
decide "I'm not going to do that any more" and you don't understand why nor
believe them, don't make THEM relive it. That's YOUR cue to relive it and
become an expert yourself if you don't believe.
IMO, CLIM is like The Calculus. Few people really need it in day to day
life, since in practice there are ways of doing the common things that don't
require appealing to full generality. But if you're an intellectual type,
it stretches your mind interestingly to think about it. And certain problems
can't be solved without it. But because of that, mostly the world works
hard to find problems to worry about that aren't those...
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> Arthur Lemmens <········@xs4all.nl> writes:
>
> CLIM's design was actually less general than DW's, intended to provide
> less functionality in order to allow it to be lots faster in many more
> cases than DW, exactly so that it could run without hardware and operating
> system assist.
Actually CLIM was more general than DW, but would not
work on prehistoric stream implementations. CLIM is one
of those things that got to stand on the shoulders of a previous
implementation and not make the same mistakes. Some of the
people at Symbolics thought that DW should work seamlessly
and compatibly with old pre-Genera streams, and that constraint
just killed the performance.
> Scott McKay could probably comment more on why CLIM has never been as
> robust as DW. My recollections on this are vague and possibly more faulty
> than some of my ANSI CL recollections. Nevertheless, I'd be the reasons
> are these:
>
> - Raw Human Resources.
>
> It was never staffed as well as the DW team. LOTS of resources
> went into designing DW, and probably even more into fixing it
> once deployed. It was central to the Genera product.
>
> By contrast, CLIM was an add-on, and the resources for it were
> distributed over multiple platforms, and sometimes not shared among
> vendors.
Yup. I agree with all of what you say here.
> - Usage Testing.
>
> CLIM was used by a tiny fraction of the people who used DW. In many
> cases, the users divided into two classes: (a) people who had used DW
> for a long time and understood its concepts, but were not seriously
> motivated to relive the initial DW rollout again with CLIM.
> (CLIM was not well-integrated with Genera. It was an add-on there.
> It fought with the native window system and did not integrate with
> many of its tools.) (b) people who had never used DW and were afraid
> of CLIM because they'd never seen anything like it, so they didn't know
> how to use it or what to expect, so mostly didn't test it as
thoroughly.
> There wer probably a few in between, but I bet not many.
>
> (After the first release) when DW went into the debugger, the debugger
> was still running DW and the system didn't recursively grind to a halt.
> It was remarkably robust. Forcing an error break in the presentation
> system was, in fact, one of the best ways to learn about how it worked.
> From there, you could click on things and find out what they did, and
> you could hit c-E in the debugger to edit the source for things.
>
> DW was integrated with the Lisp Listener. CLIM had to run in other
> windows. At old-Harlequin, Scott McKay made a CLIM that ran a Lisp
Listener
> based on CLIM for development. This wasn't ever sold, I think. It had
> a lot of problems. DW had a well-integrated pointer model that allowed
> you to mouse on ranges of text or on displayed whole items and copy
them
> into other windows. CLIM's default set of mouse operations was much
more
> impoverished and cutting/pasting information back and forth between
CLIM
> and non-CLIM windows was much harder.
Yeah, this was something CLIM didn't get right.
BTW, I was prodded to resurrect a version of my CLIM-based
environment over the winter. I've got it working quite nicely on
Franz and MCL.
> - Documentation.
>
> The only really good user doc came from Symbolics, and was expensive.
> I believe the manual was $100. At the time, this seemed too much for
> some to pay. Now that document is rare to obtain, but is still reputed
> to be the best. I don't have a copy. Other vendor doc was reputedly
much
> poorer. I think competent reference doc is available, but that doesn't
> help. It's possible, too, that the Symbolics doc is for CLIM 1.0, not
2.0,
> and so documents the old way of doing things, prior to the stuff that
did
> all the integration with native look and feel.
>
> - Underlying Platform.
>
> Many people involved in CLIM's design (by which I don't mean just
Symbolics
> employees, but also the folks at ILA, who were seeming to head the
proejct)
> were working on Genera and I think only doing superficial testing on
other
> platforms. Some of the main problems relate to the handling of
> multitasking, and the absence of the Genera LETF operator (dynamic bind
> of arbitrary cells, not just special variables) means that on standard
> hardware, the use of multitasking worked poorly.
>
> - Fonts vs other graphics
>
> CLIM relies on stretching things, but it wasn't very well implemented
in
> the implementations I've seen to stretch fonts and graphics compatibly.
> As a consequence, there is it doesn't always stretch fonts the same as
it
> stretches graphics, or even at all. (There's an allowance forthis in
the
> spec, but relying on fonts to stretch is dangerous for users, and not
> expecting it to happen looks lousy for applications.) But even then,
> easy access to fonts on a multi-platform situation is hard. [This is a
> pity because there's so much else to CLIM that one little detail like
this
> shouldn't have the right to be so harmful.] It's possible that this is
> just a bug that is fixed in some modern versios of CLIM, btw; please
don't
> quote me out of context on this paragraph. My knowledge is 10 years
out
> of date, but is merely explaining the CLIM/DW split.
CLIM was sort of ahead or beside its time here. Ahead, in that
I was a bit ahead of the curve on scalable fonts. Beside, in that
when scalable fonts appeared in window systems, they were
different (and better) than I anticipated. Again, DUIM does a
better job of this because I got to look at better models.
> - Graphics and Windowing Model
>
> I'm the most blurry on this paragraph because I've pieced it together
> mostly from recollections of conversations, not from actual experience.
> Don't lean too heavily on the facts I offer here, but rather listen to
> the 'shape' of what I'm saying--I think I've got the shape of the
problem
> right even if the actual details of what I'm saying are slightly off...
>
> CLIM makes various assumptions about the way that graphics work in the
> lowlevel that I think have been found to be at odds with the way native
> graphics systems work, so that even though it has tremendous power,
it's
> hard to offer all of that power directly. My recollection is that
native
> graphics tends to work by establishing pens with various qualities and
> then drawing with them; whereas CLIM tends to decode the drawing
attributes
> on a per-call basis. I think there are maybe also some issues to do
with
> managing callbacks for redraw due to occluding windows that are an
issue.
> The click protocol for CLIM is also stream-based; deciding what is
going
> to be mouse sensitive is often an issue of being in an input wait.
(One
> can create 'panic buttons' that aren't that way, but it's not the
intended
> mode.) This in turn fights the event-driven 'browser model' (which
didn't
> exist when CLIM came out). A lot of what DW/CLIM did was futuristic
back
> when it came out, and freaked people out. People panicked at the idea
of
> a widget with a scrollbar that itself was on a page that was scrolling
so
> that half a scroll-bar appeared in view. This is now commonplace due
to
> browsers. Lisp/DW/CLIM's public relations resources were insufficient
> to push for acceptance originally, just as they were for GC pre-Java,
but
> had they come at a different time the situation would have been utterly
> different.
>
Yup, CLIM's streaming event model didn't work out, and yup, it
was again ahead of its time in the use of gadgets. And again, DUIM
came out better because it could be designed to working window
systems.
> > I've been studying the CLIM specification for quite some time now
> > and I think it's a lovely design, very much in the 'Lisp
> > spirit'. But some people whose opinion I respect a lot (like you and
> > Scott McKay) keep saying that there are problems with CLIM and that
> > 'it's not worth the trouble'.
> >
> > I keep wondering what those problems and 'trouble' might be. The
> > comments I've seen in the last couple of years haven't convinced me
> > that there are serious problems in CLIM's design. Then again, I've
> > never written any big & serious CLIM program, so maybe I just missed
> > all the pitfalls.
>
> Google. There is more information that's already been discussed than
> you are finding and it's not our responsibility to repeat ourselves.
>
> > When you say that CLIM is not worth the trouble (as you recently did
> > on the Lispworks mailing list, IIRC), is this because you think that
> > CLIM's design somehow misses the point? Or are you just unhappy with
> > the available implementations?
>
> I think at this point the answer is "both".
>
> Scott did substantial redesign when doing DUIM and keeps insisting that
> anyone with a serious interest in the answer should compare those two.
> Maybe someone will get ambitious and do a comparative report on these
> as an academic paper or public service.
>
> > If it's just the implementations, I'm afraid I would agree with you:
> > - Xanalys seems to be more interested in their CAPI than in CLIM,
which
> > is a real pity since CAPI misses interesting and useful CLIM
concepts
> > like extended output streams and presentations.
> > - McClim has a license that effectively forbids distributing CLIM-
> > applications that are developed with a commercial compiler.
> > - Franz' runtime licensing schemes make their CLIM unaffordable for
> > small companies like mine.
>
> I doubt either Xanalys or Franz want you to use CLIM mostly because it's
> very expensive to support and not for any fault of their own. One pushes
> its other products heavily and the other just says it'll charge you a lot
> if you use CLIM, but it all amounts to the same. The community keeps
saying
> it wants to keep CLIM alive. It does have some cool features that people
> can learn from. But if you can get away with a more native approach like
> Xanalys' CAPI or Franz' Common Windows (or whatever it's called), you
should
> do that.
>
> > But if you think there's something wrong with CLIM's design, I would
> > appreciate it very much if you could explain what you don't like about
> > it.
>
> The information is there in public. You should dig more if you care and
> report back. The experts on it have moved on to other things. That's
what
> experts do. They save you the time of reliving their life experience by
> summarizing. You can either take that advice or not. But every time they
> decide "I'm not going to do that any more" and you don't understand why
nor
> believe them, don't make THEM relive it. That's YOUR cue to relive it and
> become an expert yourself if you don't believe.
>
> IMO, CLIM is like The Calculus. Few people really need it in day to day
> life, since in practice there are ways of doing the common things that
don't
> require appealing to full generality. But if you're an intellectual type,
> it stretches your mind interestingly to think about it. And certain
problems
> can't be solved without it. But because of that, mostly the world works
> hard to find problems to worry about that aren't those...
>
Maybe some of us should take the trouble to come to the Lisp Conference
in New York this fall, and we can have a "what can we learn from CLIM,
DUIM, and everything else" group.
"Scott McKay" <···@attbi.com> wrote in message news:<·······················@rwcrnsc51.ops.asp.att.net>...
(lot's of stuff skipped)
> Maybe some of us should take the trouble to come to the Lisp Conference
> in New York this fall, and we can have a "what can we learn from CLIM,
> DUIM, and everything else" group.
especially since some people are actively reimplementing CLIM:
See:
http://mcclim.cliki.net/index
There is an "Annotatable CLIM II Specification"
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/
There is even a web browser written with it:
http://www-jcsu.jesus.cam.ac.uk/~csr21/closure-tex.png
Lisp hackers are invited to join. See here:
http://mcclim.cliki.net/Projects
"Scott McKay" <···@attbi.com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> > Arthur Lemmens <········@xs4all.nl> writes:
> >
>
> > CLIM's design was actually less general than DW's, intended to provide
> > less functionality in order to allow it to be lots faster in many more
> > cases than DW, exactly so that it could run without hardware and operating
> > system assist.
>
> Actually CLIM was more general than DW, but would not
> work on prehistoric stream implementations.
Hmm. FWIW, I think one thing I was thinking of was mouse doc. I'm pretty
sure CLIM had a much more limited number of hooks for mouse doc than Genera
did, and that a lot of thing had to be precomputed strings. I think also
certain kinds of scrollable windows had to be things you gave to native
window system scrollers and so certain kinds of highly active scrollable
windows (like the kind Genera's Peek uses, though I forget its name) were
not possible--then again, maybe Peek is using Sheets, not DW anyway, so maybe
that part I'm misremembering. Nevertheless, I seem to recall that when I
went to do a Zmail-substitute, I ran head up against the fact that I wanted
a kind of window that would tolerate thousands of messages that had not yet
been 'parsed' and would demand-parse them as you scrolled, and the problem
was that CLIM wanted to dispatch out to the native window system for such
scrolling and so I couldn't get a callback on scroll without writing a native
window widget to do that because CLIM couldn't simulate it. Am I
misremembering, and were these things not more easily done in DW?
I certainly trust your assessment that, on the whole, we gained more than
we lost. I never really made a full comparative survey of the two in order
to have an informed opinion. But I'm just wondering if I'm misremembering
on these details.
I sometimes hesitate to post my fuzzy impressions, but force myself to anyway,
mostly because others are not volunteering much that is either fuzzy or not,
and I figure fuzzy is better than nothing. I'm glad I didn't get it _too_
wrong. ;)
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Scott McKay" <···@attbi.com> writes:
>
> > "Kent M Pitman" <······@world.std.com> wrote in message
> > ····················@shell01.TheWorld.com...
> > > Arthur Lemmens <········@xs4all.nl> writes:
> > >
> >
> > > CLIM's design was actually less general than DW's, intended to provide
> > > less functionality in order to allow it to be lots faster in many more
> > > cases than DW, exactly so that it could run without hardware and
operating
> > > system assist.
> >
> > Actually CLIM was more general than DW, but would not
> > work on prehistoric stream implementations.
>
> Hmm. FWIW, I think one thing I was thinking of was mouse doc. I'm pretty
> sure CLIM had a much more limited number of hooks for mouse doc than
Genera
> did, and that a lot of thing had to be precomputed strings. I think also
> certain kinds of scrollable windows had to be things you gave to native
> window system scrollers and so certain kinds of highly active scrollable
> windows (like the kind Genera's Peek uses, though I forget its name) were
> not possible--then again, maybe Peek is using Sheets, not DW anyway, so
maybe
> that part I'm misremembering. Nevertheless, I seem to recall that when I
> went to do a Zmail-substitute, I ran head up against the fact that I
wanted
> a kind of window that would tolerate thousands of messages that had not
yet
> been 'parsed' and would demand-parse them as you scrolled, and the problem
> was that CLIM wanted to dispatch out to the native window system for such
> scrolling and so I couldn't get a callback on scroll without writing a
native
> window widget to do that because CLIM couldn't simulate it. Am I
> misremembering, and were these things not more easily done in DW?
The core CLIM implementation did not have Genera-style
"text scroll" windows built into it. This was a mistake, which
I addressed by building some of my own. The CLIM environment
we have alluded to includes these. They're as fast as you would
hope, but at some small loss of generality.
> I certainly trust your assessment that, on the whole, we gained more than
> we lost. I never really made a full comparative survey of the two in
order
> to have an informed opinion. But I'm just wondering if I'm misremembering
> on these details.
>
> I sometimes hesitate to post my fuzzy impressions, but force myself to
anyway,
> mostly because others are not volunteering much that is either fuzzy or
not,
> and I figure fuzzy is better than nothing. I'm glad I didn't get it _too_
> wrong. ;)
No, pretty close. I think that the fuzzy impressions over time are
actually quite valuable.
Kent M Pitman wrote:
[lots of interesting stuff about CLIM and Dynamic Windows]
Thanks a lot for your comments. I appreciate this very much.
> Google. There is more information that's already been discussed than
> you are finding
All I've found about CLIM is:
- everything mentioned at http://www.cliki.net/CLIM
(Franz' and Xanalys' user guides, a couple of versions of the CLIM
specification, the archives of the BBN CLIM mailing list, two tutorials,
references to Digitool's FTP server and the CMU Lisp repository)
- the DUIM source code, reference guide and user guide
- SciGraph and CLASP
- a few other programs with a CLIM interface: closure, reversi and
weird-irc
- some messages on comp.lang.lisp
- the McClim mailing list.
If you're aware of other sources of information about CLIM, I'd appreciate
it if you could be more explicit.
> IMO, CLIM is like The Calculus. Few people really need it in day to day
> life, since in practice there are ways of doing the common things that don't
> require appealing to full generality. But if you're an intellectual type,
> it stretches your mind interestingly to think about it. And certain problems
> can't be solved without it. But because of that, mostly the world works
> hard to find problems to worry about that aren't those...
I suppose the same could be said about Lisp (compared to more 'common'
programming languages). I like Lisp because it has, in Scott McKay's words,
several "big ideas" in it. That's what I like about CLIM, too: it's not
afraid to "think big". I've never regretted my decision to make Common Lisp my
main programming language. I'm hoping I'll feel the same way about CLIM in a
couple of years.
Thanks once more for your comments.
Arthur Lemmens
From: Tim Bradshaw
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ey3el2pvrhg.fsf@cley.com>
* Arthur Lemmens wrote:
> Was the slowness and 'buggyness' due to the design of CLIM's
> presentation system? Or was it an implementation issue?
I'm not sure. Certainly the latter, but I don't know enough about the
design to be able to comment on the former.
> Is there some place where we can find out more about Genera's
> presentation system?
Not as far as I know - the manuals were extensive, and the source was
largely available to users of the system, but none of that helps much.
> When you say that CLIM is not worth the trouble (as you recently did
> on the Lispworks mailing list, IIRC), is this because you think that
> CLIM's design somehow misses the point? Or are you just unhappy with
> the available implementations?
I think that it's very hard to get CLIM to look like a native GUI, and
people want something which looks native. I think CLIM sits on the
underlying GUI at the wrong level, reinventing a whole bunch of stuff
that the underlying system also does. Both these problems may be
common to other portable toolkits (Java's), but I don't think so - for
instance LW's CAPI does not have them to nearly the same extent. Apart
from other issues, I think CLIm doesn't *want* to look like a native
GUI, it wants to look like Genera's, and Genera just looked different
than modern window systems do.
I think the implementations are typically marginal, and are probably
very hard to maintain, hence the bugs and slowness. I think there are
things in CLIM which are very hard, or maybe impossible, to implement
correctly (LETF, probably other things).
All of this sounds like I don't really want presentations. Well, I
do, but I want them really integrated into a `modern' GUI (actually, I
think modern GUIs are largely awful, but they have kind of won for now
- maybe something radically different could displace them, but CLIM
won't). I don't know how that would work in detail, I'm afraid.
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
>
> I think that it's very hard to get CLIM to look like a native GUI, and
> people want something which looks native. I think CLIM sits on the
> underlying GUI at the wrong level, reinventing a whole bunch of stuff
> that the underlying system also does. Both these problems may be
> common to other portable toolkits (Java's), but I don't think so - for
> instance LW's CAPI does not have them to nearly the same extent. Apart
> from other issues, I think CLIm doesn't *want* to look like a native
> GUI, it wants to look like Genera's, and Genera just looked different
> than modern window systems do.
>
In my last post I should have admitted that making CLIM "look
native" is damned near impossible. This is a shortcoming that
directly reflects on the myopia (at the time) of its main designer
(that would be me).
Prodded mercilessly by Andy Armstrong while at Harlequin,
this design problem was fixed (and fixed properly, I might add,
with due credit to Andy) in Dylan's UI system, DUIM. I've
urged people working on McCLIM to look at this, but I don't
know if anyone did, and Naggum always flamed me.
I have a working output recording and presentation type system
for DUIM that never made it into the Dylan product.
If I were doing CLIM 2000 (trying to stay a bit behind the curve,
as usual), I would start by rewriting DUIM in Lisp, and then layer
a rewritten CLIM presentation system on top of it. This would
achieve the important goals of:
- having proper UI appearance
- having a full-scale presentation type system
- having a really good abstraction layer for dealing with windows
and graphics, far better that, at, AWT/Swing
Scott McKay wrote:
> In my last post I should have admitted that making CLIM "look
> native" is damned near impossible.
Yes, that's one of the remarks that keeps coming back. I still don't understand
what it is in CLIM's design (or, to be more precise, in the CLIM 2.0
specification) that makes it so hard to make CLIM "look native".
So I suppose I have no choice but to "relive" (in Kent Pitman's words) the
experience and try this for myself. I'll probably start doing that Real Soon
Now. I've written about 22K lines implementing parts of CLIM, and I've finally
reached the stage where I can start implementing the Windows backend. I'm
still hoping that I can get a sufficiently native look and feel. If this
turns out to be impossible, I'll take another look at DUIM for inspiration.
Thanks a lot for your comments.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Scott McKay wrote:
>
> > In my last post I should have admitted that making CLIM "look
> > native" is damned near impossible.
>
> Yes, that's one of the remarks that keeps coming back. I still don't
> understand what it is in CLIM's design (or, to be more precise, in
> the CLIM 2.0 specification) that makes it so hard to make CLIM "look
> native".
My only hint to you is that in my guess it's not hard to make it look native,
it's hard to make the same user-code for CLIM look the-same-kind-of-native
on two different systems. That is, you can probably stretch CLIM semantics
to mean the right thing on some underlying window system, but making it so
that you use the same source CLIM to get nice-looking native stuff on two
different underlying window systems may be much tougher.
Arthur Lemmens <········@xs4all.nl> writes:
> Scott McKay wrote:
>
> > In my last post I should have admitted that making CLIM "look
> > native" is damned near impossible.
>
> Yes, that's one of the remarks that keeps coming back. I still don't
> understand
> what it is in CLIM's design (or, to be more precise, in the CLIM 2.0
> specification) that makes it so hard to make CLIM "look native".
>
I don't have much experience with "classic" CLIM applications and the
"real" CLIM implementation, but from implementing McCLIM and some toy
applications, I see two issues:
The CLIM command paradigm, which is really a Lisp REPL on massive
steroids, doesn't fit well with common GUI implementations. That is
not to say that it isn't useful, or that it couldn't be transformed
into something more familiar.
Gadgets in CLIM are defined in a least common denominator way
relative to what might be available in window systems, so the
selection and functionality are kind of lame. That might not be so bad
-- after all, you can always define new gadget classes -- but the real
weakness is that gadgets are a real bag on the side of CLIM, not
integrated with the presentation system, or input editing, in any
way. There are various hacks that can be used to "throw"
presentations from native gadgets, but it would be nice if that
capability had been designed in.
> So I suppose I have no choice but to "relive" (in Kent Pitman's words) the
> experience and try this for myself. I'll probably start doing that Real Soon
> Now. I've written about 22K lines implementing parts of CLIM, and
> I've finally
> reached the stage where I can start implementing the Windows backend. I'm
Too bad that code isn't in McCLIM, I guess. We're up to 53K lines as
we approach feature-completeness :).
> still hoping that I can get a sufficiently native look and feel. If this
> turns out to be impossible, I'll take another look at DUIM for inspiration.
>
> Thanks a lot for your comments.
>
> Arthur Lemmens
Tim
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
>
> Tim Bradshaw wrote:
> >
> > * Timothy Moore wrote:
> >
> > > Could you expand on that? What are the differences between the
> > > presentation system in Genera and presentations in CLIM?
> >
> > Mostly that the Genera ones worked seamlessly and fast, while anything
> > to do with CLIM was always slow & buggy in my experience of it.
>
> Was the slowness and 'buggyness' due to the design of CLIM's presentation
> system? Or was it an implementation issue?
>
> Is there some place where we can find out more about Genera's presentation
> system?
>
> I've been studying the CLIM specification for quite some time now and I
think
> it's a lovely design, very much in the 'Lisp spirit'. But some people
whose
> opinion I respect a lot (like you and Scott McKay) keep saying that there
are
> problems with CLIM and that 'it's not worth the trouble'.
I (mainly) wrote CLIM, so my saying it's "not worth the trouble"
is a reflection of my belief that CLIM is better as a starting point
for its logical successor.
That being said, I think -- based on evidence, not just ego -- that
CLIM is actually a whole lot better than Dynamic Windows in most
ways. Its mostly faster, mostly better written, mostly more functional.
There are places we went overboard -- the pattern-based graphics
model, e.g.
I also think that all of the vendors who supported CLIM did a pretty
poor job of it. The Lucid version never had any full-time people
working on it. Franz had to be brow-beat into it, and they did do
good things with it for a while, but no really deep investment. Harlqn
only invested in it while John Aspinall and I were working on it, and
then only very grudgingly. No Lisp vendor ever decided to use CLIM
to build any interesting tools, which would have greatly contributed
to its robustness.
A shame, really. CLIM is a rare thing that has several "big ideas" in it,
where most things are lucky to have even one.
> I keep wondering what those problems and 'trouble' might be. The comments
I've
> seen in the last couple of years haven't convinced me that there are
serious
> problems in CLIM's design. Then again, I've never written any big &
serious
> CLIM program, so maybe I just missed all the pitfalls.
>
> When you say that CLIM is not worth the trouble (as you recently did on
the
> Lispworks mailing list, IIRC), is this because you think that CLIM's
design
> somehow misses the point? Or are you just unhappy with the available
> implementations?
>
> If it's just the implementations, I'm afraid I would agree with you:
> - Xanalys seems to be more interested in their CAPI than in CLIM, which
> is a real pity since CAPI misses interesting and useful CLIM concepts
> like extended output streams and presentations.
> - McClim has a license that effectively forbids distributing CLIM-
> applications that are developed with a commercial compiler.
> - Franz' runtime licensing schemes make their CLIM unaffordable for
> small companies like mine.
>
> But if you think there's something wrong with CLIM's design, I would
> appreciate it very much if you could explain what you don't like about
> it.
>
> Thanks.
>
> Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
...
> When you say that CLIM is not worth the trouble (as you recently did on the
> Lispworks mailing list, IIRC), is this because you think that CLIM's design
> somehow misses the point? Or are you just unhappy with the available
> implementations?
>
> If it's just the implementations, I'm afraid I would agree with you:
> - Xanalys seems to be more interested in their CAPI than in CLIM, which
> is a real pity since CAPI misses interesting and useful CLIM concepts
> like extended output streams and presentations.
> - McClim has a license that effectively forbids distributing CLIM-
> applications that are developed with a commercial compiler.
I don't think the McCLIM team itself believes that. What problems are
there with McCLIM's license?
> - Franz' runtime licensing schemes make their CLIM unaffordable for
> small companies like mine.
>
> But if you think there's something wrong with CLIM's design, I would
> appreciate it very much if you could explain what you don't like about
> it.
Tim
Timothy Moore wrote:
> I don't think the McCLIM team itself believes that. What problems are
> there with McCLIM's license?
We discussed this on the McCLIM mailing list about two years ago. McCLIM is
distributed with the LGPL license. Here's a quote from section 6 of the license
that makes it impossible to distribute McCLIM applications that were created
with a commercial compiler:
"the required form of the 'work that uses the library' must include
any data and utility programs needed for reproducing the executable
from it."
No, I'm not a lawyer. But I'm pretty sure that my compiler is needed for
"reproducing the executables" that I sell, and I'm also pretty sure that
I can't freely distribute the Lisp compiler that I happen to use.
I suppose this is one of the reasons why Franz distributes Allegroserve and
their other Open Source libraries with the "Prequel to the LGPL License", which
says (among other things):
"an executable that results from linking a 'work that use the Allegroserve
Library' with the Library is [...] NOT covered by LGPL. Because of this
declaration, section 6 of LGPL is not applicable to the Allegroserve
Library."
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Timothy Moore wrote:
>
> > I don't think the McCLIM team itself believes that. What problems are
> > there with McCLIM's license?
>
> We discussed this on the McCLIM mailing list about two years ago. McCLIM is
> distributed with the LGPL license. Here's a quote from section 6 of the license
> that makes it impossible to distribute McCLIM applications that were created
> with a commercial compiler:
>
> "the required form of the 'work that uses the library' must include
> any data and utility programs needed for reproducing the executable
> from it."
>
> No, I'm not a lawyer. But I'm pretty sure that my compiler is needed for
> "reproducing the executables" that I sell, and I'm also pretty sure that
> I can't freely distribute the Lisp compiler that I happen to use.
I believe that if you read that excerpt in context, it's saying that
you need to provide a way for the user to modify the library source,
and cause your product to use the modified version. So, loading the
library from source if it's newer than the fasl files seems like it
would satisfy that.
> I suppose this is one of the reasons why Franz distributes Allegroserve and
> their other Open Source libraries with the "Prequel to the LGPL License", which
> says (among other things):
>
> "an executable that results from linking a 'work that use the Allegroserve
> Library' with the Library is [...] NOT covered by LGPL. Because of this
> declaration, section 6 of LGPL is not applicable to the Allegroserve
> Library."
I don't see how this section has any bearing on the above. This is
just saying clearly that your app is not the library.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Arthur Lemmens <········@xs4all.nl> writes:
>
> > "the required form of the 'work that uses the library' must include
> > any data and utility programs needed for reproducing the executable
> > from it."
>
> I believe that if you read that excerpt in context, it's saying that
> you need to provide a way for the user to modify the library source,
> and cause your product to use the modified version. So, loading the
> library from source if it's newer than the fasl files seems like it
> would satisfy that.
That's a clever interpretation, and I like it. But I'm not sure that a more
pessimistic interpretation can be excluded.
> > "an executable that results from linking a 'work that use the Allegroserve
> > Library' with the Library is [...] NOT covered by LGPL. Because of this
> > declaration, section 6 of LGPL is not applicable to the Allegroserve
> > Library."
>
> I don't see how this section has any bearing on the above.
Section 6 of the LGPL contains the part that I consider problematic. So when
"Section 6 is not applicable to the library", the problematic part disappears.
> This is just saying clearly that your app is not the library.
That's not all it's saying. It's saying that the app is NOT covered by LGPL.
Contrast this with section 5 of the LGPL, which says:
"The executable is therefore covered by this License. Section 6 states
terms for distribution of such executables."
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Timothy Moore wrote:
>
> > I don't think the McCLIM team itself believes that. What problems are
> > there with McCLIM's license?
>
> We discussed this on the McCLIM mailing list about two years ago. McCLIM is
Fortunately before my time :)
> distributed with the LGPL license. Here's a quote from section 6 of
>the license
> that makes it impossible to distribute McCLIM applications that were created
> with a commercial compiler:
>
> "the required form of the 'work that uses the library' must include
> any data and utility programs needed for reproducing the executable
> from it."
>
> No, I'm not a lawyer. But I'm pretty sure that my compiler is needed for
> "reproducing the executables" that I sell, and I'm also pretty sure that
> I can't freely distribute the Lisp compiler that I happen to use.
Your reading puts an unreasonable obligation on the library author to
supply development environments to end users which just doesn't
exist. Can one not distribute works that use LPGL'ed libraries
which are compiled with Visual C++, for example? If you compile your
application with a commercial C++ or Fortran compiler, are you barred
from using LPGL'ed libraries?
The next section of license, after the part you've quoted, says:
"However, as a special exception,
the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable."
This is pretty confusing: on the one hand, Lisp systems aren't
normally distributed with operating systems today; on the other hand,
someone who's going to do any development or modification to a Lisp
program needs a Lisp system, and I don't see a requirement in the LGPL
that the library user needs to supply that. On might say that this
passage is so confusing, and so obviously tied to C programming
issues, that it doesn't mean anything at all.
Anyway...
>
> I suppose this is one of the reasons why Franz distributes Allegroserve and
> their other Open Source libraries with the "Prequel to the LGPL
> License", which
> says (among other things):
I'm not sure there's any reason for us McCLIM developers to not
include the Franz prequel and get rid of lingering confusion.
Tim
Timothy Moore wrote:
> Your reading puts an unreasonable obligation on the library author to
> supply development environments to end users
Exactly. You may think there are other ways to read this section of the LGPL,
but that's not the point. My problem with the LGPL is that it is possible to
interpret section 6 as saying that an application developer is required to
distribute the development environment with the application. I'm not saying
that this is the only way to interpret section 6; I'm just saying that it's
not unreasonable to interpret it that way. For me, the risk of that
interpretation is too big.
> This is pretty confusing: on the one hand, Lisp systems aren't
> normally distributed with operating systems today; on the other hand,
> someone who's going to do any development or modification to a Lisp
> program needs a Lisp system, and I don't see a requirement in the LGPL
> that the library user needs to supply that. On might say that this
> passage is so confusing, and so obviously tied to C programming
> issues
Yes, I think that's the main problem with the LGPL. It was written by people
who had C as their programming language and Unix as their operating system
in mind. When I try to apply to this to my situation (Lisp and Windows),
things become so confusing that I don't dare to invest lots of time in
LGPL'ed libraries.
> I'm not sure there's any reason for us McCLIM developers to not
> include the Franz prequel and get rid of lingering confusion.
Yes, I think Franz found a good solution for the ambiguousness of the LGPL.
But Robert Strandh didn't like Franz' modifications to the LGPL (when we
discussed this two years ago). Apart from that, there's the problem of
finding all contributors and getting them to agree with a change to the
license. I don't know if there's an archive for the free-clim mailing list;
if there is, you may want to look up our discussion. It started on
2001-05-08; the subject of the thread was "License for McClim".
Arthur Lemmens
Kent M Pitman <······@world.std.com> writes:
> The point of this rant, though, is to say that a great deal of good has
> come from carrying the banner for that curious old operating system, and
> making sure its ideas did not just die, regardless of how irritating that
> has been to some people along the way.
I think that is a worthwhile thing. I also think that it was not a
wasted effort to re-create Unix in the from of Linux with all those
GNU tools (and some BSD ones). My problem with the Unix Hater's
Handbook is that by far the majority of complaints have to do with
tools that have nothing to do with the kernel at all.
As for doing _new_ things, I agree that we should. However, creating
something entirely new is really hard. It is much easier to evolve
something that exists into something better. Also, getting something
entirely new that doesn't work with what already exists is a recipe
for failure. Apple did something new in 1984. How many times has
Apple been pronounced dead?
When it comes to the future success and growth of Lisp, I think a
large part of it will be interoperability with existing software
systems. There will also be a time period where you will probably be
better off using existing libraries for various software (libpng,
libmpeg, etc) rather than re-writing them simply for sake of
expediency.
It may be something of an irony that my primary reason for finally
switching over to Linux was so I could learn to program in Lisp.
Linux is simply friendlier than Windows when you would rather spend
your money on hardware than software.
Who is to say that some future version of Mach won't be the kernel for
a new LispOS type system that has new stuff?
--
(describe 'describe)
After a long battle with technology,David Steuber <·············@verizon.net>, an earthling, wrote:
> Who is to say that some future version of Mach won't be the kernel for
> a new LispOS type system that has new stuff?
That seems _seriously_ doubtful.
Mach involved two things:
a) Some interesting technologies, particularly relating to threading,
and
b) A hefty "propaganda" machine.
(Note that microkernelling _isn't_ on that list; the main commercial
OSes based on Mach, OSF/1 and NeXTStep, which since became MacOS-X are
not microkernel-based...)
At one point, it was thought that, by implementing Mach for new CPU
architectures, all OSes would automagically become supported.
Today, the only prominent thing still related to Mach is MacOS-X, and
the main ex-mouthpiece for Mach is the head of Microsoft Research.
And CMU dropped all research efforts on Mach, which moved to
University of Utah, who don't seem to be doing vastly much with it.
This is not a picture that leaves much room for Mach being about to
get *really* popular...
--
let name="aa454" and tld="freenet.carleton.ca" in name ^ ·@" ^ tld;;
http://www.ntlug.org/~cbbrowne/lisp.html
This program posts news to billions of machines throughout the galaxy.
Your message will cost the net enough to bankrupt your entire planet.
As a result your species will be sold into slavery. Be sure you know
what you are doing. Are you absolutely sure you want to do this? [yn]
y
Christopher Browne <········@acm.org> writes:
> This is not a picture that leaves much room for Mach being about to
> get *really* popular...
Mach was just an example of a possible kernel. I am not married to
any OS or CPU architecture. What I would actually like to see is
something like Sun promised Java would do (but doesn't). I would like
to program in Lisp and then produce exacutable targets for the
existing supported platforms. You can do this with C++. However, you
still have to jump through a lot of hoops because there is not enough
abstraction.
Java (just an example) does something really strange. It abstracts
the underlying architecture that the JRE runs on top of, but the
language itself feels as low level as C++. Personally, I like the
scripting languages better.
ANSI CL seems to be an alternative that offers what I want. In terms
of lines of code (or, rather, expressions) it competes well with high
level scripting languages. This is great for programmer
productivity. As for runtime, it seems to compete in many ways with
C. Scripting languages generally don't do that.
--
(describe 'describe)
"David Steuber" <·············@verizon.net> wrote in message
···················@verizon.net...
> Christopher Browne <········@acm.org> writes:
>
> > This is not a picture that leaves much room for Mach being about to
> > get *really* popular...
>
> Mach was just an example of a possible kernel. I am not married to
> any OS or CPU architecture. What I would actually like to see is
> something like Sun promised Java would do (but doesn't). I would like
> to program in Lisp and then produce exacutable targets for the
> existing supported platforms. You can do this with C++. However, you
> still have to jump through a lot of hoops because there is not enough
> abstraction.
>
> Java (just an example) does something really strange. It abstracts
> the underlying architecture that the JRE runs on top of, but the
> language itself feels as low level as C++. Personally, I like the
> scripting languages better.
>
> ANSI CL seems to be an alternative that offers what I want. In terms
> of lines of code (or, rather, expressions) it competes well with high
> level scripting languages. This is great for programmer
> productivity. As for runtime, it seems to compete in many ways with
> C. Scripting languages generally don't do that.
>
> --
> (describe 'describe)
No only if one Lisp env. would produce executables for many different
platforms ;) Lisp would do want people wanted Java to do, but Java did not
want to do. :)
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ufzn5cg27.fsf@dtpq.com>
>>>>> On Fri, 23 May 2003 23:47:13 GMT, David Steuber ("David") writes:
David> I would like to program in Lisp and then produce exacutable
David> targets for the existing supported platforms. You can do this
David> with C++. However, you still have to jump through a lot of
David> hoops because there is not enough abstraction.
Don't you do it approximately the same way in both languages?
C++ gcc foo.cpp
Lisp (compile-file "foo.lisp")
(Maybe there was a lot of context that was snipped from your question?)
"Christopher C. Stacy" <······@dtpq.com> wrote in message
··················@dtpq.com...
> >>>>> On Fri, 23 May 2003 23:47:13 GMT, David Steuber ("David") writes:
> David> I would like to program in Lisp and then produce exacutable
> David> targets for the existing supported platforms. You can do this
> David> with C++. However, you still have to jump through a lot of
> David> hoops because there is not enough abstraction.
>
> Don't you do it approximately the same way in both languages?
> C++ gcc foo.cpp
> Lisp (compile-file "foo.lisp")
>
> (Maybe there was a lot of context that was snipped from your question?)
In a Lot of Lisps (compile-file "foo.lisp") produces a
file called "foo.fsl" which means a fast load file.
and to run the file you'd have to type
(load "foo.fsl")
in Lisp.
whereas most C++ compilers
will produce a file called foo.exe
which does not require a C++ compiler to run.
If more Lisps would make it easy to create exe files
rather than relieing on imp. specific. things like
(build-application "foo" #'foo "foo.fsl")
than maybe more people would start to use Lisp.
Lots of the free Lisps can't create the exe files.
If some can please tell me which ones.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> Lots of the free Lisps can't create the exe files. If some can
> please tell me which ones.
In one of your recent postings[1] you boasted that you have been using
Lisp "for years". I think you should be clever enough to find this out
for yourself, then.
Other than that I think this question is #1 on the troll top 10 list
so a Google search might help.
Edi.
PS: For the record:
<http://article.gmane.org/gmane.lisp.cmucl.devel/3029/>.
[1] <http://www.google.com/groups?selm=CnQva.6199%24HW4.1511%40news01.roc.ny.frontiernet.net>
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
writes:
>
> > Lots of the free Lisps can't create the exe files. If some can
> > please tell me which ones.
>
> In one of your recent postings[1] you boasted that you have been using
> Lisp "for years". I think you should be clever enough to find this out
> for yourself, then.
>
> Other than that I think this question is #1 on the troll top 10 list
> so a Google search might help.
>
> Edi.
>
> PS: For the record:
>
> <http://article.gmane.org/gmane.lisp.cmucl.devel/3029/>.
>
>
> [1]
<http://www.google.com/groups?selm=CnQva.6199%24HW4.1511%40news01.roc.ny.fro
ntiernet.net>
> ----- Original Message -----
> From: "Edi Weitz" <···@agharta.de>
> Newsgroups: comp.lang.lisp
> Sent: Saturday, May 24, 2003 1:15 AM
> Subject: Re: New Newsgroup on LispM/LispOS?
>
>
> > "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail .
com>
> writes:
> >
> > > Lots of the free Lisps can't create the exe files. If some can
> > > please tell me which ones.
> >
> > In one of your recent postings[1] you boasted that you have been using
> > Lisp "for years". I think you should be clever enough to find this out
> > for yourself, then.
> >
>
> This is the first time I wanted to create exe files.
>
> & I can see how the attitudes of people here
> are scaring people away from Lisp.
>
> Luckily when I first was learning Lisp people
> on CLL were much nicer. -- They actually
> encouraged people to use Lisp.
>
> The people on Smalltalk had bad attitudes--
> this made me want to learn Lisp. Now the
> Lisp people are acting just as bad--a new
> user wants a simple answer to a simple questions
> --not rants & attitudes.
Send your reply to c.l.l and I'll be happy to respond.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> This is the first time I wanted to create exe files.
>
> & I can see how the attitudes of people here are scaring people away
> from Lisp.
>
> Luckily when I first was learning Lisp people on CLL were much
> nicer. -- They actually encouraged people to use Lisp.
>
> The people on Smalltalk had bad attitudes-- this made me want to
> learn Lisp. Now the Lisp people are acting just as bad--a new user
> wants a simple answer to a simple questions --not rants & attitudes.
If you decide which programming languages to use/learn based upon the
perceived rudeness or friendliness of newsgroups I can't help you -
sorry.
But while we're at it let me add a few sentences although I don't
think this will help very much:
Since your postings started to appear in c.l.l about two months ago
I'm pretty sure there wasn't one day you didn't post. Most of the time
you demanded things others should do for you - preferably for free or
at least without you paying for it. You want LispMachine emulators,
you want "recodeable hardware" where the "microcode" is Lisp, and of
course you have to tell us that call/cc should have been part of the
ANSI CL standard, that the commercial Lisp vendors should give their
compilers away for free, and that nobody can use Lisp because the
"free" Lisp compilers can't create stand-alone executables. Believe
me, we have threads like these almost every month.
You tell us you've been using Lisp "for years" or "for a long time",
you tell us about the programmers you "had", and you give "advice"
(mostly wrong) to other c.l.l readers. I have yet to see that you want
to learn Lisp. All I can see is someone with childish behavior who
spends way too much time posting to Usenet.
I hope school holidays are over soon...
Edi.
PS: I'm not really interested to discuss this any further so don't
expect me to answer in case you feel the need to reply.
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <u7k8gcwtb.fsf@dtpq.com>
>>>>> On Sat, 24 May 2003 01:09:35 GMT, Franz Kafka ("Franz") writes:
Franz> "Christopher C. Stacy" <······@dtpq.com> wrote in message
Franz> ··················@dtpq.com...
>> >>>>> On Fri, 23 May 2003 23:47:13 GMT, David Steuber ("David") writes:
David> I would like to program in Lisp and then produce exacutable
David> targets for the existing supported platforms. You can do this
David> with C++. However, you still have to jump through a lot of
David> hoops because there is not enough abstraction.
>>
>> Don't you do it approximately the same way in both languages?
>> C++ gcc foo.cpp
>> Lisp (compile-file "foo.lisp")
>>
>> (Maybe there was a lot of context that was snipped from your question?)
Franz> In a Lot of Lisps (compile-file "foo.lisp") produces a
Franz> file called "foo.fsl" which means a fast load file.
In Unix, running the compiler produces a ".o" object file.
You can run the linker to produce an executable binary.
Typically this is done in several passes in a Makefile.
In most Common Lisp implementations, COMPILE-FILE produces an object
file (called as "FASL" file). There is a utility similar to Make
called (variously) MAKE:DEFSYSTEM. To produce a binary executable,
you typically invoke Lisp from the command line again, this time
specifying (through a trivial build script written in Lisp) that
you would like your FASL object files to be loaded and linked
into an executable file.
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Fri, 23 May 2003 23:47:13 GMT, David Steuber ("David") writes:
> David> I would like to program in Lisp and then produce exacutable
> David> targets for the existing supported platforms. You can do this
> David> with C++. However, you still have to jump through a lot of
> David> hoops because there is not enough abstraction.
>
> Don't you do it approximately the same way in both languages?
> C++ gcc foo.cpp
> Lisp (compile-file "foo.lisp")
I see your point. Certainly for a very trivial program this is true.
If you want to include a GUI and play with audio, then things get more
complicated. The Qt library from TrollTech lets you right pretty
source portable C++.
I was thinking of the cpp preprocessor and the autoconfig/automake
tools that are typically used with extra programmer work to make a
non-trivial program build and run on a variety of environments. Also,
GCC can be built as a cross-compiler so that you can target a platform
other than what you develop on.
I suppose Lisp would have to do all the same work. My thinking was
that it could be more transparent to the programmer than with C++.
Perhaps that is not the case.
Java skirts the issue by having a "Java" platform. If you don't want
to start a program by calling java -j foo.jar (or whatever the command
is, I forget), you have to write a native wrapper that loads the JRE.
So you have your source portability, but you still have to build a
bunch of distributions (which is not what I am trying to avoid).
What I want to avoid is starting a program as lisp foo.lisp. So if I
used CMUCL and built an executible image for some platform like Linux
on the x86 or Mac OS X, the image would be loaded and executed like
any other program created for that environment. The user of the
program does not need to know that it was written in Lisp.
I admit that I am still somewhat fuzzy on this whole thing. Obviously
when you go to build a runnable image you will have to tell Lisp what
the target is (with the development platform as the default). So the
nuts and bolts of it is still no different from C++ in that respect.
Come to think of it, I believe there is a front end for GCC that will
make an executable file out of Java code. Perhaps GCL as well.
--
(describe 'describe)
On Sat, May 24, 2003 at 11:23:28PM +0000, David Steuber wrote:
> What I want to avoid is starting a program as lisp foo.lisp. So if I
> used CMUCL and built an executible image for some platform like Linux
> on the x86 or Mac OS X, the image would be loaded and executed like
> any other program created for that environment. The user of the
> program does not need to know that it was written in Lisp.
CMUCL has recently gained, thanks to Eric Marsden, the capability to
load an image from an ELF section. See recent mail archives on gmane.
Of course, the image size is rather hefty in most cases, as there is no
``tree-shaker'' utility to reduce it.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <uel2nkc84.fsf@dtpq.com>
>>>>> On Sat, 24 May 2003 23:23:28 GMT, David Steuber ("David") writes:
David> ······@dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On Fri, 23 May 2003 23:47:13 GMT, David Steuber ("David") writes:
David> I would like to program in Lisp and then produce exacutable
David> targets for the existing supported platforms. You can do this
David> with C++. However, you still have to jump through a lot of
David> hoops because there is not enough abstraction.
>>
>> Don't you do it approximately the same way in both languages?
>> C++ gcc foo.cpp
>> Lisp (compile-file "foo.lisp")
David> I see your point. Certainly for a very trivial program this is true.
David> If you want to include a GUI and play with audio, then things get more
David> complicated. The Qt library from TrollTech lets you right pretty
David> source portable C++.
The ANSI Common Lisp language does not have a standard, portable,
platform-independant interface defined for making a GUI or playing
a WAV file. Of course, neither does C++. That kind of software
has to be implemented for specific platforms. But when you buy
a Lisp environment, it should come with the extra libraries that
most people will use to write those kinds of programs.
For example, the Xanalys Lispworks comes with a GUI library called
CAPI. In fact, your CAPI code will even be source-compatible across
platforms, so it will work on both Windows and Linux.
(I assume it will also be in their upcoming Macintosh version.)
Most people don't need sound as much as they need a GUI.
But you can just call the operating system to do that.
Or, you could have Lisp call your C++ library that you like.
All Lisps that I have seen include the ability to call "foreign" code.
From: Christopher C. Stacy
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <ud6iachlj.fsf@dtpq.com>
>>>>> On Thu, 22 May 2003 23:48:36 GMT, David Steuber ("David") writes:
David> My problem with the Unix Hater's Handbook is that by far the
David> majority of complaints have to do with tools that have nothing
David> to do with the kernel at all.
Most users, including people who program Unix, consider "Unix" to
include all those tools, and would not want the system without them.
In particular, they love the shell and the byte pipes, the window
system, the programs like 'more', 'grep', and so on. They also
love the libraries like stdio, termcap, and the kernel components
such as the file system, NFS, the network stack, etc. Not to mention
that's all written in C, which leads to many of the problems.
An "operating system" is generally considered to include the tools
that come with it that make it useful. When people are interested
in only the kernel, they say "kernel".
That's why people liked Genera, the (Symbolics) Lisp Machine
operating system. Not because it ran on special hardware,
or because of its kernel (except insofar as the kernel was
responsible for allowing the wonderful tools).
"Christopher C. Stacy" <······@dtpq.com> wrote in message
··················@dtpq.com...
>
> That's why people liked Genera, the (Symbolics) Lisp Machine
> operating system. Not because it ran on special hardware,
> or because of its kernel (except insofar as the kernel was
> responsible for allowing the wonderful tools).
>
Your right. It's the tools, and how they were all integrated together /w the
Lisp environment. Not the hardware, or kernal (except for the
fact that it was written in Lisp, and thus understandable to Lisp
programmers more easily that if it were written in Machine lang.)
It went: Microcode --> Low Level Lisp --> Full Lisp
The "wonderful" tools were the Bomb. How easy it was to switch from one tool
to the next--no waiting for a tool to load--was an other
good point.
From: Joe Marshall
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <d6i9bvcy.fsf@ccs.neu.edu>
David Steuber <·············@verizon.net> writes:
> My problem with the Unix Hater's
> Handbook is that by far the majority of complaints have to do with
> tools that have nothing to do with the kernel at all.
You're right. They complain about NFS, the file system, security,
administration, csh, pipes, find, X-Windows, curses, mail and
documentation. Barring those, I don't think they have much to
complain about.
On Thu, 22 May 2003 00:26:10 +0100, Tim Bradshaw wrote:
> Why can't we create something *new* instead? Sure Genera (I
> know) and ITS (I assume) were great (Unix is fine too, and
> Windows is at least habitable), but can't we, please, *move
> on* now, and make something new?
>
> --tim
I'd *love* to do something new - something truly original.
Looking back over the history of computing though, it does
sometimes seem like all the innovative stuff had been done by the
80s and since then we've just been doing the same stuff (perhaps
faster, and with bigger data sets, but essentially the same).
So until I think of that big new idea I'll just keep plugging
away at my own "re-inventing the wheel" project (Schemix).
My own career in computing started only a few years ago when I
finished my Ph.D (not in computing), but I've been hacking in my
spare time since I was 12 years old, when I taught myself Lisp so
that I could re-implement ELIZA.
Sad to think I'm now 27 and I'm still re-implementing ideas that
are older than I am!
Sorry for the rant ;-)
Best wishes,
Bill.
i have up for sale on ebay a symbolics 3650 lisp machine.
4 MW (18 MB) of memory,
750 MB disk,
genera 8.3 installed
works, in good condition, screen excellent with no burn in,
located in pittsburgh, PA
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2731980507
happy hacking,
isildur
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> >
> > For exactly this reason, don't expect them to do it. Competent people
> > rarely if ever expose their legal position in advance when money is on
> > the line. It's like showing someone else your poker hand. It totally
> > undercuts your negotiating position. Unless MIT has actively given up
> > on the value of this (and I seriously doubt that), I think you are being
> > naive in your expectation that this will happen.
>
> It's this kind of attitude that is making it not so desirable for people to
> work on Lisp Machine Emulators.
Does the phrase "beggars can't be choosers" have any currency with you?
You may have lost track of the part that you are the one with something to
gain and they are the ones with something of value to lose, and that when
you get frustrated by their unwillingness to give up the something of value
to you for free, that's because they have been through this kind of thing
before and they are not going to just knuckle under to your "you're making
it hard for me to take this off your hands for free" pitch.
> If some one at MIT--I sent an other letter--would clear this up it would
> make the issue more clear.
Obviously. But that doesn't mean they're going to do it.
Go back to my poker analogy. If everyone at the table would lay their
cards face up while playing, it would make the issue more clear. What
makes you suppose that making the issue clear is a goal of theirs?
> I think BSDing, GPLing, or FSFing the Lispm code would be a benefit to the
> Lisp community, I hope I am met by more help by people @ MIT than your
> response would indicate.
Of course you do. People who want something for nothing always make the
argument that it would benefit them personally, which it always would.
e.g., I might say "giving away the Microsoft Windows sources would be a
benefit to the Lisp community" and I'm sure it's probably true.
But it's the wrong argument to use when talking to the person you want to
give stuff away. That person is in charge of protecting the assets of the
place you're trying to get stuff free from. That person will be _fired_
if they give away something they could have made money on.
The argument you must make is not why it's of benefit to _you_, but
why it's of benefit to _MIT_ to do this. Further, this argument is
not made by finding people at MIT and saying "these people say it
would benefit them". Because for all you know, those people's
salaries can be paid for by _selling_ the stuff you propose to give
away for free. To make a credible argument, you need to (a)
acknowledge and quantify the legitimate dollar value of the item you
are trying to acquire, (b) project and justify a path to an even
larger sum of money (not just "amorphous benefit" but real cash
dollars) that MIT not only could but _would_ do. For example, saying
"Well, MIT could find investors and spin off a company to do x." You
_are_ the company, as far as they are concerned, and they want you to
do that part. They want to sit back and take the intellectual
property returns that come as a result of their having taken
_substantial risk_ over a long period of time doing research in a
variety of areas, some of which yield lots of money and some of which
only drain them. At this point, the risk part is done, and they are
in "take the profits" mode. So it's your job to promise them profits.
No matter what you may think, MIT is not in the business of "making
the world better". It is a business, like any other. To the extent
that they happen to also make the world better, so much the better
because good press gets them donations. BUT, in particular, since
free software advocates are often actively engaged in efforts to
disempowering themselves economically, impressing the whole free
software community is (I suspect) going to buy very little in donations
to MIT, so if I were MIT, this is not an area I'd see as worth giving
these sources to. If I were MIT, I'd hold out for someone who said they
wanted to make money on the stuff, and I'd demand a slice of that money.
> It seems to me like it would be in MIT's interests as an educational
> institution to spread info. about the Lispm around.
I don't see why. Neither MIT nor any educational institution is in
the business of giving knowledge away. They charge dearly for it. I
don't know their present tuition, but When I was in college there 20
years ago, the acceleration of tuition was $350/yr/yr, and I think
that kind of growth has continued, well above "cost of living
increases"... which is not a trend toward making information available
more freely.
Btw, even internally at MIT, not everyone thought the lisp machine
was the way to go. MIT is, like the US, not of one mind. It is a
pluralistic society with many co-existing points of view.
> Most people don't even know what one is--if they were used more MIT
> would get a larger name recognition
To round numbers, MIT could not have larger name recognition.
And it's money, not technology, that would raise its prestige.
> and maybe a lot more contracts to do more research, esp. when people
> realize how powerful, in programmer productivity, the Lisp Machines
> were.
This has been tried. Contracts are not a direct function of technology.
Moreover, free software would not make them moreso. Free software makes
its money off of "support organizations" and other peripheral business
activities, not off of technology, and so when the amount of money varies,
it's not because of betterness of technology, but betterness of support
or whatever it is that money is being charged for. That's not going to
benefit MIT at all. No one is going to say "Wow, any educational institution
that could put out people who would respond that fast to my phone calls
deserve my research dollars." That's too many inferential leaps to make
in one thought.
> Are you fighting the rebirth of the Lispm because it might hurt the sales of
> commercial Lisp systems,
No. I fear that the people at MIT will decide that you are short of basic
business knowledge and living in a fantasy world. I fear that then later
when people with a better story come to try to do the same thing in what
should be a way that would otherwise have succeeded, the people at MIT will
say "enough of this. we talked to other people about this already and it
went nowhere. we want nothing to do with you."
I don't have any commercial interest in Lisp Machines. I have one on my desk.
I like and miss it. I would like to see it be available again. I think
that a commercial enterprise is the most practical way toward that end,
unless whoever owns the modern souces decides to give those away.
Among other things, there were about 20-30 developers working a dozen
or so years full-time on moving the sources ahead of the ones you're
trying to obtain. What you are trying to do is to get a bunch of
people interested in something that is 200-400 man years older than
the technology I am familiar with. I don't see how that will help at
all. I personally have no interest in reliving that multi-man-century
evolution... Modern software-only Lisp systems from Franz or
Xanalys strike me as nearly as already highly competitive with the
stuff you're trying to acquire. If anything, I think getting an emulated
version of that old stuff would set the industry back by reinforcing the
(false) notion that Lisp cannot run natively and requires emulation.
What would be missing was the result of all those years and years of
_experience_ using such a system, and I don't think that years and years
on an emulator would yield the same outcome.
> or for some other reason? I'd think that more
> people in the Lisp community, if they could remember how it was to use a
> Lispm, would want to see them back.
You're suggesting that no one learned anything from the LispM experience.
Xanalys and Franz and Digitool have environments that are, in their own
ways, quite competitive. Yes, they lose some features. But they gain some
native integration that the LispM should have had. Apples and oranges, and
hard to compare. I loved the CADR (the early LispM that came out in 1978)
in its day, but I can't say, overall, that it's better for doing serious work
than any modern software-only Lisp. If I were going to repeat all that
evolution, I'd rather do that in a native Lisp, not an emulator. What an
emulator would be useful for is for executing the modern system, and that
requires direct negotiation with the holders of the modern intellectual
property rights to Genera, which is not MIT.
Kent M Pitman <······@world.std.com> writes:
> Neither MIT nor any educational institution is in the business of
> giving knowledge away. They charge dearly for it.
You should qualify that statement with "in the US". In some parts of
the world (higher) education is considered more like a human right
than a business.
For many European universities saying that they are mainly in the
business of giving knowledege away is more accurate than the opposite.
Jesper Harder <······@myrealbox.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Neither MIT nor any educational institution is in the business of
> > giving knowledge away. They charge dearly for it.
>
> You should qualify that statement with "in the US". In some parts of
> the world (higher) education is considered more like a human right
> than a business.
>
> For many European universities saying that they are mainly in the
> business of giving knowledege away is more accurate than the opposite.
How about if I instead qualify it to say that it's "my opinion".
For all I know, MIT itself would portray itself differently than I have.
I am not its spokesman, nor the spokesman even for "all US educational
institutions".
Internally, though, I wouldn't be surprised if some places you like to
model as thusly friendly still have to break even on a budget and have
to make choices about what to share freely and what not to. If
nothing else, I know of none that will accept all students who apply
without charging money.
Personally, I like to make a formal distinction between 'rights' and
'goals' of society. I claim (and it's just my personal terminology)
that one precondition of a right is that it must be free. That is,
rights should be those things that when all people of goodwill are acting
with goodwill, independent of resources, do not cost. So, for example, it
costs nothing to offer 'free speech' because there is no specific cost
to allowing another to speak. Curiously, I'm not sure that 'food' is a
right because I'm not sure that one could always say that there is enough
food, regardless of resouces. As such, I classify 'food' as a goal.
I also classify 'education' as a goal, too, since all of societies resources
might be consumed already before education is available, and it is in
some circumstances an unaffordable luxury to offer education.
Kent M Pitman <······@world.std.com> writes:
> Internally, though, I wouldn't be surprised if some places you like to
> model as thusly friendly
Note that I was not passing a value judgment. I was just observing
that there are probably some differences in the public perception of
the role of universities.
> still have to break even on a budget and have to make choices about
> what to share freely and what not to. If nothing else, I know of
> none that will accept all students who apply without charging money.
Well, that's more or less the way it works in Denmark. All students
that satisfy the entrance requirements are admitted for free (students
are even payed for attending). Funding is provided by the government
on the basis of students passing exams.
> I also classify 'education' as a goal, too, since all of societies
> resources might be consumed already before education is available,
> and it is in some circumstances an unaffordable luxury to offer
> education.
Yes, of course. What Article 26 of the Human Rights Declaration says
is:
higher education shall be equally accessible to all on the basis
of merit.
That leaves some room for interpretation. But you could argue about
if being able to cough up hefty tuition fees counts as "basis of
merit" :-)
> Neither MIT nor any educational institution is in the business of
> giving knowledge away. They charge dearly for it.
Yes, that is not their business, but it's a mistake to think about
this in black and white terms: Even a US university is usually a
non-profit and sees itself as having an educational mission. MIT in
particular do give a lot of knowledge away, such as all their course
material. Quoting from <http://ocw.mit.edu/index.html>: "This
initiative supports MIT's fundamental mission - to advance knowledge
and education to best serve the nation and the world."
If it's patentable results, they will want their share, but they are
not miserly libertarian hoarders.
PS. I'm not pining for the old LM, either, even though it was the most
comfortable IDE I've known. What we need are better tools for the
modern Lisp implementations. I always thought it was a pity that the
old Harlequin didn't put all those Symbolics people they hired to work
on reimplementing the best of Genera on LW.
--
Pekka P. Pirinen
The LM was a wonderful peak of programmability, and will remain so as
long as enthusiasts can find enough low-sulfur coal to shovel into
those machines' boilers to keep them running... :-) - Steven M. Haflich
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
writes:
>
> For exactly this reason, don't expect them to do it. Competent people
> rarely if ever expose their legal position in advance when money is on
> the line. It's like showing someone else your poker hand. It totally
> undercuts your negotiating position. Unless MIT has actively given up
> on the value of this (and I seriously doubt that), I think you are being
> naive in your expectation that this will happen.
>
Then why would Tom Knight have posted this on usenet
awhile ago--I'm just reposting it because it might prove
to be helpful
Tom Knight posts:
Several people have asked about the naughty bits of the original MIT
lisp machine architecture. I've put my master's thesis (1979) on line
for those of you with a generous non-critical spirit to take a look
at. I will duck all arrows, but praise will be gratefully received.
There are genuine logic diagrams for those of you who recall Schottky
TTL logic or who want to know how hard it was to do anything back in
the bad old days.
General features include a 32 bit word, 180ns cycle, 3-stage pipe,
bypass logic, barrel shifter, single cycle arbitrary field
extract/deposit, and a "dispatch" instruction which did an extracted
field multi-way table lookup branch in a single cycle. Microcode PC
push down stack, top-of-stack cache, and an ability to variablize
microcode instructions on-the-fly are also interesting features.
Branch delay slots appeared here also.
Best, tk
http://www.ai.mit.edu/people/tk/tk-sm-79.pdf
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> > "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
> writes:
> >
> > For exactly this reason, don't expect them to do it. Competent people
> > rarely if ever expose their legal position in advance when money is on
> > the line. It's like showing someone else your poker hand. It totally
> > undercuts your negotiating position. Unless MIT has actively given up
> > on the value of this (and I seriously doubt that), I think you are being
> > naive in your expectation that this will happen.
> >
>
> Then why would Tom Knight have posted this on usenet
> awhile ago--I'm just reposting it because it might prove
> to be helpful
I'm really tired of discussing this with you and am going to stop
pretty soon. Please don't take my failure to respond in the future to
every single little weirdness you post as my "agreeing" with your
position. Just write it off to exhaustion.
Perhaps I had misunderstood you and was responding to something
different, or perhaps because you misunderstood me. Either way, I'm
just starting to not care.
For example, your post here syntactically seems to position itself (by
beginning "Then why would ...") as a counterexample to what I said.
In fact, though, the thing you point me to is not related at all to
what I said. To me, the Lisp Machine is only incidentally a hardware
issue--yes, it ran on hardware, but the hardware is utterly
uninteresting to me except for one isolated virtue: its ability to
assure that no well-meaning manager can ask me to compile out the
error checking the hardware provides. (That's not to say that the
hardware didn't have other fascinating features, but they are features
I would trade away in a heartbeat for the non-technical benefits of
stock hardware, most particularly cost and availability.)
I had made all of my remarks above about the issues of the software
that ran on the lispm platform, not about anything you're trying to
acquire to allow you to build an emulator. To me, what makes the Lisp
Machine interesting is the software that ran on it. And, in case you
don't know, not that you ever bothered to ask, there is nothing that ran
on Lisp Machines that I think could not have run elsewhere. What I lament
when I wax nostalgic about it is not the availability of the machine, but
the prevalance of the mindset.
When I was at the AI Lab, before I want to Symbolics, I used to sit around
and make lists of things people said could never be done on regular hardware
and then amuse myself making such thing. For example, I implemented a
version of Zmail (admittedly smaller, but similar in character) in Teco
on the PDP10 in 50Kbytes (10Kwords in 36-bit PDP10 parlance) of code.
I did this because people had told me it was impossible make Zmail's notion
of filters. Then they said, "well, not filters, but the filter creation
menu." So I added that, with a keyboard interface. Then they said,
"well, I want to click with my mouse". This was tough because PDP10's didn't
have mice, but I made an Emacs interface so that if you netted in from a
LispM (which did have one), clicking on the window would send coordinate info
that drove my ZBabyl extensions to Zmail to run my filter creation menu.
I wrote a [very limited] Lisp compiler in Teco and I even made it read in
people's Zmail init files, just so they could share an init file between
ZBabyl and Zmail. It was all silly, I suppose, but the point was to stretch
the imagination and to show that if people not on Lisp Machines wanted
what Lisp Machines had, they had only to decide to implement them.
(I suppose you can go get a PDP10 emulator and play with ZBabyl if you want.
It's probably all documented in INFO.)
Back to your post--What Knight posted is not about LM software, other
than how to bootstrap it. The Lisp Machine without its software is
not very much. But moreover, all comments which I made had nothing to
do with the hardware--I was _only_ discussing the software. All I
said was that the software would be boring to me except for nostalgia
purposes in its 1980 form; for all intents and purposes, modern
software-only platforms already do most of this. The software that
evolved over 20 years on architectures that likewise evolved is of
interset because it has another 200-400 man years of investment in it,
but (a) that's not supported by the hardware in Knight's thesis and
(b) that's not software you can get from anyone but Symbolics.
The only thing I've said about an emulator at all is that if you build
one, you will probably do lisp a disservice by suggesting to the world
that Lisp can only run on emulated systems, which is plainly not true
and is a myth we have _slowly_ been beating down. But it is possible
to set us back, and with your communication skills, I must say you
show (at least to me) every likelihood of being just the man to do it.
From: Joe Marshall
Subject: Re: New Newsgroup on LispM/LispOS?
Date:
Message-ID: <vfw4f7wz.fsf@ccs.neu.edu>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> I'd also love it if an MIT rep. would post MIT's offical position
> about the issue here --- this would resolve a lot of legal issues
> that so many people have been raising.
Rather than ask an MIT representative to do your work for you, you can
simply go to their web site:
http://web.mit.edu/
and in particular:
http://web.mit.edu/tlo/www/
which is the Technology Licensing Office.
A little reading would reveal that you need to get in touch with
Joe Schatz who is the Technology Licensing Officer in charge of
Computer Architecture and Software Algorithms and Systems.
> "Christopher C. Stacy" <······@dtpq.com> wrote in message
> ··················@dtpq.com...
>
> >
> >First you say it "must" have happened, then you say that you asked,
> >and someone at MIT told you something. But you don't say who >you asked,
> or what they told you. Who did you ask? What did they say?
> >
Sorry I did not post quotes from actually e-mails. I don't like to post
private e-mails unless the person already posted the info. I am quoting.
Tom Knight posted the web link on this group a few months ago.
I am hoping that one of the designers of the Lispm posted infomation about
the Lispm project--weather the code is avail. or not.
MIT's stance about it being used as the bases of a Lispm OS project.
I'd like to hear from both sides of the issue: 1.) people who want it
released 2.) people who don't want it released.
& maybe they could work out an arangement where everyone is happy--so using
the code is not a legal risk.
On Wed, 21 May 2003 14:09:29 GMT, "Franz Kafka" <Symbolics _ XL1201 _ Sebek
_ Budo _ Kafka @ hotmail . com> wrote:
[about Tom Knight]
> Since he invented the Lispm; I think he can decide what he wants to do with
> the sources. (I don't know if he released them--they may be in the public
Richard Stallman had a similar thought at the time. But things went
differently with Symbolics.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In comp.lang.scheme Christopher Browne <········@acm.org> wrote:
> In the last exciting episode, Sander Vesik <······@haldjas.folklore.ee> wrote:
>> I think its a bit worse than 'not sustainable level of interest' -
>> it hasn't reached the stage where a failed project would leave
>> enough stuff around that the next would have a lower barrier to
>> success...
>
> Indeed.
>
> Numerous "LispOS" projects have come and disappeared over the years.
>
> At this point, the only approach viable enough to "leave anything
> behind" is the one that involves running the system atop one of the
> "free Unix variants," so that someone else is responsible for
> implementing support for various graphics and disk hardware.
No, not really. You could use the fruits of the Flux project.
>
> The approach that could lead to building a whole OS would be to build
> compiler tools generating ELF binaries, as that could lead to being
> able to replace GCC by a Lisp compiler of some sort. Of course, it
> still begs the question of what CPU architectures to look at; it would
> be unfortunate to discover that the system was unusable on x86-64 or
> IA-64 or whatever might prove popular next year...
The system would need to be sufficenetly hardware non-specific, otherwise
it is ultimately doomed - when IDE gets replaced with something else or you
have a new gfx card or whatever.
--
Sander
+++ Out of cheese error +++
Oops! Sander Vesik <······@haldjas.folklore.ee> was seen spray-painting on a wall:
> In comp.lang.scheme Christopher Browne <········@acm.org> wrote:
>> In the last exciting episode, Sander Vesik <······@haldjas.folklore.ee> wrote:
>>> I think its a bit worse than 'not sustainable level of interest' -
>>> it hasn't reached the stage where a failed project would leave
>>> enough stuff around that the next would have a lower barrier to
>>> success...
>>
>> Indeed.
>>
>> Numerous "LispOS" projects have come and disappeared over the years.
>>
>> At this point, the only approach viable enough to "leave anything
>> behind" is the one that involves running the system atop one of the
>> "free Unix variants," so that someone else is responsible for
>> implementing support for various graphics and disk hardware.
>
> No, not really. You could use the fruits of the Flux project.
That's the nearest thing to being something different, but it still
has a hefty dependency on the "free Unix variants" as it consists in
great part of "layering software" so that they can make use of:
a) Linux filesystems and device drivers,
b) NetBSD FFS,
c) FreeBSD TCP/IP stack and FreeBSD device drivers,
d) X atop this.
The last release was in March 2002, so it is by no means evident that
it's active enough to be supporting recent changes to these OSes,
recent filesystems, recent devices, or next year's graphics cards.
>> The approach that could lead to building a whole OS would be to build
>> compiler tools generating ELF binaries, as that could lead to being
>> able to replace GCC by a Lisp compiler of some sort. Of course, it
>> still begs the question of what CPU architectures to look at; it would
>> be unfortunate to discover that the system was unusable on x86-64 or
>> IA-64 or whatever might prove popular next year...
>
> The system would need to be sufficenetly hardware non-specific, otherwise
> it is ultimately doomed - when IDE gets replaced with something else or you
> have a new gfx card or whatever.
SATA looks to be the Something Else...
I certainly agree that it is pretty easy for these systems to get
hardware-specific to the point of being "doomed."
--
output = reverse(····················@" "454aa")
http://www.ntlug.org/~cbbrowne/oses.html
Honuphrius is a concupiscent exservicemajor who makes dishonest
propositions to all.
In comp.lang.scheme Christopher Browne <········@acm.org> wrote:
> Oops! Sander Vesik <······@haldjas.folklore.ee> was seen spray-painting on a wall:
>> In comp.lang.scheme Christopher Browne <········@acm.org> wrote:
>>> In the last exciting episode, Sander Vesik <······@haldjas.folklore.ee> wrote:
>>>> I think its a bit worse than 'not sustainable level of interest' -
>>>> it hasn't reached the stage where a failed project would leave
>>>> enough stuff around that the next would have a lower barrier to
>>>> success...
>>>
>>> Indeed.
>>>
>>> Numerous "LispOS" projects have come and disappeared over the years.
>>>
>>> At this point, the only approach viable enough to "leave anything
>>> behind" is the one that involves running the system atop one of the
>>> "free Unix variants," so that someone else is responsible for
>>> implementing support for various graphics and disk hardware.
>>
>> No, not really. You could use the fruits of the Flux project.
>
> That's the nearest thing to being something different, but it still
> has a hefty dependency on the "free Unix variants" as it consists in
> great part of "layering software" so that they can make use of:
> a) Linux filesystems and device drivers,
> b) NetBSD FFS,
> c) FreeBSD TCP/IP stack and FreeBSD device drivers,
> d) X atop this.
>
> The last release was in March 2002, so it is by no means evident that
> it's active enough to be supporting recent changes to these OSes,
> recent filesystems, recent devices, or next year's graphics cards.
>
I believe replicating their changes to newer versions would not be that hard -
I mean, compared to creating the same things from scrtach, its going to be many
orders of magnitude easier. If people are afraid to do maintenenace on something
that was last released a year ago they have no hope whatsoever of ever getting
anywhere with an OS projects - OS projects are large enough that you always have
pieces that are at least a year since somebody looked at them and now need some
maintenance.
--
Sander
+++ Out of cheese error +++
Sander Vesik wrote:
> In comp.lang.scheme Christopher Browne <········@acm.org> wrote:
>> In the last exciting episode, Sander Vesik <······@haldjas.folklore.ee>
>> wrote:
>>> I think its a bit worse than 'not sustainable level of interest' -
>>> it hasn't reached the stage where a failed project would leave
>>> enough stuff around that the next would have a lower barrier to
>>> success...
>>
>> Indeed.
>>
>> Numerous "LispOS" projects have come and disappeared over the years.
>>
>> At this point, the only approach viable enough to "leave anything
>> behind" is the one that involves running the system atop one of the
>> "free Unix variants," so that someone else is responsible for
>> implementing support for various graphics and disk hardware.
>
> No, not really. You could use the fruits of the Flux project.
Isn't there a Scheme-OS already existing based on a mixture of MIT Scheme
and Flux? A bit limited, apparently, but you could use it as a basis.
Wesley Parish
>
>>
>> The approach that could lead to building a whole OS would be to build
>> compiler tools generating ELF binaries, as that could lead to being
>> able to replace GCC by a Lisp compiler of some sort. Of course, it
>> still begs the question of what CPU architectures to look at; it would
>> be unfortunate to discover that the system was unusable on x86-64 or
>> IA-64 or whatever might prove popular next year...
>
> The system would need to be sufficenetly hardware non-specific, otherwise
> it is ultimately doomed - when IDE gets replaced with something else or
> you have a new gfx card or whatever.
>
--
First the wife, tone of awe. So much a condition. Kent in the labs, fast
forward. "So how was the worthlessful businessman?" But they hadn't
stopped meat for year ago, that arose hotel facade slowly moved apper.
- Don't let emacs meta-x dissociatedpress write your speeches!