What I'm looking for is a reasonably complete and mature CL
implementation that has, at least, the following features:
- It is Open Source / Free Software.
- Makes it easy to call C functions and access C objects from within
LISP code.
- Has support for networking (sockets).
- Has good support for accessing O/S services (for example has
support for accessing serial ports).
- Has some reasonably-good mutlithreading support.
- Produces "binaries" that run on Linux, Windows, and MACOS.
- Is cross-platform at least at the source code level, including the
support for networking and threading, and for as much of the other
O/S support stuff as the semantics allow.
- Provides support for writting *cross-platform* graphical
applications that use each platform's native GUI toolkit.
As far as I have looked, there seems to be no implementation that
covers my checklist. Am I wrong, or should I turn to Python?
Thanks in advance
/npat
> From: "Nick Patavalis" <····@efault.net>
> Sent: Friday, February 27, 2004 2:04 PM
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
>
> - It is Open Source / Free Software.
Yeah, we have those.
> - Makes it easy to call C functions and access C objects from within
> LISP code.
Yeah, some do that.
> - Has support for networking (sockets).
Most do that.
> - Has good support for accessing O/S services (for example has
> support for accessing serial ports).
Hmm...maybe
> - Has some reasonably-good mutlithreading support.
Welllll...you talking native can-be-scheduled-on-your-128CPU-E10000 kind of
threads? We have several with internal threading model, but not necessarily
native threads. Ones working real hard on it, though.
> - Produces "binaries" that run on Linux, Windows, and MACOS.
Oh. Ooops. Nope. The only single Free CL that can possibly meet this
criteria doesn't support threads.
> - Is cross-platform at least at the source code level, including the
> support for networking and threading, and for as much of the other
> O/S support stuff as the semantics allow.
Well, that's CL in general. Standards help encourage that, the community
helps enforce it.
> - Provides support for writting *cross-platform* graphical
> applications that use each platform's native GUI toolkit.
Yeah. Nope. Sorry.
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
Nope. Sorry. Python it is.
Of course, there are commercial versions that meet all of the above,
but...well...why would anyone want to use those?
Off with you then. Have fun! We'll catch up with you on c.l.python.
Oh. Wait. I don't subscribe to that...never mind then.
Regards,
Will Hartung
(·····@msoft.com)
<·····@msoft.com> wrote:
>> - Produces "binaries" that run on Linux, Windows, and MACOS.
>
>Oh. Ooops. Nope. The only single Free CL that can possibly meet this
>criteria doesn't support threads.
I thought that ECL supported both threads and Windows (Cygwin)
binaries. (Though whether they're both supported at the same time
would depend on whether Cygwin supports pthreads).
--
Juho Snellman
"Will Hartung" <·····@msoft.com> writes:
> > - Produces "binaries" that run on Linux, Windows, and MACOS.
[...]
> > As far as I have looked, there seems to be no implementation that
> > covers my checklist. Am I wrong, or should I turn to Python?
>
> Nope. Sorry. Python it is.
Python does not produce binaries that run on Linux, Windows, and
MACOS.
BTW, Isn't it strange that the very same question appears here over
and over and over again in the very same form? Is it trolling,
perhaps?
Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@germany.igpm.rwth-aachen.de>...
>
> Python does not produce binaries that run on Linux, Windows, and
> MACOS.
>
I don't need the _same_ binaries to run on all platfroms. What I need
is source-code level compatibility (_including_ the libraries).
/npat
····@efault.net (Nick Patavalis) writes:
>
> Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@germany.igpm.rwth-aachen.de>...
> >
> > Python does not produce binaries that run on Linux, Windows, and
> > MACOS.
> >
>
> I don't need the _same_ binaries to run on all platfroms. What I need
> is source-code level compatibility (_including_ the libraries).
Ah. Well, that is where the Common Lisp standard helps. You get the
source code level compatibility for those things which have been
standardized. A couple of your desiderata, however, have not been
completely standardized, (i.e., sockets, threading) so unless you
manage to use the same implementation across platforms, you may have a
problem.
On the other hand, you may be able to write your own interface wrapper
to things like the thread and socket interface and essentially get a
common interface. I've done this for socket connections and it actually
isn't very hard to get basic operations on sockets with a single
interface.
--
Thomas A. Russ, USC/Information Sciences Institute
Mario S. Mommer <········@yahoo.com> writes:
> "Will Hartung" <·····@msoft.com> writes:
> > > - Produces "binaries" that run on Linux, Windows, and MACOS.
> [...]
> > > As far as I have looked, there seems to be no implementation that
> > > covers my checklist. Am I wrong, or should I turn to Python?
> >
> > Nope. Sorry. Python it is.
>
> Python does not produce binaries that run on Linux, Windows, and
> MACOS.
>
> BTW, Isn't it strange that the very same question appears here over
> and over and over again in the very same form? Is it trolling,
> perhaps?
Or Pythonista competitor analysis? :-)
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
On Fri, 27 Feb 2004 14:04:35 -0800, Nick Patavalis wrote:
> Am I wrong, or should I turn to Python?
I'm sure you'll find some reason to do the later. If you have not
explored languages deeply enough to realize that their benefits cannot
always be tallied by naive feature checklists, then you are ready *only*
for a language like Python, where there are no confusing alternative
implementations, where your old paradigms can be tranferred with little
thought, and where you can dwell in your ignorance as long as you wish.
Save Lisp for when you have a bit more curiosity and desire for knowledge.
faa
In article <····························@posting.google.com>, Nick
Patavalis <····@efault.net> wrote:
> - Produces "binaries" that run on Linux, Windows, and MACOS.
>
> - Is cross-platform at least at the source code level, including the
> support for networking and threading, and for as much of the other
> O/S support stuff as the semantics allow.
>
> - Provides support for writting *cross-platform* graphical
> applications that use each platform's native GUI toolkit.
This is more difficult than you realize. There are some cross platform
GUIs out there (notably QT and wxWidgets nee wxWindows), but they are
absolute /atrocities/ on the OS X platform. LispWorks' CAPI is slightly
better but not perfect.
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
Is there any particular reason it's Lisp or Python? If you have an
overwhelming desire to write source code which is "write once, look
awful anywhere" using an open-source implementation, then you might
consider PLT Scheme.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook <····················@cs.indiana.edu> wrote in message news:<·······································@cs.indiana.edu>...
>
> This is more difficult than you realize. There are some cross platform
> GUIs out there (notably QT and wxWidgets nee wxWindows), but they are
> absolute /atrocities/ on the OS X platform. LispWorks' CAPI is slightly
> better but not perfect.
>
I guess wxWindows is ok---this is what I had in mind for Python anyway---but
is there any CL implementation that provides bindings for wxWindows?
> Is there any particular reason it's Lisp or Python? If you have an
> overwhelming desire to write source code which is "write once, look
> awful anywhere" using an open-source implementation, then you might
> consider PLT Scheme.
I want to write an application which will be "write once, look reasonably
well everywhere", and I want to use a relatively high-level language.
I have written similar stuff with python quite successfully.
The one at hand is not a project of huge complexity, neither with a
deadline too pressing, so I would love to try lisp on this.
In article <····························@posting.google.com>, Nick
Patavalis <····@efault.net> wrote:
> I guess wxWindows is ok---this is what I had in mind for Python anyway---but
> is there any CL implementation that provides bindings for wxWindows?
Not currently.
> I want to write an application which will be "write once, look reasonably
> well everywhere", and I want to use a relatively high-level language.
> I have written similar stuff with python quite successfully.
> The one at hand is not a project of huge complexity, neither with a
> deadline too pressing, so I would love to try lisp on this.
Your comments suggest you have never used a wxWindows or QT program on
OS X - or that you've never seriously sat down with OS X at all, to
notice how poorly those Motif-inspired toolkits tend to fit in to the
environment.
PLT Scheme will give you the same as wxWindows and QT, which is to say,
looking good on Linux and Windows, and crappy but usable on OS X.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
In article <·······································@cs.indiana.edu>,
Brian Mastenbrook wrote:
>
> Your comments suggest you have never used a wxWindows or QT program on
> OS X - or that you've never seriously sat down with OS X at all, to
> notice how poorly those Motif-inspired toolkits tend to fit in to the
> environment.
You 're right, I have never seriously used MACOS-X, and as a matter of
fact, though I would like my programs to be able to run under it and
look as good as possible, not been able to do so is not a show-stopper
for my particular case. Perhaps I should have clarified this in the
original post... Windows and Linux, are absolutely required though!
> PLT Scheme will give you the same as wxWindows and QT, which is to say,
> looking good on Linux and Windows, and crappy but usable on OS X.
Thanks for the hint. I was looking for a CL (rather than Scheme)
environment, but I will still give PLT-Sceme a look.
/npat
On Fri, 27 Feb 2004 17:35:43 -0500, Brian Mastenbrook
<····················@cs.indiana.edu> wrote:
> In article <····························@posting.google.com>, Nick
> Patavalis <····@efault.net> wrote:
>
>> - Produces "binaries" that run on Linux, Windows, and MACOS.
>>
>> - Is cross-platform at least at the source code level, including the
>> support for networking and threading, and for as much of the other
>> O/S support stuff as the semantics allow.
>>
>> - Provides support for writting *cross-platform* graphical
>> applications that use each platform's native GUI toolkit.
>
> This is more difficult than you realize. There are some cross platform
> GUIs out there (notably QT and wxWidgets nee wxWindows), but they are
> absolute /atrocities/ on the OS X platform. LispWorks' CAPI is slightly
> better but not perfect.
>
>> As far as I have looked, there seems to be no implementation that
>> covers my checklist. Am I wrong, or should I turn to Python?
>
> Is there any particular reason it's Lisp or Python? If you have an
> overwhelming desire to write source code which is "write once, look
> awful anywhere" using an open-source implementation, then you might
> consider PLT Scheme.
>
Have you consideded a gnome inteface.
Intefacing to C++ is less than ideal because C++'s static object structure
is not a good mach for CLOS.
I have looked into the gnome interface for common lisp for CMUCL cl-gtk
and it looks promesing
but unfinihsed. gnome altso runs onder win32 so porting it to windows
should not be a huge problem.
I am looking ito this solution now perhaps a port to Corman common lisp
and clisp.
Anyhow gnome seems to fit CLOS quite well. I like what I am seeing
programwise.
Perhaps worth a look?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: John Watton
Subject: Re: A good open-source CL implementation?
Date:
Message-ID: <403fe21d_3@news1.prserv.net>
What do you mean by binaries? I don't think Python has any native compilers.
If all you mean by binaries is byte compiled then why do you need this
feature?
"Nick Patavalis" <····@efault.net> wrote in message
·································@posting.google.com...
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
>
> - It is Open Source / Free Software.
>
> - Makes it easy to call C functions and access C objects from within
> LISP code.
>
> - Has support for networking (sockets).
>
> - Has good support for accessing O/S services (for example has
> support for accessing serial ports).
>
> - Has some reasonably-good mutlithreading support.
>
> - Produces "binaries" that run on Linux, Windows, and MACOS.
>
> - Is cross-platform at least at the source code level, including the
> support for networking and threading, and for as much of the other
> O/S support stuff as the semantics allow.
>
> - Provides support for writting *cross-platform* graphical
> applications that use each platform's native GUI toolkit.
>
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
>
> Thanks in advance
> /npat
Nick Patavalis wrote:
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
>
> - It is Open Source / Free Software.
>
> - Makes it easy to call C functions and access C objects from within
> LISP code.
>
> - Has support for networking (sockets).
>
> - Has good support for accessing O/S services (for example has
> support for accessing serial ports).
>
> - Has some reasonably-good mutlithreading support.
>
> - Produces "binaries" that run on Linux, Windows, and MACOS.
>
> - Is cross-platform at least at the source code level, including the
> support for networking and threading, and for as much of the other
> O/S support stuff as the semantics allow.
>
> - Provides support for writting *cross-platform* graphical
> applications that use each platform's native GUI toolkit.
>
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
Nothing meets all your criteria. Several things meet most of them. FOr
example, if you omit the first criterion, Lispworks succeeds. If you
omit the last one, SBCL succeeds. If you omit the criterion that a
single implementation must produce binaries that work on all of Windows,
Mac, and Linux, then several Lisps meet your criterion for the Mac and
Linux (but you have to pay money for one on Windows).
Several projects are working on meeting your full list of requirements,
but none of them are all the way there yet.
mikel <·····@evins.net> wrote in message news:<·····················@newssvr25.news.prodigy.com>...
>
> Several projects are working on meeting your full list of requirements,
> but none of them are all the way there yet.
Which are they?
/npat
Nick Patavalis wrote:
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
Why are you looking? Are you just window shopping? Off hand
I cannot think of why you need a cross platform GUI that
utilizes native toolkits to such an implied depth. (or for
that matter any app that can run on all three platforms). If you
need absolute control of native GUI's toolkits then you
are going to have to interface directly with the native
libraries. Then code will have to customized for each platform.
Do not expect any language implementation to smooth over
deep differences between platforms (unless you are Sun
and try make the Java run-time replace all other systems).
Just an aside, I would suggest making a *commitment* to one platform,
writing your application and WORRY LATER about moving to other
platforms if it is successful. By that time you will know your
code inside and out and have no trouble porting it. (even to
another language if necessary). As a math professor once told me
"Sometimes things need hard work.".
Wade
Wade Humeniuk <····································@telus.net> wrote in message news:<·····················@edtnps84>...
>
> Why are you looking? Are you just window shopping? Off hand
> I cannot think of why you need a cross platform GUI that
> utilizes native toolkits to such an implied depth. (or for
> that matter any app that can run on all three platforms). If you
> need absolute control of native GUI's toolkits then you
> are going to have to interface directly with the native
> libraries.
I'm not just window shopping. I do have a project in mind. It _has_
to run on Linux and Windows (it would be very nice if it could also
run on Macs), it is an application with a GUI, and it must not look
_awfull_ on any of the platforms. I have writen similar stuff in Python
(using the wxWindows toolkit). All I'm looking for a similar level
of O/S support and cross-platformness
Thanks
/npat
> Why are you looking? Are you just window shopping? Off hand
> I cannot think of why you need a cross platform GUI that
> utilizes native toolkits to such an implied depth.
I'm not the OP, but I think its important to keep multiple platforms
in mind. Linux is continuing to become more popular on the desktop,
MacOS seems to be on a resurgance, etc. It doesn't hurt to have your
code cross-platform from the beginning --- especially since its such a
PITA to rip out the GUI toolkit from a large program.
If SBCL were ported to Windows, the toolkit situation wouldn't be too
bad --- GTK+ runs on Windows, so in theory, cl-gtk should be pretty
easily ported over. A Qt-binding for SBCL would be even better, since
Qt looks native on the platforms it supports, unlike GTK+. Idolino
seems very interesting, though I don't know if its continuing to be
developed.
On 2 Mar 2004 22:32:38 -0800, Rayiner Hashem <·······@mindspring.com>
wrote:
>> Why are you looking? Are you just window shopping? Off hand
>> I cannot think of why you need a cross platform GUI that
>> utilizes native toolkits to such an implied depth.
> I'm not the OP, but I think its important to keep multiple platforms
> in mind. Linux is continuing to become more popular on the desktop,
> MacOS seems to be on a resurgance, etc. It doesn't hurt to have your
> code cross-platform from the beginning --- especially since its such a
> PITA to rip out the GUI toolkit from a large program.
>
> If SBCL were ported to Windows, the toolkit situation wouldn't be too
> bad --- GTK+ runs on Windows, so in theory, cl-gtk should be pretty
> easily ported over. A Qt-binding for SBCL would be even better, since
> Qt looks native on the platforms it supports, unlike GTK+. Idolino
> seems very interesting, though I don't know if its continuing to be
> developed.
Qt is not free under windows.
Even under unix commericial use is costly.
(Otherwise I would have started using it a long time ago)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> Qt is not free under windows.
> Even under unix commericial use is costly.
> (Otherwise I would have started using it a long time ago)
There is actually a free non-commercial-use license that comes with
the new Qt book. Closed-source use is costly, but not compared to some
of the tools commercial programmers use. I still remember being
shocked by how much Rational quoted for Rose when we saw the demo...
·······@mindspring.com (Rayiner Hashem) writes:
> > Qt is not free under windows.
> > Even under unix commericial use is costly.
> > (Otherwise I would have started using it a long time ago)
> There is actually a free non-commercial-use license that comes with
> the new Qt book. Closed-source use is costly, but not compared to some
> of the tools commercial programmers use. I still remember being
> shocked by how much Rational quoted for Rose when we saw the demo...
Keep in mind that Booch was shopping for a new yacht at the time.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> > > Qt is not free under windows.
> > > Even under unix commericial use is costly.
> > > (Otherwise I would have started using it a long time ago)
> > There is actually a free non-commercial-use license that comes with
> > the new Qt book. Closed-source use is costly, but not compared to some
> > of the tools commercial programmers use. I still remember being
> > shocked by how much Rational quoted for Rose when we saw the demo...
>
> Keep in mind that Booch was shopping for a new yacht at the time.
At least they're getting their money's worth. Their office was really nice!
David Steuber <·············@verizon.net> writes:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> > > Qt is not free under windows.
> > > Even under unix commericial use is costly.
> > > (Otherwise I would have started using it a long time ago)
> > There is actually a free non-commercial-use license that comes with
> > the new Qt book. Closed-source use is costly, but not compared to some
> > of the tools commercial programmers use. I still remember being
> > shocked by how much Rational quoted for Rose when we saw the demo...
>
> Keep in mind that Booch was shopping for a new yacht at the time.
What? You mean you can't get some free yachts like free software??
What is doing the FSF?!?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Cesar Rabak
Subject: Re: A good open-source CL implementation?
Date:
Message-ID: <4040B381.8060003@acm.org>
Nick Patavalis escreveu:
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
>
[snipped]
>
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
>
Given you're considering Python, perhaps you could consider a mixed
approach and do things in Lisp and Python/Tk for the GUI part?
HTH
--
Cesar Rabak
In article <················@acm.org>, Cesar Rabak wrote:
>
> Given you're considering Python, perhaps you could consider a mixed
> approach and do things in Lisp and Python/Tk for the GUI part?
>
And have them communicate though sockets, or something like that... I
thought of this, but no. If I bring python into this, then it will
probably be just python since what will remain for Lisp to cut, will
not be that much to justify mixing the two languages.
/npat
····@efault.net (Nick Patavalis) writes:
> What I'm looking for is a reasonably complete and mature CL
> implementation that has, at least, the following features:
>
> - It is Open Source / Free Software.
>
> - Makes it easy to call C functions and access C objects from within
> LISP code.
>
> - Has support for networking (sockets).
>
> - Has good support for accessing O/S services (for example has
> support for accessing serial ports).
>
> - Has some reasonably-good mutlithreading support.
>
> - Produces "binaries" that run on Linux, Windows, and MACOS.
>
> - Is cross-platform at least at the source code level, including the
> support for networking and threading, and for as much of the other
> O/S support stuff as the semantics allow.
>
> - Provides support for writting *cross-platform* graphical
> applications that use each platform's native GUI toolkit.
Given that Common-Lisp does not specify anything about GUI (or serial
ports or networking for that matter), how do you hope to find a
Common-Lisp implementation to these specification? You'll have to use
external libraries such as a X client/server. Happily, you specified
FFI, so that should not be a problem. You could use sbcl with CLX and
have X client programs running on all your selected operating systems.
> As far as I have looked, there seems to be no implementation that
> covers my checklist. Am I wrong, or should I turn to Python?
Check again sbcl!
And remember, it's free software, meaning, you are FREE to add the features
you want!
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon wrote:
>
> Given that Common-Lisp does not specify anything about GUI (or serial
> ports or networking for that matter), how do you hope to find a
> Common-Lisp implementation to these specification? You'll have to use
> external libraries such as a X client/server.
Yes of course. What I'm looking for is a CL system that provides such
non-standardized libraries. Either as native CL implementations, or as
bindings to foreign-language libraries, or---more likely---as a
combination of these.
> You could use sbcl with CLX and
> have X client programs running on all your selected operating systems.
AFAIK, CLX is a set of bindings for libX11, or something similar. If
I'm not mistaken, then this is far too low-level for my needs. I need
*toolkit* (e.g. GTK, QT) support, or even better higher-level
frameworks (e.g. wxWindows), that abstract the underlying toolkits in
a platform independent environment. Bare-bones libX11 bindings, are
not what I'm looking for.
What I would really *love* to find would be: CL bindings for, say,
GTK, plus CL bindings for the Win32 toolkit, plus a wrapper-framework
*written in CL* that abstract these bindings providing a
cross-platform environment.
If this is not available, then I could easily settle for CL binding to
a foreign-language cross-platform GUI framework, like wxWindows.
Thanks
/npat
Nick Patavalis <····@efault.net> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon wrote:
> >
> > Given that Common-Lisp does not specify anything about GUI (or serial
> > ports or networking for that matter), how do you hope to find a
> > Common-Lisp implementation to these specification? You'll have to use
> > external libraries such as a X client/server.
>
> Yes of course. What I'm looking for is a CL system that provides such
> non-standardized libraries. Either as native CL implementations, or as
> bindings to foreign-language libraries, or---more likely---as a
> combination of these.
I'd try to fight this idea that the common-lisp implementor should
provide non-standardized libraries.
Perhaps it's a good strategy for commercial implementors, so I'll only
speak about free implementations. The only non-Common-Lisp-standard
API that should be provided by implementors is FFI. Once they all
have a good common FFI, the libraries can be developed portably either
in Common-Lisp or in an external language, and be used on all free
implementations. That would multiply the number of available
libraries for each free implementation, and that would free time for
their implementors to improve their implementations. Let's
differentiate on implementation quality and conformity rather than on
libraries.
> > You could use sbcl with CLX and
> > have X client programs running on all your selected operating systems.
>
> AFAIK, CLX is a set of bindings for libX11, or something similar. If
> I'm not mistaken, then this is far too low-level for my needs. I need
> *toolkit* (e.g. GTK, QT) support, or even better higher-level
> frameworks (e.g. wxWindows), that abstract the underlying toolkits in
> a platform independent environment. Bare-bones libX11 bindings, are
> not what I'm looking for.
Of course, I would not use CLX directly either myself. But there are
a range of toolkits. garnet, various CLIM, etc.
> What I would really *love* to find would be: CL bindings for, say,
> GTK, plus CL bindings for the Win32 toolkit, plus a wrapper-framework
> *written in CL* that abstract these bindings providing a
> cross-platform environment.
>
> If this is not available, then I could easily settle for CL binding to
> a foreign-language cross-platform GUI framework, like wxWindows.
There are bindings to Qt for CMUCL.
See also: http://www.cliki.net/Graphics%20Toolkit
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon wrote:
>
> I'd try to fight this idea that the common-lisp implementor should
> provide non-standardized libraries.
>
Ok, libraries do not have to come *from* the implementor. They just
have to be usable by the implementation. There's nothing wrong with
that. As matter of fact the GUI framework example I gave for Python,
is not a part of the official language implementation.
>
> See also: http://www.cliki.net/Graphics%20Toolkit
>
Here's what I can figure out from this, and _please_ correct me if I'm
wrong:
CLIM sounds like a rather ambitious effort to define a versatile LISP
framework for GUI development. This seems to be pretty much what I'm
looking for. Reading from the Overview of the CLIM-II spec:
The Common Lisp Interface Manager (CLIM) is a powerful Lisp-based
programming interface that provides a layered set of portable
facilities for constructing user interfaces. These include basic
windowing, input, output, and graphics services; stream-oriented
input and output extended with facilities such as output recording,
presentations, and context sensitive input; high level ``formatted
output'' facilities; application building facilities; command
processing; and a compositional toolkit similar to those found in
the X world that supports look and feel independence.
CLIM provides an API (applications programmer interface) to user
interface facilities for the Lisp application programmer. CLIM does
not compete with the window system or toolkits of the host machine
(such as Motif or OpenLook), but rather uses their services (to the
extent that it makes sense) to integrate Lisp applications into the
host's window environment. For example, CLIM ``windows'' are mapped
onto one or more host windows, and input and output operations
performed on the CLIM window are ultimately carried out by the host
window system.
The programmer using CLIM is insulated from most of the complexities
of portability, since the Lisp-based application need only deal with
CLIM objects and functions regardless of their operating platform
(that is, the combination of Lisp system, host computer, and host
window environment). CLIM abstracts out many of the concepts common
to all window environments. The programmer is encouraged to think in
terms of these abstractions, rather than in the specific
capabilities of a particular host system. For example, using CLIM,
the programmer can specify the appearance of output in high-level
terms and those high-level descriptions are turned into the
appropriate appearance for the given host. Thus, the application has
the same fundamental interface across multiple environments,
although the details will differ from system to system.
Yes, in theory this is __exactly__ what I'm looking for! The problem
is, there seems to be no reasonably complete, multi-platform, and
mature free CLIM implementation (McCLIM is rather in its
infancy). Also, trying to read between the lines, I see that while
CLIM seemed to achieve some kind of consensus as a "universal" Lisp
GUI framework a couple of years ago, it looks as though the
"enthusiasm" has kind of subsided lately. Am I getting this wrong (I
hope I am)? To put it bluntly, do you think CLIM has a future?
Thanks again
/npat
From: Christopher C. Stacy
Subject: Re: A good open-source CL implementation?
Date:
Message-ID: <uu11aqtif.fsf@news.dtpq.com>
>>>>> On Sun, 29 Feb 2004 00:48:38 +0000 (UTC), Nick Patavalis ("Nick") writes:
Nick> Yes, in theory this is __exactly__ what I'm looking for!
Nick> The problem is, there seems to be no reasonably complete,
Nick> multi-platform, and mature free CLIM implementation
Your problem is only the "free" part, of course.
What is the corresponding solution that meets all your
critera in some other language?
In article <···················@localhost.localdomain>,
Nick Patavalis <····@efault.net> wrote:
<...>
> Yes, in theory this is __exactly__ what I'm looking for! The problem
> is, there seems to be no reasonably complete, multi-platform, and
> mature free CLIM implementation (McCLIM is rather in its
> infancy). Also, trying to read between the lines, I see that while
> CLIM seemed to achieve some kind of consensus as a "universal" Lisp
> GUI framework a couple of years ago, it looks as though the
> "enthusiasm" has kind of subsided lately. Am I getting this wrong (I
> hope I am)? To put it bluntly, do you think CLIM has a future?
McCLIM has a future.
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Given that Common-Lisp does not specify anything about GUI (or serial
> ports or networking for that matter), how do you hope to find a
> Common-Lisp implementation to these specification?
Nonsense. The hope that an implementor has implemented extra-standard
features, of course.
> You'll have to use external libraries such as a X client/server.
Nonsense.
> Happily, you specified FFI, so that should not be a problem. You
> could use sbcl with CLX and have X client programs running on all
> your selected operating systems.
I can't begin to describe just how nonsensical this is.
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 Bourguignon <····@thalassa.informatimago.com> writes:
> And remember, it's free software, meaning, you are FREE to add the features
> you want!
I think this is perhaps the most appropriate definition of free
software ;)
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.