Why Lisp is too hard for me to use
Christopher C. Stacy
I would like to relate the following comments and suggestions to the
kind people who maintain the various downloadable libraries for Common
Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.
1. Your software for utility libraries like networking,
FFI, OS interfaces, GUIs, and so on, is just what
is needed for people who want to use Lisp.
People expect this to be available out-of-the-box,
as it is (they believe, anyway) for all the other
major languages.
So it's great for Lisp that you are providing this.
2. Your software is TOO HARD to download and use.
My remarks will echo some of the sentiments that are occasionally
expressed by newbies here from time to time. I think the reasons
that you don't here these complaints continuously are:
1. Most people have already exhausted all their energy trying to
figure it out, and by the time they get this far, any interest
they had in using Lisp has already been exhausted.
They give up and just go away, and you never hear from them.
If they're not already Lispniks, they decide NOT to use Lisp.
2. Most people are afraid of appearing too be stupid to figure
this out. (And the Lisp community has somewhat of a reputation
for elitism, which makes it even worse.)
3. Aside from a small and definitely annoying minority,
most people don't want to appear to be ungrateful plaintive
"gimme" jerks who are demanding even more of your time.
Of course I'm not a newbie, and I don't care about (2), and I
am sure that my comments will be taken as the positive criticism
that it's meant to be, knowing that I am someone who appreciates
the work that folks have already put into these public-minded
endeavours.
So I will tell you that I fall into category (1).
By and large, this doesn't affect me personally very much,
because I do most of my work using commercial Lisp products
and using my own libraries that I've written over the decades.
But I can't figure out how to download all this free stuff.
Furthermore, speaking to a number of experienced (> 20 years)
programmers, including both some who are Lisp newbies and
potential converts, as well as some who have used Lisp,
I can safely assert that I am definitely not in the minority.
If you are trying to promote Lisp, you need to better "sell it",
in a very specific way. You need to make it easy enough to
obtain and get into -- without a lot of arcane knowledge of Lisp --
and without a lot of arcane knowledge of distributed software
development. Yes, I am sure you think that the procedures for
obtaining and installing this software is all standard, well-known,
well-documented knowledge. I'm here to tell you that it is not.
Today I've been trying for several hours to figure out how to
get CLOCC and use it on my RedHat Linux machine with CLISP.
This is by no means my first foray into this nightmare.
While doing this, I got a call from another guy trying
to do essentially the same thing with CMUCL. On Sunday I
had a a call from someone else in the same boat with Corman.
We're all lost.
It's just too hard.
There is too little documentation, or too much documentation,
and it's too hard to figure out where to go and what to read
and how to do it.
It is simply too overwhelming to figure out how to download
and install any of these packages.
The result is that I can't recommend to anyone that they
use these libraries (and transitively, any Lisp systems
other than Xanalys or Franz which have bundled their own
proprietary platform/utility solutions.)
What is needed is a simple installation and distribution system.
If such a thing exists, I don't know where it is, or how to find it.
I am not willing to spend hours researching Google, chasing down
links, making guesses, trying experiments, starting over, etc.
The following may help clarify the problem.
Here is a profile of your target audience:
* We DON'T understand SourceForge, we don't have or want CVS,
and, sorry, mostly we don't run Debian. We may or may not
have bzip, and we probably don't know even about it, if we do.
If you want your libraries, and Lisp, to be used only by people
who are willing to invest in those searching, locating, downloading
and installing ways of life, then you can stop reading right now
(and kiss the largest portion of the community goodbye).
* We DO have Linux or BSD or Windows: we understand tar files,
gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
(But we hate BSD ports. :)
Some of us have been downloading, compiling, installing,
and configuring large packages (such as the GNU suite
and Emacs) for years, before things like RPMs were invented.
But some of us can not deal with anywhere near that complexity,
and need to have a single "self-everything" installation.
Either way, we're not idiots.
(We wanted your libraries, right? :)
In other words, the ONLY acceptable solution is the SAME as
for all the other software that we use (for Perl, JAVA, and C).
There has to be a series of mostly self-installing download
distributions, and simple documentation to tell what we need.
I mean a series of tar files that includes the build scripts under
the standard native shell (eg. GNU Makefiles, or .BAT files).
Of course, an automatic installation system (such as RPM) would be better.
And there needs to be documentation for each system that tells you what
other tar'd systems will need to be installed first. Something like
CPAN would of course be the best, but that booting module itself needs
to come to us in the above self-contained manner.
If there are clear-cut solutions that already exist for these issues,
then they are just not sufficiently documented.
I am not looking for anyone to educate me here.
Please do not respond by telling me what I need to learn,
or how I missed the obvious documentation.
Rather, I am TELLING YOU what people are willing to do,
and what they can figure out with what you have provided
to them. Certainly you are under no obligation to do
anything, and whether you are interested in catering to
that community is entirely up to you. I'm just informing
you of the requirements of the major part of the universe,
should you happen to be interested.
This probably came off sounding rather nasty or harsh, but I would
like to again emphasize how nice it is for people to have put this
stuff together. The bottom line is that you are appreciated, but
if you want to know the truth: it's not good enough for most users.
But I didn't want to mince words, and I certainly hope you find
this to be useful feedback.
In any event, thanks again for all your hard work.
Rahul Jain
> * We DON'T understand SourceForge, we don't have or want CVS,
> and, sorry, mostly we don't run Debian. We may or may not
> have bzip, and we probably don't know even about it, if we do.
Unfortunately, Debian is the only way we can integrate the packages we
provide into the host package management system seamlessly, so you can
easily browse and install lisp libraries just like anything else you'd
want.
Also, it's far easier to put the basic bits needed to support this stuff
into the distribution when the distribution is maintained by a user
community. The people who package cmucl, etc for Debian are lispers and
use all these other libraries, too. It also helps that none of us have
much interest in ever maintaining a RedHat box over the long term.
So if someone who actually uses RedHat AND cares about these libraries
is interested in developing a solution for RedHat (we never needed to do
anything of the sort, as the solution is already intrinsic in debian),
please do so. We've been asking for years and have repeatedly only ever
received comments indicating that some people might use it, but no one
cares to create it. Please understand that we're not making money off
this stuff nor do we use the systems you want us to support, so there's
no reason for us to do it.
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Thomas F. Burdick
> 2. Your software is TOO HARD to download and use.
Several times, when I was still fairly new to Lisp, I tried getting
things from CLOCC, and had the same reaction you had. Since then,
I've stayed clear of it. Have you actually had a lot of difficulty
with non-CLOCC libraries?
> The result is that I can't recommend to anyone that they
> use these libraries (and transitively, any Lisp systems
> other than Xanalys or Franz which have bundled their own
> proprietary platform/utility solutions.)
>
> What is needed is a simple installation and distribution system.
>
> If such a thing exists, I don't know where it is, or how to find it.
> I am not willing to spend hours researching Google, chasing down
> links, making guesses, trying experiments, starting over, etc.
It's not prime-time yet, but there's a start; try asdf (a defsystem
replacement) and asdf-install:
http://www.cliki.net/asdf-install
The package list isn't what it should be, but it does seem to be
growing. Unfortunately it's currently SBCL-specific, but there's talk
of starting to ship CMUCL with it. There's no reason it couldn't be
ported to CLISP, either.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Eladio
I'm a newbie - rank amateur all the way, but grossly infected with the
lisp-bug, and I definitely echo the sentiment that the free-lisp environment
needs to be more easily accessible. It's not a question of dumbing it down for
the masses, but simply of making it user-friendly. My time is precious, and
frankly I'd rather crank out code than wasting hours just trying to install a
half-assed getopt-library.
How hard can it be to create a package management tool that downloads wanted
items plus dependencies, compiles the whole nine yards and dumps them in the
right directories and insert the appropriate lines in the config files if need
be? On FreeBSD, the basic CLOCC bundle is actually available in the port
system, and installed nicely. But it at the end of the compilation the
pkg-desc file had told me *exactly* how to call the bundle from lisp, I
wouldn't have wasted 2 days trying to get it right. (And #lisp was useless,
natch)
So I went to the CLOCC page to get the full cllib system, and finally figured
out I should download the nightly *snapshot* in order to get a tar-bundle. To
be brutally honest, that never crossed my mind because I figured snapshots
were caustic, volative development versions which would probably land me in
heaps of troubles if I even managed to get it installed in the first place.
So I untarred the whole nine yards, and now being somewhat familiar with the
manner in which /usr/local/lib/common-lisp was set up, I moved the clocc/
directory to there - on a hunch. Again, why didn't the README say that in
flaming red letters? "Warning: this is not a makefile like you know it from
C. Move the crap into your asdf:central-registry path - and here's how you
find that out via your lisp prompt. Blah blah blah." In fact, would it have
been too much trouble to create a script which automated the process?!
Of course, to actually USE the cllib package, you need to compile it - which
of course requires obscure knowledge of *metering*, *defsystem*, *asdf* and
other no-doubt fabulous utilities, which the newbie has never heard of
before. Result? Hours wasted in maddening frustration to get the stuff
*compiled*!
"2. Edit the logical hosts definitions in the file "clocc.lisp" in the
top-level directory according to your configuration."
Huh?! Logical hosts definitions?! I scanned like a obsessed for urls in that
file. The only thing that came somewhat close was the *clocc-root* variable,
but that was far from obvious.
"make clocc-top" prompted me with the following screed:
"Makefile", line 7: Could not find /clocc.mk
"Makefile", line 11: Missing dependency operator
"Makefile", line 12: Missing dependency operator
"Makefile", line 14: Need an operator
"Makefile", line 19: Need an operator
"Makefile", line 26: Need an operator
make: fatal errors encountered -- cannot continue
Again, hours squandered digging into the right files and trying to set the
right variables - to no avail, of course.
So finally I went gaga and decided to try the alternative route and followed
the instructions to compile it from within my lisp system. And lo-and-behold!
It worked! In both clisp and cmucl thank you very much!
Now, can anyone tell me why some shmock didn't bundle all those instructions
into a SINGLE, convenient function call - (load-clocc) or something?!
So now it was all compiled, and there was much rejoice. Then like the fool I
am, I figured I could actually savor my victory by checking out some functions
in my new-fangled libs:
[1]> (load (translate-logical-pathname "clocc:src;cllib;animals"))
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/animals.fas ...
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
1. Break [2]> :a
[3]> (load (translate-logical-pathname "clocc:src;cllib;base"))
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
1. Break [4]> :a
1. Break [6]> (load (translate-logical-pathname "clocc:src;cllib;html"))
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/html.fas ...
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
2. Break [7]> a:
AAAAAAAAAAAAARRRRRRGGGGGGHHHHHNNNNNNN!!!!! * Simpson-style tongue-rattle*
This can't be happening!!! What on EARTH does this mean?! So after 5 days of
playing around with the coolest programming language I've ever had the
pleasure to work with, I was back to square one. (Incidentally, if anyone has
a clue, I'm buying!)
Now I've downloaded lisp-utilities.ps, and plan on digesting it at the rate of
one tool per day, and then plunge into the whole set-up to tackle it
line-by-line. That is, once I've gotten defpackage to work with my personal
raft of baby-utilities and figured out the intrinsics of eval-when, and other
amigos in the HyperSpec.
Frankly guys, this is too much. You spend so much of your time and efforts to
divine these great utilities, libraries and implementations, but what's the
use if no-one but a handful of insiders get to use them?
I'm gonna stick to this like fly on shit until I got it down pat - but *only*
because I can't afford a commercial lisp system. Going through "Symbolic
Computation" was a revelation, and "OnLisp" is opening on a whole new world
for me. Lisp dazzles me every step of the way; it's like finally finding that
left-handed hammer in a world of righties. But daaayme, gurl; keepin' that
enthusiasm hot and steamin' is some piece of work.
Here's what could make the ride a tad more pleasant than the cold plunge into
the abyss I've experienced:
* Instructions when needed. I'm not asking for the Great American novel, just
a lousy roadmap. If your granny can't install it, it's too hard. But even
granny knows how to to use "cp", "make" and "cd".
* Tools with simple interfaces. Perl has 'perl -MCPAN -e 'install FOO', which
I turned into a simple shell alias; "cpan". Works like a charm. Lisp can't
be that much harder than Elisp, and I've *never* had problems getting new
Emacs packages. Asdf-install sounds great, as does cclan-get. But please,
make them just a tad more accessible.
* Basic tutorials. "Packages For Dummies" was unnecessarily complex. As a
newbie, I haven't yet wrapped my head around the concepts of symbols, so
puh-lease don't lecture me about it. You waste your time. What I want is
simple boilerplates showing me the rudiments, like a sample defpackage I
can just cut-and-paste and pluck in my own functions. That's MORE than
enough, and if I want more, I can always jump into the HyperSpec, or ask on
#lisp for the skinny.
* Basic roadmap-to-lisp. I don't care where YOU are coming from, or how much
cooler your resume is than mine. I want to know how to find my
way. Something like a Starter's Guide would be nice: read this, and this
and this in that order, create some projects, then install this gizmo and
learn about defsystem through this excellent tutorial. This presupposed the
existence of the above, of course.
I'm gonna make a little "diary of a newbie lispnik" of my little journey here,
and jot down all my woes and frustrations along the way, and make it available
on cliki or wherever. And I'll gladly create the little tools along the way
that would make life easier - or even possible! But it's damn hard to get over
the first few humps and even out of the starting block, so if more experienced
folks would like to pave the way for the next gen, be my guest. I do realize
you're all busy people, and I'm asking for a luxury. But it's a question of
whether you'd rather waste time on pathetic newbies who can't figure anything
out, or add a little more professionalism to the tools that already exist.
Thanks for starting this topic, Christopher.
And if anyone knows the answers to my lastest problem, please do speak out.
Oh - and how do you start Hemlock?! Thanks for your consideration.
--
o _ _ _
------- __o __o /\_ _ \\o (_)\__/o (_) -o)
----- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/ /\\
---- (_)/ (_) (_)/ (_) (_) (_) (_) (_)' _\o_ _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
Christophe Rhodes
> I would like to relate the following comments and suggestions to the
> kind people who maintain the various downloadable libraries for Common
> Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.
^^^^
(I'm replying essentially from the perspective of an SBCL implementor;
I understand that you're talking about libraries, but you also
mentioned that the transitive utility would lead you to not be able to
recommend use of free systems, so it affects we implementors as well.)
> 2. Your software is TOO HARD to download and use.
This is to an extent true. There are certainly certain spots of the
package space which baffle me, and I know I'm not alone. However...
> Today I've been trying for several hours to figure out how to
> get CLOCC and use it on my RedHat Linux machine with CLISP.
... to a certain extent I wonder how much you are suffering from this
particular effort, and extrapolating to the generality.
> It is simply too overwhelming to figure out how to download
> and install any of these packages.
^^^
SBCL has for several months provided a module for downloading and
installing third-party software, which is then "seamlessly" integrated
into the system (by which I mean that it is then available for use by
REQUIRE). It automatically chases dependencies; it verifies
authenticity (in as much as that is made possible by the local
configuration) and it's even documented in its own manual page.
Approximately 50 packages are available for download by this method as
I write; no doubt the quality and applicability varies, but I think
you do some library writers a certain disservice by accusing them of
not following your advice when in fact they are.
> What is needed is a simple installation and distribution system.
>
> If such a thing exists, I don't know where it is, or how to find it.
> I am not willing to spend hours researching Google, chasing down
> links, making guesses, trying experiments, starting over, etc.
I'm surprised that you dont mention CLiki, which I would have thought
would be the first port of call for free lisp on Unix. Did you in
fact try there, or was it an oversight? A CLiki search for "download
install" gets you asdf-install as the top hit.
> If there are clear-cut solutions that already exist for these issues,
> then they are just not sufficiently documented.
asdf-install is currently sbcl-only, because sbcl is the only
environment that distributes the seed client. It is a clear-cut
solution, but if you're not using sbcl then it won't work for you
right now. I can only express sympathy in that case.
> I am not looking for anyone to educate me here.
> Please do not respond by telling me what I need to learn,
> or how I missed the obvious documentation.
I'm asking you how you missed the obvious documentation... maybe it's
because you were tied to clisp? Implementations need to support such
a automatic download system at least minimally, by providing a simple
client with their distributions. This needn't be difficult, but
applying a certain amount of pressure to your distributor might help.
"Ask your vendor" as a response works even in the Free Software world.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Rainer Joswig
cst...@news.dtpq.com (Christopher C. Stacy) wrote:
> I would like to relate the following comments and suggestions to the
> kind people who maintain the various downloadable libraries for Common
> Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.
Christopher, nice posting. Thanks.
<...>
> By and large, this doesn't affect me personally very much,
> because I do most of my work using commercial Lisp products
> and using my own libraries that I've written over the decades.
I have tried to understand some of the current stuff and
its distribution model. Fortunately (or unfortunately one could say)
I now have with Mac OS X - with it having Unix underneath -
all this Unix stuff right here and can try it out.
> Today I've been trying for several hours to figure out how to
> get CLOCC and use it on my RedHat Linux machine with CLISP.
> This is by no means my first foray into this nightmare.
> While doing this, I got a call from another guy trying
> to do essentially the same thing with CMUCL. On Sunday I
> had a a call from someone else in the same boat with Corman.
I gave up early on CLOCC.
<...>
> The following may help clarify the problem.
> Here is a profile of your target audience:
>
> * We DON'T understand SourceForge, we don't have or want CVS,
> and, sorry, mostly we don't run Debian. We may or may not
> have bzip, and we probably don't know even about it, if we do.
Well, I learned to check out stuff from sourceforge CVS,
I have a Debian system for trying out some stuff and, yes,
I even have bzip. ;-)
<...>
> * We DO have Linux or BSD or Windows: we understand tar files,
> gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
> (But we hate BSD ports. :)
haha. ;-)
> Some of us have been downloading, compiling, installing,
> and configuring large packages (such as the GNU suite
> and Emacs) for years, before things like RPMs were invented.
> But some of us can not deal with anywhere near that complexity,
> and need to have a single "self-everything" installation.
> Either way, we're not idiots.
> (We wanted your libraries, right? :)
Just some thoughts:
Let's say we have three categories of software:
- commercial
we pay bucks and expect it to work. and it better works,
otherwise we call the support and complain. Though, the
bigger days of commercial Lisps are over - with a
few exceptions.
- university
probably the software is used in some research
projects. as long as that is the case it may work.
if the project is over, good luck. Nowadays
Lisp (Common Lisp) is mostly non-existent at
universities (which says more about the state
of the universities than about Common Lisp).
- hobbyist
currently a lot of the Lisp software that is new falls in
this category. The reason is that since a few years there
is growing interest in Common Lisp from an 'underground'.
Still there are few jobs and few commercial uses, since the
'industry' hasn't (yet) re-discovered Lisp yet. so it
is still more a 'sub-culture' - an underground. You see
Compiler hackers. Lots of them. a few years ago I feared
that CMUCL would die or just stayed on one platform. Now
we have quite a lot Lisp people hacking on Compilers.
More than ever.
What still often is lacking is packaging (yes, you are right).
We have more compilers, but we lack software engineering skills,
more and better libraries (it may need another five years
to get there) and, well, and applications (other than Lisp
compilers compiling itself or other Lisp compilers ;-) ).
Some projects already started - often for web stuff.
Or McCLIM, the reimplementation of CLIM.
It is still experimentation time.
Some people are caring for packaging issues, so SBCL has
been created as an answer to CMUCL's difficult
handling at that time. Installation of CMUCL on debian
is easy. I installed it with apt-get, copied a tar
of CL-HTTP on the machine, loaded the cmucl start file
for CL-HTTP and got a webserver on that machine in Lisp.
(Btw., did I mention that probably the single most
important (IMHO) project now is McCLIM? Oh, and that
a few more hackers would definitely help?)
To sum it up, yes, you are right. it is rough sometimes.
We are very early in the beginning of a (small) Lisp comeback.
Things should get better though, it may take a few years...
Maybe some of the old Lisp hackers should make sure
the old tricks are not forgotten...
tony
trying to "learn lisp". i'm using the Xanalys and Franz products on
w2k and redhat 9.0 as well as the CLISP downloads. while i like the
tools that come with the commercial products, i'm trying to grow my
understanding of the programming process as a whole (i haven't been
programming for long and am trying to wrap my aged brain around these
concepts) and feel that getting to the level of interaction necessary
with the freely distributed products will be beneficial. i also don't
have the scratch to pay for the unrestricted commercial products yet.
that being said...
i'd have to agree that the process has proven somewhat difficult. i
tried to get the Garnet toolkit up and running and found a paucity of
understandable (to my simple mind) documentation on how to make the
damned thing work. as a result, my attempts of installing Garnet on
Redhat led to a break of the Lispworks and CLISP installs. I had to
rebuild the system (OS and such) from scratch... which is ok 'cause
every attempt leads me to more knowledge.
i know that the development has ceased on Garnet. i also know there
is documentation that comes with the product. most of what i've been
able to extract from that documentation has to do with the tools
available and not about installation related issues. i also now know
that CLISP comes with MIT-CLX and NEW-CLX as well as an FFI and socket
interfaces. i was able to find a website that has the manual for CLX
available as an http interface. so...
again, while i agree that this can prove itself a frustrating process,
i believe that there is gold on the other side and am willing to
accept the frustration... for now.
peace
Mario S. Mommer
> get CLOCC and use it on my RedHat Linux machine with CLISP.
> This is by no means my first foray into this nightmare.
> While doing this, I got a call from another guy trying
> to do essentially the same thing with CMUCL. On Sunday I
> had a a call from someone else in the same boat with Corman.
This is very strange. I have installed CLOCC a few times and I have
never had any problems. Did you try the included readme? That is all
the documentation I ever needed.
> We're all lost.
>
> It's just too hard.
I can think of at least one alternative explanation.
Thomas F. Burdick
in the late 90's. And the situation's still improving.
Eladio <eladio_...@yahoo.com> writes:
> I'm a newbie - rank amateur all the way, but grossly infected with the
> lisp-bug, and I definitely echo the sentiment that the free-lisp environment
> needs to be more easily accessible. It's not a question of dumbing it down for
> the masses, but simply of making it user-friendly. My time is precious, and
> frankly I'd rather crank out code than wasting hours just trying to install a
> half-assed getopt-library.
I'd recommend that you get SBCL. Dan Barlow replaced his old guide to
getting started on CMUCL with a new one for SBCL:
http://ww.telent.net/lisp/according_to/
This should be enough to get you mostly where you need to be.
"... according to" covers library installation, which is as easy as it
is with Perl. Not everything is available this way, but there should
be enough to get you started. You can tackle other libraries on a
case by case basis by asking on their lists. Once you get them
working on your system, be a part of the solution: make that library
asdf-installable.
> Here's what could make the ride a tad more pleasant than the cold plunge into
> the abyss I've experienced:
>
> * Instructions when needed. I'm not asking for the Great American novel, just
> a lousy roadmap. If your granny can't install it, it's too hard. But even
> granny knows how to to use "cp", "make" and "cd".
There are very good documents for getting started with CMUCL and SBCL.
Check their websites and the CLiki.
> * Tools with simple interfaces. Perl has 'perl -MCPAN -e 'install FOO', which
> I turned into a simple shell alias; "cpan". Works like a charm. Lisp can't
> be that much harder than Elisp, and I've *never* had problems getting new
> Emacs packages. Asdf-install sounds great, as does cclan-get. But please,
> make them just a tad more accessible.
SBCL ships with asdf-install, and CMUCL probably will soon.
> * Basic tutorials. "Packages For Dummies" was unnecessarily complex.
Uh, yeah, the "for complete idiots" part of that title is kind of a
joke.
> As a
> newbie, I haven't yet wrapped my head around the concepts of symbols, so
> puh-lease don't lecture me about it. You waste your time. What I want is
> simple boilerplates showing me the rudiments, like a sample defpackage I
> can just cut-and-paste and pluck in my own functions. That's MORE than
> enough, and if I want more, I can always jump into the HyperSpec, or ask on
> #lisp for the skinny.
>
> * Basic roadmap-to-lisp. I don't care where YOU are coming from, or how much
> cooler your resume is than mine. I want to know how to find my
> way. Something like a Starter's Guide would be nice: read this, and this
> and this in that order, create some projects, then install this gizmo and
> learn about defsystem through this excellent tutorial. This presupposed the
> existence of the above, of course.
>
These exist.
> I'm gonna make a little "diary of a newbie lispnik" of my little journey here,
> and jot down all my woes and frustrations along the way, and make it available
> on cliki or wherever.
Ug. There are tons of getting-started guides. The problem is making
them easy to find for newbies and/or getting newbies to ask, "I want to
get started, where is the HOWTO that tells me how to do this?"
> And if anyone knows the answers to my lastest problem, please do speak out.
(I don't use CLOCC)
> Oh - and how do you start Hemlock?! Thanks for your consideration.
Go to CLiki. Type "hemlock" in the search. Click on the third link,
GettingStartedWithHemlock.
Zach Beane
> Eladio <eladio_...@yahoo.com> writes:
>
>> I'm gonna make a little "diary of a newbie lispnik" of my little
>> journey here, and jot down all my woes and frustrations along the
>> way, and make it available on cliki or wherever.
>
> Ug. There are tons of getting-started guides. The problem is making
> them easy to find for newbies and/or getting newbies to ask, "I want to
> get started, where is the HOWTO that tells me how to do this?"
Ug seconded. It's tempting, as a newbie, to write about every false
start and blind alley you wandered down while looking for the right
solution. A truly useful document would apply the benefit of hindsight
and expose the proper path in a way that not only helps the reader in
a specific case, but also provides insight useful to guide futher
intuition when venturing into the unknown.
The "newbies teaching newbies" (or "blind leading the blind") idea
always reminds me of this bit by Erik Naggum:
I recently reviewed a book in which the author could only be
understood to apologize for his lack of mastery of the subject when
he chatted endlessly about how hard it was to linearize the
material and where he used more promises of what was to come and
repetitions of what he had discussed than actual new information in
each paragraph, how this and that feature in the topic he discussed
"is not easy" to use and understand. It was torture to read and
try to lift it to some readable level.
Zach
Thomas F. Burdick
> i'd have to agree that the process has proven somewhat difficult. i
> tried to get the Garnet toolkit up and running and found a paucity of
> understandable (to my simple mind) documentation on how to make the
> damned thing work. as a result, my attempts of installing Garnet on
> Redhat led to a break of the Lispworks and CLISP installs. I had to
> rebuild the system (OS and such) from scratch... which is ok 'cause
> every attempt leads me to more knowledge.
Wow, I don't know what you did, but anything you do with compiling
Garnet should only affect things in Garnet's directory. :-)
I'm still using Fred Gilham's distribution of Garnet, but I don't
imagine much is different in the sourceforge Garnet. There is good
documentation in the doc/ directory. I found the build scripts in the
toplevel directory pretty self-explanatory, but I've only used Garnet
with CMUCL. If you have specific questions, ask here or on the garnet
list.
Eladio
> FWIW, it's waaaaay easier to find and install things now than it was
> in the late 90's. And the situation's still improving.
Yeah, that's the open source movement for you. Stuff that broke your teeth 3
months ago suddenly fly by wire. But it's still frustrating while it goes
on. *sigh*
> I'd recommend that you get SBCL. Dan Barlow replaced his old guide to
> getting started on CMUCL with a new one for SBCL:
>
> http://ww.telent.net/lisp/according_to/
Wonderful! I've been on #lisp all day, and go the same advice. It still gives
me heaps of trouble since asdf-install doesn't seem to be installed by default
on FreeBSD, but I'm working on it. At least SBCL focuses the problem down a
tad. Thanks for the link too!
> This should be enough to get you mostly where you need to be.
> "... according to" covers library installation, which is as easy as it
> is with Perl. Not everything is available this way, but there should
> be enough to get you started.
That's all I'm asking for!
> Once you get them working on your system, be a part of the solution: make
> that library asdf-installable.
Great idea, I'll do that. In fact, I've more or less committed myself to put
my shoulder to the wheel and compile a couple of howtos for others in the same
boat.
>> RE. Lack of Instructions.
> There are very good documents for getting started with CMUCL and SBCL.
> Check their websites and the CLiki.
The problem is not firing up the lisp systems - they all work. There's also
tons of free, top-notch and accessible material out there for mastering the
basics. The problems arrive the second you try to write your first application
and it dawns on you that you have nothing along the lines of "getopt",
"configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
cliki, cclan, cclib and all those great libraries jam-packed with goodies to
sink your teeth into... and find that you spend days on end to move
forward. Hence the frustration.
I have yet to find anything remotely ressembling a manual for asdf, let alone
instructions for actually *fixing* the problems you encounter. So I'm supposed
to type:
(require 'asdf)
(require 'asdf-install)
(asdf-install 'cliki) ; or whatever
Okay. Peace of cake. But clisp, cmucl, and sbcl ALL break down at step one, so
even though I have an instruction, it flunks in practice, even though the
system I'm on is one of the most widespread of its kind. There's no way to
really solve the problem as a newbie, except by whining about it to the
pros. Again!
Here's an example of just one such crazy situation, from earlier today:
;;; loading #P"/usr/local/lib/common-lisp/asdf/sbclfasl/asdf.fasl"
; loading system definition from
; #P"/usr/local/lib/common-lisp/system-registry/port.asd" into
; #<PACKAGE "ASDF2640">
; registering #<SYSTEM #:PORT {483A90D1}> as PORT
debugger invoked on condition of type SIMPLE-ERROR in thread 12767:
Don't know how to load ASDF
Crazy, innit?! First it loads asdf.fasl successfully - and then I'm told I
doesn't know how to load it! So I sashay around mailing lists, irc and the
archives of this newsgroup and constantly wind up empty handed. So either the
information out there is obsolete, or the applications were written for
"insiders". But at least by concentrating on SBCL I can now contact people
who're familiar with that particular system, and maybe find some FreeBSD
mavens among them. That always helps!
I'd LOVE to do something about this situation - and I will, once I got at
least a basic system up, but it ain't exactly a gas while it lasts! I was
thinking of creating a tutorial tackling problems newbies face, such as:
* Setting Up Your Lisp System (clocc/cclib, how asdf-install works,
troubleshooting)
* Setting Up Emacs (ilisp basics)
* Packages 101 (plug-and-rock defpackage, how to use asdf)
* Cllib/cliki lib Tutorials (basic stuff like getopt, configuration parser,
curl, cgi, xml etc)
I don't wanna step on the toes of the cl-cookbook (which is fantastic), but
provide some salient examples for the newbies who find plunging into libraries
from the get-go a little too sanity-wracking.
Personally, I've found lisp tutorials and guidelines every easily. But I still
think this information and tools need to be at least A) updated for non-Debian
systems B) available for existing libraries.
> SBCL ships with asdf-install, and CMUCL probably will soon.
Yeah, that's great. If you're on Debian. I have SBCL running full speed ahead,
but no asdf-install - and I'm sure I'm not the only one. That's a major
oversight, and it needs to be remedied. Sounds fabulous, though! *daydreams*
> > * Basic tutorials. "Packages For Dummies" was unnecessarily complex.
>
> Uh, yeah, the "for complete idiots" part of that title is kind of a
> joke.
Well, they're actually great. I've been absolutely floored every time I've
started a tutorial, and discovered some new aspect of lisp. It blows my mind,
quite frankly. But I think we need some stuff written for the newbies - even
those who use lisp as a first or second language - after PHP, like myself. I'm
talking holding-hands stuff: "do A, B and C - and voila, your mojo
happens". Right now, it's "if you're on Debian, and asdf is perfectly
installed and you're lucky enough to have asdf-install running, THEN type A, B
and C...".
> > Something like a Starter's Guide would be nice: read this, and this
>
> These exist.
And I've read them. Or something *like* them. But they virtually all function
as *portals* glumming up a load of resources - many written in dry-ass
academic language, with the occassional gem on little details loop or equality
tossed in. But if they fulfilled the role I outlined above - why am I sitting
here and whine like a baby because I can't load in a single external library?
The ride needs to be less bumpy - especially for the non-Debian guys. I
actually nursed the idea to switch OS today, but that would only mean I'd have
even *more* to learn! All I want is being able to finish my first
baby-project. * WAAAH! *
> Ug. There are tons of getting-started guides. The problem is making
> them easy to find for newbies and/or getting newbies to ask, "I want to
> get started, where is the HOWTO that tells me how to do this?"
You'll have to excuse me. Like I said earlier, getting off the ground with
lisp is not really the problem. But there's more to being a newbie than just
figuring out how to access elements in a hash. There's the whole programming
environment to master, and of course the "standard" libraries, without which
the newbie is in for a world of hurt.
The "getting-started" guides completely neglect that aspect of the newbie
period, which is the time where you're ready to kick off your first few
projects and play around with the language in earnest. In PHP, I was
productive from day 1, and whenever I wished to learn something new, like
sockets or xml parsing, I just downloaded a library and *presto* - a whole new
world opened up. In Lisp, you thrash through the tutorials, go "OOOOH!",
"WOW!", "Awesome!", "Honey, you gotta *see* this!!" for a week... and then you
splatter against the window pane like a bug. Again. And again. And again.
Oh well, nobody stays newbie forever!
> > Oh - and how do you start Hemlock?! Thanks for your consideration.
>
> Go to CLiki. Type "hemlock" in the search. Click on the third link,
> GettingStartedWithHemlock.
Success! Success at last!!! Thank you *so* much! I get the feeling I'll spend
the whole day tomorrow on cliki, hehehe! Finally a little victory to round off
the day. Sorry for the verboseness of this post, by the by - and merry
Christmas!
Eladio
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> Ug seconded. It's tempting, as a newbie, to write about every false
> start and blind alley you wandered down while looking for the right
> solution.
Hmmm... damn good point. I hate that too - especially on matters in which I've
gained just a modicum of insight above the author's - and the latter turns out
to be woefully mistaken.
> A truly useful document would apply the benefit of hindsight
> and expose the proper path in a way that not only helps the reader in
> a specific case, but also provides insight useful to guide futher
> intuition when venturing into the unknown.
You're absolutely right. I'm still gonna make a log of my own mistakes, and
then keep it for later. In practice, the problem is usually that by that time,
most people no longer care about the newbies because they got their hands full
thanks to their own hard-earned skills.
Guess I was just going off my rockers after a long day of going nowhere fast...
> The "newbies teaching newbies" (or "blind leading the blind") idea
> always reminds me of this bit by Erik Naggum:
>
> I recently reviewed a book in which the author could only be
> understood to apologize for his lack of mastery of the subject when
> he chatted endlessly about how hard it was to linearize the
> material and where he used more promises of what was to come and
> repetitions of what he had discussed than actual new information in
> each paragraph, how this and that feature in the topic he discussed
> "is not easy" to use and understand. It was torture to read and
> try to lift it to some readable level.
That's a great quote, but personally I think the style and incompetence of the
author in this particular case has more to do with why he got put off by the
material. I was never talking about drawing up an exhaustive account of
technicalities I'm way too underqualified to expound on in the first place. That
would be unprofessional and counter productive.
What I had in mind was something along the lines of www.freebsddiary.org, and
other sites which were started by frustrated starters who decided to sum up
proven techniques of what little they *did* know, and provide a place where
others could post their hard-earned experiences too. Helped me out a ton in the
past.
Cliki seems to be the perfect medium for that approach, but until today I had no
idea that there were actual tutorials on the site, like the Hemlock hint Thomas
pointed me to.
Don Geddis
> 2. Your software is TOO HARD to download and use.
> and, sorry, mostly we don't run Debian. We may or may not
> have bzip, and we probably don't know even about it, if we do.
> gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
> (But we hate BSD ports. :)
It's too bad you rule out Debian, because CMUCL is especially easy there.
But OK, I'll give it a try. Headed to Google, typed "CMUCL". First link is
www.cons.org/cmucl/
the home page of CMUCL. Index bar on the left-hand side has an item called
"Download" which takes me to
http://www.cons.org/cmucl/download.html
This mentions a number of mirrors for sources and binaries. But that's too
difficult for you. The second section says "Alternative binary distributions".
No, don't want FreeBSD...no, you've already rejected Debian...apparently
there's some "alien" thing that will convert a Debian .deb to an .rpm, but
perhaps that's too difficult and you don't want to bother. Ah! Here goes.
The third "alternative" link is that CMUCL is "available in RPM format"
thanks to Miles Egan. Sounds great! Click on the link to
http://www.caddr.com/lisp/
and you find source and binary Redhat RPMs for CMUCL 18c, 18d, and 18e.
That took less than 30 seconds. Seems like exactly what you were asking
for. How hard did you try?
> I am not looking for anyone to educate me here.
> Please do not respond by telling me what I need to learn,
> or how I missed the obvious documentation.
I'm not sure how anyone can help you, then. I suppose you're not looking for
help, but merely reporting on observed problems in user-land.
Perhaps. But since there _are_ solutions, just like you want, perhaps you
can be more constructive and say how to improve the solutions that exist so
that users aren't as confused as you believe they are today.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
No man ever steps in the same river twice, for it's not the same river and he's
not the same man. -- Heraclitas
tony
> yel...@yahoo.com (tony) writes:
>
> > i'd have to agree that the process has proven somewhat difficult. i
> > tried to get the Garnet toolkit up and running and found a paucity of
> > understandable (to my simple mind) documentation on how to make the
> > damned thing work. as a result, my attempts of installing Garnet on
> > Redhat led to a break of the Lispworks and CLISP installs. I had to
> > rebuild the system (OS and such) from scratch... which is ok 'cause
> > every attempt leads me to more knowledge.
>
> Wow, I don't know what you did, but anything you do with compiling
> Garnet should only affect things in Garnet's directory. :-)
i tried to figure out what i'd done. based on my reading of the
docs, i thought it an easy process ("run the before-compile, then
run..."). i've a machine i can do another test build on. i will
certainly ask questions if need be. thanks for the help.
Christopher C. Stacy
Don> How hard did you try?
How nice for you.
Average time spent by the people I talked to: three to
six hours before they gave up.
Christopher C. Stacy
Don> solutions that exist so that users aren't as confused as you
Don> believe they are today.
What you have done, Don, is to recite to me your experience
in solving a different problem than the one that I reported.
Then you suggested I should change operating systems, and
then gave a wisecrack about how it took you thirty seconds
to do this, how perhaps I didn't try very hard, or there's
something wrong with me, or perhaps I could be "more constructive"
and say how to improve the solutions.
I was not trying to download CMUCL, but rather certain libraries;
changing operating systems is not an option; and I did offer some
specific suggestions as to what kind of download procedures and
formats would be more palatable.
I don't plan on reading any more of your messages.
Paolo Amoroso
> (Btw., did I mention that probably the single most
> important (IMHO) project now is McCLIM? Oh, and that
> a few more hackers would definitely help?)
I agree on the importance of McCLIM, which is in a usable state. But
in a thread where Lisp novices are worried about the difficulties of
installing and running libraries, I wouldn't recommend it to the faint
of heart :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso
> I'm a newbie - rank amateur all the way, but grossly infected with the
> lisp-bug, and I definitely echo the sentiment that the free-lisp environment
> needs to be more easily accessible. It's not a question of dumbing it down for
> the masses, but simply of making it user-friendly. My time is precious, and
> frankly I'd rather crank out code than wasting hours just trying to install a
> half-assed getopt-library.
I understand yours and Christopher's frustration. But I think that the
explanation of why Lisp may currently be hard to use is very simple,
and you have hinted at it: the developers' time is precious as well.
There's no deliberate plan by the developers to hide information to
novices. It's just that there is not enough volunteer labor.
The bottom line is that things are improving in the Lisp world, even
in library packaging, but not as fast as in other language
communities.
> How hard can it be to create a package management tool that downloads wanted
> items plus dependencies, compiles the whole nine yards and dumps them in the
> right directories and insert the appropriate lines in the config files if need
> be? On FreeBSD, the basic CLOCC bundle is actually available in the port
I suspect it's not trivial.
> cooler your resume is than mine. I want to know how to find my
> way. Something like a Starter's Guide would be nice: read this, and this
> and this in that order, create some projects, then install this gizmo and
> learn about defsystem through this excellent tutorial. This presupposed the
> existence of the above, of course.
A few starting points for understanding the Lisp equivalent of Unix
`make', i.e. DEFSYSTEM tools (Google if necessary). Read:
- Kent Pitman's article "The Description of Large Systems", available
at his web site
- the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
- the README file of Dan Barlow's `asdf' tool
> Oh - and how do you start Hemlock?! Thanks for your consideration.
Evaluate these expressions at the CMUCL prompt:
(require :clx)
(require :hemlock)
(ed)
The Hemlock manual, available at the CMUCL site in the documentation
section, provides more details. Also check the Hemlock page at CLiki.
rydis
> changing operating systems is not an option; and I did offer some
> specific suggestions as to what kind of download procedures and
> formats would be more palatable.
I know you don't really want /help/, per se, and I can understand that
the difference in installation procedures for different libraries
might throw one for a spin; your initial post is, IMO, a very fine
problem statement. It's being worked on, as others have written;
asdf-install is, though not yet deployed for very many Common Lisp
implementations, quite a bit on the way to CPAN goodness (personally,
I have problems with CPAN, but I really don't know Perl, and am just
installing software for others).
I find CLiki invaluable in that it contains links to lots of cool
stuff, but that isn't the problem you're talking about, though it is a
great solution of a different problem (finding all that good stuff).
The main reason /I/ see why the same approach as all other software
uses (makefiles, shell scripts and .BAT-files) isn't widely used is
that most free CL implementations are more or less in a state of
flux. Stuff changes, in slight and sometimes incompatible ways. If
there is a makefile or a shell script, it's often (from what I've
seen) most difficult to fix small stuff, and even to see what the
problem is. If you use a in-Lisp approach (be it MK:DEFSYSTEM, ASDF or
some load-/compile-file written to suit the task at hand), it's a lot
easier to fix and diagnose slight breakage, /if/ you know more than
just a bit about your system. With makefiles, it's a lot more bother,
and especially so for a novice (with the particular system). At least,
that's /my/ experience. (I'd like to write something about it being
nicer to get "Stuff broke; these are the parts, what now?" than "Stuff
broke. I threw it away. Fix and start over, or give up/wait for the
next release.", but most people know that, and I can't put it in a
non-obnoxious way, I'm afraid.)
People (and I) have mentioned asdf-install; another project that
sounds like it'll really fit your description is Dan Barlows cirCLe,
if it gets off the ground. (I think, actually, asdf-install is a part
of the infrastructure for that bigger project.)
I'm mostly on Debian/x86, so I don't see a lot of the problems. I also
primarily use CMUCL (mostly the snapshots, not the Debian-supplied
version), so I do see some. Most of the time, I don't find fixing
the problems that arise very hard. I'd like to help. I really don't
know how, though. Major infrastructure is a bit beyond me, being a
long time newbie, not involved in any real project, and usually
woefully behind in the newsgroups and mailing lists.
This might be silly, but what are your suggestions as to what I do to
make the situation less unbearable? English isn't my first language,
but I think I can write understandably. I do know a fair bit about CL,
un*x systems, and shell scripting. Should I try to start writing
alternative installation documents? Alternative installation scripts?
Package up a CMUCL-extra-extras, with pre-compiled modules you'd drop
in $CMUCLLIB? Try harder to stay afloat with mailing lists and
newsgroups, and actually post rather than just read, even though my
"solutions" might not be the cleanest or the Right Thing (since I have
yet to really understand MK:DEFSYSTEM or ASDF)?
The preceding paragraph does seem a bit provocative. It isn't actually
meant to be. It's /definitely/ not meant as an attack. I would like to
know what I, as a mere user, could do. On a case-by-case basis I'm
fairly certain I can help people with installation. Actually telling
people how to /use/ the libraries/apps might be a different issue.
The main problem I've always seen with CL libraries is the sheer
profusion of different solutions to problems, and no actual de facto-
standard. Want to do a GUI? There are dozens of toolkits, in differing
states of either flux or decay, often two or three different versions
of the more interesting ones. XML libraries, HTML generators or
frameworks, web servers, regexp libraries, defsystem variants...
There doesn't seem to be enough of us to make one of either a clear
winner, or even "the most popular". Yet. I /do/ think things will
stabilize, soonish. It's kind of ironical having early adopter-trouble
with a language as old as Lisp, but I think that's what we're seeing.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that
is beautiful. -- Neal Stephenson, _In the Beginning was the Command
Line_
Pascal Bourguignon
> > Oh - and how do you start Hemlock?! Thanks for your consideration.
>
> Evaluate these expressions at the CMUCL prompt:
>
> (require :clx)
> (require :hemlock)
> (ed)
>
> The Hemlock manual, available at the CMUCL site in the documentation
> section, provides more details. Also check the Hemlock page at CLiki.
[pascal@thalassa pascal]$ cmucl
; Loading #p"/local/users/pascal/.cmucl-init.lisp".
CMU Common Lisp 18d, running on thalassa
Send questions to cmucl...@cons.org. and bug reports to cmuc...@cons.org.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (require :clx)
; Loading #p"/local/languages/cmucl/lib/cmucl/lib/subsystems/clx-library.x86f".
[GC threshold exceeded with 2,005,376 bytes in use. Commencing GC.]
[...]
[GC will next occur when at least 4,855,200 bytes are in use.]
T
* (require :hemlock)
; Loading #p"/local/languages/cmucl/lib/cmucl/lib/subsystems/hemlock-library.x86f".
[GC threshold exceeded with 4,855,496 bytes in use. Commencing GC.]
[...]
[GC will next occur when at least 8,693,592 bytes are in use.]
T
* (ed)
Parse error in namestring: Expecting a file name, got #\..
home:.hemlock-init
^
Restarts:
0: [CONTINUE] Return NIL from load of "home:.hemlock-init".
1: [ABORT ] Return to Top-Level.
Debug (type H for help)
(COMMON-LISP::EXPECTING "a file name" ((#\. . 5) ("HEMLOCK-INIT" . 6)))
Source:
; File: target:code/pathname.lisp
; File has been modified since compilation:
; target:code/pathname.lisp
; Using form offset instead of character position.
(ERROR 'NAMESTRING-PARSE-ERROR
:COMPLAINT
"Expecting ~A, got ~:[nothing~;~:*~S~]."
:ARGUMENTS
...)
0]
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ ( . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postm...@sco.com ******************
Christopher C. Stacy
mr> I know you don't really want /help/, per se, and I can understand that
mr> the difference in installation procedures for different libraries
mr> might throw one for a spin; your initial post is, IMO, a very fine
mr> problem statement. It's being worked on, as others have written;
mr> asdf-install is, though not yet deployed for very many Common Lisp
mr> implementations, quite a bit on the way to CPAN goodness (personally,
mr> I have problems with CPAN, but I really don't know Perl, and am just
mr> installing software for others).
Some of the things I've read here are very encouraging!
(I've been programming almost exclusively in Lisp full-time for the
past 23 years, so I know that if I find some of these things rather
frustrating, it's gotta be terribly discouraging for new people.
And indeed that's what I hear from almost everyone I've turned
on to using Common Lisp in the last couple of years.)
(I think it's great that people are volunteering on this stuff.
I wish I had time to work on it, but I pretty much used up
this week's free time on just filing that marketing-oriented
"bug report".)
Friedrich Dominicus
> Parse error in namestring: Expecting a file name, got #\..
> home:.hemlock-init
> ^
Yeah, I posted about this a few days ago. CMUL can not handle a dot in
logical-pathnames. I tried to find a way to report this but just found
the mailings lists....
touch $HOME/hemlock-init
will help you go over this hurdle.
This thing in which I agree with you is that many of the available
packages are difficult to install, and that they are often lacking
documentation. On the other hand using the right "Distribution"
(Debian of course) helps quite a bit ;-)
Regards
Friedrich
Friedrich Dominicus
> cst...@news.dtpq.com (Christopher C. Stacy) writes:
>> Today I've been trying for several hours to figure out how to
>> get CLOCC and use it on my RedHat Linux machine with CLISP.
>> This is by no means my first foray into this nightmare.
>> While doing this, I got a call from another guy trying
>> to do essentially the same thing with CMUCL. On Sunday I
>> had a a call from someone else in the same boat with Corman.
>
> This is very strange. I have installed CLOCC a few times and I have
> never had any problems. Did you try the included readme? That is all
> the documentation I ever needed.
Well the documentation at the moment states:
> INSTALLATION OF CLOCC
>
> You have two options:
> + using GNU Make or
> + doing everything from your lisp prompt
> It is entirely up to you what path to take.
>
> * Using GNU Make (<http://www.gnu.org/software/make/make.html>)
>
> 1. Set the environment variable LISPTYPE appropriately
> (currently supported types: acl43, acl5, clisp, cmucl, gcl).
> Set the environment variable CLOCC_DUMP to the space-separated list of
> your lisps for which you want to dump images.
> E.g., ACL/Linux trial version cannot dump images,
> and CMU CL dumps multi-megabyte images,
> so you might want to set CLOCC_DUMP to "clisp",
> and change the value of LISPTYPE according to the implementation
> you are using at the moment.
>
Seems reasonable let's do it:
export LISPTYPE=cmucl
> 2. Edit the logical hosts definitions in the file "clocc.lisp" in the
> top-level directory according to your configuration.
>
Oh well, at least I have to know what logical hosts are. Remember we
are talking about Lisp beginners.
Let's see what we find:
this:
> (defvar *clocc-root*
> #-(or win32 winnt mswindows) "/home/frid/lib/cl/clocc/"
> #+(or win32 winnt mswindows) "d:/gnu/clocc/"
> "*The root CLOCC directory.")
>
> (setf (logical-pathname-translations "clocc")
> `(("src;defsystem;*"
> ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*"))
> ("src;defsystem;*.*"
> ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*.*"))
> ("src;defsystem-3-x;*"
> ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*"))
> ("src;defsystem-3-x;*.*"
> ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*.*"))
> ("**;*" ,(concatenate 'string *clocc-root* "**/*"))
> ("**;*.*" ,(concatenate 'string *clocc-root* "**/*.*"))))
>
Well 2 states I should change the logigical hosts definition. But
that's wrong. I have to change *clocc-root*. If I mess around in the
logical-pathnames-translations what do you think will happen?
OK assume that i adjusted *clocc-root* properly.
Now we're reaching this:
> 4. You should be able to compile any package in CLOCC now by typing
> "make system" in the appropriate directory.
> E.g., if you want to compile "PORT" (the cross-implementation
> portability system), you do
> $ cd src/port
> $ make system
>
Just let us try:
cd src/tools/ansi-test;
make system
make: *** Keine Regel, um »system« zu erstellen. Schluss.
well let's try something else
cd src/tools/clunit
/home/frido/lib/cl/clocc/bin/run-lisp -i /home/frido/lib/cl/clocc/clocc-top -i clunit.system
; Loading #p"/home/frido/lib/common-lisp/clocc/clocc-top.x86f".
Warning: MAKE also exports the following symbols:
(HARDCOPY-SYSTEM COMPILE-SYSTEM
*COMPILE-DURING-LOAD*
*FILES-MISSING-IS-AN-ERROR*
AFS-SOURCE-DIRECTORY
COMPILER-TYPE-TRANSLATION
DEFSYSTEM
LOAD-SYSTEM
DEFINE-LANGUAGE
FILES-IN-SYSTEM
OOS
UNDEFSYSTEM
*MULTIPLE-LISP-SUPPORT*
*DONT-REDEFINE-REQUIRE*
*BIN-SUBDIR*
ADD-REGISTRY-LOCATION
DESCRIBE-SYSTEM
*RELOAD-SYSTEMS-FROM-DISK*
*DEFSYSTEM-VERSION*
*MINIMAL-LOAD*
DEFINED-SYSTEMS
SYSTEM-SOURCE-SIZE
FIND-SYSTEM
AFS-BINARY-DIRECTORY
*CENTRAL-REGISTRY*
EDIT-SYSTEM
FILES-WHICH-NEED-COMPILATION
CLEAN-SYSTEM
SOFTWARE-TYPE-TRANSLATION
MACHINE-TYPE-TRANSLATION
OPERATE-ON-SYSTEM
*BINARY-PATHNAME-DEFAULT*
MAKE-SYSTEM-TAG-TABLE
ALLEGRO-MAKE-SYSTEM-FASL
*SOURCE-PATHNAME-DEFAULT*)
; Loading #p"/home/frido/lib/common-lisp/clocc/src/tools/clunit/clunit.system".
Hm what does this warnings mean?
What can I do with clunit?
there is a clunit.html so let's look at it:
Somewhere in the first lines:
(load "CLUnit.lisp")
Dummy error occurred in test "Error test"
1 test run; 0 tests passed; 1 test failed.
Dummy error occurred in test "Error test"
1 test run; 0 tests passed; 1 test failed.
2 tests run; 2 tests passed; 0 tests failed.
11 tests run; 11 tests passed; 0 tests failed.
CLUnit self-test passed.
Hm do I have to load this thing or not? The INSTALL says everything
fine while running make system so let's try a test:
(deftest "Test car 1" #'(lambda () (eq (car '(a b)) 'a)))
next message:
Error in KERNEL:%COERCE-TO-FUNCTION: the function DEFTEST is undefined.
[Condition of type UNDEFINED-FUNCTION]
Restarts:
0: [ABORT] Return to Slime toplevel.
1: [ABORT] Return to Top-Level.
Backtrace:
0: (KERNEL:%COERCE-TO-FUNCTION DEFTEST)
1: ("Top-Level Form")[:TOP-LEVEL]
well of course this error will occur, this little line here:
; Loading #p"/home/frido/lib/common-lisp/clocc/src/tools/clunit/clunit.system".
tells what has happened, what is this clunit.system stuff about?
lookint at it:
;;; -*- Mode: Lisp -*-
;;; clunit.system --
(mk:defsystem clunit
:source-pathname (translate-logical-pathname "clocc:src;tools;clunit;")
:source-extension "lisp"
:components ((:file "clunit")))
what does it mean?
And so on, ...
I assume that is what has driven them nuts. I can understand that
fully.
Regards
Friedrich
Tayssir John Gabbour
> newbie, I haven't yet wrapped my head around the concepts of symbols, so
> puh-lease don't lecture me about it. You waste your time. What I want is
> simple boilerplates showing me the rudiments, like a sample defpackage I
> can just cut-and-paste and pluck in my own functions. That's MORE than
> enough, and if I want more, I can always jump into the HyperSpec, or ask on
> #lisp for the skinny.
Cltl2 has a good, short section on symbols. Also check this out:
http://www.cliki.net/Online%20Tutorial
as well as Peter Seibel's book in progress.
I learned that people really weren't kidding when they say Cltl2
diverges from the standard a bit, but it's often more clear than other
sources.
CL is among the best languages in terms of documentation, especially
when you note that the language is simple/extensible enough that you
can cover a great amount of ground fast.
Sadly enough, using Emacs/CLisp on Windows:
- my Emacs doesn't support labels/flet. When I attempt to trivially
use them, it complains of stack overflow. This does not reproduce on
Unix.
- ILisp won't install, though perhaps I didn't try particularly hard.
So it's a crazy life. The problem is, with Free Software, the
consumer must meet the producer half way and provide incentives for
further work. I read this thread as asking producers for almost pure
altruism, and it's not clear what the results will be.
Companies like O'Reilly have attempted to fix this problem, but AFAIK
they've failed. If Fred Brooks is right, packaging software to be
simple to use is much more work than simply banging out reasonably
robust code, so this problem is deeper than some may think. This is
pretty much the reason why commercial developers don't have to commit
suicide in fear of Free Software, unless their hyperspecialized niche
was demolished.
Fortunately, there is little I ask from CL. As far as interacting
with the system, I simply need I/O to disk for sexprs and text files.
As far as installing utils, I simply read the lib, and either
cut&paste or rewrite the code. I have too many important interests to
deal with someone's ghetto install system. ;)
rydis
> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>
> > Parse error in namestring: Expecting a file name, got #\..
> > home:.hemlock-init
> > ^
>
> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
> logical-pathnames. I tried to find a way to report this but just found
> the mailings lists....
But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
you've defined a logical host called "HOME". "home:" is a search
list.
Friedrich Dominicus
> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
>> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>>
>> > Parse error in namestring: Expecting a file name, got #\..
>> > home:.hemlock-init
>> > ^
>>
>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
>> logical-pathnames. I tried to find a way to report this but just found
>> the mailings lists....
>
> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
> you've defined a logical host called "HOME". "home:" is a search
> list.
I've such a logical-host defined. And there I had this problem with
the . in it.
(translate-logical-pathname "home:t1.txt")
#p"/home/frido/t1.txt"
CL-USER>
but
CL-USER> (translate-logical-pathname "home:.t1.txt")
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable CL-USER> is unbound.
[Condition of type UNBOUND-VARIABLE]
Backtrace
0: (EVAL CL-USER>)
1: (SWANK::EVAL-REGION "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")" T)
2: (SWANK::EVAL-REGION 2 "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")" T)[:EXTERNAL]
3: (SWANK:LISTENER-EVAL "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")") 0: [ABORT] Return to Slime toplevel.
So why is this error message there?
Regards
Friedrich
Friedrich Dominicus
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
>> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
>>> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>>>
>>> > Parse error in namestring: Expecting a file name, got #\..
>>> > home:.hemlock-init
>>> > ^
>>>
>>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
>>> logical-pathnames. I tried to find a way to report this but just found
>>> the mailings lists....
>>
>> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
>> you've defined a logical host called "HOME". "home:" is a search
>> list.
Oh, well that is even worse. The same structure as an logical-pathname
is used in another way. How should a Lisp beginner know?
See below I messed up some stuff.
I've such a logical-host defined. And there I had this problem with
the . in it.
CL-USER> (setf (logical-pathname-translations "test")
'(("**;*.*" "/tmp/**/*.*")))
(("**;*.*" "/tmp/**/*.*"))
CL-USER> (translate-logical-pathname "test:t1.txt")
#p"/tmp/t1.txt"
CL-USER> (translate-logical-pathname "test:.t1.txt")
Parse error in namestring: Expecting a file name, got #\..
test:.t1.txt
^
[Condition of type COMMON-LISP::NAMESTRING-PARSE-ERROR]
Restarts:
0: [ABORT] Return to Slime toplevel.
1: [ABORT] Return to Top-Level.
Backtrace:
0: (COMMON-LISP::EXPECTING "a file name" ((#\. . 5) ("T1" . 6) (#\. . 8) ("TXT" . 9)))
1: (COMMON-LISP::PARSE-DIRECTORY ((#\. . 5) ("T1" . 6) (#\. . 8) ("TXT" . 9)))
2: (COMMON-LISP::PARSE-LOGICAL-NAMESTRING "test:.t1.txt" 0 12)
3: (COMMON-LISP::%PARSE-NAMESTRING "test:.t1.txt" NIL #p"" 0 ...)
4: (COMMON-LISP::%PARSE-NAMESTRING 6 "test:.t1.txt" NIL #p"" ...)[:EXTERNAL]
5: (PATHNAME "test:.t1.txt")
6: (TRANSLATE-LOGICAL-PATHNAME "test:.t1.txt")
But know that I know that this Search List exists (I did not even
thought that one could overload the meaning of logical-pathnames,
things get even worse now I can do
a
(ed "home:.cint_hist")
and hemlock shows me the proper field but doing a
(ed "test:.t1.txt") yields an error
Well I do not know how you think about it, but for me that is an
extremly poor interface.
Regards
Friedrich
Eladio
> A few starting points for understanding the Lisp equivalent of Unix
> `make', i.e. DEFSYSTEM tools (Google if necessary). Read:
>
> - Kent Pitman's article "The Description of Large Systems", available
> at his web site
> - the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
> - the README file of Dan Barlow's `asdf' tool
Beautiful - I'll sink my teeth into those right off the bat!
> > Oh - and how do you start Hemlock?! Thanks for your consideration.
>
> Evaluate these expressions at the CMUCL prompt:
>
> (require :clx)
> (require :hemlock)
> (ed)
>
> The Hemlock manual, available at the CMUCL site in the documentation
> section, provides more details. Also check the Hemlock page at CLiki.
I'm all over it! Thank you so much for taking the time with this.
--
"Thinking gives you wrinkles!" - Malibu Stacy, the Simpsons.
Vladimir Zolotykh
! If such a thing exists, I don't know where it is, or how to find it.
! I am not willing to spend hours researching Google, chasing down
! links, making guesses, trying experiments, starting over, etc.
I presume this is the only way. At least for me. Let me give an
example. Some time ago I tried to apply UncommonSQL for my restricted
needs. My way was exactly as you've described it. Searching, trying,
reading sources, making experiments, asking more experienced,
etc. Eventually it began working for me. But to that time I ended up
with my own much simplified code for that. The reason for that was
simple. I know my code and always able to mould it for my own needs.
I'm not saying anything against UncommonSQL. I was just unable to
understood it well enough. Having enough of up-to-date documentation
probably would save me many troubles, but...
! In other words, the ONLY acceptable solution is the SAME as
! for all the other software that we use (for Perl, JAVA, and C).
! There has to be a series of mostly self-installing download
! distributions, and simple documentation to tell what we need.
In that way, if things were so, we would get just another counterpart
for "Perl, JAVA, and C". Let me make a comparison which you may
consider as a trite. Standardization went much further in hardware
than in software. Allow me to think that the analogy is suitable:
hardware and software, traditional languages like C and Lisp. Lisp
software is just too flexible to be easily standardized or restricted
to a few well defined ways or at least susceptible of standardization
by far harder.
To conclude. All you've prospect is possible but hundredfold harder.
--
Vladimir Zolotykh
Christopher C. Stacy
Vladimir> Lisp software is just too flexible to be easily standardized
Vladimir> or restricted to a few well defined ways or at least
Vladimir> susceptible of standardization by far harder.
I was not suggesting that there be only one way, but rather that
there exist a standard way. To suggest that Lisp is too flexible
for there to exist a standard way to download and install does
not make any sense.
Especially since similar things, such as network-available "autoload"
existed for Lisp more than 20 years ago when I used them.
I think something like CPAN could be implemented in a week.
Don Geddis
> Don> perhaps you can be more constructive and say how to improve the
> Don> solutions that exist so that users aren't as confused as you
> Don> believe they are today.
cst...@news.dtpq.com (Christopher C. Stacy) writes:
> What you have done, Don, is to recite to me your experience
> in solving a different problem than the one that I reported.
Ah. My mistake.
Since you made the subject line be "why _Lisp_ is too hard", I got confused
into believing that you had some problems with installing and using Lisp.
Apparently that's not the case. Despite your subject line, you (and your
friends) _don't_ have any problems installing and programming in Lisp.
(It might have helped clarify things if you had said so.)
Instead, your concern apparently is with installing and using free
open-source contributed libraries, that happen to be written in Lisp.
I guess I'm not as surprised that installing a random programmer's freely-
offered code might take a bit of effort. But at least you don't have a problem
with Lisp itself, installing or programming in it.
> Then you suggested I should change operating systems, and
> then gave a wisecrack about how it took you thirty seconds
> to do this, how perhaps I didn't try very hard, or there's
> something wrong with me, or perhaps I could be "more constructive"
> and say how to improve the solutions.
I was much more constructive with you than you're giving me credit here.
I didn't just say it took me 30 seconds: I showed the exact steps I took,
which in each case were the obvious, uneducated ones. My question was,
how were you not able to follow this same path yourself?
It isn't that I was making wisecracks. The only issue was your goal:
> I was not trying to download CMUCL, but rather certain libraries;
This no longer seems to be something about Lisp (the language), though. Now
it's about the user community. Lisp implementors shouldn't be held
responsible for what Lisp users choose to do independently.
Don Geddis
> The problem is not firing up the lisp systems - they all work.
Great!
> The problems arrive the second you try to write your first application
> and it dawns on you that you have nothing along the lines of "getopt",
> "configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
> cliki, cclan, cclib and all those great libraries jam-packed with goodies to
> sink your teeth into... and find that you spend days on end to move
> forward. Hence the frustration.
This hasn't been my experience. I've written tons of Lisp code, and only
very, very rarely have I used third-party libraries.
I'm not saying there's anything right or wrong about using libraries, but
you're far underselling Lisp if you think that you can't do anything useful
with the language (especially with the extras including in the major
implementations) unless you also install many additional packages.
Common Lisp out of the box is a very full-featured language, and you can do
lots of cool stuff by yourself (especially as a novice!) just using the
standard Lisp system with no additional libraries.
I sympathize that there seem to be lots of useful packages out there, yet
newbies find it difficult to install and use them. My question, though, is
why does this stop you? Just ignore the packages, and start writing great
Lisp code by yourself!
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
It is possible for your mind to be so open that your brain falls out.
Christophe Rhodes
> Especially since similar things, such as network-available "autoload"
> existed for Lisp more than 20 years ago when I used them.
^
+---- a given implementation of
> I think something like CPAN could be implemented in a week.
Actually, this turns out to be hard, based on actual attempts to
implement it. Or rather, it's easy if you are willing to tolerate
brokenness, or lack of generality.
The problem is the combinatorial explosion, one more than Perl, Python
or other 'one-implementation' languages have to cope with (but even
there, life is not full of roses, as those who remember the transition
between Perl 5.004 and 5.005 will know).
If you restrict the combinatorial explosion to manageable proportions,
then as people have informed you *several times* in this thread,
'something like CPAN' _has_ been implemented more than once; you just
happen to have made choices that prevent you from using it. I'm
sorry, that's not my fault; please reconsider your choices in the
light of the information you take in (and, while I'm making requests,
please stop peddling misinformation).
The problem gets tricky when you wish to support, say, 4
implementations on 4 operating systems (each of which is more-or-less
braindead) on 5 architectures or so. Sure, this combinatorial
explosion isn't a problem for portable code, but note that network
interaction is non-portable, so it needs implementation support.
Let me take a little historical diversion, since you seem to assume
that this is a grand new idea that has just burst on the scene, and
that just a little evangelism is needed to get the ball rolling. Some
people have been working on this problem for about two years (in their
free time, of course, since they're freeloaders^Wfree software
writers). By far the hardest problem has been in convincing
implementations to support some kind of stub for this kind of
autoloading.
In the first iteration of cCLan (some historical details of which you
can find on CLiki, and on various mailing lists), the problem was
dodged by dealing with just one Linux distribution. Because Debian is
a distribution with community support and -- and this bit is important
-- a well-constructed package policy (the package /format/ is almost
completely irrelevant) we could construct packages that were
seamlessly integrated with the rest of the system, and that, by
obeying a defined protocol, would be managed by the system for the
productivity benefit of the user: they would be compiled for the
various Lisp compilers that were installed (and understood the
protocol), upgrades to either compiler or library would be
transparently handled, and so on. The current strong support for Lisp
in Debian is the natural offshoot of this, but note that the Debian
distributors have to modify the lisps that they distribute so that
they obey the various protocols that have been established -- in other
words, they don't distribute vanilla cores for CLISP, CMUCL, and so
on. Note also that, as has already been said, no one seemed
interested to provide lisps and libraries packaged for this
infrastructure on anything other than Debian.
Fast-forward a little: it turns out that this system for managing Lisp
software is fine for end-users, but a little too intrusive for
developers. It is tricky, because of these modifications to lisps
(and lighter, but still present, modifications to the upstream
libraries) to work on, rather than with, software distributed in this
form. It's particularly bad for lisp implementors, who will wish to
test modifications to their lisps, but have no way of easily inserting
it into their system. So, cCLan version two is born.
cCLan version two is essentially inspired by CTAN (the comprehensive
TeX archive network, which has a well-tested and venerable history).
This consists of simple .tar.gz packages, following extremely simple
policy: have a asdf system description in a file with the same name as
the library. See CLiki pages "cclan" and "vn-cclan". Though this
still survives, the problem here is the burden it places on the
archive maintainers and the library writers: the act of placing a
package in the repository is burdensome (particuarly if a project is
fast-moving) for both, and nodes with permanent presence were hard to
find. The combinatorial explosion is under control, but even the
end-user has to do the work themselves; fairly repetitive work, at
that (download package, untar, link, compile...).
So, to lighten the burden, in comes asdf-install. This is a simple
http client, so it can easily retrieve packages in the
"vendor-neutral" archive. However, the additional functionality comes
from the use of CLiki-the-site as a central registry of package
locations. By adding a tag to a page, say the cl-ppcre page, the
asdf-install client can download and unpack the software, investigate
and possibly recursively operate on its (Lisp package) dependencies,
and compile the library. However, here again we've lost against the
combinatorial explosion; instead of the first iteration (where we only
support one OS), currently the asdf-install client is only publically
available for one Lisp implementation.
So, where does this leave us? Well, I can download and install
packages automatically, so I'm happy. So can the users of my Lisp
implementation, so as long as they're happy, I'm happy. If users of
other implementations would like to live in this
one-step-closer-to-nirvana, well, I approve and encourage efforts to
make it happen, either by writing or porting a client, or asking your
distributor to do it for you, or even by doing something completely
different (though if you do try doing something completely different,
I'd suggest that you consider the experience of those who have already
trodden down some paths less fruitful).
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Edi Weitz
> Note also that, as has already been said, no one seemed interested
> to provide lisps and libraries packaged for this infrastructure on
> anything other than Debian.
... and Gentoo[1].
For those of you who don't know the details it should be noted that
(AFAIK) there are only three "Lisp-y" Debian maintainers (and one of
them, Kevin Rosenberg, maintains the vast majority of the packages)
and there's only one "Lisp-y" Gentoo maintainer.
Being someone who has also contributed a minimal amount of Lisp code
to "the community" (whoever that is) I feel tempted to write much much
more about this subject but a) I'm very busy with other things right
now, and b) it will in no way improve the current situation. The fact
is that, despite of its glorious history, (Common) Lisp currently is
in an "early-adopter" stage. It doesn't help very much to tell people
that it's not very convenient for a user of Corman Lisp on Microsoft
Windows to install CLOCC. We already know that.
As Paolo has mentioned, there is no secret plot to prevent people from
using CL and Lisp libraries, there's just a lack of people working on
this. This is a classical chicken-and-egg problem. For the few
developers working on "free" Lisp stuff it's much more fun[2] to write
new code than to write docs or care about packaging issues. You /will/
find capable people willing to work on this but only if you reach a
"critical mass" of users. Of course it'd be easier to reach this
critical mass if it were easier to install and use these
libraries. Sigh...
Let me ask just a few questions: If CPAN is so great, how easy is it
to install[3] a random Perl module on Windows? How easy would it be if
cygwin or a commercial entity like ActiveState didn't exist? Why does
ActiveState offer Perl, Python, and TCL for Windows but not Common
Lisp? How old is Perl, how old is ActiveState? How many different Perl
implementations do you know?
If you're using Debian or Gentoo or if you happen to use SBCL[4]
together with asdf-install you're already rather lucky. If you
/insist/ on using another OS and/or another Lisp implementation and
you don't have the time or drive to help please ask your commercial
vendor (Red Hat, SuSE, Mandrake, Microsoft, Apple, Franz, Xanalys,
Digitool, Corman, whoever) or come back in two or three years. We're
already working on your problems but we need some more time,
sorry... :)
Edi.
[1] <http://www.cliki.net/gentoo>
[2] or (like me) they're more or less just distributing "offsprings"
of their commercial work
[3] From the CPAN docs:
"Does the module require compilation (i.e. does it have files
that end in .xs, .c, .h, .y, .cc, .cxx, or .C)? [...]. If it
does, life is now officially tough for you."
[4] CMUCL to come soon...
Eladio
> I'm not saying there's anything right or wrong about using libraries, but
> you're far underselling Lisp if you think that you can't do anything useful
> with the language (especially with the extras including in the major
> implementations) unless you also install many additional packages.
Of course I don't think that way, silly wabbit! Lisp is fabulous - but those
libraries are just too cool, and I'm bristling with great projects I'd love to
kick off. Besides, I'm problably just going through some growing pains. I
remember wasting an entire WEEK just to install a stupid database driver and
figuring out the how to set up the CLASSPATH correctly. Lisp isn't any worse
than that, at the end of the day.
> Common Lisp out of the box is a very full-featured language, and you can do
> lots of cool stuff by yourself (especially as a novice!) just using the
> standard Lisp system with no additional libraries.
Same thing could be said for any other language. The NASM assembler is
amazingly fullfledged too, so are Python, Perl, PHP, C, C++, C# and Java. But
libraries make you so much more productive at a much faster rate. I was
floored when I tried out lisp-functions like "time", compared to what a bitch
it was to figure out how to use the Benchmark module in PHP. At least the Perl
version has documentation in abundance. I've yet to find anything near to
"trace" in any other language. Little features like that are all over
Lisp. It's awesome.
But now I want more! More! MOOOORE!! *slaver*
> I sympathize that there seem to be lots of useful packages out there, yet
> newbies find it difficult to install and use them. My question, though, is
> why does this stop you? Just ignore the packages, and start writing great
> Lisp code by yourself!
Stop MOI?! Armaggedon couldn't stop me from blasting out Lisp-code, man! But
imagine hackin' Perl without CPAN. It's just not the same. And frankly, I'd
rather blaze a new trail than reinventing the wheel.
The Lisp libraries out there are fabulous, and DESERVE to be used. I'm just
struggling to do just that, and if FreeBSD won't let me, then I'll just have
to switch to Debian until I grok the package system, and port the whole
stuffed enchilada over at some point myself.
The tools are there, the libraries are there, the knowhow is there, and the
userbase is there. There's just a few kinks which spoil the fun for the
clueless, and little by little they'll all be ironed out, I'm sure.
Paolo Amoroso
> Paolo Amoroso <amo...@mclink.it> writes:
>
>> A few starting points for understanding the Lisp equivalent of Unix
>> `make', i.e. DEFSYSTEM tools (Google if necessary). Read:
>>
>> - Kent Pitman's article "The Description of Large Systems", available
>> at his web site
>> - the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
>> - the README file of Dan Barlow's `asdf' tool
>
> Beautiful - I'll sink my teeth into those right off the bat!
A few additional resources accessible from CLiki:
Practical Lisp Programming
http://www.cliki.net/Practical%20Lisp%20Programming
Fight the System
Installing and Using Common Lisp Libraries
http://www.henrik-motakef.de/defsystem.html
The latter looks like what you were looking for, and is accessible
from the former. Have (de)fun,
james anderson
Paolo Amoroso wrote:
>
> ...
>
> A few additional resources accessible from CLiki:
>
> Practical Lisp Programming
> http://www.cliki.net/Practical%20Lisp%20Programming
>
> Fight the System
> Installing and Using Common Lisp Libraries
> http://www.henrik-motakef.de/defsystem.html
>
as informative as this latter may be, it is both ironic and typical that much
of it is expressed in terms of physical pathnames and logical pathnames end up
in a footnote.
...
Ng Pheng Siong
> struggling to do just that, and if FreeBSD won't let me...
Of course FreeBSD lets you; you just have to ask properly. ;-)
But really this hasn't much to do with operating systems. (My POV may be
"different": I was a system administrator of several flavours of Un*x and
Windows for some years before moving to programming.)
Going back two nodes in this thread tree, I see you're talking about
(require 'asdf) and (require 'asdf-install).
Well, I haven't looked at asdf-install, but for asdf, I did the following:
0. In a listener, (compile-file ".../.../asdf")
On CMUCL, this produces asdf.x86f; on LispWorks/Windows, asdf.fsl.
1. In .cmucl-init.lisp (for CMUCL (duh!)) or lispworks-init.lisp (my
convention for LispWorks), add the form at the beginning of the file:
(load ".../.../asdf")
2. Now ASDF is available. To load Portable AllegroServe, say, I have the
following in the init files:
(defun go-aserve ()
(load "/usr/local/pkg/lisp/portableaserve/acl-compat/acl-compat.asd")
(asdf:oos 'asdf:load-op :acl-compat)
(load "/usr/local/pkg/lisp/portableaserve/aserve/htmlgen/htmlgen.asd")
(asdf:oos 'asdf:load-op :htmlgen)
(load "/usr/local/pkg/lisp/portableaserve/aserve/aserve.asd")
(asdf:oos 'asdf:load-op :aserve))
So when I want it, I just say "(go-aserve)" in a listener. Works for both
CMUCL and LispWorks/Windows.
I don't know much about REQUIRE, coz when I got started, I noticed the CLHS
say it is deprecated [*], so I figured out the above and didn't think
about it anymore.
* Fire up Emacs, fire up CMUCL, type "(require<ctrl-c><shift-h>" and the
CLHS pops up in my Mozilla browser window, positioned at the docu for
REQUIRE. Cool huh! IIRC the instructions to do this are in the ILISP
distribution.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Igor Carron
a language that deals nicely with extraodirnarly complex problems
dealing with recursion/combinatorial and time critical issues (Hanoi's
towers, Orbitz search engine and so on) cannot come up with a way to
deal with the complexity of having to deal with several OS/several
Lisps and several libraries.
I know this sounds like a bait but if one were to contemplate the
situation from afar like a newbie would (myself being one of them), it
really looks like a lost opportunity to prove a very powerful point.
Igor.
Christophe Rhodes <cs...@cam.ac.uk> wrote in message news:<sqn09gh...@lambda.jcn.srcf.net>...
Pascal Costanza
Igor Carron wrote:
> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
>
> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.
I hope it doesn't look like a lost opportunity to learn why these are
two very different issues.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Eladio
> Well, I haven't looked at asdf-install, but for asdf, I did the following:
>
> 0. In a listener, (compile-file ".../.../asdf")
>
> On CMUCL, this produces asdf.x86f; on LispWorks/Windows, asdf.fsl.
>
> 1. In .cmucl-init.lisp (for CMUCL (duh!)) or lispworks-init.lisp (my
> convention for LispWorks), add the form at the beginning of the file:
>
> (load ".../.../asdf")
>
> 2. Now ASDF is available. To load Portable AllegroServe, say, I have the
> following in the init files:
>
> (defun go-aserve ()
> (load "/usr/local/pkg/lisp/portableaserve/acl-compat/acl-compat.asd")
> (asdf:oos 'asdf:load-op :acl-compat)
> (load "/usr/local/pkg/lisp/portableaserve/aserve/htmlgen/htmlgen.asd")
> (asdf:oos 'asdf:load-op :htmlgen)
> (load "/usr/local/pkg/lisp/portableaserve/aserve/aserve.asd")
> (asdf:oos 'asdf:load-op :aserve))
>
> So when I want it, I just say "(go-aserve)" in a listener. Works for both
> CMUCL and LispWorks/Windows.
Ng, you ARE the man! I'm starting to get the hang of this baby. Actually, I
switched over to SBCL and re-did the clocc-instructions from A-Z. Now at least
I have the whole CLLIB package tree compiled, and I can load it in too, which
means I now know how to grab any module on cliki by hand, compile it, and load
it in - so I'm aaaaaalmost ready to rock 'n rock!
The only snag left is figuring out which *prefix* to use to get at the goodies,
and I'm all set. For instance, I do a
(load (translate-logical-pathname "clocc:src;cllib;animals"))
and the following symbols get exported: play-animals, play-game,
*animals-file-name*, but I can't for the life of me not figure out how to call
them. I've tried, say (play-game), (cllib:play-game) and numerous other
variations, including trying to change to different packages. (I'm told that
none of those symbols are bound, which *freaks* me out!)
This is a minor issue, really. Nothing I can't pester the good folks on #lisp
about, hehehe.
So I'm so close I can smell the victory, man. And thank you so much for taking
the time: I'm wasted now, but I'll try it out first thing in the morning.
Cheers!
Pascal Bourguignon
tayss...@yahoo.com (Tayssir John Gabbour) writes:
> So it's a crazy life. The problem is, with Free Software, the
> consumer must meet the producer half way and provide incentives for
> further work. I read this thread as asking producers for almost pure
> altruism, and it's not clear what the results will be.
I can assure you that you will meet the Free Software producers with
at least as much altruism, if not a thousandfold more, as, for example
Microsoft, if you, as with Microsoft, start to send them your VISA
number to get support and to motivate improvements. In addition, you
have the freedom to contract the services of your favorite IT
professionnal to make modification to free software, which you don't
have and can't do with closed proprietary software...
> Companies like O'Reilly have attempted to fix this problem, but AFAIK
> they've failed. If Fred Brooks is right, packaging software to be
> simple to use is much more work than simply banging out reasonably
> robust code, so this problem is deeper than some may think.
Indeed.
> This is
> pretty much the reason why commercial developers don't have to commit
> suicide in fear of Free Software, unless their hyperspecialized niche
> was demolished.
>
> Fortunately, there is little I ask from CL. As far as interacting
> with the system, I simply need I/O to disk for sexprs and text files.
> As far as installing utils, I simply read the lib, and either
> cut&paste or rewrite the code. I have too many important interests to
> deal with someone's ghetto install system. ;)
--
Paolo Amoroso
> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
Here is a hint. Those who use Lisp to deal with those extraordinarily
complex problems do not need newbie documentation or operating system
independent packaging tools. And given their limited time and
resources, if they have to choose between solving complex problems
that interest them, or writing newbie tools/documentation, you might
guess what they are going to do.
Paolo Amoroso
> as informative as this latter may be, it is both ironic and typical that much
> of it is expressed in terms of physical pathnames and logical pathnames end up
> in a footnote.
If you put it this way, the glass is indeed half-empty. But if you
consider Eladio's original request of learning what a DEFSYSTEM tool
is in the first place, the glass may look half-full.
Christopher C. Stacy
Paolo> Here is a hint. Those who use Lisp to deal with those
Paolo> extraordinarily complex problems do not need newbie
Paolo> documentation or operating system independent packaging tools.
That's got to be just about the lamest thing I've ever heard.
Thomas F. Burdick
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > FWIW, it's waaaaay easier to find and install things now than it was
> > in the late 90's. And the situation's still improving.
>
> Yeah, that's the open source movement for you. Stuff that broke your teeth 3
> months ago suddenly fly by wire. But it's still frustrating while it goes
> on. *sigh*
>
> > I'd recommend that you get SBCL. Dan Barlow replaced his old guide to
> > getting started on CMUCL with a new one for SBCL:
> >
> > http://ww.telent.net/lisp/according_to/
>
> Wonderful! I've been on #lisp all day, and go the same advice. It still gives
> me heaps of trouble since asdf-install doesn't seem to be installed by default
> on FreeBSD, but I'm working on it.
Where did you get your SBCL distribution? I have no idea what's in
ports (I haven't used FreeBSD in a long time), but if you're using
that, try switching to a recent binary from the SBCL website
(sbcl.sf.net). Either you're using an old SBCL, or something's
broken, in which case it's a bug.
> I have yet to find anything remotely ressembling a manual for asdf,
[ The "README" file is actually decent documentation ]
> let alone
> instructions for actually *fixing* the problems you encounter. So I'm supposed
> to type:
>
> (require 'asdf)
> (require 'asdf-install)
> (asdf-install 'cliki) ; or whatever
>
> Okay. Peace of cake. But clisp, cmucl, and sbcl ALL break down at step one,
Only SBCL ships with ASDF, so that's the only one where this would
work. When you run into problems like this, don't write long messages
about how you Love Love Love Lisp and it would be Great If This Worked
-- instead, report it as a bug, giving details (software versions,
instructions to reproduce, etc) -- nothing exactly wrong with the
former, but the latter is more helpful :). In this case, after making
sure you're running the latest SBCL, report this as a bug to sbcl-help
at lists dot sourceforge dot net.
As for CLISP and CMUCL, you can get ASDF for them, just download the
asdf.lisp file, and load it:
(load "/path/to/asdf.lisp")
It's kind of the Lisp answer to "make".
> > Go to CLiki. Type "hemlock" in the search. Click on the third link,
> > GettingStartedWithHemlock.
>
> Success! Success at last!!! Thank you *so* much! I get the feeling I'll spend
> the whole day tomorrow on cliki, hehehe! Finally a little victory to round off
> the day. Sorry for the verboseness of this post, by the by - and merry
> Christmas!
(Oh good -- and if you have *any* problems with it, lemme know, so I
can fix it for future newbies).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Christophe Rhodes
> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
What is this "community" and who is in it? What I see is mostly a
bunch of individuals: some extremely helpful, and a vast majority
sitting on the sidelines and carping. There Is No Common Lisp
Community. I'm sorry, but that's the way it is. If you want one,
help to build one.
> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.
I don't have any points to prove. I _do_ _not_ _care_ that
Christopher Stacy has made choices that mean that he can't do some
things he whines about; likewise, I do not feel the need to proclaim
Common Lisp, or even one particular implementation of it, as The
Answer. I care about the misinformation that has been provided, and I
have given recent history for why the current situation is how it is
to try to redress the balance.
I don't need to market Lisp as a silver bullet. If it meets your
needs, or can be moulded to do so (that being what Lisp is generally
good at, after all) then welcome, and I'll provide such assistance as
I can; if not, then fine.
On the other hand, if I were provided with even the relatively small
budget[1] of Orbitz (though I wouldn't say no to being given the
budget for building large towers, either :-) I don't think I'd have
too much difficulty building a sufficiently complex system to evolving
specifications. The same goes for those few out there who are not
among the carpers.
Christophe
[1] time is probably the most important bit in the equation here; but
as Einstein proved, money can be converted to time in a
thermodynamically reversible process.
Christophe Rhodes
Well, thank you for that insightful contribution.
It would be tempting, in the light of this message, to dismiss your
initial post as simply a well-crafted troll. You haven't responded to
any of the substantive replies to your posts in any meaningful way,
contenting yourself with dismissing reasonable messages in this thread
not with argument but with insult.
However, one must be careful not to let the messenger's rather tedious
behavior to obscure the message too far; it remains true that users of
CLISP on RedHat are less well-served in the general infrastructure
than certain other Lisp programmers. If that were generally unknown
to compiler maintainers and library writers, well, bringing it to
light in such an obtrusive fashion might have helped; however, as I
hope you are beginning to gather, such issues are not completely
unknown, and not completely without existing solutions, either.
Alternatively, maybe your intervention will motivate young,
enthusiastic programmers to join the cause of making things better.
But with rhetoric like that displayed above, my feeling is that you're
more likely to have a detrimental effect. Is that your intention?
Marc Battyani
"Edi Weitz" <e...@agharta.de> wrote
> As Paolo has mentioned, there is no secret plot to prevent people from
> using CL and Lisp libraries, there's just a lack of people working on
> this. This is a classical chicken-and-egg problem. For the few
> developers working on "free" Lisp stuff it's much more fun[2] to write
> new code than to write docs or care about packaging issues. You /will/
> find capable people willing to work on this but only if you reach a
> "critical mass" of users. Of course it'd be easier to reach this
> critical mass if it were easier to install and use these
> libraries. Sigh...
Hmm, I must admit that there is very few docs for the libraries I release as
open-source. But the problem is not only related to lack of time. If I had
more time I would write more code, not more docs! So the best way IMHO would
be if users wrote some doc/tutorial/how-to/cheat sheet/etc. once they figure
out how some library works ;-)
Marc
Marc Battyani
"Christophe Rhodes" <cs...@cam.ac.uk> wrote
> igorc...@yahoo.com (Igor Carron) writes:
>
> > So let me get this straight. The community that prides itself in using
> > a language that deals nicely with extraodirnarly complex problems
> > dealing with recursion/combinatorial and time critical issues (Hanoi's
> > towers, Orbitz search engine and so on) cannot come up with a way to
> > deal with the complexity of having to deal with several OS/several
> > Lisps and several libraries.
>
> What is this "community" and who is in it? What I see is mostly a
> bunch of individuals: some extremely helpful, and a vast majority
> sitting on the sidelines and carping. There Is No Common Lisp
> Community. I'm sorry, but that's the way it is. If you want one,
> help to build one.
At least there is a Common Whining Community for sure... ;-)
> > I know this sounds like a bait but if one were to contemplate the
> > situation from afar like a newbie would (myself being one of them), it
> > really looks like a lost opportunity to prove a very powerful point.
>
> I don't have any points to prove. I _do_ _not_ _care_ that
> Christopher Stacy has made choices that mean that he can't do some
> things he whines about; likewise, I do not feel the need to proclaim
> Common Lisp, or even one particular implementation of it, as The
> Answer. I care about the misinformation that has been provided, and I
> have given recent history for why the current situation is how it is
> to try to redress the balance.
May be he just had a bad day ? I have been puzzled by this post too.
Especially when he says that he doesn't have the time to help... BTW I tried
to install viewcvs for my open-source subversion repositories and, though
it's not in Lisp but in Python, I couldn't make it work on my Debian Woody
box. On the other hand, all the Common Lisp libraries I used worked more or
less out of the box. So YMMV as usual...
[...]
> [1] time is probably the most important bit in the equation here; but
> as Einstein proved, money can be converted to time in a
> thermodynamically reversible process.
I like that, but I'm not sure it's really true in the programming world. At
the very least it would be highly non linear...
Marc
Brian Mastenbrook
Carron <igorc...@yahoo.com> wrote:
> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
>
> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.
>
> Igor.
As a word of correction: it's improper to top-quote on Usenet, and I
don't think you'll see anyone else here doing so.
That said, I think you are confusing two very different ideas here. The
way that the towers of Hanoi and Orbitz are complex is not the same
thing as vendor packaging. To clarify the situation for you, packaging
is not difficult because it is intrinsically algorithmically complex,
or because the solution is unknown and only hueristics exist. It is
complex because it is like playing whack-a-mole from the perspective of
the mole. It's difficult and I doubt you or any of the carpers could
actually do it. (Not to mention dealing with users who don't read
documentation, know how to use Google, etc.)
Of course, if I'm wrong, go ahead and prove it. I bet you can't.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Michael Hudson
> BTW I tried to install viewcvs for my open-source subversion
> repositories and, though it's not in Lisp but in Python, I couldn't
> make it work on my Debian Woody box. On the other hand, all the
> Common Lisp libraries I used worked more or less out of the box. So
> YMMV as usual...
This is a fair point; I'm much more a member of the Python community
than the Lisp community (whatever that means) and I wouldn't want
comp.lang.lisp to get the impression that the grass is all that much
greener on the other side. A bit greener, in some ways, maybe, but
packaging and distributing applications and libraries seems to be a
hard problem. At least, that's what the paucity of decent solutions
suggests to me.
Cheers,
mwh
--
If design space weren't so vast, and the good solutions so small a
portion of it, programming would be a lot easier.
-- maney, comp.lang.python
Lupo LeBoucher
Don Geddis <d...@geddis.org> wrote:
>Eladio <eladio_...@yahoo.com> writes:
>> The problem is not firing up the lisp systems - they all work.
>
>Great!
>
>> The problems arrive the second you try to write your first application
>> and it dawns on you that you have nothing along the lines of "getopt",
>> "configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
>> cliki, cclan, cclib and all those great libraries jam-packed with goodies to
>> sink your teeth into... and find that you spend days on end to move
>> forward. Hence the frustration.
>
>This hasn't been my experience. I've written tons of Lisp code, and only
>very, very rarely have I used third-party libraries.
That's because you never had to do anything which involved, say, something
like a GUI.
And ... what the first guy said.
-Lupo
"the vague tori, being of too indistinct a character to object, are then
heavily exploited" -W.P. Reinhardt <i...@fnord.io.com>
Eladio
> Where did you get your SBCL distribution? I have no idea what's in
> ports (I haven't used FreeBSD in a long time), but if you're using
> that, try switching to a recent binary from the SBCL website
> (sbcl.sf.net). Either you're using an old SBCL, or something's
> broken, in which case it's a bug.
Argh! Why didn't I think of that?! I'll try this baby one last time, or it's
goodbye FreeBSD, hello Gentoo.
The sbcl is found in /usr/ports/lang/sbcl, and there're various other ports for
it too. Just use a "locate" & "grep" combo. They're all called
"-sbcl"-something.
> Only SBCL ships with ASDF, so that's the only one where this would
> work. When you run into problems like this, don't write long messages
> about how you Love Love Love Lisp and it would be Great If This Worked
> -- instead, report it as a bug, giving details (software versions,
> instructions to reproduce, etc) -- nothing exactly wrong with the
> former, but the latter is more helpful :).
I know, and I apologize. I was in rant-mode after a long, long day.
> In this case, after making sure you're running the latest SBCL, report this
> as a bug to sbcl-help at lists dot sourceforge dot net.
Will do.
> As for CLISP and CMUCL, you can get ASDF for them, just download the
> asdf.lisp file, and load it:
>
> (load "/path/to/asdf.lisp")
>
> It's kind of the Lisp answer to "make".
Way ahead of you. Asdf is a port in FreeBSD, and there's even binaries for all
3 free lisps. It loads just dandy, there's just no asdf-install in sight.
> (Oh good -- and if you have *any* problems with it, lemme know, so I
> can fix it for future newbies).
Count on me! (Actually, the intel was right there, I just had to poke around in
the right spots, as you saw)
--
Christophe Rhodes
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> In this case, after making sure you're running the latest SBCL, report this
>> as a bug to sbcl-help at lists dot sourceforge dot net.
>
> Will do.
Actually, and I hate to bounce you around (so please do report it to
sbcl-help, as well), I think this is better described as a FreeBSD
packaging bug. For reasons unknown to me, I believe the FreeBSD port
of sbcl chops out the "contrib" section, containing tools best
described as "userspace" -- including asdf and asdf-install, but also
other handy utilities (not to mention a socket interface!)
If my recollection on this is correct, it would probably also be worth
taking this up with the FreeBSD port maintainer (and logging this
issue with the FreeBSD bug tracking mechanism).
I hope that this isn't too far off the mark, and that it clears up
some of the confusion.
Eladio
> > t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> >> In this case, after making sure you're running the latest SBCL, report this
> >> as a bug to sbcl-help at lists dot sourceforge dot net.
> > Will do.
>
> Actually, and I hate to bounce you around (so please do report it to
> sbcl-help, as well), I think this is better described as a FreeBSD
> packaging bug. For reasons unknown to me, I believe the FreeBSD port
> of sbcl chops out the "contrib" section, containing tools best
> described as "userspace" -- including asdf and asdf-install, but also
> other handy utilities (not to mention a socket interface!)
That's right on the money. Asdf is installed via a separate port, either as
a source-package ("cl-asdf"), or as binaries for individual lisps, such as
"cl-asdf-sbcl". The problem seems to be that the maintainer didn't include the
contrib stuff in either of them. Sockets and the like are found in a separate
package, "cl-port", which successfully installs the following:
ls /usr/local/lib/common-lisp/port
drwxr-xr-x 2 root wheel 512 Dec 23 11:19 clispfasl
drwxr-xr-x 2 root wheel 512 Dec 23 11:20 cmuclfasl
-r--r--r-- 1 root wheel 8181 Dec 20 20:07 ext.lisp
-r--r--r-- 1 root wheel 1811 Dec 20 20:07 gray.lisp
-r--r--r-- 1 root wheel 22958 Dec 20 20:07 net.lisp
-r--r--r-- 1 root wheel 5920 Dec 20 20:07 path.lisp
-r--r--r-- 1 root wheel 783 Dec 20 20:07 port.asd
-r--r--r-- 1 root wheel 705 Dec 20 20:07 port.system
-r--r--r-- 1 root wheel 16720 Dec 20 20:07 proc.lisp
drwxr-xr-x 2 root wheel 512 Dec 24 16:36 sbclfasl
-r--r--r-- 1 root wheel 4447 Dec 20 20:07 shell.lisp
-r--r--r-- 1 root wheel 13728 Dec 20 20:07 sys.lisp
So there's no real "bugs" per se, because all this loads beautifully in all
the lisps. The only problem is merely that asdf-install doesn't seem to be
included in the sbcl/asdf installations on FreeBSD so we don't get convenience,
for now. And no matter how I try to set up asdf-install manually, I just can't
get it to work, because I'm too unfamiliar with asdf, defsystem, lisp and all
that jazz.
And frankly, right now I'm getting to the point where I can't even eat with
knife and fork with screwing up, so I'm calling it quits for this time - at
least on FreeBSD. I'm simply burned out. I'm switching over to either Gentoo or
Debian tonight. I was *floored* when I saw the number of lisp packages they
have available out of the box. FreeBSD has 5 or 6! But hey, that'll come in
time.
> If my recollection on this is correct, it would probably also be worth
> taking this up with the FreeBSD port maintainer (and logging this
> issue with the FreeBSD bug tracking mechanism).
That's the very last thing I'll do tonight before I crash the machine.
> I hope that this isn't too far off the mark, and that it clears up
> some of the confusion.
Yes, absolutely. It jives completely with my own conclusions. Had
asdf-install been included in sbcl on my system, I could have followed the
laundry-lists on cliki and elsewhere, type (require whatever) and downloaded
libraries to my heart's content, and I wouldn't have vented to the newsgroup
about my frustrations in the first place.
But thanks for the assistence all around! It's clear to me that the lisp
community is more than willing to take hand of newbies and make them feel
welcome, and I look so much forward to hack the living daylights out of your
libraries, ha ha!
C-ya!
--
Paolo Amoroso
> Answer. I care about the misinformation that has been provided, and I
> have given recent history for why the current situation is how it is
> to try to redress the balance.
Speaking of history, there was a possibly less know but relevant
attempt to create an `asdf-install'-like tool. In the early days of
the CLOCC project, Marco Antoniotti, Don Geddis(?), and probably
others I can't remember, discussed the possibility of extending
MK:DEFSYSTEM to handle dependencies and versions. The discussion
should still be available in the mailing list archive.
Edi Weitz
From the names I'd guess that these are from CLOCC, not from the
contrib directory of SBCL.
Edi.
Don Geddis
> >This hasn't been my experience. I've written tons of Lisp code, and only
> >very, very rarely have I used third-party libraries.
i...@io.com (Lupo LeBoucher) writes:
> That's because you never had to do anything which involved, say, something
> like a GUI.
Well, first of all, a newbie isn't forced to write GUIs. If that's so hard,
then pick some other interesting application to get started.
As for me, I've certainly written web-based GUIs without any third-party
libraries. HTTP/HTML is a simple enough protocol that you can code it up
yourself in a few hours.
That said, I'll agree that if you wanted to write X-windows GUI applications,
you probably need some libraries on top of Common Lisp before you start.
But this shouldn't be the key that prevents novices from getting into Lisp,
such that their difficult in writing Lisp X GUIs means they abandon Lisp
all together. That seems too extreme.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Igor Carron
> In article <ef3c551.03122...@posting.google.com>, Igor
> Carron <igorc...@yahoo.com> wrote:
>
> > So let me get this straight. The community that prides itself in using
> > a language that deals nicely with extraodirnarly complex problems
> > dealing with recursion/combinatorial and time critical issues (Hanoi's
> > towers, Orbitz search engine and so on) cannot come up with a way to
> > deal with the complexity of having to deal with several OS/several
> > Lisps and several libraries.
> >
> > I know this sounds like a bait but if one were to contemplate the
> > situation from afar like a newbie would (myself being one of them), it
> > really looks like a lost opportunity to prove a very powerful point.
> >
> > Igor.
>
> As a word of correction: it's improper to top-quote on Usenet, and I
> don't think you'll see anyone else here doing so.
>
> That said, I think you are confusing two very different ideas here. The
> way that the towers of Hanoi and Orbitz are complex is not the same
> thing as vendor packaging. To clarify the situation for you, packaging
> is not difficult because it is intrinsically algorithmically complex,
> or because the solution is unknown and only hueristics exist. It is
> complex because it is like playing whack-a-mole from the perspective of
> the mole. It's difficult and I doubt you or any of the carpers could
> actually do it.
It is one thing to give etiquette lessons on top-quoting, it is
another to be polite enough to read posts, take a deep breath and
respond intelligently.
Christopher makes a statement on the current state of the libraries in
Lisp. I make another statement about how it is somehow bizarre that
Lisp being branded by this community as being a very powerful tool
(most probably rightly so), that after some 40 years after its
introduction, there seems to be little more than some ad-hoc way to
deal with the complexity alluded to in this thread. I don't think I
said anything else.
Now let's go back to the complexity issue you are mentionning. A most
intelligent student in cognitive science such as yourself tells us
that the problem of context in our problem (whack-a-mole from the mole
perspective) is complex but at some different level/quality as the
much rehashed "Hanoi's tower" problem (well defined and known
algorithm.) What makes you think that ?
My lowly non-expert view is that your analysis is a little short. It
is a little short because as far as I can see, a better-than-average
user like Christopher can set up a working library after a day or two
(by essentially understanding the difference between a debian system
and his, reading a lot of how-tos and similar experiences by other
users). While I do not underestimate Christopher's ability in math, I
doubt his ability to solve Hanoi's tower problem on his own in the
same time frame. Most of the messages that have examples in this
thread so far, show that setting up libraries can be handled with a
lot of fortran like "if..then..else" or through the appropriate
transformation of variable names within libraries (a feat I cannot see
as overwhelming using Lisp). I also see the "combinatorial"
complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
possibilities so what ? It is not because you cannot deal with this
complexity that you should resort to name calling (carper) on people
who might want to take a stab at it. Again, I believe your analysis on
the complexity of this issue is flawed. Moreover, if it is shared by
most Lisp experts, your community is doomed. Shoot the messengers all
you want.
By the way, I surely do not advocate solving this library issue in the
way described above: we all have interesting and productive lives
after all. I wished that as a newbie, there had been a Lisp site that
said in big font=7 letters:
" Your experience in lisp and its attendant libraries strongly depends
on your ability to install debian and run lisp from there."
or something equivalent. In this case, the combinatorial complexity
drops significantly.
Some of us newbies wished we had been given this advice in the first
place. Compared to the pain of understanding some of the errors I have
seen on this thread, I would not see a dual boot on my current windows
laptop with a debian distro as being such a major pain. At least, I
know there is ample information on that.
> (Not to mention dealing with users who don't read
> documentation, know how to use Google, etc.)
>
> Of course, if I'm wrong, go ahead and prove it. I bet you can't.
I most certainly cannot prove wrong somebody doing cognitive science
as you must be more aware than I am.
Igor.
Björn Lindberg
> According to Eladio <eladio_...@yahoo.com>:
> > struggling to do just that, and if FreeBSD won't let me...
>
> Of course FreeBSD lets you; you just have to ask properly. ;-)
>
> But really this hasn't much to do with operating systems. (My POV may be
> "different": I was a system administrator of several flavours of Un*x and
> Windows for some years before moving to programming.)
>
> Going back two nodes in this thread tree, I see you're talking about
> (require 'asdf) and (require 'asdf-install).
>
> Well, I haven't looked at asdf-install, but for asdf, I did the following:
>
> [ ... ]
I have the following code for getting asdf packages to work:
==>BEGIN<==================================
(in-package :asdf)
(push "/home/bjorn/share/common-lisp/system/" *central-registry*)
(defvar *system-configuration-paths*
'(("/home/bjorn/share/common-lisp/src/"
"/home/bjorn/lib/common-lisp/cmucl/")))
(defun pathname-prefix-p (prefix pathname)
"Tar två sökvägsnamn eller namnsträngar och returnerar sant om det
första är ett prefix i det andra. :absolute/:relative först i
kataloglistan fungerar som ankare, vilket gör att SEARCH inte kan
matcha en dellista mitt i."
(search (pathname-directory prefix)
(pathname-directory pathname)
:test #'equal))
(defmacro iterate (name bindings &body body)
`(labels ((,name ,(mapcar #'first bindings)
,@body))
(,name ,@(mapcar #'second bindings))))
(defmethod output-files :around ((operation compile-op)
(c cl-source-file))
(let* ((source-pathname (component-pathname c))
(default-pathname (car (call-next-method)))
(type (pathname-type default-pathname)))
(iterate iter ((translations *system-configuration-paths*))
(let ((translation (first translations)))
(cond ((null translations) default-pathname)
((pathname-prefix-p (first translation) default-pathname)
(list
(translate-pathname source-pathname
(merge-pathnames
(make-pathname :directory
'(:relative :wild-inferiors)
:type
:wild)
(first translation))
(merge-pathnames
(make-pathname :directory
'(:relative :wild-inferiors)
:type
type)
(second translation)))))
(t
(iter (rest translations))))))))
==>END<====================================
Now I can put asdf-installable packages (in the tarball sense) under
/home/bjorn/share/common-lisp/src & symlink the .asd file to
/home/bjorn/share/common-lisp/system. That is all that is necessary to
be able to work with it in lisp. In cmucl I can now just write (asdf:oos
'asdf:load-op :cl-ppcre) to eg load the cl-ppcre library. I meant to
expand on the code to make it work with defsystem and clisp as well,
but I haven't gotten around to it yet. Half the point is trying to
parameterize the directories where source, binaries & system
definitions exist. For instance, the *system-configuration-paths*
variable above can have several directory pairs, and the right ones
will be used (eg one can have both /home/user/.../ dirs and
/usr/local/.../ dirs). (Sorry about the iterate macro; I haven't
really learned LOOP yet.)
A comment on the broader issue discussed in this thread: I would like
to see some sort of agreed-upon (informal) standards developed for CL
on Unix. Standardized places where source and binary files go in the
file system, perhaps some standardized environment variables. Compare
with C: anyone writing or installing a C library, or packaging a
library for a distro, can count on the basic directory structure, with
/.../{lib,include}, can count on environment variables like CC, LD_*,
etc. I think more of a de facto standard in this area for CL would
make it much easier for people to use different
administration/installation tools, different distro packaging systems,
and lots of other issues like that.
Björn
Christopher C. Stacy
Björn> A comment on the broader issue discussed in this thread: I would like
Björn> to see some sort of agreed-upon (informal) standards developed for CL
Björn> on Unix. Standardized places where source and binary files go in the
Björn> file system, perhaps some standardized environment variables.
Björn> Compare with C: anyone writing or installing a C library,
Björn> or packaging a library for a distro, can count on the basic
Björn> directory structure, with /.../{lib,include}, can count on
Björn> environment variables like CC, LD_*, etc. I think more of a de
Björn> facto standard in this area for CL would make it much easier
Björn> for people to use different administration/installation tools,
Björn> different distro packaging systems, and lots of other issues
Björn> like that.
This is what logical pathnames are supposed to be for.
The installation procedure is supposed to look in some standard
place to find or put the logical translation host definition.
Pascal Costanza
Igor Carron wrote:
> Christopher makes a statement on the current state of the libraries in
> Lisp. I make another statement about how it is somehow bizarre that
> Lisp being branded by this community as being a very powerful tool
> (most probably rightly so), that after some 40 years after its
> introduction, there seems to be little more than some ad-hoc way to
> deal with the complexity alluded to in this thread. I don't think I
> said anything else.
Lisp has had its main quantum leaps at times when it wasn't clear at all
that Unixy operating systems - including DOS & Windows - would "win",
i.e the 60's, 70's and 80's. Linux and Windows are relatively recent
phenomenons that evolved in the 90's - these were times when Lisp
suffered from the backlash of AI.
The combination of Common Lisp + Unix/Windows + Open Source is a very
recent evolution. Until the 90's, Common Lisp has been a language that
was mainly driven by commercial vendors. It is only since recently, that
people have started to pick up Common Lisp because they have learned
from languages like Python and Ruby that programming convenience can be
far more important than micro-efficiency. Since this is a very "young"
phenomenon, the infrastructure for newbies is far from perfect. This has
both advantages and disadvantages. One of the advantages is that you can
very quickly make a good name for yourself by starting to contribute.
> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
>
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."
Well, but it doesn't. Look out for personal / free editions of
commercial Common Lisp implementation that offer an above average newbie
experience. Don't feel hindered by the fact that the non-free editions
are typically very expensive. If your goal is to learn the language in
the first place, these are excellent options. You can change your mind
later on if you want or need to. Lisp is an extremely flexible language,
which means that a vendor lock-in is not very likely, at least not at
the same degree as is the case for other languages.
You might even find out that commercial implementations are good options
for later projects. Open Source is not a silver bullet.
Björn Lindberg
Yes, but I think there should also be a Unix standard for pathnames
and environment variables. If these are mapped to by logical
pathnames[1], and these logical pathnames perhaps are stanadrized over
other platforms as well, then all the better, but I still think a more
standardized approach on Unix would be good.
I have a perhaps slightly different perspective than most, since I am
running Lisp on Linux From Scratch. It means that I basically compile
all my software from tarballs, and I am not using any package
system. From this perspective, most tarballs with C programs are
self-contained; they can be compiled and installed by "./configure;
make; make install". This is possible in part, as I see it, because
such standards as I was alluding to above does exist for C on
Unix. You may say that Linux From Scratch users are an insignificant
and uniportant part of the CL user base, but an LFSer is doing
something very similar to what a package maintainer for a distribution
is doing, namely preparing a program package for a platform. If we
want it to be easy to create and maintain packages for different Unix
platforms/distributions, I think this part has to be standarized and
easy, and it is this I am aiming towards when I am talking about
standardizing a few things such as file system structure and
environment variables[2].
[1] I actually did try to use logical pathnames at first for my hack I
included in the post you responded to, but I was hesitant, because
AFAICT, logical pathnames cannot cope with such things as mixed-case
file names and certain characters in filenames, and I cannot guarantee
that a library writer will not name files in a package in such a way
that logical pathnames cannot be used to refer to them.
[2] Here is a not well thought out quick suggestion for a proposal: In
a standard Unix CL installation, library code should reside in the
following locations:
/usr/share/common-lisp/src/
/usr/share/common-lisp/system/
/usr/lib/common-lisp/<implementation name>/
Similar locations could exist for the /usr/local/ hierarchy for local
installations.
An environment variable called COMMON_LISP_FEATURES could function
like a shell equivalent to the *features* variable, and could eg
include the available implementations ("cmucl clisp sbcl").
Björn
Tayssir John Gabbour
> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
>
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."
I think you are mistating your criticism. I doubt anyone lied to you
about the state of Lisp. The language is huge, and most of it is
"libraries." The fucker has batteries. But only until it gets to
interacting with outside systems, which has been an enormously moving
target recently and you must solve through FFI or whatever.
There is a sense that Lisp wants to have a system all to itself, but
right now we're in the diaspora.
However, lispers tend to underestimate the intelligence required to
make a system that works. I used to get into flamewars here about
Windows because lispers tend to sound like Pythonistas revulsed over
parentheses when they speak of it.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=5627c6fa.0307200237.4acaf99c%40posting.google.com
It is quite fun to write a pretty system from scratch, without the
need for backwards compat. Especially when you control the damn
hardware. Microsoft took the tack of having none of these advantages,
and further underpricing their OS (a double-edged sword -- it leads to
devaluation). And for all that work, they actually changed the world
for the better. In fact, Gates was right for claiming some credit for
gnu/Linux's success -- MSFT forced PC hardware companies to be
reasonably standardized, which is really an artificial situation.
gnu/Linux users would be in a lot more pain if this were not so.
james anderson
Björn Lindberg wrote:
>
> cst...@news.dtpq.com (Christopher C. Stacy) writes:
>
> > >>>>> On 28 Dec 2003 01:28:40 +0100, Björn Lindberg ("Björn") writes:
> > Björn> A comment on the broader issue discussed in this thread: I would like
> > Björn> to see some sort of agreed-upon (informal) standards developed for CL
> > Björn> on Unix. Standardized places where source and binary files go in the
> > Björn> file system, perhaps some standardized environment variables.
> >
> > Björn> Compare with C: anyone writing or installing a C library,
> > Björn> or packaging a library for a distro, can count on the basic
> > Björn> directory structure, with /.../{lib,include}, can count on
> > Björn> environment variables like CC, LD_*, etc. I think more of a de
> > Björn> facto standard in this area for CL would make it much easier
> > Björn> for people to use different administration/installation tools,
> > Björn> different distro packaging systems, and lots of other issues
> > Björn> like that.
> >
> > This is what logical pathnames are supposed to be for.
> > The installation procedure is supposed to look in some standard
> > place to find or put the logical translation host definition.
>
> Yes, but I think there should also be a Unix standard for pathnames
> and environment variables. If these are mapped to by logical
> pathnames[1], and these logical pathnames perhaps are stanadrized over
> other platforms as well, then all the better, but I still think a more
> standardized approach on Unix would be good.
unless it is implemented in terms of ansi behaviour, the question remains,
good for what?
>
> ...
>
?
> [1] I actually did try to use logical pathnames at first for my hack I
> included in the post you responded to, but I was hesitant, because
> AFAICT, logical pathnames cannot cope with such things as mixed-case
> file names and certain characters in filenames, and I cannot guarantee
> that a library writer will not name files in a package in such a way
> that logical pathnames cannot be used to refer to them.
>
i thought this thread was about problem-free, portable library installation.
if a library writer has chosen a non-portable syntax to name source files,
they have declared the library to be non-portable. what is the benefit of
tailoring a build system to that goal?
> [2] Here is a not well thought out quick suggestion for a proposal: In
> a standard Unix CL installation, library code should reside in the
> following locations:
>
> /usr/share/common-lisp/src/
> /usr/share/common-lisp/system/
> /usr/lib/common-lisp/<implementation name>/
>
> Similar locations could exist for the /usr/local/ hierarchy for local
> installations.
>
> An environment variable called COMMON_LISP_FEATURES could function
> like a shell equivalent to the *features* variable, and could eg
> include the available implementations ("cmucl clisp sbcl").
what's an environment variable?
...
Björn Lindberg
Good for (1) anyone implementing or maintaining an implementation of
Lisp on Unix, such that it will easily interoperate with other Lisp
facilities available on Unix, (2) anyone authoring a library for Lisp
on Unix, (3) anyone maintaining packages (in the distro sense) of (1)
or (2) for a specifix Unix system/distribution, (4) etc...
> > [1] I actually did try to use logical pathnames at first for my hack I
> > included in the post you responded to, but I was hesitant, because
> > AFAICT, logical pathnames cannot cope with such things as mixed-case
> > file names and certain characters in filenames, and I cannot guarantee
> > that a library writer will not name files in a package in such a way
> > that logical pathnames cannot be used to refer to them.
> >
>
> i thought this thread was about problem-free, portable library installation.
> if a library writer has chosen a non-portable syntax to name source files,
> they have declared the library to be non-portable. what is the benefit of
> tailoring a build system to that goal?
I am sorry if I was unclear. I was restricting the scope to talk about
substandards specifically for Unix. I am well aware that there are
other operating systems out there, but I don't see how they get hurt
just because we make things a bit easier on Unix. Ideally, this Unix
substandard would of course blend well with more general approaches.
> > [2] Here is a not well thought out quick suggestion for a proposal: In
> > a standard Unix CL installation, library code should reside in the
> > following locations:
> >
> > /usr/share/common-lisp/src/
> > /usr/share/common-lisp/system/
> > /usr/lib/common-lisp/<implementation name>/
> >
> > Similar locations could exist for the /usr/local/ hierarchy for local
> > installations.
> >
> > An environment variable called COMMON_LISP_FEATURES could function
> > like a shell equivalent to the *features* variable, and could eg
> > include the available implementations ("cmucl clisp sbcl").
>
> what's an environment variable?
It is an important concept in the Unix environment. I suggest that
Common Lisp on Unix should standardize its use for Lisp purposes.
Björn
Edi Weitz
> i thought this thread was about problem-free, portable library
> installation. if a library writer has chosen a non-portable syntax
> to name source files, they have declared the library to be
> non-portable.
Most "interesting" libraries (the ones that people on c.l.l are asking
about) are non-portable anyway. As soon as you have to deal with
sockets, foreign functions or anything that isn't a standard character
you are non-portable.
Edi.
Gareth McCaughan
[Björn Lindberg:]
>> [1] I actually did try to use logical pathnames at first for my hack I
>> included in the post you responded to, but I was hesitant, because
>> AFAICT, logical pathnames cannot cope with such things as mixed-case
>> file names and certain characters in filenames, and I cannot guarantee
>> that a library writer will not name files in a package in such a way
>> that logical pathnames cannot be used to refer to them.
>
> i thought this thread was about problem-free, portable library installation.
> if a library writer has chosen a non-portable syntax to name source files,
> they have declared the library to be non-portable. what is the benefit of
> tailoring a build system to that goal?
Portability is not all-or-nothing. It may be useful to have a
build system that can accommodate minor infractions of portability
by library authors.
>> [2] Here is a not well thought out quick suggestion for a proposal: In
>> a standard Unix CL installation, library code should reside in the
>> following locations:
>>
>> /usr/share/common-lisp/src/
>> /usr/share/common-lisp/system/
>> /usr/lib/common-lisp/<implementation name>/
>>
>> Similar locations could exist for the /usr/local/ hierarchy for local
>> installations.
>>
>> An environment variable called COMMON_LISP_FEATURES could function
>> like a shell equivalent to the *features* variable, and could eg
>> include the available implementations ("cmucl clisp sbcl").
>
> what's an environment variable?
Something available on every Unix-like system in the world.
Observe the word "Unix" in the paragraph beginning "[2]".
--
Gareth McCaughan
.sig under construc
james anderson
if the library is an interface<em><bold>to</bold> the operating system<em>, i agree.
any ""interesting"" library which, despite that is not an interface to the
operating system, is written from this point of view, is not part of the
solution. it is part of the problem.
one of my ruder surprises of late was to discover collections of files which
purport to be clx distributions, but which have been "ported" such that day-1
compatibility was eliminated.
...
james anderson
Björn Lindberg wrote:
>
> james anderson <james.a...@setf.de> writes:
>
> ...
> >
> > i thought this thread was about problem-free, portable library installation.
> > if a library writer has chosen a non-portable syntax to name source files,
> > they have declared the library to be non-portable. what is the benefit of
> > tailoring a build system to that goal?
>
> I am sorry if I was unclear. I was restricting the scope to talk about
> substandards specifically for Unix. I am well aware that there are
> other operating systems out there, but I don't see how they get hurt
> just because we make things a bit easier on Unix. Ideally, this Unix
> substandard would of course blend well with more general approaches.
my impression, from the occasions when i've worked with libraries which are
written from this point of view, is that ideal is an illusion.
>
> ...
> > >
> > > An environment variable called COMMON_LISP_FEATURES could function
> > > like a shell equivalent to the *features* variable, and could eg
> > > include the available implementations ("cmucl clisp sbcl").
> >
> > what's an environment variable?
the question was rhetorical.
>
> It is an important concept in the Unix environment. I suggest that
> Common Lisp on Unix should standardize its use for Lisp purposes.
to what end. (note, i did read the 1,2,3,4 in the response before elision.)
just because one can do this,
[tschichold:clisp/clisp-2003-12-26/build-20031226]
janson% ./clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2003
[1]> (getenv "COMMON_LISP_FEATURES")
NIL
[2]> (exit)
Bye.
[tschichold:clisp/clisp-2003-12-26/build-20031226]
janson%
does not mean that one is any where near to asking the correct questions to
address this
Welcome to Macintosh Common Lisp Version 4.3.1!
? (getenv "COMMON_LISP_FEATURES")
> Error: Undefined function GETENV called with arguments ("COMMON_LISP_FEATURES") .
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry applying GETENV to ("COMMON_LISP_FEATURES").
See the Restarts… menu item for further choices.
1 >
...
james anderson
Gareth McCaughan wrote:
>
> James Anderson wrote:
>
> [Björn Lindberg:]
> >> [1] I actually did try to use logical pathnames at first for my hack I
> >> included in the post you responded to, but I was hesitant, because
> >> AFAICT, logical pathnames cannot cope with such things as mixed-case
> >> file names and certain characters in filenames, and I cannot guarantee
> >> that a library writer will not name files in a package in such a way
> >> that logical pathnames cannot be used to refer to them.
> >
> > i thought this thread was about problem-free, portable library installation.
> > if a library writer has chosen a non-portable syntax to name source files,
> > they have declared the library to be non-portable. what is the benefit of
> > tailoring a build system to that goal?
>
> Portability is not all-or-nothing.
a library which purports to be portable should compile, load, and run in any
conformant lisp. this leaves room for bugs, and for the fact that the given
lisp likely only purports to confrom.
(please note the distinction wrt interfaces to the operating system in another
message.)
is there another definition for portability?
> It may be useful to have a
> build system that can accommodate minor infractions of portability
> by library authors.
agreed. it is, on the other hand, not productive for a build system to induce
library authors to formulate a build specification such that either it is, in
itself, non-portable, or the build system is not capable of interpreting it portably.
...
Greg Menke
> igorc...@yahoo.com (Igor Carron) wrote in message news:<ef3c551.03122...@posting.google.com>...
> > By the way, I surely do not advocate solving this library issue in the
>
> It is quite fun to write a pretty system from scratch, without the
> need for backwards compat. Especially when you control the damn
> hardware. Microsoft took the tack of having none of these advantages,
> and further underpricing their OS (a double-edged sword -- it leads to
> devaluation). And for all that work, they actually changed the world
> for the better. In fact, Gates was right for claiming some credit for
> gnu/Linux's success -- MSFT forced PC hardware companies to be
> reasonably standardized, which is really an artificial situation.
> gnu/Linux users would be in a lot more pain if this were not so.
Not quite. Windows benefited from the standardization and contributed
to it- but remember all the OS's preceeding Windows. IBM & Intel
pretty much did all the big PC standards up until the mid 90's- and
I'll be you a penny that OS/2 drove more of the fundamental
architecture of PC hardware than Windows did since Windows 3.x was all
Microsoft had for such a long time. There have been a few standards
that evolved since then, USB, WinModems, etc.. which Microsoft was
probably involved with and/or dominated but thats hardly a cause of
Linux's success. I think Microsoft is probably a major part of the
cause, but for a different reason; if they were not so dominant and so
monopolistic and writing such unportable, inflexible and low quality
software, then there wouldn't be as much pressure for an alternative.
Are you really asserting Windows is underpriced?
Gregm
Christophe Rhodes
> Christopher makes a statement on the current state of the libraries in
> Lisp.
I'm not sure -- are you referring to me here, or not? Both
Christopher Stacy and I have made statements on the current state of
library use in Free Lisps, and your wording below (talking about
"carper") points to me, since I'm the only one to have used that word
in this thread, but I'm not sure. If it is indeed me, note that the
confusion could be avoided by spelling my name correctly :-)
> Now let's go back to the complexity issue you are mentionning. A most
> intelligent student in cognitive science such as yourself tells us
> that the problem of context in our problem (whack-a-mole from the mole
> perspective) is complex but at some different level/quality as the
> much rehashed "Hanoi's tower" problem (well defined and known
> algorithm.) What makes you think that ?
From my perspective: experience. I know how to solve the Towers of
Hanoi problem; having tried, I don't have a complete solution to the
Make Lisp Libraries Easy To Use By Everyone problem. I have several
partial results, though.
> Most of the messages that have examples in this
> thread so far, show that setting up libraries can be handled with a
> lot of fortran like "if..then..else" or through the appropriate
> transformation of variable names within libraries (a feat I cannot see
> as overwhelming using Lisp). I also see the "combinatorial"
> complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
> possibilities so what ?
What you're missing here is that a solution to this problem at exactly
one point in time is no good. The solution has to be robust enough,
maintainable enough to be able to absorb changes to the external world
(new OSes, new versions of Lisp, new file systems [ha!]) with a
minimum of effort. If you simply "solve" the problem now with a large
CASE form, you will have in your hands a piece of code that will be
useless in six months' or a year's time.
> It is not because you cannot deal with this
> complexity that you should resort to name calling (carper) on people
> who might want to take a stab at it.
Since I used the word, I'd like to point out that it's the people who
only speak and do not act who merit the name. And there are rather a
lot of them. By all means, Just Do It.
> Again, I believe your analysis on the complexity of this issue is
> flawed. Moreover, if it is shared by most Lisp experts, your
> community is doomed. Shoot the messengers all you want.
There Is No Lisp Community. There's nothing there to doom. In that
sense, my message is much more positive than yours: the only way is
up.
Christophe Rhodes
> Edi Weitz wrote:
>>
>> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <james.a...@setf.de> wrote:
>>
>> > i thought this thread was about problem-free, portable library
>> > installation. if a library writer has chosen a non-portable syntax
>> > to name source files, they have declared the library to be
>> > non-portable.
>>
>> Most "interesting" libraries (the ones that people on c.l.l are asking
>> about) are non-portable anyway. As soon as you have to deal with
>> sockets, foreign functions or anything that isn't a standard character
>> you are non-portable.
>
> if the library is an interface<em><bold>to</bold> the operating
> system<em>, i agree.
What's an operating system? Please don't answer "just the kernel".
> any ""interesting"" library which, despite that is not an interface to the
> operating system, is written from this point of view, is not part of the
> solution. it is part of the problem.
You see no use for the MOP as decribed in the Art of the Metaobject
Protocol, then?
> one of my ruder surprises of late was to discover collections of
> files which purport to be clx distributions, but which have been
> "ported" such that day-1 compatibility was eliminated.
I see no-one stepping forward to maintain completely portable CLX. Do
you? In case you are under the misguided assumption that there is no
cost involved in such an endeavour, just think about the requirements
for efficiency a little.
Björn Lindberg
> Björn Lindberg wrote:
> >
> > james anderson <james.a...@setf.de> writes:
> >
> > ...
> > >
> > > i thought this thread was about problem-free, portable library installation.
> > > if a library writer has chosen a non-portable syntax to name source files,
> > > they have declared the library to be non-portable. what is the benefit of
> > > tailoring a build system to that goal?
> >
> > I am sorry if I was unclear. I was restricting the scope to talk about
> > substandards specifically for Unix. I am well aware that there are
> > other operating systems out there, but I don't see how they get hurt
> > just because we make things a bit easier on Unix. Ideally, this Unix
> > substandard would of course blend well with more general approaches.
>
> my impression, from the occasions when i've worked with libraries which are
> written from this point of view, is that ideal is an illusion.
So, independent of there being any truly portable standard for build &
install systems, it is a bad thing if there exists one for Unix? I am
advocating standardising very low level things, for other layers to
build on. I fail to see how this can be a bad thing.
> > > > An environment variable called COMMON_LISP_FEATURES could function
> > > > like a shell equivalent to the *features* variable, and could eg
> > > > include the available implementations ("cmucl clisp sbcl").
> > >
> > > what's an environment variable?
>
> the question was rhetorical.
I guessed as much.
> > It is an important concept in the Unix environment. I suggest that
> > Common Lisp on Unix should standardize its use for Lisp purposes.
>
> to what end. (note, i did read the 1,2,3,4 in the response before elision.)
>
> just because one can do this,
> [ snip example regarding environment variables ]
I will give you an example use case. Suppose that I have three
different Lisps on my Unix box (eg cmucl, sbcl & clisp). I want to use
my build system to install a new Lisp library. Perhaps I give the
commands at the shell prompt, through a GUI program or at a Lisp REPL,
but I want to be able to build the library for all my Lisps by issuing
one command. I do not want to have to manually start up an incarnation
of each Lisp and issue commands from them. Thus, my build system needs
infromation about which Lisps are installed on my box. This
information is system information, not information from within any of
my Lisps. I cannot count on any one of my Lisps being able to present
it. Such system information can, on Unix, be made available through
environment variables. I am proposing that this system interface be
standardised, so that there can exist different build/install systems,
or different layers of them, that all share the same interface. On the
Mac, I guess there is some other way to make this kind of infromation
available, and then a more system independent layer could abstract
away the mechanism, and work on both Unix and Mac.
In the same way, even if there exists a Unix file system hierarchy
standard for CL as I suggested earlier, nothing prevents there being a
higher level layer which maps some standardised logical pathnames to
this directory structure, and thus is portable over different
platforms. The Unix substandard could be very useful at its level
without interfering at all with higher layers. Au contraire, the Unix
substandard would probably help build a higher level layer which will
work well on Unix (as well as other platforms of course).
So, in conclusion, I think we are discussing different layers of the
issue. What I don't see is why you think that standardising the layer
I am talking about would complicate anything at a higher level.
Björn
Gareth McCaughan
> > > i thought this thread was about problem-free, portable library installation.
> > > if a library writer has chosen a non-portable syntax to name source files,
> > > they have declared the library to be non-portable. what is the benefit of
> > > tailoring a build system to that goal?
> >
> > Portability is not all-or-nothing.
>
> a library which purports to be portable should compile, load, and run in any
> conformant lisp. this leaves room for bugs, and for the fact that the given
> lisp likely only purports to confrom.
>
> (please note the distinction wrt interfaces to the operating system in another
> message.)
>
> is there another definition for portability?
Application A is more portable than application B if the effort
required to make A run on a new system is less than that required
to make B run on a new system. (It might be advisable to normalize
with respect to the sizes of A and B, somehow.) An application is
maximally portable if there exists (even in potentiality) no other
application that does substantially the same thing in substantially
the same way but which is more portable.
Being able to compile (without intervention), load and run (correctly)
on any conformant Lisp is roughly equivalent to being maximally portable,
for that class of applications whose basic functionality doesn't
prevent that. But, for instance, an application whose purpose is to
dump live Linux filesystems by definition cannot run correctly in
any system that isn't capable of *having* live Linux filesystems,
so such an application could be maximally portable (by my definition)
without being portable (by yours).
> > It may be useful to have a
> > build system that can accommodate minor infractions of portability
> > by library authors.
>
> agreed. it is, on the other hand, not productive for a build system to induce
> library authors to formulate a build specification such that either it is, in
> itself, non-portable, or the build system is not capable of interpreting it portably.
Agreed. A good build system might permit, but issue warnings for,
such minor infractions.
james anderson
Gareth McCaughan wrote:
>
> ...
> >
> > is there another definition for portability?
>
> Application A is more portable than application B if the effort
> required to make A run on a new system is less than that required
> to make B run on a new system. (It might be advisable to normalize
> with respect to the sizes of A and B, somehow.) An application is
> maximally portable if there exists (even in potentiality) no other
> application that does substantially the same thing in substantially
> the same way but which is more portable.
>
> Being able to compile (without intervention), load and run (correctly)
> on any conformant Lisp is roughly equivalent to being maximally portable,
> for that class of applications whose basic functionality doesn't
> prevent that. But, for instance, an application whose purpose is to
> dump live Linux filesystems by definition cannot run correctly in
> any system that isn't capable of *having* live Linux filesystems,
> so such an application could be maximally portable (by my definition)
> without being portable (by yours).
no, such an application is not portable. it does not even purport to being
portable. the definition
portable adj. (of code) required to produce equivalent results and observable
side effects in all conforming implementations.[0]
is not mine. should it be useful to talk about application which produce
"equivalent results and observable side effects" given constraints in addition
to implementation conformance, it would be appropriate to use another word.
...
[0] http://www.lispworks.com/reference/HyperSpec/Body/26_glo_p.htm#portable
james anderson
Björn Lindberg wrote:
>
> ...
> >
> > my impression, from the occasions when i've worked with libraries which are
> > written from this point of view, is that ideal is an illusion.
>
> So, independent of there being any truly portable standard for build &
> install systems, it is a bad thing if there exists one for Unix? I am
> advocating standardising very low level things, for other layers to
> build on. I fail to see how this can be a bad thing.
>
to quote from another respose:
> ... it is, on the other hand, not productive for a build system to induce
> library authors to formulate a build specification such that either it is, in
> itself, non-portable, or the build system is not capable of interpreting it portably.
>
...
james anderson
Christophe Rhodes wrote:
>
> james anderson <james.a...@setf.de> writes:
>
> > Edi Weitz wrote:
> >>
> >> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <james.a...@setf.de> wrote:
> >>
> >> > i thought this thread was about problem-free, portable library
> >> > installation. if a library writer has chosen a non-portable syntax
> >> > to name source files, they have declared the library to be
> >> > non-portable.
> >>
> >> Most "interesting" libraries (the ones that people on c.l.l are asking
> >> about) are non-portable anyway. As soon as you have to deal with
> >> sockets, foreign functions or anything that isn't a standard character
> >> you are non-portable.
> >
> > if the library is an interface<em><bold>to</bold> the operating
> > system<em>, i agree.
>
> What's an operating system? Please don't answer "just the kernel".
there is no need to prevaricate. to "<em>deal</em> with sockets, foreign
functions or anything that isn't a standard character" requires that the
library afford more than a wrapper for that which the underlying
implementation offers. unless, of course, the goal is to sell a particular
implementation. if the goal is to provide a lisp library, one has not produced
a useful, interesting library until one admits portability as part of the problem.
>
> > any ""interesting"" library which, despite that is not an interface to the
> > operating system, is written from this point of view, is not part of the
> > solution. it is part of the problem.
>
> You see no use for the MOP as decribed in the Art of the Metaobject
> Protocol, then?
you misconstrue. i would see no use for a mop which required that the
application use facilities which are present in one implementation only. the
art of the metaobject protocol describes a library which is both interesting
and ostensibly portable.
>
> > one of my ruder surprises of late was to discover collections of
> > files which purport to be clx distributions, but which have been
> > "ported" such that day-1 compatibility was eliminated.
>
> I see no-one stepping forward to maintain completely portable CLX. Do
> you?
it does not matter whether or not someone is willing or able to do that. no, i
did not read through the code to attempt to understand why someone identified
expediency with necessity. i remain surpised at seeing code, which derived
from source which i had used over a decade ago in more than one lisp
implementation, which was now non-portable.
...
Edi Weitz
> portable adj. (of code) required to produce equivalent results and
> observable side effects in all conforming implementations.[0]
Nice. That probably means that /every/ program is portable because
there clearly is no conforming implementation (at least none that I
know of).
To remind you: This thread started with Mr. Stacy complaining that it
is too hard to install a certain library. He specifically mentioned
CLISP and Corman Lisp which both definitely aren't conforming. I
myself remember adding #+/#- in various places of my (otherwise
portable) code to cater to these implementations. Do you suggest it
would be more helpful to prospective users if all libraries were 100%
"portable" but wouldn't run on any existing platform?
Edi.
Tayssir John Gabbour
> Not quite. Windows benefited from the standardization and contributed
> to it- but remember all the OS's preceeding Windows. IBM & Intel
> pretty much did all the big PC standards up until the mid 90's- and
> I'll be you a penny that OS/2 drove more of the fundamental
> architecture of PC hardware than Windows did since Windows 3.x was all
> Microsoft had for such a long time. There have been a few standards
> that evolved since then, USB, WinModems, etc.. which Microsoft was
> probably involved with and/or dominated but thats hardly a cause of
> Linux's success.
Ferguson, _High Stakes, No Prisoners_
> Are you really asserting Windows is underpriced?
Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.
> if they were not so dominant and so
> monopolistic and writing such unportable, inflexible and low quality
> software, then there wouldn't be as much pressure for an alternative.
You forgot, they eat babies. The cute ones.
- - - -
Food for thought: Windows rode a price revolution. So did gnu/Linux.
And likely Unix. Note the the chapter before the conclusion of
Kernighan and Mashey's paper "The Unix Programming Environment" for a
hint.
james anderson
Edi Weitz wrote:
>
>..
>
> To remind you: This thread started with Mr. Stacy complaining that it
> is too hard to install a certain library. He specifically mentioned
> CLISP and Corman Lisp which both definitely aren't conforming. I
> myself remember adding #+/#- in various places of my (otherwise
> portable) code to cater to these implementations. Do you suggest it
> would be more helpful to prospective users if all libraries were 100%
> "portable" but wouldn't run on any existing platform?
on the contrary. i entered this discussion to question the notion, that one
has accomplished something fundamental if one has adressed portability among
unix implementations only. i fail to see how the assertion, that purported
portability cannot depend on features which are either not portable or are
non-conformant could somehow lead to a claim that a purportedly portable
application should not run in an implementation which purports but does not
achieve conformance.
i am fairly good speaking terms with read-time conditionalization. where it is
possible to port an application by extending a #+/#- "clause", that is good.
where one can predict, in advance, that such adaptation will likely be
difficult, if not impossible, that is not good.
>
> Edi.
Pascal Bourguignon
> [tschichold:clisp/clisp-2003-12-26/build-20031226]
> NIL
> Welcome to Macintosh Common Lisp Version 4.3.1!
> ? (getenv "COMMON_LISP_FEATURES")
> > Error: Undefined function GETENV called with arguments ("COMMON_LISP_FEATURES") .
Another example of the kind of items I don't like in the Common-Lisp
specification. It says that a conformant implementation is free to
use any implementation defined package in COMMON-LISP-USER.
This has the negative consequences that:
1- I have to do this first thing in ALL the init rc files of all the
Common-Lisp implementations I use:
(MAPC (LAMBDA (USED) (UNUSE-PACKAGE USED "COMMON-LISP-USER"))
(REMOVE (FIND-PACKAGE "COMMON-LISP")
(COPY-SEQ (PACKAGE-USE-LIST "COMMON-LISP-USER"))))
2- Unsuspecting users of clisp believe that they're entitled to write:
(GETENV "HOME")
while they shoud write:
(EXT:GETENV "HOME")
and therefore, clearly documenting the fact that they're using
clisp specific EXT package.
Ok, nothing that some self imposed discipline cannot solve, but the
point is exactly here: available free libraries lack the homogeneity
and well defined interfaces that come with self discipline since
there's no imposed discipline.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postm...@sco.com ******************
Pascal Bourguignon
We don't need portable libraries. We need portable interfaces!
(Well, once there's a portable FFI (UFFI being a step in the right
direction, but based on a lowest, common denominator), you can easily
implement libraries portable accros a range of Common-Lisp
implementations running on a same system class).
Pascal Bourguignon
> > what's an environment variable?
>
> Something available on every Unix-like system in the world.
> Observe the word "Unix" in the paragraph beginning "[2]".
Last time I looked at MS-DOS (ie, circa 1985), ISTR that there was
environment variables there too...
Edi Weitz
> We don't need portable libraries. We need portable interfaces!
No, we need people who say that we need portable interfaces. Much
better.
Edi.
Gareth McCaughan
> Gareth McCaughan <gareth.m...@pobox.com> writes:
> > > what's an environment variable?
> >
> > Something available on every Unix-like system in the world.
> > Observe the word "Unix" in the paragraph beginning "[2]".
>
> Last time I looked at MS-DOS (ie, circa 1985), ISTR that there was
> environment variables there too...
I didn't say "only on Unix-like systems".
Gareth McCaughan
> > > is there another definition for portability?
> >
> > Application A is more portable than application B if the effort
> > required to make A run on a new system is less than that required
> > to make B run on a new system. (It might be advisable to normalize
> > with respect to the sizes of A and B, somehow.) An application is
> > maximally portable if there exists (even in potentiality) no other
> > application that does substantially the same thing in substantially
> > the same way but which is more portable.
> >
> > Being able to compile (without intervention), load and run (correctly)
> > on any conformant Lisp is roughly equivalent to being maximally portable,
> > for that class of applications whose basic functionality doesn't
> > prevent that. But, for instance, an application whose purpose is to
> > dump live Linux filesystems by definition cannot run correctly in
> > any system that isn't capable of *having* live Linux filesystems,
> > so such an application could be maximally portable (by my definition)
> > without being portable (by yours).
>
> no, such an application is not portable. it does not even purport to being
> portable. the definition
>
> portable adj. (of code) required to produce equivalent results and observable
> side effects in all conforming implementations.[0]
(Note: taken from the HyperSpec.)
> is not mine. should it be useful to talk about application which produce
> "equivalent results and observable side effects" given constraints in addition
> to implementation conformance, it would be appropriate to use another word.
The Hyperspec is a wonderful thing, but I see no reason to require
that all discussions of Common Lisp use its definitions in all
contexts. I think my definition is clearly more useful than the
HyperSpec one in most contexts.
Consider two applications. Both are designed to run only on Unix-like
systems. One of them has been written with care to make the minimum
set of assumptions beyond that. The other has been written to run
happily in CMUCL 18e on Debian Linux, and no attempt has been made
to make it easy to transfer to any other implementation or any other
operating system. The definition in the HyperSpec simply says: neither
of these programs is portable. It offers no way of saying that the
second is less portable than the first. Why should I prefer that over
my definition?
If there were something wrong with writing programs designed for
a particular subset of all possible platforms, then indeed it might
be better to use the term "portable" only for programs that will
(modulo bugs) run on any platform at all. So far as I can tell,
that is not the case.
Incidentally, I seem to recall that the following is a conforming
Common Lisp implementation.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
fprintf(stderr, "Out of memory.\n");
return 1;
}
In which case there are *no* portable programs according to the
definition you quoted above.
Björn Lindberg
I read it the first time, but I still don't see what it has to do with
what I am saying. From the UI of a build/install system all the way
down to the metal, along the way there will be portable layers,
partially portable layers and unportable layers, the last being the
layer that communicates directly with the underlying platform. What I
am talking about is that I see some gains to be had from standardising
this lowest layer *on the Unix platform*.
Here is another reason: Someone working on Unix *will* want to be able
to work with his Lisp system both "from the inside" and "from the
outside". I should be able to sit down at a new box and have some
intuitive notion of where in the file system different Lisp stuff is,
or which Lisps are installed. At least I think so. If I find a Lisp
library that for some reason isn't installable by some fancy
install/build method, I should still be able to manually make it fit
in nicely with the rest of the system. Since Common Lisp is not
exactly common on Unix today, I think a "standard" of some sort could
really succeed in being used. Watch all the pain that went into the
File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
such simple things as which file goes where on a Unix system. Wouldn't
it be great if when Common Lisp becomes really popular again, and is
installed on every box, things like the directory structure and
perhaps cross-implementation information was reasonably
standardised? :-)
(I'm looking forward to a Common Lisp chapter in the FHS. :-)
Björn
james anderson
Björn Lindberg wrote:
>
> ... Watch all the pain that went into the
> File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
> such simple things as which file goes where on a Unix system. Wouldn't
> it be great if when Common Lisp becomes really popular again, and is
> installed on every box, things like the directory structure and
> perhaps cross-implementation information was reasonably
> standardised? :-)
if you figure out how to express "cross-implementation information" in a
standardised form, that would be a good thing. i suggest that "standardized"
does not mix well with physical pathname namestrings and implementation
directly in terms of os-specific primitives.
Björn Lindberg
> Björn Lindberg wrote:
> >
> > ... Watch all the pain that went into the
> > File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
> > such simple things as which file goes where on a Unix system. Wouldn't
> > it be great if when Common Lisp becomes really popular again, and is
> > installed on every box, things like the directory structure and
> > perhaps cross-implementation information was reasonably
> > standardised? :-)
>
> if you figure out how to express "cross-implementation information" in a
> standardised form, that would be a good thing.
As far as I can see, and have explained, this cannot be done within
Lisp, it has to be done outside of Lisp, ie in the environment of the
platform. (Eg with Unix environment variables).
> i suggest that "standardized"
> does not mix well with physical pathname namestrings and implementation
> directly in terms of os-specific primitives.
Oh, I see. I mean standardised from a Unix perspective, not a Lisp
one.
Björn
Greg Menke
> Greg Menke <gregm...@toadmail.com> wrote in message news:<m3k74hr...@europa.pienet>...
> > Not quite. Windows benefited from the standardization and contributed
> > to it- but remember all the OS's preceeding Windows. IBM & Intel
> > pretty much did all the big PC standards up until the mid 90's- and
> > I'll be you a penny that OS/2 drove more of the fundamental
> > architecture of PC hardware than Windows did since Windows 3.x was all
> > Microsoft had for such a long time. There have been a few standards
> > that evolved since then, USB, WinModems, etc.. which Microsoft was
> > probably involved with and/or dominated but thats hardly a cause of
> > Linux's success.
>
> Ferguson, _High Stakes, No Prisoners_
>
>
> > Are you really asserting Windows is underpriced?
>
> Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.
Please humor me and provide some quotes.
> > if they were not so dominant and so
> > monopolistic and writing such unportable, inflexible and low quality
> > software, then there wouldn't be as much pressure for an alternative.
>
> You forgot, they eat babies. The cute ones.
You've obviously not spent enough time writing software for the Win32
API, using Visual Basic, or trying to sysadmin a Windows network with
more than a few machines.
Gregm
Stephen J. Bevan
> Apparently that's not the case. Despite your subject line, you (and your
> friends) _don't_ have any problems installing and programming in Lisp.
> (It might have helped clarify things if you had said so.)
The first paragraph in the message was :-
I would like to relate the following comments and suggestions to the
kind people who maintain the various downloadable libraries for Common
Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.
I'm not sure how much clearer it could have been.
Christophe Rhodes
Well, let me try to address this surprise, by doing the work of
reading through the code for you.
Firstly, you presumably accept on my word that there are elements of
CLX which must use extra-standard functionality. If you don't, of
course, we can stop having this discussion. Such functionality comes
in two parts: firstly, use of implementation-specific interfaces to
sockets; secondly, use of implementation-specific idioms and
optimization directives to ensure non-painful performance.
If one distributes code advertised as 'portable', even implicitly (by
the presence of many read-time conditionals, for instance), one takes
responsibility for functionality. If one wishes to make modifications
to a relatively complex codebase, it behooves the maintainer to test
that the modifications have not introduced a deleterious effect
anywhere. That "anywhere" becomes significantly harder to investigate
if access to the systems claimed is not available. I would therefore
argue that a responsible maintainer for a distribution of CLX would
only advertise functionality for which he feels able to be confident
about, and let the market of potential users offer testing facilities
and/or expertise for those systems not directly accessible.
As for "now non-portable" nature of CLX, please disabuse yourself of
this notion; it always was non-portable. It may be instructive for
you if you were to attempt to use the original CLX distribution in,
say, SBCL.
Tayssir John Gabbour
> > Ferguson, _High Stakes, No Prisoners_
> > Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.
>
> Please humor me and provide some quotes.
You didn't seem to be interested in bringing up any new points (I read
Slashdot too, you know), so when I cracked open the pricing book and
noticed how much the index sucked, I didn't think it worthwhile to do
exacting research, and just mentioned the book for anyone who might
want a worthwhile read in the bookstore.
Should I reduce a book to soundbites so we can have a nice flame?
Maybe gift you a little target to fire at? I seriously doubt that
approach actually works in reality. We'll just both be swallowed by
Usenet, a sea of forgotten arguments.
> > You forgot, they eat babies. The cute ones.
>
> You've obviously not spent enough time writing software for the Win32
> API, using Visual Basic, or trying to sysadmin a Windows network with
> more than a few machines.
That's because I know better than to do such things. In the same way,
I do not install every lisp library or gnu/Linux distro because these
things tend to improve with time. In particular, .net seems to be a
decent though limited system, and eventually the legacy Win32 api may
be written in terms of it.
Of course Windows has sharp edges. They employ 50k people, and no
matter how well they answer some interview puzzles, some will suck.
In fact, popularity often brings burdens.
Just the other day, I noticed a Mac dev complaining about Apple's
willingness to break backwards compat:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=98013&ixReplies=22
whereas Microsoft seems to have the problem that they bend over
backwards to keep it, which can lead to nonconformance to standards
and painful apis.
Sure, no doubt the Mac is currently nicer than Windows, but after
reading enough of Ted Nelson's writings recently, they both look the
same to me. Mac is more facist but more usable. Maybe Microsoft will
pull ahead with Longhorn, maybe not. Yawn.
rydis
> james anderson <james.a...@setf.de> writes:
> > if you figure out how to express "cross-implementation information" in a
> > standardised form, that would be a good thing.
>
> As far as I can see, and have explained, this cannot be done within
> Lisp, it has to be done outside of Lisp, ie in the environment of the
> platform. (Eg with Unix environment variables).
Keeping this information in an environment variable would, IMO, be
bad. Better to keep it in a file, or something at least accessible
as a file. When in unix, do as the eunuchs, or something.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Greg Menke
> Greg Menke <gregm...@toadmail.com> wrote in message news:<m3llowi...@europa.pienet>...
> > > You forgot, they eat babies. The cute ones.
> >
> > You've obviously not spent enough time writing software for the Win32
> > API, using Visual Basic, or trying to sysadmin a Windows network with
> > more than a few machines.
>
> That's because I know better than to do such things. In the same way,
> I do not install every lisp library or gnu/Linux distro because these
> things tend to improve with time. In particular, .net seems to be a
> decent though limited system, and eventually the legacy Win32 api may
> be written in terms of it.
So since you don't sit down and actually <use> the stuff you're
talking about, that makes you somehow well-informed about it?
Remember .net is there to solve a marketing problem, not a technical
one, Microsoft is bound religiously to keeping you off the OS so they
can control the languages and compilers too. .NET is there to keep
Java away.
> Of course Windows has sharp edges. They employ 50k people, and no
> matter how well they answer some interview puzzles, some will suck.
> In fact, popularity often brings burdens.
The problem is with Microsoft's management. If quality architecture
and quality implementation were important to them, thats what we would
have.
> Just the other day, I noticed a Mac dev complaining about Apple's
> willingness to break backwards compat:
> http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=98013&ixReplies=22
> whereas Microsoft seems to have the problem that they bend over
> backwards to keep it, which can lead to nonconformance to standards
> and painful apis.
The Windows api was painful from day 1 back in the Win 3.0 days. They
declined to fix and rationalize it with the first NT, and thus it is
what it is today. If backwards compatability is so well managed then
why do so many functions in the Win32 api have eratta for so many of
the different OS releases? And why do the testing people of any
organization that distributes software widely need to have every
version of Windows they support on as many different kinds of PC's
they can get their hands on?
> Sure, no doubt the Mac is currently nicer than Windows, but after
> reading enough of Ted Nelson's writings recently, they both look the
> same to me. Mac is more facist but more usable. Maybe Microsoft will
> pull ahead with Longhorn, maybe not. Yawn.
No doubt you've also avoided ever using a Mac and so understand it
much better than everyone else.
Gregm
rydis
> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
> > rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> >>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
> >>> logical-pathnames. I tried to find a way to report this but just found
> >>> the mailings lists....
> >>
> >> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
> >> you've defined a logical host called "HOME". "home:" is a search
> >> list.
>
> Oh, well that is even worse. The same structure as an logical-pathname
> is used in another way. How should a Lisp beginner know?
By taking a look in the documentation for the implementation. Search
lists, and the standard search lists, are described in the second
chapter, _Design Choices and Extensions_. (It isn't the same structure
as logical pathnames, by the way.)
<snip>
> But know that I know that this Search List exists (I did not even
> thought that one could overload the meaning of logical-pathnames,
> things get even worse now I can do
> a
> (ed "home:.cint_hist")
>
> and hemlock shows me the proper field but doing a
>
> (ed "test:.t1.txt") yields an error
Yes. Without reading the spec for LPN:s, I can't really say whether
it's standards-conformant, though I suspect it might be. It sure is
inconvenient, though.
> Well I do not know how you think about it, but for me that is an
> extremly poor interface.
No, it isn't, IMO. It might be just your understanding of your chosen
CL implementation that could be described that way.