What would be the best way to put together a workstation optimized for
running and developing in lisp?
What architecture to go ahead with? Or that dosent make a difference?
Would it make sense in investing in more RAM than CPU ?
nikhilketkar wrote:
> What would be the best way to put together a workstation optimized for
> running and developing in lisp?
> What architecture to go ahead with? Or that dosent make a difference?
> Would it make sense in investing in more RAM than CPU ?
Buy a Mac. Currently, there is no platform that supports more Common
Lisp implementations than Mac OS X.
Make sure to add a considerable amount of RAM when you buy a Mac, Apple
has a tendency to underestimate the need for RAM.
Apart from that, it doesn't really matter what you buy. Just make sure
that it's one of the newer models. A Mac Mini, for example, should be
sufficient.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> nikhilketkar wrote:
>
> > What would be the best way to put together a workstation optimized for
> > running and developing in lisp?
> > What architecture to go ahead with? Or that dosent make a difference?
> > Would it make sense in investing in more RAM than CPU ?
Usually any high-end Unix, PC or Mac system will be good enough.
But he needs to be more specific what he wants to do with Lisp.
> Buy a Mac. Currently, there is no platform that supports more Common
> Lisp implementations than Mac OS X.
>
> Make sure to add a considerable amount of RAM when you buy a Mac, Apple
> has a tendency to underestimate the need for RAM.
Actually I don't think that Apple underestimates the need for RAM.
Don't buy RAM, disk drives, floppy disks, printer ink and
similar stuff from a computer vendor. It will almost always
be too expensive. Apple shows you the configuration with the
minimum useful amount of RAM - you can configure higher
amounts of RAM in their online shop. Watch the prices!
So the usual way to deal with that is to buy a Mac with
the minimum amount of RAM you can order and buy more RAM
somewhere else. If you happen to know a good dealer, he/she
might just have some use for the original RAM and lower
the price a bit.
> Apart from that, it doesn't really matter what you buy. Just make sure
> that it's one of the newer models. A Mac Mini, for example, should be
> sufficient.
The Mac Mini is sufficient. It has a few limitations - one is
the maximum of possible RAM is 1 GB. It is hardly a 'workstation'
- by today's criteria.
Otherwise here are a few tips for those who want a Mac-based
workstation (not just a desktop computer).
One may want to buy the fastest Mac. Note though, that it
may be that Apple will update the PowerMac line (slightly)
in the next days.
- PowerMac G5, Dual G5 processor, 2.5Ghz
- Get atleast 2GB RAM
- Get the NVIDIA 6800 Ultra DDL or the ATI X800 XT Mac Edition
graphics cards (both can drive the 30" Cinema Display)
- Buy two 10000U/min Disks and configure them as RAID 0 (or 2)
- Get one or two large displays (23" Cinema Display)
This will cost a few Euros. But we paid much more for machines
that were less capable just a few years ago.
Then talk to the Lisp vendors to better support the Mac.
Currently none of the better Lisps have
- specialized support for the G5 (aka PowerPC 970fx)
- automagical Altivec support
- a ****really***** good native Mac UI (neither for development nor for delivery)
Other from that one will have a large amount of implementations
to choose from.
And here comes the last and most important tip: if one want
to get work done with your Lisp workstation, cancel your
Internet account. ;-)
Rainer Joswig <······@lisp.de> writes:
> And here comes the last and most important tip: if one want
> to get work done with your Lisp workstation, cancel your
> Internet account. ;-)
What? And loose access to #lisp and cll?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David Steuber <·····@david-steuber.com> writes:
> Rainer Joswig <······@lisp.de> writes:
>
>> And here comes the last and most important tip: if one want
>> to get work done with your Lisp workstation, cancel your
>> Internet account. ;-)
>
> What? And loose access to #lisp and cll?
Like he said. I get more done on my laptop in coffee shops than I ever
do on my higher-powered machine at home.
-dan
--
Daniel Barlow // ·············@uk.clara.net // ext 3233
ENOVWLS
On Tue, 26 Apr 2005 11:21:51 +0100, Daniel Barlow <·············@uk.clara.net> wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>> What? And loose access to #lisp and cll?
>
> Like he said. I get more done on my laptop in coffee shops than I
> ever do on my higher-powered machine at home.
Yep, I also realized this is a nice trick about a year ago.
Unfortunately, in the meantime my favorite caf� started offering WLAN
access to the Internet... :(
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> wrote:
+---------------
| Daniel Barlow <·············@uk.clara.net> wrote:
| > David Steuber <·····@david-steuber.com> writes:
| >> What? And loose access to #lisp and cll?
| >
| > Like he said. I get more done on my laptop in coffee shops than I
| > ever do on my higher-powered machine at home.
|
| Yep, I also realized this is a nice trick about a year ago.
| Unfortunately, in the meantime my favorite caf� started offering
| WLAN access to the Internet... :(
+---------------
I'm afraid I did it to myself! I subscribe to the AT&T\\\\ Cingular
"EDGE" service[1], which comes with a little PCMCIA card that plugs
into my laptop, so I don't even need a WiFi-enabled coffeeshop to
service my "comp.lang.lisp" jones... ;-} ;-}
-Rob
p.s. With a good signal, I get ~240 Kb/s sustained download & ~100 Kb/s
sustained upload, which is quite good, but it has *terrible* RTT (latency)
of a half-second or more. Makes editing... "interesting". [Full-duplex
ASR-33, anyone?]
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
nikhilketkar wrote:
> What would be the best way to put together a workstation optimized for
> running and developing in lisp?
> What architecture to go ahead with? Or that dosent make a difference?
> Would it make sense in investing in more RAM than CPU ?
>
What platform are you running right now?
Whatever it is, grab emacs and clisp (if you're low on resources)
or another Lisp and try it out ;)
I big monitor might help. If you need more speed, get something
faster, but with the quick code/compile/test cycle of Lisp you
should really be fine.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
"nikhilketkar" <············@gmail.com> writes:
> What would be the best way to put together a workstation optimized for
> running and developing in lisp?
> What architecture to go ahead with? Or that dosent make a difference?
If you don't have any specific project or requirement, I suggest that
you start using whatever hardware and operating system you currently
have, then decide where the performance or productivity bottlenecks
are.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
I think I need to be a lot more specific about the kind of work I do.
I am a phd. student and my research is in multirelational learning. I
do all my work in LISP. I dont need cool and fancy stuff. What I need
is something that prevents the "stack overflow" messages. My LAB has a
significant amount of computational resources currently and that does
not happen many times.
I would like to discuss this issue from a study perspective. The
question is what kind hardware/systems should be be put together for
using LISP. This issue is important because LISP Machines are dead but
LISP has just reached its teens. The objective is to put together 'off
the shelf' hardware and put together a workstation whose primary
purpose is running LISP. I would also like to discuss putting together
a cluster whose primary purpose is running LISP. I intend this to be an
educational experience which will lead to a better understanding of
LISP, hardware and systems in general.
nikhilketkar wrote:
> I think I need to be a lot more specific about the kind of work I do.
> I am a phd. student and my research is in multirelational learning. I
> do all my work in LISP. I dont need cool and fancy stuff. What I need
> is something that prevents the "stack overflow" messages. My LAB has
a
> significant amount of computational resources currently and that does
> not happen many times.
I have no experience with this sort of issue, but I would expect
maximum "computational resources" to be available through a combination
of a 64-bit memory architecture and a mature commercial Common Lisp
implementation on that system. Franz claims to have Allegro CL 7.0
running on Linux x86, and several 64-bit UNIXes (the Mac OS version is
only listed in 32-bit; perhaps this will change when Mac OS X 10.4
comes out.) It is not immediately clear from Lispworks.com whether they
have a 64-bit offering.
Ph.D. research, to me, implies at least some level of funding for a
commercial product, unless it is only incidental to your research
goals.
> LISP has just reached its teens. The objective is to put together
'off
> the shelf' hardware and put together a workstation whose primary
> purpose is running LISP.
"off the shelf" biases me toward a Linux x86-64 platform. I have a
fondness for Macs, but the 64-bit stuff is only coming hot from the
presses now.
>I would also like to discuss putting together
> a cluster whose primary purpose is running LISP. I intend this to be
an
> educational experience which will lead to a better understanding of
> LISP, hardware and systems in general.
"Lisp, hardware, and systems in general" are each extremely broad
topics. A Ph.D. project in a mature field requires relentless focus.
Getting practical experience on a new OS is good for the resume, but
you have to choose carefully before breaking new ground, or you can get
sidetracked for a long time. (I learned Lisp while working on a Ph.D.
in experimental physics, so I don't mean to discourage you, but I was
just doing small-scale hacking, not trying to build a new kind of
computer cluster.)
Have fun, and good luck.
"nikhilketkar" <············@gmail.com> writes:
> No No..this is not my phd. topic. This is just out of intrest.
So far I think "get a Mac" is the best advice. For clustering,
Rendezvous may be just the ticket.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
nikhilketkar wrote:
> What would be the best way to put together a workstation optimized for
> running and developing in lisp?
> What architecture to go ahead with? Or that dosent make a difference?
> Would it make sense in investing in more RAM than CPU ?
>
If I would do it I would get one of those new AMD64 systems. Load a 64
bit OS and find a 64 Bit Lisp. Then you do not have to worry (as much)
about fixnum and array limits. Of course you have to concerned about
your deployment system. There are many non-Lisp things I would
want in a workstation, 3 monitors, quiet, back-up media,..
(and then there is price). Get good quality parts, do not skimp, there
is nothing like a flaky system, it can drive you insane.
I do not see why 1G of RAM should not be enough for just about anything,
if you do hit the limit, then the solution is relatively easy. Just
get a motherboard that supports lots of RAM.
Wade
After takin a swig o' Arrakan spice grog, Wade Humeniuk <··················@telus.net> belched out:
> nikhilketkar wrote:
>> What would be the best way to put together a workstation optimized for
>> running and developing in lisp?
>> What architecture to go ahead with? Or that dosent make a difference?
>> Would it make sense in investing in more RAM than CPU ?
>>
>
> If I would do it I would get one of those new AMD64 systems. Load a 64
> bit OS and find a 64 Bit Lisp. Then you do not have to worry (as much)
> about fixnum and array limits. Of course you have to concerned about
> your deployment system. There are many non-Lisp things I would
> want in a workstation, 3 monitors, quiet, back-up media,..
> (and then there is price). Get good quality parts, do not skimp, there
> is nothing like a flaky system, it can drive you insane.
>
> I do not see why 1G of RAM should not be enough for just about anything,
> if you do hit the limit, then the solution is relatively easy. Just
> get a motherboard that supports lots of RAM.
Which Lisps support AMD64 so far?
I didn't think there were any just yet...
[rummaging on my Debian box...]
Hmm...
no, no cmucl.
CLISP works, but that doesn't make it '64 bit'...
Interesting... sbcl is available, which suggest that they have built
an AMD64 code generator...
Interesting! That is rather encouraging!
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxfinances.info/info/postgresql.html
Rules of the Evil Overlord #85. "I will not use any plan in which the
final step is horribly complicated, e.g. "Align the 12 Stones of Power
on the sacred altar then activate the medallion at the moment of total
eclipse." Instead it will be more along the lines of "Push the
button." <http://www.eviloverlord.com/>
Christopher Browne <········@acm.org> writes:
> After takin a swig o' Arrakan spice grog, Wade Humeniuk <··················@telus.net> belched out:
> > nikhilketkar wrote:
> >> What would be the best way to put together a workstation optimized for
> >> running and developing in lisp?
> >> What architecture to go ahead with? Or that dosent make a difference?
> >> Would it make sense in investing in more RAM than CPU ?
> >>
> >
> > If I would do it I would get one of those new AMD64 systems. Load a 64
> > bit OS and find a 64 Bit Lisp. Then you do not have to worry (as much)
> > about fixnum and array limits. Of course you have to concerned about
> > your deployment system. There are many non-Lisp things I would
> > want in a workstation, 3 monitors, quiet, back-up media,..
> > (and then there is price). Get good quality parts, do not skimp, there
> > is nothing like a flaky system, it can drive you insane.
> >
> > I do not see why 1G of RAM should not be enough for just about anything,
> > if you do hit the limit, then the solution is relatively easy. Just
> > get a motherboard that supports lots of RAM.
>
> Which Lisps support AMD64 so far?
>
> I didn't think there were any just yet...
Allegro CL does, both the 32-bit and a 64-bit version.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·····················@news20.bellglobal.com>,
Christopher Browne <········@acm.org> wrote:
>Which Lisps support AMD64 so far?
>
>I didn't think there were any just yet...
Gambit-C beta is a 64-bit Scheme that works just fine on AMD64.
Brad
Christopher Browne <········@acm.org> wrote:
+---------------
| Which Lisps support AMD64 so far?
| I didn't think there were any just yet...
| [rummaging on my Debian box...]
| Hmm... no, no cmucl.
+---------------
CMUCL-19a works fine as a 32bit app on AMD64 under a 64-bit
Linux such as 2.4.21-20.EL (RedHat something or other).
Just grab the pre-built binaries and hand-install...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Sun, 24 Apr 2005 08:03:40 +0200, Friedrich Dominicus <···················@q-software-solutions.de> wrote:
> Christopher Browne <········@acm.org> writes:
>
>> Which Lisps support AMD64 so far?
> Franz Common Lisp
> SBCL
> CLISP
And Scieneer Common Lisp.
And LispWorks 5.0 according to Dave Fox' talk in Amsterdam yesterday.
Unfortunately, it hasn't been released yet.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Sat, 23 Apr 2005 19:07:03 +0000, Christopher Browne wrote:
> Interesting... sbcl is available, which suggest that they have built an
> AMD64 code generator...
>
> Interesting! That is rather encouraging!
For its age it's remarkably mature. I find it rather extraordinary that
64-bit Lisp implementations are available for running on 64-bit Operating
Systems before Microsoft even managed to get their 64-bit OS out the door.
A very important change that occurred mid-March was the introduction of
immediate single (32-bit) floats by Juho Snellman. A single-float can now
be returned from a global function without it having to be allocated on
the heap.
Amusingly I'm now looking at whether I should go back to 32-bit floats. I
wonder if leaving room for tag bits was ever seriously considered in the
ANSI/IEEE 754-1985 standardisation process.
Regards,
Adam
On Sat, 23 Apr 2005 19:07:03 +0000, Christopher Browne wrote:
> CLISP works, but that doesn't make it '64 bit'...
CLISP has a MOST-POSITIVE-FIXNUM of 4294967295 on AMD64, which is still a
big improvement over 16777215 on IA32.
The CVS version of GCL (gclcvs on Debian) has a MOST-POSITIVE-FIXNUM of
9223372036854775807 on AMD64 compared to 2147483647 on IA32. GCL is yet to
incorporate READTABLE-CASE support in its progress towards ANSI
compatibility.
ECL has a MOST-POSITIVE-FIXNUM of 2305843009213693951 on AMD64 compared
with 536870911 on IA32. ECL is rapidly become ANSI compliant and like GCL
can compile to shared objects (ECL even claims to generate Win32 DLLs).
ABCL also runs on AMD64 builds of the Java Virtual Machine and
unsurprisingly keeps a MOST-POSITIVE-FIXNUM of 2147483647. Still it gains
all the benefits of a larger address space and AMD64 JIT optimisation.
The JVM itself has a serious limitation that Sun is yet to address: All
array indices are limited to 31 bits.
Thus to more or less a degree all these implementations (plus SBCL as the
native code compiler with a standard virtual memory size over 8GB) are
enhanced for 64 bits on AMD64.
Regards,
Adam
Wade Humeniuk <··················@telus.net> writes:
> If I would do it I would get one of those new AMD64 systems.
Yes - even with a 32 bit lisp that's a good choice!
My informal LispWorks-benchmarking shows that even the current 32-bit
version runs much faster on Opteron and Athlon64 boxes than on the
fastest Xeon boxes.
(I also agree that a mac with OS X makes a nice Lisp Workstation, and
actually LispWorks on my 1.33Ghz G4 PowerBook is also very fast
compared to Intel machines, but of course much slower than AMD 64)
> I do not see why 1G of RAM should not be enough for just about anything,
Hah, my workstation has 1G, and I keep running out of memory all the
time!
--
(espen)
"nikhilketkar" <············@gmail.com> wrote in message
·····························@o13g2000cwo.googlegroups.com...
> What would be the best way to put together a workstation optimized for
> running and developing in lisp?
> What architecture to go ahead with? Or that dosent make a difference?
> Would it make sense in investing in more RAM than CPU ?
>
I have read that the best development environments
for Lisp were the Lisp machines of the early 1990's, now
owned by but a few devotees and some museums.
There are some postings here and there about how wonderful they
were, the unsurpassed efficacy of their environments... etc. etc.
There are some movies demonstrating these environments on the web here and
there,
and they are indeed quite impressive.
Yet... here is the curious part:
The hardware of today probably easily surpasses the even microcoded
environments of 15 years ago.
And yet...no Lisp machines on our desktop - yes, most certainly several
excellent Lisp implementations by various vendors
and some excellent open sourced or gnu stuff - but hardly to be
considered in the same league with LM and Symbolics and TI Explorer.
Is what ZMacs and all the other much ballyhooed features of the old systems
so hard to emulate with the very powerful software of today??
Has anyone even tried?? Or were the MIT (and other) programmers
of 20 years ago somehow smarter than today's developers??
ECB in Emacs seems a step in the right direction, but just a baby step
towards the "what might be".
Mysterious.
Tak (Jim Pannozzi)
Quoth "Takuon Soho" <···@somwhere.net>:
> The hardware of today probably easily surpasses the even microcoded
> environments of 15 years ago.
>
> And yet...no Lisp machines on our desktop - yes, most certainly several
> excellent Lisp implementations by various vendors
> and some excellent open sourced or gnu stuff - but hardly to be
> considered in the same league with LM and Symbolics and TI Explorer.
Part of what _broke_ is that many these systems built their own GUIs,
which takes a barrel of effort.
With the "destruction" of market for them, and the whole "destruction"
of the notion of there being an "OS development market" (you have very
little room in between recreating another Linux/*BSD clone, for which
there is little money, and creating something that'll call Microsoft's
"hitmen" on you), there has been considerable discouragement against
such developments.
Windows is distasteful in many ways... So also is X, particularly to
Lisp folk.
The "Unix Haters' Handbook" was shaped very much by fans of the
various sorts of Lisp Machines.
I don't see it being likely that jumping into Windows will "win the
day." I don't see any other alternative than for people to hold their
noses and do something on top of X.
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxfinances.info/info/slony.html
People consistently decry X for doing precisely what it was designed
to do: provide a mechanism to allow *OTHERS* to build GUI systems.
-- John Stevens <········@samoyed.ftc.nrcs.usda.gov>
On Sat, 23 Apr 2005 19:07:04 +0000, Christopher Browne wrote:
> With the "destruction" of market for them, and the whole "destruction"
> of the notion of there being an "OS development market" (you have very
> little room in between recreating another Linux/*BSD clone, for which
> there is little money, and creating something that'll call Microsoft's
> "hitmen" on you), there has been considerable discouragement against
> such developments.
So no FreeLispOS then. And yet there are plenty of niches to fill. Just
look at all the Linux distros.
Centuries ago, Nostradamus foresaw when BR <··········@comcast.net> would write:
> On Sat, 23 Apr 2005 19:07:04 +0000, Christopher Browne wrote:
>> With the "destruction" of market for them, and the whole
>> "destruction" of the notion of there being an "OS development
>> market" (you have very little room in between recreating another
>> Linux/*BSD clone, for which there is little money, and creating
>> something that'll call Microsoft's "hitmen" on you), there has been
>> considerable discouragement against such developments.
> So no FreeLispOS then. And yet there are plenty of niches to
> fill. Just look at all the Linux distros.
Well, if you build something that runs on top of either Linux or some
BSD, along with X and Emacs, then you can build the applications
without having to start over any time the disk controller vendors
change, or there's a new model of ATI video card.
That's essentially where OpenGenera went, with the difference that
they wound up choosing the "dead end" of depending on Digital
Alpha/OSF/1 as the new underpinning of the system. I can't call them
dumb for making the choice they did; it wasn't at all evident, at the
time, that it was a poor choice.
--
(format nil ···@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/slony.html
Rules of the Evil Overlord #5. "The artifact which is the source of my
power will not be kept on the Mountain of Despair beyond the River of
Fire guarded by the Dragons of Eternity. It will be in my safe-deposit
box. The same applies to the object which is my one weakness."
<http://www.eviloverlord.com/>
Christopher Browne <········@acm.org> writes:
> Well, if you build something that runs on top of either Linux or some
> BSD, along with X and Emacs, then you can build the applications
> without having to start over any time the disk controller vendors
> change, or there's a new model of ATI video card.
>
If someone really wanted to do this....
1. Get a uinxy lisp system that does not need to run external programs
in day to day operations. ie, no gcc for example. This probably
knocks out GCL, right? It would be cooler if it used native threads
just so that it would run well on a mp box but this is not required.
2. Expand it out until all the "important" system calls can be called
from lisp functions. You obviously need all the file system calls but
you also probably need the swap management calls as well. For a first
pass scan the section 2 and section 3 man pages and make sure that
anything that looks important can be called. Figuring out ioctl and
then what ioctl's have to be done to bring up the network interface
would be a smashing start. One will not have ifconfig :-)
3. Make sure that the screen i/o goes through the frame buffer (ie, no
X).
4. Make sure that you can read the mouse and keyboard etc. Once again,
no X loop.
5. Build a CD with your favorite boot code from either linux or *bsd,
a kernel, and put your statically linked lisp system on it as well
with a link to /sbin/init (or where ever your kernel expects to find
init). Put in some convient location all the support files that your
lisp needs as well.
6. Boot. Once the kernel is done loading you should have a lisp
prompt. You're running as root, obviously :-)
Yes, it's not lisp all the way down, though it's close, but for free
you get:
- a whole lot of fiddly device drivers.
- debugged and robust file systems.
Both of those are hard and painful to write.
The squeak folks are quite close to this, though, I'm not sure that
anyone is really going to go all the way. Maybe I'll add it to my
(too long) project list... Once done for one unixy program it should
be easy to do with another.
Why, you might ask, doesn't someone do this if it's so "easy." The
problem is that while you don't need the underlying OS, many of the
programs that come with an OS are bloody handy. In the above scenario
you won't have emacs/xemacs, for example. Therefore your lisp system
will need to have some sort of internal editor.
No mail/news reader. It's not impossible to write, but, it'll take a
while.
No firefox/mozilla/etc. This is a big job to write. Web sites are
the definition of kludge. Even writing something that will render in
text in a way that you can read it will be a bit of a job (see lynx).
SSL and forms turn out to be oddly important as well :-)
No graphics. Well, you will have the ability to turn a pixel a
certain color. Then it's just a small matter of programming and some
time with Foley and van Dam et al and you have a windowing system :-)
A bit more time and some more reading of Watt and you have Quake...
No sh/bash/tcsh/what ever. The syntax is horrid, but, you'd be
suprised how optimized they are for dealing with masses of files.
This was always a gigantic pita on the
Explorers. One. File. At. A. Time. or you were flipping through
manuals/reading online docs and scripting away. OTOH, you're likely
to need less files so this might not be such a big deal.
No everything else. Every utility that comes with linux/*bsd/windows
you'll have to do on your own as you need them. One probably doesn't
need 95% of them, but, the other 5% will be a hassle. I'd miss tar
and ssh/scp.
The way to gauge how hard this might be for you (that's an arbitrary
you) would be to condition yourself to log in, start only lisp, and
then do everything you can from lisp (and no (system "do something"))
and watch what you have to escape from lisp to do. Those things
you'll have to write.
If I can figure out how to make Squeak write to the frame buffer in
NetBSD (my prefered OS, and the one I'm most familar with) then I'll
build a static binary and make a boot CD and give this a shot. If I
get this to work I'm happy to point others at the code. Don't hold
your breath though.
cheers
bruce
Bruce O'Neel <···········@obs.unige.ch> writes:
> Christopher Browne <········@acm.org> writes:
>
>
>> Well, if you build something that runs on top of either Linux or some
>> BSD, along with X and Emacs, then you can build the applications
>> without having to start over any time the disk controller vendors
>> change, or there's a new model of ATI video card.
>>
>
> If someone really wanted to do this....
>
> 1. Get a uinxy lisp system that does not need to run external programs
> in day to day operations. ie, no gcc for example. This probably
> knocks out GCL, right? It would be cooler if it used native threads
> just so that it would run well on a mp box but this is not required.
>
> 2. Expand it out until all the "important" system calls can be called
> from lisp functions. You obviously need all the file system calls but
> you also probably need the swap management calls as well. For a first
> pass scan the section 2 and section 3 man pages and make sure that
> anything that looks important can be called. Figuring out ioctl and
> then what ioctl's have to be done to bring up the network interface
> would be a smashing start. One will not have ifconfig :-)
>
> 3. Make sure that the screen i/o goes through the frame buffer (ie, no
> X).
>
> 4. Make sure that you can read the mouse and keyboard etc. Once again,
> no X loop.
>
> 5. Build a CD with your favorite boot code from either linux or *bsd,
> a kernel, and put your statically linked lisp system on it as well
> with a link to /sbin/init (or where ever your kernel expects to find
> init). Put in some convient location all the support files that your
> lisp needs as well.
>
> 6. Boot. Once the kernel is done loading you should have a lisp
> prompt. You're running as root, obviously :-)
One thing that you need to boot is mount(8) unless you have mount(2).
See my "Emacs standing alone on a Linux Kernel" HOWTO:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
You could easily substitute a Common Lisp instead of emacs, but
indeed, it'd need more work to integrate other tools. At least
emacs comes with shell, news, mail, web, ftp, etc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
On 25 Apr 2005 15:22:21 +0200, <···········@obs.unige.ch> wrote:
>
> The way to gauge how hard this might be for you (that's an arbitrary
> you) would be to condition yourself to log in, start only lisp, and
> then do everything you can from lisp (and no (system "do something"))
> and watch what you have to escape from lisp to do. Those things
> you'll have to write.
Since this thread started, I've been busy using CMUCL as my user
shell. So I would disagree on "no using system", since whenever I'm
using system I get to see what's missing, but I also get the work
done. Unless you get to be one of Paul Grahams summer interns to
bring a Lisp Workstation into being, one must pay the bills
afterall.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
> If someone really wanted to do this....
How about for starters, we find out what happened to the
TI Explorer Lisp code - TI got OUT of AI experimentation
a long time ago - did they:
a. sell the code to someone
b. give it away
c. its lying forgotten on some old tapes in an abandoned mail room scheduled
for demolition.
d. TI managment is convinced this stuff is totally worthless but if they
release it and something important is built with it, they'll look like
idiots,
so its been carefully buried somewhere and they lost the key.
Consider this as a related example,
the power of something like the old Macsyma would be unknown to everyone
now if it were not for the dedication and work of Dr. William Schelter in
getting
the rights to an earlier version and re-building it as the wonderful
"Maxima" symbolic
math system, available today on both Windows and Linux. The power of all
those
man hours of development by the numerous early dedicated Macsyma
mathematicians
and programmers has hence been passed down to us. It even comes with
integrated
3D plotting graphics. Work continues on it today by a dedicated group of
enthusiasts and
the results are very very impressive.
But the Lisp programmers who created perhaps the greatest development
environment
in history, their work is lost with the exception of some commercial
packages which
are priced out of reach of the average developer.
To underscore the totality of the "newspeak" burial, I checked a list of
Emacs implementations
recently and it mentioned just about every possible editor, many of which
had little to do with Emacs,
with the amazing exception of Zmacs which was not mentioned at all.
Tak
P.S. Oh by the way, there is some sample Newsreader code for the TI Explorer
in the Carnegie Mellon Lisp archives - true it is not of much use without
the rest of the system, but still suggestive.
"Bruce O'Neel" <···········@obs.unige.ch> wrote in message
····················@obs.unige.ch...
> Christopher Browne <········@acm.org> writes:
>
>
>> Well, if you build something that runs on top of either Linux or some
>> BSD, along with X and Emacs, then you can build the applications
>> without having to start over any time the disk controller vendors
>> change, or there's a new model of ATI video card.
>>
>
> If someone really wanted to do this....
>
> 1. Get a uinxy lisp system that does not need to run external programs
> in day to day operations. ie, no gcc for example. This probably
> knocks out GCL, right? It would be cooler if it used native threads
> just so that it would run well on a mp box but this is not required.
>
> 2. Expand it out until all the "important" system calls can be called
> from lisp functions. You obviously need all the file system calls but
> you also probably need the swap management calls as well. For a first
> pass scan the section 2 and section 3 man pages and make sure that
> anything that looks important can be called. Figuring out ioctl and
> then what ioctl's have to be done to bring up the network interface
> would be a smashing start. One will not have ifconfig :-)
>
> 3. Make sure that the screen i/o goes through the frame buffer (ie, no
> X).
>
> 4. Make sure that you can read the mouse and keyboard etc. Once again,
> no X loop.
>
> 5. Build a CD with your favorite boot code from either linux or *bsd,
> a kernel, and put your statically linked lisp system on it as well
> with a link to /sbin/init (or where ever your kernel expects to find
> init). Put in some convient location all the support files that your
> lisp needs as well.
>
> 6. Boot. Once the kernel is done loading you should have a lisp
> prompt. You're running as root, obviously :-)
>
> Yes, it's not lisp all the way down, though it's close, but for free
> you get:
>
> - a whole lot of fiddly device drivers.
>
> - debugged and robust file systems.
>
> Both of those are hard and painful to write.
>
> The squeak folks are quite close to this, though, I'm not sure that
> anyone is really going to go all the way. Maybe I'll add it to my
> (too long) project list... Once done for one unixy program it should
> be easy to do with another.
>
> Why, you might ask, doesn't someone do this if it's so "easy." The
> problem is that while you don't need the underlying OS, many of the
> programs that come with an OS are bloody handy. In the above scenario
> you won't have emacs/xemacs, for example. Therefore your lisp system
> will need to have some sort of internal editor.
>
> No mail/news reader. It's not impossible to write, but, it'll take a
> while.
>
> No firefox/mozilla/etc. This is a big job to write. Web sites are
> the definition of kludge. Even writing something that will render in
> text in a way that you can read it will be a bit of a job (see lynx).
> SSL and forms turn out to be oddly important as well :-)
>
> No graphics. Well, you will have the ability to turn a pixel a
> certain color. Then it's just a small matter of programming and some
> time with Foley and van Dam et al and you have a windowing system :-)
> A bit more time and some more reading of Watt and you have Quake...
>
> No sh/bash/tcsh/what ever. The syntax is horrid, but, you'd be
> suprised how optimized they are for dealing with masses of files.
> This was always a gigantic pita on the
> Explorers. One. File. At. A. Time. or you were flipping through
> manuals/reading online docs and scripting away. OTOH, you're likely
> to need less files so this might not be such a big deal.
>
> No everything else. Every utility that comes with linux/*bsd/windows
> you'll have to do on your own as you need them. One probably doesn't
> need 95% of them, but, the other 5% will be a hassle. I'd miss tar
> and ssh/scp.
>
> The way to gauge how hard this might be for you (that's an arbitrary
> you) would be to condition yourself to log in, start only lisp, and
> then do everything you can from lisp (and no (system "do something"))
> and watch what you have to escape from lisp to do. Those things
> you'll have to write.
>
> If I can figure out how to make Squeak write to the frame buffer in
> NetBSD (my prefered OS, and the one I'm most familar with) then I'll
> build a static binary and make a boot CD and give this a shot. If I
> get this to work I'm happy to point others at the code. Don't hold
> your breath though.
>
>
> cheers
>
> bruce
BR wrote:
> So no FreeLispOS then. And yet there are plenty of niches to fill. Just
> look at all the Linux distros.
I would think all those Linux distros are the result rather of egomania
than of necessity...
mkb.
In article <···················@newsread3.news.pas.earthlink.net>,
"Takuon Soho" <···@somwhere.net> wrote:
> "nikhilketkar" <············@gmail.com> wrote in message
> ·····························@o13g2000cwo.googlegroups.com...
> > What would be the best way to put together a workstation optimized for
> > running and developing in lisp?
> > What architecture to go ahead with? Or that dosent make a difference?
> > Would it make sense in investing in more RAM than CPU ?
> >
>
> I have read that the best development environments
> for Lisp were the Lisp machines of the early 1990's, now
> owned by but a few devotees and some museums.
>
> There are some postings here and there about how wonderful they
> were, the unsurpassed efficacy of their environments... etc. etc.
> There are some movies demonstrating these environments on the web here and
> there,
> and they are indeed quite impressive.
>
> Yet... here is the curious part:
>
> The hardware of today probably easily surpasses the even microcoded
> environments of 15 years ago.
>
> And yet...no Lisp machines on our desktop - yes, most certainly several
> excellent Lisp implementations by various vendors
> and some excellent open sourced or gnu stuff - but hardly to be
> considered in the same league with LM and Symbolics and TI Explorer.
>
> Is what ZMacs and all the other much ballyhooed features of the old systems
> so hard to emulate with the very powerful software of today??
>
> Has anyone even tried?? Or were the MIT (and other) programmers
> of 20 years ago somehow smarter than today's developers??
It is not easy to create these environments. It took large
companies like Xerox or DARPA paid research labs and companies
to do it. Several thousand person years went into building these
systems and it took lots of money.
At the end they were large complicated software systems
that had all kinds of legacy code and were a bit hard to move
on. The important achievement was not the hardware (this was
to go away anyway), but the software. Unfortunately
ports of the software to stock hardware (Suns, Macs, later PCs, ...)
did not evolve with the underlying software/hardware platform.
It was also at a time when monetary resources were getting smaller
all the time. The AI winter started... Then all the legal issues
and a lack of interest of the owners to settle those
made it impossible to use the legacy code later by other
companies. Companies like TI complete lost interest... Research
labs moved on.
> ECB in Emacs seems a step in the right direction, but just a baby step
> towards the "what might be".
>
> Mysterious.
It's not mysterious. Customers are needed and you need some clue
how to scale your community (which is certainly not easy,
but a key to success). The previous vendors scaled with the
growing research labs and offered systems that came with full
source code to enable all kinds of experimentations. You can
see that Franz has taken some lessons from that, otherwise
they would have been long dead. They are doing a lot of
good/clever things to build a community around ACL
(education, PR, source code, source code sharing, ...). But
they seem to have some other limits (business model, target
markets, gui technology, ...).
For developers willing to dedicate some time I think it is best
to improve some of the better free implementations (like OpenMCL,
SBCL, ...) and get familiar with hacking/improving McCLIM
and CLIMACS (http://common-lisp.net/project/climacs/). It is quite
possible to create something useful based on these. But it
will take many person years...
"Takuon Soho" <···@somwhere.net> writes:
> "nikhilketkar" <············@gmail.com> wrote in message
> ·····························@o13g2000cwo.googlegroups.com...
> > What would be the best way to put together a workstation optimized for
> > running and developing in lisp?
> > What architecture to go ahead with? Or that dosent make a difference?
> > Would it make sense in investing in more RAM than CPU ?
> >
>
> I have read that the best development environments
> for Lisp were the Lisp machines of the early 1990's, now
> owned by but a few devotees and some museums.
I think a few people are still using some of these (purchased in the
past 5 years) "for real". Most likely the DEC Alpha version ("Open Genera").
But they are not being actively marketed or anything.
······@news.dtpq.com (Christopher C. Stacy) writes:
> But [the Symbolics systems] are not being actively marketed or anything.
That's an understatement.
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > But [the Symbolics systems] are not being actively marketed or anything.
>
> That's an understatement.
In what way? You can call them up and order one. People do.