Lisp OpenGL bindings?
Justin Dubs
I'm looking for a Common Lisp implementation with support for the OpenGL
API. Just in case that question is too simple, I'll complicate
matters further by asking that it work on Mac OS X. :-)
If this is not possible, what about Linux? I'd rather not have to
resurrect my old x86, but I suppose I can if I *need* to.
I've been looking via Google, but with no success.
Thanks,
Justin Dubs
Edi Weitz
Really? Google seems to return a couple of interesting links if asked
for 'opengl common lisp'. Anyway - as always, CLiki is your friend:
<http://www.cliki.net/OpenGL%20Bindings>
AFAIK the MCL bindings by Alexander Repenning are still under active
development and should have been or will be ported to OS X. Maybe you
should ask on the MCL mailing list - see
<http://www.digitool.com/contact.html#discussion-forum>
Cheers,
Edi.
Justin Dubs
Yeah, I've been to the CLiki page. All of their bindings are either for
compilers not supported on Mac OS X or for commercial compilers.
Which brings me to my second problem. I forgot to mention that I'm a
broke-ass college student. So, $300 for the educationally priced
edition of MCL is a little out of my desired range of spending.
Unfortunately, the MCL bindings do not work with OpenMCL, although I
believe that they are working on some bindings of their own.
It seems as though every Common Lisp interpreter in existance either has
no bindings, or bad bindings to OpenGL and that they are all "trying" to
get them de-suck-ified, and have been since their inceptions and will be
for the foreseeable future.
Truly a shame, as Common Lisp is a fabulous language. It just has
absolutely no support for, well, anything outside of the language
itself. No portable threading, graphics, windowing, sound, sockets ...
anything. Various half-finished, non-portable extensions for various
half-finished interpreters abound. If only there were one, portable,
solid, standards-complient Common Lisp implementation. A GCC of the
Common Lisp world. That'll be the day.
Looks like I'll be using C++ for the graphics and trying to find some
way to embed a Lisp interpreter, or get the Lisp interpreter to call the
C++ code. Or abstract the C++ code away over a non-portable socket
extension. Dirty, ugly, not fun, but I don't see what choice I have.
Thanks anyway,
Justin Dubs
John DeSoi
A quick review of the MCL implementation reveals only a couple of
MCL-specific functions to make it work (most of which are trivial). I'm
sure you could port it OpenMCL with far less work than the alternatives
you have listed.
You might find it useful to look at UFFI (http://uffi.med-info.com/)
which has a common foreign function interface for ACL, MCL, and OpenMCL
(and many others).
Best,
John DeSoi, Ph.D.
Chris Double
> It seems as though every Common Lisp interpreter in existance either
> has no bindings, or bad bindings to OpenGL and that they are all
> "trying" to get them de-suck-ified, and have been since their
> inceptions and will be for the foreseeable future.
Corman Lisp has OpenGL bindings that ship with the compiler. But
that's not an interpreter. It's a compiler.
LispWorks has OpenGL bindings/examples too doesn't it?
> Dirty, ugly, not fun, but I don't see what choice I have.
Write some OpenGL bindings perhaps? Pick one of the Common Lisp
implementations and go for it. It's not that difficult and if you're
not willing (or able) to shell out money for someone else to do it and
not willing to do it yourself then you can't complain too much...
Chris.
--
http://www.double.co.nz
Justin Dubs
I'm sorry. I haven't been speaking horribly well tonight.
When pointing out the "flaws" of Lisp interpreters, i was referring only
to the subset of them that are available to me, as in, the free ones.
Yeah, LispWorks, and most of the other commercial Lisps are very
full-featured and very robust. But none of the free ones are able to
live up to them unfortunately.
As you suggested, I might very well be undertaking the task of writing
and OpenGL binding for CLisp, or maybe helping out with the one for
OpenMCL. We'll see.
I think you'll be surprised, however, how much I am able to complain. :-)
Thanks for the resonse,
Justin Dubs
Thomas F. Burdick
Justin Dubs <justi...@zencode.org> writes:
> Yeah, I've been to the CLiki page. All of their bindings are either for
> compilers not supported on Mac OS X or for commercial compilers.
>
> Which brings me to my second problem. I forgot to mention that I'm a
> broke-ass college student. So, $300 for the educationally priced
> edition of MCL is a little out of my desired range of spending.
You bought a *Mac*, the Cadillac of PC's. And you're not willing to
shell out 300 measly dollars for a copy of a really nice CL
environment for it?!?! That's like buying a Sun, then complaining
that there's no IDE, except for Forte, which costs money. It's really
not that much!
> Unfortunately, the MCL bindings do not work with OpenMCL, although I
> believe that they are working on some bindings of their own.
Check out the NSOpenGLView class in the Cocoa framework. OpenMCL has
an Objective-C bridge, and you *are* working on the modern offspring
of NeXT -- shit's easy to program.
> It seems as though every Common Lisp interpreter in existance either has
> no bindings, or bad bindings to OpenGL and that they are all "trying" to
> get them de-suck-ified, and have been since their inceptions and will be
> for the foreseeable future.
No offense, but what in the hell are you talking about? The OpenGL
API is well-specified, and there is no shortage of implementations
with a reasonable FFI. Put 2+2 together. Just write bindings to GLUT
if you can't find them for your implementation. Porting those
bindings would be so trivial, it's not worth it to release some
universal OpenGL API, and per-implementation, they're already there:
GLUT!
> Truly a shame, as Common Lisp is a fabulous language.
No doubt.
> It just has absolutely no support for, well, anything outside of the
> language itself.
Yeah ... all those languages besides Java that do ... oh wait, there
aren't any. And just try to get Java to work across Unix-Mac-Windows,
supporting JVM 1.1-1.4, I dare you.
> No portable threading, graphics, windowing, sound, sockets ...
> anything. Various half-finished, non-portable extensions for
> various half-finished interpreters abound.
I routinely use 5 CL implementations on 4 platforms and I haven't had
a practical problem yet. Admittedly, I know when to use Squeak, and
when to use CL ... but I really can't sympathize with your position
one bit. Not one iota.
> If only there were one, portable, solid, standards-complient Common
> Lisp implementation. A GCC of the Common Lisp world. That'll be
> the day.
Oh for godsakes. Allegro. It runs on Windows, Mac OS X, Linux, and
real Unixes. Or CLISP, it's not standards-compliant, but its
deviations are well-defined, and still leave it second to no language
except ANSI CL and maybe Smalltalk.
> Looks like I'll be using C++ for the graphics and trying to find some
> way to embed a Lisp interpreter, or get the Lisp interpreter to call the
> C++ code.
Eff Eff Eye.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Edi Weitz
> When pointing out the "flaws" of Lisp interpreters,
That should be "compilers". You should do some research first and get
rid of some of your misconceptions. You're rather close to becoming
the troll of the week here.
Edi.
Tim Bradshaw
> Truly a shame, as Common Lisp is a fabulous language. It just has
> absolutely no support for, well, anything outside of the language
> itself. No portable threading, graphics, windowing, sound, sockets
> ... anything. Various half-finished, non-portable extensions for
> various half-finished interpreters abound. If only there were one,
> portable, solid, standards-complient Common Lisp implementation. A
> GCC of the Common Lisp world. That'll be the day.
At least you recognise the problem: Apart from C, essentially all the
other `languages' which actually offer `portable' interfaces to other
things have precisely one implementation, and for C the calling
convention is typically standardised so you might as well have only
one implementation. This makes life kind of easy.
--tim
Justin Dubs
> [ Only on c.l.Lisp ]
>
> Justin Dubs <justi...@zencode.org> writes:
>
>
>>Yeah, I've been to the CLiki page. All of their bindings are either for
>>compilers not supported on Mac OS X or for commercial compilers.
>>
>>Which brings me to my second problem. I forgot to mention that I'm a
>>broke-ass college student. So, $300 for the educationally priced
>>edition of MCL is a little out of my desired range of spending.
>
>
> You bought a *Mac*, the Cadillac of PC's. And you're not willing to
> shell out 300 measly dollars for a copy of a really nice CL
> environment for it?!?! That's like buying a Sun, then complaining
> that there's no IDE, except for Forte, which costs money. It's really
> not that much!
I can't afford it. I'm not made of money, I'm a college student. I had
a relatively high-paying part-time job at IBM for a semester, and that
bought me this Apple machine. I can't afford $300 for a Lisp
interpreter when Lisp is nothing but a hobby to me. Maybe when I
graduate in a year fine, but not now.
>
>
>>Unfortunately, the MCL bindings do not work with OpenMCL, although I
>>believe that they are working on some bindings of their own.
>
>
> Check out the NSOpenGLView class in the Cocoa framework. OpenMCL has
> an Objective-C bridge, and you *are* working on the modern offspring
> of NeXT -- shit's easy to program.
>
>
>>It seems as though every Common Lisp interpreter in existance either has
>>no bindings, or bad bindings to OpenGL and that they are all "trying" to
>>get them de-suck-ified, and have been since their inceptions and will be
>>for the foreseeable future.
>
>
> No offense, but what in the hell are you talking about? The OpenGL
> API is well-specified, and there is no shortage of implementations
> with a reasonable FFI. Put 2+2 together. Just write bindings to GLUT
> if you can't find them for your implementation. Porting those
> bindings would be so trivial, it's not worth it to release some
> universal OpenGL API, and per-implementation, they're already there:
> GLUT!
>
There IS a shortage of implementations with a reasonable FFI, ON MAC OS
X. CLisp's FFI doesn't work on Mac OS X. The OpenMCL one is currently
giving me problems, so I'll keep working on figuring it out. The
commercial ones, as I said, I can't afford. Also, I have no idea HOW to
write bindings for GLUT. I know what I binding IS. I know what an FFI
is. But I've never actually used one before, aside from the Python FFI,
which was trivial as the wrappers were automatically generated via SWIG.
I've never needed to really learn an FFI before. But I am trying to
learn. So, take it easy. I'm not as experienced in the Lisp FFI world
as you are.
>
>>Truly a shame, as Common Lisp is a fabulous language.
>
>
> No doubt.
>
>
>>It just has absolutely no support for, well, anything outside of the
>>language itself.
>
>
> Yeah ... all those languages besides Java that do ... oh wait, there
> aren't any. And just try to get Java to work across Unix-Mac-Windows,
> supporting JVM 1.1-1.4, I dare you.
C/C++, on Unix, which includes my platform of Mac OS X does have
well-established POSIX standards for networking and threading. Also,
standard OpenGL libraries exist for almost all unix-es giving them
standard C/C++ OpenGL support. All of this has been ported to Win32 as
well, making it pretty damned portable. OpenAL, which works with C++ on
Linux, Mac OS X, and Win32 (that I know of), give C++ cross-platform
sound as well.
Python and Perl will also do cross-platform sockets. Perl does
cross-platform threading. Python does cross-platform Sound and
3D-graphics with PyOpenGL, PyGame and a port of SDL.
Shit, Haskell comes with cross-platform OpenGL/GLUT bindings.
Almost all of these aforementioned languages have a single,
cross-platform, open-source compiler/interpreter. That's a good thing.
I was simply pointing out that Lisp does not have this luxury. CMUCL
is portable across most unix-es, but not all of them. CLisp is
improving but not there yet. OpenMCL, obviously only works on Macs.
The commercial ones are somewhat portable, but, obviously not free.
>
>
>>No portable threading, graphics, windowing, sound, sockets ...
>>anything. Various half-finished, non-portable extensions for
>>various half-finished interpreters abound.
>
>
> I routinely use 5 CL implementations on 4 platforms and I haven't had
> a practical problem yet. Admittedly, I know when to use Squeak, and
> when to use CL ... but I really can't sympathize with your position
> one bit. Not one iota.
>
>
Have you ever tried to use a complicated external API from one of these
CL implementations? I have no problems running lisp on various
machines, it's their support for 3rd party API's that's lacking as
binding for them have to be created per-API, and differently for each
lisp implementation.
Are you seriously trying to argue that Lisp external library support and
multimedia support on part with C/C++, Perl and Python?
>>If only there were one, portable, solid, standards-complient Common
>>Lisp implementation. A GCC of the Common Lisp world. That'll be
>>the day.
>
>
> Oh for godsakes. Allegro. It runs on Windows, Mac OS X, Linux, and
> real Unixes. Or CLISP, it's not standards-compliant, but its
> deviations are well-defined, and still leave it second to no language
> except ANSI CL and maybe Smalltalk.
>
Except for that small difference of Allegro not being free.
CLisp's FFI, as I already stated, doesn't work on Mac OS X and it
doesn't come with OpenGL bindings, so that doesn't help me.
>
>>Looks like I'll be using C++ for the graphics and trying to find some
>>way to embed a Lisp interpreter, or get the Lisp interpreter to call the
>>C++ code.
>
>
> Eff Eff Eye.
>
As I said, I'm not familiar with how to implement a binding via an FFI.
I've never tried before. I'm tring to learn. I've had a very long
day of trying to get various implementations compiled and working on my
system, so I'm sorry if my previous port, or this one, seemed a bit
melodramatic or pessimistic.
You sarcasm and condecsension, however, are not helping. I hope it is
atleast making you feel good about yourself.
Justin Dubs
Justin Dubs
Why "compilers?" They aren't compiling to C. I'm not using (compile
...) to compile my forms. I'm issuing commands in a read-eval-print
loop. Wouldn't that make it an interpreter? Or maybe I'm just confused.
What misconceptions are you talking about? The misconception that there
aren't any OpenGL bindings for free Lisps that work on OS X out of the box?
If I actually do have any misconceptions, I would be more than happy for
you to clear them up for me. I am in no way opposed to learning.
I come to this public forum, ask a question, make another post lamenting
some of the short-comings of available, free, Lisp implementations and
this, apparently, makes me a troll. Fine.
Regardless, have a good day/night,
Justin Dubs
Matthieu Villeneuve
>
> Edi Weitz wrote:
> > Justin Dubs <justi...@zencode.org> writes:
> >>When pointing out the "flaws" of Lisp interpreters,
> >
> > That should be "compilers". You should do some research first and get
> > rid of some of your misconceptions. You're rather close to becoming
> > the troll of the week here.
>
> ...) to compile my forms. I'm issuing commands in a read-eval-print
> loop. Wouldn't that make it an interpreter? Or maybe I'm just confused.
The fact that you are issuing commands in a read-eval-print loop doesn't
tell you anything about whether an interpreter or a compiler is used
behind the scene. The read-eval-print loop is just the way to interact
with the core of the Lisp environment, which can be an interpreter or a
compiler. Some implementations don't have an interpreter at all, all
forms you type are directly compiled to native code, then evaluated.
--Matthieu
Coby Beck
"Justin Dubs" <justi...@zencode.org> wrote in message
news:3de1eed9$1...@nopics.sjc...
> Edi Weitz wrote:
> > Justin Dubs <justi...@zencode.org> writes:
> >
> >
> >>When pointing out the "flaws" of Lisp interpreters,
> >
> >
> > That should be "compilers". You should do some research first and get
> > rid of some of your misconceptions. You're rather close to becoming
> > the troll of the week here.
> >
> > Edi.
>
> Why "compilers?" They aren't compiling to C. I'm not using (compile
> ...) to compile my forms. I'm issuing commands in a read-eval-print
> loop. Wouldn't that make it an interpreter? Or maybe I'm just confused.
He's referring to the very common misconception that Lisp is an interpreted
language. It is a common troll and sore point around here, don't worry if
some of us are a bit touchy ;) Re: compiling, most implementations compile
to machine language.
>
> What misconceptions are you talking about? The misconception that there
> aren't any OpenGL bindings for free Lisps that work on OS X out of the
box?
(see above)
> If I actually do have any misconceptions, I would be more than happy for
> you to clear them up for me. I am in no way opposed to learning.
>
> I come to this public forum, ask a question, make another post lamenting
> some of the short-comings of available, free, Lisp implementations and
> this, apparently, makes me a troll. Fine.
I don't think you're a troll. Ask away, but as is the nature of usenet,
expect many different kinds of responses, don't get caught in any flame
wars, they are all too common here (as are real trolls!)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Christophe Rhodes
Justin Dubs <justi...@zencode.org> writes:
> Edi Weitz wrote:
> > Justin Dubs <justi...@zencode.org> writes:
> >
> >> When pointing out the "flaws" of Lisp interpreters,
> > That should be "compilers". You should do some research first and get
> > rid of some of your misconceptions. You're rather close to becoming
> > the troll of the week here.
> > Edi.
>
> Why "compilers?" They aren't compiling to C. I'm not using (compile
> ...) to compile my forms. I'm issuing commands in a read-eval-print
> loop. Wouldn't that make it an interpreter? Or maybe I'm just
> confused.
It makes it an interactor. Apart from the semantics of what commands
that you issue return, the language does not define what happens under
the hood; thus, it is a perfectly acceptable implementation strategy
to compile almost everything:
* (defun foo (x) (1+ x))
FOO
* (compiled-function-p #'foo)
T ; or NIL, depending on your implementation
* (disassemble 'foo)
; 0C014114: MOVE $A3, $LRA ; no-arg-parsing entry point
; 18: SW $A3, $CFP[4]
; 1C: AND $NL3, $A2, 3
; 20: BEQ $ZERO, $NL3, L0
[...]
Other implementations compile to intermediate representations, to byte
code, or any or all of these forms, or to operate directly on the list
structure in a classic "interpreter" mode.
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)
Pascal Costanza
> Except for that small difference of Allegro not being free.
Allegro Common Lisp is free for personal use, including the version for
Mac OS X. I hope this helps.
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Justin Dubs
Thank you. I didn't know that. I'm still not sure I completely
understand though.
So, whether it's an interpreter or a compiler depends on the internals
of (eval ...), right? In a read-eval-print loop, (read) returns a list,
which eval then evaluates.
So, a compiler's eval would compile the list and then execute it, and an
interpreters eval would just interpret it intact?
CLisp:
> (defun foo ())
FOO
> (compiled-function-p #'foo)
NIL
> (compile 'foo)
FOO ;
NIL ;
NIL
> (compiled-function-p #'foo)
T
This would make CLisp an interpreter by default, but supporting
compilation upon request?
OpenMCL:
> (defun foo ())
FOO
> (compiled-function-p #'foo)
T
And this would make OpenMCL a compiler?
Thanks again,
Justin Dubs
Justin Dubs
Thanks to both yourself and Coby Beck for a hand in understanding this.
Justin Dubs
Justin Dubs
> Justin Dubs wrote:
>
>> Except for that small difference of Allegro not being free.
>
>
> Allegro Common Lisp is free for personal use, including the version for
> Mac OS X. I hope this helps.
>
>
> Pascal
>
Yeah, it is free, but crippled. It's the "Trial Edition."
The limited heap size of 18MB is far too small for what I'm trying to
accomplish, although good enough to use as a toy or for class work.
Maybe even enough to tide me over until I can afford to buy the real
version. Oh, that'll be sweet, the day I finally have extra money...
*drool*
And I fear the 60-day renewable license might be a pain in the ass, but
I don't really know because I've never tried to get one before.
Thanks for the heads-up though. I didn't realize the trial edition was
free,
Justin Dubs
Frederic Brunel
> Truly a shame, as Common Lisp is a fabulous language. It just has
> absolutely no support for, well, anything outside of the language
> itself. No portable threading, graphics, windowing, sound, sockets
> ... anything. Various half-finished, non-portable extensions for
> various half-finished interpreters abound. If only there were one,
> portable, solid, standards-complient Common Lisp implementation. A
> GCC of the Common Lisp world. That'll be the day.
You've pointed a problem I'm currently facing on. I would like to
write a 3D application in Common Lisp but I couldn't find any free
and complete bindings for OpenGL.
There is also a lot of incomplete implementation of Common Lisp in
the free software community. Same thing for the Scheme community. I
really don't known why everybody wants to write its own Scheme/Lisp
compiler instead of using and getting involved in an existing
implementation. When I see all this wasted energy and time, it just
make me sick!
The other, I was still looking for good free Common Lisp bindings
for OpenGL and I found another Lisp-like language for multimedia and
mathematical computation called Lush (http://lush.sf.net/). The *Not
Invented Here* and *Reinventing the Wheel* rules seems to apply once
again! :(
> Looks like I'll be using C++ for the graphics and trying to find some
> way to embed a Lisp interpreter, or get the Lisp interpreter to call
> the C++ code. Or abstract the C++ code away over a non-portable
> socket extension. Dirty, ugly, not fun, but I don't see what choice I
> have.
I was thinking about making this kind of things but I'm still trying
Common Lisp by writing my own bindings. There is a free projects
named CL-SDL (http://cl-sdl.sf.ne/) to interface the SDL library and
OpenGL to Common Lisp using UFFI. But again it's really imcomplete
and doesn't seems very active!
But I agree with you, it's really disapointing to see all this free
but bloated pieces of code. It's not really in favor of the Lisp
community.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
Matthieu Villeneuve
>
> Matthieu Villeneuve wrote:
> > The fact that you are issuing commands in a read-eval-print loop doesn't
> > tell you anything about whether an interpreter or a compiler is used
> > behind the scene. The read-eval-print loop is just the way to interact
> > with the core of the Lisp environment, which can be an interpreter or a
> > compiler. Some implementations don't have an interpreter at all, all
> > forms you type are directly compiled to native code, then evaluated.
> >
> >
> > --Matthieu
>
> Thank you. I didn't know that. I'm still not sure I completely
> understand though.
>
> So, whether it's an interpreter or a compiler depends on the internals
> of (eval ...), right? In a read-eval-print loop, (read) returns a list,
> which eval then evaluates.
>
> So, a compiler's eval would compile the list and then execute it, and an
> interpreters eval would just interpret it intact?
Pretty much. Some implementations compile everything, some interpret
everything, some do some processing on expressions then interpret the
result.
> CLisp:
> > (defun foo ())
> FOO
> > (compiled-function-p #'foo)
> NIL
> > (compile 'foo)
> FOO ;
> NIL ;
> NIL
> > (compiled-function-p #'foo)
> T
>
> This would make CLisp an interpreter by default, but supporting
> compilation upon request?
Right.
> OpenMCL:
> > (defun foo ())
> FOO
> > (compiled-function-p #'foo)
> T
>
> And this would make OpenMCL a compiler?
Maybe, depending on what you call a compiler. Note that within the
Common Lisp terminology, compiling doesn't necessarily mean transforming
Lisp code to a machine native code. For example, a function that is
internally being represented with a "list" can be considered as
compiled, as long as it respects a few conditions, like for example not
containing references to macros that haven't been expanded. See the
HyperSpec section 3.2.2 about that.
--Matthieu
Matthias Heiler
Justin Dubs wrote:
[...]
> It seems as though every Common Lisp interpreter in existance either has
> no bindings, or bad bindings to OpenGL and that they are all "trying" to
> get them de-suck-ified, and have been since their inceptions and will be
> for the foreseeable future.
>
> Truly a shame, as Common Lisp is a fabulous language. It just has
> absolutely no support for, well, anything outside of the language
> itself. No portable threading, graphics, windowing, sound, sockets ...
> anything. Various half-finished, non-portable extensions for various
> half-finished interpreters abound. If only there were one, portable,
> solid, standards-complient Common Lisp implementation. A GCC of the
> Common Lisp world. That'll be the day.
I made the very same observations in a couple of instances, and I also share
your experience that many of the libraries available at cliki are not
really finished, documented, or stable. As for many projects I don't have
time to build my own bindings (or debug someone elses) I settled down for
the somewhat strange compromise to use CL when I can do something within
its core language and to use other tools when I need anything related to
the areas you mentioned above. (For doing OpenGL-stuff I would use Python
and PyOpenGL, for instance.)
Yours,
Matthias
Jochen Schmidt
> Truly a shame, as Common Lisp is a fabulous language. It just has
> absolutely no support for, well, anything outside of the language
> itself. No portable threading, graphics, windowing, sound, sockets ...
> anything. Various half-finished, non-portable extensions for various
> half-finished interpreters abound. If only there were one, portable,
> solid, standards-complient Common Lisp implementation. A GCC of the
> Common Lisp world. That'll be the day.
Yes Common Lisp qua language does not have any support for anything outside
of Common Lisp qua language - this sounds very obvious to me.
If you actually meant that implementations of Common Lisp do not support
anything outside what is defined as being part of the language then you are
wrong. Any lisp-systems I know define things which are outside of the
standard.
I think you meant something like: "Those implementations of Common Lisp I
can afford (those who cost nothing and run on Mac) do not support anything
of the things I personally want to toy with in my freetime"
But lets investigate how this problem could get solved. First we have to
identify the one who is likely to solve your problem. Here are some people
I could see who are able to solve your problem.
1) A vendor of a commercial Lispsystem running on Mac
He could solve your problem by granting you a free uncrippled copy of their
product. I think this is rather unlikely to happen if you are not willing to
give them anything back. "Hey I'm a student I cannot afford this Porsche but
other means of transport like busses are free to students like me and its a
shame there are no free Porsches for students..." does not seem to work
out. (Well - I never tried... ;-) )
2) Some developer who needs OpenGL for a commercial product
He might decide to develop bindings to OpenGL for a free lisp-system running
on Mac but since he plans to earn money from his product he might choose to
invest in a commercially supported solution which would fit his needs and
will make his product happen to be finished earlier.
3) Some student or hobbyist
Unable to afford a commercial solution he has nothing left but to do it
himself or help others who are in a similar situation.
Please do not understand this as an offense to you. I'm really interested to
know who it is you actually imagine solving your problem. And it is not
only 3 that seems to be open to you. If you are flexible enough to adapt
yourself instead of demanding this from others you could find another
solution:
Examples:
a) Earn some money in your freetime
b) Offer something interesting to a vendor or developer as compensation
c) Choosing another platform were there are more opportunities for you
(x86 Windows with Corman Lisp or Linux with CMUCL comes to my mind...)
I personally chose a combination of a and b when I was in a similar
situation.
> Looks like I'll be using C++ for the graphics and trying to find some
> way to embed a Lisp interpreter, or get the Lisp interpreter to call the
> C++ code. Or abstract the C++ code away over a non-portable socket
> extension. Dirty, ugly, not fun, but I don't see what choice I have.
This is another way to solve your problem - indeed a bit ugly - driving a
porsche is definitely more fun than driving with the bus...
ciao,
Jochen
Knut Arild Erstad
:
: No offense, but what in the hell are you talking about? The OpenGL
: API is well-specified, and there is no shortage of implementations
: with a reasonable FFI. Put 2+2 together. Just write bindings to GLUT
: if you can't find them for your implementation. Porting those
: bindings would be so trivial, it's not worth it to release some
: universal OpenGL API, and per-implementation, they're already there:
: GLUT!
This is not true in my experience. I ported some OpenGL bindings from
Allegro to CMUCL, and the absolutely hardest part was getting GLUT to
work, because calling Lisp from C is harder than the other way around (in
CMUCL at least). It is also a problem that the GLUT main loop is not
meant to be exited, and even though there are ways to do so (THROW/CATCH),
there seems to be problems on some platforms (such as windows not
closing). Being able to open and close windows without restarting the
application is pretty essential for interactive programming, so I ended up
using X11/GLX-bindings instead of GLUT.
For those interested: http://www.ii.uib.no/~knute/lisp/lisp.html
--
Knut Arild Erstad
Don't try to solve serious matters in the middle of the night.
-- Philip K. Dick
Knut Arild Erstad
:
: Yeah, I've been to the CLiki page. All of their bindings are either for
If OpenMCL has a decent FFI, it shouldn't be too hard to port some of the
existing bindings to it. I converted bindings from Allegro to CMUCL, and
most of the work was simply understanding and experimenting with the FFI.
I also had OpenGL bindings for clisp up-and-running at one point. I can
dig them out if anoyone is interested.
Kenny Tilton
Jochen Schmidt wrote:
> Examples:
> a) Earn some money in your freetime
> b) Offer something interesting to a vendor or developer as compensation
> c) Choosing another platform were there are more opportunities for you
> (x86 Windows with Corman Lisp or Linux with CMUCL comes to my mind...)
>
> I personally chose a combination of a and b when I was in a similar
> situation.
I just flashed back to when I discovered, a bit belatedly in 77 or 78,
that an ordinary individual could own a computer. I remember eliminating
all extraneous expenditure (including the sunday paper) until I had
enough to buy an Apple II.
I'm over in Pythonland these days porting Cells to Python and I am
starting to get a feel for the phenomenon. Ideas still forming, but my
working theory is that CL and Py are apples and oranges, no point in
comparing the experiences. Py will never be CL purely as a language, but
it is cool enough and free and xplatform and C-ish and it has a ton of
people churning out libraries for it.
CLers can find great support outside CL if they go to a vendor and pay
for it. This ain't no mass hobby language, and it could take a while for
that to happen. "mass" might never happen (most people including me
could not even drive a formula 1 race car), but maybe enough to make
more free stuff available.
<end of rambling, unfocussed, mind-dribble>
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton
Knut Arild Erstad wrote:
> It is also a problem that the GLUT main loop is not
> meant to be exited, and even though there are ways to do so (THROW/CATCH),
> there seems to be problems on some platforms (such as windows not
> closing). Being able to open and close windows without restarting the
> application is pretty essential for interactive programming,
I have not attempted this, but did you look at hacking the GLUT as
described here?:
http://sjbaker.org/steve/software/glut_hack.html
I guess you get the GLUT sources, make a small change and rebuild the dll.
I passed on it because the GLUT doc itself says it is not suitable for
serious development.
Jochen Schmidt
>
>
> Jochen Schmidt wrote:
>
>> Examples:
>> a) Earn some money in your freetime
>> b) Offer something interesting to a vendor or developer as compensation
>> c) Choosing another platform were there are more opportunities for you
>> (x86 Windows with Corman Lisp or Linux with CMUCL comes to my mind...)
>>
>> I personally chose a combination of a and b when I was in a similar
>> situation.
>
> I just flashed back to when I discovered, a bit belatedly in 77 or 78,
> that an ordinary individual could own a computer. I remember eliminating
> all extraneous expenditure (including the sunday paper) until I had
> enough to buy an Apple II.
>
> I'm over in Pythonland these days porting Cells to Python and I am
> starting to get a feel for the phenomenon. Ideas still forming, but my
> working theory is that CL and Py are apples and oranges, no point in
> comparing the experiences. Py will never be CL purely as a language, but
> it is cool enough and free and xplatform and C-ish and it has a ton of
> people churning out libraries for it.
>
> CLers can find great support outside CL if they go to a vendor and pay
> for it. This ain't no mass hobby language, and it could take a while for
> that to happen. "mass" might never happen (most people including me
> could not even drive a formula 1 race car), but maybe enough to make
> more free stuff available.
Well there are a lot of people making free stuff available for Common Lisp.
Compilers like CMUCL, SBCL, OpenMCL, CLISP, ECL and more are just one
category of CL projects with highly motivated and hard working people
behind.
I think it is wrong to claim that CLers can find support only by paying a
vendor. Its just like anywhere else - go to c.l.python and ask them why
there is no symbolic math package like Maxima or even just an optimizing
native code compiler freely available for Python while other languages like
CL offer things like that for free. There will always be stuff that is not
directly available for free.
I find it particularily annoying if there are claims about CL as a language
not supporting something just because some of the setup constraints (like
chosen platform and cost in the OP case) do not fit with available
implementations. It is not a lack of CL but a lack of the chosen
implementation.
Kenny Tilton
Jochen Schmidt wrote:
> Kenny Tilton wrote:
>
>
>>
>>Jochen Schmidt wrote:
> Well there are a lot of people making free stuff available for Common Lisp.
fer sher, and if I am not mistaken the pace is increasing. Speak of the
devil, I myself did have some fun with OpenGL bindings (for Acl and
win32), and if I decide to attempt a universal CL GUI I will certainly
tap Kevin's killer UFFI stuff. And I would love on the CliniSys app to
explore using DEY's Lisa for authoring rules.
> I think it is wrong to claim that CLers can find support only by paying a
> vendor.
I guess I was thinking of ACL's tight interface to Java. Shucks, if we
all had that I just might look at using SWT instead of OGL.
> Its just like anywhere else - go to c.l.python and ask them why
> there is no symbolic math package like Maxima or even just an optimizing
> native code compiler freely available for Python while other languages like
> CL offer things like that for free. There will always be stuff that is not
> directly available for free.
Well the compiler thing I think is a category-change. I am starting to
think Python is about straightforward programming in a
cool-but-not-great language Just to Get Things Done. And the speed hit
does not compromise for them the "Done" thang. So I don't think we can
wave free compilers around, it just reinforces their perception that the
CL crowd is focused on other stuff besides add-on libraries as opposed
to inside-the-language good stuff.
Mario S. Mommer
Kenny Tilton <kti...@nyc.rr.com> writes:
>
> Well the compiler thing I think is a category-change. I am starting to
> think Python is about straightforward programming in a
> cool-but-not-great language Just to Get Things Done. And the speed hit
> does not compromise for them the "Done" thang. So I don't think we can
> wave free compilers around, it just reinforces their perception that
> the CL crowd is focused on other stuff besides add-on libraries as
> opposed to inside-the-language good stuff.
I have the feeling that most of the inside-the-language good stuff
ends up being incomplete and unsupported because the original
programmer(s) feels that there is no interest for it. Like a "well - I
solved my problem and nobody cares, so screw it" thing. This is sad,
because people indeed care. And good inside-the-language stuff
attracts people that then care.
On the other hand, performance still matters for a lot of people, so
"just getting the job done" cannot be the only issue. Have you ever
tried CMUCL? The machine-code its compiler generates just burns.
Btw I'm sad to hear that you are no longer pursuing the universal CL
GUI thing. I think that that would have a very positive impact. Why
not try out something simple and maybe a bit limited as a prototype?
Using Cells of course! :-)
Mario.
Daniel Barlow
> Truly a shame, as Common Lisp is a fabulous language. It just has
> absolutely no support for, well, anything outside of the language
> itself. No portable threading, graphics, windowing, sound, sockets
> ... anything. Various half-finished, non-portable extensions for
> various half-finished interpreters abound. If only there were one,
> portable, solid, standards-complient Common Lisp implementation. A
> GCC of the Common Lisp world. That'll be the day.
Please let us know what you intend doing to ameliorate the situation.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Kenny Tilton
Mario S. Mommer wrote:
> I have the feeling that most of the inside-the-language good stuff
> ends up being incomplete and unsupported because the original
> programmer(s) feels that there is no interest for it.
right, and so we have a chicken-egg thing going here to the extent that
folks eschew Lisp because Python or Java has more libs. Those two have
more contributors, and they are single-implementation (roughly speaking)
so they don't get "oh, yes, but only for [some OS or even some
implementation].
> Btw I'm sad to hear that you are no longer pursuing the universal CL
> GUI thing. I think that that would have a very positive impact. Why
> not try out something simple and maybe a bit limited as a prototype?
> Using Cells of course! :-)
Cells! <g>
Think "detour". What happened was, I saw Python had this (somewhat)
standard relationship with Tkinter (a GUI) so I thought I would explore
doing a Python thing first. What is needed is some open source energy
(lotsa hands on deck) and I am just going where the recruits are.
See, so far I am one of only a few folks excited about Cells, and the
others (the ones there at its inception) are long gone. I knew from day
one folks would have to see Cells in the context of a GUI before digging
it, so I gots to do a GUI. Python offers an easy port (core already done
in just a week, while learning Python) and an already universal framework.
Mind you, I have come close a couple of times to throwing up my hands in
despair over the language and even the IDE, but I'll soldier on a while
longer. The worst thing is, I am starting to wonder if the Python crowd
is even the right audience.
If they like a simple "save me from myself, and don't confuse me"
language, maybe they will not groove on a new programming paradigm. Is
Python mostly for non-professional programmers, like scientists brave
enough to write code for their own use, but otherwise amateur in
abaility and aspiration?
I'll let you know. :)
Christopher C. Stacy
Justin> Why "compilers?" They aren't compiling to C. I'm not using
Justin> (compile ...) to compile my forms. I'm issuing commands in a
Justin> read-eval-print loop. Wouldn't that make it an interpreter?
Justin> Or maybe I'm just confused. What misconceptions are you
Justin> talking about?
Most Lisp implementations compile to machine code,
and many don't have an interpreter at all.
You type in a Lisp form to the read-eval-print loop,
the form is compiled, and then it is executed.
Some implementations also provide an interpreter.
Janis Dzerins
> Pascal Costanza wrote:
> >
> > Allegro Common Lisp is free for personal use, including the version for
> > Mac OS X. I hope this helps.
>
> Yeah, it is free, but crippled. It's the "Trial Edition."
>
> The limited heap size of 18MB is far too small for what I'm trying to
> accomplish,
How do you know? Have you tried?
I know one can do a hell of a lot with that "crippled" edition.
> And I fear the 60-day renewable license might be a pain in the ass, but
> I don't really know because I've never tried to get one before.
You better try because it's no pain at all and there's a little
program that does it for you.
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
Joshua D. Boyd
> [ Only on c.l.Lisp ]
>
> Justin Dubs <justi...@zencode.org> writes:
>
>> Yeah, I've been to the CLiki page. All of their bindings are either
>> for compilers not supported on Mac OS X or for commercial compilers.
>>
>> Which brings me to my second problem. I forgot to mention that I'm a
>> broke-ass college student. So, $300 for the educationally priced
>> edition of MCL is a little out of my desired range of spending.
>
> You bought a *Mac*, the Cadillac of PC's. And you're not willing to
> shell out 300 measly dollars for a copy of a really nice CL environment
> for it?!?! That's like buying a Sun, then complaining that there's no
> IDE, except for Forte, which costs money. It's really not that much!
No IDE except Forte? What more of an IDE could a person want when Emacs
is available? But seriously, my Sun Ultra1 cost a small fraction of what
Sun ONE (the product formerly known as Forte) costs. It was easy to buy
the Ultra1, but for what I paid, Sun ONE is a dozen times more expensive,
and the price of Ultra1s has fallen further since then.
Likewise, a person desperate enough for OS X can buy and upgrade an older
Mac, like an 8500, to run OS X for about $300. Sure, it will run pretty
slowly, but it will be running. Used B&W G3s aren't too expensive now
either, and with an upgraded video card, it wouldn't be too slow.
However, $300 for the limited (if only by the license) student version is
a lot for a lot of students.
However, I also fail to see what the problem with OpenMCL (anyone tried
it on mkLinux/PPC BTW?) or CMUCL is.
>> Unfortunately, the MCL bindings do not work with OpenMCL, although I
>> believe that they are working on some bindings of their own.
>
> Check out the NSOpenGLView class in the Cocoa framework. OpenMCL has an
> Objective-C bridge, and you *are* working on the modern offspring of
> NeXT -- shit's easy to program.
Hmm. Does that Objective-C bridge work on Linux? I know that since I
can't afford a resonable OS X machine, I'm doing my Objective development
on Linux.
Thomas F. Burdick
> On Mon, 25 Nov 2002 02:51:22 -0500, Thomas F. Burdick wrote:
>
> > [ Only on c.l.Lisp ]
> >
> > Justin Dubs <justi...@zencode.org> writes:
> >
> >> Yeah, I've been to the CLiki page. All of their bindings are either
> >> for compilers not supported on Mac OS X or for commercial compilers.
> >>
> >> Which brings me to my second problem. I forgot to mention that I'm a
> >> broke-ass college student. So, $300 for the educationally priced
> >> edition of MCL is a little out of my desired range of spending.
> >
> > You bought a *Mac*, the Cadillac of PC's.
[ I take this back, Macs are more like Alfas or Infinities. The
Cadillac would probably be Sun -- gotta love that chromed out scraper ]
> > And you're not willing to
> > shell out 300 measly dollars for a copy of a really nice CL environment
> > for it?!?! That's like buying a Sun, then complaining that there's no
> > IDE, except for Forte, which costs money. It's really not that much!
>
> No IDE except Forte? What more of an IDE could a person want when Emacs
> is available?
Well, *I'm* happier with Emacs, but if someone is used to, say, Visual
C++, they might want a real IDE.
> But seriously, my Sun Ultra1 cost a small fraction of what Sun ONE
> (the product formerly known as Forte) costs. It was easy to buy the
> Ultra1, but for what I paid, Sun ONE is a dozen times more
> expensive, and the price of Ultra1s has fallen further since then.
Well, in that offhand hypothetical, I was assuming someone bought a
new Sun, and forgot that they'd raised the price of Forte (er, ONE)
recently. I feel you on the cost relative to a used Ultra, especially
since Forte C whups gcc, and there's no other Fortran option I'd even
consider. Thankfully, you only need a copy on one machine.
> Likewise, a person desperate enough for OS X can buy and upgrade an older
> Mac, like an 8500, to run OS X for about $300. Sure, it will run pretty
> slowly, but it will be running. Used B&W G3s aren't too expensive now
> either, and with an upgraded video card, it wouldn't be too slow.
That's true. But it's unusual, and someone with such a system
probably wouldn't be wanting to do OpenGL stuff.
> However, $300 for the limited (if only by the license) student version is
> a lot for a lot of students.
Yes and no. I mean, yeah, it is a lot, but if your demands from your
development environment are that high, it's not too much. But if it's
a hobby you take seriously, it's not at all unreasonable. Especially,
again, since it's on a Mac. You don't expect anything to be the
Bargain Basement version on a Mac. $100 for a CL environment on
Windows vs $300 for a Mac one with more development niceties -- that
sounds about right.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Dennis Marti
"Joshua D. Boyd" <jdb...@cs.millersville.edu> wrote:
> However, $300 for the limited (if only by the license) student version is
> a lot for a lot of students.
$300 has been quoted a lot in this thread; I just wanted to point out
that the last release of MCL (4.3.5) only costs $66 US with a student
discount. It runs in classic mode on OS X, has OpenGL bindings, runs
CL-HTTPD, includes an emacs clone (fred), a persistent object store
(WOOD) and a nice interface toolkit. It's got to be one of the sweetest
Lisp deals out there.
Dennis
Matthias Hölzl
> You've pointed a problem I'm currently facing on. I would like to
> write a 3D application in Common Lisp but I couldn't find any free
> and complete bindings for OpenGL.
You might be interested in the ffigen backend available from
<http://www.gauss.muc.de/c-interface.tgz>.
I use this program to generate X11/GLX/OpenGL/GLU bindings for some of
my applications. Currently the backend only supports CMUCL but it
should not be too difficult to generate ffi-bindings for other Lisps
(or the UFFI).
Matthias