From: Tom Lord Subject: python libs v lisp coolness? Date: Message-ID: <vprc9phusr2u7b@corp.supernews.com>
So, if Python has all these great libraries and Common Lisp needs analogs of them, why isn't the right approach to write a translator? Even if the interfaces to those python libraries is not very "lisp-like" -- wouldn't it be easier to wrap up ugly interfaces in a clean interface than to start from scratch? Something about data-type isomorphism, I suspect..... W3C is doing the job that lispers neglected. Poorly. -t
From: Mario S. Mommer Subject: Re: python libs v lisp coolness? Date: Message-ID: <fz65iamdcs.fsf@cupid.igpm.rwth-aachen.de>
····@emf.emf.net (Tom Lord) writes: > So, if Python has all these great libraries and Common Lisp needs > analogs of them, why isn't the right approach to write a translator? > > Even if the interfaces to those python libraries is not very > "lisp-like" -- wouldn't it be easier to wrap up ugly interfaces in a > clean interface than to start from scratch? Yeah, but then you have ugly interfaces. The right approach, IMHO, is to identify the problems found when writing libraries, and then use the power of lisp to "bend space-time", as someone put it recently. In essence, we need an abstraction for the rest of the world. Then everything is easy :-) We need programmers too, of course.
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <vRinb.11699$Gq.4459530@twister.nyc.rr.com>
Mario S. Mommer wrote:
> ····@emf.emf.net (Tom Lord) writes:
>
>>So, if Python has all these great libraries and Common Lisp needs
>>analogs of them, why isn't the right approach to write a translator?
>>
>>Even if the interfaces to those python libraries is not very
>>"lisp-like" -- wouldn't it be easier to wrap up ugly interfaces in a
>>clean interface than to start from scratch?
>
>
> Yeah, but then you have ugly interfaces.
>
> The right approach, IMHO, is to identify the problems found when
> writing libraries, and then use the power of lisp to "bend
> space-time", as someone put it recently.
>
> In essence, we need an abstraction for the rest of the world. Then
> everything is easy :-)
>
> We need programmers too, of course.
IIUC, when Pythonistas brag about their libs they are talking mainly
about C libs made available via the Python FFI. This works better in
Python because there is only one Python, so any FFI grunt-work is hugely
rewarded/beneficial.
UFFI is a start, but it does not cover all implementations and it does
not cover all FFI requirements.
Me, I have on my plate plans to do the FFI work for ImageMagick. I have
FFI for openGL and FreeGlut, was not too painful. Macros helped.
Corman and ACL (I hear) have stuff to automate some of the work, tho of
course to their own FFIs.
Lisp is now in the phase of Getting Noticed. This we can assume will
lead to folks Getting Excited and wanting to Actually Use it. To do so,
they will have to UFFI up some bindings to Various Libraries.
If the CL community wants to be useful (ha!), UFFI should be completed.
In all dimensions. Callbacks from C should be UFFI-ized, and un-UFFI-ed
implementations should be brought under the UFFI umbrella.
Build it and they will come.
kenny
--
http://tilton-technology.com
Why Lisp?...
http://alu.cliki.net/RtL%20Highlight%20FilmFrom: james anderson Subject: Re: python libs v lisp coolness? Date: Message-ID: <3F9DB1EE.5BDBA1CA@setf.de>
Kenny Tilton wrote: > > Mario S. Mommer wrote: > > ... > > Me, I have on my plate plans to do the FFI work for ImageMagick. I have > FFI for openGL and FreeGlut, was not too painful. Macros helped. > do you have a pointer to a clean api specification for imagemagick? in particular the c interface rather than the c++ interface? ...
From: Edi Weitz Subject: Re: python libs v lisp coolness? Date: Message-ID: <87znfm2mr1.fsf@bird.agharta.de>
On Tue, 28 Oct 2003 03:06:29 +0200, james anderson <··············@setf.de> wrote: > do you have a pointer to a clean api specification for imagemagick? > in particular the c interface rather than the c++ interface? You are aware of this one? <http://www.imagemagick.org/www/api.html> I haven't really looked at it so I don't know if it's any good. Edi.
From: james anderson Subject: Re: python libs v lisp coolness? Date: Message-ID: <3F9DBEBA.94C7B41F@setf.de>
Edi Weitz wrote: > > On Tue, 28 Oct 2003 03:06:29 +0200, james anderson <··············@setf.de> wrote: > > > do you have a pointer to a clean api specification for imagemagick? > > in particular the c interface rather than the c++ interface? > > You are aware of this one? > > <http://www.imagemagick.org/www/api.html> > > I haven't really looked at it so I don't know if it's any good. it made me realize where the directory full if .h files is. now, is there some uffi-auxilliary which parses .h files? looking around i found only conjectures and dead links. ...
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <0Cknb.12071$Gq.4540364@twister.nyc.rr.com>
james anderson wrote:
>
> Edi Weitz wrote:
>
>>On Tue, 28 Oct 2003 03:06:29 +0200, james anderson <··············@setf.de> wrote:
>>
>>
>>>do you have a pointer to a clean api specification for imagemagick?
>>>in particular the c interface rather than the c++ interface?
>>
>>You are aware of this one?
>>
>> <http://www.imagemagick.org/www/api.html>
>>
>>I haven't really looked at it so I don't know if it's any good.
>
>
> it made me realize where the directory full if .h files is.
> now, is there some uffi-auxilliary which parses .h files?
> looking around i found only conjectures and dead links.
>
> ...
Not that I know of. I have played with Corman's tool for auto-converting
to Corman FFI. One could buy Corman and convert from their ffi to uffi,
or if the source is incuded modify it to "write" UFFI instead. ACL says
it does auto-FFI, but (kick me) I have not yet asked them where they hid
it (I can't find it, but I looked for less than 120 seconds). I was
unaware of the tool when I was interfacing Cello to OpenGL and Freeglut.
Could CParse be used? Actually, I also heard of a C++ parser and looked
at that when lisp-nyc was looking at porting a C++ RoboCup team to Lisp.
I'd have to dig into the archives to find that link.
What I did with OpenGL was to write macros which expanded into UFFI,
macros tailored for global editing of a .h file into calls to my macros:
- change all /* to ;;
- delete all commas
- s/<return-type-decl> /(my-macro (<return-type /w
etc etc. then I eyeballed each substitution as they went by watching for
places I had to hand-edit. tedious but linear.
kenny
--
http://tilton-technology.com
Why Lisp?...
http://alu.cliki.net/RtL%20Highlight%20FilmFrom: Christian Lynbech Subject: Re: python libs v lisp coolness? Date: Message-ID: <8765i9dbp3.fsf@dhcp229.ted.dk.eu.ericsson.se>
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
Kenny> Could CParse be used?
Cparse was written for CMUCL, but I did a semi-simple fix to gtet it
to work with ACL instead. This suggests to me that it should not be to
complicated to get a UFFI version of it.
I'll try to see if I can find my fix somewhere.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)From: james anderson Subject: Re: python libs v lisp coolness? Date: Message-ID: <3F9E30D4.C78D0AA7@setf.de>
can given me a hint about where to find the base version too? that was the dead link i referred to. ... Christian Lynbech wrote: > > Cparse was written for CMUCL, but I did a semi-simple fix to gtet it > to work with ACL instead. This suggests to me that it should not be to > complicated to get a UFFI version of it. > > I'll try to see if I can find my fix somewhere. >
From: Henrik Motakef Subject: Re: python libs v lisp coolness? Date: Message-ID: <868yn5ix6m.fsf@pokey.internal.henrik-motakef.de>
james anderson <··············@setf.de> writes: > now, is there some uffi-auxilliary which parses .h files? > looking around i found only conjectures and dead links. There is some UFFI support in recent versions of the Swig interface generator (which already can output some custom s-expression format). It isn't too pretty, and last time I looked it wasn't complete. Oh, and it doesn't use plain C headers, you have to augment them with some Swig-specific annotations. On the pro side, for a lot of libraries there are already Swig bindings that could probably be reused, and it handles C++ as well as plain C by automatically generating wrapper functions for methods and stuff, creates accessors for global variables (think errno), and some other useful stuff. I'm not sure whether it is the best way to go, but it's surely one that should be further explored.
From: james anderson Subject: Re: python libs v lisp coolness? Date: Message-ID: <3F9E4371.962195FA@setf.de>
is there a repository for the interface files? the swig site didn't given any hints about that and the mailing list archive ovver no apparent search capability. Henrik Motakef wrote: > > james anderson <··············@setf.de> writes: > > > now, is there some uffi-auxilliary which parses .h files? > > looking around i found only conjectures and dead links. > > There is some UFFI support in recent versions of the Swig interface > generator (which already can output some custom s-expression > format). It isn't too pretty, and last time I looked it wasn't > complete. > > Oh, and it doesn't use plain C headers, you have to augment them with > some Swig-specific annotations. On the pro side, for a lot of > libraries there are already Swig bindings that could probably be > reused, and it handles C++ as well as plain C by automatically > generating wrapper functions for methods and stuff, creates accessors > for global variables (think errno), and some other useful stuff. I'm > not sure whether it is the best way to go, but it's surely one that > should be further explored.
From: j.barner Subject: Re: python libs v lisp coolness? Date: Message-ID: <8c2415f1.0310280807.7775d8ff@posting.google.com>
james anderson <··············@setf.de> wrote in message news:<·················@setf.de>... > is there a repository for the interface files? the swig site didn't given any > hints about that and the mailing list archive ovver no apparent search capability. although swig is quite good, its programmers have to build a new C/C++ preprocessor. I have tried it and it has still has some problems in parsing the header files. Franz has a modified gcc for parsing and generating a FFI for Allegro, but its development seems to be stopped (ftp://ftp.franz.com/pub/cbind/5.0.beta) A promising approach is at http://www.gccxml.org/HTML/Index.html They represent the structure of C++ programs in xml files. Should be possible for cl-xml to parse and generate interface definitions > > Henrik Motakef wrote: > > > > james anderson <··············@setf.de> writes: > > > > > now, is there some uffi-auxilliary which parses .h files? > > > looking around i found only conjectures and dead links. > > > > There is some UFFI support in recent versions of the Swig interface > > generator (which already can output some custom s-expression > > format). It isn't too pretty, and last time I looked it wasn't > > complete. > > > > Oh, and it doesn't use plain C headers, you have to augment them with > > some Swig-specific annotations. On the pro side, for a lot of > > libraries there are already Swig bindings that could probably be > > reused, and it handles C++ as well as plain C by automatically > > generating wrapper functions for methods and stuff, creates accessors > > for global variables (think errno), and some other useful stuff. I'm > > not sure whether it is the best way to go, but it's surely one that > > should be further explored.
From: Matthias Koeppe Subject: SWIG and UFFI (was: python libs v lisp coolness?) Date: Message-ID: <uw5fzhduzsw.fsf_-_@merkur.math.uni-magdeburg.de>
james anderson <··············@setf.de> writes:
> is there a repository for the interface files? the swig site didn't
> given any hints about that and the mailing list archive ovver no
> apparent search capability.
I don't think there is such a repository. There seem to be a number
of projects that use SWIG to maintain language bindings to C and C++
libraries. But though SWIG supports many languages, most bindings
projects seem to pick just one language. Also the interfaces are
pretty specific for the chosen language.
Here are links to two projects that I know (in case you just wanted to
see what SWIG interface files look like).
http://cvs.sourceforge.net/viewcvs.py/primaldual/cplex-glue/
This creates a Guile interface to some proprietary library.
This interface file uses a SWIG feature called "typemaps" to
generate C code that does automatic conversion between some C
datastructures and Lisp datastructures and that checks the
return status. This way, SWIG generates "friendly" bindings
to the library.
http://savannah.nongnu.org/cgi-bin/viewcvs/guile-num/guile-num/gsl/
This creates a Guile interface to the GNU Scientific
Library. SWIG only seems to be used to create "raw" bindings
to all library functions. Additional Scheme code does the
conversion between some C datastructures and Lisp
datastructures to create "friendly" bindings.
> Henrik Motakef wrote:
>>
>> james anderson <··············@setf.de> writes:
>>
>> > now, is there some uffi-auxilliary which parses .h files?
>> > looking around i found only conjectures and dead links.
>>
>> There is some UFFI support in recent versions of the Swig interface
>> generator (which already can output some custom s-expression
>> format). It isn't too pretty, and last time I looked it wasn't
>> complete.
I have improved the s-expression output in the CVS version of SWIG.
(In the released version (SWIG 1.3.19), sometimes unreadable objects
were written out.)
The UFFI support really is just a little CL program (~250 lines, see
Examples/s-exp/uffi.lisp in the CVS version of SWIG) that reads SWIG's
s-expression output and writes UFFI declarations.
So far it handles only very few things: Only C functions and
structures are supported. Global variables are not handled yet, and
no C++ either.
Anyone who wants to help?
>> Oh, and it doesn't use plain C headers, you have to augment them with
>> some Swig-specific annotations.
Actually, you don't have to. SWIG can parse most C and C++ headers
directly. The Swig-specific annotations are only needed if you want
to use SWIG features like typemaps that improve the integration with
the target language.
--
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppeFrom: Christian Lynbech Subject: Re: python libs v lisp coolness? Date: Message-ID: <87wuapb9nv.fsf@dhcp229.ted.dk.eu.ericsson.se>
Is the link you think of is this one:
http://bricoworks.com/~moore/cparse/index.html
I cannot imagine me getting it anywhere else and that link does indeed
seems to be out of order.
I'll check to see if I have the original sources floating around as
well.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <aMunb.13486$Gq.4759940@twister.nyc.rr.com>
Henrik Motakef wrote:
> james anderson <··············@setf.de> writes:
>
>
>>now, is there some uffi-auxilliary which parses .h files?
>>looking around i found only conjectures and dead links.
>
>
> There is some UFFI support in recent versions of the Swig interface
> generator (which already can output some custom s-expression
> format). It isn't too pretty, and last time I looked it wasn't
> complete.
>
> Oh, and it doesn't use plain C headers, you have to augment them with
> some Swig-specific annotations. On the pro side, for a lot of
> libraries there are already Swig bindings that could probably be
> reused, and it handles C++ as well as plain C by automatically
> generating wrapper functions for methods and stuff, creates accessors
> for global variables (think errno), and some other useful stuff.
I can see singly-inherited class hierarchies expressed via C-structs in
astraightforward fashion, but god bless 'em if they worked out some way
to handle multiply-inheriting classes.
I'm
> not sure whether it is the best way to go, but it's surely one that
> should be further explored.
If I get around to doing bindings for ImageMagick, I'll look at using
Swig. Not that there are not other tools, but I like the sound of "re-used".
But that still leaves UFFI not doing callbacks from C and not covering
all the implementations. Well, hang on, I have not downloaded UFFI for
ages, so whadoiknow?
kenny
--
http://tilton-technology.com
Why Lisp?...
http://alu.cliki.net/RtL%20Highlight%20FilmFrom: Matthias Koeppe Subject: Re: python libs v lisp coolness? Date: Message-ID: <uw58yn5ux3t.fsf@merkur.math.uni-magdeburg.de>
Kenny Tilton <·······@nyc.rr.com> writes: > Henrik Motakef wrote: >> james anderson <··············@setf.de> writes: >>>now, is there some uffi-auxilliary which parses .h files? >>>looking around i found only conjectures and dead links. >> There is some UFFI support in recent versions of the Swig interface >> generator (which already can output some custom s-expression >> format). It isn't too pretty, and last time I looked it wasn't >> complete. >> Oh, and it doesn't use plain C headers, you have to augment them with >> some Swig-specific annotations. On the pro side, for a lot of >> libraries there are already Swig bindings that could probably be >> reused, and it handles C++ as well as plain C by automatically >> generating wrapper functions for methods and stuff, creates accessors >> for global variables (think errno), and some other useful stuff. > > I can see singly-inherited class hierarchies expressed via C-structs > in astraightforward fashion, but god bless 'em if they worked out some > way to handle multiply-inheriting classes. There is currently no support in SWIG's UFFI code to handle any C++ (see my other posting). SWIG's approach to making C++ libraries available to other languages is like the following. 1. It generates C wrappers for all methods and also getter and setter functions to access class slots. 2. These C wrapper functions are imported into the target language via the FFI. 3. SWIG also generates target language code that builds "proxy classes" that mirror the C++ class hierarchy. The methods of these proxy classes simply call the imported C wrapper functions. As far as I know, multiple inheritance is supported. Step 3 (generating proxy classes) is not yet supported by all language back-ends of SWIG. Currently this is being added for the CLOS-related object system of the Scheme system Guile. -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe
From: Marco Antoniotti Subject: Re: python libs v lisp coolness? Date: Message-ID: <Tgynb.86$KR3.39829@typhoon.nyu.edu>
Edi Weitz wrote: > On Tue, 28 Oct 2003 03:06:29 +0200, james anderson <··············@setf.de> wrote: > > >>do you have a pointer to a clean api specification for imagemagick? >>in particular the c interface rather than the c++ interface? > > > You are aware of this one? > > <http://www.imagemagick.org/www/api.html> > > I haven't really looked at it so I don't know if it's any good. > The simple fact that function names do not have a standardized prefix make my stomach hurt. Cheers -- marco
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <Onknb.12010$Gq.4529605@twister.nyc.rr.com>
james anderson wrote:
>
> Kenny Tilton wrote:
>
>>Mario S. Mommer wrote:
>>
>>...
>>
>>Me, I have on my plate plans to do the FFI work for ImageMagick. I have
>>FFI for openGL and FreeGlut, was not too painful. Macros helped.
>>
>
>
> do you have a pointer to a clean api specification for imagemagick?
> in particular the c interface rather than the c++ interface?
>
> ...
Hmmm. I just DLed the whole thing from the site Edi gave. I heard it was
a "C" lib. And I just looked at some of the .h files and it all looked
C-ish. The web site does say "C, C++, Ruby, ..." so I think Lisp can get
there. Not sure what is meant by "C interface rather than C++
interface", unless the C++ interface is the moral equivalent of FFI
bindings, viz, just enough syntax to make C++ happy.
--
http://tilton-technology.com
Why Lisp?...
http://alu.cliki.net/RtL%20Highlight%20FilmFrom: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <Fnnnb.12329$Gq.4643212@twister.nyc.rr.com>
Paul Foley wrote:
> On Tue, 28 Oct 2003 00:35:39 GMT, Kenny Tilton wrote:
>
>
>>IIUC, when Pythonistas brag about their libs they are talking mainly
>>about C libs made available via the Python FFI.
>
>
> *What* Python FFI? Python doesn't *have* an FFI, in any sense I
> recognise. You interface Python to C by writing more C -- that's a
> C FFI for linking to Python, not a Python FFI for linking to C.
>
Can Python just call C? No. Glue is needed. You call that "a C FFI for
linking to Python"? Where Python wants to call C? I think we're headed
for a word game. Have fun, I'm out.
--
http://tilton-technology.com
Why Lisp?...
http://alu.cliki.net/RtL%20Highlight%20FilmFrom: Mario S. Mommer Subject: Re: python libs v lisp coolness? Date: Message-ID: <fz4qxs8b1m.fsf@cupid.igpm.rwth-aachen.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> IIUC, when Pythonistas brag about their libs they are talking mainly
> about C libs made available via the Python FFI. This works better in
> Python because there is only one Python, so any FFI grunt-work is
> hugely rewarded/beneficial.
Yeah, but then they have only one implementation.
> UFFI is a start, but it does not cover all implementations and it does
> not cover all FFI requirements.
I have found normal FFI bindings to be dangerous and rather useless by
themselves.
> Me, I have on my plate plans to do the FFI work for ImageMagick. I
> have FFI for openGL and FreeGlut, was not too painful. Macros helped.
Do you have them on the 'net?
> Corman and ACL (I hear) have stuff to automate some of the work, tho
> of course to their own FFIs.
<plug> I've been doing some bindings for GTK (see
http://common-lisp.net/project/lgtk/) </plug> and found that to do
really usefull bindings you need at least to look at the functions,
and think on how to interface with the lib. I don't think you can do
that last bit automagically.
> Lisp is now in the phase of Getting Noticed. This we can assume will
> lead to folks Getting Excited and wanting to Actually Use it. To do
> so, they will have to UFFI up some bindings to Various Libraries.
Yes, but having a bunch of C prototypes to be called from Lisp
probably won't make you happy. You want garbage-collection support. If
a function returns twice the same pointer, you want to get the same
object each time. You probably also want to be able to use whatever
you want as a callback - not only functions defined with defcallback
or whatever. You want the thing to be lisp-friendly: errors should not
mess up your image. This is a bit of work, but is essential IMHO.
> If the CL community wants to be useful (ha!), UFFI should be
> completed. In all dimensions. Callbacks from C should be UFFI-ized,
> and un-UFFI-ed implementations should be brought under the UFFI
> umbrella.
Yes, native callbacks (not just the possibility to fake them somehow)
are aboslutely essentiall.
Regards,
Mario.From: james anderson Subject: Re: python libs v lisp coolness? Date: Message-ID: <3F9FBAE8.A3F03F79@setf.de>
"Mario S. Mommer" wrote: > >... > > > Me, I have on my plate plans to do the FFI work for ImageMagick. I > > have FFI for openGL and FreeGlut, was not too painful. Macros helped. > > Do you have them on the 'net? > if you are looking for an opengl interface description. there are several: http://www.cliki.net/OpenGL%20Bindings ...
From: Alexander Schmolck Subject: Re: python libs v lisp coolness? Date: Message-ID: <yfsad7khyqn.fsf@black132.ex.ac.uk>
Mario S. Mommer <········@yahoo.com> writes: > Kenny Tilton <·······@nyc.rr.com> writes: > > IIUC, when Pythonistas brag about their libs they are talking mainly > > about C libs made available via the Python FFI. This works better in > > Python because there is only one Python, so any FFI grunt-work is > > hugely rewarded/beneficial. > > Yeah, but then they have only one implementation. OK, since I sense a shared misconception here, let me put this straight. Who would in his right mind would want (or be proud of) using what is essentially a collection of C interfaces as the library base of a HLL? AFAIK most of python's libs are exclusively written in python, only some also use C/C++ and only very few are completely done in C/C++. That python makes it relatively easy to interface to C/C++ surely is one of the reasons for the good library support, but that doesn't mean that most python libraries typically just thinly wrap some low-level C lib, whereas equivalent CL libraries provide some wonderful high-level interfaces. In fact, from what I've seen often the opposite is the case (presumably pythonistas don't already tire themselves out trying to get some low-level crap to work portably between n-implementations). To pick just two examples python has a fairly nice and high-level library for doing array calculations (Numeric). The only equivalent thing I've seen in CL is some undocumented low-level interface to lapack that hadn't seen a proper release for ages last time I looked. Similarly, on a smaller scale, the command line arguments handling stuff (regardless of what one might think of command lines) I've seen for CL looks like C, whereas python comes with a much pxumore thoughtful a nicer interface (optparse). 'as
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <6cTnb.17331$Gq.5372245@twister.nyc.rr.com>
Alexander Schmolck wrote: > Mario S. Mommer <········@yahoo.com> writes: > > >>Kenny Tilton <·······@nyc.rr.com> writes: >> >>>IIUC, when Pythonistas brag about their libs they are talking mainly >>>about C libs made available via the Python FFI. This works better in >>>Python because there is only one Python, so any FFI grunt-work is >>>hugely rewarded/beneficial. >> >>Yeah, but then they have only one implementation. > > > OK, since I sense a shared misconception here, let me put this straight. Who > would in his right mind would want (or be proud of) using what is essentially > a collection of C interfaces as the library base of a HLL? Agreed. As crazy as it sounds, in many cases re-inventing something like OpenGL in native Common Lisp rapidly pays off over the "quicker" binding route. Dealing with a non-Lisp system can be death by a thousand cuts. Thomas wants me to use GTK for my CL Gui, Jay wants me to use Tk, but my feeling is that this is not a high-level application I am offering, it is meant to be the standard CL gui. That makes it seriously worth making it CL all the way down, OpenGL being a reasonable value for "all the way": it is not all the way, but it is cross-platform and it does not make me deal with its own objects (other than display lists). > > AFAIK most of python's libs are exclusively written in python, only some also > use C/C++ and only very few are completely done in C/C++. I stand corrected. But Python took off because of its easy integration with C (on top of everything else like interactivity). If people are writing CSound versions in Python, it is because the community exploded and the hands are available. It also explains why Python is experienced as slow. :) OK, just checked, of course they are interfacing to the "C" CSound. Maybe we are talking about two different things. I just want to get my mitts on OpenGL and ImageMagick and Music. It is mad cool that Rick Taube has produced Common Music, but that was no small project. I am talking about leveraging existing C libs for a quick win expanding CL programmer reach--with, yes, more or less friction coping with the land of "C". > > That python makes it relatively easy to interface to C/C++ surely is one of > the reasons for the good library support, but that doesn't mean that most > python libraries typically just thinly wrap some low-level C lib, whereas > equivalent CL libraries provide some wonderful high-level interfaces. oh. you knew all that. :) > > In fact, from what I've seen often the opposite is the case (presumably > pythonistas don't already tire themselves out trying to get some low-level > crap to work portably between n-implementations). tell me about it. CLisp, could not just implement the :include option for defstruct, could they? <sigh> kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Mario S. Mommer Subject: Re: python libs v lisp coolness? Date: Message-ID: <fzad7j7v9z.fsf@cupid.igpm.rwth-aachen.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> I am talking about leveraging existing C libs for a quick win
> expanding CL programmer reach--with, yes, more or less friction coping
> with the land of "C".
One of the things I tried with lgtk is precisely to get some knowledge
on the general problem of interfacing with C libs. I think I have a
lot of it figured out, and I /think/ [1] that I could cook up similar
bindings for a library like lesstiff (for instance) in less than a
week or so, complete with GC support and error handling. One of the
projects I have waiting is to take this interfacing code out and make
it a meta-library, a library for writing usable bindings.
Portability of the framework is relatively easy, as soon as I have
1. Native callback support.
2. finalization, weak pointers and gc hooks
3. Plain old ffi.
4. A posibility to install signal handlers
5. A way to cath the return-to-toplevel debugging event. In
cmucl this amounts to caching
common-lisp::*top-level-catcher*.
(am I asking too much? :O) )
How do current free implementations support 1.-5. above? Cmucl does,
but I'm not aware of others. Does CLisp?
-----
[1] ...but I don't /know/...From: Matthias Subject: Re: python libs v lisp coolness? Date: Message-ID: <36wwuan59l1.fsf@chagall.ti.uni-mannheim.de>
Kenny Tilton <·······@nyc.rr.com> writes: > Dealing with a non-Lisp system can be death by a > thousand cuts. Thomas wants me to use GTK for my CL Gui, Jay wants me > to use Tk, but my feeling is that this is not a high-level application > I am offering, it is meant to be the standard CL gui. That makes it > seriously worth making it CL all the way down, OpenGL being a > reasonable value for "all the way": it is not all the way, but it is > cross-platform and it does not make me deal with its own objects > (other than display lists). Interestingly, most other communities (in the Perl, Python, Ruby league) do not have a "pure" GUI and seem to be quite happy to use whatever already exists _and_ whatever they already know. They also build impressive applications on top of these simplistic libs. If I had the choice between a lib I already know (and eventually have documentation for on my desk) and a lib which is 100%-pure-whatever I would choose the stuff I know in most cases (unless the advantages of the new lib are outstanding). From a marketing perspective it seems also easier to say "you can just use GTK/TK/KDE/whatever as you did in your previous projects" than to say "we have here something that solves essentially the same problem, but works totally different than everything else, but is much more Lisp/Perl/Python/whatever-like". Just 2 cents.
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <r%7ob.20739$Gq.6095618@twister.nyc.rr.com>
Matthias wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Dealing with a non-Lisp system can be death by a
>>thousand cuts. Thomas wants me to use GTK for my CL Gui, Jay wants me
>>to use Tk, but my feeling is that this is not a high-level application
>>I am offering, it is meant to be the standard CL gui. That makes it
>>seriously worth making it CL all the way down, OpenGL being a
>>reasonable value for "all the way": it is not all the way, but it is
>>cross-platform and it does not make me deal with its own objects
>>(other than display lists).
>
>
> Interestingly, most other communities (in the Perl, Python, Ruby
> league) do not have a "pure" GUI and seem to be quite happy to use
> whatever already exists _and_ whatever they already know.
Yeah, but they are a bunch of "quick-win" artists just trying to script
up a cool app. So they are doing the sensible thing. ANy GUI they
developed ground-up would be no better than GTK et al, so why bother?
But the presumption there is just that: GTk is as Bad (good) As Its
Gonna Be. Cello soars above GTk, because of Cells. I have married Cells
to things like GTk in the past. Added a ton of friction, broke a few
things, and there was no added value anyway because now the arrow points
in the other direction: Cells make widgets easy to roll from scratch.
So Cello would not really be built atop GTk, cuz I'm making my own
cell-driven class hierarchy anyway. it would be built atop GLib (or XLib
if I go that way, but for now Freeglut is worrying about all that).
Am I the exception because I have Cells? I do not think so. I think if
someone using a Better Language such as CL sat down to do a GUI from
scratch, it would always turn out more powerful than GTk, by as great a
margin/factor as CL itself excels over C. There are sad cases out there
of people still clinging to the lifeless body of Garnet, unable to let
go (of course that has KR, prior art for Cells).
There is something about the language.
As for the marketing thing ("You can still use GTk!"), that's just lame.
CLers need to burst out laughing when someone asks if there are GTk
bindings, then say "Wait till you see Cello, the CL Gui."
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Mario S. Mommer Subject: Re: python libs v lisp coolness? Date: Message-ID: <fzznfi6ee6.fsf@cupid.igpm.rwth-aachen.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> Matthias wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Dealing with a non-Lisp system can be death by a
> >>thousand cuts. Thomas wants me to use GTK for my CL Gui, Jay wants me
> >>to use Tk, but my feeling is that this is not a high-level application
> >>I am offering, it is meant to be the standard CL gui. That makes it
> >>seriously worth making it CL all the way down, OpenGL being a
> >>reasonable value for "all the way": it is not all the way, but it is
> >>cross-platform and it does not make me deal with its own objects
> >>(other than display lists).
> > Interestingly, most other communities (in the Perl, Python, Ruby
> > league) do not have a "pure" GUI and seem to be quite happy to use
> > whatever already exists _and_ whatever they already know.
>
> Yeah, but they are a bunch of "quick-win" artists just trying to
> script up a cool app. So they are doing the sensible thing. ANy GUI
> they developed ground-up would be no better than GTK et al, so why
> bother?
Have you ever used GTK? Greenspuns tenth has taken a few victims in
GTK-land. GTK is pretty good, and has the benefit of actually
existing.
> But the presumption there is just that: GTk is as Bad (good) As Its
> Gonna Be. Cello soars above GTk, because of Cells. I have married
> Cells to things like GTk in the past. Added a ton of friction, broke a
> few things, and there was no added value anyway because now the arrow
> points in the other direction: Cells make widgets easy to roll from
> scratch.
>
> So Cello would not really be built atop GTk, cuz I'm making my own
> cell-driven class hierarchy anyway. it would be built atop GLib (or
> XLib if I go that way, but for now Freeglut is worrying about all
> that).
>
> Am I the exception because I have Cells? I do not think so. I think if
> someone using a Better Language such as CL sat down to do a GUI from
> scratch, it would always turn out more powerful than GTk, by as great
> a margin/factor as CL itself excels over C. There are sad cases out
> there of people still clinging to the lifeless body of Garnet, unable
> to let go (of course that has KR, prior art for Cells).
>
> There is something about the language.
>
> As for the marketing thing ("You can still use GTk!"), that's just
> lame. CLers need to burst out laughing when someone asks if there are
> GTk bindings, then say "Wait till you see Cello, the CL Gui."
>
> :)
Thank you for adding that smiley.From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <zC8ob.20921$Gq.6126792@twister.nyc.rr.com>
Mario S. Mommer wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Matthias wrote:
>>
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>Dealing with a non-Lisp system can be death by a
>>>>thousand cuts. Thomas wants me to use GTK for my CL Gui, Jay wants me
>>>>to use Tk, but my feeling is that this is not a high-level application
>>>>I am offering, it is meant to be the standard CL gui. That makes it
>>>>seriously worth making it CL all the way down, OpenGL being a
>>>>reasonable value for "all the way": it is not all the way, but it is
>>>>cross-platform and it does not make me deal with its own objects
>>>>(other than display lists).
>>>
>>>Interestingly, most other communities (in the Perl, Python, Ruby
>>>league) do not have a "pure" GUI and seem to be quite happy to use
>>>whatever already exists _and_ whatever they already know.
>>
>>Yeah, but they are a bunch of "quick-win" artists just trying to
>>script up a cool app. So they are doing the sensible thing. ANy GUI
>>they developed ground-up would be no better than GTK et al, so why
>>bother?
>
>
> Have you ever used GTK? Greenspuns tenth has taken a few victims in
> GTK-land. GTK is pretty good, and has the benefit of actually
> existing.
I looked over the doc. Yawn.
Have you ever used my GUIs, built on QuickDraw, win32 GDT, and/or
OpenGL/Freeglut? Have you been to my web site? Do you know how long it
took me to re-invent GDT scrollbars from scratch using that GUI, or the
nifty tab control?
I know GTk is good (best?) by industry standards, but I'll be adjusting
those shortly.
>>As for the marketing thing ("You can still use GTk!"), that's just
>>lame. CLers need to burst out laughing when someone asks if there are
>>GTk bindings, then say "Wait till you see Cello, the CL Gui."
>>
>>:)
>
>
> Thank you for adding that smiley.
That wasn't to soften the prediction, just to alleviate by some small
degree the drumbeat tedium of my saturation marketing.
:)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Henrik Motakef Subject: Re: python libs v lisp coolness? Date: Message-ID: <86n0bi7rme.fsf@pokey.internal.henrik-motakef.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> As for the marketing thing ("You can still use GTk!"), that's just
> lame. CLers need to burst out laughing when someone asks if there are
> GTk bindings, then say "Wait till you see Cello, the CL Gui."
Unless one can use Cello to build apps that look and feel like apps
native to the platform they run on (where the "platform" is something
like Gnome, KDE or Windows), including widget and icon themes, the
preferred keybinding scheme, integration with assistive technologies,
standard dialogs, general HIG compliance etc., prepare to get laughed
at yourself.
Making a GUI lib that is a joy to program is only half of the
battle. You must also make the apps that use it a joy to use, or at
least non-annoying. The first rule for that is, I fear, "when in rome,
do as romans do."
Unless you are writing some kind of media player, of course. In that
case, unusable-but-shiny seems to be the way to go.From: Daniel Barlow Subject: Re: python libs v lisp coolness? Date: Message-ID: <87vfq6ervm.fsf@noetbook.telent.net>
Henrik Motakef <············@henrik-motakef.de> writes: > Unless one can use Cello to build apps that look and feel like apps > native to the platform they run on (where the "platform" is something > like Gnome, KDE or Windows), including widget and icon themes, the > preferred keybinding scheme, integration with assistive technologies, > standard dialogs, general HIG compliance etc., prepare to get laughed > at yourself. Bah. No Gnome or KDE user really expects all his apps to look like Gnome, or look like KDE. (If you'd given "Windows" or "Mac OS" as the platform examples, you'd have a much more convincing argument). If Gnome and KDE were really such entrenched UI standards, Red Hat wouldn't have been able to get away with Bluecurve -dan -- http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
From: Jan Rychter Subject: Re: python libs v lisp coolness? Date: Message-ID: <m2brrubkd6.fsf@tnuctip.rychter.com>
>>>>> "Daniel" == Daniel Barlow <···@telent.net>: Daniel> Henrik Motakef <············@henrik-motakef.de> writes: >> Unless one can use Cello to build apps that look and feel like apps >> native to the platform they run on (where the "platform" is >> something like Gnome, KDE or Windows), including widget and icon >> themes, the preferred keybinding scheme, integration with assistive >> technologies, standard dialogs, general HIG compliance etc., prepare >> to get laughed at yourself. Daniel> Bah. No Gnome or KDE user really expects all his apps to look Daniel> like Gnome, or look like KDE. (If you'd given "Windows" or Daniel> "Mac OS" as the platform examples, you'd have a much more Daniel> convincing argument). Daniel> If Gnome and KDE were really such entrenched UI standards, Red Daniel> Hat wouldn't have been able to get away with Bluecurve Still, writing a GUI toolkit is hard. Very hard. And unfortunately most programmers seem to forget just how important consistency is to users. One of the reasons why UNIX didn't become more popular was that everyone had to write his own GUI. So we had Xaw, Xaw3d, XFCE, Motif, GTK+, XForms, Qt. I probably missed many others. And mind you, it's not just pixel-perfect native-looking widgets. It's the small stuff that's so hard to get right, like proper TAB-cycling between fields in dialogs, behavior of menus when the pointer is being dragged, etc. And of course customization, I really want to configure _all_ of my applications in one place. That's why I still think that using GTK widgets with CL is superior to just reinventing everything all over again. BTW, I think Bluecurve is a very good move on RedHat's part, even if it's a bit too late in coming. They should have done it a long time ago. --J.
From: Daniel Barlow Subject: Re: python libs v lisp coolness? Date: Message-ID: <87wuaicvoh.fsf@noetbook.telent.net>
Jan Rychter <···@rychter.com> writes: > And mind you, it's not just pixel-perfect native-looking widgets. It's > the small stuff that's so hard to get right, like proper TAB-cycling > between fields in dialogs, behavior of menus when the pointer is being > dragged, etc. And of course customization, I really want to configure > _all_ of my applications in one place. I'm not arguing that a consistent standard UI is undesirable. I'm saying that I don't think Gtk is (currently, anyway) that standard. As you point out, there are a whole bunch of other more-or-less widely used widget libraries. > BTW, I think Bluecurve is a very good move on RedHat's part, even if > it's a bit too late in coming. They should have done it a long time ago. Right. But if Gtk was the standard Unix GUI, nobody would be using KDE so there would have been no need for Bluecurve. -dan -- http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
From: Pascal Bourguignon Subject: Re: python libs v lisp coolness? Date: Message-ID: <87ekwq1lxq.fsf@thalassa.informatimago.com>
Jan Rychter <···@rychter.com> writes: > That's why I still think that using GTK widgets with CL is superior to > just reinventing everything all over again. I totally agree with you, only that what I want is to use the GNUstep "widgets" with CL. :-) If only I could fork myself... -- __Pascal_Bourguignon__ http://www.informatimago.com/
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <Fv9ob.21161$Gq.6183510@twister.nyc.rr.com>
Henrik Motakef wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>As for the marketing thing ("You can still use GTk!"), that's just
>>lame. CLers need to burst out laughing when someone asks if there are
>>GTk bindings, then say "Wait till you see Cello, the CL Gui."
>
>
> Unless one can use Cello to build apps that look and feel like apps
> native to the platform they run on (where the "platform" is something
> like Gnome, KDE or Windows), including widget and icon themes, the
> preferred keybinding scheme, integration with assistive technologies,
> standard dialogs, general HIG compliance etc., prepare to get laughed
> at yourself.
Sure. If you check another post in this thread, you'll see I reinvented
win32 scrollbars (pixel-perfect, btw) just for that reason. On the Mac I
was able to use native controls because they got along better with my
model. back on win32, I took a few days to work in changing the window
color scheme to match the Display Control Panel options.
But the immediate objective of Cello is to give newbies One Common Lisp
Gui to play with, on any platform. The next objective is worrying about
platform look/feel. And possibly the easiest way on Unix derivatives is
a GTk back-end (or GLib if possible).
One thing at a time, or nothing gets done (see "Lisp OS").
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Rmagere Subject: Re: python libs v lisp coolness? Date: Message-ID: <bo8pvs$bhv$1@news.ox.ac.uk>
Kenny Tilton wrote: > > But the immediate objective of Cello is to give newbies One Common > Lisp Gui to play with, on any platform. The next objective is > worrying about platform look/feel. And possibly the easiest way on > Unix derivatives is a GTk back-end (or GLib if possible). > > One thing at a time, or nothing gets done (see "Lisp OS"). > By the way is there a way to try out Cello?
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <UMTpb.35040$Gq.9573828@twister.nyc.rr.com>
Rmagere wrote: > Kenny Tilton wrote: > >>But the immediate objective of Cello is to give newbies One Common >>Lisp Gui to play with, on any platform. The next objective is >>worrying about platform look/feel. And possibly the easiest way on >>Unix derivatives is a GTk back-end (or GLib if possible). >> >>One thing at a time, or nothing gets done (see "Lisp OS"). >> > > By the way is there a way to try out Cello? > > What I have now works on a hacked version of FreeGlut 1.x on win32, using OpenGL for all drawing. No doc, tho Cells per se have a little doc, and more is on the way. Tested so far under ACL and LW. CormanCL and CLisp successfully resisted a serious porting effort, but one or the other might work for someone strong on those environments. Nothing attempted yet on the X side, but Freeglut supports that. Freeglut itself just went thru a major release to celebrate getting adopted by RedHat when it realized the Glut license was unacceptable. I am going to look at using a FreeType-based OpenGL font package to replace current wgl* font mechanisms because I am concerned about getting fast & pretty type out of OpenGL and there is no point in continuing on ogl if it cannot do that. Then I would look at porting to Mac OSX, since I am looking at doing educational software again and I'd like support on win32 and OS X. Interestingly, I see the OS X Glut also has glutCheckLoop and another key function (window closing?) to make life with Glut viable (such fixes are the raison d'etre of FreeGlut). I have someone dropping by today to look at Cello to see if he wants to help (assuming I don't just punt and switch to CAPI). Cello was more about Lisp advocacy, but Lisp will get there anyway and it is a real pain worrying about multiple OSes and Lisp implementations, so Cello won't happen unless others support other platforms. What platform were you interested in? kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rmagere Subject: Re: python libs v lisp coolness? Date: Message-ID: <bo94vm$fm2$1@news.ox.ac.uk>
Kenny Tilton wrote: > > Tested so far under ACL and LW. CormanCL and CLisp successfully > resisted a serious porting effort, but one or the other might work > for someone strong on those environments. Nothing attempted yet on > the X side, but Freeglut supports that. <snipped> > What platform were you interested in? I am using ACL Professional Edition v5.0.1 and I also have available ACL Professional Edition v6.2 Special Edition (though v6.2 will expire soonish and I do all my work on 5.0.1 so I would be really interested in 5.0.1 but if 6.x is required then I might just go for have a look at Cello on the 6.2). I know there are some cg-user differences between 5.x and 6.x, such as although drawing a box works in both of them, drawing a line doesn't seem quite as portable (i.e. my 5.x code that draws lines shows nothing with 6.x haven't bothered to find out why), also I know that (make-window ...) in 5.0.1 takes the keywords :device and :parent which have been replaced by :class and :owner in 6.x (though I think that in 6.x :device and :parent might be just deprecated while in 5.x definitely :class and :owner are not there). rmagere
From: Kenny Tilton Subject: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <IdVpb.35050$Gq.9599049@twister.nyc.rr.com>
Rmagere wrote: > Kenny Tilton wrote: > >>Tested so far under ACL and LW. CormanCL and CLisp successfully >>resisted a serious porting effort, but one or the other might work >>for someone strong on those environments. Nothing attempted yet on >>the X side, but Freeglut supports that. > > <snipped> > >>What platform were you interested in? > > > I am using ACL Professional Edition v5.0.1 and I also have available ACL > Professional Edition v6.2 Special Edition (though v6.2 will expire soonish > and I do all my work on 5.0.1 so I would be really interested in 5.0.1 but > if 6.x is required then I might just go for have a look at Cello on the > 6.2). There ya go. I think original development was under ACL5. And I think you missed that Cello also runs under Lispworks, ie, no CG, no ACL nothing anywhere. How is your tolerance for pain? I could send you a zip with a pre-built Freeglut DLL built on NT but which is running now on XP. It would come with one very silly demo and a graphical object inspector which needs serious cosmetic work but which otherwise does neat things. Caveat: the Freeglut is obsolete and the Cells used by Cello is not the latest, so don't try swapping in the new version of Cells. Speaking of which, if you have not looked at Cells, Cello will be a little hard to follow once you look at the source. I plan tomorrow to put up a new release of Cells along with a new NetSaint-like hack and doc on how that got developed tomorrow. That will appear on the Cells SourceForge project. The current release of Cells is embedded in the SourceForge RoboCells project. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rmagere Subject: Re: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <boa7kr$qm7$1@news.ox.ac.uk>
Kenny Tilton wrote: > > How is your tolerance for pain? I could send you a zip with a > pre-built Freeglut DLL built on NT but which is running now on XP. It > would come with one very silly demo and a graphical object inspector > which needs serious cosmetic work but which otherwise does neat > things. My tolerance for pain is very variable i.e. if I am getting bored in the lab and I manage to get a toy example running relatively easily then I have a high tolerance for the remaining pain otherwise if after one hour (or two) of trying to get something to work, it still doesn't work then I tend to give up and not look at it for another month or longer. > > Caveat: the Freeglut is obsolete and the Cells used by Cello is not > the latest, so don't try swapping in the new version of Cells. > > Speaking of which, if you have not looked at Cells, Cello will be a > little hard to follow once you look at the source. I plan tomorrow to > put up a new release of Cells along with a new NetSaint-like hack and > doc on how that got developed tomorrow. That will appear on the Cells > SourceForge project. The current release of Cells is embedded in the > SourceForge RoboCells project. > I haven't yet looked at Cells (i.e. I know the idea behind it from your messages on the newsgroups and the website) but I haven't tryied to install it, I have been to www.sourceforge.net/projects/cells but no files are released (as you said) so if you think it is worthwile then I will wait for you to update the sourceforge page, play a little with cells and then ask again about cello. rmagere
From: Rmagere Subject: Re: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <boao28$42a$1@news.ox.ac.uk>
Kenny Tilton wrote:
>
> Speaking of which, if you have not looked at Cells, Cello will be a
> little hard to follow once you look at the source. I plan tomorrow to
> put up a new release of Cells along with a new NetSaint-like hack and
> doc on how that got developed tomorrow. That will appear on the Cells
> SourceForge project. The current release of Cells is embedded in the
> SourceForge RoboCells project.
>
Ok I have played about with Cells for the first time and it does look really
cool (especially as my work is on traffic analysis & synthesis where each
vehicles action is dependent on its current state and its neighbours current
state - i.e. self is good).
After having runned the following modified build.lisp
(load (compile-file #p"C:\\robocells\\asdf-155.lisp"))
(progn
(push (make-pathname
:device "C"
:directory \\robocells)
asdf:*central-registry*)
(asdf :oos 'asdf:load-op :robocells :force t)
#+force
(asdf :oos 'asdf:load-op :robocells :force t)
#+min
(asdf :oos 'asdf:load-op :robocells :force nil))
;^ the
last bracket is not present in your build.lisp
Everything compiles but for "Warning: While compilinb these undefined
functions were referenced: CELLS::WHILE".
Checking the code I see that while is not compiled for acl so I had to
change in (defun call-with-dataflow-management ...)
the following line
from: (while (and *sw-pending* ...
to: (aclwin:while (and *sw-pending* ...
then all the examples in 01-Cell-basics.lisp work fine, however I am not
satisfied with the aclwin:while as that ruins the compatibility of the file
(i.e. I cannot put all the changes only in build.lisp) so I was wondering if
there was a better way to solve this problem.
Anyway I am off now to see if I get a gain in changing my code to cell-code.From: Kenny Tilton Subject: Re: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <3P6qb.62357$ri.10299608@twister.nyc.rr.com>
Rmagere wrote:
> Kenny Tilton wrote:
>
>>Speaking of which, if you have not looked at Cells, Cello will be a
>>little hard to follow once you look at the source. I plan tomorrow to
>>put up a new release of Cells along with a new NetSaint-like hack and
>>doc on how that got developed tomorrow. That will appear on the Cells
>>SourceForge project. The current release of Cells is embedded in the
>>SourceForge RoboCells project.
>>
>
>
> Ok I have played about with Cells for the first time and it does look really
> cool (especially as my work is on traffic analysis & synthesis where each
> vehicles action is dependent on its current state and its neighbours current
> state - i.e. self is good).
Cool project. I'm jealous. I have long thought a traffic sim would be
great fun. I've been known to stand at hairy intersections during rush
hour to watch the ebb and flow of things. But I also imagine the project
would be a black hole of complexity, where realistic sim did not arise
until a tremendous amount of detail was just right.
Food for thought: Another project I am working with falls into the
category of NetSaint. The user's first attempt included a circular rule:
:reachable (c? (and (^up) (some 'reachable (neighbors self))))
I started to work on making Cells handle cyclicity, but it got a little
scary and then I realized the rule was a little off: what if my neighbor
is getting to the central node (the "from" implicit in reachable)
through me and only through me? Once this got sorted out (use-case
write-up today, I hope) there was no cyclicity (path matters, and in
this problem there is no reason to revisit the same node twice).
I bring that up only because I imagine similar issues arising with your
application. btw, the NetSaint-alike project is intended to be open
software and the user gave me permission to do the use case based on his
code/spec, but closed/proprietary/comfidential is OK, too.
>
> After having runned the following modified build.lisp
> (load (compile-file #p"C:\\robocells\\asdf-155.lisp"))
> (progn
> (push (make-pathname
> :device "C"
> :directory \\robocells)
> asdf:*central-registry*)
> (asdf :oos 'asdf:load-op :robocells :force t)
> #+force
> (asdf :oos 'asdf:load-op :robocells :force t)
> #+min
> (asdf :oos 'asdf:load-op :robocells :force nil))
> ;^ the
> last bracket is not present in your build.lisp
thx.
>
> Everything compiles but for "Warning: While compilinb these undefined
> functions were referenced: CELLS::WHILE".
> Checking the code I see that while is not compiled for acl so I had to
> change in (defun call-with-dataflow-management ...)
> the following line
> from: (while (and *sw-pending* ...
> to: (aclwin:while (and *sw-pending* ...
wow, I am surprised that is in there; I've known for a while that WHILE
is not portable. Just changed it to a DO.
> Anyway I am off now to see if I get a gain in changing my code to cell-code.
Feel free to pepper me with questions/problems even before digging into
them very deeply. Without any doc to speak of[1], I have to compensate
on support. :)
Also, Cello will be great for this when it comes time to display the
traffic. The original impetus for Cells was highly-dynamic, algorithmic,
interdependent GUI layout. From there it permeated the model semantics.
Speaking of which, I was very happy to get the Family class working very
early on without much difficulty, because that lets the model cope
seamlessly with model instances coming and going. ie, the model
population itself is part of the dataflow. i wager you'll need this to
bring new vehicles into a point of investigation and have them leave.
kenny
[1] In the cells-test subdirectory, several of the source files have a
ton of very detailed doc. The internal combustion engine bit especially
tries to validate all sorts of things and some nasty edge cases, and the
long comments go into detail about what is going on behind the scenes to
make the various tests necessary. One Prime Design Directive is that
Cells be easy to use and that a developer should not have to worry about
internals, but if you like to look under the hood, there ya go.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Rmagere Subject: Re: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <bodba7$5qi$1@news.ox.ac.uk>
Kenny Tilton wrote:
> Cool project. I'm jealous. I have long thought a traffic sim would be
> great fun. I've been known to stand at hairy intersections during rush
> hour to watch the ebb and flow of things. But I also imagine the
> project would be a black hole of complexity, where realistic sim did
> not arise until a tremendous amount of detail was just right.
Well actually I am not planning to build a simulator (though I have
read lots about them and so on), I am more interested in providing
a description of the traffic scene with some behavioural analysis
of the different drivers.
> Food for thought: Another project I am working with falls into the
> category of NetSaint. The user's first attempt included a circular
> rule:
>
> :reachable (c? (and (^up) (some 'reachable (neighbors self))))
>
> I started to work on making Cells handle cyclicity, but it got a
> little scary and then I realized the rule was a little off: what if
> my neighbor is getting to the central node (the "from" implicit in
> reachable) through me and only through me? Once this got sorted out
> (use-case write-up today, I hope) there was no cyclicity (path
> matters, and in this problem there is no reason to revisit the same
> node twice).
>
> I bring that up only because I imagine similar issues arising with
> your application. btw, the NetSaint-alike project is intended to be
> open software and the user gave me permission to do the use case
> based on his code/spec, but closed/proprietary/comfidential is OK,
> too.
And the moment I am avoiding circularity by not allowing users to
think about other users - this is quite a strong limitation but for the
time-being I'll kind of stick to it (as you said it can get hairy fast).
However I'll have a look to NetSaint to see what it does.
> wow, I am surprised that is in there; I've known for a while that
> WHILE is not portable. Just changed it to a DO.
Ah there's the obvious answer.
> Feel free to pepper me with questions/problems even before digging
> into them very deeply. Without any doc to speak of[1], I have to
> compensate on support. :)
Right how about a question from the "Handbook of Silly and Lazy
Questions":
I want to create a model with two cells where one acts as a counter
for the number of times the other cell gets clicked.
I though that something like this would have worked:
(defmodel trial ()
((update :cell :ephemeral :initform (cv nil) :accessor update)
(time-elapsed :cell t :accessor time-elapsed
[1] :initarg (c? (when (^update) (if (^time-elapsed)
[1] (+ 1
(^time-elapsed))
[1]
1))))))
(def-c-echo update ((self trial) new old old-bound-p)
(trc "ECHO update" :new new :old old :oldp old-bound-p))
(def-c-echo time-elapsed ((self trial)
(format t "~&ECHO time-elapsed: ~a seconds" new-value))
however running
(defparameter *tt* (to-be (make-instance 'trial)))
(setf (update *tt*) t)
doesn't seem to work.
I then changed [1] to include setf
(if (^time-elapsed)
(setf (^time-elapsed) (+ 1 (^time-elapsed)))
(setf (^time-elapsed) 1))
However I then get a time-elapsed is unbound error.
Furthermore I haven't understood if it's possible (and if
so how) to set a cell to have an initialization value and then
an update rule rather than one or the other (as that would get
rid of the need for the if statement all together).
Regarding the problem itself I wonder if I actually should be
using the Family class and the Kids.
I haven't actually spent that much time on the problem yet
but I was going to reply to your message anyway so I might
as well stick this is to give a) a chance for me to better understand
or just be told go and study more b) a chance for you to see
where some people might at the very beginning stumble upon
with your package and maybe make a note in your doc to avoid
other failing the same way.
> Also, Cello will be great for this when it comes time to display the
> traffic. The original impetus for Cells was highly-dynamic,
> algorithmic, interdependent GUI layout. From there it permeated the
> model semantics.
Yep, that's what first got me interested as I wasn't quite sure what
spreadsheet programming style meant.
> Speaking of which, I was very happy to get the Family class working
> very early on without much difficulty, because that lets the model
> cope seamlessly with model instances coming and going. ie, the model
> population itself is part of the dataflow. i wager you'll need this to
> bring new vehicles into a point of investigation and have them leave.
Haven't really thought about the Family class yet, though I expect I
would probably use it to hold the neighbouring vehicles.
> [1] In the cells-test subdirectory, several of the source files have a
> ton of very detailed doc. The internal combustion engine bit
> especially tries to validate all sorts of things and some nasty edge
> cases, and the long comments go into detail about what is going on
> behind the scenes to make the various tests necessary. One Prime
> Design Directive is that Cells be easy to use and that a developer
> should not have to worry about internals, but if you like to look
> under the hood, there ya go.
Just as a side note is not really clear which files depend on which in
the cells-test subdirectory as some files call cv-assert, echo-... and
so on that are not defined in the main cells but only within cells-test.
Got all them working by loading everything once (and just for safety
once again) however you might consider making a asdf file for them
too.
By the way when running cv-test I get the error: "Attempt to call
cv-assert which is defined as a macro".
rmagereFrom: Kenny Tilton Subject: Re: Cello [was Re: python libs v lisp coolness?] Date: Message-ID: <Hntqb.42105$Gq.10497391@twister.nyc.rr.com>
Meta-comment: I'll be working today on finishing setting up a couple of
projects on: http://common-lisp.net/
There will be two projects, one for Cells, one for Cello. Assuming all
goes well, the matching SOurceForge projects will be put down.
Meta-comment2: as you opined below, yes, I have to take all these issues
as Messages From God(tm) as to what doc to write or "features" to fix. I
will do so.
Rmagere wrote:
> And the moment I am avoiding circularity by not allowing users to
> think about other users - this is quite a strong limitation but for the
> time-being I'll kind of stick to it (as you said it can get hairy fast).
> However I'll have a look to NetSaint to see what it does.
Well, I am told by my Cells user that the little ring-net-clocked.lisp
example already outdoes NetSaint (now Nagios), so not sure how valuable
that will be to look at. If I ever get around to the use case on this
you'll see that what happened was that I stared at the apparently
circular requirement ("I am reachable if one of my neighbors is
reachable") was a misformulation. When corrected ("I am reachable if one
of my neighbors is reachanble not thru me") the circularity went away.
Hellasweet.
And there is always the WITHOUT-C-DEPENDENCY macro. :) But in RoboCells
I found a lot of temptation to get circular, and better, clearer
formulations always made the circularities go away.
That said, I wager I'll have to knuckle down someday and go circular, I
just want it to be on merit.
> I want to create a model with two cells where one acts as a counter
> for the number of times the other cell gets clicked.
> I though that something like this would have worked:
>
> (defmodel trial ()
> ((update :cell :ephemeral :initform (cv nil) :accessor update)
> (time-elapsed :cell t :accessor time-elapsed
> [1] :initarg (c? (when (^update) (if (^time-elapsed)
> [1] (+ 1
> (^time-elapsed))
> [1]
> 1))))))
Ah, brave try (but you meant ":initform (c?....)", yes?
I ended up creating a special type of Cell for that case. (This is cool,
all the Cells newbies are immediately jumping to the trickiest
applications, the stuff I thought could wait till Chapter 9.) I call
them "drifters": you can initialize them to something, and then the rule
is understood to be a delta. Changing the name a little
(update-count :accessor update-count :initarg :update-count
:initform (c... (0) (when (^update) 1)))
The ellipsis is meant to be a mnemonic for something drifting. :)
btw, back in your nice try, a rule can refer to its current value via
the symbol-macro ".CACHE". revisited below,
aside: since c? expands into a lambda form, one could also do:
(let ((count 0))
(c? (setf count (incf count (if (^update) 1 0)))))
i have to run out, but i need to check the source: I /think/ I allow
user code to randomly reset a drifter-mediated slot, after which the
rule resumes drifting the value. This would be different than a vanilla
C?, where internals shoot down user SETF's.
>
> (def-c-echo update ((self trial) new old old-bound-p)
> (trc "ECHO update" :new new :old old :oldp old-bound-p))
> (def-c-echo time-elapsed ((self trial)
> (format t "~&ECHO time-elapsed: ~a seconds" new-value))
Just checking: yer just experimenting here and not being rigorous with
names? I ask because the code looks like it is counting updates, not time.
>
> however running
> (defparameter *tt* (to-be (make-instance 'trial)))
> (setf (update *tt*) t)
> doesn't seem to work.
I am starting to think the :initarg/:initform typo was in the code, I am
pretty sure cell internals would shoot down time-elapsed being dependent
on itself.
>
> I then changed [1] to include setf
> (if (^time-elapsed)
> (setf (^time-elapsed) (+ 1 (^time-elapsed)))
> (setf (^time-elapsed) 1))
> However I then get a time-elapsed is unbound error.
OK, if you left off the :initform arg inadvertently typing :initarg,
that would leave time-elapsed unbound. Not sure who is reading the slot,
but I think we have enough issues it is worth sorting them out and
trying with a drifter or the other trick I showed.
btw, sometimes I /do/ like to refer to the current value of a slot
within a rule, and for that you can use the symbol-macro ".CACHE". SO we
could also do:
(update-count :initform (c? (if (^update)
(if .cache (1+ .cache) 1)
0)))
>
> Furthermore I haven't understood if it's possible (and if
> so how) to set a cell to have an initialization value and then
> an update rule rather than one or the other (as that would get
> rid of the need for the if statement all together).
<g> Great minds think alike? That's the spec for drifters. And you are
right, you could just do:
(c... (0) (let ((upd (^update))
(declare (ignore update))
1))
But in real rules there are other dependencies which might get touched
in deciding the delta value to be applied. When they change the drifter
rule gets kicked off. So /then/ you better be testing for the (^update)
not being nil. In general, it is probably a bad idea to let your
understanding of Cells internals stop one from writing more natural code
(as in "when an update event happens, count it").
>
> Regarding the problem itself I wonder if I actually should be
> using the Family class and the Kids.
I don't think that applies here.
>
> I haven't actually spent that much time on the problem yet
> but I was going to reply to your message anyway so I might
> as well stick this is to give a) a chance for me to better understand
> or just be told go and study more b) a chance for you to see
> where some people might at the very beginning stumble upon
> with your package and maybe make a note in your doc to avoid
> other failing the same way.
Absolutely.
>
>
>>Also, Cello will be great for this when it comes time to display the
>>traffic. The original impetus for Cells was highly-dynamic,
>>algorithmic, interdependent GUI layout. From there it permeated the
>>model semantics.
>
>
> Yep, that's what first got me interested as I wasn't quite sure what
> spreadsheet programming style meant.
<g> It is such a different paradigm /for programming/ that I think the
only way to get it is to try it. Then it turns out simple, but until
then it is just to big a conceptual leap. It actually took me many
months before I stopped falling back inro an imperative, procedural
paradigm when tackling big new sections of functionality. But then I
would get this sickening feeling and realize, oh!, I'm backsliding!
>
>
>>Speaking of which, I was very happy to get the Family class working
>>very early on without much difficulty, because that lets the model
>>cope seamlessly with model instances coming and going. ie, the model
>>population itself is part of the dataflow. i wager you'll need this to
>>bring new vehicles into a point of investigation and have them leave.
>
>
> Haven't really thought about the Family class yet, though I expect I
> would probably use it to hold the neighbouring vehicles.
You'll create a world instance with everything in it as a child,
including vehicles, pedestrians, traffic lights. I suppose you could
have different levels: first level: road-system, traffic-control-system,
pedestrian-population, vehicle-population. etc etc
>
>
>>[1] In the cells-test subdirectory, several of the source files have a
>>ton of very detailed doc. The internal combustion engine bit
>>especially tries to validate all sorts of things and some nasty edge
>>cases, and the long comments go into detail about what is going on
>>behind the scenes to make the various tests necessary. One Prime
>>Design Directive is that Cells be easy to use and that a developer
>>should not have to worry about internals, but if you like to look
>>under the hood, there ya go.
>
>
> Just as a side note is not really clear which files depend on which in
> the cells-test subdirectory as some files call cv-assert, echo-... and
> so on that are not defined in the main cells but only within cells-test.
> Got all them working by loading everything once (and just for safety
> once again) however you might consider making a asdf file for them
> too.
> By the way when running cv-test I get the error: "Attempt to call
> cv-assert which is defined as a macro".
<g> I was horrified to learn I had left the ASDF file out of the latest
distro. I'll get that sorted out today. A couple of folks have set Cells
up for ASDF-INSTALL, fwiw.
I'm gonna grab some coffee and get to work on the common-lisp.net
projects. Thanks for your patience.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Marc Battyani Subject: Re: python libs v lisp coolness? Date: Message-ID: <bnrj4t$42s@library1.airnews.net>
"Kenny Tilton" <·······@nyc.rr.com> wrote
>
> Am I the exception because I have Cells? I do not think so. I think if
> someone using a Better Language such as CL sat down to do a GUI from
> scratch, it would always turn out more powerful than GTk, by as great a
> margin/factor as CL itself excels over C. There are sad cases out there
> of people still clinging to the lifeless body of Garnet, unable to let
> go (of course that has KR, prior art for Cells).
>
> There is something about the language.
>
> As for the marketing thing ("You can still use GTk!"), that's just lame.
> CLers need to burst out laughing when someone asks if there are GTk
> bindings, then say "Wait till you see Cello, the CL Gui."
>
> :)
I also think that pure CL libraries can be much better than C bindings.
As an example the C pdf library PDFlib lite has 43271 lines in the .c and .h
files of pdfcore and pdflib directories.
cl-pdf has 2587 lines in the .lisp files and does essentially the same thing.
Ok maybe PDFlib lite has a few more functions but I can't imagine that they
could not be done in a few lines of Common Lisp.
To go back to the GUI, I once wrote a Win+Mac cross platform GUI with all the
widgets drawn "by hand". The look and feel was exactly the same as the native
UI and it was much faster. I also could have Mac L&F on Windows for instance.
So go Kenny, I'm with you!
BTW I remind everybody that I'm still looking for cl-pdf and -cl-typesetting
contributors... ;-)
MarcFrom: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <kBSnb.17156$Gq.5362505@twister.nyc.rr.com>
Mario S. Mommer wrote: > Kenny Tilton <·······@nyc.rr.com> writes: > >>IIUC, when Pythonistas brag about their libs they are talking mainly >>about C libs made available via the Python FFI. This works better in >>Python because there is only one Python, so any FFI grunt-work is >>hugely rewarded/beneficial. > > > Yeah, but then they have only one implementation. Super, but irrelevant in the narrow context of getting ourselves some libraries. I just meant we have a disadvantage specifically in re getting libraries built. The very simple point is that when one open (as in source) minded Pythonista has a library, they all do. Not so with CL. A corrollary is that a Pythonista contemplates the effort required to create a library, they quickly realize, "Then I can I can be famous in my community and advance the cause!". Not so with CL. My current project (evangelizing Lisp by cultivating a Lisp+music cabal in NYC) has exposed me to a current, active CL project which stands on its head to be portable. You wanna see some (#+and #+excl (#+not (#+or #+acl61...........) nairy code? :) Kevin Rosenberg made a huge contrib with UFFI, to the extent that big huge C libraries at CL's fingertips address the library question. OpenGL, ImageMagick, CSound, etc. UFFI (or a clone of that or a fork) needs to be expanded to deliver on the promise of that "U". > > >>Me, I have on my plate plans to do the FFI work for ImageMagick. I >>have FFI for openGL and FreeGlut, was not too painful. Macros helped. > > > Do you have them on the 'net? RSN, because I am starting work again soon on a portable CL GUI. I punted on stuff that resisted, but a lot of OpenGL is available (and I forget what made me punt, so not sure how hard it would be to finish. I was in proof-of-concept mode, so I grabbed the low-lying fruit (quite a bit) and got on with the main project.) > > >>Corman and ACL (I hear) have stuff to automate some of the work, tho >>of course to their own FFIs. > > > <plug> I've been doing some bindings for GTK (see > http://common-lisp.net/project/lgtk/) </plug> Excellent! Burdick keeps telling me to use GTK for the backend to my Common Lisp GUI. I will check that out next. Need help with that? I volunteer Thomas. and found that to do > really usefull bindings you need at least to look at the functions, > and think on how to interface with the lib. I don't think you can do > that last bit automagically. Right. eg, Some OGL calls allocate and return a resource, specifically something known as a "display list". Ya gotta know to free those bad boys when done with them up or OGL runs out. Fortunately there is not much of that in OpenGL. > > >>Lisp is now in the phase of Getting Noticed. This we can assume will >>lead to folks Getting Excited and wanting to Actually Use it. To do >>so, they will have to UFFI up some bindings to Various Libraries. > > > Yes, but having a bunch of C prototypes to be called from Lisp > probably won't make you happy. You want garbage-collection support. If > a function returns twice the same pointer, you want to get the same > object each time. You probably also want to be able to use whatever > you want as a callback - not only functions defined with defcallback > or whatever. You want the thing to be lisp-friendly: errors should not > mess up your image. This is a bit of work, but is essential IMHO. Sh*t, this community won't get off its ass to grind out bindings to something like ImageMagick, do you think they are going to write it in CL from scratch? We have a chicken-egg situation here, needing libraries to get newbies and live newbies (not the walking dead we have on cll) to get libraries. Fortunately the newbies will be comfortable with C so their pain interfacing to a C lib will be less than ours. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Thomas F. Burdick Subject: Re: python libs v lisp coolness? Date: Message-ID: <xcv65i8c4py.fsf@famine.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:
> Mario S. Mommer wrote:
>
> > Yes, but having a bunch of C prototypes to be called from Lisp
> > probably won't make you happy. You want garbage-collection support. If
> > a function returns twice the same pointer, you want to get the same
> > object each time. You probably also want to be able to use whatever
> > you want as a callback - not only functions defined with defcallback
> > or whatever. You want the thing to be lisp-friendly: errors should not
> > mess up your image. This is a bit of work, but is essential IMHO.
>
> Sh*t, this community won't get off its ass to grind out bindings to
> something like ImageMagick, do you think they are going to write it in
> CL from scratch?
I'd think that would be more appealing to CL'ers. It's frustrating
trying to do the hard work of making CL work with the crufty parts of
the C/Unix world. Working *within* CL, however, is fun. We're mostly
spoiled.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----' From: Christophe Rhodes Subject: Re: python libs v lisp coolness? Date: Message-ID: <sqznfkq6j9.fsf@lambda.jcn.srcf.net>
Kenny Tilton <·······@nyc.rr.com> writes: > My current project (evangelizing Lisp by cultivating a Lisp+music > cabal in NYC) has exposed me to a current, active CL project which > stands on its head to be portable. You wanna see some (#+and #+excl > (#+not (#+or #+acl61...........) nairy code? :) If I want mk-defsystem, I know where to find it. ;-) (I did a very small amount of work on and with Common Music Notation a long while ago, and your little excerpt there brings back some memories...). > Sh*t, this community won't get off its ass to grind out bindings to > something like ImageMagick, do you think they are going to write it in > CL from scratch? > > We have a chicken-egg situation here, needing libraries to get newbies > and live newbies (not the walking dead we have on cll) to get > libraries. To a certain extent I think I object to this categorization and the implication about the necessity of a constant flux of willing and eager workers. On the other hand, I agree that a certain amount of fresh insight is necessary from time to time, and also that it could make my life easier if other people(tm) would take it upon themselves to write high-quality ultraportable libraries. On the other hand, in this kind of situation, you have to consider how to make breaking the vicious circle of chicken-and-egg palatable for the individuals involved; appeals to "community" will get you some of the way, but not all. I would advise against obsessing massively about portability in the first instance. If you happen to need bindings to ImageMagick, then don't contort yourself unnecessarily such that version 1.0 works on all lisps on all platforms (particularly if such includes a 64bit-alike platform, which I believe still causes problems for UFFI); I think I'm probably in agreement with Kenny when I say "just do it" (for your needs), make its doing known, and let others pitch in: you can even market it as somewhat of a master/apprentice relationship. :) Hmm. That sounds a little free-marketish for a college student working on free software; I apologise :-) Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Marc Battyani Subject: Re: python libs v lisp coolness? Date: Message-ID: <bnov43$79c@library1.airnews.net>
"Kenny Tilton" <·······@nyc.rr.com> wrote > Mario S. Mommer wrote: > > > > <plug> I've been doing some bindings for GTK (see > > http://common-lisp.net/project/lgtk/) </plug> > > Excellent! Burdick keeps telling me to use GTK for the backend to my > Common Lisp GUI. I will check that out next. Need help with that? I > volunteer Thomas. Don't do that! He should be writing user friendly syntaxes (with the associated emacs modes) for cl-typesetting! > We have a chicken-egg situation here, needing libraries to get newbies > and live newbies (not the walking dead we have on cll) to get libraries. Yep, they should all be writing libraries. The good news for them is that it's in Common Lisp. BTW it's not only for the newbies ;-) > Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Cool! Marc
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <goUnb.17354$Gq.5386103@twister.nyc.rr.com>
Marc Battyani wrote: > "Kenny Tilton" <·······@nyc.rr.com> wrote > >>Mario S. Mommer wrote: >> >>><plug> I've been doing some bindings for GTK (see >>>http://common-lisp.net/project/lgtk/) </plug> >> >>Excellent! Burdick keeps telling me to use GTK for the backend to my >>Common Lisp GUI. I will check that out next. Need help with that? I >>volunteer Thomas. > > > Don't do that! He should be writing user friendly syntaxes (with the > associated emacs modes) for cl-typesetting! This is sad, library-builders fighting over the few (one?) CLer(s) prepared to write code instead of feed Mike420's bonfires. Well, at least the ball seems to be rolling. Apress should expedite the production on Peter's book, there's gold in them thar bookstores. >>Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film > > > Cool! Is it just me, or is that great reading or what? Only one or two are pure rah-rah, the rest really say something about Lisp. So...is your Road in the works? :) -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Thomas F. Burdick Subject: Re: python libs v lisp coolness? Date: Message-ID: <xcvu15rbjyb.fsf@famine.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:
> This is sad, library-builders fighting over the few (one?) CLer(s)
> prepared to write code instead of feed Mike
??? Have you not looked at, say, <http://www.cliki.net/asdf-install>?
These are all libraries that I can install simply by typing
(asdf-install:install 'foo) [and then fixing the lack-of-symlink
breakage on OS X, but that's neither here nor there].
> 420's bonfires.
Out-of-context, that sounds a lot more interesting than it really is
:-P
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----' From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <uc%nb.18085$Gq.5720173@twister.nyc.rr.com>
Thomas F. Burdick wrote: > Kenny Tilton <·······@nyc.rr.com> writes: > > >>This is sad, library-builders fighting over the few (one?) CLer(s) >>prepared to write code instead of feed Mike > > > ??? Have you not looked at, say, <http://www.cliki.net/asdf-install>? Now I have. reversi? puh-leeze. split-sequence? you call that a library? two defystems? those aren't libraries, they /build/ libraries. and what is that cells crap? Tell you what. Go bragging about that list on c.l.python. If you come back alive, I'll take it all back. :) kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Daniel Barlow Subject: Re: python libs v lisp coolness? Date: Message-ID: <871xsvfl9j.fsf@noetbook.telent.net>
Kenny Tilton <·······@nyc.rr.com> writes: > split-sequence? you call that a library? You would too, if you knew how fucking long it took how many people to write. Admittedly, most of that was arguing about the name. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=sqofr3wnkg.fsf%40lambda.jesus.cam.ac.uk&rnum=1&prev=/groups%3Fselm%3Dsqofr3wnkg.fsf%2540lambda.jesus.cam.ac.uk for anyone whose scars don't still itch. -dan -- http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <JN0ob.18444$Gq.5823992@twister.nyc.rr.com>
Daniel Barlow wrote: > Kenny Tilton <·······@nyc.rr.com> writes: > > >>split-sequence? you call that a library? > > > You would too, if you knew how fucking long it took how many people to > write. Admittedly, most of that was arguing about the name. Don't remind me. It is one of my favorite stories about c.l.l. People who haven't contributed a line of code to the community and who had no intention ever of using the frickin library cut vacations short to get home and attack the contributor over the /name/ of the library. "most of that"? I do not recall one article that was about functionality. I don't know. Maybe I'm wrong. If Lisp is such a great language and people love it so much, how come they don't write any code? kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Ingvar Mattsson Subject: Re: python libs v lisp coolness? Date: Message-ID: <87znfjyrgo.fsf@gruk.tech.ensign.ftech.net>
Kenny Tilton <·······@nyc.rr.com> writes: > Daniel Barlow wrote: > > > Kenny Tilton <·······@nyc.rr.com> writes: > > > >> split-sequence? you call that a library? > > You would too, if you knew how fucking long it took how many people > > to > > write. Admittedly, most of that was arguing about the name. > > Don't remind me. It is one of my favorite stories about c.l.l. People > who haven't contributed a line of code to the community and who had no > intention ever of using the frickin library cut vacations short to get > home and attack the contributor over the /name/ of the library. > > "most of that"? I do not recall one article that was about functionality. There were discussions on "one separator or multiple separators?" and "separators in a string or in a list" and a few others. > I don't know. Maybe I'm wrong. If Lisp is such a great language and > people love it so much, how come they don't write any code? In my case, because at the moment I cannot stomach touching a keyboard outside work, so I do woodworking and build arcade controllers (or sleep) at home, where most of my code writing normally happens. //Ingvar -- When in doubt, debug-on-entry the function you least suspect have anything to do with something.
From: mikel Subject: Re: python libs v lisp coolness? Date: Message-ID: <o3aob.579$0a6.7@newssvr14.news.prodigy.com>
Kenny Tilton wrote: > > > Daniel Barlow wrote: > >> Kenny Tilton <·······@nyc.rr.com> writes: >> >> >>> split-sequence? you call that a library? >> >> >> >> You would too, if you knew how fucking long it took how many people to >> write. Admittedly, most of that was arguing about the name. > > > Don't remind me. It is one of my favorite stories about c.l.l. People > who haven't contributed a line of code to the community and who had no > intention ever of using the frickin library cut vacations short to get > home and attack the contributor over the /name/ of the library. > > "most of that"? I do not recall one article that was about functionality. > > I don't know. Maybe I'm wrong. If Lisp is such a great language and > people love it so much, how come they don't write any code? Maybe because people write code wanting it to be used, and half the time the lisp community is like an I'm-smarter-than-you club with everyone explaining why this or that new piece of code should never be used?
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <haaob.21307$Gq.6223091@twister.nyc.rr.com>
mikel wrote: > Kenny Tilton wrote: >> I don't know. Maybe I'm wrong. If Lisp is such a great language and >> people love it so much, how come they don't write any code? > > > Maybe because people write code wanting it to be used, and half the time > the lisp community is like an I'm-smarter-than-you club with everyone > explaining why this or that new piece of code should never be used? So it's a vicious cycle? They'd all be writing code if they weren't all just sitting around pissing on anyone Actually Working? We had this great game riding our Flexible Flyers back when the Northeast had snow in winter. Six of us would line up at the top of the hill with our sleds at the ready, eyeing each other like a shoot-out. Then one idiot would suddenly take off down the hill, and the other five would tear after them. Someone was bound to end up on better ice, catch the rabbit and flip them by yanking the tail of a runner. Deja vu all over again; I liked being the idiot. Mario, tell me again why I should give up on Cello and use a C library? :) The Savages of C.L.L. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <tTaob.21595$Gq.6263235@twister.nyc.rr.com>
Kenny Tilton wrote: > > Deja vu all over again; I liked being the idiot. Mario, tell me again > why I should give up on Cello and use a C library? :) > Oops. That should be Henrik, not Mario. Smiley either way. Hey, I am looking at GTk again. I passed on it before because of no Mac support, but OS X changes that, yes? I won't be doing GTk, but using GDT, Pango, etc in my own framework. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: mikel Subject: Re: python libs v lisp coolness? Date: Message-ID: <U%aob.18966$Jz.3657@newssvr29.news.prodigy.com>
Kenny Tilton wrote: > > > Kenny Tilton wrote: > >> >> Deja vu all over again; I liked being the idiot. Mario, tell me again >> why I should give up on Cello and use a C library? :) >> > > Oops. That should be Henrik, not Mario. Smiley either way. > > Hey, I am looking at GTk again. I passed on it before because of no Mac > support, but OS X changes that, yes? Yes. Plain vanilla GTk+ works with Apple's X11 (a tweaked version of XFree86 that is now distributed with the OS). There are also two projects devoted to making native-Aqua implementations of GTk+: http://gtk-osx.sourceforge.net http://gtk-quartz.sourceforge.net
From: Henrik Motakef Subject: Re: python libs v lisp coolness? Date: Message-ID: <86wuamzn1m.fsf@pokey.internal.henrik-motakef.de>
Kenny Tilton <·······@nyc.rr.com> writes: > Kenny Tilton wrote: > > > Deja vu all over again; I liked being the idiot. Mario, tell me > > again why I should give up on Cello and use a C library? :) > > > > Oops. That should be Henrik, not Mario. Smiley either way. Oh, but I certainly didn't mean to discourage you from writing Cello. I just don't think that stopping any other effort while waiting on Cello becoming the one perfect GUI for all uses would be a good idea. The problem of having to choose whether Cello, McCLIM or one of many bindings to preexisting libraries would be best for a Lisp GUI app is not one I'm going to complain about :-)
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <6Tcob.22598$Gq.6343613@twister.nyc.rr.com>
Henrik Motakef wrote: > Kenny Tilton <·······@nyc.rr.com> writes: > > >>Kenny Tilton wrote: >> >> >>>Deja vu all over again; I liked being the idiot. Mario, tell me >>>again why I should give up on Cello and use a C library? :) >>> >> >>Oops. That should be Henrik, not Mario. Smiley either way. > > > Oh, but I certainly didn't mean to discourage you from writing > Cello. I just don't think that stopping any other effort while waiting > on Cello becoming the one perfect GUI for all uses would be a good > idea. Lord, no. There is a good chance I'll blow the whole thing off. I can go cross-platform for my next commercial enterprise by building a Cell-based gui on top of LW+CAPI. Neatly abstracted it could port to ACL or MCL or XLib. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Marc Battyani Subject: Re: python libs v lisp coolness? Date: Message-ID: <bnrj5m$v87@library1.airnews.net>
"Kenny Tilton" <·······@nyc.rr.com> wrote > I don't know. Maybe I'm wrong. If Lisp is such a great language and > people love it so much, how come they don't write any code? Good question. I'm still trying to understand why so many ones prefer to spend more time reading and writing posts about libraries than writing them. (this one included ;-) It's like the discussions about libraries licenses by people who have not written one... Marc
From: ·············@comcast.net Subject: Re: python libs v lisp coolness? Date: Message-ID: <he1qryba.fsf@comcast.net>
Kenny Tilton <·······@nyc.rr.com> writes: > I don't know. Maybe I'm wrong. If Lisp is such a great language and > people love it so much, how come they don't write any code? Between python bashing and attempting pull static typer's heads out of their asses, who has the time?
From: Kenny Tilton Subject: Re: python libs v lisp coolness? Date: Message-ID: <y1kob.24493$Gq.6688022@twister.nyc.rr.com>
·············@comcast.net wrote: > Kenny Tilton <·······@nyc.rr.com> writes: > > >>I don't know. Maybe I'm wrong. If Lisp is such a great language and >>people love it so much, how come they don't write any code? > > > Between python bashing and attempting pull static typer's heads out > of their asses, who has the time? And to think Lispniks are accused of being elitist, when in fact we are sacrificing valuable library-writing time to save our static typing brethren from Hell and make sure Pythonistas get to enjoy macros as much as we do. Someone should pin a medal on us. But maybe Marc hit on it when he mentioned how little code it had taken him to roll Quark XPress from scratch: libraries? Lispniks don't need no stinkin' libraries! A couple lines of code and, Presto!, library! kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application
From: Raymond Wiker Subject: Re: python libs v lisp coolness? Date: Message-ID: <861xst22pc.fsf@raw.grenland.fast.no>
Kenny Tilton <·······@nyc.rr.com> writes:
> But maybe Marc hit on it when he mentioned how little code it had
> taken him to roll Quark XPress from scratch: libraries? Lispniks don't
> need no stinkin' libraries! A couple lines of code and, Presto!,
> library!
This is actually a point... I wrote some HTTP client code for
fetching HTML content from a web server. It weighs in at 215 lines,
but that includes
- parsing of the url
- fetching the web page using either "chunked" encoding, or
HTTP/1.0 style Content-Length
- a small state machine for stripping away all the markup
Writing this from scratch took less time (and was more fun)
than even *locating* an existing library, not to mention actually
learning the API :-)
Soooo, I suggest that one of the major weaknesses with Common
Lisp is that it is so easy, fun and fast to write code in that the
incentive to go look for existing library is minimised.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/From: Espen Vestre Subject: Re: python libs v lisp coolness? Date: Message-ID: <kwn0bh9393.fsf@merced.netfonds.no>
Raymond Wiker <·············@fast.no> writes: > Soooo, I suggest that one of the major weaknesses with Common > Lisp is that it is so easy, fun and fast to write code in that the > incentive to go look for existing library is minimised. Good point! But there are of course limits to this. E.g. _I_ thought it was fun to write my own RSA-key-generator but I don't think hackers who are less fascinated by prime numbers etc. would agree. -- (espen)
From: Paolo Amoroso Subject: Re: python libs v lisp coolness? Date: Message-ID: <87ekwxe413.fsf@plato.moon.paoloamoroso.it>
Tom Lord writes: > So, if Python has all these great libraries and Common Lisp needs > analogs of them, why isn't the right approach to write a translator? The lack of Lisp libraries is being addressed. Paolo -- Why Lisp?... http://alu.cliki.net/RtL%20Highlight%20Film
From: Ville Vainio Subject: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <du765i810a1.fsf_-_@mozart.cc.tut.fi>
Paolo Amoroso <·······@mclink.it> writes:
> The lack of Lisp libraries is being addressed.
Are they also going to address the lack of modules? The way I've seen
Lisp used, everything is dumped into a global namespace (even
"methods" in CLOS). I shudder at the thought of using Python where all
the names from various modules would be in the global namespace.
in Python you can do:
import os
files = os.listdir("/root")
--
Ville Vainio http://www.students.tut.fi/~vainio24From: Jon S. Anthony Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <m365i7x3d4.fsf@rigel.goldenthreadtech.com>
Ville Vainio <······················@spamtut.fi> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > The lack of Lisp libraries is being addressed.
>
> Are they also going to address the lack of modules? The way I've seen
> Lisp used, everything is dumped into a global namespace (even
> "methods" in CLOS). I shudder at the thought of using Python where all
> the names from various modules would be in the global namespace.
There's a difference between modules and name spaces, though modules
in many languages also serve as name spaces. The issue you are
talking about here really is a name space issue and Common Lisp has
had control over that from the start. Its construct is the _package_.
> in Python you can do:
>
> import os
>
> files = os.listdir("/root")
In Common Lisp this is basically the same. The symbols from OS that
should be public are _exported_. You then can access them, for
example, as:
(os:listdir "/root")
You can also _use_ a package if you are in another so that the
_exported_ symbols become visible w/o qualification.
(use-package :os)
...
(listdir "/root")
There are a lot of other things for controlling visibility of this
sort. For example, you can _import_ only specific symbols or you can
_shadow_ others, etc.
/JonFrom: Harald Hanche-Olsen Subject: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <pco7k2ndcpw.fsf_-_@thoth.math.ntnu.no>
+ ·········@rcn.com (Jon S. Anthony): | There's a difference between modules and name spaces, though modules | in many languages also serve as name spaces. I have heard this one before, but have never quite understood the difference. I am quite familiar with Lisp's packages and python's modules, and sure enough they are quite different, but I lack a clear conceptual distinction between modules and name spaces. (I think it was even mentioned during an earlier discussion on c.l.lisp that it may be useful to have both available in the same language.) So, can anyone either explain the difference, or point to a resource (preferably on the web) that explains it? -- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - Debating gives most of us much more psychological satisfaction than thinking does: but it deprives us of whatever chance there is of getting closer to the truth. -- C.P. Snow
From: Erann Gat Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <gat-2910031409320001@k-137-79-50-101.jpl.nasa.gov>
In article <··················@thoth.math.ntnu.no>, Harald Hanche-Olsen <······@math.ntnu.no> wrote: > + ·········@rcn.com (Jon S. Anthony): > > | There's a difference between modules and name spaces, though modules > | in many languages also serve as name spaces. > > I have heard this one before, but have never quite understood the > difference. I am quite familiar with Lisp's packages and python's > modules, and sure enough they are quite different, but I lack a clear > conceptual distinction between modules and name spaces. (I think it > was even mentioned during an earlier discussion on c.l.lisp that it > may be useful to have both available in the same language.) > > So, can anyone either explain the difference, or point to a resource > (preferably on the web) that explains it? Packages map strings onto symbols (identifier objects). Modules map symbols/identifiers onto values. Packages work at read/parse time. Modules work at compile time or run time depending on the module system. Common Lisp has a package system but no module system (but it's possible to add one -- see e.g. http://www.flownet.com/gat/locales.pdf). Python has a module system that works at run-time, but no package system. Does that help? E.
From: Harald Hanche-Olsen Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <pcoism6flxx.fsf@thoth.math.ntnu.no>
+ ···@jpl.nasa.gov (Erann Gat): | In article <··················@thoth.math.ntnu.no>, Harald Hanche-Olsen | <······@math.ntnu.no> wrote: | | > + ·········@rcn.com (Jon S. Anthony): | > | > | There's a difference between modules and name spaces, though modules | > | in many languages also serve as name spaces. | > [...] | > So, can anyone either explain the difference, or point to a resource | > (preferably on the web) that explains it? | | Packages map strings onto symbols (identifier objects). Agreed. | Modules map symbols/identifiers onto values. Okay. | Packages work at read/parse time. Yep. | Modules work at compile time or run time depending on the module system. | | Common Lisp has a package system but no module system (but it's possible | to add one -- see e.g. http://www.flownet.com/gat/locales.pdf). Ah. I had read that one before, but never realized that it describes a module system. That gives me some idea what it's all about. Thanks. | Python has a module system that works at run-time, but no package system. | | Does that help? Now I am getting a bit confused once more, since python doesn't have symbols, and so the distinction between modules and packages gets blurred (in my mind at least): A python modules maps strings directly to values without symbols ever entering the discussion. But the read-time vs run-time (or compile-time) distinction makes more sense to me. If a python function references foo.bar then by changing the value of foo I can make the function refer to a different foo.bar, but if a Common Lisp function references foo:bar, then messing around with the FOO package is never going to change the meaning of that reference. I guess what I am saying is that, while packages without symbols don't make sense, modules don't require them. But then, neither did you say they do, now that I read what you said over again. -- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - Debating gives most of us much more psychological satisfaction than thinking does: but it deprives us of whatever chance there is of getting closer to the truth. -- C.P. Snow
From: Erann Gat Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <gat-3010031425150001@k-137-79-50-101.jpl.nasa.gov>
In article <···············@thoth.math.ntnu.no>, Harald Hanche-Olsen <······@math.ntnu.no> wrote: > | Modules work at compile time or run time depending on the module system. > | > | Common Lisp has a package system but no module system (but it's possible > | to add one -- see e.g. http://www.flownet.com/gat/locales.pdf). > > Ah. I had read that one before, but never realized that it describes > a module system. That gives me some idea what it's all about. > Thanks. I really should have called them modules, not locales. (Maybe I'll change the name in the next version.) Locale nowadays has to do with internationalization. But I chose the name out of respect for the original design in T. > | Python has a module system that works at run-time, but no package system. > | > | Does that help? > > Now I am getting a bit confused once more, since python doesn't have > symbols, and so the distinction between modules and packages gets > blurred (in my mind at least): A python modules maps strings directly > to values without symbols ever entering the discussion. That's right. That's why I wrote: > Modules map symbols/identifiers onto values. instead of just "modules map symbols onto values." Lisp uses symbols (and sometimes other things as well) as identifiers. Python uses strings. > I guess what I am saying is that, while packages without symbols don't > make sense, modules don't require them. But then, neither did you > say they do, now that I read what you said over again. That's mostly right. At some point you run into the problem of defining what a symbol is. In some contexts "symbol" means nothing more than "uniquified string", in which case Python strings are really symbols: >>> "foo" is "foo" 1 In Common Lisp symbols have extra stuff attached to them, and the term "keyword" is sometimes used to refer to a uniqified string without that extra stuff. But this usage is far from universal. E.
From: Alexander Schmolck Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <yfsznfigyc4.fsf@black132.ex.ac.uk>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> Now I am getting a bit confused once more, since python doesn't have
> symbols,
>>> intern("symbol") is intern("symbol")
True
'asFrom: Henrik Motakef Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <86oevyz921.fsf@pokey.internal.henrik-motakef.de>
Harald Hanche-Olsen <······@math.ntnu.no> writes: > But the read-time vs run-time (or compile-time) distinction makes more > sense to me. If a python function references foo.bar then by changing > the value of foo I can make the function refer to a different foo.bar, > but if a Common Lisp function references foo:bar, then messing around > with the FOO package is never going to change the meaning of that > reference. Well, not quite. It will still use the same /symbol/ foo:bar, but its SYMBOL-FUNCTION may change, of course. * (defpackage :p1 (:use :cl)) #<PACKAGE "P1"> * (defpackage :p2 (:use :cl)) #<PACKAGE "P2"> * (in-package :p1) #<PACKAGE "P1"> * (defun foo () :first-definition) FOO * (in-package :p2) #<PACKAGE "P2"> * (defun bar () (p1::foo)) BAR * (bar) :FIRST-DEFINITION * (defun p1::foo () :second-definition) STYLE-WARNING: redefining P1::FOO in DEFUN FOO * (bar) :SECOND-DEFINITION
From: Henrik Motakef Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <86k76mz8ou.fsf@pokey.internal.henrik-motakef.de>
Henrik Motakef <············@henrik-motakef.de> writes: > Harald Hanche-Olsen <······@math.ntnu.no> writes: > > > But the read-time vs run-time (or compile-time) distinction makes more > > sense to me. If a python function references foo.bar then by changing > > the value of foo I can make the function refer to a different foo.bar, [...] > Well, not quite. It will still use the same /symbol/ foo:bar, but its > SYMBOL-FUNCTION may change, of course. Rereading your paragraph, it should be noted that changing the /package name/ of any referenced packages afterwards (which is closer to changing the value of "foo", i.e. having foo refer to another module) indeed won't affect users. I.e., after the previous example: * (defpackage p3 (:use :cl)) #<PACKAGE "P3"> * (defun p3::foo () :something-completely-different) P3::FOO * (rename-package :p1 :p-old) #<PACKAGE "P-OLD"> * (rename-package :p3 :p1) #<PACKAGE "P1"> * (bar) :THIRD-DEFINITION
From: Pascal Costanza Subject: Re: Modules vs name spaces (Was: Global namespace) Date: Message-ID: <bnpfe2$sr2$3@newsreader2.netcologne.de>
Harald Hanche-Olsen wrote: > + ·········@rcn.com (Jon S. Anthony): > > | There's a difference between modules and name spaces, though modules > | in many languages also serve as name spaces. > > I have heard this one before, but have never quite understood the > difference. I am quite familiar with Lisp's packages and python's > modules, and sure enough they are quite different, but I lack a clear > conceptual distinction between modules and name spaces. (I think it > was even mentioned during an earlier discussion on c.l.lisp that it > may be useful to have both available in the same language.) > > So, can anyone either explain the difference, or point to a resource > (preferably on the web) that explains it? http://www.flownet.com/gat/packages.pdf and http://www.flownet.com/gat/locales.pdf are excellent papers IMHO. Pascal
From: Christophe Rhodes Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <sq4qxsrot5.fsf@lambda.jcn.srcf.net>
Ville Vainio <······················@spamtut.fi> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> The lack of Lisp libraries is being addressed.
>
> Are they also going to address the lack of modules? The way I've seen
> Lisp used, everything is dumped into a global namespace (even
> "methods" in CLOS). I shudder at the thought of using Python where all
> the names from various modules would be in the global namespace.
>
> in Python you can do:
>
> import os
>
> files = os.listdir("/root")
Knowing no python, I believe the Common Lisp equivalent of this is
(cl:defpackage "MY-APP" (:use "CL"))
(cl:in-package "MY-APP")
(os:listdir "/root")
Optionally, if one wishes to import an interface wholesale and use it
without qualification, one may USE-PACKAGE a package, for example:
(cl:defpackage ("MY-OTHER-APP") (:use "CL" "OS"))
(cl:in-package "MY-OTHER-APP")
(listdir "/root")
[ this is written for maximum paranoia; usually you wouldn't see the
cl: prefixes on defpackage and in-package. ]
Ancient code is typically less careful about stomping over the global
namespace; if you see (in-package "CL-USER") anywhere, reeducate the
maintainer of the code :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)From: Ville Vainio Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <du77k2nn8g6.fsf@mozart.cc.tut.fi>
Christophe Rhodes <·····@cam.ac.uk> writes: > Knowing no python, I believe the Common Lisp equivalent of this is > (cl:defpackage "MY-APP" (:use "CL")) > (cl:in-package "MY-APP") > > (os:listdir "/root") Any way to do this in emacs lisp? -- Ville Vainio http://www.students.tut.fi/~vainio24
From: Thomas F. Burdick Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <xcvwuanbk7j.fsf@famine.OCF.Berkeley.EDU>
Ville Vainio <······················@spamtut.fi> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > Knowing no python, I believe the Common Lisp equivalent of this is
> > (cl:defpackage "MY-APP" (:use "CL"))
> > (cl:in-package "MY-APP")
> >
> > (os:listdir "/root")
>
> Any way to do this in emacs lisp?
No, but you can have different worlds of interned symbols. Lookup
obarrays in the elisp manual -- then don't use them ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----' From: Christophe Rhodes Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <sq8yn3rftq.fsf@lambda.jcn.srcf.net>
Ville Vainio <······················@spamtut.fi> writes: > Christophe Rhodes <·····@cam.ac.uk> writes: > >> Knowing no python, I believe the Common Lisp equivalent of this is >> (cl:defpackage "MY-APP" (:use "CL")) >> (cl:in-package "MY-APP") >> >> (os:listdir "/root") > > Any way to do this in emacs lisp? Not as far as I know. (You do know that comp.lang.lisp isn't the best forum for discussing emacs lisp, right? comp.lang.lisp caters for lisps which don't have their own newsgroups, which in practice at the moment means Common Lisp with smatterings of ISLISP, XLisp and InterLISP). Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Henrik Motakef Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <86wuan7r4p.fsf@pokey.internal.henrik-motakef.de>
Ville Vainio <······················@spamtut.fi> writes: > > Knowing no python, I believe the Common Lisp equivalent of this is > > (cl:defpackage "MY-APP" (:use "CL")) > > (cl:in-package "MY-APP") > > > > (os:listdir "/root") > > Any way to do this in emacs lisp? Emacs Lisp has no packages, even after (require 'cl). You are free to use (defun os:listdir ...) instead of (defun os-listdir ...) or something, but that's it. No (use-package :os), no import, no shadow. On the plus side, you can use the Python os module from Emacs Lisp, with Pymacs.
From: Kaz Kylheku Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <cf333042.0310300111.6278f8b0@posting.google.com>
Ville Vainio <······················@spamtut.fi> wrote in message news:<···············@mozart.cc.tut.fi>... > Christophe Rhodes <·····@cam.ac.uk> writes: > > > Knowing no python, I believe the Common Lisp equivalent of this is > > (cl:defpackage "MY-APP" (:use "CL")) > > (cl:in-package "MY-APP") > > > > (os:listdir "/root") > > Any way to do this in emacs lisp? Emacs Lisp is very limited dialect of Lisp used to develop and extend a single application into which it is embedded. Never mind packages, it has no lexical scope, object system or conditions. It's best discussed in Emacs-related newsgroups, not comp.lang.lisp, where the focus is the most prominent Lisp dialect known as ANSI Common Lisp.
From: sean Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <m2oevy3euq.fsf@rh220-50.resnet.ucsd.edu>
···@ashi.footprints.net (Kaz Kylheku) writes: > Ville Vainio <······················@spamtut.fi> wrote in message news:<···············@mozart.cc.tut.fi>... >> Any way to do this in emacs lisp? > > Emacs Lisp is very limited dialect of Lisp used to develop and > extend a single application into which it is embedded. Never > mind packages, it has no lexical scope, object system or > conditions. IIRC it has CLOS-like objects as an extension (EIEIO), and Lars Brinkhoff's post suggests it can have packages as well (yes, "no lexical scope" is painful sometimes). > the most prominent Lisp dialect known as ANSI Common Lisp. What do you mean by "prominent" here? I'll bet you a nickel that more people install and use elisp than Common Lisp. "Eminent", "magnificent" or, in a less chariable mood "corpulent" seem like better descriptions ;). /s
From: Ingvar Mattsson Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <87r80uy87b.fsf@gruk.tech.ensign.ftech.net>
sean <········@reverse-that.ucsd.edu> writes: > ···@ashi.footprints.net (Kaz Kylheku) writes: > > > Ville Vainio <······················@spamtut.fi> wrote in message news:<···············@mozart.cc.tut.fi>... > >> Any way to do this in emacs lisp? > > > > Emacs Lisp is very limited dialect of Lisp used to develop and > > extend a single application into which it is embedded. Never > > mind packages, it has no lexical scope, object system or > > conditions. > > IIRC it has CLOS-like objects as an extension (EIEIO), and Lars > Brinkhoff's post suggests it can have packages as well (yes, "no > lexical scope" is painful sometimes). That would be Lars' very brave attempt at implementing Common Lisp in Emacs Lisp (after that, we can try to port the Hemlocky bits my code needs and we can run an elisp-incl-in-elisp and see teh whole world be sucked into a spinning vortex). //Ingvar -- Q: What do you call a Discworld admin? A: Chelonius Monk
From: Lars Brinkhoff Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <85k76nnpyp.fsf@junk.nocrew.org>
Ville Vainio <······················@spamtut.fi> writes: > Christophe Rhodes <·····@cam.ac.uk> writes: > > Knowing no python, I believe the Common Lisp equivalent of this is > > (cl:defpackage "MY-APP" (:use "CL")) > > (cl:in-package "MY-APP") > > (os:listdir "/root") > > Any way to do this in emacs lisp? There is the hard way: implement packages in Emacs Lisp. Then implement a new read function that interns symbols in those packages. Incidentally, I did that one month ago. Emacs> (readtable-case *readtable*) :UPCASE Emacs> |default-major-mode| |fundamental-mode| Emacs> (setf (readtable-case *readtable*) :preserve) :PRESERVE Emacs> (SYMBOL-PACKAGE 'fundamental-mode) #<PACKAGE "EMACS-LISP"> Emacs> (SYMBOL-PACKAGE :foo) #<PACKAGE "KEYWORD"> -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/
From: Ingvar Mattsson Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <87d6cg0zr4.fsf@gruk.tech.ensign.ftech.net>
Ville Vainio <······················@spamtut.fi> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > The lack of Lisp libraries is being addressed.
>
> Are they also going to address the lack of modules? The way I've seen
> Lisp used, everything is dumped into a global namespace (even
> "methods" in CLOS). I shudder at the thought of using Python where all
> the names from various modules would be in the global namespace.
There's packages. They're not *quite* the same thing, I hear, but for
this discussion, we can assume they are. One of the reasons most
examples just dump stuff in the global namespace is because (to some
degree) it's simpler.
From a piece of code I'm doodling on in my copious free time:
(defpackage "ELISP"
(:shadow "=" "DEFUN" "LET" "IF" "SETQ" "ASSOC" "COMMANDP" "AREF")
(:use "COMMON-LISP" "HEMLOCK-INTERNALS")
(:export
; Lots of symbols not listed
))
(defpackage "ELISP-INTERNALS"
(:shadow "READ-STRING")
(:use "COMMON-LISP")
(:export
"FIND-LAMBDA-LIST-VARIABLES"
"GENERATE-CL-PACKAGE"
"REQUIRE-LOAD"
"GET-USER-HOMEDIR"
"INTERACTIVE-GLUE"
"*ELISP-READTABLE*"
)
)
(defpackage "ELISP-USER"
(:use "ELISP" "ELISP-INTERNALS")
)
After this has been done (and the relevant code loaded), there is a
package called ELISP-USER, where all action happens. It sees
symbols from ELISP and ELISP-INTERNALS as "local" and instead of using
<module>.<name>, one uses <package>:<name> to signify a thing from a
package one isn't using or isn't the local package.
//Ingvar
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.lFrom: Kenny Tilton Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <J%Rnb.16986$Gq.5354016@twister.nyc.rr.com>
Ville Vainio wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
>
>>The lack of Lisp libraries is being addressed.
>
>
> Are they also going to address the lack of modules? The way I've seen
> Lisp used, everything is dumped into a global namespace (even
> "methods" in CLOS). I shudder at the thought of using Python where all
> the names from various modules would be in the global namespace.
>
> in Python you can do:
>
> import os
>
> files = os.listdir("/root")
>
Python and Lisp, separated at birth?
(require 'os)
(defparameter *files* (os::listdir "/root"))
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20ApplicationFrom: Bruce Stephens Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <80wuaoou8t.fsf@isode.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Ville Vainio wrote:
>> Paolo Amoroso <·······@mclink.it> writes:
[...]
>> in Python you can do:
>> import os
>> files = os.listdir("/root")
>>
>
> Python and Lisp, separated at birth?
>
> (require 'os)
> (defparameter *files* (os::listdir "/root"))
That should be
(defparameter *files* (os:listdir "/root"))
shouldn't it?
(Single colons let you at exported symbols; double colons let you
access even unexported symbols. If I understand things correctly,
anyway.)From: Kenny Tilton Subject: Re: Global namespace (was Re: python libs v lisp coolness? Date: Message-ID: <KOSnb.17218$Gq.5365182@twister.nyc.rr.com>
Bruce Stephens wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Ville Vainio wrote:
>>
>>>Paolo Amoroso <·······@mclink.it> writes:
>
>
> [...]
>
>
>>>in Python you can do:
>>>import os
>>>files = os.listdir("/root")
>>>
>>
>>Python and Lisp, separated at birth?
>>
>> (require 'os)
>> (defparameter *files* (os::listdir "/root"))
>
>
> That should be
>
> (defparameter *files* (os:listdir "/root"))
>
> shouldn't it?
>
> (Single colons let you at exported symbols; double colons let you
> access even unexported symbols. If I understand things correctly,
> anyway.)
Right, thx. I actually always "use" a package and started my response
that way, then realized a closer parallel would be just to load the code
and use a package qualifier to get at the symbol. Wasn't thinking very
hard when I switched over to the second approach and added the package
qualifier.
My excuse is (and I'm sticking to it) that I was too pleased with myself
over my "separated at birth" crack. More support, from GvR:
http://www.python.org/doc/essays/blurb.html
Wow. s/Python/Lisp/w!
And from http://www.python.org/doc/essays/comparisons.html :
"[CL and Scheme] are close to Python in their dynamic semantics, but so
different in their approach to syntax that a comparison becomes almost a
religious argument: is Lisp's lack of syntax an advantage or a
disadvantage?"
Arnold "Lisp" Schwarznegger and Danny "Python" de Vito?
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application