Hi,
and am about to start a new project which needs a GUI. I thought about
Lisp and tk.
At first I started to evaluate newLisp but run into some trouble with
tk. Then I learned that GNU GCL also supports tk but only version 2.3
and above.
Currently I could not find any precompiled binaries for Win32 / NT of
GCL 2.3 or higher. I do not want to install gcc and all that stuff, I
want to do my LISP work.
Anyobody out how knows where to get GCL 2.3 for win32?
Or is there any newLisp guru who can help me with my tk-problem. It
sounds so simple. I want to get some user input form the tk GUI and
use these numbers and strings in LIPS.
But nevertheless I would prefer GCL because it seems to me that it is
more according to the LISP standard.
Thanks in advance,
Johann
········@acm.org
········@acm.org (Johann Murauer) writes:
> Hi,
> and am about to start a new project which needs a GUI. I thought about
> Lisp and tk.
You're request is a bit strange. This are the points which make me
wonder what your problem really is.
- subject is Lisp + TK
I assume you want to have Common Lisp than there are at least three
choices on Windows
- LispWorks (which comes with CAPI + CLIM)
- Cormanlisp which probably is the most windows centric Common Lisp
which you can use to write "native" win32 stuff
- AllegroServe
If you start a new project why don't you even mention this
alternatives and more important why you must use GCL?
>
> But nevertheless I would prefer GCL because it seems to me that it is
> more according to the LISP standard.
Hardly as much as the mentioned alternatives.
Why don't you try them before insisting on GCL?
Regards
Friedrich
On 11 Sep 2002 14:21:09 +0200, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
>········@acm.org (Johann Murauer) writes:
>
>> Hi,
>> and am about to start a new project which needs a GUI. I thought about
>> Lisp and tk.
>You're request is a bit strange. This are the points which make me
>wonder what your problem really is.
Well, I wonder why you think this is strange. My new project is in the
educational area. The student who will use the programm know nothing
about lisp, they are used to "common" GUIs.
The programm is about simulation in the social sciences - based on
cellular automata. I have some LISP source about it and would like to
reuse it. Otherwise I could do it in C++ or similar.
>
>- subject is Lisp + TK
>I assume you want to have Common Lisp than there are at least three
>choices on Windows
>- LispWorks (which comes with CAPI + CLIM)
>- Cormanlisp which probably is the most windows centric Common Lisp
>which you can use to write "native" win32 stuff
>- AllegroServe
>
>If you start a new project why don't you even mention this
>alternatives and more important why you must use GCL?
>
Okay, Cormanlisp look good because of the not so expensive licences.
Only one drawback: currently Linux is not a strict requirement but I
was said I should keep it in mind. From this point of view GNU Common
Lisp or newLisp would be more appropriate
>>
>> But nevertheless I would prefer GCL because it seems to me that it is
>> more according to the LISP standard.
>Hardly as much as the mentioned alternatives.
>
>Why don't you try them before insisting on GCL?
What's bad about GCL?
>
>Regards
>Friedrich
Regards,
Johann
········@acm.org (Johann Murauer) writes:
> On 11 Sep 2002 14:21:09 +0200, Friedrich Dominicus
> <·····@q-software-solutions.com> wrote:
>
> >········@acm.org (Johann Murauer) writes:
> >
> >> Hi,
> >> and am about to start a new project which needs a GUI. I thought about
> >> Lisp and tk.
> >You're request is a bit strange. This are the points which make me
> >wonder what your problem really is.
>
> Well, I wonder why you think this is strange. My new project is in the
> educational area. The student who will use the programm know nothing
> about lisp, they are used to "common" GUIs.
Well that is an argument.
>
> Okay, Cormanlisp look good because of the not so expensive licences.
> Only one drawback: currently Linux is not a strict requirement but I
> was said I should keep it in mind. From this point of view GNU Common
> Lisp or newLisp would be more appropriate
The trial version from LispWorks and too from Allegroserver are
free. I bet both offer extra licences for educational
purpuses. LispWorks comes with CAPI which works on either Windows
and/or Linux.
Well it's not clear about what Lisp you're talking.
>
>
> >>
> >> But nevertheless I would prefer GCL because it seems to me that it is
> >> more according to the LISP standard.
> >Hardly as much as the mentioned alternatives.
> >
> >Why don't you try them before insisting on GCL?
>
> What's bad about GCL?
It's not an ANSI-Common Lisp.
If you want alternatives try out
CLisp and/or CMUCL.
Regards
Friedrich
On Wed, 11 Sep 2002 09:59:35 -0300, Johann Murauer wrote:
n GCL?
>
> What's bad about GCL?
>
>
Hi --
GCL is not ANSI, AFAIK.
So, stick with the others, IMHO. Ars longa, vita brevis, anyways, and
there are 100-plus pages just about I/O on CtTl2..and it's ANSI, so...
;-)
Cheers
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
Johann Murauer wrote:
>
> But nevertheless I would prefer GCL because it seems to me that it is
> more according to the LISP standard.
GCL is not considered to be state of the art by many. The open source
Common Lisp implementations that are mentioned very often nowadays are
CLISP, CMU CL, Steel Bank CL and OpenMCL. However, I don't if they have
tk bindings. I guess they have alternative GUI libraries - can anybody
give some facts about GUI libraries and open source CLs?
You will find links to open source, as well as other Common Lisp
implementations for example at http://www.lisp.org or, well,
http://www.pascalcostanza.de/lisp/guide.html ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Wed, 11 Sep 2002 10:30:54 -0300, Pascal Costanza wrote:
> Johann Murauer wrote:
>>
>>
>> But nevertheless I would prefer GCL because it seems to me that it is
>> more according to the LISP standard.
>
> GCL is not considered to be state of the art by many. The open source
> Common Lisp implementations that are mentioned very often nowadays are
> CLISP, CMU CL, Steel Bank CL and OpenMCL. However, I don't if they have
> tk bindings. I guess they have alternative GUI libraries - can anybody
> give some facts about GUI libraries and open source CLs?
>
>
And...Since we're on the topic, I recently saw a FreeCLIM web page.
Sooo...that *must* mean CLIM is only implementable on proprietary Lisps,
ain't that correct?
So, what is the your favorite way to built a GUI on a Free Software
Common Lisp?
And, by the way, how would you go about using Free/Libre CL and a Java
AWT GUI toolkit? JACOL?
Thank you
Regs
synthespian
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!"
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
From: Timothy Moore
Subject: Re: GUIs with Free/Libre CL [was Re: LISP + TK]
Date:
Message-ID: <aluh3l$3m8$1@216.39.145.192>
synthespian <···········@debian-rs.org> writes:
> And...Since we're on the topic, I recently saw a FreeCLIM web page.
> Sooo...that *must* mean CLIM is only implementable on proprietary Lisps,
> ain't that correct?
I'm not sure if you meant "implemented" instead of "implementable",
but on both counts you're conclusion is not correct. McCLIM
(http://ww.telent.net/cliki/McCLIM) is getting close to being a full
implementation of and runs on several free Lisps (CMUCL, SBCL,
OpenMcl) and one proprietary one (ACL).
Tim
On Fri, 13 Sep 2002 23:33:24 -0300, synthespian <···········@debian-rs.org>
wrote:
> And...Since we're on the topic, I recently saw a FreeCLIM web page.
> Sooo...that *must* mean CLIM is only implementable on proprietary Lisps,
> ain't that correct?
No. McCLIM (formerly known as Free CLIM) happily runs under CMU CL.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
On Sat, 14 Sep 2002 10:37:18 -0300, Paolo Amoroso wrote:
> On Fri, 13 Sep 2002 23:33:24 -0300, synthespian
> <···········@debian-rs.org> wrote:
>
>> And...Since we're on the topic, I recently saw a FreeCLIM web page.
>> Sooo...that *must* mean CLIM is only implementable on proprietary
>> Lisps, ain't that correct?
>
> No. McCLIM (formerly known as Free CLIM) happily runs under CMU CL.
>
>
> Paolo
Well, it causes smoe confusion that there's a Free CLIM page up... Also,
on this web page
http://www.toolinux.com/lininfo/dossiers/salons/abul/themes/freeclim.htm
there's a conference by Robert Strandh. It says that "CLIM signifie Common
Lisp Interface Manager, et d�signe un ensemble de fonctions d�di�es aux
d�veloppement d'interfaces graphiques. Il existe actuellement plusieurs
impl�mentations de CLIM, mais celles-ci sont commerciales et assez ch�res
(ce sont elles qui permettent de maintenir un prix �lev� sur les
distributions commerciales de Common Lisp)."
Thanks for pointing out that McCLIM would be the right choice.
Regs
synthespian
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
From: Timothy Moore
Subject: Re: GUIs with Free/Libre CL [was Re: LISP + TK]
Date:
Message-ID: <am016m$dck$0@216.39.145.192>
synthespian <···········@debian-rs.org> writes:
>
> http://www.toolinux.com/lininfo/dossiers/salons/abul/themes/freeclim.htm
>
> there's a conference by Robert Strandh. It says that "CLIM signifie Common
> Lisp Interface Manager, et d�signe un ensemble de fonctions d�di�es aux
> d�veloppement d'interfaces graphiques. Il existe actuellement plusieurs
> impl�mentations de CLIM, mais celles-ci sont commerciales et assez ch�res
> (ce sont elles qui permettent de maintenir un prix �lev� sur les
> distributions commerciales de Common Lisp)."
>
> Thanks for pointing out that McCLIM would be the right choice.
The rest of that page describes the McCLIM effort, though in July,
2000 it wasn't really called that yet.
Tim
The research group I'm part of uses common lisp almost exclusively and
we've built systems with GUIs on many platforms with many lisp
implementations. While I'm certainly no authority on lisp/GUI solutions,
I'd like to take a stab at answering your post...
While GCL is still an "active" project, I'd discourage you from using it on
Windows because of it's dependence on gcc. This being said, it seems that
you could (most to least difficult):
1 Use tcl/tk sources to build a dll and code your GUI in lisp via a FFI.
2 Use ACL (the free d/load version) and code your GUI with the form builder.
3 Use LispWorks (the free d/load version) and code your GUI with CAPI.
4 Use something like process streams to directly interact with wish.
Choice 1 requires that your lisp have a FFI that you can understand and
successfully work with. If you need to deploy on a variety of platforms
through a variety of lisp implementations, things could get awkward. I'm
sure that the final system would be fast and other people would be
interested in using your dll and interface.
Choices 2&3 lead away from tcl/tk. If you're not compelled to use tcl/tk,
consider using the native GUI construction tools provided by ACL and
LispWorks. If you intend to deploy on Windows, ACL or LispWorks should be
fine. You'll find ACL's form-based interface toolkit more powerful and
easier to use than CAPI so bias towards Windows/ACL if you opt for this
type of choice. If you plan on targeting Linux too, bias towards
LispWorks/CAPI.
Choice 4 is the easiest solution if you're willing to limit your deployment
choices to capable systems/lisp implementations. For example...
ftp://ftp.cis.upenn.edu/pub/kaye/with-wish.tar.Z
is simple, easy to extend, and may be all you need.
Two lisp, implementations come to mind which support tk:
xlisp3.0 or 3.3 by D. Betz, but is not common lisp
ecls, a common lisp version with tk bindings
succes!
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
Scott A Douglass schrieb:
> Choice 4 is the easiest solution if you're willing to limit your
> deployment choices to capable systems/lisp implementations. For example...
>
> ftp://ftp.cis.upenn.edu/pub/kaye/with-wish.tar.Z
> is simple, easy to extend, and may be all you need.
CLISP with with-wish is probably the easiest and best solution.
But I haven't tried it out by myself yet.
http://ftp.gnu.org/pub/gnu/clisp/contrib/with-wish.tar.gz
An interface between CLISP and wish, the Tcl/Tk interpreter.
By Matthias Lindner <········@intellektik.informatik.th-darmstadt.de>
Should work on a default cygwin CLISP.
--
Reini Urban - Programmer - http://inode.at
If someone wants to run lisp2wish under CMUCL, here are a few changes
that should make it work.
#+:CMU (defvar *wish-process*)
(defun OPEN-PROCESS-STREAM (cmd &optional arguments)
#+:CLISP (run-program cmd
:arguments arguments
:input :stream
:output :stream)
#+:LUCID (lcl:run-program cmd
:arguments arguments
:input :stream
:output :stream
:wait NIL)
#+:CMU
(progn
(setf *wish-process*
(ext:run-program cmd arguments
:input :stream
:output :stream
:wait NIL))
(unless *wish-process*
(error "Can't create wish process with command ~S and arguments ~S" cmd arguments))
(make-two-way-stream
(ext:process-output *wish-process*)
(ext:process-input *wish-process*)))
#+:ALLEGRO (run-shell-command
(format NIL "exec ~A~{ \"~A\"~}" cmd arguments)
:input :stream
:output :stream
:wait NIL)
#+:KCL (run-program cmd arguments))
(defun CLOSE-PROCESS-STREAM (stream)
#+(or :CMU :ALLEGRO) (declare (ignore stream))
#+:CMU (ext:process-wait *wish-process*)
#-(or :KCL :CMU) (close stream)
#+:KCL (close-program-stream stream)
#+:ALLEGRO (sys:os-wait))
Note that because of using *wish-process* special variable to hold the
CMU process handle, you can only have one wish process at a time.
Someone who wanted more than one wish process at a time could rewrite
the code to pass around the process handle instead of the stream or
use an alist associating the stream with the process handle.
--
Fred Gilham ······@csl.sri.com | See the lambs and the lions playin?
I join in and I drink the music. Holiness is the air I'm breathin'.
My faithful heroes break the bread and answer all of my questions.
Not to mention what the streets are made of. My heart's held hostage
by this love. -- Chris Rice, DEEP ENOUGH TO DREAM
Scott A Douglass <····@andrew.cmu.edu> writes:
> [...] This being said, it seems that you could (most to least
> difficult):
>
> [...]
> 4 Use something like process streams to directly interact with wish.
>
> [...]
>
> Choice 4 is the easiest solution if you're willing to limit your
> deployment choices to capable systems/lisp implementations. For
> example...
>
> ftp://ftp.cis.upenn.edu/pub/kaye/with-wish.tar.Z
>
> is simple, easy to extend, and may be all you need.
Are there any other systems or Lisp implementations with which you are
familiar that have "process streams"? In particular, I'm looking for
something not necessarily associated with wish.
Damien Kick <······@email.mot.com> wrote in message
> Are there any other systems or Lisp implementations with which you are
> familiar that have "process streams"? In particular, I'm looking for
> something not necessarily associated with wish.
I am not the original poster, but I believe with-wish uses the standard
make-two-way-stream function, atleast the #+clisp code did when I used it last.