Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton <kentilton@xxxxxxxxx>
- Date: Tue, 30 Jan 2007 19:35:45 -0500
Stocker wrote:
Hi all! I just entered the world of lisp GUI's, and I'm still trying
out cells+celtk under a Windows 2003 machine.
I passed most of the "tricks" Ken placed for newcomers (asdf not
up to date with lpr's, paths to libraries and to movies, etc),
but I'm still having my share of quirks to discuss.
On Jan 30, 1:43 am, Michael <spamt...@xxxxxxxxxxxxxx> wrote:
On 2007-01-29 18:40:37 -0500, Ken Tilton <kentil...@xxxxxxxxx> said:Fortunately, it's easy enough to fix those from the lpr. Question, quad.lisp is on cells/utils-kt for any particular reason other than to be a proof-of-concept, or something that has no place in the dependency-graph? (if so, may I suggest a separate dir, like ./
Ah, someone else just reported that. My apologies (and a warning that I
do not use ASDF day to day so those files do not get maintained).
examples ?)
Quads! That is my implementation of the mechanism suggested by none other than Erik Naggum Himself as an alternative to XML. Can't hide that!
3. Oddly enough my sbcl chokes on ltktest-ci.
You're lucky. Mine doesn't get to it. I can load everything up to the point of tk-interp loading, when I get this error when evaluating the form:
(defcfun ("Tcl_FindExecutable" tcl-find-executable) :void
(argv0 :string))
Here's the error I get:
Undefined alien: "Tcl_FindExecutable"
[Condition of type UNDEFINED-ALIEN-ERROR]
Restarts:
0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {B873951}> on #<ASDF:CL-SOURCE-FILE "tk-interp" {ABFFAE9}>.
1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {B873951}> on #<ASDF:CL-SOURCE-FILE "tk-interp" {ABFFAE9}> as having been successful.
2: [ABORT] Abort SLIME compilation.
3: [ABORT] Return to SLIME's top level.
4: [CLOSE-CONNECTION] Close SLIME connection
5: [ABORT] Exit debugger, returning to top level.
Backtrace:
0: (SB-SYS:ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS
"Tcl_FindExecutable"
#<unused argument>)
1: (SB-IMPL::LINK-FOREIGN-SYMBOL "Tcl_FindExecutable" NIL)
2: (SB-IMPL::ENSURE-FOREIGN-SYMBOL-LINKAGE "Tcl_FindExecutable" NIL)
3: (SB-SYS:FOREIGN-SYMBOL-ADDRESS "Tcl_FindExecutable" NIL)
4: (SB-FASL::FOP-FOREIGN-FIXUP)
5: (SB-FASL::LOAD-FASL-GROUP
#<SB-SYS:FD-STREAM for "file C:\\dev\\cells\\Celtk\\tk-
interp.fasl" {A923269}>)
I don't know if there's something particular I have to change on
the library location in order for sbcl to recognize it, I'm using
something like the following for each library (and it works on ACL):
(define-foreign-library Tcl
(:darwin (:framework "Tcl"))
(:windows (:or "/dev/Tcl/bin/tcl85.dll" "tcl85.dll"))
(:unix "libtcl.so")
(t (:default "libtcl")))
I don't know what to do from here about this. Any clues?
1. That looks like the first defcfun for Tcl, so a wild guess is that SBCL just cannot find (in wasy to be discussed) the .SO. You can firm by commenting out Tcl_FindExecutable and confirming that compile fails on the next defcfun. Disucessed: did you install Tcl? Is it where you said it was in the define-foreign-library?
2. Another issue /I believe/ (not sure) is that SBCL and CMUCL are severely retarded and do not understand Lisp and want the library to be loaded before you compile a defcfun. That is what you get with free software! But...
3. Other people have used SBCL, so you next suspect is ASDF, also retarded in that it tries to compile everything before loading anything. I gather it does this to support McCLIM, which of course is wonderful fodder for all my anti-yobbo cannons. But I digress... maybe add lines like this before the defcun:
(use-foreign-library Tcl)
(use-foreign-library Tk)
Hmm, I have to wonder if SBCL is still retarded, my code base (used by a coworker on SBCL who sent patches as necessary) does not execute the USEs until run time. But maybe you have an old SBCL?
Oh, great, now free software is chewing up my time as well as yours! :)
2) Under ACL 7.0, I run into this whenever trying to load your
lotsa-widgets (with the video - I can run it just fine without
them, working great!).
Damn! Stallman said I would be able to sell support. Thanks for nothing, RMS!
I googled the code, but the only thing I
suspect is that it can be about QuikTimeTcl. But I have the
latest library (3.1) , from the site, placed in the lib folder,
properly, so I don't know what can it be[1].
Tcl error: Error in user parameter list
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [ABORT] Abort entirely from this (lisp) process.
Backtrace:
0: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x2136d34a>
#<Function SWANK-DEBUGGER-HOOK>)
1: (ERROR "Tcl error: ~a" "Error in user parameter list")
2: ((METHOD CFFI:TRANSLATE-FROM-FOREIGN (T (EQL 'CELTK::TCL-
RETCODE))) 1
CELTK::TCL-RETCODE)
3: ((METHOD CFFI::TRANSLATE-TYPE-FROM-FOREIGN (T CFFI::FOREIGN-
TYPEDEF))
1 #<CFFI::FOREIGN-TYPEDEF CELTK::TCL-RETCODE>)
4: (CELTK::TCL_EVALEX 485001136
"movie .f713.f716.f742.f747.f751.play-me -
palindromeloopstate 0 -loopstate 0 -file c:\\dev\\cells\\Celtk\\good-
thing2.mov"
-1 0)
What say you? Is it serious? Does it have a known cure?
I am pretty sure that just means it cannot find the file (I mean, I got that "parameter error" too and it turned out to be a naming thing). My code looks like this now:
"c:/0dev/celtk/good-thing2.mov"
One sanity check I like to try is:
(probe-file "c:\\dev\\cells\\Celtk\\good-thing2.mov")
I would not worry about anything else until that works. And then I would go with / over \\ as a wild stab talking to TCL.
That, btw, is not how I have my code organized, under /0dev (did you copy my structure then miss the 0 in odev?) or in CVS, where Celtk is alongside Cells.
[1] Note that I'm not that familiar with Tcl/Tk, I'm installing
it for the first time to use celltk!
Great library, great community. Lisp and Tcl/Tk, perfect marriage.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
.
- Follow-Ups:
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Edgar Gonçalves
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- References:
- All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Michael
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Michael
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Michael
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Michael
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Stocker
- All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Prev by Date: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Next by Date: Re: Die, CL App Builder! Die!!! [was Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)]
- Previous by thread: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Next by thread: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Index(es):
Relevant Pages
|