Mike McDonald wrote in message <72i153$3c...@spitting-spider.aracnet.com>... >(MIT has agreed in principle to the CADR code but they can't find a copy of >the sources.
Have they contacted the usual suspects? the original spin-off founders?
>TI also seems to have misplaced theirs, although they haven't
I doubt they have the rights to redistribute the MIT and LMI code upon which they built the Explorer OS.
>said whether they'd be willing to release it anyway. LMI has completely >disappeared. <snip>
I lost my copies (masters) of the final LMI tapes some time ago. (I turned out the lights at LMI - twice.) IIRC, when GigaMos folded, there was serious controversy over who held the assets. Claimants included the founders, a Japanese investor, the government of Saskatchewan, and employees in Cambridge and Canada. (I am not making this up.)
>Only Symbolics is still around and they're determined to take >their code to the grave with them. Which is a shame even if it's their right >to do so.) So, if anyone has or know someone who has the sources to any of the >older LispMs, please, PLEASE, speek up!
No, no, no, let's not start another thread about copyrights! :>
On Tue, 17 Nov 1998 01:18:06 -0000, CsO <c...@mindless.com> posted:
>Andi Kleen wrote in message ... >>In article <72ov7j$3j...@nnrp1.dejanews.com>, >>matom...@acm.org writes: >>> If on Linux, I would go with MkLinux for several reasons: >>> - Evolutionary path to Mach >>Mach seems to be a complete dead end. >whatever happened to the gnu hurd?
Development continues, probably most quickly in the form of the Debian Hurd project. See <http://www.debian.org>, and look for mailing lists...
It has definitely not progressed *real* fast...
-- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html> cbbro...@hex.net - "What have you contributed to Linux today?..."
> It seems that the GGI is currently starting to establish itself as the > low-level graphics interface for Linux (and others?), with X & others > to be layered on top of this. So basing the Windowing System on GGI > would probably allow you to reap the benefits of the graphics-device > drivers for GGI being implemented by others (including possibly the > manufacturers themselves), whilst leaving you much lee-way in the > Windowing System, since GGI is very low-level (if you don't use > libGGI, you get even more low-level access, if that should be needed, > IIRC).
Good idea. We waited for Flux to come out. Now let's wait for GGI to establish itself. If we plan it right, we can spend all our time waiting for the right software & will never have to code anything.
-- Harvey J. Stein BFM Financial Research hjst...@bfr.co.il
In article <joswig-1411980827480...@194.163.195.67> jos...@lavielle.com (Rainer Joswig) writes: >It's $5000 for a single machine, multiple emulations at the same >time, lots of source, lots of software, ... >Sadly I can tell you that this is ******really******* cheap. >Ask the other vendors, who are offering similar Lisp environments >for Unix. Seems like you have to be a big telecom company or in the >military to be able to afford Lisp development under Unix >with a commercial system.
Sadly so. I have a Sun Ultra at home, but you try getting a Solaris eval copy of something like Lispworks under the same terms that they entertain for stuff like PCs or Linux ( $50 or free for the latter) . If they just laugh in your face, I consider that being as 'polite' ...
> > It seems that the GGI is currently starting to establish itself as the > > low-level graphics interface for Linux (and others?), with X & others > > to be layered on top of this. So basing the Windowing System on GGI > > would probably allow you to reap the benefits of the graphics-device > > drivers for GGI being implemented by others (including possibly the > > manufacturers themselves), whilst leaving you much lee-way in the > > Windowing System, since GGI is very low-level (if you don't use > > libGGI, you get even more low-level access, if that should be needed, > > IIRC).
> Good idea. We waited for Flux to come out. Now let's wait for GGI to > establish itself. If we plan it right, we can spend all our time > waiting for the right software & will never have to code anything.
That's been the LispOS group's plan for quite a while now.
> In article <m2btm6hdxu....@blinky.bfr.co.il>, > hjst...@bfr.co.il (Harvey J. Stein) writes: > > Pierre Mai <p...@acm.org> writes: > > > > > It seems that the GGI is currently starting to establish itself as the > > > low-level graphics interface for Linux (and others?), with X & others > > > to be layered on top of this. So basing the Windowing System on GGI > > > would probably allow you to reap the benefits of the graphics-device > > > drivers for GGI being implemented by others (including possibly the > > > manufacturers themselves), whilst leaving you much lee-way in the > > > Windowing System, since GGI is very low-level (if you don't use > > > libGGI, you get even more low-level access, if that should be needed, > > > IIRC). > > > > Good idea. We waited for Flux to come out. Now let's wait for GGI to > > establish itself. If we plan it right, we can spend all our time > > waiting for the right software & will never have to code anything. > > That's been the LispOS group's plan for quite a while now.
The smart thing is to develop the (portable) CL apps necessary to give a lisp-machine personality on top of unix. If you do this, then you cut out the necessity of:
- Choosing which Common Lisp implementation to use. - Choosing which unix to implement on top of. - Writing device drivers/PCI crap/... for all the different kinds of hardware out there.
This allows getting a sort of user level lisp machine feel as soon as possible. It's also necessary anyway even if you're going to have lisp from the metal up - little of the work would be thrown away. At some low level you'd just rip out the cl/unix layer & plug in a cl/lispos layer. It'll also give the maximum spread for the apps - the system will be largely able to run on lispos or on unix & under a variety of Common Lisp implementations.
The problem is that the *sexy* thing to do is to boot your machine directly into the lisp interpreter, set lisp breakpoints in the tcp stack, ... However, to do this you also have to settle on a class of hardware, a particular Common Lisp implementation which will have to be hacked to deal with the low level sorts of things needed inside the kernel, ... Hell, once you've stuck yourself with needing a particular Common Lisp implementation, you might as well even consider one of the more modern Scheme implementations (like rscheme).
Now you even get to discuss whether the Common Lisp (or scheme) compiler should produce C code which gets compiled by a C compiler (i.e. - hybrid unix system) or whether it must produce machine code (i.e. - pure lisp system, aka hellish to port system).
So, everyone wants to start with the sexy stuff & no one's willing to do the apps, so the project's dead. Not that the sexy route is impossible. After all, Linux was able to get from 0 to many full fledged systems in ~8 years. However, lispos is a bigger project. Linux was just kernel - compiler, libs, apps & a "well" defined kernel interface already existed. Lispos is a much bigger project - it needs the apps, everyone's still arguing about kernel & system interfaces, and if you're going to do a pure lisp system you need some serious compiler work too.
The sexy route could work *if* a couple of people just made the decisions themselves & did it. But, like I said, "if".
-- Harvey J. Stein BFM Financial Research hjst...@bfr.co.il
> The smart thing is to develop the (portable) CL apps necessary to give > a lisp-machine personality on top of unix.
To Messrs Coleman and McDonald:
When scanning the LispOS mail archive, I saw that this approach is already being taken care of. Solution: CMUCL on top of Unix, don't expect any fast results. Coleman to start this, McDonald to do that. The postings were dated somewhere around april 98?, anyway at least half a year ago.
Stein) wrote: > This allows getting a sort of user level lisp machine feel as soon > as possible. It's also necessary anyway even if you're going to have > lisp from the metal up - little of the work would be thrown away. At > some low level you'd just rip out the cl/unix layer & plug in a > cl/lispos layer. It'll also give the maximum spread for the apps - > the system will be largely able to run on lispos or on unix & under a > variety of Common Lisp implementations.
> The problem is that the *sexy* thing to do is to boot your machine > directly into the lisp interpreter, set lisp breakpoints in the tcp > stack, ... However, to do this you also have to settle on a class of > hardware, a particular Common Lisp implementation which will have to > be hacked to deal with the low level sorts of things needed inside the > kernel, ... Hell, once you've stuck yourself with needing a > particular Common Lisp implementation, you might as well even consider > one of the more modern Scheme implementations (like rscheme).
...
> So, everyone wants to start with the sexy stuff & no one's willing to > do the apps, so the project's dead.
A couple of guys are maintaining the portable web server. They are interested in having more common ground in the source (streams, locks, processes, TCP/IP). If you have stuff to contribute - do it. See also the list of possible projects.
Harvey J. Stein wrote: > The smart thing is to develop the (portable) CL apps necessary to give > a lisp-machine personality on top of unix.
Yes. The project is huge, conflictive, and worse, the few people interested are are too busy with their jobs. We need to build developer mindshare. One thing that might work could be:
- Somebody creates an RPM for scsh, so Linux distributions start bundling as a basic tool. - Somebody developes a `lambdaconf' in scsh that beats the heck out of Autoconf (imagine having config test libraries so that people wouldn't need to go ripping off tests from this and that configure.in file!). - People start using lambdaconf and that motivates some to maintain scsh. - Some start writing scsh scripts for other purposes. - Newcomers (including VB types) start seeing all those parens in scripts coming with different apps, and think that's some quite usual Unix thing, and they buy into it. - Some people want to start writing real programs with a real compiler. More compiler maint. - Now they need FFIs to libraries. - Now they want _real_ lisp libraries. - Now they think C,C++,*x sucks and want a Lisp OS (better yet, they want Lisp/Java/Smalltalk/Eiffel-oriented _hardware_)
It wouldn't hurt either if some Lisp guerrillas created their own Linux distro where all sh scripts are incrementally migrated to scsh. Some are so trivial anybody could contribute one in the 5 minutes before dinner gets ready..
-- Fernando D. Mato Mira Real-Time SW Eng & Networking Advanced Systems Engineering Division CSEM HTTP: www.csem.ch Jaquet-Droz 1 email: matom...@acm.org CH-2007 Neuchatel tel: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720
From: "Fernando D. Mato Mira" <matom...@acm.org> Subject: Lisp through the back door (was: LispOS, LispVM projects?) Newsgroups: comp.lang.lisp,comp.lang.scheme
One thing that might work could be:
- Somebody creates an RPM for scsh, so Linux distributions start bundling as a basic tool.
From time to time people like Fernando ask about copyright info & putting scsh on some Linux distribution or another. So let me pass on some interesting news and also make a little statement about copyright.
The news:
Jonathan Rees came by my office yesterday and mentioned that he and Kelsey were close to getting Scheme48's copyright massively liberalised -- up to BSD or X levels. So that would make life a lot easier for flooding the world with Scheme48 bits.
Scsh Copyright:
The source files to scsh are usually copyright "Olin Shivers", or the other main author (usually Carlstrom, Albertz, or Fisher), or sometimes just "The Scheme Underground" -- whatever that might be. I have, to date, retained full rights on the source. Let me explain why.
It's not because I think it's going to make me a lot of money.
I'm delighted for people to steal the source or the design or the underlying ideas. That is why I wrote the thing. I give real Scheme implementors, such as Jim Blandy, major encouragement to do exactly this. See my essay on "the 80% problem" at the beginning of my SRE spec & tutorial for the attitudes behind this: http://www.ai.mit.edu/~shivers/sre.txt
I've kept tight control of scsh to date because I am afraid some bozo is going to come along, make a few "improvements" to the design, which will in fact be deep screwups, call it "scsh++" or "gnu scsh" or something, and release it. In short, I'm trying to control the *name* "scsh."
I've had bad experiences before. When you say m-x shell or m-x run-scheme or basically run any process in an emacs buffer, you run code I wrote for emacs, a package called "comint.el". When the FSF adopted comint.el, RMS threw out several of the most useful history-search commands, then another FSF hacker went in and tweaked some of the other commands (this wasn't Simon Marshall; it was a predecessor of his). Then the package accreted an enormous amount of hairy auxiliary code that added a lot of fragile machinery to the design -- code I had made a point of *not* adding over the course of several years. I had carefully tuned that package so that all the pieces *fit together* in nice ways; these tweaks destroyed that. As a result, I've never had a satisfying process-in-a-buffer experience since the gnu project adopted my source. Until the day comes when I decide to grit my teeth, and dive back into that mess of code for a solid week, I just have to grin and bear it.
I've seen "improvements" to scsh along the same lines -- changes that aren't sensitive to the distinction between syntax (notation), and data structure. I've had arguments with RMS that make clear he and I have fundamental disagreements about exactly this issue. I really don't want to see scsh go the same road.
Now, you may think this puts me in the "cathedral" camp, vs the "bazaar" camp, and that is somewhat true. Good design is very hard -- hard for me, anyway. Quality source code is rare. People who worry about security and robustness run "cathedral" systems such as FreeBSD or NetBSD, rather than Linux. But note that "cathedral" development groups are usually much more open than one would infer from Raymond's simplistic distinction -- the FreeBSD group, for example, puts their whole source tree up for network CVS access, and have stated that anyone who makes a serious change to the source will be given write access to the repository.
On the other hand, in over five years, I've had exactly one guy who popped up off the net and volunteered to hack scsh... actually do it. And many have started. No one has ported scsh to another Scheme platform, although many are interested. If a serious Scheme implementor ever does a complete port of the scsh Unix API to another platform, I am not going to let the source copyright stand in his way.
I'm not committed to the current copyright strategy. I've never said "no" to anyone who was nice enough to actually ask for permission to do anything at all with scsh, commercial or otherwise. I'd be happy to entertain alternate strategies. If you think the current copyright is a barrier to your getting something done, you are almost certainly mistaken.
So, back to Fernando's post: - Somebody developes a `lambdaconf' in scsh that beats the heck out of Autoconf (imagine having config test libraries so that people wouldn't need to go ripping off tests from this and that configure.in file!). - People start using lambdaconf and that motivates some to maintain scsh. - Some start writing scsh scripts for other purposes. - Newcomers (including VB types) start seeing all those parens in scripts coming with different apps, and think that's some quite usual Unix thing, and they buy into it.
Yeah, a Scheme autoconf would be nice. As would a scsh knockoff of make(1). Boy, I hate make for its horrible syntax. A good macro and some auxiliary support routines would do it. You already have the process notation for describing the commands to execute -- stuff like (cc ,@flags ,from -o ,to).
It wouldn't hurt either if some Lisp guerrillas created their own Linux distro where all sh scripts are incrementally migrated to scsh. Some are so trivial anybody could contribute one in the 5 minutes before dinner gets ready..
I have rewritten a lot of the /etc scripts in my linux box in scsh -- mostly ppp, dhcp, and pcmcia stuff; boy, is it pleasant.
Of course, you'd have to put a self-contained scsh with a statically-linked heap in /bin so the really basic, hindbrain scripts could run -- but that's no big deal.
David Fisher and I developed a lot of useful technology for doing this kind of thing last summer, including an argv[] switch-parser, and an expect(1) macro. I haven't released this, and probably won't until after I've rolled out a huge chunk of more-basic stuff I've done lately -- the new regexp system, and the new list, vector, string, sort, etc. libraries I'm proposing as SRFIs. But we'll get it out. -Olin
Olin Shivers <shiv...@lambda.ai.mit.edu> writes: > Jonathan Rees came by my office yesterday and mentioned that he and Kelsey > were close to getting Scheme48's copyright massively liberalised -- up to > BSD or X levels. So that would make life a lot easier for flooding the world > with Scheme48 bits.
Oh so sweet. Scheme48 is such a divine implementation, not to belittle other implementors mind you. Would this allow you to remove the notification requirement for commercial use from scsh, and if so would you plan on removing that? It's hard to get mgmt types to invest in something which they cannot outright puchase the rights to use commercially, or have a garuntee that they can use it commercially.
> I'm not committed to the current copyright strategy. I've never said "no" to > anyone who was nice enough to actually ask for permission to do anything at > all with scsh, commercial or otherwise. I'd be happy to entertain alternate > strategies. If you think the current copyright is a barrier to your getting > something done, you are almost certainly mistaken.
Oh, BTW someone has done a port of scsh to guile, but I'm not sure how complete it is. If something like this could be placed under GPL, provided it used a different name possibly, it would make scsh much more attractive to alot of people working on projects like Debian. Presently it is relegated to the non-free bin, which means that I can't use it for some of the infrastruture projects I am interested in. If scsh itself could be given a copyright which satisfies the Debian definition of free, then considering the possibly changes to the scheme48 copyright, I could use it straight up in these situations.
Perhaps there is some way to preserve the integrity of the name "scsh" and still have a copyright which allows free source modification and unrestricted use commercial or otherwise? It's obviously completely your decision, and I don't mean to imply you have any moral or civic responsibility to liberalize the license in that way.
>> The smart thing is to develop the (portable) CL apps necessary to give >> a lisp-machine personality on top of unix.
> To Messrs Coleman and McDonald:
> When scanning the LispOS mail archive, I saw that this approach is > already being taken care of. Solution: CMUCL on top of Unix, don't > expect any fast results. Coleman to start this, McDonald to do that. The > postings were dated somewhere around april 98?, anyway at least half a > year ago.
> Is this thing still being done?
> Lars Lundback
I'm still working on my end. In between getting engaged, getting dumped, ...
> > The smart thing is to develop the (portable) CL apps necessary to give > > a lisp-machine personality on top of unix.
> To Messrs Coleman and McDonald:
> When scanning the LispOS mail archive, I saw that this approach is > already being taken care of. Solution: CMUCL on top of Unix, don't > expect any fast results. Coleman to start this, McDonald to do that. The > postings were dated somewhere around april 98?, anyway at least half a > year ago.
> Is this thing still being done?
Different people are still working on bits and pieces. The various CL implementations (CMU CL) continue to improve.
Unfortunately, between work and other things (getting married, etc), I have not been able to put as much time in it, as I had wanted. Such is life.
> Perhaps there is some way to preserve the integrity of the name "scsh" > and still have a copyright which allows free source modification and > unrestricted use commercial or otherwise?
I believe this is the general intent of Raymond's "Artistic License" (cute name). I'll work something out. -Olin
Craig Brozefsky <cr...@onshore.com> writes: > Perhaps there is some way to preserve the integrity of the name "scsh" > and still have a copyright which allows free source modification and > unrestricted use commercial or otherwise?
Of course there is. The name can be trademarked. Look at TeX, for example. The code is in the public domain (sort of), but the name is strictly restricted to those programs that pass the TRIP test.
Copyright is a foolish way to protect a name; it just does not work. It protects that code base, but it does not restrict the use of the name by other code bases.
Antti-Juhani -- %%% Antti-Juhani Kaijanaho % g...@iki.fi % http://www.iki.fi/gaia/ %%% NOTE: I am migrating to a new setup. There may still be problems with my mail/news headers, so *please* trust the above addresses more than the addresses in the headers. I hope I'll get this working ASAP.
Lies, damned lies, and benchmarks! First, your time for ACL above is optimized, where as the comment above by Fernando specificly stated "w/o declarations".
I was involved in the ACL/SGI benchmark above. The "optimization" was just doing a (declaim (optimize (speed 3) (safety 0) (debug 0))), not actually putting declarations in the code. Otherwise, it was the "pure" Gabriel code.
Part of it is likely the SGI's blazing FP.
Larry
-- Lawrence Hunter, PhD. National Library of Medicine phone: +1 (301) 496-9303 Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673 Bethesda. MD 20894 USA email: hun...@nlm.nih.gov
Christopher Stacy <cst...@pilgrim.com> writes: > I think you have to have a 64 bit machine, or it's hopeless.
People keep making this point, but I just don't understand it. Last I heard, the Ivory emulator did some tricks like holding the 8-bit tags along with the 32-bit pointer value in a single 64-bit register, but what does that really buy? Is there enough state that register pressure is an issue? Does that alone give more than, say, a factor of two in performance?
"Fernando D. Mato Mira" <matom...@acm.org> writes:
> - Somebody developes a `lambdaconf' in scsh that beats the heck out of Autoconf > (imagine having config test > libraries so that people wouldn't need to go ripping off tests from this and > that > configure.in file!).
The `aclocal' program, which is part of GNU automake, grabs tests from such libraries.
I'd still be interested in seeing a `lambdaconf' -- with Scheme, quoting wouldn't be such a nightmare as it is with m4.
On Mon, 16 Nov 1998 19:57:02 +0100, Rainer Joswig <jos...@lavielle.com> wrote: >How does this work? AFAIK not even MacOS and Linux are able >to run at the same time...
There might be some solution to that, as soon as Sheepshaver for LinuxPPC exists :-)
In article <w0k4sruc6jx....@lagavulin.cyc.com>, David Gadbois <gadb...@lagavulin.cyc.com> wrote:
>Christopher Stacy <cst...@pilgrim.com> writes: >> I think you have to have a 64 bit machine, or it's hopeless.
>People keep making this point, but I just don't understand it. Last I >heard, the Ivory emulator did some tricks like holding the 8-bit tags >along with the 32-bit pointer value in a single 64-bit register, but >what does that really buy?
In short, speed.
[ On a 32 bit machine it isn't "hopeless" , just "slow as molasses" ]
Given that you are trying to emulate a machine with registers larger than 32 bits. It means not haveing to use 2 registers to "model" 1.
For one this aviods having to do 2 loads get the data and the tag. As opposed to one load to get both.
two registers one register
load data load data/tag load tag mask tag into another register
That mask isn't going to have to reach out into the memory hierarchy to get the data. Load once, use often. :-)
> Is there enough state that register >pressure is an issue?
Your running an emulator. Register pressure is an issue from the simply just because of that. You need registers for the emulator and you need registers for the code being executed.
Secondly, the Symbolics archictecture had a stack cache which also needs to be emulated. Preferable by registers. So that is consumer also.
I'd be very surprised with there were any underutilized registers by the Symbolics emulator. It was written in hand tuned assembler.
I'm not sure how they delt with the issues of the symbolics being Word addresses versus the byte address of the Alpha. [ that part of one paper isn't on the web. ] I imagine this may be a register consumer too.
> Does that alone give more than, say, a factor >of two in performance?
Pushing losts of tuff out to the high levels of the memory hierarchy typically has much more than a factor of two performance on high clock rate processors like the Alpha.
--
Lyman S. Taylor "Computers are too reliable to replace (ly...@cc.gatech.edu) humans effectively." Commander Nathan Spring, "Starcops"
> For one this aviods having to do 2 loads get the data and the tag. > As opposed to one load to get both. > two registers one register > load data load data/tag > load tag mask tag into another register > That mask isn't going to have to reach out into the memory hierarchy > to get the data. Load once, use often. :-)
Actually, I think this may not be as much of an issue as all that. If the data & tag are next to each other in address space, then those two loads probably come down to a single memory fetch and then a cache hit. If the cache hit is single-cycle then this may actually execute as fast as the other case, perhaps depending on pipeline issues.
Of course this assumes a 64-bit+ path to main memory, but I think everyone has that now (?).
Of course it's still a pain because it's a completely different implementation, and because of register pressure.
> David Gadbois <gadb...@lagavulin.cyc.com> wrote:
> >Last I heard, the Ivory emulator did some tricks like holding the > >8-bit tags along with the 32-bit pointer value in a single 64-bit > >register, but what does that really buy?
> In short, speed.
> [On a 32 bit machine it isn't "hopeless" , just "slow as molasses"]
Well, Open Genera 1.0 on a 190MHz 21064 was perfectly usable for development. More recent 32-bit machines are roughly 4-8 times faster than that old part, and, more importantly, have bigger caches with more associativity. So I would expect a 32-bit version of the emulator to be even more usable, even with a factor of two hit for a 32-bit emulator.
I still don't understand why folks are obsessing over some notion of absolute performance of the emulator. I mean, jeez, if performance is an issue, get rid of the emulation first.
> Given that you are trying to emulate a machine with registers larger > than 32 bits. It means not haveing to use 2 registers to "model" 1.
> For one this aviods having to do 2 loads get the data and the tag. > As opposed to one load to get both.
I gather that the current emulator uses two loads on the Alpha anyway: The tag bits are stored separately from the contents. The emulation of the SYS:MEMORY-READ instruction would go something like:
Mask the tag out of the register holding the argument address Load the contents of the address Compute the address of the tag Load the tag Mask in the tag to the contents
The rational was not wasting 24 bits for every (emulated) word of memory and to allow for easier (unboxed) communication of values to the run-time system.
