Hi,
I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
to the Tk toolkit, offering a portable GUI for Common Lisp. It
is portable not only between different operation systems as well
as Lisp implementations. In contrary to other Tk bindings so far,
Ltk is a complete lispy wrapper - that is, no Tcl/Tk knowledge
is required. While not completely finished, (thus the 0.8 version
number) it is quite stable and usable.
You can find the package, its documentation and of course,
some screenshots here:
http://www.peter-herth.de/ltk/
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth <·····@netcologne.de> writes:
> Hi,
>
> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
> to the Tk toolkit, offering a portable GUI for Common Lisp. It
> is portable not only between different operation systems as well
> as Lisp implementations. In contrary to other Tk bindings so far,
> Ltk is a complete lispy wrapper - that is, no Tcl/Tk knowledge
> is required. While not completely finished, (thus the 0.8 version
> number) it is quite stable and usable.
>
> You can find the package, its documentation and of course,
> some screenshots here:
>
> http://www.peter-herth.de/ltk/
Cool. I see in the "Under the hood" section of your docs that Lisp
communicates to Tk via as stream. Just out of curiosity, is this how
other language's bindings to Tk (such as Perl's and Python's) work?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
>>>>> "Peter" == Peter Seibel <·····@javamonkey.com> writes:
Peter> Cool. I see in the "Under the hood" section of your docs that Lisp
Peter> communicates to Tk via as stream. Just out of curiosity, is this how
Peter> other language's bindings to Tk (such as Perl's and Python's) work?
STk, a scheme interface to Tk, builds directly on Tk, and integrates
pretty closely. I think it's more than just "using" Tk as a library.
Haven't used this in a long time, though. But the Tk widgets were all
very nicely integrated into scheme, including callbacks.
Ray
Peter Seibel wrote:
> Cool. I see in the "Under the hood" section of your docs that Lisp
> communicates to Tk via as stream. Just out of curiosity, is this how
> other language's bindings to Tk (such as Perl's and Python's) work?
I am not too familiar with their implementations, but I think
Python started its Tk support in a similiar way and only later
directly linked to the Tk libraries.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth wrote:
> Peter Seibel wrote:
>
>>Cool. I see in the "Under the hood" section of your docs that Lisp
>>communicates to Tk via as stream. Just out of curiosity, is this how
>>other language's bindings to Tk (such as Perl's and Python's) work?
>
> I am not too familiar with their implementations, but I think
> Python started its Tk support in a similiar way and only later
> directly linked to the Tk libraries.
...and this is probably also an option for LTK in the long run, right?
By the way, I have seen Peter's demo of a pre-release version at the
last cl-lc meeting, and it was quite impressive, with lots of very
Lispish little features (debugging on the fly, etc.)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
> ...and this is probably also an option for LTK in the long run, right?
Hehe, yes, I have considered that also. The main advantage of this
would be some speed gain, especially if you wanted to do pixel
manipulations of bitmaps displayed (for most other uses, the stream-based
version should be fast enough). If we do not want to sacrifice portability,
an UFFI-based version might be neat. As soon one adds call-back support
to UFFI I might give it a try...
> By the way, I have seen Peter's demo of a pre-release version at the
> last cl-lc meeting, and it was quite impressive, with lots of very
> Lispish little features (debugging on the fly, etc.)
Thank you :)
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth wrote:
> Hi,
>
> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
> to the Tk toolkit, offering a portable GUI for Common Lisp.
Does it run under LispWorks?
Cheers
--
Marco
Marco Antoniotti wrote:
> Peter Herth wrote:
>
>> Hi,
>>
>> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
>> to the Tk toolkit, offering a portable GUI for Common Lisp.
>
> Does it run under LispWorks?
Yes. The presentation Peter gave was under LispWorks for Macintosh.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Marco Antoniotti wrote:
> Does it run under LispWorks?
Yes. Ltk currently runs under Allegro (thanks to Martin Elster for the
patch), CMUCL, LispWorks, and SBCL. I tested it under Linux and Mac OS X,
but in principle there are no reasons to prevent it running under other
operating systems. There is only a single non-portable function in Ltk,
it is do-excecute where the subprocess for Tk is started. So if your
Lisp is missing in the list above, please add it and send me the patch :).
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth wrote:
> Marco Antoniotti wrote:
>
>
>>Does it run under LispWorks?
>
>
> Yes. Ltk currently runs under Allegro (thanks to Martin Elster for the
> patch), CMUCL, LispWorks, and SBCL. I tested it under Linux and Mac OS X,
> but in principle there are no reasons to prevent it running under other
> operating systems. There is only a single non-portable function in Ltk,
> it is do-excecute where the subprocess for Tk is started. So if your
> Lisp is missing in the list above, please add it and send me the patch :).
>
That is good news. Do you use UFFI?
Cheers
--
Marco
Marco Antoniotti wrote:
> That is good news. Do you use UFFI?
No. Which makes Tk suitiable for an easy and portable solution, is, that
it comes with the program wish. This is the shell which executes tcl/tk
programs, but if no script is given, it reads tcl commands via
stdin and responds to stdout. So a subprocess is started running wish
(this is the single function that needs ported to different Lisps) and
the stdin/stdout of this subprocess is turned into a Lisp stream. From
there on we can do all communication with format/read.
(there is some comprehensive documentation on my Ltk page:
http://www.peter-herth.de/ltk/ )
Peter
--
Peter Herthhttp://www.peter-herth.de/ltk/
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Besides the Ltk package for creating GUI applications, the tarball
of Ltk additionally contains ltk-remote. Ltk-remote is a package
to create networked gui applications. That is, your application is
run as a server process, and any number of clients can connect to
it and run the GUI application using a client software (remote.tcl).
As Ltk uses streams to talk to the GUI, it was easy to make it
networkable. As it requires some more nonportable stuff (sockets,
threads), ltk-remote is a little bit less portable, but support
for CMUCL, SBCL and Lispworks is there.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth wrote:
> Hi,
>
> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
> to the Tk toolkit, offering a portable GUI for Common Lisp. It
> is portable not only between different operation systems as well
> as Lisp implementations. In contrary to other Tk bindings so far,
> Ltk is a complete lispy wrapper - that is, no Tcl/Tk knowledge
> is required. While not completely finished, (thus the 0.8 version
> number) it is quite stable and usable.
>
> You can find the package, its documentation and of course,
> some screenshots here:
>
> http://www.peter-herth.de/ltk/
Cells/Tk! I'll try give it a go.
btw, the Cello code has some callback extensions to fill in the UFFI
gap, but not much: just AllegroCL and Lispworks. But it's a start if the
community wants to start an UFFI Callbacks mini-project. Now that
CMUCL/SBCL handle those, maybe KR would go for adding callbacls to UFFI.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
I tried it and it works quite well with Clisp and SBCL on Mac OS X. I
had to do a minor modification to the call to run-program. Just made
that ext:run-program and I think a couple of functions were getting
commented out by #| |#. I uncommented those. It would be a cinch to
add openmcl to this.
Its really nice to use Tk in a Lispy way.
Thanks for creating it.
OCID wrote:
> I tried it and it works quite well with Clisp and SBCL on Mac OS X. I
> had to do a minor modification to the call to run-program. Just made
> that ext:run-program and I think a couple of functions were getting
> commented out by #| |#. I uncommented those. It would be a cinch to
> add openmcl to this.
You mean the run-program entry for CLisp ? I changed it to ext:run-program.
The commented code are functions that are in building but not yet used, but
in the next mayor release they will be used.
So the list of supported Lisps now is: Allegro, CLisp, CMUCL, LispWorks,
and SBCL.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth <·····@netcologne.de> wrote:
+---------------
| I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
| to the Tk toolkit, offering a portable GUI for Common Lisp...
...
| http://www.peter-herth.de/ltk/
+---------------
Looks neat! But also see:
<URL:http://www.cliki.net/Lisp-Tk>
<URL:http://www.cliki.net/lisp2wish>
<URL:http://www.cliki.net/cl-gtk>
<URL:http://www.cliki.net/clg>
<URL:http://www.cliki.net/lgtk>
Some of these have BSD/MIT-style licenses, if the GPL of "Ltk"
doesn't work for you...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Looks neat! But also see:
>
> <URL:http://www.cliki.net/Lisp-Tk>
> <URL:http://www.cliki.net/lisp2wish>
> <URL:http://www.cliki.net/cl-gtk>
> <URL:http://www.cliki.net/clg>
> <URL:http://www.cliki.net/lgtk>
Yes I am aware of all of these, having tried out all of them before
I started to write Ltk. The first two gave me the idea how easy it
is, to use Tk from Lisp. But they just contain code to communicate
with Tk, but they do not wrap the library itself. So you have to
write Tk code to create your GUIs and not Lisp code. That was the
reason for Ltk so you can do the GUI in Lisp and not only from Lisp...
The latter three are bindings to Gtk, wich is a very nice toolkit.
From those I think, Mario's lgtk is the most promising. As they
directly link to Lisp, they should be somewhat faster than Ltk,
but this linking limits portability.
> Some of these have BSD/MIT-style licenses, if the GPL of "Ltk"
> doesn't work for you...
I have to stress that Ltk is LGPL *not* GPL. That means you are
free to use it even in commercial/closed source programs. The
only restriction is, that if you change the Ltk code itself, you
may not distribute it without publishing the source of your changes,
but all application code using Ltk can be as closed source as
you want :).
By choosing the LGPL as license for the Ltk code I do not want
to limit the use of Ltk in any way, but only ensure, that every
change to Ltk itself gets back to the Lisp community.
If there are any problems with the Ltk license, please point
them out. I do not want license problems to prevent its usage.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Rob Warnock wrote:
| > Some of these have BSD/MIT-style licenses, if the GPL of "Ltk"
| > doesn't work for you...
|
| I have to stress that Ltk is LGPL *not* GPL.
+---------------
Oops! Correction noted.
+---------------
| That means you are free to use it even in commercial/closed source
| programs. The only restriction is, that if you change the Ltk code
| itself, you may not distribute it without publishing the source of
| your changes, but all application code using Ltk can be as closed
| source as you want :).
| By choosing the LGPL as license for the Ltk code I do not want
| to limit the use of Ltk in any way, but only ensure, that every
| change to Ltk itself gets back to the Lisp community.
| If there are any problems with the Ltk license, please point
| them out. I do not want license problems to prevent its usage.
+---------------
Apologies. I didn't mean to be critical. Your package looks like
a very nice contribution to the state of the art, and is appreciated.
But it's not clear that the LGPL "does the right thing" when applied
to Lisp code, which is why Franz invented the LLGPL:
<URL:http://opensource.franz.com/preamble.html>
It's not even 100% certain (IMHO) that the LLGPL doesn't violate the
LGPL, since provision #10 of the LGPL says:
... You may not impose any further restrictions on the recipients'
exercise of the rights granted herein. ...
which the LLGPL "preamble" perhaps violates by making its "certain
clarifications" of the LGPL (specifically, those affecting #5 & #6).
Still, the LLGPL is probably better than the LGPL for Lisp code, and
a number of packages now use it, so if you could see your way clear
to using it instead of the LGPL, some of us would probably feel more
comfortable.
Thanks again for the nice library...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Apologies. I didn't mean to be critical. Your package looks like
No need to apologize. I answered a little bit in length to prevent
either a possible misunderstandig and to make sure *I* haven't
messed something up with the license. :)
> a very nice contribution to the state of the art, and is appreciated.
> But it's not clear that the LGPL "does the right thing" when applied
> to Lisp code, which is why Franz invented the LLGPL:
>
> <URL:http://opensource.franz.com/preamble.html>
>
> It's not even 100% certain (IMHO) that the LLGPL doesn't violate the
> LGPL, since provision #10 of the LGPL says:
>
> ... You may not impose any further restrictions on the recipients'
> exercise of the rights granted herein. ...
>
> which the LLGPL "preamble" perhaps violates by making its "certain
> clarifications" of the LGPL (specifically, those affecting #5 & #6).
Hmm, IANAL but while you may not impose those restrictions on software
under the LGPL, what the preamble does is create an entirely new license
which shares some common text parts with the LGPL. So unless that
creates copyright problems with the authors of the LGPL, this should
not concern users of this license. However I think it would be more
clean and simple, if Franz would write a single new license file
based on their preamble and the LGPL (though they have probably
good reasons to do it the way they do now :).
> Still, the LLGPL is probably better than the LGPL for Lisp code, and
> a number of packages now use it, so if you could see your way clear
> to using it instead of the LGPL, some of us would probably feel more
> comfortable.
I just uploaded a new version of Ltk with the LLGPL license.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Rob Warnock wrote:
| > which the LLGPL "preamble" perhaps violates by making its "certain
| > clarifications" of the LGPL (specifically, those affecting #5 & #6).
|
| Hmm, IANAL but while you may not impose those restrictions on software
| under the LGPL, what the preamble does is create an entirely new license...
+---------------
Hmmm... Good point. (Note: IANAL, either.)
+---------------
| I just uploaded a new version of Ltk with the LLGPL license.
+---------------
Thanks!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Peter Herth <·····@netcologne.de> wrote
> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
I just tried it and encountered a problem: running (test), Lispworks
complained that
Error: The class #<STANDARD-CLASS MENUBUTTON 21515764> cannot
be finalized because the following superclass is not defined:
#<FORWARD-REFERENCED-CLASS VARIABLE 215157C4>.
I'll try to take a look at it in the morning; I posted it here in case
it's a well-known bug.
(It's Lispworks Personal Edition 4.3.6 and Tcl 8.4.6.0 running under
Windows XP, btw.)
Peter Lewerin wrote:
> I just tried it and encountered a problem: running (test), Lispworks
> complained that
>
> Error: The class #<STANDARD-CLASS MENUBUTTON 21515764> cannot
> be finalized because the following superclass is not defined:
> #<FORWARD-REFERENCED-CLASS VARIABLE 215157C4>.
>
> I'll try to take a look at it in the morning; I posted it here in case
> it's a well-known bug.
>
> (It's Lispworks Personal Edition 4.3.6 and Tcl 8.4.6.0 running under
> Windows XP, btw.)
My CLISP started to swear on menubutton's VARIABLE too, and I have just
removed the bloody VARIABLE from the class definition. Worked alright.
line 559:
(defclass menubutton(widget)
((text :accessor text :initarg :text)
(command :accessor command :initarg :command :initform nil)))
Hope it wasnt too rude,
Sergey
Peter Lewerin wrote:
> I just tried it and encountered a problem: running (test), Lispworks
> complained that
>
> Error: The class #<STANDARD-CLASS MENUBUTTON 21515764> cannot
> be finalized because the following superclass is not defined:
> #<FORWARD-REFERENCED-CLASS VARIABLE 215157C4>.
>
> I'll try to take a look at it in the morning; I posted it here in case
> it's a well-known bug.
Sorry, that was me. I have of course not stopped working at the code, but
at the wrong point choose to upload an untested version. I think I have
fixed that bug and uploaded the bugfix. Thank you for pointing to it.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
> Sorry, that was me. I have of course not stopped working at the code,
Naughty :-)
Works like a charm now. I'm going to dig deeper into this as time allows.
(BTW: I'm currently working on a limited implementation of Lisp in Tcl.)
Peter Lewerin <·············@swipnet.se> wrote:
+---------------
| (BTW: I'm currently working on a limited implementation of Lisp in Tcl.)
+---------------
You might have an easier time of it working in the other direction... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote
> Peter Lewerin <·············@swipnet.se> wrote:
> | (BTW: I'm currently working on a limited implementation of Lisp in Tcl.)
> You might have an easier time of it working in the other direction... ;-}
That's most likely true, but it isn't what I want to do.
Actually, it's not that hard to implement basic Lisp functionality in
Tcl. Doing it in C would be a lot harder.
Peter Herth wrote:
> Hi,
>
> I am proud to announce Ltk version 0.8. Ltk is a Lisp binding
> to the Tk toolkit, offering a portable GUI for Common Lisp. It
> is portable not only between different operation systems as well
> as Lisp implementations. In contrary to other Tk bindings so far,
> Ltk is a complete lispy wrapper - that is, no Tcl/Tk knowledge
> is required. While not completely finished, (thus the 0.8 version
> number) it is quite stable and usable.
>
> You can find the package, its documentation and of course,
> some screenshots here:
>
> http://www.peter-herth.de/ltk/
(1) Will this be moving to common-lisp.net?
(2) I got it to work a little on WinXP under Allegro 6.2, adding in
do-execute:
#+allegro (excl:run-shell-command fullstring
:input :stream
:output :stream
:wait nil)
Anyone see a problem with that? When I run hello-1 the window appears,
but (all but one time) is completely unresponsive. One time I clicked
away happily a few times, the messages appeared in the console, but then
it stopped working after a sequence of bouncing to the Lisp console and
back. Not sure of the exact sequence and have not been able to recreate.
Closing the window leads to windows telling me the program is
unresponsive and I have to whack it.
Anyone have better luck on win32 with allegrocl?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> (1) Will this be moving to common-lisp.net?
Yes, why not :).
> (2) I got it to work a little on WinXP under Allegro 6.2, adding in
> do-execute:
>
> #+allegro (excl:run-shell-command fullstring
> :input :stream
> :output :stream
> :wait nil)
Another Ltk user sent me the following entry for do-execute:
#+:allegro (let ((proc (excl:run-shell-command
(apply #'vector program program args)
:input :stream :output :stream :wait wt)))
(unless proc
(error "Cannot create process."))
proc
)
I don't know whether it makes a difference to yours...
> Anyone see a problem with that? When I run hello-1 the window appears,
> but (all but one time) is completely unresponsive. One time I clicked
> away happily a few times, the messages appeared in the console, but then
> it stopped working after a sequence of bouncing to the Lisp console and
> back. Not sure of the exact sequence and have not been able to recreate.
> Closing the window leads to windows telling me the program is
> unresponsive and I have to whack it.
>
> Anyone have better luck on win32 with allegrocl?
Sorry I can provide not much help here, having neither Win nor Allegro.
I hope other Ltk users can help out here. The only thing that might
give information may be the debug output of Ltk on the Lisp console.
Everything sent to Tk and read from it is echoed there. When a button
is pressed, a list containing he button name is sent back to Lisp and
should be read. Besides some technical issues of Windows itself it could
be that read belches somehow on the strings sent by Tk.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth wrote:
> Kenny Tilton wrote:
>
>
>>(1) Will this be moving to common-lisp.net?
>
>
> Yes, why not :).
>
>
>>(2) I got it to work a little on WinXP under Allegro 6.2, adding in
>>do-execute:
>>
>> #+allegro (excl:run-shell-command fullstring
>> :input :stream
>> :output :stream
>> :wait nil)
>
>
> Another Ltk user sent me the following entry for do-execute:
> #+:allegro (let ((proc (excl:run-shell-command
> (apply #'vector program program args)
> :input :stream :output :stream :wait wt)))
> (unless proc
> (error "Cannot create process."))
> proc
> )
> I don't know whether it makes a difference to yours...
Interesting error from that: "On Windows a string is required...."
Anyway, I did get a few more successful runs, but not reliably. But i
found a workaround which probably points at a fix. I happen to use the
ACL project manager, and execute code via the project manager "run
project" command which I set up to execute hello-1. This works
differently than running the same function from the listener command
line. For one thing, when using "run project", output gets directed to
the ACL console window instead of the listener window. IIUC, the Lisp
console is a separate process. Anyway, running hello-1 from the listener
works, so I probably just have to set things up (in ways not yet
known) so the run project command will work.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Anyway, I did get a few more successful runs, but not reliably. But i
> found a workaround which probably points at a fix. I happen to use the
> ACL project manager, and execute code via the project manager "run
> project" command which I set up to execute hello-1. This works
> differently than running the same function from the listener command
> line. For one thing, when using "run project", output gets directed to
> the ACL console window instead of the listener window. IIUC, the Lisp
> console is a separate process. Anyway, running hello-1 from the listener
> works, so I probably just have to set things up (in ways not yet
> known) so the run project command will work.
I am glad to hear that there is a way to make it run for you. As
Ltk starts a subprocess to run Tk and communicates with a pipe
with this process, it may be influcenced by how Allegro handles
these processes. For example, ltk-remote doesn't run well under
CMUCL when started from SLIME, starting it in a separate CMUCL
session works fine, while SBCL has no problems even in co-existance
with SLIME.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
From: Juan Jose Garcia Ripoll
Subject: Patches for Ltk under (unstable) ECL
Date:
Message-ID: <2j2majFsc010U1@uni-berlin.de>
If somebody wants to experiment with Ltk under the latest version of ECL
(retrieved from CVS):
--- ltk.lisp 2004-06-13 10:59:10.000000000 +0200
+++ ltk.lisp 2004-06-13 10:59:17.000000000 +0200
@@ -271,6 +271,7 @@
(error "Cannot create process.")) proc
)
+ #+:ecl(ext:run-program program args :input :stream :output :stream
:error :output)
))
Regards
Juanjo
On Thu, 10 Jun 2004 20:04:30 +0200, Peter Herth wrote:
> You can find the package, its documentation and of course,
> some screenshots here:
>
> http://www.peter-herth.de/ltk/
Well, this seems to be a breakthrough! But I still cannot run it under XP
and CLisp:
[1]> (compile-file "ltk")
*** - OPEN: file #P"C:\\Lisp-programs\\ltk.lisp" does not exist
Break 1 [2]> (compile-file "ltk")
Compiling file C:\Lisp-programs\ltk.lisp ...
WARNING in DO-EXECUTE in lines 231..274 :
variable WT is not used.
Misspelled or missing IGNORE declaration?
Wrote file C:\Lisp-programs\ltk.fas
0 errors, 1 warning
#P"C:\\Lisp-programs\\ltk.fas" ;
1 ;
NIL
Break 1 [2]> (load "ltk")
*** - Win32 error 5 (ERROR_ACCESS_DENIED): Access is denied.
Break 2 [3]>
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> [1]> (compile-file "ltk")
>
> *** - OPEN: file #P"C:\\Lisp-programs\\ltk.lisp" does not exist
> Break 1 [2]> (compile-file "ltk")
>
> Compiling file C:\Lisp-programs\ltk.lisp ...
> WARNING in DO-EXECUTE in lines 231..274 :
> variable WT is not used.
> Misspelled or missing IGNORE declaration?
The clisp entry did not use the wt parameter, I corrected that
>
> Wrote file C:\Lisp-programs\ltk.fas
> 0 errors, 1 warning
> #P"C:\\Lisp-programs\\ltk.fas" ;
> 1 ;
> NIL
> Break 1 [2]> (load "ltk")
>
> *** - Win32 error 5 (ERROR_ACCESS_DENIED): Access is denied.
> Break 2 [3]>
>
It looks as if CLisp under Windows has some problem with the paths.
Did you try (compile-file "c:\Lisp-programs\ltk.lisp") and
(load-file "c:\Lisp-programs\ltk") respectively ? (you may need
to use double backslashes.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
> It looks as if CLisp under Windows has some problem with the paths.
> Did you try (compile-file "c:\Lisp-programs\ltk.lisp") and
> (load-file "c:\Lisp-programs\ltk") respectively ? (you may need
> to use double backslashes.
Actually, first I did not extract the tgz file ("idiots are geniusses").
Then I did and I get the files
11.06.2004 13:39 26.430 lgpl.txt
11.06.2004 13:38 343 license.txt
05.06.2004 17:38 400 ltk-remote.asd
11.06.2004 13:55 7.503 ltk-remote.lisp
05.06.2004 17:38 329 ltk.asd
12.06.2004 01:31 52.995 ltk.lisp
11.06.2004 10:29 147.064 ltkdoc.pdf
11.06.2004 13:57 1.330 remote.tcl
8 Datei(en) 236.394 Bytes
2 Verzeichnis(se), 64.122.167.296 Bytes frei
Then I could compile the file (the .fas file was generated). Using full
path names with "load" does not help:
Break 2 [3]> (load-file "ltk")
** - Continuable Error
EVAL: undefined function LOAD-FILE
If you continue (by typing 'continue'): Retry
The following restarts are also available:
STORE-VALUE :R1 You may input a new value for (FDEFINITION 'LOAD-FILE).
USE-VALUE :R2 You may input a value to be used instead of (FDEFINITION
'LOAD-FILE).
Break 3 [4]> (load "c:\\Lisp-programs\\ltk")
** - Continuable Error
Win32 error 5 (ERROR_ACCESS_DENIED): Access is denied.
If you continue (by typing 'continue'): Retry
The following restarts are also available:
STORE-VALUE :R1 You may input a new value for (FDEFINITION 'LOAD-FILE).
USE-VALUE :R2 You may input a value to be used instead of (FDEFINITION
'LOAD-FILE).
Break 4 [5]>
TIA,
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> Break 2 [3]> (load-file "ltk")
Ah sorry, that was my error, it should just be (load "ltk") of course...
Besides, you do not need to compile it before usage, so a (load "ltk")
should be ok any way.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
> Ah sorry, that was my error, it should just be (load "ltk") of course...
> Besides, you do not need to compile it before usage, so a (load "ltk")
> should be ok any way.
But as you could see, I could not load it:
[1]> (load "ltk")
*** - Win32 error 5 (ERROR_ACCESS_DENIED): Access is denied.
Break 1 [2]>
What do I load? ltk.lisp?
When I load ltk.lisp, it maybe works and the file is loaded. I am not
sure. Then I get the next error message using (use-package 'ltk) stating
that there is some name conflict, etc.
Well, it seems I would have to understand the internals of Lisp and
Clisp to some depth to use your package (if the description does not fit
exactly, I am lost).
Thank you anyway.
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> What do I load? ltk.lisp?
Yes, ltk.lisp. You may need to give the full name as: (load "ltk.lisp")
of, if that does not work, the full pathname.
>
> When I load ltk.lisp, it maybe works and the file is loaded. I am not
> sure. Then I get the next error message using (use-package 'ltk) stating
> that there is some name conflict, etc.
if the load succeeds, try:
(use-package :ltk)
(test)
Then the test window should come up. If not, please mail me the
error message created by CLisp.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
On Sat, 12 Jun 2004 21:29:20 +0200, Peter Herth wrote:
> jblazi wrote:
>
>> What do I load? ltk.lisp?
>
> Yes, ltk.lisp. You may need to give the full name as: (load "ltk.lisp")
> of, if that does not work, the full pathname.
>
>>
>> When I load ltk.lisp, it maybe works and the file is loaded. I am not
>> sure. Then I get the next error message using (use-package 'ltk) stating
>> that there is some name conflict, etc.
>
> if the load succeeds, try:
> (use-package :ltk)
> (test)
Here is the error message (it is the same as with 'ltk):
Break 5 [6]> (use-package :ltk)
** - Continuable Error
1 name conflicts while executing USE-PACKAGE of (#<PACKAGE LTK>) into package #<
PACKAGE COMMON-LISP-USER>.
If you continue (by typing 'continue'): You may choose for every conflict in fav
our of which symbol to resolve it.
The following restarts are also available:
CONTINUE :R1 Retry
STORE-VALUE :R2 You may input a new value for (FDEFINITION 'TEST).
USE-VALUE :R3 You may input a value to be used instead of (FDEFINITION
'TEST).
CONTINUE :R4 Retry
STORE-VALUE :R5 You may input a new value for (FDEFINITION 'TEST).
USE-VALUE :R6 You may input a value to be used instead of (FDEFINITION
'TEST).
Break 6 [7]> (test)
Actually, (test) does not work either (undefined function).
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> Here is the error message (it is the same as with 'ltk):
>
> Break 5 [6]> (use-package :ltk)
>
> ** - Continuable Error
> 1 name conflicts while executing USE-PACKAGE of (#<PACKAGE LTK>) into
> package #< PACKAGE COMMON-LISP-USER>.
> If you continue (by typing 'continue'): You may choose for every conflict
> in fav our of which symbol to resolve it.
> The following restarts are also available:
> CONTINUE :R1 Retry
> STORE-VALUE :R2 You may input a new value for (FDEFINITION 'TEST).
> USE-VALUE :R3 You may input a value to be used instead of
> (FDEFINITION
> 'TEST).
> CONTINUE :R4 Retry
> STORE-VALUE :R5 You may input a new value for (FDEFINITION 'TEST).
> USE-VALUE :R6 You may input a value to be used instead of
> (FDEFINITION
> 'TEST).
>
> Break 6 [7]> (test)
It looks as if the name of the function "test" conflicts with a symbol
in the common-lisp-user package. That is a bit strange, but test is
perhaps a not so good choice for the name. I will rename it in the
next release of Ltk. Until then, try to skip the (use-package :ltk)
step and type (ltk:test). If you do not "use" the package, its symbols
are note inserted in the common-lisp-user package but you can access
all of them by prefixing them with ltk: to designate the ltk package.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
We are getting there :). The test function runs, but you have got the bugged
Ltk version. Please download it again, as I fixed problem with the testing
function, then it should work.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
On Sat, 12 Jun 2004 22:39:40 +0200, Peter Herth wrote:
>
> We are getting there :). The test function runs, but you have got the bugged
> Ltk version. Please download it again, as I fixed problem with the testing
> function, then it should work.
Very nice, thx. Now it works! After 30 or more years
of Lisp I can write "Hullo world" on the screen! But seriously: This is a
real Lisp revolution as your port is easy to use and as everybody knows
Tk, so Lisp becomes a bit less exotic and much, much more usable.
A final question: Why did you take Tk instead of wxWidgets? Was it easier
to do the port?
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> Very nice, thx. Now it works! After 30 or more years
> of Lisp I can write "Hullo world" on the screen! But seriously: This is a
> real Lisp revolution as your port is easy to use and as everybody knows
> Tk, so Lisp becomes a bit less exotic and much, much more usable.
Glad to hear that :). I had the same feeling about "Hello world" before
I started writing Ltk.
> A final question: Why did you take Tk instead of wxWidgets? Was it easier
> to do the port?
Yes, the mayor reason for selecting Tk was, that I do not have to do
a binary link to a library. That way, it would be quite non-portable.
What I do is to start Tk as a subprocess to Lisp and send Tk commands
as text via a stream. You can see the commands sent and the responses
of Tk on the Lisp console. So the only nonportable function is opening
the subprocess, but fortunately all Lisps have similiar functions for it.
Once I have the stream to talk to the subprocess, I can use the standard
Lisp IO functions from there on and thus the whole rest of the code is
absolutely portable.
An additional helping point is, that on many operating systems, Tk is
preinstalled, so the Ltk user just needs to load ltk.lisp to start
using it, no complex installation required.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
··········@ozemail.com.au wrote:
> debugger invoked on a TYPE-ERROR in thread 1968:
> The value NAME is not of type LIST.
>
A bug in Ltk. I just uploaded a fixed version.
Thanks for reporting it.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth hat geschrieben:
> ··········@ozemail.com.au wrote:
>
> > debugger invoked on a TYPE-ERROR in thread 1968:
> > The value NAME is not of type LIST.
> >
>
> A bug in Ltk. I just uploaded a fixed version.
> Thanks for reporting it.
>
That works nice with cmucl and with clisp with a t instead of wt
in line 254.
Thanks a lot for your work!
Philippe
--
Philippe Brochard <·····@free.fr>
http://hocwp.free.fr
-=-= http://www.gnu.org/home.fr.html =-=-
Peter Herth <·····@netcologne.de> wrote:
+---------------
| ··········@ozemail.com.au wrote:
| > debugger invoked on a TYPE-ERROR in thread 1968:
| > The value NAME is not of type LIST.
|
| A bug in Ltk. I just uploaded a fixed version.
| Thanks for reporting it.
+---------------
Aha! I was having the same problem under CMUCL/FreeBSD, now also fixed.
Thanks!
A few small suggestions:
- The interaction between DO-EXECUTE, START-W, *W*, the callers of
START-W, and the users of *W* seems a bit awkward. Since you already
have DO-EXECUTE heavily conditionalized for various operating systems,
it might be better to simply eliminate START-W altogether, pull the
pathname for "wish" out into a global constant to make it easier to
conditionalize for local variations [see next item], and just have
the two former callers of START-W call DO-EXECUTE directly. And perhaps
the same for the args to the "wish" process (in case somebody wants to
start "wish" with a different colormap or something). The result might
look something like this:
(defconstant +wish-pathname+
#+freebsd "wish8.3" ; or 8.4, whatever
#+(and sbcl (not freebsd)) "/usr/bin/wish"
#-(or sbcl freebsd) "wish")
(defconstant +wish-args+ '("-name" "LTK"))
...
(defmacro with-ltk (&rest body)
`(progn
(setf *w* (do-execute +wish-pathname+ +wish-args+))
,@body
(mainloop)))
- Your doc file suggests:
Note: on FreeBSD wish resides in /usr/local/bin/wish8.4 for
Tcl/Tk version 8.4. You either have to modify the path to wish
in ltk.lisp or create a link called wish to the executable
(like: cd /usr/local/bin;ln -s /usr/local/bin/wish8.4 wish).
Actually, on FreeBSD there is *already* a program named "wish", which
when run, says this:
% wish
In FreeBSD, wish is named with a version number. This is
because different versions of wish are not compatible with
each other and they can not all be called "wish"! You may
need multiple versions installed because a given port may
depend on a specific version.
On your system, wish is installed under at least the following
names:
wish8.3
%
So you probably don't want to overwrite that program. ;-}
- On Common Lisps which provide threads (CMUCL, SBCL, others), it would
be nice if LTK:MAINLOOP ran in a separate thread, so that one still
had access to the main REPL, at least while debugging. [Time permitting,
I'll try to hack something up to work under CMUCL as a base case...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> A few small suggestions:
>
> - The interaction between DO-EXECUTE, START-W, *W*, the callers of
> START-W, and the users of *W* seems a bit awkward. Since you already
> have DO-EXECUTE heavily conditionalized for various operating systems,
> it might be better to simply eliminate START-W altogether, pull the
> pathname for "wish" out into a global constant to make it easier to
> conditionalize for local variations [see next item], and just have
> the two former callers of START-W call DO-EXECUTE directly. And perhaps
> the same for the args to the "wish" process (in case somebody wants to
> start "wish" with a different colormap or something). The result might
> look something like this:
>
> (defconstant +wish-pathname+
> #+freebsd "wish8.3" ; or 8.4, whatever
> #+(and sbcl (not freebsd)) "/usr/bin/wish"
> #-(or sbcl freebsd) "wish")
>
> (defconstant +wish-args+ '("-name" "LTK"))
Yes that was a little bit cluttered. I have cleaned it up following
your suggestions. Yet I think it may be useful to declare wish-pathname
and wish-args as special variables, so that it can be overridden
for special purposes without changing the Ltk source.
> ...
>
> (defmacro with-ltk (&rest body)
> `(progn
> (setf *w* (do-execute +wish-pathname+ +wish-args+))
> ,@body
> (mainloop)))
I have retained (though cleaned up) start-w, so that especially
for playing with Ltk from the REPL you can initialize it without
exposing details to the user.
> - Your doc file suggests:
>
> Note: on FreeBSD wish resides in /usr/local/bin/wish8.4 for
> Tcl/Tk version 8.4. You either have to modify the path to wish
> in ltk.lisp or create a link called wish to the executable
> (like: cd /usr/local/bin;ln -s /usr/local/bin/wish8.4 wish).
>
> Actually, on FreeBSD there is *already* a program named "wish", which
> when run, says this:
>
> % wish
> In FreeBSD, wish is named with a version number. This is
> because different versions of wish are not compatible with
> each other and they can not all be called "wish"! You may
> need multiple versions installed because a given port may
> depend on a specific version.
>
> On your system, wish is installed under at least the following
> names:
>
> wish8.3
> %
>
> So you probably don't want to overwrite that program. ;-}
Indeed :). It was only a shot in the dark after I received a mail
from a FreeBSD user, as I have no FreeBSD experience of myself.
> - On Common Lisps which provide threads (CMUCL, SBCL, others), it would
> be nice if LTK:MAINLOOP ran in a separate thread, so that one still
> had access to the main REPL, at least while debugging. [Time permitting,
> I'll try to hack something up to work under CMUCL as a base case...]
Yes that might be useful. You can find some thread stuff in ltk-remote,
which creates a seperate thread for each new connection. With CMUCL I
made the experience that the threads do not mix well with SLIME,
but that probably is a mistake a I made.
I just uploaded the newest version of Ltk to my website, incoorperating
your changes. Due to the experience with the last version I released,
I have labled it seperately as ltk-latest.tgz and will only move it
to the stable version after a few days of use...
Thanks for your contributions.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Rob Warnock wrote:
| > A few small suggestions:
| > - The interaction between DO-EXECUTE, START-W, *W*, the callers of
| > START-W, and the users of *W* seems a bit awkward. ...
|
| Yes that was a little bit cluttered. I have cleaned it up following
| your suggestions. Yet I think it may be useful to declare wish-pathname
| and wish-args as special variables, so that it can be overridden
| for special purposes without changing the Ltk source.
+---------------
Sounds fine [though in that case they should be named *WISH-PATHNAME*
and *WISH-ARGS*, of course].
+---------------
| > (defmacro with-ltk (&rest body)
| > `(progn
| > (setf *w* (do-execute +wish-pathname+ +wish-args+))
| > ,@body
| > (mainloop)))
|
| I have retained (though cleaned up) start-w, so that especially
| for playing with Ltk from the REPL you can initialize it without
| exposing details to the user.
+---------------
Well, o.k., but the issue I had with START-W was precisely that
it did a "hidden" SETF of *W*, a single global, rather than (say)
being dynamically bound by WITH-LTK. If it's dynamically bound,
then different parts of the program [OR DIFFERENT THREADS!] can
use different copies of a "wish" child process, and you still
get the simplicity of an implied global. That's why I suggested
removing START-W entirely... though perhaps I should have been
a little more proactive in proposing an alternative to the SETF
in WITH-LTK, perhaps something like this:
(defmacro with-ltk (&rest body)
`(let ((*w* (do-execute *wish-pathname* *wish-args*)))
,@body
(mainloop)))
Just make sure that in a threaded version of WITH-LTK the new binding
is made in the new thread...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Well, o.k., but the issue I had with START-W was precisely that
> it did a "hidden" SETF of *W*, a single global, rather than (say)
> being dynamically bound by WITH-LTK. If it's dynamically bound,
> then different parts of the program [OR DIFFERENT THREADS!] can
> use different copies of a "wish" child process, and you still
> get the simplicity of an implied global. That's why I suggested
> removing START-W entirely... though perhaps I should have been
> a little more proactive in proposing an alternative to the SETF
> in WITH-LTK, perhaps something like this:
>
> (defmacro with-ltk (&rest body)
> `(let ((*w* (do-execute *wish-pathname* *wish-args*)))
> ,@body
> (mainloop)))
>
> Just make sure that in a threaded version of WITH-LTK the new binding
> is made in the new thread...
Yes, for multi-threading, we need to bind *w* dynamically
(see ltk-remote :p) and also we should dynamically bind *callbacks* and
for aesthetical reasons the variable issuing the counters. Then we
even can have any number of separate GUIs running at the same time.
The only thing I am still pondering is which interface to give
to the multithreaded version. I do not think the macro with-ltk
should force multithreading. So there are two alternatives: either
add a new macro for that purposes or, just make with-ltk thread-safe
by rebinding the special variables and add a (portable) convenience
function to wrap around with-ltk. I am open for suggestions, what
is the most convenient and clean way.
Peter
--
Peter Herth
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
On 2004-06-13 10:58:06, Peter Herth wrote:
> I just uploaded the newest version of Ltk to my website, incoorperating
> your changes. Due to the experience with the last version I released,
> I have labled it seperately as ltk-latest.tgz and will only move it
> to the stable version after a few days of use...
How about using a release number?