Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)

I posted a reply yesterday, but somehow it never met the news server :
\ Well, here's another go:

On Jan 31, 12:35 am, Ken Tilton <kentil...@xxxxxxxxx> wrote:
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:

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).

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 ./
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?
Yap, that's all set - note that allegro can show me windows, so this
could never be the problem, I guess.


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?

Actually, I did, but I changed in order to test it again, to no
avail. So the problem holds for SBCL, the good news being that use-
foreign-library fixes that. So, to leave something for the eventual
reader, I added to tk-interp.lisp and to togl.lisp, right before the
defcfuns:

,----------<tk-interp.lisp>
| #+sbcl (use-foreign-library Tcl)
| #+sbcl (use-foreign-library Tk)
| #+sbcl (use-foreign-library Tile)
`----------

,----------<togl.lisp>
| #+sbcl (use-foreign-library Togl)
`----------


But alas, there's still another trouble before making a
window. This time, it's really weird, especially because ACL
again behaves differently (see the last part of my reply). SBCL
complains in CFFI:TRANSLATE-FROM-FOREIGN saying:
,----------
| Tcl error: QuickTimeTcl requires tcl version 8.4 or later
| [Condition of type SIMPLE-ERROR]
| Backtrace:
| 0: ((SB-PCL::FAST-METHOD CFFI:TRANSLATE-FROM-FOREIGN
| (T (EQL 'CELTK::TCL-RETCODE)))
| #<unavailable argument>
| #<unavailable argument>
| 1
| #<unavailable argument>)
| 1: (CELTK::TCL_EVALEX
| #.(SB-SYS:INT-SAP #X01331A50)
| "package require QuickTimeTcl"
| -1
| 0)
| 2: (NIL "package require QuickTimeTcl")
| 3: (RUN-WINDOW LOTSA-WIDGETS T)
`----------

What's weird about this? well, for starters, QuickTimeTcl says it
can use 8.4, "or above". Then, you seem to use the 8.5 library
yourself, judging from your library paths declarations on the
code. Lastly, I have both libraries in the same dir, both 8.5 and
8.4, so it wouldn't be problematic to use either one - and no,
changing celtk to use the 8.4 gives me other issues, this time with
tile, but I'd rather not try to understand obsolete buggy
configurations...


Oh, great, now free software is chewing up my time as well as yours! :)

I guess it does come with a price after all! :)




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 guess you could always sell support for some particular audience -
like those using free cl implementations, for instance (the joke being
on your clients that wouldn't pay for software but for fixing a free -
but buggy - equivalent!). Wouldn't that raise your motivation as a
good seller? :d




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.


Ok, I assume there was a path issue, as I was using something
like (merge-pathname "good-thing2.mov"). I started using the full
path string, and it's aaaaalmost there. Now I can see
lotsa-widgets, but I have no video showing up nowhere. Here's the
relevant part from the output, telling me that tcl was commanded
to play the movie (and yes, this is the full path for my celtk,
and the file is there - probe-file confirms it.)

,---------------
| CL-USER> (ctk::tk-test)
|
| "----------UTILSRESET----------------------------------"
| tk> movie .f13.f16.f42.f47.f51.play-me -palindromeloopstate 0 -
loopstate 0 -file "c:/dev/cells/celtk/good-thing2.mov"
| tk>
pack .f13.f16.f42.f47.f51.f95 .f13.f16.f42.f47.f51.f96 .f13.f16.f42.f47.f51.play-
me -side top -anchor nw -padx 0 -pady 0
`---------------

Question: what versions of '(Tcl/tk Tile QuickTimeTcl Togl QuickTime)
are known to work with celtk? (This is the kind of thing I'd like to
see on a doc - but as I would probably not find one with this, I'd
like to be able to find with google :) )

My configuration (not fully functional):
o SBCL 1.02 (win32) or ACL 7.0 (win32)
o tcl85.dll
o tk85.dll
o tile078.dll
o QuickTimeTcl3.1.dll
o Togl17.dll
o QuickTimeLibrary version 7.1.3.100 (from the free QuickTime
Alternative distribution)

.

Relevant Pages

  • Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
    ... up to date with lpr's, paths to libraries and to movies, etc), ... (define-foreign-library Tcl ... SBCL just cannot find the .SO. ... that just makes a movie widget and then places it in the GUI ...
    (comp.lang.lisp)
  • Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
    ... up to date with lpr's, paths to libraries and to movies, etc), ... SBCL just cannot find the .SO. ... Disucessed: did you install Tcl? ... that just makes a movie widget and then places it in the GUI hierarchy for Tk to manage. ...
    (comp.lang.lisp)
  • Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
    ... up to date with lpr's, paths to libraries and to movies, etc), ... 2: [ABORT] Abort SLIME compilation. ... That looks like the first defcfun for Tcl, so a wild guess is that SBCL just cannot find the .SO. ...
    (comp.lang.lisp)
  • Re: Managing many small libraries
    ... Some suggested that I simply load all the libraries all the time. ... I'm using openmcl for most things, and sbcl on rare occasions, so I ... Now both lisps use module- ...
    (comp.lang.lisp)
  • Re: Managing many small libraries
    ... Some suggested that I simply load all the libraries all the time. ... I'm using openmcl for most things, and sbcl on rare occasions, so I ... Now both lisps use module- ...
    (comp.lang.lisp)