Hi gang. I'm currently learning lisp, and getting somewhat far along,
to the point where I am fairly comfortable with the basic langauge[1].
My background is basically one of casual learning. Always tinkered with
computers as I was growing up (I'm 21 now...). Spent a few years part
timing at a local company hacking, and did a year at the local uni in
comp sci before deciding I wanted more from life than churning out C++
and Java[2]. As you might guess from those statements, I like Lisp
quite a bit. Makes programming FUN again, which for me is pretty much
the point. The only language I found to be close to this rewarding is
python, but once you start appreciating lisp, it starts to feel a bit
like a toy.
Anyway, I'm currently at a bit of a quandray. I've kinda gotten past
the point where small problems are of interest but yet not ready to
tackle really large projects that would result in real useable
software. I'm basically looking for suggestions for problems that would
be good learning expriments. Ideally, such problems could be tackled in
a single sitting in no more than, say, 100 lines of code. As a bit of
anexample, at http://cg2.org/poker.lisp you can see some code I wrote
today that implements the guts of a video poker simulation.
Alternatively, if there are any open source projects out there that
could use a hand, and are willing to put up with a newbie drop me a
line ;)
[1] - To put it in book terms, I'm read most of ANSI Common Lisp and
Practical Common Lisp, and am nibbling at On Lisp. That's not to say I
understand all of it, esp. CLOS and Macros, but I've got a good outline
at least...
[2] - For those additionally curious, I'm currently enrolled in the
Mechanical Engineering Technology program at my local community
college. Subject matter ranges from topics like CAD and PLC
programming, to basic electriciy and hydrualics. Lots of hands on
problem solving. Fun stuff. Lots of fun toys too.... (CNC machining is
rather neat...)
Nice code btw. I particularly like the way you did the count pairs
stuff so that your evaluate hand function ends up being very succint
and readable.
I see you've also done what I did when I wrote a blackjack game... used
a global deck of cards and done setf everywhere. I've started rewriting
the code without globals, you basically have to pass the decks around
in the code and think a lot harder about the flow of data, which is
imho a good thing.
Justin
Tyler Eaves <······@gmail.com> writes:
> Alternatively, if there are any open source projects out there that
> could use a hand, and are willing to put up with a newbie drop me a
> line ;)
Well, most open-source Lisp projects fit that description... :)
You may try grepping for the TODO string in SBCL source files. It
looks like there is a lot of useful work that a newbie could do.
Another possibility is to generate bindings for C/C++ libraries with
Verrazano:
http://common-lisp.net/project/fetter/
Kenny Tilton says that this is a great newbie project, and it has the
useful side effect of increasing the pool of Lisp libraries. I have
always been meaning to try this myself, but other stuff got in the
way. I will eventually give it a shot.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> Tyler Eaves <······@gmail.com> writes:
>
>> Alternatively, if there are any open source projects out there that
>> could use a hand, and are willing to put up with a newbie drop me a
>> line ;)
>
> Well, most open-source Lisp projects fit that description... :)
>
> You may try grepping for the TODO string in SBCL source files. It
> looks like there is a lot of useful work that a newbie could do.
TODO picks up some things, but FIXME is usually a better indicator of
work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
Christophe
Christophe Rhodes wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
>
>>Tyler Eaves <······@gmail.com> writes:
>>
>>
>>>Alternatively, if there are any open source projects out there that
>>>could use a hand, and are willing to put up with a newbie drop me a
>>>line ;)
>>
>>Well, most open-source Lisp projects fit that description... :)
>>
>>You may try grepping for the TODO string in SBCL source files. It
>>looks like there is a lot of useful work that a newbie could do.
>
>
> TODO picks up some things, but FIXME is usually a better indicator of
> work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
Shame on you. A newby is looking for a way to have some fun and you
suggest they strap on a harness and become a slave to one particular
Lisp implementation's bug fixes. Everybody!...
"999 bugs on the wall, 999 bugs. Fix one up, pass it around, 998 bugs on
the wall."
This should succeed in stopping all useful progress for a year or two,
your apparent goal.
Exactly how desperate are you yobbos to "save money" by exhausting
zillions of hours on a "free" implementation that you will suck the life
blood out of newbies to get it done? Could you all please move over to
Python?
Fuck SBCL or any particular Lisp implementation. Recommend something
interesting, ferchissakes. You remind me of those Google Summer of Code
proposals: "Fix SBCL bugs". Oh, be still my beating heart!
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
>> TODO picks up some things, but FIXME is usually a better indicator of
>> work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
>
> Shame on you. A newby is looking for a way to have some fun and you
> suggest they strap on a harness and become a slave to one particular
> Lisp implementation's bug fixes.
No, I don't.
> Fuck SBCL or any particular Lisp implementation. Recommend something
> interesting, ferchissakes. You remind me of those Google Summer of Code
> proposals: "Fix SBCL bugs".
I'm sorry that that's the impression you got from the Summer of Code
proposals I submitted; it certainly wasn't the intention behind any of
the proposals simply to fix one implementation's bugs, but rather to
explore interesting areas of implementation space. Fortunately, the
proposals I made are a matter of public record (the first five under
the Summer of Lisp:" subheading at
<http://www.lispnyc.org/summerofcode.html>, of which the first three
were sbcl-specific) so there's no need for anyone else to rely on your
judgment of the intention; anyone who cares can draw their own
conclusions.
(Some people find working on compiler and implementation issues
sufficiently interesting to submit applications to work on those
projects; as you know, they weren't selected for funding.)
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> (Some people find working on compiler and implementation issues
> sufficiently interesting to submit applications to work on those
> projects; as you know, they weren't selected for funding.)
Just for the record, I would have found the loop optimizations project
a lot of fun, back when I had time for "summer of ..." type of things.
Unlike most undergrad compiler work, this would be implementing an
interesting, useful analysis in an industrial-strength system -- a
great combination for those who enjoy both CS and engineering.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Christophe Rhodes wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>>TODO picks up some things, but FIXME is usually a better indicator of
>>>work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
>>
>>Shame on you. A newby is looking for a way to have some fun and you
>>suggest they strap on a harness and become a slave to one particular
>>Lisp implementation's bug fixes.
>
>
> No, I don't.
>
>
>>Fuck SBCL or any particular Lisp implementation. Recommend something
>>interesting, ferchissakes. You remind me of those Google Summer of Code
>>proposals: "Fix SBCL bugs".
>
>
> I'm sorry that that's the impression you got from the Summer of Code
> proposals I submitted; it certainly wasn't the intention behind any of
> the proposals simply to fix one implementation's bugs,...
Agreed, I misspoke, my actual impression was "Finish SBCL". But I see
your intention was...
> but rather to
> explore interesting areas of implementation space.
Sounds like you wanted a Genius Grant to do something that would be of
little value to anyone else, kind of like an obscure research paper. I
for one was looking for a little more beef for Lisp developers everywhere.
Lisp-NYC gathered a good-sized (twelve? fifteen?) group of venerables at
Lisp 2005 and solicited input from the general community. I for one was
surprised at the ones they picked, but hey, that's why we asked and we
went with their recommendations. Google did the last round of filtering
-- I forget which were submitted for Google's approval, but I do know
not all were approved by Google.
I honestly do recall any discussion of your proposals, except for my own
opposition. But that might not have come up in the roundtable
discussion, because we simply gave everyone all the proposals and asked
them which they thought should be recommended. If no one recommended
yours, their would have been no discussion. Again, I do not recall if
anyone in fact recommended yours at the roundtable. Certainly during the
internal Lisp-NYC discussions I spoke against. But I also spoke up
against two source-code steppers (one Slime, one Scheme) and they both
got approved (the roundtable like those).
> Fortunately, the
> proposals I made are a matter of public record (the first five under
> the Summer of Lisp:" subheading at
> <http://www.lispnyc.org/summerofcode.html>, of which the first three
> were sbcl-specific) so there's no need for anyone else to rely on your
> judgment of the intention; anyone who cares can draw their own
> conclusions.
>
> (Some people find working on compiler and implementation issues
> sufficiently interesting to submit applications to work on those
> projects; as you know, they weren't selected for funding.)
Some folks approached Lisp-NYC and the individuals such as myself who
had suggested projects to see if we liked their ideas, or even for ideas
to propose. Google did not recommend they do that, IIRC, but it worked
out well for those who thought to check with the mentors first.
Not that we did not recommend any projects that came out of the blue. In
fact, Rayiner's VZN was unsolicited and bumped one of my pet projects
because it was duplicative and better. This was disappointing to the
gent who had been working with me to shape a project around my less
ambitious idea.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>> Fuck SBCL or any particular Lisp implementation. Recommend
>>> something interesting, ferchissakes. You remind me of those Google
>>> Summer of Code proposals: "Fix SBCL bugs".
>> I'm sorry that that's the impression you got from the Summer of Code
>> proposals I submitted; it certainly wasn't the intention behind any of
>> the proposals simply to fix one implementation's bugs,...
>
> Agreed, I misspoke, my actual impression was "Finish SBCL".
That's still an odd impression to get from those projects, because it
seems unlikely to me that anyone can think that a couple of compiler
improvements would lead to a finished product. Still, it's worth
knowing that that's your view.
> But I see your intention was...
>
>> but rather to
>> explore interesting areas of implementation space.
>
> Sounds like you wanted a Genius Grant to do something that would be of
> little value to anyone else, kind of like an obscure research paper. I
> for one was looking for a little more beef for Lisp developers everywhere.
Maybe it sounds like that to you, but oddly enough I think that
enhancments to compilers can lead to beef for lisp developers
everywhere. For instance, it's now possible to write cryptographic
algorithms (and similar, like checksums, compression and so on) using
32-bit arithmetic in the obvious way in Lisp and have them perform at
hardware speeds, thanks to stuff that looks kind of like an obscure
research paper. Little value? Maybe, I don't know; it's tricky to
know what the value of anything is without doing it, but I don't think
it's that easy to dismiss out of hand.
> I honestly do recall any discussion of your proposals, except for my own
^ [not]
> opposition.
Thank you. [All I know about the discussion process is that I
received a phone call at about 3am local time on the deliberation day,
when I was in the land of Nod, which I believe was to ask for
clarifications].
> Again, I do not recall if anyone in fact recommended yours at the
> roundtable.
Fair enough.
> Certainly during the internal Lisp-NYC discussions I spoke against.
Out of interest, did you (personally) speak against all the project
proposals I made, or simply those relating to compiler work?
Christophe
On Tue, 11 Oct 2005 10:38:54 +0100, Christophe Rhodes <·····@cam.ac.uk> wrote:
> For instance, it's now possible to write cryptographic algorithms
> (and similar, like checksums, compression and so on) using 32-bit
> arithmetic in the obvious way in Lisp and have them perform at
> hardware speeds, thanks to stuff that looks kind of like an obscure
> research paper. Little value? Maybe, I don't know
Kenny would probably prefer to use the FFI for that stuff... :)
I for one think this is quite an achievement - especially if it works
kind of automatically and you don't have to jump through hoops.[1] I'd
be happy if my preferred Lisp implementation offered something
similar... :)
Cheers,
Edi.
[1] <http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-93.htm>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> I for one think this is quite an achievement - especially if it works
> kind of automatically and you don't have to jump through hoops.[1] I'd
> be happy if my preferred Lisp implementation offered something
> similar... :)
Second that. My preferred implementation provides what I consider
a pretty terrible kluge, with the result that my crypto code is
40x faster in CMUCL/SBCL than in it. Result, I'm now doing crypto
via FFI. And it lead to headaches and other obscure problems.
All in all, I think the lisp community is making tremendous progress,
given its current level of resources.
Christophe Rhodes wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>>Fuck SBCL or any particular Lisp implementation. Recommend
>>>>something interesting, ferchissakes. You remind me of those Google
>>>>Summer of Code proposals: "Fix SBCL bugs".
>>>
>>>I'm sorry that that's the impression you got from the Summer of Code
>>>proposals I submitted; it certainly wasn't the intention behind any of
>>>the proposals simply to fix one implementation's bugs,...
>>
>>Agreed, I misspoke, my actual impression was "Finish SBCL".
>
>
> That's still an odd impression to get from those projects, because it
> seems unlikely to me that anyone can think that a couple of compiler
> improvements would lead to a finished product.
You take me too literally. I will try again: "Work on SBCL"?
Mind you, that was just /my/ opinion. You do not need to fret over it so
much. I was the one who lobbied hard for Lisp-NYC to get a wide range of
input, and to be honest I was sorry I did, because I really disagreed
withe the projects favored by the roundtable. But that was the whole
idea, I consoled myself.
Now, fresh from the tail end of tonight's Lisp-NYC monthly meeting, I
must correct the record: I had been plannning to confess with great
embarrassment that I did not recall you applying for any SOC projects.
At the meeting I was told my Alzheimer's is not as bad as I feared: you
did not apply for any projects. You submitted project ideas for students
to choose from. If they wanted. Did that happen? Anyone? I thought I saw
students apply. Note that Google had a one-human model for mentors, but
we were just a loose connection of Lispnyks. The Lispnyk contact person
had to open his gmail account to us all to rank project applications
(not ideas). So I cannot now go back and refresh my memory.
>>Sounds like you wanted a Genius Grant to do something that would be of
>>little value to anyone else, kind of like an obscure research paper. I
>>for one was looking for a little more beef for Lisp developers everywhere.
>
>
> Maybe it sounds like that to you, but oddly enough I think that
> enhancments to compilers can lead to beef for lisp developers
> everywhere.
Fine. I am just a simple application programmer, left me cold. But I
also tried to cover the risk of personal bias by insisting Lisp-NYC
sample a larger population. Blessed with perfect timing of ILC 2005 we
totally did so in re the actual applications to do projects.
For instance, it's now possible to write cryptographic
> algorithms (and similar, like checksums, compression and so on) using
> 32-bit arithmetic in the obvious way in Lisp and have them perform at
> hardware speeds, thanks to stuff that looks kind of like an obscure
> research paper. Little value? Maybe, I don't know; it's tricky to
> know what the value of anything is without doing it, but I don't think
> it's that easy to dismiss out of hand.
Oh, it was easy for me, but only because I am an apps guy. This is
sales. Some folks will walk past your stall in the bazaar without even
looking, some will look and not break their stride, others will stop and
talk for an hour. I am an apps guy, never broke my stride.
> Out of interest, did you (personally) speak against all the project
> proposals I made, or simply those relating to compiler work?
What were the others? Anyway, there was not much discussion of the
project /proposals/. The applications were what we judged.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Christophe Rhodes wrote:
>>>
>>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>>
>>>>>Fuck SBCL or any particular Lisp implementation. Recommend
>>>>>something interesting, ferchissakes. You remind me of those Google
>>>>>Summer of Code proposals: "Fix SBCL bugs".
>>>>
>>>>I'm sorry that that's the impression you got from the Summer of Code
>>>>proposals I submitted; it certainly wasn't the intention behind any of
>>>>the proposals simply to fix one implementation's bugs,...
>>>
>>> Agreed, I misspoke, my actual impression was "Finish SBCL".
>> That's still an odd impression to get from those projects, because it
>> seems unlikely to me that anyone can think that a couple of compiler
>> improvements would lead to a finished product.
>
> You take me too literally. I will try again: "Work on SBCL"?
I'll buy that. (It was never the intention that any enhancement
coming from the SOC projects should have been untransferrable to other
implementations, but as a first approximation, the work under my
mentorship would have been done in SBCL because that's where I have
expertise.)
> Now, fresh from the tail end of tonight's Lisp-NYC monthly meeting, I
> must correct the record: I had been plannning to confess with great
> embarrassment that I did not recall you applying for any SOC projects.
> At the meeting I was told my Alzheimer's is not as bad as I feared: you
> did not apply for any projects. You submitted project ideas for students
> to choose from. If they wanted.
That's right.
> Did that happen? Anyone? I thought I saw students apply.
I received four distinct enquiries related to the project proposals I
made, all of which (I believe, but obviously I don't know for sure)
led to applications for the Google SOC via LispNYC. (I deduce that
there must have been at least one submitted application, otherwise I
wouldn't have found that someone attempted to contact me in the middle
of my night regarding it.)
Christophe
>>>>> "kt" == Kenny Tilton <·······@nyc.rr.com> writes:
csr> but rather to
csr> explore interesting areas of implementation space.
kt> Sounds like you wanted a Genius Grant to do something that would
kt> be of little value to anyone else, kind of like an obscure
kt> research paper. I for one was looking for a little more beef for
kt> Lisp developers everywhere.
well, it's unfortunate that this is being debated once everything is
all over, but I for one strongly disagree with your appraisal.
Certainly, some of the projects that Christophe suggested were
specific to SBCL, but they strike me as being more interesting &
useful than those implementation-specific projects that ended up
being chosen. Christophe also suggested two projects that are
neither SBCL-specific nor compiler related (protocol extensions for
CLX ; systems programming for CMUCL) that I find very interesting.
kt> Lisp-NYC gathered a good-sized (twelve? fifteen?) group of
kt> venerables at Lisp 2005 and solicited input from the general
kt> community. I for one was surprised at the ones they picked, but
kt> hey, that's why we asked and we went with their recommendations.
as an outside observer, my impression is that Lisp-NYC ran a
relatively opaque selection process that led to partially misguided
choices. My assessment is possibly based on incomplete information;
it is certainly colored by my negative reaction to Kenny's
inflammatory attitude.
--
Eric Marsden
Eric Marsden <············@free.fr> writes:
Christophe also suggested two projects that are
> neither SBCL-specific nor compiler related (protocol extensions for
> CLX ; systems programming for CMUCL) that I find very interesting.
The systems programming extensions for CMUCL was my contribution. I
do not know how any name other than my own ended up on that page, but
I wish somebody had consulted me before suggesting mentors, I would
have chosen a different set of individuals than those listed. On the
other hand, given how chaotic the whole selection process was I am not
surprised that such weird and careless things occurred.
> as an outside observer, my impression is that Lisp-NYC ran a
> relatively opaque selection process that led to partially misguided
> choices. My assessment is possibly based on incomplete information;
> it is certainly colored by my negative reaction to Kenny's
> inflammatory attitude.
Granted, there is a dearth of publicly accessible information about
the final selection process, but I don't think it was as misguided as
one may assume. As far as I remember, there was a bunch of qualified
and well-intentioned people who volunteered to evaluate proposals at
the past Lisp conference and I believe they made reasonable decisions.
I had no part in the evaluation, but I read all of the applications
submitted and I cannot say that after reviewing the applications that
I would have chosen much differently.
Eric Marsden <············@free.fr> writes:
> Christophe also suggested two projects that are
> neither SBCL-specific nor compiler related (protocol extensions for
> CLX ; systems programming for CMUCL) that I find very interesting.
I can't take credit for the second of those, though I too was
interested by it (and was not averse to being listed as a
mentor/advisor). I did also suggest a McCLIM-related project; I
cannot say that I would be surprised to learn that Kenny argued
against that, given his views expressed in this forum.
Christophe
Eric Marsden wrote:
> kt> Lisp-NYC gathered a good-sized (twelve? fifteen?) group of
> kt> venerables at Lisp 2005 and solicited input from the general
> kt> community. I for one was surprised at the ones they picked, but
> kt> hey, that's why we asked and we went with their recommendations.
>
> as an outside observer, my impression is that Lisp-NYC ran a
> relatively opaque selection process that led to partially misguided
> choices.
I gather then that you applaud my insistence that we sample a larger
audience. Thanks, I appreciate the recognition. :)
But apparently no good deed goes unpunished. Matt and Heow worked
feverishly to deal with a late selection of Lisp-NYC as a mentoring
organization. Just a few days notice, really. And not very clear
instructions at that. Maybe everyone went through that, because maybe
Google did not think to do SOC until the last minute before the US
summer break for schools.
> My assessment is possibly based on incomplete information;
> it is certainly colored by my negative reaction to Kenny's
> inflammatory attitude.
>
That's "Demon Kenny", OK?
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton schrieb:
> Christophe Rhodes wrote:
> > Paolo Amoroso <·······@mclink.it> writes:
> >>Tyler Eaves <······@gmail.com> writes:
> >>>Alternatively, if there are any open source projects out there that
> >>>could use a hand, and are willing to put up with a newbie drop me a
> >>>line ;)
> >>Well, most open-source Lisp projects fit that description... :)
> >>You may try grepping for the TODO string in SBCL source files. It
> >>looks like there is a lot of useful work that a newbie could do.
> > TODO picks up some things, but FIXME is usually a better indicator of
> > work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
> Shame on you. A newby is looking for a way to have some fun and you
> suggest they strap on a harness and become a slave to one particular
> Lisp implementation's bug fixes. Everybody!...
> This should succeed in stopping all useful progress for a year or two,
> your apparent goal.
Ahja
But isn't it so that every programmer want another project infront of
his nose instead of all the same boring lines?
So, a place, where unsolved problems or even bugs are listed could be
intressting, maybe sorted from easy to never-find.
This could also be a nice place for threads in here like "comment my
code" and a bit of competition can easy put some live to that. (see
summer-code). While as I know from my HD, there are code-lines I don't
like to touch anymore ...
Meanwhile the planet Lisp did what all other planets do: circle around
a fixed axis. So think about that (can be done as a wiki).
stefan
Christophe Rhodes <·····@cam.ac.uk> writes:
> TODO picks up some things, but FIXME is usually a better indicator of
> work needed (there are only 64 TODO items, but about 1000 FIXMEs...)
I had forgotten about that, thanks for the clarification.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
On Mon, 10 Oct 2005 10:54:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
> Another possibility is to generate bindings for C/C++ libraries with
> Verrazano:
>
> http://common-lisp.net/project/fetter/
>
> Kenny Tilton says that this is a great newbie project, and it has
> the useful side effect of increasing the pool of Lisp libraries.
Let me chime in here and say that I disagree. While creating bindings
for arbitrary C/C++ projects a newbie won't learn much interesting
stuff about Lisp. Also, if we just wrap every "interesting" library
out there we end up like Perl and Python - only that those are more
tightly integrated with C. IMHO it's much more rewarding to develop
"pure Lisp" replacements of C functionality - see projects like
(Portable) AllegroServe, salza/zip, CXML, cl-pdf, cl-md5, you name it.
All of these could have been implemented by interfacing with existing
C programs or libraries but only with a pure Lisp program do you get
full IDE support and an easy way to deliver your application.
YMMV, of course.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Mon, 10 Oct 2005 10:54:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
>
>
>>Another possibility is to generate bindings for C/C++ libraries with
>>Verrazano:
>>
>> http://common-lisp.net/project/fetter/
>>
>>Kenny Tilton says that this is a great newbie project, and it has
>>the useful side effect of increasing the pool of Lisp libraries.
>
>
> Let me chime in here and say that I disagree. While creating bindings
> for arbitrary C/C++ projects a newbie won't learn much interesting
> stuff about Lisp.
I agree. The whole point of Verrazano and the facilitatingly (?!) more
universal CFFI-Luis is to make C/C++ access thoroughly uninteresting.
OTOH, if a newby has some dream C/C++ library they would like to play
with from Lisp, then using vzn/cffi to get there will improve those
tools... there is nothing like real-world usage to unmask limitations in
tools.
> Also, if we just wrap every "interesting" library
> out there we end up like Perl and Python - only that those are more
> tightly integrated with C. IMHO it's much more rewarding to develop
> "pure Lisp" replacements of C functionality -
Nonsense. Suppose FTGL is a fine C++ library for displaying text in
OpenGL (it is). What value do you get out of a FTGL in Lisp? [Hint: none]
see projects like
> (Portable) AllegroServe, salza/zip, CXML, cl-pdf, cl-md5, you name it.
> All of these could have been implemented by interfacing with existing
> C programs or libraries but only with a pure Lisp program do you get
> full IDE support and an easy way to deliver your application.
IDE support for cl-pdf?! Whatever advantages you have in mind are
nothing compared to the effort of a Lisp port.
>
> YMMV, of course.
IDI.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
On Mon, 10 Oct 2005 09:55:53 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> Nonsense. Suppose FTGL is a fine C++ library for displaying text in
> OpenGL (it is). What value do you get out of a FTGL in Lisp?
I could repeat what I have said but why should I as you obviously
don't read it anyway?
> IDE support for cl-pdf?! Whatever advantages you have in mind are
> nothing compared to the effort of a Lisp port.
Hint: cl-pdf is already written in pure Lisp - there's no need to port
it.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz เขียน:
> On Mon, 10 Oct 2005 09:55:53 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
> > Nonsense. Suppose FTGL is a fine C++ library for displaying text in
> > OpenGL (it is). What value do you get out of a FTGL in Lisp?
>
> I could repeat what I have said but why should I as you obviously
> don't read it anyway?
>
> > IDE support for cl-pdf?! Whatever advantages you have in mind are
> > nothing compared to the effort of a Lisp port.
>
> Hint: cl-pdf is already written in pure Lisp - there's no need to port
> it.
>
> Cheers,
> Edi.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Only advantage I see from pure lisp implmentation over FFI approach is
that I could run the pure-lisp version on both Win32, Linux and Mac.
But then, if the FFI was the wrapper over cross-platform lib I still
have those advantage. Too bad most wrapper FFI is a wrapper over Linux
library. So what I can use most of the time is the pure lisp one.
I don't see any advantage in IDE support for cl-pdf over FFI cl-xxx. I
get as much code completion support from SLIME when using an Lisp FFI
library as I use CL-PDF. What's the advantage you are talking about?
Only advantage is that I'm allow to walk into CL-PDF's source code. But
then, Why would I want to, except to fix the bug in CL-PDF, which the
FFI version doesn't have. (In neccessity, I can still read C source
code of the library that FFI wrap over).
On 11 Oct 2005 01:58:48 -0700, "Pisin Bootvong" <··········@gmail.com> wrote:
> I don't see any advantage in IDE support for cl-pdf over FFI
> cl-xxx. I get as much code completion support from SLIME when using
> an Lisp FFI library as I use CL-PDF. What's the advantage you are
> talking about?
Debugging and multi-processing - see my other message in this thread.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Edi Weitz" <········@agharta.de> wrote in message
··················@agharta.de...
> On 11 Oct 2005 01:58:48 -0700, "Pisin Bootvong" <··········@gmail.com>
wrote:
>
> > I don't see any advantage in IDE support for cl-pdf over FFI
> > cl-xxx. I get as much code completion support from SLIME when using
> > an Lisp FFI library as I use CL-PDF. What's the advantage you are
> > talking about?
>
> Debugging and multi-processing - see my other message in this thread.
In the case of cl-pdf/cl-typesetting there are other reasons as well. Here
are some of those reasons I can think about (without any ordering)
When cl-pdf-parser opens and parse an existing pdf file, you can then
inspect and modify (add/remove pages, write on existing pages, etc) it which
would be tedious through an FFI interface.
You can write the pdf file in a string stream (in memory) for generating
documents on the fly in an application.
You can generate pretty complex documents by having several passes on the
pdf document.
It's much more fun.
Though not yet finished, cl-typesetting has no real equivalent that I know
of in term of potential power. (Yes I've heard about TeX. Now try to do the
cl-typesetting example in TeX ;-). Note that I know that a lot of stuff is
missing in the current cl-typesetting version, but for business and
application document generation it's already very usable.
You can optimize some kind of documents generation by writing on pages with
predefined backgrounds by using and duplicating pre-computed internal
pdf-structures.
In case on an unexpected problem, you can process the error instead of a
core dump.
There is no memory leaks.
There are no buffer overflow exploits.
Did I mentioned it's much more fun?
You can mix high level typesetting with low level pdf drawing and
recursively. (For instance in cl-typechart, each node of the graphs is a
cl-typesetting instance. This mean that you can embed a graph in a document
with each node containing a layout containing other graphs etc...
By having pdf and typesetting internal functions written in Lisp you can add
methods to them to instrument (?) and/or tweak the generation.
etc.
Now it's obvious that FFI is useful to interface with the system or
subsystems like OpenGL but for libraries more at the application level like
typesetting/pdf generation, it's much better to have them in Lisp if
possible.
Marc
Pisin Bootvong wrote:
> Only advantage I see from pure lisp implmentation over FFI approach is
> that I could run the pure-lisp version on both Win32, Linux and Mac.
Not just that, but you can use the native code in whatever Common Lisp
you like, and it's vastly easier to distribute I suppose.
> Only advantage is that I'm allow to walk into CL-PDF's source code. But
> then, Why would I want to, except to fix the bug in CL-PDF, which the
> FFI version doesn't have. (In neccessity, I can still read C source
> code of the library that FFI wrap over).
Exactly. If the C version is perfect, that's cool. But if you want to
modify the code in any way, I think Lisp is much better.
--
State, the new religion from the friendly guys who brought you fascism.
Ulrich Hobelmann <···········@web.de> writes:
> Pisin Bootvong wrote:
[..]
> > Only advantage is that I'm allow to walk into CL-PDF's source code. But
> > then, Why would I want to, except to fix the bug in CL-PDF, which the
> > FFI version doesn't have. (In neccessity, I can still read C source
> > code of the library that FFI wrap over).
>
> Exactly. If the C version is perfect, that's cool. But if you want
> to modify the code in any way, I think Lisp is much better.
The idea of a library is that you use it, not fix it. If it's buggy,
file a bug report, or avoid it if it's hopelessly so. Lisp is _of
course_ better, if you have the sources.
Andras
Andras Simon wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>>Pisin Bootvong wrote:
>
> [..]
>
>>>Only advantage is that I'm allow to walk into CL-PDF's source code. But
>>>then, Why would I want to, except to fix the bug in CL-PDF, which the
>>>FFI version doesn't have. (In neccessity, I can still read C source
>>>code of the library that FFI wrap over).
>>
>>Exactly. If the C version is perfect, that's cool. But if you want
>>to modify the code in any way, I think Lisp is much better.
>
> The idea of a library is that you use it, not fix it. If it's buggy,
> file a bug report, or avoid it if it's hopelessly so.
This is different in an open-source setting where the original author
might have lost interest in maintaining the code. Options include
maintaining your own version, taking over maintenance, or paying someone
to do this for you.
> Lisp is _of course_ better, if you have the sources.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Andras Simon wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>> Pisin Bootvong wrote:
>
> [..]
>
>>> Only advantage is that I'm allow to walk into CL-PDF's source code. But
>>> then, Why would I want to, except to fix the bug in CL-PDF, which the
>>> FFI version doesn't have. (In neccessity, I can still read C source
>>> code of the library that FFI wrap over).
>> Exactly. If the C version is perfect, that's cool. But if you want
>> to modify the code in any way, I think Lisp is much better.
>
> The idea of a library is that you use it, not fix it. If it's buggy,
> file a bug report, or avoid it if it's hopelessly so. Lisp is _of
> course_ better, if you have the sources.
I'm not talking bug-fixing, but adapting, extending, or improving the
code in ways the author(s) aren't interested in. Maybe it takes a lot
of abstraction that a C programmer isn't willing to take for readability
reasons...
--
State, the new religion from the friendly guys who brought you fascism.
Ulrich Hobelmann <···········@web.de> writes:
> Andras Simon wrote:
> > Ulrich Hobelmann <···········@web.de> writes:
> >
> >> Pisin Bootvong wrote:
> > [..]
> >
> >>> Only advantage is that I'm allow to walk into CL-PDF's source code. But
> >>> then, Why would I want to, except to fix the bug in CL-PDF, which the
> >>> FFI version doesn't have. (In neccessity, I can still read C source
> >>> code of the library that FFI wrap over).
> >> Exactly. If the C version is perfect, that's cool. But if you want
> >> to modify the code in any way, I think Lisp is much better.
> > The idea of a library is that you use it, not fix it. If it's buggy,
> > file a bug report, or avoid it if it's hopelessly so. Lisp is _of
> > course_ better, if you have the sources.
>
> I'm not talking bug-fixing, but adapting, extending, or improving the
> code in ways the author(s) aren't interested in. Maybe it takes a lot
> of abstraction that a C programmer isn't willing to take for
> readability reasons...
OK, so that's when you start contemplating rewriting the damn thing in
Lisp (or wishing someone did it). (Unless you can extend it in Lisp
through FFI.) I repeat: Lisp is of course better.
"God grant me serenity to accept the code I cannot change, courage to
change the code I can, and wisdom to know the difference." -- Erik Naggum
:-)
Andras
Edi Weitz <········@agharta.de> writes:
> On Mon, 10 Oct 2005 10:54:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
>
> > Another possibility is to generate bindings for C/C++ libraries with
> > Verrazano:
> >
> > http://common-lisp.net/project/fetter/
> >
> > Kenny Tilton says that this is a great newbie project, and it has
> > the useful side effect of increasing the pool of Lisp libraries.
>
> Let me chime in here and say that I disagree. While creating bindings
> for arbitrary C/C++ projects a newbie won't learn much interesting
> stuff about Lisp. Also, if we just wrap every "interesting" library
> out there we end up like Perl and Python - only that those are more
> tightly integrated with C. IMHO it's much more rewarding to develop
> "pure Lisp" replacements of C functionality - see projects like
> (Portable) AllegroServe, salza/zip, CXML, cl-pdf, cl-md5, you name it.
> All of these could have been implemented by interfacing with existing
> C programs or libraries but only with a pure Lisp program do you get
> full IDE support and an easy way to deliver your application.
There seem to be two issues here.
1. What is more rewarding to a newbie and 2. what's good for CL.
As for 1., I think that designing and implementing a Lispy API on top
of a C library can be very rewarding. One nice thing about it is that
you get something that *works* in a reasonable amount of time. And
it's not that trivial, even with Vzn/CFFI (you still have to fight
C). One could (though I do not) also say that rewriting in Lisp
something that's already there (only, written in C) is not that much
fun. Building higher level stuff on the base that the C lib gives you
can be more interesting and useful. CLSQL and Cells-Gtk are fine
examples of this.
2. Unless you're a lucky Lisp Machine user, you're already using FFI
behind the scenes (for I/O and stuff). Where do you draw the line?
Is using sockets via a thin Lisp wrapper to a C facility fine, but
FTGL is over the limits? I'd say that as long as the Lisp wrapping
(and the library it wraps) is good, it's fine with me. Yeah, I believe
that delivery can be a PITA, but Rayiner and Luis are doing their best
for it not to be :-)
Just my very small fraction of a US$.
>
> YMMV, of course.
Yes, this is the gist of what I'm trying to say.
Andras
On 10 Oct 2005 18:19:56 +0200, Andras Simon <······@math.bme.hu> wrote:
> 2. Unless you're a lucky Lisp Machine user, you're already using FFI
> behind the scenes (for I/O and stuff). Where do you draw the line?
> Is using sockets via a thin Lisp wrapper to a C facility fine, but
> FTGL is over the limits?
The Lisp implementations will need to call OS-supplied functionality
for this, yes. I don't see what this has to do with the FFI and C,
though.
> Yeah, I believe that delivery can be a PITA, but Rayiner and Luis
> are doing their best for it not to be :-)
I was talking about application delivery which'll necessarily include
distribution of shared libraries, putting them into the right place on
the user's machine, making sure the version is correct - all the stuff
I don't have to care about if my app is Lisp all the way down. Do
CFFI and Verrazano help with that?
One other issue I forgot to address: Using the FFI can be a real PITA
if your Lisp doesn't support "native" threads because one call out to
C can potentially block all other threads. The number of CL
implementations that support native threads is increasing but the
majority still uses user-land threads AFAIK.
Just to make this clear: It's good that we have UFFI, it's good that
we now also have CFFI and Verrazano. It's fine with me if someone
uses the FFI to quickly include existing functionality written in
another language - I also do this myself. I just don't think that
piling tons of C/C++ libraries atop CL[*] will significantly improve
its position in the long run.
Cheers,
Edi.
[*] See <http://www.cliki.net/Bindings%20for%20libraries> or any
posting by Kenny.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> Just to make this clear: It's good that we have UFFI, it's good that
> we now also have CFFI and Verrazano. It's fine with me if someone
> uses the FFI to quickly include existing functionality written in
> another language - I also do this myself. I just don't think that
> piling tons of C/C++ libraries atop CL[*] will significantly improve
> its position in the long run.
I agree with Edi. I would much rather deal with a pure Lisp solution
than an FFI wrapper. By definition the FFI wrapper is likely to suck
in UFFI or CFFI or whatever if the wrapper was implementation
specific. A pure Lisp solution will be that much more portable.
Imagine having pure Lisp implementations of such things as Image
Magick and OpenSSH.
Java programmers must agree with the sentiment because they don't use
JNI a while lot.
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
David Steuber <·····@david-steuber.com> writes:
> Edi Weitz <········@agharta.de> writes:
>
> > Just to make this clear: It's good that we have UFFI, it's good that
> > we now also have CFFI and Verrazano. It's fine with me if someone
> > uses the FFI to quickly include existing functionality written in
> > another language - I also do this myself. I just don't think that
> > piling tons of C/C++ libraries atop CL[*] will significantly improve
> > its position in the long run.
>
> I agree with Edi. I would much rather deal with a pure Lisp solution
> than an FFI wrapper.
Why do you care what's under the hood? Aren't all CL implementations
(with the exception of ABCL) written at least partly in C? Does that
worry you?
> By definition the FFI wrapper is likely to suck
> in UFFI or CFFI or whatever if the wrapper was implementation
> specific.
Why would an FFI wrapper be implementation specific? What do you
think the 'u' in uffi stands for?
> A pure Lisp solution will be that much more portable.
No, a portable implementation will be portable. Certainly, a pure Lisp
implementation will be easier to deal with.
> Imagine having pure Lisp implementations of such things as Image
> Magick and OpenSSH.
I'd love to have a LispM, too.
> Java programmers must agree with the sentiment because they don't use
> JNI a while lot.
Yeah, but they have a rich uncle who creates all the libraries they
need, and then some. Besides, there's a million Java programmers to
do the rest.
Andras
>
> --
> http://www.david-steuber.com/
> The UnBlog | Lisp on OS X topics for the most part
> Click all the links you want. I'll make more!
On 10 Oct 2005 23:10:00 +0200, Andras Simon <······@math.bme.hu> wrote:
> Aren't all CL implementations (with the exception of ABCL) written
> at least partly in C?
Are they? Why do you think that?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On 10 Oct 2005 23:10:00 +0200, Andras Simon <······@math.bme.hu> wrote:
>
> > Aren't all CL implementations (with the exception of ABCL) written
> > at least partly in C?
>
> Are they? Why do you think that?
Good question. Hmmm. Aren't they? CMUCL, SBCL, GCL, ECLS and CLISP
certainly are. OpenMCL (and hence probably MCL) has C (and maybe
Objective C) under its hood. I don't know about Corman, ACL and LW. But
even if these are written in Intercal, the majority of CL
implementations aren't C-free.
In any case, they all rely on services written in C (or C++ or
Objective C).
Andras
On 11 Oct 2005 13:43:31 +0200, Andras Simon <······@math.bme.hu> wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> On 10 Oct 2005 23:10:00 +0200, Andras Simon <······@math.bme.hu> wrote:
>>
>> > Aren't all CL implementations (with the exception of ABCL)
>> > written at least partly in C?
>>
>> Are they? Why do you think that?
>
> Good question. Hmmm. Aren't they? CMUCL, SBCL, GCL, ECLS and CLISP
> certainly are.
Let's have a look at the CMUCL sources:
···@vmware:/tmp/src$ find . -name '*.c' -o -name '*.h' | xargs cat | wc -l
35577
···@vmware:/tmp/src$ find . -name '*.lisp' | xargs cat | wc -l
423835
Note that the C files include benchmarks, a Motif server, and code for
several different architectures and operating systems. For a specific
platform I think it is safe to say that less than 5% of the CMUCL code
is C. AFAIK the C code is just a thin "driver" to get the image
started in a hostile (Unix) environment.
I'm pretty sure similar numbers apply to SBCL, OpenMCL, LispWorks, and
AllegroCL. Maybe Duane, Christophe, or other implementors who read
c.l.l want to chime in. (GCL, ECL, and CLISP are different, of
course.)
Saying that CMUCL is partly implemented in C is a bit of a stretch
IMHO. It's like saying that Apache is partly implemented as a shell
script... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On 11 Oct 2005 13:43:31 +0200, Andras Simon <······@math.bme.hu> wrote:
>
>> Edi Weitz <········@agharta.de> writes:
>>
>>> On 10 Oct 2005 23:10:00 +0200, Andras Simon <······@math.bme.hu> wrote:
>>>
>>> > Aren't all CL implementations (with the exception of ABCL)
>>> > written at least partly in C?
>>>
>>> Are they? Why do you think that?
>>
>> Good question. Hmmm. Aren't they? CMUCL, SBCL, GCL, ECLS and CLISP
>> certainly are.
>
> Let's have a look at the CMUCL sources:
>
> ···@vmware:/tmp/src$ find . -name '*.c' -o -name '*.h' | xargs cat | wc -l
> 35577
> ···@vmware:/tmp/src$ find . -name '*.lisp' | xargs cat | wc -l
> 423835
>
> Note that the C files include benchmarks, a Motif server, and code for
> several different architectures and operating systems. For a specific
> platform I think it is safe to say that less than 5% of the CMUCL code
> is C. AFAIK the C code is just a thin "driver" to get the image
> started in a hostile (Unix) environment.
>
> I'm pretty sure similar numbers apply to SBCL, OpenMCL, LispWorks, and
> AllegroCL. Maybe Duane, Christophe, or other implementors who read
> c.l.l want to chime in. (GCL, ECL, and CLISP are different, of
> course.)
I'll bite (yet again :-) - this seems to be a recurring issue on a
somewhat longer cycle, perhaps every 2-3 years or so).
Allegro CL is written with three languages:
Image:
1. The Common Lisp itself. The lisp compiler compiles down to .fasl
files, which are loaded (or deferred to autoload) at build time and
dumped into an image.
Library:
2. C code. This code is mainly interface code, using .h files to
parse the incredibly complex macrology involved on some
architectures. Objects like stat structures and signal contexts are
parameterized on the whims of the vendor's developers (subject to
whatever new standards they are asked to follow). Rather than trying
to track these structures by hand over 15 to 20 different operating
systems, we let the vendor's C compiler do the work for these
interfacing needs.
3 A "runtime system Lisp". This lisp source is not Common Lisp,
but a lisp where integers are machine-integers and operations like +
and logand are compiled into individual machine instructions. The
Allegro CL compiler is used, in a runtime-system mode, to generate
assembler source code which is then linked wth the C object files
and any libraries to form a shared-library.
[Note on the library: our garbage collector is also currently written
in C. It need not be, and I've been enhancing the runtime-system lisp
to handle all constructs that are needed by the gc. One thing remains
that I'm aware of - our rs lisp knows how to reference and set global
variables (not lisp globals, but "globl" or "public" variables - some
would call these C variables, but they are really just exported named
data words known by the linker). But it does not yet know how to
define and allocate the storage for such globals - currently it has
to be done in C. I may end up borrowing CL's defvar for such a purpose,
but haven't decided. This project has been a low priority project,
but once it is done it will allow the gc to be rewritten (or new ones
written) in rs lisp language.]
In addition to the library, There is some C and/or C++ code which is linked
to form the main(), whose purpose is to load the shared library and to
run the lisp_main. It is a very small amount of C code for which we
provide the user with the option to write his own, in his own favorite
language.
As for LOC, I won't give those out, but suffice it to say that the Lisp
and rs lisp code far outstrips the C code, and if we were to move our
gc over to rs lisp the C code would become incidental.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Edi Weitz <········@agharta.de> writes:
>
> > On 11 Oct 2005 13:43:31 +0200, Andras Simon <······@math.bme.hu> wrote:
> >
> > I'm pretty sure similar numbers apply to SBCL, OpenMCL, LispWorks, and
> > AllegroCL. Maybe Duane, Christophe, or other implementors who read
> > c.l.l want to chime in. (GCL, ECL, and CLISP are different, of
> > course.)
>From my hazy memory of porting Lucid CL to a new platform (on the
opposite coast from the Lucid implementors) it was written almost
entirely in Lisp at three levels:
1. A Lisp format assembler written in CL.
2. A subset of CL with many optimized primitives. Probably all
implementations have such a subset but it's worth pointing out because
programming in it has a quite different flavor than programming in CL.
3. CL itself.
There was a really tiny bit of C which they reluctantly added after
trying to do Unix system calls in machine code and discovering to their
horror that part of the system call was implemented in the user space C
wrapper.
The garbage collector was written in CL (and primitives) entirely with
macros so that there would be no Lisp function calls or consing in its
execution. One of the many porting challenges it presented was that
the resulting function was over 65K bytes, thus exceeding all of the
smaller address ranges in the instruction set. The memory invariant
was that a GC could be expected between any two arbitrary machine
instructions (^C could be typed at any time...). This forced lots of
low level code to be very carefully written.
The build system was written in CL and had no support for build
dependencies because it is possible to prove that Lisp code and
invalidate any dependency tracking.
In other words, Lucid took the extreme pure Lisp view of
implementation. From a brief internal look at Allegro after doing
this, it seems that Franz took a much more pragmatic Unix view on many
of these issues. This appeared to result in the Allegro code base
being MUCH easier to work with.
Dan Pierson
ITA Software, Inc.
···@itasoftware.com writes:
> Duane Rettig wrote:
>> Edi Weitz <········@agharta.de> writes:
>>
>> > On 11 Oct 2005 13:43:31 +0200, Andras Simon <······@math.bme.hu> wrote:
>> >
>> > I'm pretty sure similar numbers apply to SBCL, OpenMCL, LispWorks, and
>> > AllegroCL. Maybe Duane, Christophe, or other implementors who read
>> > c.l.l want to chime in. (GCL, ECL, and CLISP are different, of
>> > course.)
>
>>From my hazy memory of porting Lucid CL to a new platform (on the
> opposite coast from the Lucid implementors) it was written almost
> entirely in Lisp at three levels:
>
> 1. A Lisp format assembler written in CL.
I assume you mean LAP here (for other readers, LAP means "lisp
assembler program", and is a style which incorporates an
assembler-like machine-dependent code syntax and structure).
Allegro CL used to program in LAP, as well. Dusting off some
old Attic source:
(def-runtime i-runtime-list-nreverse
;; do an nreverse of a known PROPER list.
;; this is useful for mapcar type applications.
(dglobal-name list_nreverse)
(linkin t)
(args list)
(labels done)
(code
(i-push-link-descriptor 0 #.i-nreverse-link-desc 1)
;; look for the empty list
(ce-lap 'mov list '#.l.ret)
(ce-lap 'cmp '(= nil) '#.l.ret)
(ce-lap 'je.s done)
;; l.ret: will have the current cons
;; c.sad: will have the previous/next cons
(ce-lap 'mov '(= nil) '#.c.sad) ; initially prev=nil
(cem-loop
(ce-lap 'xchg '(4byte #.l.ret) '#.c.sad) ; store prev/get next
(ce-lap 'push '#.l.ret) ; preserve lisp registers
(ce-lap 'push '#.c.sad)
(i-gsgc-protect-setf '#.l.ret '(4byte #.l.ret))
(ce-lap 'pop '#.c.sad) ; restore lisp registers
(ce-lap 'pop '#.l.ret)
(ce-lap 'cmp '(= nil) '#.c.sad) ; end of the line??
(ce-lap 'je.s done) ; yes
(ce-lap 'xchg '#.l.ret '#.c.sad))
(ce-label done)
;; result in l.ret
(i-set-number-of-results 1)))
This coding style was useful for precise per-architecture coding,
back in the days when we had only a couple of architectures on
which Allegro CL ran. But it was horrendous to actually maintain,
and as new RISC architectures started coming out, John Foderaro
realized that major porting was going to be too complex, and so
he invented the runtime-system lisp compiler enhancements. Note
the same simple function above gets a whole lot simpler in
runtime-system coding style:
(def-runtime-q list-nreverse (list)
(if (null list)
nil
(let ((prev list)
(next (ls md-cons cdr list))
(follow nil))
(loop
(setf (ls md-cons cdr prev) follow)
(if (null next)
(return prev)
(setf follow prev
prev next
next (ls md-cons cdr next)))))))
> 2. A subset of CL with many optimized primitives. Probably all
> implementations have such a subset but it's worth pointing out because
> programming in it has a quite different flavor than programming in CL.
>
> 3. CL itself.
[ ... ]
> In other words, Lucid took the extreme pure Lisp view of
> implementation. From a brief internal look at Allegro after doing
> this, it seems that Franz took a much more pragmatic Unix view on many
> of these issues. This appeared to result in the Allegro code base
> being MUCH easier to work with.
Thanks. I've never seen Lucid code, but I can believe that our
code does take a more pragmatic stance. I think our viewpoint can
be summed up by saying we start pragmatically and then proactively
purify as time progresses. And from a comparison of the code snippets
above, I think we can say we are successful in at least some
situations.
There's nothing bad about purism, except that it's so expensive -
I find myself in a constant love/hate relationship with the
"worse-is-better" concept. For example, at one point we removed
all LAP code from our runtime-system, moving code that relied on
machine-dependencies to actual hand-coded assembler files - e.g.
.globl list
list:
movl %eax,4(%esp)
movl %edx,8(%esp)
leal 4(%esp),%eax
jmp restify2
.type list,@function
.size list,.-list
Note that this assembler code is not only x86 specific, but
linux/freebsd specific - it does not work on Windows, where
we have to do this:
extrn restify2:near
[ ... ]
public list
list:
mov [esp+4],eax
mov [esp+8],edx
lea eax,[esp+4]
jmp restify2
This has several disadvantages wrt maintenance, including the obvious
duplication of code, but also, more subtlely, the fact that if I make
any mistakes on offsets, then that architecture has a bug. So I
resurrected the older lap coding, but giving the code some more
automation:
(def-runtime-md list ()
(iqe export '(:label "list"))
(iqe label '(:label "list"))
(do ((irs *in-regs-iq* (cdr irs))
(count 0 (1+ count)))
((null irs))
(iqe move.l (car irs) (iq-param-address count)))
(iqe lea (iq-param-address 0) *retval-reg-iq*)
(iqe bcc :t '(:label restify2)))
This ends up generating exactly the same assembler source code as
was in the assembler files, but it does so with offsets that are
generated automatically and are thus consistent with the rest of
the lisp, and it also generates the correct format as each assembler
wants to see it.
I guess you could say in all of this that "assembler" represents
a class of domain-specific languages, and we are harnessing the
power of Common Lisp to address these languages and to write the
code in higher level, more lisp-like languages.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 12 Oct 2005 08:02:59 -0700, ···@itasoftware.com wrote:
> There was a really tiny bit of C which they reluctantly added after
> trying to do Unix system calls in machine code and discovering to
> their horror that part of the system call was implemented in the
> user space C wrapper.
Thanks for the interesting info. The part I'm citing above for me is
an example of what I called a "hostile environment." (This is
specifically addressed to the poster who thinks that people who
believe Unix is more friendly to C than to Lisp don't get out enough.
See also Duane's remark about "incredibly complex macrology involved
on some architectures.")
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 12 Oct 2005 08:02:59 -0700, ···@itasoftware.com wrote:
>
>
>>There was a really tiny bit of C which they reluctantly added after
>>trying to do Unix system calls in machine code and discovering to
>>their horror that part of the system call was implemented in the
>>user space C wrapper.
>
>
> Thanks for the interesting info. The part I'm citing above for me is
> an example of what I called a "hostile environment." (This is
> specifically addressed to the poster who thinks that people who
> believe Unix is more friendly to C than to Lisp don't get out enough.
> See also Duane's remark about "incredibly complex macrology involved
> on some architectures.")
Don't mischaracterize my post. Lisp, by its nature*, will have to jump
through a few hoops to "play nice" on ANY physical architecture, even a
Lisp machine. It's not a UNIX and C thing.
As to Dan Pierson's remembrance of a syscall partially implemented in
user space, can one bad (interesting?) implementation besmirch all
UNIXes? Possibly it was a variant of the "PC-losering problem" but maybe
it was something else. I've implemented a Forth directly on top of UNIX
syscalls with no reliance on libc or any other userspace C
infrastructure, and it worked just fine: 10kB binaries with no dependencies.
* - This isn't technically true, come to think of it, since CL doesn't
say anything about memory management. But in practical Lisp
implementations where objects have a tendency to move about in memory,
the implementor will of course be responsible for ensuring that pointers
which the OS expects to remain valid between syscalls do indeed remain
valid.
Actually, I was working for a hardware vendor which supported three
different versions of Unix at the time (Encore Computer). We all
thought it obvious that parts of the system call interface would be
implemented in the user space library.
Edi Weitz <········@agharta.de> writes:
> On 11 Oct 2005 13:43:31 +0200, Andras Simon <······@math.bme.hu> wrote:
>
> > Edi Weitz <········@agharta.de> writes:
> >
> >> On 10 Oct 2005 23:10:00 +0200, Andras Simon <······@math.bme.hu> wrote:
> >>
> >> > Aren't all CL implementations (with the exception of ABCL)
> >> > written at least partly in C?
> >>
> >> Are they? Why do you think that?
> >
> > Good question. Hmmm. Aren't they? CMUCL, SBCL, GCL, ECLS and CLISP
> > certainly are.
>
> Let's have a look at the CMUCL sources:
>
> ···@vmware:/tmp/src$ find . -name '*.c' -o -name '*.h' | xargs cat | wc -l
> 35577
> ···@vmware:/tmp/src$ find . -name '*.lisp' | xargs cat | wc -l
> 423835
>
> Note that the C files include benchmarks, a Motif server, and code for
> several different architectures and operating systems. For a specific
It also includes the gc...
> platform I think it is safe to say that less than 5% of the CMUCL code
> is C. AFAIK the C code is just a thin "driver" to get the image
> started in a hostile (Unix) environment.
35K (or even 10K) lines of C code should already be sufficiently scary
for a purist.
>
> I'm pretty sure similar numbers apply to SBCL, OpenMCL, LispWorks, and
> AllegroCL. Maybe Duane, Christophe, or other implementors who read
> c.l.l want to chime in. (GCL, ECL, and CLISP are different, of
> course.)
Not that it's relevant to this subthread (but then, neither is this
subthread too relevant to the whole discussion) ABCL has 41685 lines
of Lisp vs 59245 lines of Java; I guess the ratio will improve
over time.
>
> Saying that CMUCL is partly implemented in C is a bit of a stretch
> IMHO. It's like saying that Apache is partly implemented as a shell
> script... :)
I'm happy this is the only part of my post that you found
objectionable :)
Andras
Edi Weitz <········@agharta.de> writes:
> For a specific platform I think it is safe to say that less than 5%
> of the CMUCL code is C. AFAIK the C code is just a thin "driver" to
> get the image started in a hostile (Unix) environment.
the runtime support systems of current high-level language
implementations tend to be written in C. this typically includes the
GC, image dumper/loader, signal/interrupt handling logic, low-level
threading support, etc.
while this runtime part tends to be rather small source-wise (compared
to the rest of the implementation), it's hardly insignificant.
I'd even say that the main thing contributing to CL's impressive score
on the percent-of-being-implemented-in-itself-and-not-in-C metric is
the relatively big size of its standard. :)
--m
--
Every program is a part of some other program and rarely fits.
-- Alan Perlis
Andras Simon <······@math.bme.hu> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Edi Weitz <········@agharta.de> writes:
> >
> > > Just to make this clear: It's good that we have UFFI, it's good that
> > > we now also have CFFI and Verrazano. It's fine with me if someone
> > > uses the FFI to quickly include existing functionality written in
> > > another language - I also do this myself. I just don't think that
> > > piling tons of C/C++ libraries atop CL[*] will significantly improve
> > > its position in the long run.
> >
> > I agree with Edi. I would much rather deal with a pure Lisp solution
> > than an FFI wrapper.
>
> Why do you care what's under the hood? Aren't all CL implementations
> (with the exception of ABCL) written at least partly in C? Does that
> worry you?
Dependencies, no, and no.
The use of C in some Lisp implementations is a programmer effort
optimization anyway. That is, it leverages the C compiler's knowledge
of local ABI conventions.
> > By definition the FFI wrapper is likely to suck
> > in UFFI or CFFI or whatever if the wrapper was implementation
> > specific.
>
> Why would an FFI wrapper be implementation specific? What do you
> think the 'u' in uffi stands for?
You would use an implementation specific FFI wrapper to take advantage
of the implementation's abilities to deal with foreign code. The 'u'
in uffi stands for Least Common Denominator. I can not wrap the
Carbon APIs using UFFI. I've been sticking to OpenMCL's FFI
directly. If I move ahead with that project, and I get to work with
another Lisp implementation that supports threads, callbacks, stack
allocation, etc on OS X, then I will probably add an abstraction layer
with macrology.
> > A pure Lisp solution will be that much more portable.
>
> No, a portable implementation will be portable. Certainly, a pure Lisp
> implementation will be easier to deal with.
Much, much easier. It's one thing on OS X to deal with standard
Frameworks. It's another thing entirely to deal with shared libraries
on Linux that may or may not be installed on a particular machine.
> > Imagine having pure Lisp implementations of such things as Image
> > Magick and OpenSSH.
>
> I'd love to have a LispM, too.
I am quite confident that implementing the functionality of Image
Magick and OpenSSH, seeing as how they both have source code
availability and specifications, is orders of magnitude easier than
building a LispM from scratch.
> > Java programmers must agree with the sentiment because they don't use
> > JNI a while lot.
>
> Yeah, but they have a rich uncle who creates all the libraries they
> need, and then some. Besides, there's a million Java programmers to
> do the rest.
So your answer is to get a rich uncle or let someone else do the work?
You are going to just give up that easily? I've already used a pure
Lisp JPEG library in code I have published (for a contest, so it isn't
exactly a real application or anything). Libraries exist, in Lisp,
for creating PNG files. I also home spun my own TGA writing code and
PGM writing code. It's rather application specific, but there is no
reason one can't read the specifications and build a pure Lisp library
for working with bitmap data and doing file format conversions.
Don't get me wrong. FFI is a wonderful if not essential feature to
have. FFI happens to carry certain costs that make it less than ideal
for many applications. I would prefer to reserve FFI for system level
access where it does represent the best solution. Otherwise, I would
like to remain in a pure Lisp space where things work better
together.
GC'd languages are inherently xenophobic. There is a lot of ugliness
under the hood to make them play well with Unix like environments.
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
David Steuber <·····@david-steuber.com> writes:
> Andras Simon <······@math.bme.hu> writes:
>
> > David Steuber <·····@david-steuber.com> writes:
> >
> > > Edi Weitz <········@agharta.de> writes:
> > >
> > > > Just to make this clear: It's good that we have UFFI, it's good that
> > > > we now also have CFFI and Verrazano. It's fine with me if someone
> > > > uses the FFI to quickly include existing functionality written in
> > > > another language - I also do this myself. I just don't think that
> > > > piling tons of C/C++ libraries atop CL[*] will significantly improve
> > > > its position in the long run.
> > >
> > > I agree with Edi. I would much rather deal with a pure Lisp solution
> > > than an FFI wrapper.
> >
> > Why do you care what's under the hood? Aren't all CL implementations
> > (with the exception of ABCL) written at least partly in C? Does that
> > worry you?
>
> Dependencies, no, and no.
>
> The use of C in some Lisp implementations is a programmer effort
> optimization anyway. That is, it leverages the C compiler's knowledge
> of local ABI conventions.
>
> > > By definition the FFI wrapper is likely to suck
> > > in UFFI or CFFI or whatever if the wrapper was implementation
> > > specific.
> >
> > Why would an FFI wrapper be implementation specific? What do you
> > think the 'u' in uffi stands for?
>
> You would use an implementation specific FFI wrapper to take advantage
> of the implementation's abilities to deal with foreign code. The 'u'
> in uffi stands for Least Common Denominator. I can not wrap the
> Carbon APIs using UFFI. I've been sticking to OpenMCL's FFI
> directly. If I move ahead with that project, and I get to work with
> another Lisp implementation that supports threads, callbacks, stack
> allocation, etc on OS X, then I will probably add an abstraction layer
> with macrology.
You can always lobby your vendor for missing features in its FFI, so
that in the end the LCD will be sufficient. Also, I don't see any
reason why a universal FFI (say, CFFI) cannot have features that not
all implementations support. (Please don't say that then it's not
universal anymore.) Actually, CFFI has callbacks which non-x86 SBCL
doesn't support yet. So now is the time to join the CFFI mailing list
and make sure that you can eventually wrap the Carbon API using CFFI
(if this is at leat remotely possible; I have no idea what features
are missing). BTW, you aren't rewriting Carbon in Lisp, do you?
But all this is beside the point. I never advocated CFFIzing libraries
that cannot be CFFIzed. And if the problem is that (U)FFI's aren't
good enough, the solution is to improve, not ignore them.
>
> > > A pure Lisp solution will be that much more portable.
> >
> > No, a portable implementation will be portable. Certainly, a pure Lisp
> > implementation will be easier to deal with.
>
> Much, much easier. It's one thing on OS X to deal with standard
> Frameworks. It's another thing entirely to deal with shared libraries
> on Linux that may or may not be installed on a particular machine.
Or the wrong version is installed...
>
> > > Imagine having pure Lisp implementations of such things as Image
> > > Magick and OpenSSH.
> >
> > I'd love to have a LispM, too.
>
> I am quite confident that implementing the functionality of Image
> Magick and OpenSSH, seeing as how they both have source code
> availability and specifications, is orders of magnitude easier than
> building a LispM from scratch.
The problem is breadth, not depth. Any single library can be rewritten
in Lisp, but there're simply too many libraries out there to rewrite
each and every one of them.
>
> > > Java programmers must agree with the sentiment because they don't use
> > > JNI a while lot.
> >
> > Yeah, but they have a rich uncle who creates all the libraries they
> > need, and then some. Besides, there's a million Java programmers to
> > do the rest.
>
> So your answer is to get a rich uncle or let someone else do the work?
No, my answer is to realize that we don't have a rich uncle, and to not
compare the small and poor Lisp world to the huge and rich Java world.
> You are going to just give up that easily? I've already used a pure
I don't consider using whatever (good) stuff is out there already
giving up. I'm no purist when the issue is "working less". That's one
of the reason why I prefer Lisp to C or asm.
> Lisp JPEG library in code I have published (for a contest, so it
BTW I loved your fractal movie!
> isn't exactly a real application or anything). Libraries exist, in
> Lisp, for creating PNG files. I also home spun my own TGA writing
> code and PGM writing code. It's rather application specific, but
> there is no reason one can't read the specifications and build a
> pure Lisp library for working with bitmap data and doing file format
> conversions.
I'm a happy user of pure Lisp libraries (aserve, cl-ppcre, and a bunch
of others). And I think the more (quality) pure CL libraries are
there, the better. But there just isn't enough manpower (and
widespread interest among Lispers) to have every useful library
rewritten in Lisp.
> Don't get me wrong. FFI is a wonderful if not essential feature to
> have. FFI happens to carry certain costs that make it less than ideal
> for many applications. I would prefer to reserve FFI for system level
> access where it does represent the best solution. Otherwise, I would
> like to remain in a pure Lisp space where things work better
> together.
>
> GC'd languages are inherently xenophobic. There is a lot of ugliness
> under the hood to make them play well with Unix like environments.
It's not languages, but users, who can be xenophobic. And we're not in
a position where we can chose our neighbours.
Andras
Andras Simon wrote:
> No, my answer is to realize that we don't have a rich uncle, and to not
> compare the small and poor Lisp world to the huge and rich Java world.
Oh but we did! The problem is, our rich uncles died and had most of the
family fortune buried with them.
>>GC'd languages are inherently xenophobic. There is a lot of ugliness
>>under the hood to make them play well with Unix like environments.
>
>
> It's not languages, but users, who can be xenophobic. And we're not in
> a position where we can chose our neighbours.
It's the language and the users. I've seen posts about interfacing with
"UNIX like environments" and "C like languages" and they make me laugh,
because I wonder whether the people who advance such arguments ever go
out on dates. To meet a friend for lunch, I've got to tell her WHERE
I'll be and WHEN I'll be there. If that's UNIX-like, page me out!
Simply put, specifying the memory layout of structures and passing
around pointers are not unique to UNIX, C and their ilk, but a
reflection of how any two independent parties, whether in the real world
or inside our computers, coordinate logistics. In computers, these
parties can be two pieces of software (e.g. the OS and an application)
or software and hardware (e.g. the OS and the disk controller), but any
way you slice it, there's no getting around working with objects whose
layouts are specified and which aren't allowed to arbitrarily pick up
and move unbeknownst to the two parties. After messing around with Brad
Parker's CADR emulator and MIT's CADR disk images, I can assure you that
there was nothing magical inside Lisp machines to nullify this.
Kent Pitman discusses aspects of this at length in
http://groups.google.com/group/comp.lang.lisp/msg/1dae8d0ce313f314
I don't know if there are better ways to interface with the "real"
(foreign) world than out current FFIs, but a good start would be to
admit that there's nothing uniquely ugly about UNIX and C: Any operating
system has to deal with time/space locality in exactly the same way.
Cameron MacKinnon wrote:
> Simply put, specifying the memory layout of structures and passing
> around pointers are not unique to UNIX, C and their ilk, but a
> reflection of how any two independent parties, whether in the real world
> or inside our computers, coordinate logistics. In computers, these
> parties can be two pieces of software (e.g. the OS and an application)
> or software and hardware (e.g. the OS and the disk controller), but any
> way you slice it, there's no getting around working with objects whose
> layouts are specified and which aren't allowed to arbitrarily pick up
> and move unbeknownst to the two parties. After messing around with Brad
> Parker's CADR emulator and MIT's CADR disk images, I can assure you that
> there was nothing magical inside Lisp machines to nullify this.
I agree strongly with your general point, but I'm wondering if there is
something specific you are thinking about here.
Much of the serious grottiness I have see (trying to get the CADR
emulator to work under Mac OS X on a big-endian PPC processor) has to
do with the apparent provisions for the CADR development to be
bootstrapped from Maclisp-based (36-bit word!) systems, for debugging
and bootstrapping using a umbilical to another CADR machine, with
low-level disk drivers, and also with the ability to muck with the
microcode.
Much of that capability has been stripped out from other operating
environments. E.g. to develop ordinary device drivers, much less
mucking with the low-level processor details, typically requires
additional development kits and lots of additional documentation. The
weird code used to bootstrap the OS onto the platform itself has
usually vanished into the bit-bucket.
It also seems to be a point in time where the language itself was in
great flux; one of the most recent e-mails in one of the logs announces
the introduction of with-open-file. There is a lot of code meant to run
on, or waiting to be ported from Maclisp.
What we see in the CADR snapshots is something like a workshop
environment, where the system itself is under daily construction. Weird
jigs and sawdust are all around.
Most delivered environments have been cleaned up a bit before let out
into the wild. Perhaps this is an unfair comparison to a research lab
on a random day when a backup happened to be run.
That said, I still haven't gotten my Mac to boot the machine
successfully. Don't know where the problem is yet. And I wish the CADR
emulator had been written in Common Lisp :-).
Edi Weitz <········@agharta.de> writes:
> On 10 Oct 2005 18:19:56 +0200, Andras Simon <······@math.bme.hu> wrote:
>
> > 2. Unless you're a lucky Lisp Machine user, you're already using FFI
> > behind the scenes (for I/O and stuff). Where do you draw the line?
> > Is using sockets via a thin Lisp wrapper to a C facility fine, but
> > FTGL is over the limits?
>
> The Lisp implementations will need to call OS-supplied functionality
> for this, yes. I don't see what this has to do with the FFI and C,
> though.
The point I was trying to make was that just as we use stdio via (the
library part of) our favourite Common Lisp implementation, it would be
natural to have GTK or FTGL available through a (similarly
well-designed) Lispy API.
>
> > Yeah, I believe that delivery can be a PITA, but Rayiner and Luis
> > are doing their best for it not to be :-)
>
> I was talking about application delivery which'll necessarily include
> distribution of shared libraries, putting them into the right place on
> the user's machine, making sure the version is correct - all the stuff
> I don't have to care about if my app is Lisp all the way down. Do
> CFFI and Verrazano help with that?
A self-contained package is always easier to deal with, I grant you
that much :) But note that programs written in C/C++ have the same
problems, and although this does cause headache sometime, it certainly
doesn't stop firefox being a very successful cross-platform
application. I for one would be quite satisfied if Lisp delivery faced
as many obstacles as C programs do. (But maybe I'm missing something
here.)
>
> One other issue I forgot to address: Using the FFI can be a real PITA
> if your Lisp doesn't support "native" threads because one call out to
> C can potentially block all other threads. The number of CL
> implementations that support native threads is increasing but the
> majority still uses user-land threads AFAIK.
OK, this is a technical problem (slowly disappearing, as you say), and
it's probably more of a pain in some cases than in others. Depends on
the library and the nature of your application, I guess.
> Just to make this clear: It's good that we have UFFI, it's good that
> we now also have CFFI and Verrazano. It's fine with me if someone
> uses the FFI to quickly include existing functionality written in
> another language - I also do this myself. I just don't think that
> piling tons of C/C++ libraries atop CL[*] will significantly improve
> its position in the long run.
I agree. Piling will not help much. (It may help a little, though).
But building CL libraries with well thought out Lispy APIs on top of C
libs will (if it ever happens, that is). And the nice thing about it
is that you can always go back and recreate the library in Lisp if it
seems necessary (witness Franz btrees) and you have the resources
(witness Franz :)).
Andras
>
> Cheers,
> Edi.
>
> [*] See <http://www.cliki.net/Bindings%20for%20libraries> or any
> posting by Kenny.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 10 Oct 2005 18:45:44 +0200, Edi Weitz wrote:
> The number of CL implementations that support native threads is
> increasing but the majority still uses user-land threads AFAIK.
>
Which (common) lisps use user-land threads?
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On Tue, 11 Oct 2005 20:30:55 -0500, Matthew D Swank <·······································@c.net> wrote:
> Which (common) lisps use user-land threads?
Off the top of my head:
- AllegroCL on anything but Windows
- LispWorks on anything but Windows[1]
- CMUCL[2]
Well, OK, maybe "majority" wasn't the right word. It's only the
majority if you count each compiler/platform combo as a different
implementation. Here are the implementations that /do/ use native
threads AFAIK:
- AllegroCL on Windows
- LispWorks on Windows
- CormanLisp
- Scieneer Common Lisp
- OpenMCL
- SBCL on Linux/x86[3]
So, if you're not a Windows user there's not much left - two
implementations for Linux/x86, one for Darwin on PowerPCs, and one
not-really-cheap Lisp for a couple of commercial Unix variants.
And then of course there are a couple of Lisps that don't offer MP at
all, like CMUCL on anything other than x86, SBCL on anything other
than Linux/x86/2.6, CLISP, etc.
Don't take my word for this - check for yourself.
Cheers,
Edi.
[1] According to Dave Fox the upcoming LW 5.0 will offer native
threads on Linux/x86.
[2] CMUCL only has MP support on x86.
[3] Only with 2.6 kernels.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> - LispWorks on Windows
LispWorks on Mac OS X also uses native threads (but the GUI
stuff runs in one common thread).
--
(espen)
On Wed, 12 Oct 2005 10:31:07 +0200, Espen Vestre <·····@vestre.net> wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> - LispWorks on Windows
>
> LispWorks on Mac OS X also uses native threads (but the GUI stuff
> runs in one common thread).
Ah, thanks. That was new to me.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Andras Simon wrote:
> Edi Weitz <········@agharta.de> writes:
>
>
>>On Mon, 10 Oct 2005 10:54:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
>>
>>
>>>Another possibility is to generate bindings for C/C++ libraries with
>>>Verrazano:
>>>
>>> http://common-lisp.net/project/fetter/
>>>
>>>Kenny Tilton says that this is a great newbie project, and it has
>>>the useful side effect of increasing the pool of Lisp libraries.
>>
>>Let me chime in here and say that I disagree. While creating bindings
>>for arbitrary C/C++ projects a newbie won't learn much interesting
>>stuff about Lisp. Also, if we just wrap every "interesting" library
>>out there we end up like Perl and Python - only that those are more
>>tightly integrated with C. IMHO it's much more rewarding to develop
>>"pure Lisp" replacements of C functionality - see projects like
>>(Portable) AllegroServe, salza/zip, CXML, cl-pdf, cl-md5, you name it.
>>All of these could have been implemented by interfacing with existing
>>C programs or libraries but only with a pure Lisp program do you get
>>full IDE support and an easy way to deliver your application.
>
>
> There seem to be two issues here.
>
> 1. What is more rewarding to a newbie and 2. what's good for CL.
>
> As for 1., I think that designing and implementing a Lispy API on top
> of a C library can be very rewarding.
Yes, I stand corrected. I forgot that Lispers always do Nice Things in
their wrappers, they do not just spit out bindings. This is part of why
we ended up flunking the cl-sockets project, speaking of which, a nice
Lispy added-value wrapper might be beyond someone new to Lisp. What
little code we did get out of cl-sockets was awful Lisp. But if the Lisp
newby, unlike the cl-sockets student, interacts with veteran Lispniks
and accepts their guidance, perhaps there could be a happy ending and a
lot of learning will happen.
Thanks, BTW, to everyone who helped with the evaluation of cl-sockets.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Tyler Eaves <······@gmail.com> writes:
> I'm basically looking for suggestions for problems that would
> be good learning expriments. Ideally, such problems could be tackled in
> a single sitting in no more than, say, 100 lines of code. As a bit of
> anexample, at http://cg2.org/poker.lisp you can see some code I wrote
> today that implements the guts of a video poker simulation.
How about writing a backtracking search to solve boolean
satisfaction problems. For example
(satisfy '(and (or a b) (not a))) => ((a . 0)(b . 1))
The program tries a=1 which makes (or a b)=1 then it bumps
into (not a)=0 which makes (and ... (not a))=0, bummer, so
it has to backtrack and try a=0 ...
You can see a humiliating failure of mine from last summer
at http://alan.crowe.name/lisp/sat.txt. Hmm, this code
doesn't even point the way to a solution.
I've had another go, three weeks ago and cracked it in about
an hour and a half with 81 lines of code.
I don't know if the problem appeals to you, but I couldn't
leave it along, and it meets your requirement of solvable in
< 100 lines, though it might be harder than you want (or
easier, if you have that kind of mind)
Should I post my solution, or will that spoil the challenge?
Alan Crowe
Edinburgh
Scotland
Hello Tyler,
Tyler Eaves <······@gmail.com> writes:
> Alternatively, if there are any open source projects out there that
> could use a hand, and are willing to put up with a newbie drop me a
> line ;)
>
We (wxCL project) are looking for some help. You can know more about the
project at the home page :
http://www.wxcl-project.org/
and if it interests you, then send us an email on our devel mailing list.
The contact information can be found on the page:
http://www.wxcl-project.org/en/contact--contact-1.html
Cheers.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
,----
| Great wits are sure to madness near allied,
| And thin partitions do their bounds divide.
|
| (John Dryden, Absalom and Achitophel, 1681)
`----
Tyler Eaves <······@gmail.com> writes:
> I like Lisp quite a bit. Makes programming FUN again, which for me
> is pretty much the point. The only language I found to be close to
> this rewarding is python, but once you start appreciating lisp, it
> starts to feel a bit like a toy.
Welcome to the club!
> Anyway, I'm currently at a bit of a quandray. I've kinda gotten
> past the point where small problems are of interest but yet not
> ready to tackle really large projects that would result in real
> useable software. I'm basically looking for suggestions for
> problems that would be good learning expriments.
> [2] - For those additionally curious, I'm currently enrolled in the
> Mechanical Engineering Technology program at my local community
> college. Subject matter ranges from topics like CAD and PLC
> programming, to basic electriciy and hydrualics. Lots of hands on
> problem solving. Fun stuff. Lots of fun toys too.... (CNC
> machining is rather neat...)
I wonder if you can't combine the Lisp with the Mech-E. Can you
create lisp functions that output CNC commands? Are the CNC commands
written in a file somehow?
On Mon, 10 Oct 2005 20:19:46 -0400, Joe Marshall <·········@alum.mit.edu>
wrote:
> I wonder if you can't combine the Lisp with the Mech-E. Can you
> create lisp functions that output CNC commands? Are the CNC commands
> written in a file somehow?
That's an idea actually.
A simple CNC program for a milling machine might look something like this
(stuff after the ; are comments_:
N0001 T03 ;Select tool 3
N0002 M03 S3000 ;Turn spindle on, clockwise, set speed to 3000 rpm
N0003 G00 X0.0 Y0.05 Z-3.0 ;Move to start posistion of cut, clear of
workpiece
N0004 G00 Y-0.1 ;Move end of tool one tenth below part surface
N0005 G01 Z3.0 F15.0 ;Make a 6 inch cut at a feed of 15 inches per minute
N0006 G00 Y3.0 ;Move off the part
N0007 M30 ;End program, return to top
(that's quite oversimplified, I left out a lot of setup stuff, etc, but
that shows the flavor of it.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 10 Oct 2005 20:58:33 -0400, "Tyler Eaves" <······@mailshack.com> wrote:
> A simple CNC program for a milling machine might look something like
> this (stuff after the ; are comments_:
Hey, they even use the same comment characters. So you're halfway
there already... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Edi Weitz" <········@agharta.de> wrote
> On Mon, 10 Oct 2005 20:58:33 -0400, "Tyler Eaves" <······@mailshack.com>
wrote:
>
> > A simple CNC program for a milling machine might look something like
> > this (stuff after the ; are comments_:
If you still want an interesting project, you can write a Common Lisp
transformation program that would read Catia CAM files and output G-Codes.
It's rather easy to do and will make you work on parsing,
transformation/compilation methods and formatted output.
Or maybe a description language interpreter that generates G-codes so that
it's easy to make 3D fractals.
> Hey, they even use the same comment characters. So you're halfway
> there already... :)
As Edi noted, you just have the second half to write ;-)
Marc
(Who has finished his new stepper motor driver electronic board for use with
EMC.)