I've had occasions where people have asked me to point them to a good
Lisp implementation to get started with the language. At some point, I
realized that it would be great if Lisp was distributed kind of like
the JDK, with lots of libraries and documentation all in one place.
That way, people new to the language wouldn't have to let the
practicalities of seeking out libraries, building software, get in the
way of learning the language. Basically, I forsee some sort of "Lisp
in a box," a simple tarball with the compiler and lots of libraries
included and pre-configured, maybe a pre-configured Emacs + SLIME
setup, along with lots of documentation and maybe some basic tutorial
material. Not to big in scope, just enough to make a nice
first-impression.
Yes, I am volunteering to put this together. My question is:
1) What do you think of the idea? Any suggestions?
2) What libraries should be included? Which compiler?
--- Rayiner Hashem
·······@mindspring.com (Rayiner Hashem) writes:
Emacs + SLIME makes a great IDE. I don't think SLIME is Debian
apt-getable yet, but it is easy enough to check out of CVS. The SLIME
folks have been doing a wonderful job.
Are you going to be OS agnostic? That makes things tricky.
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
I think the idea is pretty cool. I would strongly lean towards an
ASDF type of system. If you can assume some version of Emacs, then
perhaps some Elisp to grab SLIME and enable it in the .emacs file
would be a reasonable launching point. Although I just used CVS and
manually put the appropriate forms in my .emacs file.
SBCL has built in ASDF and ASDF-INSTALL support. I think that is a
good packaging system and I don't see why it shouldn't be used by
everyone. For Lisps other than SBCL, the challenge would be to get
ASDF-INSTALL setup. It may be fairly simple. Edi Weitz has a page on
it here:
http://www.weitz.de/asdf-install/
Since both CLtL2 and the CLHS are available for local installation, I
would get those as well.
Things are fairly simple on Unix systems. OS X maybe a bit trickier.
I've only ever run with the CVS version of Emacs built for Carbon on
my Mac. I don't know if the older version that Panther includes will
support SLIME. I run OpenMCL on my Mac and have not attempted to
setup and use ASDF-INSTALL with it.
Another potential problem with OS X is social. Xcode is a different
world from Emacs + SLIME.
I also have not attempted to get various optional packages for Emacs
(apart from SLIME) on my Mac. I'm talking about things you might use
apt-get for on Debian. Debian has really spoiled me as far as package
management in general goes. I expect that ASDF will ultimately do the
same thing for Lisp packages.
I haven't installed GNU GPG on my Mac either. ASDF-INSTALL depends on
that. Actually, I think a brave user can ignore GPG, but that takes
some serious faith.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> ·······@mindspring.com (Rayiner Hashem) writes:
>>Yes, I am volunteering to put this together. My question is:
>>
>>1) What do you think of the idea? Any suggestions?
>>2) What libraries should be included? Which compiler?
>
>
> I think the idea is pretty cool.
Me too. I second Edi's suggestion that you look at the cirCLe project to
see whether you want to coontribute to that rather than making your own.
SBCL seems to me a promising Lisp to use. I even saw somewhere some
allegedly genuine screenshots of an early version of a Windows port, and
I use it often on Mac OS X and Linux (though compilation of large
projects can be painfully slow).
ASDF would be good to include and set up. Likewise cl-ppcre, which is
mighty useful for text processing.
Take a look at the Common Music bundle for Mac OS X; it shows a rather
clever way to bundle a lisp with Emacs on Mac OS X. Basically, it uses
an application bundle (which is a special directory structure on Mac OS
X); inside the bundle is a self-contained file-system with a full Emacs
distribution in it and a starter script that launches the Emacs and
starts a copy of OpenMCL running in an Emacs inferior lisp buffer.
It should be similarly possible to create an Emacs bundle for OS X that,
when launched, starts a Lisp (say, SBCL or OpenMCL) in a SLIME session,
with variables set up to easily access the hyperspec, menus to help the
confused newbie, and so on.
I might even be persuaded to do it in my copious free time. Along with
the million other things I'll do when I get around to them.
> I've only ever run with the CVS version of Emacs built for Carbon on
> my Mac. I don't know if the older version that Panther includes will
> support SLIME. I run OpenMCL on my Mac and have not attempted to
> setup and use ASDF-INSTALL with it.
These all work with, in some cases, some fussing.
> Another potential problem with OS X is social. Xcode is a different
> world from Emacs + SLIME.
That's for sure.
On 22 Apr 2004 20:14:01 -0700, ·······@mindspring.com (Rayiner Hashem) wrote:
> I've had occasions where people have asked me to point them to a
> good Lisp implementation to get started with the language. At some
> point, I realized that it would be great if Lisp was distributed
> kind of like the JDK, with lots of libraries and documentation all
> in one place. That way, people new to the language wouldn't have to
> let the practicalities of seeking out libraries, building software,
> get in the way of learning the language. Basically, I forsee some
> sort of "Lisp in a box," a simple tarball with the compiler and lots
> of libraries included and pre-configured, maybe a pre-configured
> Emacs + SLIME setup, along with lots of documentation and maybe some
> basic tutorial material. Not to big in scope, just enough to make a
> nice first-impression.
>
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
You might want to consider helping cirCLe:
<http://web.metacircles.com/cirCLe%20CD>
Edi.
Rayiner Hashem wrote:
> I've had occasions where people have asked me to point them to a good
> Lisp implementation to get started with the language. At some point, I
> realized that it would be great if Lisp was distributed kind of like
> the JDK, with lots of libraries and documentation all in one place.
> That way, people new to the language wouldn't have to let the
> practicalities of seeking out libraries, building software, get in the
> way of learning the language. Basically, I forsee some sort of "Lisp
> in a box," a simple tarball with the compiler and lots of libraries
> included and pre-configured, maybe a pre-configured Emacs + SLIME
> setup, along with lots of documentation and maybe some basic tutorial
> material. Not to big in scope, just enough to make a nice
> first-impression.
>
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
>
> --- Rayiner Hashem
Here's something to look at:
http://www.common-lisp.net/project/lisp-res-kit/
David Sletten <·····@slytobias.com> writes:
> Here's something to look at:
> http://www.common-lisp.net/project/lisp-res-kit/
It says it is a "self-booting CD", and:
Just insert it into the CD-ROM of your PC, turn your computer on and
enjoy of power of Lisp.
So what does it *do* when you turn your computer on?
What OS ends up running?
It sounds like something I would never want to use on any machine.
-- jd
On 24 Apr 2004 16:10:46 +0100, Jeff Dalton <····@todday.inf.ed.ac.uk> wrote:
> It says it is a "self-booting CD", and:
>
> Just insert it into the CD-ROM of your PC, turn your computer on and
> enjoy of power of Lisp.
>
> So what does it *do* when you turn your computer on?
>
> What OS ends up running?
"The Lisp Resource Kit is a self booting CD based off of the latest
stable version of Knoppix (which is in turn based on Debian
GNU/Linux)."
Which part of this sentence is so hard to understand?
> It sounds like something I would never want to use on any machine.
Fine, so don't use it.
See Rayiner? You /will/ have to filter out some people, whether you
want it or not... :)
Edi.
Edi Weitz <···@agharta.de> writes:
> On 24 Apr 2004 16:10:46 +0100, Jeff Dalton <····@todday.inf.ed.ac.uk> wrote:
>
> > It says it is a "self-booting CD", and:
> >
> > Just insert it into the CD-ROM of your PC, turn your computer on and
> > enjoy of power of Lisp.
> >
> > So what does it *do* when you turn your computer on?
> >
> > What OS ends up running?
>
> "The Lisp Resource Kit is a self booting CD based off of the latest
> stable version of Knoppix (which is in turn based on Debian
> GNU/Linux)."
>
> Which part of this sentence is so hard to understand?
Seting aside the "so hard" rhetoric, "based off", "Knoppix", "based
on". I get an OS, specifics unknown.
But thanks for "explaining". :(
> > It sounds like something I would never want to use on any machine.
>
> Fine, so don't use it.
Fine, I won't.
I would want something I could use with my usual OS. I'm not
going to reboot the machine every time I want to run Lisp,
or even once to run it once.
It's too bad, because apart from the auto-booting, the contents
looked very good.
-- jd
Jeff Dalton wrote:
> Edi Weitz <···@agharta.de> writes:
>
>
>>On 24 Apr 2004 16:10:46 +0100, Jeff Dalton <····@todday.inf.ed.ac.uk> wrote:
>>
>>
>>>It says it is a "self-booting CD", and:
>>>
>>> Just insert it into the CD-ROM of your PC, turn your computer on and
>>> enjoy of power of Lisp.
>>>
>>>So what does it *do* when you turn your computer on?
>>>
>>>What OS ends up running?
>>
>> "The Lisp Resource Kit is a self booting CD based off of the latest
>> stable version of Knoppix (which is in turn based on Debian
>> GNU/Linux)."
>>
>>Which part of this sentence is so hard to understand?
>
>
> Seting aside the "so hard" rhetoric, "based off", "Knoppix", "based
> on". I get an OS, specifics unknown.
Oh, it's the "basing" that has you guessing? A Knoppix CD installs
Debian Linux. The lisp resource kit is a Knoppix CD with more better
Lisp stuff added.
>
> But thanks for "explaining". :(
I am afraid you have just been mugged by one of a new gang of hooligans
who like to get all macho with newbies and scream out things like RTFM
if newbies dare to ask the wrong question or ask it the wrong way.
Apparently the booming growth in Lisp newbies has emboldened them into
thinking we can stop all the newby-hugging and start filtering who we
let in, mostly by abusing people in public forums to chase off ones they
don't like.
It's a pretty cool band of hooligans though, so victims should consider
rolling onto their backs and exposing their necks as a sign of
submission to be accepted by the gang.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
> Oh, it's the "basing" that has you guessing? A Knoppix CD installs
> Debian Linux. The lisp resource kit is a Knoppix CD with more better
> Lisp stuff added.
>
ie. for people unfamiliar with knoppix - it is a bootable "live" functioning
KDE linux environment, and also a harddisk-installer for debian linux.
This "try before you buy" approach has proven quite successful in
introducing windows-using europeans to desktop/workstation linux, anyway.
Does the Lisp CD simply include the Debian CMUCL and emacs etc.
packages? :-)
David Golden wrote:
> Kenny Tilton wrote:
>
>
>
>>Oh, it's the "basing" that has you guessing? A Knoppix CD installs
>>Debian Linux. The lisp resource kit is a Knoppix CD with more better
>>Lisp stuff added.
>>
>
>
>
> ie. for people unfamiliar with knoppix - it is a bootable "live" functioning
> KDE linux environment, and also a harddisk-installer for debian linux.
> This "try before you buy" approach has proven quite successful in
> introducing windows-using europeans to desktop/workstation linux, anyway.
>
> Does the Lisp CD simply include the Debian CMUCL and emacs etc.
> packages? :-)
>
From: http://www.common-lisp.net/project/lisp-res-kit/
"The Lisp Resource Kit is a dedicated development/learning environment
on a self-booting CD. It is designed to be an easy to use single
resource for those who are interested in exploring Common Lisp,
regardless of their experience or domain of expertise.
"The kit contains works by:
* Basic Lisp Techniques by David Cooper
* On Lisp book by Paul Graham
* Successful Lisp by David Lamkins
"Software by:
* Allegro Common Lisp by Franz
* LispWorks by Xanalys
* CMU Common Lisp "
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
David Golden <············@oceanfree.net> writes:
> ie. for people unfamiliar with knoppix - it is a bootable "live" functioning
> KDE linux environment,
Can one escape KDE? I happen to find KDE almost totally unusable.
> and also a harddisk-installer for debian linux.
> This "try before you buy" approach has proven quite successful in
> introducing windows-using europeans to desktop/workstation linux, anyway.
Yes, there have even been bootable Linux CDs given away with
magazines.
-- jd
Jeff Dalton wrote:
> Can one escape KDE? I happen to find KDE almost totally unusable.
http://www.gnoppix.org/ - Same idea, GNOME instead of KDE.
This thread had contained a lot of brainstorming about various ways of
packaging Lisp. Some have been about making Lisp CDs, based on Knoppix
(which presumably wouldn't, by default, install anything on one's hard
drive) and others have been about making downloadable tarballs or
installers. We now appear to have implementations of both concepts.
--
Cameron MacKinnon
Toronto, Canada
Jeff Dalton wrote:
> Can one escape KDE? I happen to find KDE almost totally unusable.
Well, there's "gnoppix", which is basically knoppix, only with gnome.
Be careful you're not basing your KDE opinions on Redhat's horribly
mutilated and broken in-house KDE fork, by the way. Mandrake and Debian
have sane KDE configurations, Redhat apparently deliberately cripples
theirs - hence the existence of e.g. http://kde-redhat.sourceforge.net/
Kenny Tilton <·······@nyc.rr.com> writes:
> >>>What OS ends up running?
> >> "The Lisp Resource Kit is a self booting CD based off of the latest
> >> stable version of Knoppix (which is in turn based on Debian
> >> GNU/Linux)."
> >>Which part of this sentence is so hard to understand?
> > Seting aside the "so hard" rhetoric, "based off", "Knoppix", "based
> > on". I get an OS, specifics unknown.
> Oh, it's the "basing" that has you guessing?
The whole business has me guessing. It looked like it was
something twice removed from Linux, and why boot from a CD
to run Lisp?
> A Knoppix CD installs
> Debian Linux. The lisp resource kit is a Knoppix CD with more better
> Lisp stuff added.
It installs Linux? As in afterwards there's a Linux on my machine?
Or am I just running Linux temporarily with no permanent side-
effects on my machine?
-- jd
> It installs Linux? As in afterwards there's a Linux on my machine?
> Or am I just running Linux temporarily with no permanent side-
> effects on my machine?
Knoppix can install Linux if you want it to, but by default, it just
runs from the CD, plus a little RAM drive. It can also use USB memory
sticks to store your configuration and personal files.
·······@mindspring.com (Rayiner Hashem) writes:
> > It installs Linux? As in afterwards there's a Linux on my machine?
> > Or am I just running Linux temporarily with no permanent side-
> > effects on my machine?
> Knoppix can install Linux if you want it to, but by default, it just
> runs from the CD, plus a little RAM drive. It can also use USB memory
> sticks to store your configuration and personal files.
Thanks to everyone for the helpful replies re Knoppix etc.
Using a bootable CD to run Lisp seemed like a very strange
approach to me at first, but if I "think Windows", it starts
to make a lot of sense as a way to let programmers try
something.
Knoppix sounded potentially quite useful from the first
(modulo KDE :)), but, especially with something a couple
of steps removed, that ran Lisp etc, it was not clear
enough what it did.
I think it would be helpful if the top lisp-res-kit web page
made it clear (or clearer, if you prefer) what the disk will
do, that it won't mess up the machine, etc, as people have
explained in this thread.
-- jd
From: Bulent Murtezaoglu
Subject: Re: lisp-res-kit question, was Re: Lisp in a Box
Date:
Message-ID: <87y8ok12a8.fsf@cubx.internal>
>>>>> "JD" == Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
[...]
JD> Using a bootable CD to run Lisp seemed like a very strange
JD> approach to me at first, but if I "think Windows", it starts
JD> to make a lot of sense as a way to let programmers try
JD> something. [...]
Also you can use something like vmware (virtual PC in PC under x86
lin/win/ bsd?) with those bootable CD's if you dislike rebooting your
box and don't have a spare one handy. That's what I do, and works
very well. It might even be possible, with slime, to have your emacs
in linux and connect to a windows list running in a vmware window
through the virtual network.
cheers,
BM
In article <···············@todday.inf.ed.ac.uk>,
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> ...
> Knoppix sounded potentially quite useful from the first
> (modulo KDE :))
you are not forced to use KDE. at boot time you have the option to
specify the desktop you want to use. vailable are xfce, twm, ascii
terminal (no GUI) and i think a few others, unfortunately (for me),
not gnome.
knoppix has also spawned a few similar distributions, one of them
gnoppix (i think the url is www.gnoppix.org) which uses gnome instead
of KDE. they started later, so are not as streamlined as knoppix yet,
but should be as easy to build a lisp-res-kit on
> ...
hs
--
Patriotism is the last refuge of the scoundrel
Samuel Johnson
Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> It installs Linux? As in afterwards there's a Linux on my machine?
> Or am I just running Linux temporarily with no permanent side-
> effects on my machine?
If it works like Knopix, then there are no side effects. Everything
stays on the CD. Although there may be an install program if you want
to put Linux on your machine.
The basic idea is to allow someone to play with a system without
having to alter their machine at all.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
In article <···············@todday.inf.ed.ac.uk>,
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> >>>What OS ends up running?
>
>> >> "The Lisp Resource Kit is a self booting CD based off of the latest
>> >> stable version of Knoppix (which is in turn based on Debian
>> >> GNU/Linux)."
>
>> >>Which part of this sentence is so hard to understand?
>> > Seting aside the "so hard" rhetoric, "based off", "Knoppix", "based
>> > on". I get an OS, specifics unknown.
>
>> Oh, it's the "basing" that has you guessing?
>
> The whole business has me guessing. It looked like it was
> something twice removed from Linux, and why boot from a CD
> to run Lisp?
>
>> A Knoppix CD installs
>> Debian Linux. The lisp resource kit is a Knoppix CD with more better
>> Lisp stuff added.
>
> It installs Linux? As in afterwards there's a Linux on my machine?
> Or am I just running Linux temporarily with no permanent side-
> effects on my machine?
if you run it off the CD, it will have no permanent side effects,
unless you mount a disk partition with write permission (read only is
default) and write something to it. there is a piece of documentation
that tells you how to install the system on your disk, but you don't
have to run it.
hs
--
Patriotism is the last refuge of the scoundrel
Samuel Johnson
Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw
Jeff Dalton wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>A Knoppix CD installs
>>Debian Linux. The lisp resource kit is a Knoppix CD with more better
>>Lisp stuff added.
>
>
> It installs Linux? As in afterwards there's a Linux on my machine?
> Or am I just running Linux temporarily with no permanent side-
> effects on my machine?
The latter: no side effects. I misspoke.
kenny
>
> -- jd
>
>
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Kenny Tilton
Subject: Re: lisp-res-kit question, was Re: Lisp in a Box
Date:
Message-ID: <408AAB6D.3000706@nyc.rr.com>
Jeff Dalton wrote:
> David Sletten <·····@slytobias.com> writes:
>
>
>>Here's something to look at:
>>http://www.common-lisp.net/project/lisp-res-kit/
>
>
> It says it is a "self-booting CD", and:
>
> Just insert it into the CD-ROM of your PC, turn your computer on and
> enjoy of power of Lisp.
>
> So what does it *do* when you turn your computer on?
It is Linux on a CD, and bootable from the CD. I think the idea of that
is so amazing you just cannot understand the words. <g> It was developed
by someone frustrated by the Linux install process.
You get a nice GUI interface after it boots, I forget which. On the
menus you will find all sorts of Lisp goodies.
>
> What OS ends up running?
>
Linux
> It sounds like something I would never want to use on any machine.
IIANM, the common-lisp.net version should have a .sig alongside the CD
image file. If you want to verify its integrity you can use the sig to
do so. Then the only question is whether you trust Heow. He's a good
guy, I think you'll be OK.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Jeff Dalton wrote:
>
> > David Sletten <·····@slytobias.com> writes:
> >
> >>Here's something to look at:
> >>http://www.common-lisp.net/project/lisp-res-kit/
> > It says it is a "self-booting CD", and:
> > Just insert it into the CD-ROM of your PC, turn your computer on
> > and
> > enjoy of power of Lisp.
> > So what does it *do* when you turn your computer on?
>
> It is Linux on a CD, and bootable from the CD. I think the idea of
> that is so amazing you just cannot understand the words. <g> It was
> developed by someone frustrated by the Linux install process.
What's with the sarcasm in this place?
Anyway, I've used Linux on a CD, several different ones, an OS on a
floppy, and so on.
But there are many different ways something like this could
work, and different intentions it could have.
For instance, it might be designed to ensure that I couldn't
extract the software and use it without running the OS on the
CD. It might leave junk on the disks. I don't know.
It seems such an odd way to distribute Lisp that it becomes
unclear what it's about.
> You get a nice GUI interface after it boots, I forget which. On the
> menus you will find all sorts of Lisp goodies.
And then ...? Can I extract the software etc and use it with
my ordinary OS? Or is it only "for evaluation"?
> > What OS ends up running?
>
> Linux
Some standard version of it? "Based on" is pretty open-ended.
> > It sounds like something I would never want to use on any machine.
>
> IIANM, the common-lisp.net version should have a .sig alongside the CD
> image file. If you want to verify its integrity you can use the sig to
> do so. Then the only question is whether you trust Heow. He's a good
> guy, I think you'll be OK.
Thanks.
-- jd
Jeff Dalton wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Jeff Dalton wrote:
>>
>>
>>>David Sletten <·····@slytobias.com> writes:
>>>
>>>
>>>>Here's something to look at:
>>>>http://www.common-lisp.net/project/lisp-res-kit/
>>>
>>>It says it is a "self-booting CD", and:
>>> Just insert it into the CD-ROM of your PC, turn your computer on
>>>and
>>> enjoy of power of Lisp.
>>>So what does it *do* when you turn your computer on?
>>
>>It is Linux on a CD, and bootable from the CD. I think the idea of
>>that is so amazing you just cannot understand the words. <g> It was
>>developed by someone frustrated by the Linux install process.
>
>
> What's with the sarcasm in this place?
No sarcasm, I just guessed wrong. I did not know:
>
> Anyway, I've used Linux on a CD, several different ones, an OS on a
> floppy, and so on.
>
> But there are many different ways something like this could
> work, and different intentions it could have.
>
> For instance, it might be designed to ensure that I couldn't
> extract the software and use it without running the OS on the
> CD. It might leave junk on the disks. I don't know.
Actually, that is how this dummy (me) did a hardware install of Linux,
following some instructions out there on the Web on how to install to HD
from a Knoppix CD (with a hat-tip to Mr Sulzberger for meta-instructing
me to use Knoppix this way).
kenny
On 24 Apr 2004 19:48:55 +0100, Jeff Dalton <····@todday.inf.ed.ac.uk>
wrote:
>Kenny Tilton <·······@nyc.rr.com> writes:
>
>> It is Linux on a CD, and bootable from the CD. I think the idea of
>> that is so amazing you just cannot understand the words. <g> It was
>> developed by someone frustrated by the Linux install process.
>
>> You get a nice GUI interface after it boots, I forget which. On the
>> menus you will find all sorts of Lisp goodies.
>
>And then ...? Can I extract the software etc and use it with
>my ordinary OS? Or is it only "for evaluation"?
You can transplant the software easily if your "ordinary" OS is Debian
Linux. If not, you may have to fiddle a bit with configuration files
and shared libs and the like.
I haven't seen this Lisp CD but my guess is that the ACL and Lispworks
offerings will be the free trial editions.
George
=============================================
Send real email to GNEUNER2 at COMCAST o NET
Kenny Tilton <·······@nyc.rr.com> writes:
> You get a nice GUI interface after it boots, I forget which. On the
> menus you will find all sorts of Lisp goodies.
Do you mean it's not Cello? :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
I have thought along the same lines mysef. I'm writing a book on lisp
games and
want a book distribution CD which encompasses a complete game developement
environment
with graphics and sound. Perhaps we should join our efforts?
John
P� 22 Apr 2004 20:14:01 -0700, skrev Rayiner Hashem
<·······@mindspring.com>:
> I've had occasions where people have asked me to point them to a good
> Lisp implementation to get started with the language. At some point, I
> realized that it would be great if Lisp was distributed kind of like
> the JDK, with lots of libraries and documentation all in one place.
> That way, people new to the language wouldn't have to let the
> practicalities of seeking out libraries, building software, get in the
> way of learning the language. Basically, I forsee some sort of "Lisp
> in a box," a simple tarball with the compiler and lots of libraries
> included and pre-configured, maybe a pre-configured Emacs + SLIME
> setup, along with lots of documentation and maybe some basic tutorial
> material. Not to big in scope, just enough to make a nice
> first-impression.
>
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
>
> --- Rayiner Hashem
--
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
John Thingstad <··············@chello.no> writes:
> I have thought along the same lines mysef. I'm writing a book on
> lisp games and want a book distribution CD which encompasses a
> complete game developement environment with graphics and
> sound. Perhaps we should join our efforts?
[...snip...]
Perhaps you can save yourself some time if you do it in the framework
of the already existing efforts. I am thinking of
http://www.cliki.net/cirCLe
and
http://www.common-lisp.net/project/lisp-res-kit/
The latter one is based on knoppix, which has a good reputation wrt
detection of audio/graphics hardware.
"Rayiner Hashem" <·······@mindspring.com> wrote in message
·································@posting.google.com...
> I've had occasions where people have asked me to point them to a good
> Lisp implementation to get started with the language. At some point, I
> realized that it would be great if Lisp was distributed kind of like
> the JDK, with lots of libraries and documentation all in one place.
> That way, people new to the language wouldn't have to let the
> practicalities of seeking out libraries, building software, get in the
> way of learning the language. Basically, I forsee some sort of "Lisp
> in a box," a simple tarball with the compiler and lots of libraries
> included and pre-configured, maybe a pre-configured Emacs + SLIME
> setup, along with lots of documentation and maybe some basic tutorial
> material. Not to big in scope, just enough to make a nice
> first-impression.
>
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
Simple. No, really.
You need to make two versions up front, one for Windows, one for Linux.
Bundle binaries of Gnu Emacs, CLISP, and some library package that suits
you.
Dump all of it into a "lispInABox" directory, and give them instructions to
start the local version of emacs which is prefconfigured to use the "LIAB"
CLISP.
While there are minor file system issues, and obviously platform issues in
terms of what CPU you're running and such (must have the correct binaries),
this is about as portable of a baseline set as you can get, it avoids the
entire "this runs on that, but not this" scenario, because Emacs and CLISP
pretty much run on everything.
Yes, it's a heavyweight install. Emacs is a monster. But, obviously, the 10K
of instructions isn't working, so we need 30MB of binaries instead.
BUT, it shouldn't be any harder to set up than:
$ cd ~
$ gtar xvfz liab-1.0.tar.gz
liab-1.0/emacs
liab-1.0/clisp
liab-1.0/...
$ cd liab-1.0
$ ./liabemacs
change tar to Zip for windows, and add a BAT file.
If they're an emacs user, it doesn't honk up their current version. If
they're not, it doesn't matter anyway.
"What about CMUCL, SBCL, GCL, ACL, LW, Corman, ECL, etc. etc. etc. etc.?"
What about them?
LW Personal is the closest "Lisp in a Box", it works on Windows and Linux,
and is brain dead to install. But doesn't come with any of the libraries.
"But, CLISP doesn't do X, Y, Z or even A, B, or C, and what's with that
candle thing?"
Simply put, bundling Emacs and CLISP is an O(1) problem, start straying, and
it becomes an O(platforms^#CL Implemenations) problem.
So you just have to ask yourself one question. "What's your goal?"
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> wrote in message news:<··············@ID-197644.news.uni-berlin.de>...
> "Rayiner Hashem" <·······@mindspring.com> wrote in message
> ·································@posting.google.com...
> > I've had occasions where people have asked me to point them to a good
> > Lisp implementation to get started with the language. At some point, I
> > realized that it would be great if Lisp was distributed kind of like
> > the JDK, with lots of libraries and documentation all in one place.
> > That way, people new to the language wouldn't have to let the
> > practicalities of seeking out libraries, building software, get in the
> > way of learning the language. Basically, I forsee some sort of "Lisp
> > in a box," a simple tarball with the compiler and lots of libraries
> > included and pre-configured, maybe a pre-configured Emacs + SLIME
> > setup, along with lots of documentation and maybe some basic tutorial
> > material. Not to big in scope, just enough to make a nice
> > first-impression.
> >
> > Yes, I am volunteering to put this together. My question is:
> >
> > 1) What do you think of the idea? Any suggestions?
> > 2) What libraries should be included? Which compiler?
>
> Simple. No, really.
That's precisely what I'm thinking. Just a big tarball that users can
unpack and give it a go. Its not an elegant install, and its not
production-quality, but its quick and painless, and gets them right to
learning Lisp. cirCLe actually looks pretty close to "just about
right," though the project itself seems a lot more ambitious than what
I'm going for. I'll take a closer look at cirCLe and see if I can do a
"quick and dirty" distribution of it (no installation of packages, for
example).
Well, thanks for all the feedback :)
"Rayiner Hashem" <·······@mindspring.com> wrote in message
·································@posting.google.com...
> "Will Hartung" <·····@msoft.com> wrote in message
news:<··············@ID-197644.news.uni-berlin.de>...
> That's precisely what I'm thinking. Just a big tarball that users can
> unpack and give it a go.
The value is ideally two fold.
One, is you have this big binary unzip and go blob.
Two, you have a solid recipe for getting it to go.
I think that to work best, the thing to do would be when you start your
LIAB, Emacs would show up with a Lisp buffer filled with the most basic
Emacs navigation instructions (arrows keys, pgup/pgdwn, what C- and M- mean,
and, maybe C-s/C-r for search, and a pointer to C-h t, of course.).
But the key thing is that the buffer is really a bunch of Lisp comments and
Lisp code, and in itself consists of a tutorial on how to use the Emacs/Lisp
interface.
When the screen shows up, a user need do nothing but follow the directions.
This is most important to show the advantages of the IDE, and integration
features beyond simply evaluating forms.
This basically gets Emacs "out of the way".
The other benefit is that someone like Peter can point to LIAB and use it to
show and run all of his samples. He can rely on the examples in the text
working without a bunch of disclaimers. He can rely on the fact that the
extra libraries are set up properly and work, and even discuss how that all
works. That way, with LIAB, pretty much any modern mainstream computer, and
his book, you have a self contained, easily installed Lab for folks to
explore Lisp and work with.
As folks grok CL etc, they can move on to other implementations, etc, but
the LIAB isn't necessarily that confining as is. Its biggest sin being that
it's may not be the same Emacs that someone is normally using. Well, Emacs
savvy folks can transition themselves if they're motivated by reading the
recipe.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> I think that to work best, the thing to do would be when you start your
> LIAB, Emacs would show up with a Lisp buffer filled with the most basic
> Emacs navigation instructions (arrows keys, pgup/pgdwn, what C- and M- mean,
> and, maybe C-s/C-r for search, and a pointer to C-h t, of course.).
Actually, is there some good documentation for getting a person started
with Emacs? I have always been a vi person, in part because of its
ubiquity and continuing because I love that I rarely have to move my
hands far from the 'home row'. The Control key is just too far out of
the way for me. So my personal 'IDE' of choice is 'screen' with one
typically 4 pages open: one where I run the program, one where I type
'make' to recompile it, one where I have a .c file open, and one where I
have a corresponding .h file open. I may add several .c windows
depending on the extent of my current round of changes.
But, as I get further along with Lisp, I feel I should change paradigms
from the old "write, compile, run, debug, compile, test, debug, compile,
package" way of doing things to the Lisp way, and it appears that a good
IDE built upon Emacs is the preferred way of doing this. This is a
paradigm shift, which is the hardest kind of change to make as it
involves a change in how a person thinks, so any pointers would be much
appreciated. I don't mind abrupt changes, but they'd better make sense
and be easy to set up so the change itself can be abrupt without severe
time investment in the initial setup.
Thanks to all comers.
Ari
Ari Johnson <·····@hotmail.com> writes:
> Actually, is there some good documentation for getting a person
> started with Emacs?
With a propertly installed Emacs, do C-h t.
After that, there is also online Emacs Manual and Emacs Lisp info
documentation that should be findable from C-h i.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
>
>>Actually, is there some good documentation for getting a person
>>started with Emacs?
>
>
> With a propertly installed Emacs, do C-h t.
As I understand that Emacs is a large system, define 'properly
installed', if you would. Thanks. :)
Ari Johnson wrote:
> David Steuber wrote:
>> Ari Johnson <·····@hotmail.com> writes:
>>> Actually, is there some good documentation for getting a person
>>> started with Emacs?
>> With a propertly installed Emacs, do C-h t.
> As I understand that Emacs is a large system, define 'properly
> installed', if you would. Thanks. :)
If C-h t starts the tutorial, then it is 'properly installed'.
--
Jens Axel S�gaard
Ari Johnson <·····@hotmail.com> writes:
> Actually, is there some good documentation for getting a person
> started with Emacs? I have always been a vi person, in part because
> of its ubiquity and continuing because I love that I rarely have to
> move my hands far from the 'home row'. The Control key is just too
> far out of the way for me.
Remap your keyboard:
Ctrl ==> Caps Lock
See `man xmodmap'.
for example (on my computer):
in `/usr/X11R6/lib/X11/xdm/Xsession'
line:
`sysmodmap=/usr/X11R6/lib/X11/xinit/.Xmodmap'
and in .Xmodmap
--------------------------------------------------
clear Control
clear Lock
keycode 37 = Hyper_L
keycode 66 = Control_L
keycode 115 = Super_L
keycode 116 = Super_R
keycode 117 = Caps_Lock
add Control = Control_L
add Control = Control_R
add Lock = Caps_Lock
add mod3 = Super_L
add mod3 = Super_R
add mod4 = Hyper_L
--------------------------------------------------
This is very convinient with vim too - Ctrl (remapped to Caps Lock) +
`[' key ==> ESC.
regards, szymon.
Actually, Meta (Alt) is the one that gives me the most trouble. Most of
the C- commands are in the region that's easy to hit with your left
index finger while pressing Ctrl with your left pinky (on a QWERTY
board), whereas some of the Meta combinations are easier to hit with
your thumb on Alt while others are easier to hit with your pinky on it.
szymon wrote:
> Remap your keyboard:
>
> Ctrl ==> Caps Lock
Keyboard remapping isn't a very good option, because I want to use the
same editor in Windows as I do in Unix (especially if that happens to be
Emacs - no sense learning a new operating system just to end up
dual-booting between what amounts to Emacs and Notepad).
> <snip>
> This is very convinient with vim too - Ctrl (remapped to Caps Lock) +
> `[' key ==> ESC.
I don't find Esc to be out of the way in vi, because I don't need it
that often and it's not the leading part of any command sequences (or at
least any that I use), whereas in Emacs using Esc for Meta doesn't do it
for me because that generates too much movement, as in more than using
Alt does.
Maybe I'll just have to learn to use Alt and start learning commands.
Do there exist any good PDF cheat sheets a la the many that exist for
vi? I'm not big on hard copy (I have never owned a printer), but I
could justify having a sheet around to learn Emacs.
Thanks for the responses so far - I am definitely learning some of the
possibilities, especially regarding gnuclient. I just wish that C-x C-c
didn't kill Emacs when issued from gnuclient...I want Emacs to stay up
all the time. I also wish Emacs were a preemptive multitasking
operating system, so network troubles with gnus, for example, wouldn't
lock it up. :)
Ari
On Tue, Apr 27, 2004 at 06:19:40PM -0700, Ari Johnson wrote:
> Maybe I'll just have to learn to use Alt and start learning commands.
> Do there exist any good PDF cheat sheets a la the many that exist for
> vi? I'm not big on hard copy (I have never owned a printer), but I
> could justify having a sheet around to learn Emacs.
I have never seen a cheatsheet for vi (though I don't doubt their
existence). I have seen approximately several thousand for Emacs,
though, check Google.
--
; 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."
Matthew Danish <·······@andrew.cmu.edu> writes:
> I have never seen a cheatsheet for vi (though I don't doubt their
> existence). I have seen approximately several thousand for Emacs,
> though, check Google.
Here's the most useful cheatsheet for the 6 editor I ever found:
----------------------------------------
Editors 101 - The vi Menace
In another article I discussed moving the cursor forward in vi, a very
advanced topic that is *not* required to pass this course. To pass
``Editors 101'' you only need to be able to answer the following
question:
Some program started vi for me. I typed a few characters before I
figured out what happened. Now everything is fubar. What do I
do?
The answer is:
* Check the settings of your EDITOR and VISUAL environment
variables.
* Delete the program from your hard disk (required by ISO 9001).
* Find and shoot the programmer (optional).
* Type ``ESC : q ! RET''.
The last sequence is the command for leaving vi. That is all you will
need to know about vi, ever. You might find the command somewhat
unintuitive, but actually it is not. All vi commands have nice
mnemonics. The mnemonic for leaving vi is:
<ESC>ape this
<COLON> thing, // The colon-thing is a nickname for vi.
<Q>uit and do
<NOT> // C slang for `!'. Here used in the meaning
// `never'.
<RET>urn.
That was all for this lecture. Today's exercises will consist of
entering and leaving vi mode in emacs. Do not try this with the real
thing. A video demonstration will be available later for interested
students.
May you never need the knowledge you have just gained.
PS: If you are forced by company policy to use vi for editing, the
ESC : ! emacs % command can make life bearable while writing
applications for a new job.
Per Abrahamsen <·······@dina.kvl.dk>
--
Fred Gilham ······@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
Ari Johnson <·····@hotmail.com> writes:
> Thanks for the responses so far - I am definitely learning some of
> the possibilities, especially regarding gnuclient. I just wish that
> C-x C-c didn't kill Emacs when issued from gnuclient...I want Emacs
You can rebind the quit function (or whatever it is) to a different
key sequence. For example, C-x C-c C-c. I don't know the
incantation, but I'm sure it's in the Emacs Manual somewhere.
> to stay up all the time. I also wish Emacs were a preemptive
> multitasking operating system, so network troubles with gnus, for
> example, wouldn't lock it up. :)
Me too!
I think this could be done if Emacs was rewritten in Common Lisp.
Many implementations are threaded now. Or should I just say some?
I don't think it will ever happen though (I know about Hemlock).
Emacs has this little problem with being "good enough". Sure, it is
still getting tweaks and stuff. But if you look at all that ELisp
code you probably would not want to rewrite it all.
Perhaps if there was an ELisp compatibility mode written in Common
Lisp? Then you just have to decide if you want to go the GNU Emacs
way or Lucid/XEmacs way. There's another religious war right there.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> You can rebind the quit function (or whatever it is) to a different
> key sequence. For example, C-x C-c C-c. I don't know the
> incantation, but I'm sure it's in the Emacs Manual somewhere.
Or maybe I could redefine the function that quits Emacs to do
nothing...is that possible?
> I don't think it will ever happen though (I know about Hemlock).
> Emacs has this little problem with being "good enough". Sure, it is
> still getting tweaks and stuff. But if you look at all that ELisp
> code you probably would not want to rewrite it all.
"Good enough" - content is the most dangerous place to be, in anything.
If you write a compatible but preemptive-multitasking Emacs, won't the
world of ELisp "just work"?
> Perhaps if there was an ELisp compatibility mode written in Common
> Lisp? Then you just have to decide if you want to go the GNU Emacs
> way or Lucid/XEmacs way. There's another religious war right there.
Without invoking the gods of either side in said religious war, can you
tell me the differences in these two approaches? I'm *that* new to
actually caring about Emacs, although I've known about and hated it for
a decade (religious wars, and all). :)
Ari Johnson <·····@hotmail.com> writes:
> David Steuber wrote:
> > You can rebind the quit function (or whatever it is) to a different
> > key sequence. For example, C-x C-c C-c. I don't know the
> > incantation, but I'm sure it's in the Emacs Manual somewhere.
>
> Or maybe I could redefine the function that quits Emacs to do
> nothing...is that possible?
I doubt that's what you want to do. Probably, you want to rebind C-x
C-c to something harmless, like:
(defun dont-kill-emacs ()
(interactive)
(message "Ha!"))
(global-set-key (kbd "C-x C-c") 'dont-kill-emacs)
Although maybe you do mean:
(defvar let-emacs-die nil)
(defadvice kill-emacs (around dont-quit activate)
(when let-emacs-die ad-do-it))
> > I don't think it will ever happen though (I know about Hemlock).
> > Emacs has this little problem with being "good enough". Sure, it is
> > still getting tweaks and stuff. But if you look at all that ELisp
> > code you probably would not want to rewrite it all.
>
> "Good enough" - content is the most dangerous place to be, in anything.
> If you write a compatible but preemptive-multitasking Emacs, won't the
> world of ELisp "just work"?
Not really. Lisp makes the transition easier than most languages, but
global state is global state. E-lisp is very tied to the internal
details of the implementation(s), and they're not very friendly code.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Ari Johnson <·····@hotmail.com> writes:
> David Steuber wrote:
> > You can rebind the quit function (or whatever it is) to a different
> > key sequence. For example, C-x C-c C-c. I don't know the
> > incantation, but I'm sure it's in the Emacs Manual somewhere.
>
> Or maybe I could redefine the function that quits Emacs to do
> nothing...is that possible?
I'm sure it is. And when you do so, then you will be screaming, "how
do I get out of this?"
> > I don't think it will ever happen though (I know about Hemlock).
> > Emacs has this little problem with being "good enough". Sure, it is
> > still getting tweaks and stuff. But if you look at all that ELisp
> > code you probably would not want to rewrite it all.
>
> "Good enough" - content is the most dangerous place to be, in
> anything. If you write a compatible but preemptive-multitasking Emacs,
> won't the world of ELisp "just work"?
I don't know. I'm wondering about how it works in Common Lisp,
specifically SBCL with sb-thread. A line from the SBCL manual reads
like this:
"Dynamic bindings to symbols are per-thread. Signal handlers are
per-thread."
Although I have not seen how Lisp does signal handling, it is nice to
know that the handler will be called in the same thread that it was
raised. That at least means that you can pretend the thread is its
own little world. I'm not quite sure about the dynamic bindings. My
interpretation is that
(defvar *foo* "bar")
means that every thread has *foo* with the initial value of "bar". If
a thread does
(setf *foo* "baz")
then /that/ thread and /only/ that thread has *foo* bound to "baz".
If this is the case, then that is great. I have a sort of thread
local storage thing going on for free.
That then leads me to wonder how to create a shareable object such as
a hash table that has serialized access from all the threads that need
to touch it in some way.
I will make a seperate posting on that subject.
> > Perhaps if there was an ELisp compatibility mode written in Common
> > Lisp? Then you just have to decide if you want to go the GNU Emacs
> > way or Lucid/XEmacs way. There's another religious war right there.
>
> Without invoking the gods of either side in said religious war, can
> you tell me the differences in these two approaches? I'm *that* new
> to actually caring about Emacs, although I've known about and hated it
> for a decade (religious wars, and all). :)
I don't know all the details. XEmacs forked off of GNU Emacs a while
back. Since the fork, irreconcilable design differences have shown
up. A non-trivial ELisp package such as GNUS or SLIME has to
conditionally see which it is running in to do certain things.
And as with any editor religious war, some people prefer one Emacs
over the other.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber <·····@david-steuber.com> writes:
> Ari Johnson <·····@hotmail.com> writes:
>> Or maybe I could redefine the function that quits Emacs to do
>> nothing...is that possible?
>
> I'm sure it is. And when you do so, then you will be screaming, "how
> do I get out of this?"
Of course not. Why would anyone WANT to get out of emacs?!
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
"Ari Johnson" <·····@hotmail.com> wrote in message
························@fed1read03...
> David Steuber wrote:
> > You can rebind the quit function (or whatever it is) to a different
> > key sequence. For example, C-x C-c C-c. I don't know the
> > incantation, but I'm sure it's in the Emacs Manual somewhere.
>
> Or maybe I could redefine the function that quits Emacs to do
> nothing...is that possible?
(global-unset-key [(control x) (control c)])
voila...
I use that little X thing in the corner with my mouse.
Emacs is the third application that starts on my PC, after Mail and Winamp.
My PC typically lasts up to 2 months without rebooting, and emacs is
basically never quit. By the time I need to kill my emacs, I've got over a
hundred buffers there. As of this second, emacs is consuming ~9MB of memory.
Hell, AIM takes 6MB.
I only use it for editing and compiling though, I don't use GNUs or mail.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> By the time I need to kill my emacs, I've got over a hundred buffers
> there. As of this second, emacs is consuming ~9MB of memory.
That's surprising to hear. Do you use emacs within Cygwin? My XEmacs
running with Cygwin typically climbs up to around 70MB after a few
days use. That's with around 30 (non-hidden) buffers open, with lots
of Gnus use in the same instance. Maybe one of my packages is causing
XEmacs to leak memory.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> wrote in message
····················@L75001820.us.ray.com...
> "Will Hartung" <·····@msoft.com> writes:
>
> > By the time I need to kill my emacs, I've got over a hundred buffers
> > there. As of this second, emacs is consuming ~9MB of memory.
>
> That's surprising to hear. Do you use emacs within Cygwin? My XEmacs
> running with Cygwin typically climbs up to around 70MB after a few
> days use. That's with around 30 (non-hidden) buffers open, with lots
> of Gnus use in the same instance. Maybe one of my packages is causing
> XEmacs to leak memory.
No, just generic GNU Emacs for Windows.
"GNU Emacs 20.4.1 (i386-*-nt5.0.2195) of Thu Jul 15 1999 on gridlock"
Pushing 5 years old. (I'm just an old sod. My machine is as old as the
Emacs, but I for assorted reasons don't bother to upgrade to the new 3GHz PC
siting on my floor next to my desk...someday perhaps -- I hate computers
[installing, configuring, etc. Waste of bloody time])
I also run Cygwin as well, but I don't use their Emacs, and simply "deal
with" the file name differences. No big deal.
Like I mentioned, I only edit Java code (using very old JDE code, of which I
use no features -- just never got it working right for me). Beyond M-x
compile, I don't run any external shells. I have a very fluid working style
bouncing between Emacs and Cygwin shells to do my work.
All of my keys are bound wrong for windows, made no effort at all to keep a
consistent interface between Emacs and Windows. I mean, you know, this is
Emacs. Emacs has major modes based on file extension, I have Major Modes
when I enter Emacs. Kind of magic how that works. Sometimes confuse C-s and
C-f, but overall it's worked pretty well. Baby Duck Emacs and all.
I wish there was a way to "snapshot" all of the gazillion variables in this
version so that I can move all of the the settings to a new version (notably
the version installed at home). The different builds all seem to have
different defaults. *sigh* (Though I wouldn't bother installing the JDE at
home, I mostly just want font-lock and indention, and that seems to come by
default with Emacs Java mode, though I need to enable font-lock by default
at home.)
Regards,
Will Hartung
(·····@msoft.com)
* Ari Johnson <·····@hotmail.com>:
> > Remap your keyboard:
> >
> > Ctrl ==> Caps Lock
>
> Keyboard remapping isn't a very good option, because I want to use the
> same editor in Windows as I do in Unix (especially if that happens to be
> Emacs - no sense learning a new operating system just to end up
> dual-booting between what amounts to Emacs and Notepad).
I'm fairly sure I've seen a utility that does the same re-mapping of Caps
Lock to Control on Windows. I might be miss-remembering but I've got a vague
recollection that it's actually part of some freely-downloadable "power
toys" type affair that's available on the Microsoft web site.
> Maybe I'll just have to learn to use Alt and start learning commands. Do
> there exist any good PDF cheat sheets a la the many that exist for vi? I'm
> not big on hard copy (I have never owned a printer), but I could justify
> having a sheet around to learn Emacs.
,----[ C-h k C-h t ]
| C-h t runs the command help-with-tutorial
| which is an interactive compiled Lisp function in `help'.
| (help-with-tutorial &optional ARG)
|
| Select the Emacs learn-by-doing tutorial.
| If there is a tutorial version written in the language
| of the selected language environment, that version is used.
| If there's no tutorial in that language, `TUTORIAL' is selected.
| With arg, you are asked to choose which language.
`----
> Thanks for the responses so far - I am definitely learning some of the
> possibilities, especially regarding gnuclient. I just wish that C-x C-c
> didn't kill Emacs when issued from gnuclient...I want Emacs to stay up all
> the time. I also wish Emacs were a preemptive multitasking operating
> system, so network troubles with gnus, for example, wouldn't lock it up.
> :)
I use this to start a long-running emacs session. As well as starting
gnuserv it also disables C-x C-c for those times when finger memory gets the
better of me.
-- cut here ----------------------------------------------------------------
(defun long-term-emacs ()
"Turn this emacs session into a long term emacs.
This involves disabling C-x C-c and also starting the GNU server."
(interactive)
(require (if (locate-library "gnuserv-compat") 'gnuserv-compat 'gnuserv))
(gnuserv-start)
(define-key global-map [(control x) (control c)]
#'(lambda ()
(interactive)
(message "C-x C-c is disabled"))))
-- cut here ----------------------------------------------------------------
Drop it into your ~/.emacs and, when you want to create a long-running
emacs, just type "M-x long-term-emacs RET" and everything should be set up
for you.
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
On 28 Apr 2004 09:04:05 GMT, Dave Pearson <··········@davep.org> wrote:
> I'm fairly sure I've seen a utility that does the same re-mapping of
> Caps Lock to Control on Windows. I might be miss-remembering but
> I've got a vague recollection that it's actually part of some
> freely-downloadable "power toys" type affair that's available on the
> Microsoft web site.
Doing that cleanly (such that it works with all versions of Windows)
doesn't seem to be easy. Here's a program (non-free) which claims to
do it:
<http://www.pcmag.com/article2/0,1759,764194,00.asp>
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> On 28 Apr 2004 09:04:05 GMT, Dave Pearson <··········@davep.org> wrote:
>
> > I'm fairly sure I've seen a utility that does the same re-mapping of
> > Caps Lock to Control on Windows. I might be miss-remembering but
> > I've got a vague recollection that it's actually part of some
> > freely-downloadable "power toys" type affair that's available on the
> > Microsoft web site.
>
> Doing that cleanly (such that it works with all versions of Windows)
> doesn't seem to be easy. Here's a program (non-free) which claims to
> do it:
>
> <http://www.pcmag.com/article2/0,1759,764194,00.asp>
For instructions on how to manually re-map the keys, see:
http://www.microsoft.com/whdc/device/input/w2kscan-map.mspx
For a free utility that does this:
http://www.cam.hi-ho.ne.jp/oishi/indexen.html
--
Bill Clementson
* Edi Weitz <···@agharta.de>:
> On 28 Apr 2004 09:04:05 GMT, Dave Pearson <··········@davep.org> wrote:
>
> > I'm fairly sure I've seen a utility that does the same re-mapping of
> > Caps Lock to Control on Windows. I might be miss-remembering but I've
> > got a vague recollection that it's actually part of some
> > freely-downloadable "power toys" type affair that's available on the
> > Microsoft web site.
>
> Doing that cleanly (such that it works with all versions of Windows)
> doesn't seem to be easy. Here's a program (non-free) which claims to do
> it:
>
> <http://www.pcmag.com/article2/0,1759,764194,00.asp>
<URL:http://www.gnu.org/software/emacs/windows/faq3.html#capscontrol> is
also an obvious place to look (although, annoyingly, all of the NT oriented
registry file links seem to be dead). Having since looked myself it seems I
had in mind Microsoft's Kernel Toys package but that this only worked for
Windows 95 (and probably 98).
<URL:http://www.manicai.net/comp/swap-caps-ctrl.html> might also be useful
to someone.
--
Dave Pearson
http://www.davep.org/lisp/
Dave Pearson <··········@davep.org> writes:
> I'm fairly sure I've seen a utility that does the same re-mapping of Caps
> Lock to Control on Windows. I might be miss-remembering but I've got a vague
> recollection that it's actually part of some freely-downloadable "power
> toys" type affair that's available on the Microsoft web site.
Simon Peyton-Jones has an extensive page about making Win32 habitable
for Unix users. It's a good first place to check for this stuff.
http://www.research.microsoft.com/~simonpj/win32-cheat.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8728 day of my life Ari Johnson wrote:
> Actually, Meta (Alt) is the one that gives me the most trouble. Most
> of the C- commands are in the region that's easy to hit with your left
> index finger while pressing Ctrl with your left pinky (on a QWERTY
> board), whereas some of the Meta combinations are easier to hit with
> your thumb on Alt while others are easier to hit with your pinky on it.
Do not use Meta then :) Use prefix C-[ (i.e. Esc) instead. For
example:
C-M-f <=> C-[ C-f
M-f <=> C-[ m
And so on...
- --
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUBQI8ijA4ALcwzZFpVAQLAbAgAieTCBGUKyfwfdgzQfxhC2NA0ma8S++5V
ApKRpkUxirk1g+MOrHmRJXW5TepWE5v08tIpwqeBryHn7M/qkLqbjnJgKvS4epbZ
HBPnS0rYYxxGUqSe6hSjtef8+Xt4UsPDKOcMVmFY48qG7elhUdwFu3fps/YVPjk6
hA+bjUAQtOZIDyd3WhcAqM2in5JNvtsVe9YmGyEamJL8T97G31xdHMtzRNtUB0UJ
gcBhH/GjOfsKSJsc0pKEA22785qWtXjnivdtokSb5vwF9g4mAgks523kvWz8docF
zEAworkm483CkJdLVy+APJR9UFcLB5CoGxuMeYJV85IligeNhTAtig==
=PayP
-----END PGP SIGNATURE-----
On Wed, Apr 28, 2004 at 10:18:33AM +0700, Ivan Boldyrev wrote:
> C-M-f <=> C-[ C-f
> M-f <=> C-[ m
Kind of sucks for navigation commands, no?
--
; 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."
--=-=-=
Content-Type: text/plain
On 8729 day of my life Matthew Danish wrote:
> On Wed, Apr 28, 2004 at 10:18:33AM +0700, Ivan Boldyrev wrote:
>> C-M-f <=> C-[ C-f
>> M-f <=> C-[ m
>
> Kind of sucks for navigation commands, no?
I use Meta :)
You can also use numeric prefixes. I use C-[ only for some
combinations that I occupied by my desktop manager or terminal
program. Fortunately they ar not navigation-related :)
--
Ivan Boldyrev
Your bytes are bitten.
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUAQJDQWQ4ALcwzZFpVAQKXKQf+OIkua+YL+CoIDvZ9o2Sfc0INSRohswSQ
73k84GCqrvBzRRmpAFIajCXZjod9swJLIitjj6EWS1NydJWuW46SZo6v3tFQgdP9
jJrDweQlzlfMuTEHDmuaWbbZAUBhCWYlPJ5anVYeciz2yYRyHS8Y3EPyrH4o3oW6
44C9CSvHCZggXhLzXoH8AQwFIG7xgnIc8jE+RS+lgQwvlsKYt6OzUDMblVCF4aV7
emm4+o6kp5A09Xn6LUXCpPxby6X1C46iiAR20II1DjDZFl0vTzYERGQpNlScFzCE
LQOdoDsX29n2goKeIhIukNykNCMzogsg3mxO1a3hH3QuO8tSOlw5vQ==
=SWGm
-----END PGP SIGNATURE-----
--=-=-=--
Ari Johnson <·····@hotmail.com> writes:
> Keyboard remapping isn't a very good option, because I want to use the
> same editor in Windows as I do in Unix (especially if that happens to
> be Emacs - no sense learning a new operating system just to end up
> dual-booting between what amounts to Emacs and Notepad).
I use Emacs on both Windows and Unix and I have remapped the keys in
both. Not a problem.
--
~jrm
Ari Johnson <·····@hotmail.com> wrote on Tue, 27 Apr 2004 18:19:40 -0700:
>
> I also wish Emacs were a preemptive multitasking operating system,
> so network troubles with gnus, for example, wouldn't lock it up. :)
IF you are running Emacs on a multitasking OS and reasonable hardware
you might want to try starting a second Emacs session for Gnus :-)
I never share my coding Emacs session and the Gnus Emacs session.
Erik Winkels <·······@xs4all.nl> writes:
> Ari Johnson <·····@hotmail.com> wrote on Tue, 27 Apr 2004 18:19:40 -0700:
>>
>> I also wish Emacs were a preemptive multitasking operating system,
>> so network troubles with gnus, for example, wouldn't lock it up. :)
>
> IF you are running Emacs on a multitasking OS and reasonable hardware
> you might want to try starting a second Emacs session for Gnus :-)
>
> I never share my coding Emacs session and the Gnus Emacs session.
I do, and I typically have my (X)Emacs for months. The
hardware I'm running on is a 666 MHz PIII with 384 MB RAM. The OS is
reasonable, though (FreeBSD 4.9).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
"Raymond Wiker" <·············@fast.no> wrote in message
···················@raw.grenland.fast.no...
> I do, and I typically have my (X)Emacs for months. The
> hardware I'm running on is a 666 MHz PIII with 384 MB RAM. The OS is
> reasonable, though (FreeBSD 4.9).
(Not to get into an OS war, but...)
Mine is a P3 900MHz with 512MB running Win2K. If I could do anything to this
machine, I'd give it more memory, but it's maxed out :-(.
For odd reasons, the Explorer shell (i.e.the desktop) occasionally just gets
sick and goes out to lunch, that's what prompts my restarts.
But I just found a tip that I can kill that shell, and restart it from the
Task Manager (via ctrl-alt-del), so I may have to restart even less than
every couple of months.
Other than that, it pretty much Just Works for me, but I'm the exception
here it seems. I don't think anyone else here at the office lasts as long
without rebooting.
Regards,
Will Hartung
(·····@msoft.com)
Ari Johnson <·····@hotmail.com> writes:
> Maybe I'll just have to learn to use Alt and start learning
> commands. Do there exist any good PDF cheat sheets a la the many
> that exist for vi? I'm not big on hard copy (I have never owned a
> printer), but I could justify having a sheet around to learn Emacs.
(shell-command
(concat "zcat" " " data-directory "refcard.ps.gz" " | lpr"))
--
BOMBED BY ENORMOUS GNATS 12W 23N. SINKING. U-753.
giacomo boffi wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
>
>>Maybe I'll just have to learn to use Alt and start learning
>>commands. Do there exist any good PDF cheat sheets a la the many
>>that exist for vi? I'm not big on hard copy (I have never owned a
>>printer), but I could justify having a sheet around to learn Emacs.
>
>
>
> (shell-command
> (concat "zcat" " " data-directory "refcard.ps.gz" " | lpr"))
>
Of all the places to hide it, the Emacs distribution is the one I
expected the least. Thanks.
Ari Johnson <·····@hotmail.com> writes:
> Thanks for the responses so far - I am definitely learning some of
> the possibilities, especially regarding gnuclient. I just wish that
> C-x C-c didn't kill Emacs when issued from gnuclient...I want Emacs
> to stay up all the time.
,----[ C-h v confirm-kill-emacs RET ]
| confirm-kill-emacs's value is y-or-n-p
|
| Documentation:
| How to ask for confirmation when leaving Emacs.
| If nil, the default, don't ask at all. If the value is non-nil, it should
| be a predicate function such as `yes-or-no-p'.
|
| You can customize this variable.
|
| Defined in `files'.
`----
--
Johan Bockg�rd
On Fri, 23 Apr 2004 11:48:46 -0700, "Will Hartung" <·····@msoft.com> wrote:
> Simple. No, really.
>
> You need to make two versions up front, one for Windows, one for
> Linux.
What about Mac OS X?
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> On Fri, 23 Apr 2004 11:48:46 -0700, "Will Hartung" <·····@msoft.com>
wrote:
>
> > Simple. No, really.
> >
> > You need to make two versions up front, one for Windows, one for
> > Linux.
>
> What about Mac OS X?
Emacs and Clisp run on OS X, don't they?
"What about Solaris? What about AIX? What about NT/MIPS?"
Once the instructions are basically done, the recipe should be widely
applicable. The Linux instructions should pretty much Just Work on any Unix,
even Mac OS X I assume, for someone willing to port the package to the
platform. I don't know what the pitfalls of Unix-esque development are on OS
X. I know that there is the Fink project, but I don't know quite what
hurdles it needs to jump through to get "./configure; make; make install" to
work.
Regards,
Will Hartung
(·····@msoft.com)
On Fri, 23 Apr 2004 12:34:28 -0700, "Will Hartung" <·····@msoft.com> wrote:
> "Edi Weitz" <···@agharta.de> wrote in message
> ···················@bird.agharta.de...
>> On Fri, 23 Apr 2004 11:48:46 -0700, "Will Hartung" <·····@msoft.com>
> wrote:
>>
>> > Simple. No, really.
>> >
>> > You need to make two versions up front, one for Windows, one for
>> > Linux.
>>
>> What about Mac OS X?
>
> Emacs and Clisp run on OS X, don't they?
Sure. But that was not why I asked. My point was that you didn't start
with "Take CLISP and Emacs because they'll run almost everywhere" but
you started with "You need to make /two/ versions..."
I don't want to nitpick but while I myself currently don't have a Mac
I think there are still more Mac users than Linux users and due to OS
X Macs (especially iBooks and PowerBooks) seem to be the new platform
of choice for many hackers. Better to cater to them, too. I'd even go
as far as to say that if your aim is to make more people aware of Lisp
(or of anything that's not mainstream) the Mac and Linux developers
are more important than the Windows bunch. But this might just be my
gut feeling and I don't want to spend much time discussing this topic
here.
Let me add that I'm not even sure if a self-contained Lisp CD is the
way to go. It sure is nice to have and now that I've heard of the Lisp
Res Kit I might even point some people to it. But, after all, Lisp is
a programming language and not an application like, say, iTunes. If a
prospective Lisp programmer can't be bothered to read a webpage,
download, install, and configure a compiler and an IDE on his platform
of choice and instead insists on getting a self-booting CD or a
one-click-no-brainer setup.exe he doesn't look like a worthy goal to
me anyway.
> "What about Solaris? What about AIX? What about NT/MIPS?"
Not relevant. If you work on Solaris or AIX exclusively you most
likely know what you're doing and don't need someone to hold your
hand.
Cheers,
Edi.
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> On Fri, 23 Apr 2004 12:34:28 -0700, "Will Hartung" <·····@msoft.com>
wrote:
>
> > "Edi Weitz" <···@agharta.de> wrote in message
> > ···················@bird.agharta.de...
> >> On Fri, 23 Apr 2004 11:48:46 -0700, "Will Hartung" <·····@msoft.com>
> > wrote:
> >>
> >> > Simple. No, really.
> >> >
> >> > You need to make two versions up front, one for Windows, one for
> >> > Linux.
> >>
> >> What about Mac OS X?
> >
> > Emacs and Clisp run on OS X, don't they?
>
> Sure. But that was not why I asked. My point was that you didn't start
> with "Take CLISP and Emacs because they'll run almost everywhere" but
> you started with "You need to make /two/ versions..."
Because once you have the Unix and Windows versions, the "work" is done, and
minor porting is (should be) all that's needed for any other platform.
Things like tweaks to an environment variable. Like I said, I dunno what the
real issues are, but a Unix-esque install should basically Just Work for the
Mac. Windows Is Different. Mac OS X much less so (so is my understanding).
I think it would be much easier for someone to create a [insert specific
Unix implementation here] binary port from a set of instructions for Linux.
That's where the work is needed, creating that meta script to build and
bundle the package. Mac OS X is just "another Unix". [Yes, I know the Mac
has issues, but it's been out long enough that I figure the basic issue of
building OSS from sources has been mostly addressed. It's an assumption on
my part.].
Windows is more difficult because I can see folks starting with binaries of
Emacs and/or CLISP to start with rather than building them from scratch, so
it's a different recipe. I'd like to hope that a Cygwin port could just
follow the Unix recipe.
After that, it's (ideally) mostly just labor by folks with the correct
machines.
Regards,
Will Hartung
(·····@msoft.com)
Edi Weitz wrote:
> Let me add that I'm not even sure if a self-contained Lisp CD is the
> way to go. It sure is nice to have and now that I've heard of the Lisp
> Res Kit I might even point some people to it. But, after all, Lisp is
> a programming language and not an application like, say, iTunes. If a
> prospective Lisp programmer can't be bothered to read a webpage,
> download, install, and configure a compiler and an IDE on his platform
> of choice and instead insists on getting a self-booting CD or a
> one-click-no-brainer setup.exe he doesn't look like a worthy goal to
> me anyway.
What makes you think that investigating a language whose advocates can't
even get their act together well enough to create a one file install
package would look like a worthy goal to an outsider?
You make it sound like configuring emacs and your-lisp-here is easy,
even for someone who has used neither.
If your goal is to keep idiots out of the Lisp community by keeping the
barriers to entry high, fine. But don't think that you won't also be
keeping out smart people who would have become valuable contributors,
but for whom life is too short to spend reading installation instructions.
Self contained Knoppix CDs are wonderful emergency toolkits. Boot the
afflicted machine, and you can bring a complete UNIX toolkit to bear on
stubborn, misconfigured operating systems or application software (or
sniff out the cheat codes in videogames :-) ). And the lusers watching
in awe are usually quite impressed at a complete, self contained
portable OS with GUI running from a CD. A Lisp CD won't have quite the
same audience, but don't underestimate the persuasiveness and utility of
a slick environment that boots up on anything with an x86 processor and
a CD drive.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Edi Weitz wrote:
> > If a
> > prospective Lisp programmer can't be bothered to read a webpage,
> > download, install, and configure a compiler and an IDE on his platform
> > of choice
Wait just a minute there.
Configuration sucks. (Installers suck too.)
I have been using Lisp for a long time, and I have never
wanted to configure a compiler and IDE before I could use it.
I don't configure Java before I use it.
And usually I haven't had to configure a Lisp either.
Back when I used Lucid CL, I just read it off a tape and hey presto it
worked. Certain other CLs made me do some configuration, and I always
found it annoying.
Sure, when I compiled a Lisp from source, I might have to
start with something like "make configure", but usually
even that didn't require answering any questions.
> > and instead insists on getting a self-booting CD or a
> > one-click-no-brainer setup.exe he doesn't look like a worthy goal to
> > me anyway.
I also hate installers. What do they do? I don't want some
random program messing with arbitrary parts of my machine.
> What makes you think that investigating a language whose advocates
> can't even get their act together well enough to create a one file
> install package would look like a worthy goal to an outsider?
What makes you think these "outsiders" think that way?
Where did this mania for "installers" come from?
> You make it sound like configuring emacs and your-lisp-here is easy,
> even for someone who has used neither.
Good point.
> If your goal is to keep idiots out of the Lisp community by keeping
> the barriers to entry high, fine. But don't think that you won't also
> be keeping out smart people who would have become valuable
> contributors, but for whom life is too short to spend reading
> installation instructions.
Another good one.
However, to avoid the installer nightmare, simple installation
instructions are a price worth paying.
There are quite a few systems that give you a tar or zip
file that you unpack somewhere, and then you can run
right away in that dir or copy (or link to) a couple
of files, or put a dir in a path, if you want to be able
to use it from other dirs easily.
For something Java the instructions might just be: put this .jar file
somewhere, then click on it or say "java -jar that.jar".
No configuration: it works out of the box.
No evil installer putting files all over the place and doing
who knows what else and leaving a mess when if it goes wrong.
> Self contained Knoppix CDs are wonderful emergency toolkits. Boot the
> afflicted machine, and you can bring a complete UNIX toolkit to bear
> on stubborn, misconfigured operating systems or application software
> (or sniff out the cheat codes in videogames :-) ). And the lusers
> watching in awe are usually quite impressed at a complete, self
> contained portable OS with GUI running from a CD.
Ok, that sounds good.
But this doesn't:
> A Lisp CD won't have
> quite the same audience, but don't underestimate the persuasiveness
> and utility of a slick environment that boots up on anything with an
> x86 processor and a CD drive.
Boots up???? With what OS?
I would keep anything like that well away from any machine I
cared anything about.
-- jd
Jeff Dalton wrote:
> Back when I used Lucid CL, I just read it off a tape and hey presto it
> worked. Certain other CLs made me do some configuration, and I always
> found it annoying.
You just read it off a tape and it worked? Either you invoked a magic
incantation from a particular directory, or the operating system you
were using had the installer functionality built in, I'd guess. Did you
have to type "cpio"?
> I also hate installers. What do they do? I don't want some
> random program messing with arbitrary parts of my machine.
The best of them put the files where the files need to be put, download
and install dependencies as needed, hook up icons on the desktop and/or
in the window manager menu systems, diddle the registry as necessary on
MS Windows systems, and leave instructions for an automated, clean and
safe uninstall. The worst of them confirm all of your nightmares.
I've written about this in c.l.l before, at
http://groups.google.com/groups?q=g:thl1295247783d&selm=9MWdnYfR_uwFir3dRVn-vg%40golden.net&rnum=120
Many man-years have been spent writing installers, for all the big
operating systems. Obviously, they fill a need. You're just not part of
the target market.
>>What makes you think that investigating a language whose advocates
>>can't even get their act together well enough to create a one file
>>install package would look like a worthy goal to an outsider?
>
>
> What makes you think these "outsiders" think that way?
>
> Where did this mania for "installers" come from?
When I said "one file install package", I wasn't advocating an
executable over a tarball with simple instructions. Both approaches have
their fans and their merits. I was arguing against Edi's "real men don't
need simple instructions" attitude.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Jeff Dalton wrote:
> > Back when I used Lucid CL, I just read it off a tape and hey presto it
> > worked. Certain other CLs made me do some configuration, and I always
> > found it annoying.
>
> You just read it off a tape and it worked?
Yes.
? Either you invoked a magic
> incantation from a particular directory, or the operating system you
> were using had the installer functionality built in, I'd guess.
Neither. I did have to invoke an ordinary incantation referring
to the Lisp system.
What are you thinking the installer did?
> Did you have to type "cpio"?
I don't think so. Maybe I had to type "tar" or something. (It was
quite a few years ago by now.)
> > I also hate installers. What do they do? I don't want some
> > random program messing with arbitrary parts of my machine.
>
> The best of them put the files where the files need to be put,
> download and install dependencies as needed, hook up icons on the
> desktop and/or in the window manager menu systems, diddle the registry
> as necessary on MS Windows systems, and leave instructions for an
> automated, clean and safe uninstall.
But where do they put the files? It all becomes a mystery.
I usually don't want icons hooked up.
And installing dependencies can mess up other things.
> The worst of them confirm all of your nightmares.
> I've written about this in c.l.l before, at
> http://groups.google.com/groups?q=g:thl1295247783d&selm=9MWdnYfR_uwFir3dRVn-vg%40golden.net&rnum=120
>
> Many man-years have been spent writing installers, for all the big
> operating systems. Obviously, they fill a need. You're just not part
> of the target market.
They fill a felt or perceived need, not necessarily a real one.
I partly exclude the "packages" that some Unixoid systems have.
They install, but in a fairly understandable and simple way.
In the old days, much software had "make install", but (1) you could
do "make -n install" to see what it would do without actually doing
it, and (2) it often wasn't necessary to do it, or you could do
only a small part of it.
Still, perhaps there's a real need on Windows. That's where
the ideology seems to be coming from, and, as you wrote in the
message ref'd above:
some Windows users are now so comfortable with the process that
they're suspicious of apps which don't provide one.
> >>What makes you think that investigating a language whose advocates
> >>can't even get their act together well enough to create a one file
> >>install package would look like a worthy goal to an outsider?
> > What makes you think these "outsiders" think that way?
> > Where did this mania for "installers" come from?
> When I said "one file install package", I wasn't advocating an
> executable over a tarball with simple instructions. Both approaches
> have their fans and their merits. I was arguing against Edi's "real
> men don't need simple instructions" attitude.
Ok; sorry for misunderstanding.
-- jd
On Sat, 24 Apr 2004 13:23:05 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
> I was arguing against Edi's "real men don't need simple
> instructions" attitude.
If this is my attitude why do I write "cookbooks" and tutorials? And
why do I try to document my own libraries as precisely as possible?
My "attitude" is that "Prospective Lisp Programmer" defines a target
market which is very different from the one defined by "Joe Windows
User."
Edi.
Edi Weitz <···@agharta.de> writes:
> On Sat, 24 Apr 2004 13:23:05 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
>
> > I was arguing against Edi's "real men don't need simple
> > instructions" attitude.
>
> If this is my attitude why do I write "cookbooks" and tutorials? And
> why do I try to document my own libraries as precisely as possible?
>
> My "attitude" is that "Prospective Lisp Programmer" defines a target
> market which is very different from the one defined by "Joe Windows
> User."
I'm not either -- I'm already well-supplied with Lisps, I
do a fair amount of Lisp programming, and I hardly ever use
Windows -- but I've often installed and tried out language
systems, and someone who doesn't do it often is likely to
appreciate simplicity even more.
It makes a big difference to me (and I don't think this is unusual)
if the process is very simple and very easy to understand, so
that it doesn't require much time or thought, because there
are always other more important or more interesting demands
on time and thought.
(For one, it's a lot more interesting to use the system than
to install it.)
Many systems make it easy. For example:
Many things implemented in Java are as easy as: put some jar files
somewhere, type "java -jar try-this.jar".
A while back, I tried out a bunch of Logo systems. Typically,
you downloaded a tar of zip file, unpacked it, and you could
start them up right then and there. No configuration, and no
installation beyond that was required. (This was on Unix,
not Windows. I don't know what the process would have been
on Windows.)
If I expected to use one of the regularly, I'd want to do
more, at least to have a command in my path, but I didn't
have to do anything more just to try them out.
And if I want to get rid of one, I just delete the directory
I unpacked it in.
Prospective Lisp programmers will get a more favorable impression
of the language if it's that easy to start using it, rather than
harder.
-- jd
> If a prospective Lisp programmer can't be bothered to read a webpage,
> download, install, and configure a compiler and an IDE on his platform
> of choice and instead insists on getting a self-booting CD or a
> one-click-no-brainer setup.exe he doesn't look like a worthy goal to
> me anyway.
I don't believe there is any reason to filter people that are by
certain standards "worthy" or "not worthy." I simply want something I
can point prospective Lisp programmers to and rest assured that
incidental issues (installation issues, library compatibility issues,
library availability issues) will not get in the way of appreciating
the language.
On 23 Apr 2004 20:23:52 -0700, ·······@mindspring.com (Rayiner Hashem) wrote:
> I don't believe there is any reason to filter people that are by
> certain standards "worthy" or "not worthy."
A noble goal, but you will nevertheless filter implicitely because you
only have a finite amount of time to devote to this task and you won't
be able to cater to anyone on this planet... :)
Edi.
According to Edi Weitz <···@agharta.de>:
> I think there are still more Mac users than Linux users and due to OS
> X Macs (especially iBooks and PowerBooks) seem to be the new platform
> of choice for many hackers.
<bait>
If they're hackers why aren't they using Lisp?
</bait>
;-)
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers
Will Hartung wrote:
> "Edi Weitz" <···@agharta.de> wrote in message
> ···················@bird.agharta.de...
>
>>On Fri, 23 Apr 2004 11:48:46 -0700, "Will Hartung" <·····@msoft.com>
>
> wrote:
>
>>>Simple. No, really.
>>>
>>>You need to make two versions up front, one for Windows, one for
>>>Linux.
>>
>>What about Mac OS X?
>
>
> Emacs and Clisp run on OS X, don't they?
>
> "What about Solaris? What about AIX? What about NT/MIPS?"
>
> Once the instructions are basically done, the recipe should be widely
> applicable. The Linux instructions should pretty much Just Work on any Unix,
> even Mac OS X I assume, for someone willing to port the package to the
> platform. I don't know what the pitfalls of Unix-esque development are on OS
> X. I know that there is the Fink project, but I don't know quite what
> hurdles it needs to jump through to get "./configure; make; make install" to
> work.
In any case, you could make a package for OSX that is essentially
equivalent to your suggestion but even easier to install:
1. Download LIAB.dmg
2. Double-click LIAB.dmg
3. Drag LIAB.app to the directory of your choice.
4. Double-click LIAB.app.
Done.
Here you go: Lisp in a Box <URL:http://www.mapcar.org/~mrd/lispbox/>
Having recently ported an app to windows, I figured that my new NSIS
skills would let me put together a package like this in a fairly short
time. I hope you don't mind I jumped to it before you.
--
; 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."
> Having recently ported an app to windows, I figured that my new NSIS
> skills would let me put together a package like this in a fairly short
> time. I hope you don't mind I jumped to it before you.
Cool. Thanks for taking the initiative. I don't mind at all, of
course. I like the emacs idea mentioned earlier, so I'll see if I can
do that instead of an HTML tutorial. I hope you don't mind if I use
your work as the basis for a more fleshed-out Linux and Mac version?
On Sat, Apr 24, 2004 at 06:53:11AM -0700, Rayiner Hashem wrote:
> > Having recently ported an app to windows, I figured that my new NSIS
> > skills would let me put together a package like this in a fairly short
> > time. I hope you don't mind I jumped to it before you.
> Cool. Thanks for taking the initiative. I don't mind at all, of
> course. I like the emacs idea mentioned earlier, so I'll see if I can
> do that instead of an HTML tutorial. I hope you don't mind if I use
> your work as the basis for a more fleshed-out Linux and Mac version?
Go ahead. A Linux version should be able to be a tarball with a script
to setup paths and run emacs, and an OS X app is probably very similar.
--
; 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."
Matthew Danish escreveu:
> On Sat, Apr 24, 2004 at 06:53:11AM -0700, Rayiner Hashem wrote:
>
>>>Having recently ported an app to windows, I figured that my new NSIS
>>>skills would let me put together a package like this in a fairly short
>>>time. I hope you don't mind I jumped to it before you.
>>
>>Cool. Thanks for taking the initiative. I don't mind at all, of
>>course. I like the emacs idea mentioned earlier, so I'll see if I can
>>do that instead of an HTML tutorial. I hope you don't mind if I use
>>your work as the basis for a more fleshed-out Linux and Mac version?
>
>
> Go ahead. A Linux version should be able to be a tarball with a script
> to setup paths and run emacs, and an OS X app is probably very similar.
>
Just .01999... in most linuces emacs may be already installed, so I
suggest the script test for this and if there is one, just install
slime, etc.
--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Matthew Danish wrote:
> On Sat, Apr 24, 2004 at 06:53:11AM -0700, Rayiner Hashem wrote:
>
>>>Having recently ported an app to windows, I figured that my new NSIS
>>>skills would let me put together a package like this in a fairly short
>>>time. I hope you don't mind I jumped to it before you.
>>
>>Cool. Thanks for taking the initiative. I don't mind at all, of
>>course. I like the emacs idea mentioned earlier, so I'll see if I can
>>do that instead of an HTML tutorial. I hope you don't mind if I use
>>your work as the basis for a more fleshed-out Linux and Mac version?
>
>
> Go ahead. A Linux version should be able to be a tarball with a script
> to setup paths and run emacs, and an OS X app is probably very similar.
I think a good OS X version would be an app bundle that you just drag
anywhere you like and then double-click to start. I did a little work to
make one, and I think I might be an hour or two of work from having it
ready to drag and double-click, but maybe I ought to look at yours
first; maybe if I make one it should reuse as much as possible of what
you did.
Rayiner Hashem wrote:
>>Having recently ported an app to windows, I figured that my new NSIS
>>skills would let me put together a package like this in a fairly short
>>time. I hope you don't mind I jumped to it before you.
>
> Cool. Thanks for taking the initiative. I don't mind at all, of
> course. I like the emacs idea mentioned earlier, so I'll see if I can
> do that instead of an HTML tutorial. I hope you don't mind if I use
> your work as the basis for a more fleshed-out Linux and Mac version?
So I knocked together a quick version of something similar that runs on
Mac OSX. You can get it from
http://evins.net/downloads/liab-osx-0.1.zip
It's a 40MB zip archive. Unpack it anywhere you like and double-click
the LispBox application. If it works properly, a Carbon Emacs session
should start with a top buffer containing a simple greeting and a bottom
buffer running OpenMCL in a SLIME session.
Why OpenMCL and not CLISP? Well, I built one with CLISP, but I found it
much easier to make the OpenMCL version independent of where you put it
in the file system. In other words, you can unpack the archive anywhere
you like and run LispBox.app without any further installation. However,
someone better-versed in CLISP might find it worthwhile to rip out
OpenMCL and replace it with CLISP. It's a simple matter of changing a
few lines in the site-start.el that is buried inside LispBox.app.
It's tested only on two G4 machines, both running OSX 10.3.3; I don't
know what happens if you try it on anything else.
It's pretty minimal; it's running OpenMCL 0.14.1-p1, and SLIME
2004-04-24. I starts up with ASDF loaded.
The full sources, docs, and examples for OpenMCL are included, including
the Objective-C interface and Cocoa examples, so one advantage is that
you have everything you need to do Mac application development, if you
should want to do that.
However, there's not really any documentation of the Lisp-in-a-Box
package per se, and I didn't package the hyperspec or anything with it,
so it needs further attention to make it really newbie-friendly.
Also, I didn't look at Matthew's Windows version, I just cobbled this
one together. It might be worth the effort to make them more similar to
each other, I don't know.
mikel <·····@evins.net> writes:
> Rayiner Hashem wrote:
> >>Having recently ported an app to windows, I figured that my new NSIS
> >>skills would let me put together a package like this in a fairly short
> >>time. I hope you don't mind I jumped to it before you.
> > Cool. Thanks for taking the initiative. I don't mind at all, of
> > course. I like the emacs idea mentioned earlier, so I'll see if I can
> > do that instead of an HTML tutorial. I hope you don't mind if I use
> > your work as the basis for a more fleshed-out Linux and Mac version?
>
> So I knocked together a quick version of something similar that runs
> on Mac OSX. You can get it from
>
> http://evins.net/downloads/liab-osx-0.1.zip
>
> It's a 40MB zip archive. Unpack it anywhere you like and double-click
> the LispBox application. If it works properly, a Carbon Emacs session
> should start with a top buffer containing a simple greeting and a
> bottom buffer running OpenMCL in a SLIME session.
Excellent! That sounds like fun.
If the Mac already has an emacs, will it be affected in any
way, or will it be left alone?
(I'll have to use a friend's Mac, and was asked that
question.)
BTW, I think it would be better to have OpenMCL for a Mac
LispBox, even if a Clisp or CMUCL or whatever was also
available.
I haven't use MCL for a long time, but it seemed very nice,
years ago, when I did.
-- jd
Jeff Dalton wrote:
> mikel <·····@evins.net> writes:
>
>
>>Rayiner Hashem wrote:
>>
>>>>Having recently ported an app to windows, I figured that my new NSIS
>>>>skills would let me put together a package like this in a fairly short
>>>>time. I hope you don't mind I jumped to it before you.
>>>
>>>Cool. Thanks for taking the initiative. I don't mind at all, of
>>>course. I like the emacs idea mentioned earlier, so I'll see if I can
>>>do that instead of an HTML tutorial. I hope you don't mind if I use
>>>your work as the basis for a more fleshed-out Linux and Mac version?
>>
>>So I knocked together a quick version of something similar that runs
>>on Mac OSX. You can get it from
>>
>>http://evins.net/downloads/liab-osx-0.1.zip
>>
>>It's a 40MB zip archive. Unpack it anywhere you like and double-click
>>the LispBox application. If it works properly, a Carbon Emacs session
>>should start with a top buffer containing a simple greeting and a
>>bottom buffer running OpenMCL in a SLIME session.
>
>
> Excellent! That sounds like fun.
>
> If the Mac already has an emacs, will it be affected in any
> way, or will it be left alone?
It should be totally unaffected, but I didn't do anything to prevent my
0.1 version of Lisp-in-a-Box from loading your .emacs, so it's certainly
possible that some code in there could screw it up (in fact, I have code
in my own .emacs that screws it up mildly; for hygiene's sake I have to
move my .emacs when test-launching this package).
>
> (I'll have to use a friend's Mac, and was asked that
> question.)
>
> BTW, I think it would be better to have OpenMCL for a Mac
> LispBox, even if a Clisp or CMUCL or whatever was also
> available.
I decided that was true, but others might not agree. I cared enough to
mention it, but not enough to try very hard to make CLISP do the right
thing. :-)
> I haven't use MCL for a long time, but it seemed very nice,
> years ago, when I did.
I tend to use OpenMCL for all development, and then SBCL and Lispworks
to ensure that I haven't accidentally created any dependencies on that
particular compiler.
mikel <·····@evins.net> writes:
> It should be totally unaffected, but I didn't do anything to prevent
> my 0.1 version of Lisp-in-a-Box from loading your .emacs, so it's
> certainly possible that some code in there could screw it up (in fact,
You may try starting Emacs with the `-q' option.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso wrote:
> mikel <·····@evins.net> writes:
>
>
>>It should be totally unaffected, but I didn't do anything to prevent
>>my 0.1 version of Lisp-in-a-Box from loading your .emacs, so it's
>>certainly possible that some code in there could screw it up (in fact,
>
>
> You may try starting Emacs with the `-q' option.
I thought about it, but then a user *can't* use a .emacs file. But, on
the other hand, I suppose I could start it with a load-file argument,
and include a starter load-file for the user to customize.
I decided it was better to just make something available rather than
theorize about the best solution to issues like this. Once people can
get it they can complain about what they don't like and I don't have to
guess how to fix it. Or they can even fix it themselves.
"mikel" <·····@evins.net> wrote in message
··························@newssvr29.news.prodigy.com...
> Paolo Amoroso wrote:
> > You may try starting Emacs with the `-q' option.
>
> I thought about it, but then a user *can't* use a .emacs file. But, on
> the other hand, I suppose I could start it with a load-file argument,
> and include a starter load-file for the user to customize.
My philosophy regarding LIAB, is simply that you needn't worry about
"general purpose emacs". In this case, emacs is simply a Lisp IDE designed
for this LIAB environment. If you wanted to take the time and effort to
remove the extra modes, GNUS, etc our of emacs to make the distribution
leaner, then go ahead. The goal should be to make LIAB as painless as
practical. Later on, the user can always bind their current emacs to the
lisp in LIAB, or read the recipe, or whatever. But for LIAB, "There is no
other emacs".
Just IMHO, of course.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> "mikel" <·····@evins.net> wrote in message
> ··························@newssvr29.news.prodigy.com...
>
>>Paolo Amoroso wrote:
>>
>>>You may try starting Emacs with the `-q' option.
>>
>>I thought about it, but then a user *can't* use a .emacs file. But, on
>>the other hand, I suppose I could start it with a load-file argument,
>>and include a starter load-file for the user to customize.
>
>
> My philosophy regarding LIAB, is simply that you needn't worry about
> "general purpose emacs". In this case, emacs is simply a Lisp IDE designed
> for this LIAB environment. If you wanted to take the time and effort to
> remove the extra modes, GNUS, etc our of emacs to make the distribution
> leaner, then go ahead. The goal should be to make LIAB as painless as
> practical. Later on, the user can always bind their current emacs to the
> lisp in LIAB, or read the recipe, or whatever. But for LIAB, "There is no
> other emacs".
I thought about some of this other stuff, too. For example, I started
out making an Emacs that had all the non-Lisp progmodes stripped out.
Then I decided that doing that was a big enough change that it dserved
more testing than I planned to do for this first shot at it, so I didn;t
do that.
I guess I agree with you. Let's see what other people say, but if
there's no strong argument the other way, then I'll make a 0.2 version
of the OSX liab that doesn't load .emacs, and that has non-lisp stuff
stripped out. (I guess I'll package the Hyperspec with it, too).
Chris Hall <·······@verizon.net> writes:
> I just *have* to say this: it seems to me that anyone that already
> has Emacs on their system already has a sort of LIAB - Emacs! I've
> got cl.el, but haven't really looked at it, so I can't comment on
> what that contributes.
Not that much, if you want to do Common Lisp programming. Think of it
as more of a way to introduce some CLisms in Emacs Lisp.
> So - a lisp (granted, a lisp-1, I believe?)
No, Lisp-2.
> I'd be interested to hear comments on (non)suitability strengths/
> weaknesses as an 'Intro to Lisp', being new myself and wanting to
> spread the word.
Emacs Lisp has been an introduction to Lisp for not a small number of
people (me included), so obviously it does has some value as an "intro
Lisp". However, compared to Common Lisp, I think it feels somewhat
like a toy.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Matthew Danish escreveu:
> Here you go: Lisp in a Box <URL:http://www.mapcar.org/~mrd/lispbox/>
>
> Having recently ported an app to windows, I figured that my new NSIS
> skills would let me put together a package like this in a fairly short
> time. I hope you don't mind I jumped to it before you.
>
Great job Matthew!
I only would like to see in the page information in the size of
"LispBox.exe" and the requirements for running.
--
Cesar Rabak
OK. The Ogre 3D developement kit.
John
P� 22 Apr 2004 20:14:01 -0700, skrev Rayiner Hashem
<·······@mindspring.com>:
> I've had occasions where people have asked me to point them to a good
> Lisp implementation to get started with the language. At some point, I
> realized that it would be great if Lisp was distributed kind of like
> the JDK, with lots of libraries and documentation all in one place.
> That way, people new to the language wouldn't have to let the
> practicalities of seeking out libraries, building software, get in the
> way of learning the language. Basically, I forsee some sort of "Lisp
> in a box," a simple tarball with the compiler and lots of libraries
> included and pre-configured, maybe a pre-configured Emacs + SLIME
> setup, along with lots of documentation and maybe some basic tutorial
> material. Not to big in scope, just enough to make a nice
> first-impression.
>
> Yes, I am volunteering to put this together. My question is:
>
> 1) What do you think of the idea? Any suggestions?
> 2) What libraries should be included? Which compiler?
>
> --- Rayiner Hashem
--
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
In article <····························@posting.google.com>,
Rayiner Hashem <·······@mindspring.com> wrote:
(Yeah, this is a slightly old thread, but the thread about standards
got me to thinking that a good default Common Lisp SDK package is what's
really direly needed, and this seems like a good start on a CLDK.)
>I've had occasions where people have asked me to point them to a good
>Lisp implementation to get started with the language. At some point, I
>realized that it would be great if Lisp was distributed kind of like
>the JDK, with lots of libraries and documentation all in one place.
The first question you need to ask yourself is: Who's the target user
for this app? A lot of the downthread messages seem to assume that
the target is novice programmers or students or what-not. And while a
My First Programming Language distribution might be useful, I think
that a far more useful distribution would be one that targets
experienced programmers who want to try out a new language.
This is really the Common Lisp SDK, the equivalent to the JDK or the
.NET SDK -- the bundle that people would grab if they wanted to try
CL, and the bundle they would keep using in production if they wrote
an app with CL.
The implications of this are:
1. The target users probably have an editor that they like and are
familiar with. You don't need to give them one in a default
install -- and, in fact, they won't want you to, any more than
they'd want Perl, the JDK, or the .NET SDK to give them a new
editor.
2. They don't want a toy implementation. They want the real thing --
the full-on, optimizing, hardcore compiler and tools that the pros
use. (Or, at least, the open source implementation that gets
closest enough to that.)
3. They are familiar with their OS, and aren't going to be switching
operating systems just to try out a new dev tool. If you don't
run on their platform, you don't exist. (Or alternately: They do
cross-platform development, and if you don't run on all their
platforms, you don't exist.)
4. They do want a bunch of libraries included by default, and they
want to be able to grab libraries off the Web and have them work
automatically for them.
5. They want a platform-native, straightforward install, ideally with
(perhaps optional) included docs and samples that will at least
get them to the "Hello world" point or beyond.
So, what's that mean in practical terms? Let's take the implications
of the implications, point by point:
1. No Emacs, no SLIME, not in the default CLDK. Links on the CLDK
download page to an easy-install Emacs+SLIME CL IDE would be
great, but it's a separate package, the same way that NetBeans is
a separate download in the Java world. (And in practical terms,
you'd only really need an Emacs+SLIME bundle for Win32; other
platforms would already have Emacs, so would just need a
convenient SLIME.)
2. This means, probably, SBCL or CMUCL. Or, at least, so is the
impression I get here. It definitely means not Clisp, based on
all the Clisp-scoffing I've gotten to enjoy. Note that it also
means frequent updates. Whenever the components of your CLDK
change -- the interpreter/compiler or the libraries -- you need to
consider a release. And you need to manage version numbers for
the CLDK as a whole in a sensible fashion, so that CLDK 1.1.2
doesn't break code that compiled cleanly with CLDK 1.1.1, but CLDK
2.0 isn't a minor library tweak improved on CLDK 1.0.
3. This means an implementation that runs on Win32, OSX, Linux, and
generic Unix. Which means, really, Clisp, as nothing else is
cross-platform enough. Note that this is incompatible with the
previous point. Stroke your goatee and stare off sagely into the
middle distance inscrutably while wondering how to solve this
dilemma.
4. You need ASDF, no question about it. You'll also want CL-PPCRE,
CL-XML, and some other handful of libraries that I am not
experienced enough to know you'll want. Obviously, all the
libraries need to work with the compiler/interpreter that's the
base of the system.
5. For Windows, this ideally means an MSI installation, but an EXE is
fine. For Linux, it means an RPM. For generic Unix, it means a
tarball with a single configure, make, make install that rolls out
the whole thing and puts the libraries in the appropriate places.
For OSX, it means... um, I dunno. Whatever OS X people use.
AppBundles or something.
This is, needless to say, not easy. Packaging up disparate open
source packages in a sensible, cross-platform, and ongoing fashion,
doing basic testing and documentation, is difficult and
time-consuming. The poor sap(s) who volunteer for this are also
putting themselves in political crosshairs, as every choice they make
is grounds for a long thread and/or nasty emails wondering why the
CLDK comes with X instead of Y.
And, oh yeah, given the current state of CL implementations, it
appears to be impossible. Either Clisp needs to get good enough that
people don't sniff at you if you use it, or SBCL/CMUCL needs to get
portable enough to run on all the major platforms of the day without
incident.
Plus, some significant fraction of the people out there are using
commercial systems that (I surmise) are better than the best open
source system available, so there's little motivation for the hardcore
CL long-timers to give a damn about this CLDK, never mind treating it
as the "default" system that it would ideally like to be.
But, y'know, if someone could do this, it'd be pretty sweet, and a
significant asset to the CL open-source community.
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski <···@klio.org> wrote in message
>
> 1. The target users probably have an editor that they like and are
> familiar with. You don't need to give them one in a default
> install -- and, in fact, they won't want you to, any more than
> they'd want Perl, the JDK, or the .NET SDK to give them a new
> editor.
They may not want emacs - but only because they are not yet aware that
they need it. They need tools that "understand" lisp or they'll suffer
pain trying to write lisp with crude tools designed to butcher perl
and java together. Emacs/Slime delivers sexp based editing, a simple
lisp IDE, hyperspec lookup etc. If they already have tools that do
this they don't need LispInABox.
Of course for "emacs" read "an emacs like editor of some sort".
>
> 2. This means, probably, SBCL or CMUCL. Or, at least, so is the
> impression I get here. It definitely means not Clisp, based on
> all the Clisp-scoffing I've gotten to enjoy.
What _specifically_ do you think is wrong with Clisp?
In article <····························@posting.google.com>,
David <························@yahoo.com> wrote:
>Mike Kozlowski <···@klio.org> wrote in message
>> 2. This means, probably, SBCL or CMUCL. Or, at least, so is the
>> impression I get here. It definitely means not Clisp, based on
>> all the Clisp-scoffing I've gotten to enjoy.
>
>What _specifically_ do you think is wrong with Clisp?
I have no idea; it seems reasonably fine to me, except that many
libraries don't seem to be compatible with it. But when I complained
about the library problems here, people spoke disparagingly of CLisp,
and suggested a different implementation.
--
Mike Kozlowski
http://www.klio.org/mlk/
On Fri, May 07, 2004 at 06:38:27PM +0000, Mike Kozlowski wrote:
> 1. The target users probably have an editor that they like and are
> familiar with. You don't need to give them one in a default
> install -- and, in fact, they won't want you to, any more than
> they'd want Perl, the JDK, or the .NET SDK to give them a new
> editor.
Big problem: target user's favorite editor is probably as useless as
notepad [1] (trust me, I've met odd people) especially when it comes to
Lisp. You see, the problem is, Lisp is not really a text-based
language, it just has a surface syntax described in characters. An
editor which does not understand s-expressions is doomed to be
frustrating.
> 2. They don't want a toy implementation. They want the real thing --
> the full-on, optimizing, hardcore compiler and tools that the pros
> use. (Or, at least, the open source implementation that gets
> closest enough to that.)
On Windows, it's CLISP or non-free (maybe GCL, ECL soon). CLISP isn't
that bad.
> 3. This means an implementation that runs on Win32, OSX, Linux, and
> generic Unix.
> For Linux, it means an RPM.
Hey! Well, I suppose... since Debian has a far superior set-up already
in the distribution =) Poor RedHat users left out in the cold. But
they usually are, these days.
> The poor sap(s) who volunteer for this are also putting themselves in
> political crosshairs, as every choice they make is grounds for a long
> thread and/or nasty emails wondering why the CLDK comes with X instead
> of Y.
It's ok; we'll just flame back (assuming it might be me).
> Plus, some significant fraction of the people out there are using
> commercial systems that (I surmise) are better than the best open
> source system available, so there's little motivation for the hardcore
> CL long-timers to give a damn about this CLDK, never mind treating it
> as the "default" system that it would ideally like to be.
Er, they probably won't give a damn for other reasons. But CMUCL and
SBCL have a pretty good compiler, perhaps the best available for some
things, so I wouldn't necessarily put the commercial implementations
that far ahead in all respects.
[1] I can't believe people still use stuff like CodeWarrior, TextPad(?),
VS, old vi, pico/nano, and of course the venerable DOS edit.
--
; 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."
On Fri, 07 May 2004 23:56:56 -0400, Matthew Danish wrote:
> [1] I can't believe people still use stuff like CodeWarrior, TextPad(?),
> VS, old vi, pico/nano, and of course the venerable DOS edit.
Many of the people I work with still swear by Joe. It's funny/painful to
watch them use it.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
In article <······················@mapcar.org>,
Matthew Danish <·······@andrew.cmu.edu> wrote:
>On Fri, May 07, 2004 at 06:38:27PM +0000, Mike Kozlowski wrote:
>> 1. The target users probably have an editor that they like and are
>> familiar with. You don't need to give them one in a default
>> install -- and, in fact, they won't want you to, any more than
>> they'd want Perl, the JDK, or the .NET SDK to give them a new
>> editor.
>
>Big problem: target user's favorite editor is probably as useless as
>notepad [1] (trust me, I've met odd people) especially when it comes to
>Lisp.
Yes, but if it's what they're familiar with, it's what they're
familiar with. No vi/Textpad user is going to want to get mandatory
Emacs in a compiler installation. Saying, "Here's your compiler, you
can plug it right into your normal environment, but P.S., Emacs will
make things more enjoyable" is good; saying, "If you want to use Lisp,
you must use Emacs, you vi-using buffoon" is less good.
Editing Java is a lot more pleasant in an editor with code completion,
refactoring support, and such-like; but the JDK is content to allow
you to use whatever you like.
>> 2. They don't want a toy implementation. They want the real thing --
>> the full-on, optimizing, hardcore compiler and tools that the pros
>> use. (Or, at least, the open source implementation that gets
>> closest enough to that.)
>
>On Windows, it's CLISP or non-free (maybe GCL, ECL soon). CLISP isn't
>that bad.
Would you (presuming you're an experienced CLer) use CLISP as your
primary CL implementation? If so, there's only the issue of spotty
library support (which makes it difficult to pre-package in all sorts
of swizzy libraries); if not, it's not good enough to be the default
implementation.
>> Plus, some significant fraction of the people out there are using
>> commercial systems that (I surmise) are better than the best open
>> source system available, so there's little motivation for the hardcore
>> CL long-timers to give a damn about this CLDK, never mind treating it
>> as the "default" system that it would ideally like to be.
>
>Er, they probably won't give a damn for other reasons.
There's that, too. It's probably impossible to create a
widely-accepted default out of a pre-existing fragmented user base.
Like I say, I'm inclined to believe it's probably impossible to create
a default open-source CL implementation that most people would use.
--
Mike Kozlowski
http://www.klio.org/mlk/
On Sat, May 08, 2004 at 04:24:32AM +0000, Mike Kozlowski wrote:
> Yes, but if it's what they're familiar with, it's what they're
> familiar with. No vi/Textpad user is going to want to get mandatory
> Emacs in a compiler installation. Saying, "Here's your compiler, you
> can plug it right into your normal environment, but P.S., Emacs will
> make things more enjoyable" is good; saying, "If you want to use Lisp,
> you must use Emacs, you vi-using buffoon" is less good.
(1) vim is fine.
(2) It's not a matter of enjoyment. It's a matter of capability. Lisp
is not a text-based language. Editting it in a text editor is just as
pointless and frustrating as editting graphics files in a text editor.
> Would you (presuming you're an experienced CLer) use CLISP as your
> primary CL implementation? If so, there's only the issue of spotty
> library support (which makes it difficult to pre-package in all sorts
> of swizzy libraries); if not, it's not good enough to be the default
> implementation.
Paul Graham became a millionaire using CLISP, why not? It's perfectly
suitable for many tasks, after all, people manage to get by with Python
or Ruby. Not to mention, CLISP has got the best bignum support of any
Lisp I've tried. The only major problem with it really is that it
doesn't support certain advanced features of Common Lisp, which I'm told
is being fixed.
--
; 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."
Mike Kozlowski <···@klio.org> wrote:
> In article <······················@mapcar.org>,
> Matthew Danish <·······@andrew.cmu.edu> wrote:
>>Big problem: target user's favorite editor is probably as useless as
>>notepad [1] (trust me, I've met odd people) especially when it comes to
>>Lisp.
>
> Yes, but if it's what they're familiar with, it's what they're
> familiar with. No vi/Textpad user is going to want to get mandatory
> Emacs in a compiler installation. Saying, "Here's your compiler, you
> can plug it right into your normal environment, but P.S., Emacs will
> make things more enjoyable" is good; saying, "If you want to use Lisp,
> you must use Emacs, you vi-using buffoon" is less good.
vim does pretty nicely on Lisp source. It has a Lisp mode for
indentation, supports moving to the next/previous s-expression, and does
rather good syntax highlighting. And it doesn't hurt my fingers like
some editors -- but that's the fault of my fingers, not emacs. :)
There's a script (VIlisp) to make vim send expressions to a Lisp session
via a FIFO hack -- unfortunately it seems to be incompatible with my
preferred way of running detached Lisp sessions, which is screen. It
would be fine for doodling around, but I need my detached SBCL for
mod_lisp.
(Maybe I can work something out with socat. socat can do anything.)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Karl A. Krueger wrote:
> Mike Kozlowski <···@klio.org> wrote:
>
>>In article <······················@mapcar.org>,
>>Matthew Danish <·······@andrew.cmu.edu> wrote:
>>
>>>Big problem: target user's favorite editor is probably as useless as
>>>notepad [1] (trust me, I've met odd people) especially when it comes to
>>>Lisp.
>>
>>Yes, but if it's what they're familiar with, it's what they're
>>familiar with. No vi/Textpad user is going to want to get mandatory
>>Emacs in a compiler installation. Saying, "Here's your compiler, you
>>can plug it right into your normal environment, but P.S., Emacs will
>>make things more enjoyable" is good; saying, "If you want to use Lisp,
>>you must use Emacs, you vi-using buffoon" is less good.
>
>
> vim does pretty nicely on Lisp source. It has a Lisp mode for
> indentation, supports moving to the next/previous s-expression, and does
> rather good syntax highlighting. And it doesn't hurt my fingers like
> some editors -- but that's the fault of my fingers, not emacs. :)
>
> There's a script (VIlisp) to make vim send expressions to a Lisp session
> via a FIFO hack -- unfortunately it seems to be incompatible with my
> preferred way of running detached Lisp sessions, which is screen. It
> would be fine for doodling around, but I need my detached SBCL for
> mod_lisp.
>
> (Maybe I can work something out with socat. socat can do anything.)
I'm still trying to figure out what Emacs gives me (other than the
kitchen sink, and I'm well-stocked on kitchen sinks already) that vim
doesn't, other than swallowing up an inferior Lisp session.
On 8738 day of my life Karl A. Krueger wrote:
> There's a script (VIlisp) to make vim send expressions to a Lisp session
> via a FIFO hack -- unfortunately it seems to be incompatible with my
> preferred way of running detached Lisp sessions, which is screen. It
> would be fine for doodling around, but I need my detached SBCL for
> mod_lisp.
As SBCL doesn't need real terminal, you can use detachtty
<http://www.cliki.net/detachtty>. It should be compatible with
VIlisp.
--
Ivan Boldyrev
Sorry my terrible English, my native language is Lisp!
"Mike Kozlowski" <···@klio.org> wrote in message
·················@reader2.panix.com...
> In article <····························@posting.google.com>,
> Rayiner Hashem <·······@mindspring.com> wrote:
>
> (Yeah, this is a slightly old thread, but the thread about standards
> got me to thinking that a good default Common Lisp SDK package is what's
> really direly needed, and this seems like a good start on a CLDK.)
Here's the major problem, and the reason I advocated bundling Emacs with
Lisp In A Box.
All of the folks using their favorite editor are using their favorite editor
for a system that most probably is a batch oriented edit/compile/run
paradigm.
While you can use Lisp this way (and I have), most folks who use Lisp In
Anger, don't. The interactivity of the system is a major enhancement to the
entire Lisp experience.
Learning Lisp in a batch mode is Wrong, and sets bad examples. Run Lisp as a
batch mode system, and you may as well use Java, because there isn't that
much difference beyond macros and some expressibility that many coders will
not necessarily use directly anyway, particularly early on.
I STILL run Lisp in a basically batch mode, because that's how I'm used to
doing it, and "I don't know any better". And I KNOW I'm "doing it wrong",
but have yet to make the leap to doing it "correctly". And by Batch mode, I
mostly mean that I continually reload entire files, vs specific definitions,
I don't use any of the auto complete features, etc. Lisp CAN be used this
way, it SHOULDN'T be.
There is a Way of working with Lisp, and letting folks run off and discover
their own Way is basically a waste of their time. The faster they get to the
Lisp Way, the faster they See The Light. How many folks use a command line
Smalltalk compiler?? Hands? Anyone?
Today, that Lisp Way is central upon Emacs and its paradigms.
And configuring the Lisp + Emacs is non-trivial, even when it is well
documented.
Simple example. Microsofts Visual Studio has, at its core, a command line
C/C++ compiler. I can guarantee you that a VAST majority of its users can
care less, and rely on Visual Studio completely. Sure, you could write NMAKE
files, integrate with a 3rd party editor, etc. But most don't, because VS is
"good enough" to not warrant going through the pain of configuring a new
environment, with a new editor etc., to the MS tools. Same with Delphi and
other IDEs.
For those who have graduated above the functionality and capability of LIAB,
then they can make the leap and configure their own system later. I use
Xanalys PE on Windows because it's brain dead to run, install, and use. And
its limitations don't get in my way enough to make me want to bother
switching.
So, Emacs must stay in LIAB, IMHO. Folks need to understand and learn the
ENVIRONMENT centered around a CL system, and not simply the language itself.
The language is only partially the benefit of the whole thing.
AFAIK the only real feature limitation of CLISP besides it being interpreted
is that it doesn't support even a fake Multi Processing module, whether its
threads, or co-processes, or whatever. For what work I have done, CLISP is
more than adequate to the task.
The other advantage of CLISP in LIAB is simply that it runs pretty much
everywhere. This gives LIAB a consistent look and feel and behavior for
anyone who wants to use and, more so, for anyone who wants to leverage its
existence with supporting documents, examples, and tutorials.
If you look at every single Lisp text out there, they pretty much handwave
away the implementation, how to use it, how to load and run programs, etc.
Because they're all different. "'Consult your System Administrator'? Wait,
I'M the System Administror!" What they also do is they completely neglect
interacting with the debugger, interacting with the Listener, "using" the
whole environment. They skip all of that detail because they can't rely on a
standard distribution. At least the Java books can rely on the Sun JDK, its
configuration, and its use, even though there are several other JVMs and
JDKs available.
If LIAB took off with CLISP, Peter could easily put a chapter on Using LIAB
in his book, knowing what libraries it will have, knowing how to start it,
what keystrokes are bound in Emacs, the screen shots will be consistent, and
his examples will WORK, whether you're running Windows, Unix, or Mac.
THAT consistency and simplicity is where LIAB gets its power. It can act as
a core for a network effect.
The configure script is what makes OSS C/C++ code even usable today.
'configure' isolates and handles 99% of the cross platform bullshit that
clouds every discussion we have about CL. Imagine having to compile perl
with just the raw C files. Imagine reading a document describing how to
compile perl with just the raw C files. That's what seems to happen with CL
software. I can't get an XML library, type (load "xml.lisp") and be off.
But, with LIAB, you CAN do that. Get the zip file, unzip it, cd liab, type
runlisp at the command prompt, and boom, you're on your way. Those
instructions will work for EVERY COMMON PLATFORM, bring up a consistent,
leverageable environment that can be used by others who really just want to
advocate CL and its use without having to go through the hell of setting it
up.
Yes, Emacs makes it a heavyweight installation, but frankly, nobody cares.
If they're willing to download Netbeans or Eclipse, this is nothing.
CL has a PACKAGING problem right now. The "lack of standards" is part of the
problem and leads to complexity. Eliminate that packaging issue, back it up
with software that works within it, and documents that leverage it, and you
have a powerful system for communicating what CL has to offer the planet.
IMHO, if there is any consolodation project at the implementation level (vs
the library level, like the ASDF stuff), LIAB is the way to go and start.
Get that going, ported, and practical, and use it as a baseline for later
projects. The time invested up front in getting LIAB/CLISP working
translates almost immediately to all of the platforms.
I appreciate the early work that was done with LIAB based on OpenMCL, and I
think that was a good proof of concept. But I think LIAB/CLISP is better
time invested for the most gain, IMHO.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> here is a Way of working with Lisp, and letting folks run off and
> discover their own Way is basically a waste of their time. The faster
> they get to the Lisp Way, the faster they See The Light. How many
> folks use a command line Smalltalk compiler?? Hands? Anyone?
>
> Today, that Lisp Way is central upon Emacs and its paradigms.
> So, Emacs must stay in LIAB, IMHO. Folks need to understand and learn
> the ENVIRONMENT centered around a CL system, and not simply the
> language itself. The language is only partially the benefit of the
> whole thing.
I read something to the effect that Emacs is not really an editor but a
Lisp development system. Of course the first thing that any
development system needs is a good editor. So RMS wrote enough lisp
primitives to support the kernel of an editor, then wrote the rest in
lisp, sort of bootstrapping the system within itself. Et voila, a lisp
development system that just happens to be the most powerful editor on
the planet. Considered in that light a lot of things about Emacs make
a lot more sense, to me at any rate.
"Will Hartung" <·····@msoft.com> writes:
> If you look at every single Lisp text out there, they pretty much
> handwave away the implementation, how to use it, how to load and run
> programs, etc. Because they're all different. "'Consult your System
> Administrator'? Wait, I'M the System Administror!" What they also do
> is they completely neglect interacting with the debugger,
> interacting with the Listener, "using" the whole environment. They
> skip all of that detail because they can't rely on a standard
> distribution. At least the Java books can rely on the Sun JDK, its
> configuration, and its use, even though there are several other JVMs
> and JDKs available.
>
> If LIAB took off with CLISP, Peter could easily put a chapter on
> Using LIAB in his book, knowing what libraries it will have, knowing
> how to start it, what keystrokes are bound in Emacs, the screen
> shots will be consistent, and his examples will WORK, whether you're
> running Windows, Unix, or Mac.
FWIW, I've already gotten in touch with Matthew and Mikel about ways I
might be able to use LIAB with my book. Because you are indeed correct
that this is an incredibly important thing to explain to new Lispniks
and also that it's quite hard since there's no standardization. So
anyone who wants to contribute to the LIAB project now has a better
than even chance of seeing their work stuffed on a CD that will
acompany a dead-tree book. For whatever that's worth. ;-)
-Peter
P.S. For a variety of reasons I'd actually like to see LIAB capable of
supporting more or less arbitrary Common Lisps. That is, it would be
great if from some LIAB web site[1] or from the various impl's web
sites you could download a LIAB installer for a given OS/Lisp impl
combo. In my Lisp utopia, commercial vendors would also support LIAB
by providing a LIAB packaging of their eval editions.
Given the uniform programming interface provided by SLIME I think the
remaining differences between Lisp impls would be in the noise. In
other words I think the benefits that would accrue from making LIAB
more universal would be greater than the drawbacks inherent in having
certain incompatibilites between different LIAB installations.
[1] That's something I imagine I could host on lispniks.com if no one
else wants to. After the book I hope to actually do something with
that site. Okay, back to writing.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp