From: Ken Tilton
Subject: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <QVavh.50$S14.1@newsfe09.lga>
Someone asked about Celtk as a platform for an app, mentioned video as a
requirement. I said, "No can do, unless....". Sixty minutes later (would
have been less if I knew how to read) I was watching a movie in a Celtk
window in an embedded QuickTime widget, thanks to:
http://quicktimetcl.sourceforge.net/
(And won't Mastenbrook be thrilled to know I have added another library!
Of course he will say I am lying....)
Look, case closed kiddies: "CL+Tcl/Tk, perfect together"
Ah. There /is/ a fly in the ointment: QuickTimeTcl is supported only on
windows and mac os x. But that might just be because the developer did
not get round to that platform. Anywho...
If I land a second user it may be time to launch a serious c-l.net
project dedicated to Celtk and the proposition that all GUIs are not
created equal. Any interest? Basically I would be putting the beast up
for adoption (I am a real programmer, I don't need no stinkin GUI) as
first Vasily and then I did with Cells-Gtk. I just have to be sure it
finds a good home. Please form a line to the right.
ken (who will be checking here hourly for the McCLIM/QT integration demo
link -- what? you wusses don't work on Sunday night?)
--
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
On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
> Someone asked about Celtk as a platform for an app, mentioned video as
> a requirement. I said, "No can do, unless....". Sixty minutes later
> (would have been less if I knew how to read) I was watching a movie in
> a Celtk window in an embedded QuickTime widget, thanks to:
>
> http://quicktimetcl.sourceforge.net/
I checked http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
but it doesn't
appear you've checked in any quicktime code today.
Am I looking in the wrong spot?
Michael
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <cnevh.306$_z3.121@newsfe10.lga>
Michael wrote:
> On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
>
>> Someone asked about Celtk as a platform for an app, mentioned video as
>> a requirement. I said, "No can do, unless....". Sixty minutes later
>> (would have been less if I knew how to read) I was watching a movie in
>> a Celtk window in an embedded QuickTime widget, thanks to:
>>
>> http://quicktimetcl.sourceforge.net/
>
>
> I checked http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
> but it doesn't
> appear you've checked in any quicktime code today.
>
> Am I looking in the wrong spot?
Oh, sorry, I was just bragging and trying to piss off the yobbos so they
could get some work done.
I am cleaning up a bit of unpleasantness (Celtk depending on Cello) and
will put up new stuff in both Cells and Celtk, um, Reasonably Soon Now.
kt
ps. There is nothing to see, except a movie player playing a movie using
an embedded QuickTime widget. I looked at a little code and found myself
wondering if there is a ... no, I do not see a C API. Which is OK, we
can do tcl commands via tcl-eval. k
>
> Michael
>
--
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
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <4Wgvh.48$Pj2.39@newsfe12.lga>
Michael wrote:
> On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
>
>> Someone asked about Celtk as a platform for an app, mentioned video as
>> a requirement. I said, "No can do, unless....". Sixty minutes later
>> (would have been less if I knew how to read) I was watching a movie in
>> a Celtk window in an embedded QuickTime widget, thanks to:
>>
>> http://quicktimetcl.sourceforge.net/
>
>
> I checked http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
> but it doesn't
> appear you've checked in any quicktime code today.
Now committed. This brings along the rough Tile support as well.
I have only tried QT on MOV files, but it works like a charm on those,
hopefully as well as anything QT supports. Nice package. I think the
tcl/Tk community has a pretty high ethic on packages, they all just
plug-n-play as far as I can tell. Small sample, I confess, but I am happy.
If you get lotsa-widgets working, try typing "sex", "bush", "drugs", or
"war" into the entry field near the movie widget.
--
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
On 2007-01-29 01:58:07 -0500, Ken Tilton <·········@gmail.com> said:
> Michael wrote:
>> On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
>>
>>> Someone asked about Celtk as a platform for an app, mentioned video as
>>> a requirement. I said, "No can do, unless....". Sixty minutes later
>>> (would have been less if I knew how to read) I was watching a movie in
>>> a Celtk window in an embedded QuickTime widget, thanks to:
>>>
>>> http://quicktimetcl.sourceforge.net/
>>
>>
>> I checked http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
>> but it doesn't
>> appear you've checked in any quicktime code today.
>
> Now committed. This brings along the rough Tile support as well.
Using sbcl on ppc OS X:
; compiling (DEFSTRUCT V3I ...)
; file:
/Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
; in: DEFSTRUCT V3I
; (DEFSTRUCT KT-OPENGL:V3I
; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
;
; caught ERROR:
; (during macroexpansion of (DEFSTRUCT V3I ...))
; error while parsing arguments to DESTRUCTURING-BIND:
; odd number of elements in keyword/value list: (GLINT)
Happens a few times, only pasted one copy. Any idea what I'm doing wrong?
Michael
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <Ifnvh.1$KX1.0@newsfe10.lga>
Michael wrote:
> On 2007-01-29 01:58:07 -0500, Ken Tilton <·········@gmail.com> said:
>
>> Michael wrote:
>>
>>> On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
>>>
>>>> Someone asked about Celtk as a platform for an app, mentioned video
>>>> as a requirement. I said, "No can do, unless....". Sixty minutes
>>>> later (would have been less if I knew how to read) I was watching a
>>>> movie in a Celtk window in an embedded QuickTime widget, thanks to:
>>>>
>>>> http://quicktimetcl.sourceforge.net/
>>>
>>>
>>>
>>> I checked
>>> http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells but it
>>> doesn't
>>> appear you've checked in any quicktime code today.
>>
>>
>> Now committed. This brings along the rough Tile support as well.
>
>
> Using sbcl on ppc OS X:
>
> ; compiling (DEFSTRUCT V3I ...)
> ; file:
> /Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
> ; in: DEFSTRUCT V3I
> ; (DEFSTRUCT KT-OPENGL:V3I
> ; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
> ; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
> ; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
> ;
> ; caught ERROR:
> ; (during macroexpansion of (DEFSTRUCT V3I ...))
> ; error while parsing arguments to DESTRUCTURING-BIND:
> ; odd number of elements in keyword/value list: (GLINT)
>
> Happens a few times, only pasted one copy. Any idea what I'm doing wrong?
No. Possibly trying to build Cello instead of Celtk. They both use
Cells. I try to keep the names indistinguishable to throw off the yobs.
Usually works, they post a lot of anti-Cells flames and call it Cello. I
always get a kick out of that. Anyway...
First of all, my code says:
(defstruct v3i
(x 0 :type GLint)
(y 0 :type GLint)
(z 0 :type GLint))
Second, that code is in kt-opengl. Vanilla Celtk does not use kt-opengl,
Cello does. Celtk3D demos use cl-opengl and adds Togl support.
But you do not need Celtk3d or OpenGL or Togl to see the QT widget in
lotsa-widgets.
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
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <1znvh.2$KX1.0@newsfe10.lga>
Ken Tilton wrote:
>
>
> Michael wrote:
>
>> On 2007-01-29 01:58:07 -0500, Ken Tilton <·········@gmail.com> said:
>>
>>> Michael wrote:
>>>
>>>> On 2007-01-28 19:10:19 -0500, Ken Tilton <·········@gmail.com> said:
>>>>
>>>>> Someone asked about Celtk as a platform for an app, mentioned video
>>>>> as a requirement. I said, "No can do, unless....". Sixty minutes
>>>>> later (would have been less if I knew how to read) I was watching a
>>>>> movie in a Celtk window in an embedded QuickTime widget, thanks to:
>>>>>
>>>>> http://quicktimetcl.sourceforge.net/
>>>>
>>>>
>>>>
>>>>
>>>> I checked
>>>> http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells but it
>>>> doesn't
>>>> appear you've checked in any quicktime code today.
>>>
>>>
>>>
>>> Now committed. This brings along the rough Tile support as well.
>>
>>
>>
>> Using sbcl on ppc OS X:
>>
>> ; compiling (DEFSTRUCT V3I ...)
>> ; file:
>> /Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
>> ; in: DEFSTRUCT V3I
>> ; (DEFSTRUCT KT-OPENGL:V3I
>> ; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
>> ; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
>> ; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
>> ;
>> ; caught ERROR:
>> ; (during macroexpansion of (DEFSTRUCT V3I ...))
>> ; error while parsing arguments to DESTRUCTURING-BIND:
>> ; odd number of elements in keyword/value list: (GLINT)
>>
>> Happens a few times, only pasted one copy. Any idea what I'm doing wrong?
>
>
> No. Possibly trying to build Cello instead of Celtk. They both use
> Cells. I try to keep the names indistinguishable to throw off the yobs.
> Usually works, they post a lot of anti-Cells flames and call it Cello. I
> always get a kick out of that. Anyway...
>
> First of all, my code says:
>
> (defstruct v3i
> (x 0 :type GLint)
> (y 0 :type GLint)
> (z 0 :type GLint))
>
> Second, that code is in kt-opengl. Vanilla Celtk does not use kt-opengl,
> Cello does. Celtk3D demos use cl-opengl and adds Togl support.
>
> But you do not need Celtk3d or OpenGL or Togl to see the QT widget in
> lotsa-widgets.
Doh! But you will need Tcl/Tk (get it from ActiveState) and QuickTimeTcl
from the site dedicated to that, possibly eponymous. The latter includes
install directions (move a directory into <Tcl>/lib -- whew! I need a nap!).
Then (just so people can see how nice is life with Tcl/Tk and Celtk), I
had to add this code:
(tk-format-now "package require QuickTimeTcl")
(deftk movie (widget)
()
(:tk-spec movie -url (tk-file -file)))
And then add a movie widget to the lotsa-widgets hierarchy:
(mk-movie :id :play-me
:tk-file (c-in "c:/0dev/celtk/good-thing2.mov"))
MWUAHAHAHAHAHAHAAAAAA!!!!
This observer unjustifiably starts a movie playing whenever the movie
file slot changes:
(defobserver tk-file :around ((self movie))
(call-next-method)
(when (and new-value old-value)
(tk-format `(:fini ,self) "~a play" (^path))))
I really should have an options slot that would contain options such as
:auto-start or :start-on-change or somethin, but this was just ten
seconds work.
I think Franz and Lispworks need to shut down their GUI projects and
adopt Celtk to avoid GUI fragmentation in the CL community, don't you?
MWUAAHAHAHHAHA!
kenny
--
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
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <KDqvh.25$wT1.10@newsfe09.lga>
Ken Tilton wrote:
>
> Then (just so people can see how nice is life with Tcl/Tk and Celtk), I
> had to add this code:
>
> (tk-format-now "package require QuickTimeTcl")
>
> (deftk movie (widget)
> ()
> (:tk-spec movie -url (tk-file -file)))
Found a few more options:
(deftk movie (widget)
()
(:tk-spec movie -url (tk-file -file)
-controller -custombutton -highlightbackground -highlightcolor
-highlightthickness -height -loadcommand -loadintoram -loopstate
-mccommand -mcedit -palindromeloopstate -preferredrate -progressproc
-qtprogress -qtvrqualitymotion -qtvrqualitystatic -resizable
-swing -swingspeed -volume -width)
(:default-initargs
:tile? nil))
MWUAHAHAHAHAHHAHAA!!!!! Yes, palindromeloopstate set to 1 makes the
movie run endlessly forth and back. Picture looks fine running
backwards, but instead of the spoken words coming out in reverse, well,
it is just unrecognizable noise. Working on that now...
ken
--
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
On 2007-01-29 09:10:48 -0500, Ken Tilton <·········@gmail.com> said:
> Michael wrote:
>> Using sbcl on ppc OS X:
>>
>> ; compiling (DEFSTRUCT V3I ...)
>> ; file:
>> /Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
>> ; in: DEFSTRUCT V3I
>> ; (DEFSTRUCT KT-OPENGL:V3I
>> ; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
>> ; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
>> ; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
>> ;
>> ; caught ERROR:
>> ; (during macroexpansion of (DEFSTRUCT V3I ...))
>> ; error while parsing arguments to DESTRUCTURING-BIND:
>> ; odd number of elements in keyword/value list: (GLINT)
>>
>> Happens a few times, only pasted one copy. Any idea what I'm doing wrong?
>
> No. Possibly trying to build Cello instead of Celtk. They both use
> Cells. I try to keep the names indistinguishable to throw off the yobs.
> Usually works, they post a lot of anti-Cells flames and call it Cello.
> I always get a kick out of that. Anyway...
Celtk's .asd depends on cl-ftgl which depends on kt-opengl which
fails with the error message I gave you.
Is there some other way to compile celtk so that it doesn't depend
on kt-opengl?
Michael
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <VBvvh.1507$KX1.384@newsfe10.lga>
Michael wrote:
> On 2007-01-29 09:10:48 -0500, Ken Tilton <·········@gmail.com> said:
>
>> Michael wrote:
>>
>>> Using sbcl on ppc OS X:
>>>
>>> ; compiling (DEFSTRUCT V3I ...)
>>> ; file:
>>> /Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
>>> ; in: DEFSTRUCT V3I
>>> ; (DEFSTRUCT KT-OPENGL:V3I
>>> ; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
>>> ; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
>>> ; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
>>> ;
>>> ; caught ERROR:
>>> ; (during macroexpansion of (DEFSTRUCT V3I ...))
>>> ; error while parsing arguments to DESTRUCTURING-BIND:
>>> ; odd number of elements in keyword/value list: (GLINT)
>>>
>>> Happens a few times, only pasted one copy. Any idea what I'm doing
>>> wrong?
>>
>>
>> No. Possibly trying to build Cello instead of Celtk. They both use
>> Cells. I try to keep the names indistinguishable to throw off the
>> yobs. Usually works, they post a lot of anti-Cells flames and call it
>> Cello. I always get a kick out of that. Anyway...
>
>
> Celtk's .asd depends on cl-ftgl which depends on kt-opengl which
> fails with the error message I gave you.
>
> Is there some other way to compile celtk so that it doesn't depend
> on kt-opengl?
>
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).
Just eliminate the cl-ftgl dependency. The ASD has been recommited,
along with slight mods for the movie widget.
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
On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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).
>
> Just eliminate the cl-ftgl dependency. The ASD has been recommited,
> along with slight mods for the movie widget.
I tried out celtk. A few comments/questons.
1. Are tile and togl required? I'm used to ltk and it
works on a stock tcl/tk. Installing tile and togl
is easy enough, just wanted to know if it is a hard
requirement.
2. Paths -- lotsa-widgets seems to expect movies to be
on C: drive.
3. Oddly enough my sbcl chokes on ltktest-ci. It started
okay but after a few mouse clicks I got the following:
CTK> (ctk::ltktest-ci)
"----------UTILSRESET----------------------------------"
"----------UTILSRESET----------------------------------"
0> 33808 numparse :=> 42
0> 1951 button pressed: 1 8 164 946 377
0> 6 button released: 1 8 164 946 377
0> 130 button pressed: 1 6 33 944 246
0> 18 button released: 1 6 33 944 246
0> 164 button pressed: 1 8 27 946 240
0> 3 button released: 1 8 27 946 240
fatal error encountered in SBCL pid 23105:
GC invariant lost, file "gc-common.c", line 140
LDB monitor
ldb>
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <oHxvh.312$wT1.175@newsfe09.lga>
Michael wrote:
> On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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).
>>
>> Just eliminate the cl-ftgl dependency. The ASD has been recommited,
>> along with slight mods for the movie widget.
>
>
> I tried out celtk. A few comments/questons.
>
> 1. Are tile and togl required? I'm used to ltk and it
> works on a stock tcl/tk. Installing tile and togl
> is easy enough, just wanted to know if it is a hard
> requirement.
<cough> yesd and no. No in principle, but maybe yes in fact because I
think I hardcode the damn thing to append ttk:: to all the widgets Tile
duplicates. You would just have to search on the string "TTK::" and
remove that.
really what should be done is simply offer new Celtk widgets like
ttk-button. Hang on. I do have a tile? attribute which I would have
defaulted to t for this experiment. Maybe track /that/ down and change
to nil and the engine will not stick in the TTK:: (or you can tweak it
not to).
Anyway, as I was saying, The Right Way probably lets people use non-Tile
versions, just because it is so easy to do so and maybe they would have
a reason for it, so err on the side of more.
>
> 2. Paths -- lotsa-widgets seems to expect movies to be
> on C: drive.
yep, that is my favorite booby trap for users.
>
> 3. Oddly enough my sbcl chokes on ltktest-ci. It started
> okay but after a few mouse clicks I got the following:
>
> CTK> (ctk::ltktest-ci)
>
> "----------UTILSRESET----------------------------------"
> "----------UTILSRESET----------------------------------"
> 0> 33808 numparse :=> 42
> 0> 1951 button pressed: 1 8 164 946 377
> 0> 6 button released: 1 8 164 946 377
> 0> 130 button pressed: 1 6 33 944 246
> 0> 18 button released: 1 6 33 944 246
> 0> 164 button pressed: 1 8 27 946 240
> 0> 3 button released: 1 8 27 946 240
> fatal error encountered in SBCL pid 23105:
> GC invariant lost, file "gc-common.c", line 140
>
> LDB monitor
> ldb>
>
Ah, the spinning moire deal. I think that uses tcl timers intensely, and
callbacks and all sorts of groovy stuff, probably a good way to break a
Lisp. I believe callbacks Lisp-to-C-back-to-lisp are new for SBCL, maybe
they have a limitation I am violating, or maybe a bug.
kzo
--
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
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <FNxvh.313$wT1.85@newsfe09.lga>
Ken Tilton wrote:
>
>
> Michael wrote:
>
>> On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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).
>>>
>>> Just eliminate the cl-ftgl dependency. The ASD has been recommited,
>>> along with slight mods for the movie widget.
>>
>>
>>
>> I tried out celtk. A few comments/questons.
>>
>> 1. Are tile and togl required? I'm used to ltk and it
>> works on a stock tcl/tk. Installing tile and togl
>> is easy enough, just wanted to know if it is a hard
>> requirement.
>
>
> <cough> yesd and no. No in principle, but maybe yes in fact because I
> think I hardcode the damn thing to append ttk:: to all the widgets Tile
> duplicates. You would just have to search on the string "TTK::" and
> remove that.
>
> really what should be done is simply offer new Celtk widgets like
> ttk-button. Hang on. I do have a tile? attribute which I would have
> defaulted to t for this experiment. Maybe track /that/ down and change
> to nil and the engine will not stick in the TTK:: (or you can tweak it
> not to).
>
> Anyway, as I was saying, The Right Way probably lets people use non-Tile
> versions, just because it is so easy to do so and maybe they would have
> a reason for it, so err on the side of more.
Ah, here is what I did (tho modified now from what you would find):
(defmethod tk-class :around ((self widget))
(conc$ (when (tile? self) "TTK::") (call-next-method)))
And the Tk default (the initform) for tile? is t, and widgets tile does
not support have a defaultinitarg of nil.
So if you make a button, you get a Tile button unless you specify:
:tile? nil
Just change the tk-object tile? initform to nil (and disable the package
require) and you should be able to avoid Tile.
kt
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 <········@ectospheno.com> wrote:
> On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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 ?)
> 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?
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!). 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?
[1] Note that I'm not that familiar with Tcl/Tk, I'm installing
it for the first time to use celltk!
On Jan 30, 11:59 pm, "Stocker" <···············@gmail.com> 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 apologize for not introducing myself to the list. I'm Edgar
Gonçalves (Stocker is my nickname assumed by default on the post
sending!).
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <wxRvh.22$lW6.14@newsfe08.lga>
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 <········@ectospheno.com> wrote:
>
>>On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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?
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
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 <·········@gmail.com> 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 <········@ectospheno.com> wrote:
>
> >>On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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)
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <7I7wh.16$yS7.1@newsfe08.lga>
Edgar Gon�alves wrote:
> 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 <·········@gmail.com> 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 <········@ectospheno.com> wrote:
>>
>>>>On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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.
Right, I had not seen your success story later in the post when I wrote
that and only after posting myself realized that ruled out this
possibility (or I would have gone back and whacked it).
>
>
>>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)
> `----------
>
Hunh. Possibly the person I was working with slipped that in someplace
and forgot to pass it along (or passed it along and I missed it in my
manual merge).
>
> 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...
Background: Celtk requires 8.5 for Togl (and I guess Tile and QT Tcl),
so... time to let go of 8.4 if you ask me. Otoh, Celtk ran fine on 8.4
before we started adding packages, so I guess it would again if someone
really wants to cling to the past. They should then just rip out
everything, default :tile? to nil everywhere, and go for it.
I would look for a Tcl command that would let you ask Tcl itself what
version it is running, although you should be able to put in some print
statements to /see/ what DLL is being loaded. Oh, wait, you got me
again: it works on ACL.
Maybe you switched the define-foreign-library to /say/ 8.5 without
recompiling or reinvoking use-foreign-library (and maybe even then SBCL
has a long memory and still ran against 8.4. You should first be
absolutely certain 8.5 is running (move 8.4, bounce SBCL, ask Tcl for a
version, etc etc) before panicking.
And never ask me about SBCL again. :)
>
>
>>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
> `---------------
No, that just makes a movie widget and then places it in the GUI
hierarchy for Tk to manage. Do you see two buttons, "serious demo" and
"celtk?"? Try pressing those. Or try typing "sex" or "bush" into the
entry field just left of the "echo" label.
It's a long story I did not want to wrestle with. Basically Cells GUIs
just spring to life. Tk is a little inflexible. I added a lot of
framework to be able to talk to Tk in the order it requires, but nothing
I have so far can start a movie playing as the window comes up -- every
attempt makes QTT complain that the movie is not yet displayed. I might
have to kludge in something related to the visibility event (which Celtk
already handles).
For now, you gots to push da button.
kt
Ken Tilton wrote:
> Edgar Gonçalves wrote:
> > 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 <·········@gmail.com> 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 <········@ectospheno.com> wrote:
> >>
> >>>>On 2007-01-29 18:40:37 -0500, Ken Tilton <·········@gmail.com> 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.
>
> Right, I had not seen your success story later in the post when I wrote
> that and only after posting myself realized that ruled out this
> possibility (or I would have gone back and whacked it).
>
> >
> >
> >>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)
> > `----------
> >
>
> Hunh. Possibly the person I was working with slipped that in someplace
> and forgot to pass it along (or passed it along and I missed it in my
> manual merge).
>
> >
> > 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...
>
> Background: Celtk requires 8.5 for Togl (and I guess Tile and QT Tcl),
> so... time to let go of 8.4 if you ask me. Otoh, Celtk ran fine on 8.4
> before we started adding packages, so I guess it would again if someone
> really wants to cling to the past. They should then just rip out
> everything, default :tile? to nil everywhere, and go for it.
Ok, that works perfectly for me. I'm pro-evolution :)
>
> I would look for a Tcl command that would let you ask Tcl itself what
> version it is running, although you should be able to put in some print
> statements to /see/ what DLL is being loaded. Oh, wait, you got me
> again: it works on ACL.
>
> Maybe you switched the define-foreign-library to /say/ 8.5 without
> recompiling or reinvoking use-foreign-library (and maybe even then SBCL
> has a long memory and still ran against 8.4. You should first be
> absolutely certain 8.5 is running (move 8.4, bounce SBCL, ask Tcl for a
> version, etc etc) before panicking.
>
> And never ask me about SBCL again. :)
I'll do all that, including this last one, worry not :) Thanks for the
clues!
>
> >
> >
> >>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
> > `---------------
>
> No, that just makes a movie widget and then places it in the GUI
> hierarchy for Tk to manage. Do you see two buttons, "serious demo" and
> "celtk?"? Try pressing those. Or try typing "sex" or "bush" into the
> entry field just left of the "echo" label.
>
> It's a long story I did not want to wrestle with. Basically Cells GUIs
> just spring to life. Tk is a little inflexible. I added a lot of
> framework to be able to talk to Tk in the order it requires, but nothing
> I have so far can start a movie playing as the window comes up -- every
> attempt makes QTT complain that the movie is not yet displayed. I might
> have to kludge in something related to the visibility event (which Celtk
> already handles).
>
> For now, you gots to push da button.
Ah, that sort of starts making some sense. The problem is, I don't get
these buttons visible. However, oddly enough, typing bush, war anger,
hate (but not sex, drugs, etc!) triggers the same movie playback
action, and it gives me an error:
,---------
| Tcl error: Movie not displayed
| [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 @ #x210a04f2>
| #<Function SWANK-DEBUGGER-HOOK>)
| 1: (ERROR "Tcl error: ~a" "Movie not displayed")
| 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 299581936
| ".f1096.f1099.f1125.f1130.f1134.play-me
play" -1 0)
| 5: (CELTK::TCL-EVAL-EX 299581936
| ".f1096.f1099.f1125.f1130.f1134.play-me
play")
| 6: (TK-FORMAT-NOW "~a play" ".f1096.f1099.f1125.f1130.f1134.play-
me")
| 7: ((FLET TK-FORMAT CELTK::DO-IT))
| 8: ((:INTERNAL TK-FORMAT 0) :USER-Q (:FINI PLAY-ME))
| 9: (TK-USER-QUEUE-HANDLER
| (NIL ((:FINI PLAY-ME) . #<Closure # @ #x2109e872>)))
| 10: (CELLS::FINISH-BUSINESS)
| 11: (CELLS::CALL-WITH-INTEGRITY :CHANGE .VALUE
| #<Closure (:INTERNAL (SETF CELLS::MD-SLOT-VALUE) 0) @
#x210985fa>)
| 12: ((SETF CELLS::MD-SLOT-VALUE) "bush" ENTER-ME .VALUE)
`---------
I guess, unless you see something more likely here, I've really gotta
stick my fingers in Tcl/Tk, check if my QuickTimeTcl is working fine,
and then figure out what's messing celtk - I'll report back. Chances
are that the free SBCL is much nicer to me, telling me there's a
problem with my QuickTimeTcl configuration, than ACL, that never
reports a problem, nor shows up usable results!
(and no, I won't ask for sbcl tips any more - at least for the time
being! ;) )
Edgar Gonçalves
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <dsbwh.14$_i4.1@newsfe09.lga>
Edgar Gon�alves wrote:
>>For now, you gots to push da button.
>
>
> Ah, that sort of starts making some sense. The problem is, I don't get
> these buttons visible.
Ah, now /that/ is inconceivable. :) Do you get two list boxes
side-by-side to the right of and a little lower than a one-line "Four
score and seven years ago" label?
Your next bit confirms that the movie widget is in the Lisp GUI
hierarchy at least, because the movie widget has a rule that watches the
entry field (unless you missed my update and got (crazy) version where
the entry widget pushed movies to the movie widget, but that would not
work either if it was not there in the Lisp hierarchy).
To see if Tcl is being told about the existence of the movie, try this
for tk-format-now (so you can watch traffic going to TCL via Tcl_Eval
(which is how Tk instances get created and packed):
(defun tk-format-now (fmt$ &rest fmt-args)
(unless (find *tkw* *windows-destroyed*)
(let* ((*print-circle* nil)
(tk$ (apply 'format nil fmt$ fmt-args)))
(let ((yes '("play-me"))
(no '()))
(declare (ignorable yes no))
(when (find-if (lambda (s) (search s tk$)) yes)
(format t "~&tk> ~a~%" tk$)))
(assert *tki*)
(setf *tk-last* tk$)
(tcl-eval-ex *tki* tk$))))
I get this output starting up:
movie .f1525.f1528.f1554.f1559.f1563.play-me -palindromeloopstate 0
-loopstate 0 -file "c:/0dev/celtk/good-thing2.mov"
pack .f1525.f1528.f1554.f1559.f1563.f1607
.f1525.f1528.f1554.f1559.f1563.f1608
.f1525.f1528.f1554.f1559.f1563.play-me -side top -anchor nw -padx 0 -pady 0
Minor diffs might be OK, I have been horsing around since the last
commit. Also, consider updating from CVS. Lotsa-widgets now ends (sorry
about the formatting):
(mk-stack ()
(duelling-scrolled-lists)
(mk-row ()
(mk-button-ex ("Serious Demo" (plug-n-play-movie (fm^ :play-me)
"c:/0dev/celtk/demo.mov")))
(mk-button-ex ("Celtk?" (plug-n-play-movie (fm^ :play-me)
"c:/0dev/celtk/good-thing2.mov"))))
(mk-movie :id :play-me
:loopstate (c-in 0) :palindromeloopstate (c-in 0)
:tk-file (c? (let ((entry (fm^v :enter-me)))
(cond
((find entry '("bush" "war" "anger" "hate") :test
'string-equal)
"c:/0dev/celtk/demo.mov")
((find entry '("sex" "drugs" "rock-n-roll" "peace")
:test 'string-equal)
"c:/0dev/celtk/good-thing2.mov")
(t "c:/0dev/celtk/good-thing2.mov" #+not .cache))))))
Final thought: if the movie is created without a file or url, it is
invisible, then it appears when one configures in a file and plays. In
an early version I just had a movie, no play buttons. But then typing in
the entry field should work.
> However, oddly enough, typing bush, war anger,
> hate (but not sex, drugs, etc!)
The rule defaults to the same movie played for sex etc, and Cells does
not react if a rule recalculates the same (eql, by default) value it
had. I guess the identical string literals are EQL.
Or maybe you fixed one path but not the other?
I'd worry about those missing buttons first. Give one of them an id and
then add that to the watch list in tk-format-now. I just tested with:
(mk-button-ex ("Serious Demo"
(plug-n-play-movie (fm^ :play-me
"c:/0dev/celtk/demo.mov"))
:id :serious-demo)
Hey, my trace shows that as a tile button (see the ttk?):
ttk::button .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo -command
"do-on-command .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo" -text
"Serious Demo"
Try defeating tile by specifying :tile? nil in
(deftk tk-object.....)
> triggers the same movie playback
> action, and it gives me an error:
> ,---------
> | Tcl error: Movie not displayed
> | [Condition of type SIMPLE-ERROR]
Hmm, if you blew the file path and configged in that bogus file value on
the movie widget it might just ignore it and then leave the movie
undisplayed and then when the "play" command comes along it just says
"not displayed", not "bogus movie path".
> |
> | 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 @ #x210a04f2>
> | #<Function SWANK-DEBUGGER-HOOK>)
> | 1: (ERROR "Tcl error: ~a" "Movie not displayed")
> | 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 299581936
> | ".f1096.f1099.f1125.f1130.f1134.play-me
> play" -1 0)
> | 5: (CELTK::TCL-EVAL-EX 299581936
> | ".f1096.f1099.f1125.f1130.f1134.play-me
> play")
> | 6: (TK-FORMAT-NOW "~a play" ".f1096.f1099.f1125.f1130.f1134.play-
> me")
> | 7: ((FLET TK-FORMAT CELTK::DO-IT))
> | 8: ((:INTERNAL TK-FORMAT 0) :USER-Q (:FINI PLAY-ME))
> | 9: (TK-USER-QUEUE-HANDLER
> | (NIL ((:FINI PLAY-ME) . #<Closure # @ #x2109e872>)))
> | 10: (CELLS::FINISH-BUSINESS)
> | 11: (CELLS::CALL-WITH-INTEGRITY :CHANGE .VALUE
> | #<Closure (:INTERNAL (SETF CELLS::MD-SLOT-VALUE) 0) @
> #x210985fa>)
> | 12: ((SETF CELLS::MD-SLOT-VALUE) "bush" ENTER-ME .VALUE)
> `---------
>
> I guess, unless you see something more likely here, I've really gotta
> stick my fingers in Tcl/Tk, check if my QuickTimeTcl is working fine,
The way cool thing is that we can run wish (or wish85 in my case) and
just do the package require, the movie command, pack, and the play
command interactively
package require QuickTimeTcl
movie .m -file whatever
pack .m
.m play
(From memory).
best of luck.
kzo
--
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
On Feb 1, 1:36 am, Ken Tilton <·········@gmail.com> wrote:
> Edgar Gonçalves wrote:
> >>For now, you gots to push da button.
>
> > Ah, that sort of starts making some sense. The problem is, I don't get
> > these buttons visible.
>
> Ah, now /that/ is inconceivable. :) Do you get two list boxes
> side-by-side to the right of and a little lower than a one-line "Four
> score and seven years ago" label?
That's a negative... Below that one-line label I have the echo box and
it's label on the right. below that (where I think the buttons and
movies should be), there's a big blank, only!
>
> Your next bit confirms that the movie widget is in the Lisp GUI
> hierarchy at least, because the movie widget has a rule that watches the
> entry field (unless you missed my update and got (crazy) version where
> the entry widget pushed movies to the movie widget, but that would not
> work either if it was not there in the Lisp hierarchy).
>
> To see if Tcl is being told about the existence of the movie, try this
> for tk-format-now (so you can watch traffic going to TCL via Tcl_Eval
> (which is how Tk instances get created and packed):
>
> (defun tk-format-now (fmt$ &rest fmt-args)
> (unless (find *tkw* *windows-destroyed*)
> (let* ((*print-circle* nil)
> (tk$ (apply 'format nil fmt$ fmt-args)))
> (let ((yes '("play-me"))
> (no '()))
> (declare (ignorable yes no))
> (when (find-if (lambda (s) (search s tk$)) yes)
> (format t "~&tk> ~a~%" tk$)))
> (assert *tki*)
> (setf *tk-last* tk$)
> (tcl-eval-ex *tki* tk$))))
>
> I get this output starting up:
>
> movie .f1525.f1528.f1554.f1559.f1563.play-me -palindromeloopstate 0
> -loopstate 0 -file "c:/0dev/celtk/good-thing2.mov"
>
> pack .f1525.f1528.f1554.f1559.f1563.f1607
> .f1525.f1528.f1554.f1559.f1563.f1608
> .f1525.f1528.f1554.f1559.f1563.play-me -side top -anchor nw -padx 0 -pady 0
>
> Minor diffs might be OK, I have been horsing around since the last
> commit. Also, consider updating from CVS. Lotsa-widgets now ends (sorry
> about the formatting):
>
> (mk-stack ()
> (duelling-scrolled-lists)
> (mk-row ()
> (mk-button-ex ("Serious Demo" (plug-n-play-movie (fm^ :play-me)
> "c:/0dev/celtk/demo.mov")))
> (mk-button-ex ("Celtk?" (plug-n-play-movie (fm^ :play-me)
> "c:/0dev/celtk/good-thing2.mov"))))
>
> (mk-movie :id :play-me
> :loopstate (c-in 0) :palindromeloopstate (c-in 0)
> :tk-file (c? (let ((entry (fm^v :enter-me)))
> (cond
> ((find entry '("bush" "war" "anger" "hate") :test
> 'string-equal)
> "c:/0dev/celtk/demo.mov")
> ((find entry '("sex" "drugs" "rock-n-roll" "peace")
> :test 'string-equal)
> "c:/0dev/celtk/good-thing2.mov")
> (t "c:/0dev/celtk/good-thing2.mov" #+not .cache))))))
I have the latest from CVS, and I have the same movie and pack lines
on startup. Really, everything looks fine, except that there's no
visible proof of the videos or their buttons (basically, that stack) :
\
>
> Final thought: if the movie is created without a file or url, it is
> invisible, then it appears when one configures in a file and plays. In
> an early version I just had a movie, no play buttons. But then typing in
> the entry field should work.
>
> > However, oddly enough, typing bush, war anger,
> > hate (but not sex, drugs, etc!)
>
> The rule defaults to the same movie played for sex etc, and Cells does
> not react if a rule recalculates the same (eql, by default) value it
> had. I guess the identical string literals are EQL.
Check, I just confirmed that. So text-box triggers movie playback
properly. The video is still missing, though...
>
> Or maybe you fixed one path but not the other?
Nop, the file paths are correct, I triple-checked that.
>
> I'd worry about those missing buttons first. Give one of them an id and
> then add that to the watch list in tk-format-now. I just tested with:
>
> (mk-button-ex ("Serious Demo"
> (plug-n-play-movie (fm^ :play-me
> "c:/0dev/celtk/demo.mov"))
> :id :serious-demo)
>
> Hey, my trace shows that as a tile button (see the ttk?):
>
> ttk::button .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo -command
> "do-on-command .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo" -text
> "Serious Demo"
I got the same trace.
>
> Try defeating tile by specifying :tile? nil in
>
> (deftk tk-object.....)
Why should tile be defeated? Didn't get that, sorry.
>
> > triggers the same movie playback
> > action, and it gives me an error:
> > ,---------
> > | Tcl error: Movie not displayed
> > | [Condition of type SIMPLE-ERROR]
>
> Hmm, if you blew the file path and configged in that bogus file value on
> the movie widget it might just ignore it and then leave the movie
> undisplayed and then when the "play" command comes along it just says
> "not displayed", not "bogus movie path".
Actually, if I put in an invalid path, I get this:
,---------
| Tcl error: Error in user parameter list
| [Condition of type SIMPLE-ERROR]
`---------
So that's not really the problem either :(
>
>
>
> > |
> > | 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 @ #x210a04f2>
> > | #<Function SWANK-DEBUGGER-HOOK>)
> > | 1: (ERROR "Tcl error: ~a" "Movie not displayed")
> > | 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 299581936
> > | ".f1096.f1099.f1125.f1130.f1134.play-me
> > play" -1 0)
> > | 5: (CELTK::TCL-EVAL-EX 299581936
> > | ".f1096.f1099.f1125.f1130.f1134.play-me
> > play")
> > | 6: (TK-FORMAT-NOW "~a play" ".f1096.f1099.f1125.f1130.f1134.play-
> > me")
> > | 7: ((FLET TK-FORMAT CELTK::DO-IT))
> > | 8: ((:INTERNAL TK-FORMAT 0) :USER-Q (:FINI PLAY-ME))
> > | 9: (TK-USER-QUEUE-HANDLER
> > | (NIL ((:FINI PLAY-ME) . #<Closure # @ #x2109e872>)))
> > | 10: (CELLS::FINISH-BUSINESS)
> > | 11: (CELLS::CALL-WITH-INTEGRITY :CHANGE .VALUE
> > | #<Closure (:INTERNAL (SETF CELLS::MD-SLOT-VALUE) 0) @
> > #x210985fa>)
> > | 12: ((SETF CELLS::MD-SLOT-VALUE) "bush" ENTER-ME .VALUE)
> > `---------
>
> > I guess, unless you see something more likely here, I've really gotta
> > stick my fingers in Tcl/Tk, check if my QuickTimeTcl is working fine,
>
> The way cool thing is that we can run wish (or wish85 in my case) and
> just do the package require, the movie command, pack, and the play
> command interactively
>
> package require QuickTimeTcl
> movie .m -file whatever
> pack .m
> .m play
>
> (From memory).
Ok, QuickTimeTcl is, indeed, working properly... these instructions
shows up both videos you have on the celtk dir (with the paths I'm
using in lotsa-widgets, too).
As you've said, let's start at the buttons - any clues on what I may
have to check in order to see them?
On Feb 1, 12:19 pm, "Edgar Gonçalves" <···············@gmail.com>
wrote:
> On Feb 1, 1:36 am, Ken Tilton <·········@gmail.com> wrote:> Edgar Gonçalves wrote:
> > >>For now, you gots to push da button.
>
> > > Ah, that sort of starts making some sense. The problem is, I don't get
> > > these buttons visible.
>
> > Ah, now /that/ is inconceivable. :) Do you get two list boxes
> > side-by-side to the right of and a little lower than a one-line "Four
> > score and seven years ago" label?
>
> That's a negative... Below that one-line label I have the echo box and
> it's label on the right. below that (where I think the buttons and
> movies should be), there's a big blank, only!
>
>
>
>
>
> > Your next bit confirms that the movie widget is in the Lisp GUI
> > hierarchy at least, because the movie widget has a rule that watches the
> > entry field (unless you missed my update and got (crazy) version where
> > the entry widget pushed movies to the movie widget, but that would not
> > work either if it was not there in the Lisp hierarchy).
>
> > To see if Tcl is being told about the existence of the movie, try this
> > for tk-format-now (so you can watch traffic going to TCL via Tcl_Eval
> > (which is how Tk instances get created and packed):
>
> > (defun tk-format-now (fmt$ &rest fmt-args)
> > (unless (find *tkw* *windows-destroyed*)
> > (let* ((*print-circle* nil)
> > (tk$ (apply 'format nil fmt$ fmt-args)))
> > (let ((yes '("play-me"))
> > (no '()))
> > (declare (ignorable yes no))
> > (when (find-if (lambda (s) (search s tk$)) yes)
> > (format t "~&tk> ~a~%" tk$)))
> > (assert *tki*)
> > (setf *tk-last* tk$)
> > (tcl-eval-ex *tki* tk$))))
>
> > I get this output starting up:
>
> > movie .f1525.f1528.f1554.f1559.f1563.play-me -palindromeloopstate 0
> > -loopstate 0 -file "c:/0dev/celtk/good-thing2.mov"
>
> > pack .f1525.f1528.f1554.f1559.f1563.f1607
> > .f1525.f1528.f1554.f1559.f1563.f1608
> > .f1525.f1528.f1554.f1559.f1563.play-me -side top -anchor nw -padx 0 -pady 0
>
> > Minor diffs might be OK, I have been horsing around since the last
> > commit. Also, consider updating from CVS. Lotsa-widgets now ends (sorry
> > about the formatting):
>
> > (mk-stack ()
> > (duelling-scrolled-lists)
> > (mk-row ()
> > (mk-button-ex ("Serious Demo" (plug-n-play-movie (fm^ :play-me)
> > "c:/0dev/celtk/demo.mov")))
> > (mk-button-ex ("Celtk?" (plug-n-play-movie (fm^ :play-me)
> > "c:/0dev/celtk/good-thing2.mov"))))
>
> > (mk-movie :id :play-me
> > :loopstate (c-in 0) :palindromeloopstate (c-in 0)
> > :tk-file (c? (let ((entry (fm^v :enter-me)))
> > (cond
> > ((find entry '("bush" "war" "anger" "hate") :test
> > 'string-equal)
> > "c:/0dev/celtk/demo.mov")
> > ((find entry '("sex" "drugs" "rock-n-roll" "peace")
> > :test 'string-equal)
> > "c:/0dev/celtk/good-thing2.mov")
> > (t "c:/0dev/celtk/good-thing2.mov" #+not .cache))))))
>
> I have the latest from CVS, and I have the same movie and pack lines
> on startup. Really, everything looks fine, except that there's no
> visible proof of the videos or their buttons (basically, that stack) :
> \
>
>
>
> > Final thought: if the movie is created without a file or url, it is
> > invisible, then it appears when one configures in a file and plays. In
> > an early version I just had a movie, no play buttons. But then typing in
> > the entry field should work.
>
> > > However, oddly enough, typing bush, war anger,
> > > hate (but not sex, drugs, etc!)
>
> > The rule defaults to the same movie played for sex etc, and Cells does
> > not react if a rule recalculates the same (eql, by default) value it
> > had. I guess the identical string literals are EQL.
>
> Check, I just confirmed that. So text-box triggers movie playback
> properly. The video is still missing, though...
>
> > Or maybe you fixed one path but not the other?
>
> Nop, the file paths are correct, I triple-checked that.
>
>
>
> > I'd worry about those missing buttons first. Give one of them an id and
> > then add that to the watch list in tk-format-now. I just tested with:
>
> > (mk-button-ex ("Serious Demo"
> > (plug-n-play-movie (fm^ :play-me
> > "c:/0dev/celtk/demo.mov"))
> > :id :serious-demo)
>
> > Hey, my trace shows that as a tile button (see the ttk?):
>
> > ttk::button .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo -command
> > "do-on-command .f2116.f2119.f2145.f2150.f2154.f2199.serious-demo" -text
> > "Serious Demo"
>
> I got the same trace.
>
> > Try defeating tile by specifying :tile? nil in
>
> > (deftk tk-object.....)
>
> Why should tile be defeated? Didn't get that, sorry.
>
>
>
> > > triggers the same movie playback
> > > action, and it gives me an error:
> > > ,---------
> > > | Tcl error: Movie not displayed
> > > | [Condition of type SIMPLE-ERROR]
>
> > Hmm, if you blew the file path and configged in that bogus file value on
> > the movie widget it might just ignore it and then leave the movie
> > undisplayed and then when the "play" command comes along it just says
> > "not displayed", not "bogus movie path".
>
> Actually, if I put in an invalid path, I get this:
> ,---------
> | Tcl error: Error in user parameter list
> | [Condition of type SIMPLE-ERROR]
> `---------
> So that's not really the problem either :(
>
>
>
>
>
> > > |
> > > | 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 @ #x210a04f2>
> > > | #<Function SWANK-DEBUGGER-HOOK>)
> > > | 1: (ERROR "Tcl error: ~a" "Movie not displayed")
> > > | 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 299581936
> > > | ".f1096.f1099.f1125.f1130.f1134.play-me
> > > play" -1 0)
> > > | 5: (CELTK::TCL-EVAL-EX 299581936
> > > | ".f1096.f1099.f1125.f1130.f1134.play-me
> > > play")
> > > | 6: (TK-FORMAT-NOW "~a play" ".f1096.f1099.f1125.f1130.f1134.play-
> > > me")
> > > | 7: ((FLET TK-FORMAT CELTK::DO-IT))
> > > | 8: ((:INTERNAL TK-FORMAT 0) :USER-Q (:FINI PLAY-ME))
> > > | 9: (TK-USER-QUEUE-HANDLER
> > > | (NIL ((:FINI PLAY-ME) . #<Closure # @ #x2109e872>)))
> > > | 10: (CELLS::FINISH-BUSINESS)
> > > | 11: (CELLS::CALL-WITH-INTEGRITY :CHANGE .VALUE
> > > | #<Closure (:INTERNAL (SETF CELLS::MD-SLOT-VALUE) 0) @
> > > #x210985fa>)
> > > | 12: ((SETF CELLS::MD-SLOT-VALUE) "bush" ENTER-ME .VALUE)
> > > `---------
>
> > > I guess, unless you see something more likely here, I've really gotta
> > > stick my fingers in Tcl/Tk, check if my QuickTimeTcl is working fine,
>
> > The way cool thing is that we can run wish (or wish85 in my case) and
> > just do the package require, the movie command, pack, and the play
> > command interactively
>
> > package require QuickTimeTcl
> > movie .m -file whatever
> > pack .m
> > .m play
>
> > (From memory).
>
> Ok, QuickTimeTcl is, indeed, working properly... these instructions
> shows up both videos you have on the celtk dir (with the paths I'm
> using in lotsa-widgets, too).
>
> As you've said, let's start at the buttons - any clues on what I may
> have to check in order to see them?
Ok, I've found my problem... Now I can't remember if you already had
this in your code or if I messed with it inadvertedly when changing
movie paths. So apparently movies won't play if they are not visible
- and that's what was happening, because the stack with the duelling-
lists, the buttons and the movie was the last element of the previous
row, so it was on the right side of the window (outside it!). Arrgh,
these things are hard to catch... I'm really sorry for the lost time
on this, Ken!
My next free time will be dedicated to exploring both cells and celtk,
learn to do some tcl/tk magic by myself :)
---
Edgar Gonçalves
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <vprwh.10$eV.5@newsfe11.lga>
Edgar Gon�alves wrote:
> Ok, I've found my problem... Now I can't remember if you already had
> this in your code or if I messed with it inadvertedly when changing
> movie paths. So apparently movies won't play if they are not visible
> - and that's what was happening, because the stack with the duelling-
> lists, the buttons and the movie was the last element of the previous
> row, so it was on the right side of the window (outside it!).
Hmmmm. I thought the packing instructions were such that the window
would always be big enough...maybe not, maybe I just hardcoded something
"way big" and system differences are pushing them offscreen.
> My next free time will be dedicated to exploring both cells and celtk,
> learn to do some tcl/tk magic by myself :)
Not gonna try for Celtk3d and the Gears demo? :)
You'll need cl-opengl from c-l.net for that. But lotsa-widgets has both
lotsa widgets and shows them interconnecting thru The Miracle of Cells,
so it is a better resource.
kzo
--
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
On Feb 1, 7:43 pm, Ken Tilton <·········@gmail.com> wrote:
> Edgar Gonçalves wrote:
> > Ok, I've found my problem... Now I can't remember if you already had
> > this in your code or if I messed with it inadvertedly when changing
> > movie paths. So apparently movies won't play if they are not visible
> > - and that's what was happening, because the stack with the duelling-
> > lists, the buttons and the movie was the last element of the previous
> > row, so it was on the right side of the window (outside it!).
>
> Hmmmm. I thought the packing instructions were such that the window
> would always be big enough...maybe not, maybe I just hardcoded something
> "way big" and system differences are pushing them offscreen.
>
> > My next free time will be dedicated to exploring both cells and celtk,
> > learn to do some tcl/tk magic by myself :)
>
> Not gonna try for Celtk3d and the Gears demo? :)
> You'll need cl-opengl from c-l.net for that. But lotsa-widgets has both
> lotsa widgets and shows them interconnecting thru The Miracle of Cells,
> so it is a better resource.
Ahh, I got bored. Celtk3D and Gears are happily rotating on my screen!
I gotta say, if you're planning to achieve world domination with this
thing, there's a few things that I'd put high on the priority list:
- Get things organized: main package, examples, docs, separate them
all in directories - oh wait, there's no docs... on to the next
point...
- docs! :) You don't want to start a thread every time someone tries
to load celltk. Ok, it's good to keep track of how many of us *are*
trying, but I think that wouldn't scale very well, world-domination-
wise...
- Get the *.asd up-to-date. Exactly why do you prefer lpr's over asd?
Even with ACL, I've only used asdf to get things running.
Well, I'm quite happy with the results I've got. Now there's *the*
main problem. How am I running this with a free CL implementation. I
know, I know, don't mention SteelBank's projects ;) Relax, I'll see
what I can come up with, and when (if) I can, I'll post some results.
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <%Kwwh.55$k7.30@newsfe10.lga>
Edgar Gon�alves wrote:
> On Feb 1, 7:43 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>Edgar Gon�alves wrote:
>>
>>>Ok, I've found my problem... Now I can't remember if you already had
>>>this in your code or if I messed with it inadvertedly when changing
>>>movie paths. So apparently movies won't play if they are not visible
>>>- and that's what was happening, because the stack with the duelling-
>>>lists, the buttons and the movie was the last element of the previous
>>>row, so it was on the right side of the window (outside it!).
>>
>>Hmmmm. I thought the packing instructions were such that the window
>>would always be big enough...maybe not, maybe I just hardcoded something
>> "way big" and system differences are pushing them offscreen.
>>
>>
>>>My next free time will be dedicated to exploring both cells and celtk,
>>>learn to do some tcl/tk magic by myself :)
>>
>>Not gonna try for Celtk3d and the Gears demo? :)
>>You'll need cl-opengl from c-l.net for that. But lotsa-widgets has both
>>lotsa widgets and shows them interconnecting thru The Miracle of Cells,
>>so it is a better resource.
>
>
> Ahh, I got bored. Celtk3D and Gears are happily rotating on my screen!
Ah, yer getting good at building kennyware.
3D is cool, right? I do not know why, but 3D really knocks my socks off.
Sound, too. But I do not think any of the demos have sound till you get
to Cello.
> I gotta say, if you're planning to achieve world domination with this
> thing,
No, that is just fun trash-talking and spreading-the-news for those like
you who Really Want It and will not be deterred by a few install issues.
There is no money in tools thanks to RMS, so the right thing to do with
great tools like Lisp, Cells, or Celltk is -- as Paul Graham said -- use
the tools to create a killer app in some niche.
My niche is an interactive educational Algebra environment.
> there's a few things that I'd put high on the priority list:
> - Get things organized: main package, examples, docs, separate them
> all in directories - oh wait, there's no docs... on to the next
> point...
> - docs! :) You don't want to start a thread every time someone tries
> to load celltk. Ok, it's good to keep track of how many of us *are*
> trying, but I think that wouldn't scale very well, world-domination-
> wise...
> - Get the *.asd up-to-date. Exactly why do you prefer lpr's over asd?
> Even with ACL, I've only used asdf to get things running.
The project manager is integrated with the IDE in useful ways. Besides,
ASDF does not know how to build software.
>
> Well, I'm quite happy with the results I've got. Now there's *the*
> main problem. How am I running this with a free CL implementation.
I think I mentioned that my application built atop an even tougher
challenge -- the diabolical Cello sitting atop Celtk -- was successfully
built and run by a co-worker using SBCL on OS X.
> I
> know, I know, don't mention SteelBank's projects ;) Relax, I'll see
> what I can come up with, and when (if) I can, I'll post some results.
>
Well, now that you have one version working that should give you a
control to help get a second version working. Michael broke the GC with
ltktest-ci, and I have to think that is related to Lisp->C->Lisp
callbacks, a relatively recent addition to the CMUCL family. There's one
issue to keep in mind.
--
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
On Feb 2, 1:47 am, Ken Tilton <·········@gmail.com> wrote:
> Edgar Gonçalves wrote:
> > On Feb 1, 7:43 pm, Ken Tilton <·········@gmail.com> wrote:
>
> >>Edgar Gonçalves wrote:
>
> >>>Ok, I've found my problem... Now I can't remember if you already had
> >>>this in your code or if I messed with it inadvertedly when changing
> >>>movie paths. So apparently movies won't play if they are not visible
> >>>- and that's what was happening, because the stack with the duelling-
> >>>lists, the buttons and the movie was the last element of the previous
> >>>row, so it was on the right side of the window (outside it!).
>
> >>Hmmmm. I thought the packing instructions were such that the window
> >>would always be big enough...maybe not, maybe I just hardcoded something
> >> "way big" and system differences are pushing them offscreen.
>
> >>>My next free time will be dedicated to exploring both cells and celtk,
> >>>learn to do some tcl/tk magic by myself :)
>
> >>Not gonna try for Celtk3d and the Gears demo? :)
> >>You'll need cl-opengl from c-l.net for that. But lotsa-widgets has both
> >>lotsa widgets and shows them interconnecting thru The Miracle of Cells,
> >>so it is a better resource.
>
> > Ahh, I got bored. Celtk3D and Gears are happily rotating on my screen!
>
> Ah, yer getting good at building kennyware.
>
> 3D is cool, right? I do not know why, but 3D really knocks my socks off.
> Sound, too. But I do not think any of the demos have sound till you get
> to Cello.
>
> > I gotta say, if you're planning to achieve world domination with this
> > thing,
>
> No, that is just fun trash-talking and spreading-the-news for those like
> you who Really Want It and will not be deterred by a few install issues.
>
> There is no money in tools thanks to RMS, so the right thing to do with
> great tools like Lisp, Cells, or Celltk is -- as Paul Graham said -- use
> the tools to create a killer app in some niche.
>
> My niche is an interactive educational Algebra environment.
>
> > there's a few things that I'd put high on the priority list:
> > - Get things organized: main package, examples, docs, separate them
> > all in directories - oh wait, there's no docs... on to the next
> > point...
> > - docs! :) You don't want to start a thread every time someone tries
> > to load celltk. Ok, it's good to keep track of how many of us *are*
> > trying, but I think that wouldn't scale very well, world-domination-
> > wise...
> > - Get the *.asd up-to-date. Exactly why do you prefer lpr's over asd?
> > Even with ACL, I've only used asdf to get things running.
>
> The project manager is integrated with the IDE in useful ways. Besides,
> ASDF does not know how to build software.
True. But i guess I'd prefer to have an asd file and a build.lisp -
that should be portable, at least. But hey, right now that's not
really important for me (since I got it running on acl already!)
>
>
>
> > Well, I'm quite happy with the results I've got. Now there's *the*
> > main problem. How am I running this with a free CL implementation.
>
> I think I mentioned that my application built atop an even tougher
> challenge -- the diabolical Cello sitting atop Celtk -- was successfully
> built and run by a co-worker using SBCL on OS X.
Ahh, where can I get cello? I'd like to give it a go, eventually, just
to see what the whole fuzz is about! :)
>
> > I
>
> > know, I know, don't mention SteelBank's projects ;) Relax, I'll see
> > what I can come up with, and when (if) I can, I'll post some results.
>
> Well, now that you have one version working that should give you a
> control to help get a second version working. Michael broke the GC with
> ltktest-ci, and I have to think that is related to Lisp->C->Lisp
> callbacks, a relatively recent addition to the CMUCL family. There's one
> issue to keep in mind.
Yap, you're probably right, I got to the same conclusion myself. Even
with a simple widget (i.e., no tile, no quicktimetcl, etc), I get an
empty window and a segmentation fault-like error, and I was blaming
callbacks for it. So, while sbcl grows, I'll try ECL (never tried it,
though, so I don't know what I'm getting into).
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <BDywh.67$k7.52@newsfe10.lga>
Edgar Gon�alves wrote:
> True. But i guess I'd prefer to have an asd file and a build.lisp -
> that should be portable, at least.
There is that. But I /live/ with the project manager 24x7 and get its
benefits, whereas persuading ASDF to build the same thing (once I go to
port) is just an hour of yobbo-cussing.
> Yap, you're probably right, I got to the same conclusion myself. Even
> with a simple widget (i.e., no tile, no quicktimetcl, etc), I get an
> empty window and a segmentation fault-like error, and I was blaming
> callbacks for it. So, while sbcl grows, I'll try ECL (never tried it,
> though, so I don't know what I'm getting into).
>
Yeah, come to think of it, the paint is pretty fresh on SBCL/win32,
isn't it? You might send them some kennyware as a stress test to help
them polish the implementation. They will love that.
What about CLisp? It runs Cells-Gtk with true callbacks.
[Hey, try running Cells-Gtk on SBCL/win32:
http://common-lisp.net/project/cells-gtk/
...damn, nice web page!]
Otoh, if the ECL maintainer(s?) are still on the case you could join
forces.
Cello? Wow, I just found this: http://common-lisp.net/project/cello/
Of course you should ignore that and look in CVS for a tarball. That
just requires GraphicsMagick, FTGL, some C glue for FTGL, OpenAL, and I
wonder if I forgot one. I always forget one. Then someday you might have
this running on your system: http://www.tilton-technology.com/jmcube.jpg
OpenGL, Image files as pixmaps or textures, sound in 3D, and arbitrary
fonts in seven modes, two of them anti-aliased, most of them rotatable
in 3D. Woohoo! Pretty weak widget set, but the code for the ones that do
exist show how to roll your own in your sleep.
Basically, anyone who can get by with a typical boring GUI should use
Celtk, Cello is just for nutjobs on a mission from God or something.
kenzo
--
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
Ok, I've come to a sad, but true conclusion. I cannot rely on SBCL for
FFI's on windows. This applies to celtk, cell-gtk, etc, but also to
some aspects of cl-sql. And, I cannot use clisp to build executable
binaries (even with sbcl, they would be huge, when all I want could
run in a couple of hundred kilobytes...). I can't get ECL to work
either, so that pretty much sums my free CL alternatives (am I missing
anything?). Ergo, I must turn to the next best thing for me: Python.
It's free, portable, well stacked with api's for pretty much
everything I need. And, it produces binary executables just fine.
Arrg, I hate to do this, but I have no time to solve all issues with
the CL way :(
Maybe for my next project I can play with celtk again. In the
meanwhile, it'll be just a hobby - I'm kinda growing into cells, and
it's applicability in user interfaces!
Thanks for the support, Ken, you've been great. If you need any help I
can give, just say so!
Edgar
In article <························@h3g2000cwc.googlegroups.com>,
"Edgar Gon�alves" <···············@gmail.com> wrote:
> And, I cannot use clisp to build executable
> binaries
You certainly can:
http://clisp.cons.org/impnotes/image.html
Note the :EXECUTABLE parameter. CLISP's executables also tend to be a
good deal smaller than SBCL's.
On Feb 7, 2:33 am, Bill Atkins <················@not-a-real-
domain.com> wrote:
> In article <························@h3g2000cwc.googlegroups.com>,
> "Edgar Gonçalves" <···············@gmail.com> wrote:
>
> > And, I cannot use clisp to build executable
> > binaries
>
> You certainly can:
>
> http://clisp.cons.org/impnotes/image.html
>
> Note the :EXECUTABLE parameter. CLISP's executables also tend to be a
> good deal smaller than SBCL's.
(sorry for the delayed reply)
My bad, yes, it produces windows binaries with sizes 1/6 of the sbcl's
binaries. And it works great for some cases, but there's a bug in the
latest clisp+clsql+ffi combination that makes it quite unusable: even
though I can get everything to work on clisp, the executable isn't
able to deal with foreign functions properly - it gives me this error:
** - Continuable Error
FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
library
:DEFAULT
But I suppose this should be fixable, and in the meanwhile I know I
can use clisp scripts to get things automated.
About the ffi issue, has anyone found a similar problem? I thought I
could workarround it by loading the library by hand in my clisp image
initial-function, with
(cffi:define-foreign-library odbc (t (:default "odbc32")))
(cffi:use-foreign-library odbc)
but then I get something like this:
*** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
comes from
a previous Lisp session and is invalid
This comes when calling the SqlAllocHandle foreign function from lisp,
but I don't know what might be going on. Has anyone got this issue out
of the way, yet? If so, how? :)
On Feb 10, 10:24 pm, "Edgar Gonçalves" <···············@gmail.com>
wrote:
> On Feb 7, 2:33 am, Bill Atkins <················@not-a-real-
>
> domain.com> wrote:
> > In article <························@h3g2000cwc.googlegroups.com>,
> > "Edgar Gonçalves" <···············@gmail.com> wrote:
>
> > > And, I cannot use clisp to build executable
> > > binaries
>
> > You certainly can:
>
> > http://clisp.cons.org/impnotes/image.html
>
> > Note the :EXECUTABLE parameter. CLISP's executables also tend to be a
> > good deal smaller than SBCL's.
>
> (sorry for the delayed reply)
>
> My bad, yes, it produces windows binaries with sizes 1/6 of the sbcl's
> binaries. And it works great for some cases, but there's a bug in the
> latest clisp+clsql+ffi combination that makes it quite unusable: even
> though I can get everything to work on clisp, the executable isn't
> able to deal with foreign functions properly - it gives me this error:
> ** - Continuable Error
> FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
> library
> :DEFAULT
>
> But I suppose this should be fixable, and in the meanwhile I know I
> can use clisp scripts to get things automated.
>
> About the ffi issue, has anyone found a similar problem? I thought I
> could workarround it by loading the library by hand in my clisp image
> initial-function, with
> (cffi:define-foreign-library odbc (t (:default "odbc32")))
> (cffi:use-foreign-library odbc)
>
> but then I get something like this:
> *** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
> comes from
> a previous Lisp session and is invalid
>
> This comes when calling the SqlAllocHandle foreign function from lisp,
> but I don't know what might be going on. Has anyone got this issue out
> of the way, yet? If so, how? :)
Ok, I've come up with a quick (somehow dirty) fix. The problem is
based on the library definition before the image creation - when we
load the image and try to access the defined library it won't find the
pointers. So my trick is solely to load the demanding module (in my
case, clsql) only after the image is loaded, not before. The following
does this (clsql is loaded in access.lisp):
(ext:saveinitmem "run-me.exe" :init-function #'(lambda () (load "c:\
\xpto\\access.lisp") (defpackage #:access (:use :cl) (:export #:main))
(access:main)) :NORC t :script t :executable t :quiet t)
Anyway, although this might do the trick for a while, it won't clear
the problem in cffi/clsql/clisp. But many, many thanks, Pascal and
Bill, for the hint!
I'll post some results, and maybe a howto, after I try a celtk
executable. It may not be as quick as I may wish, but if anyone needs
a hand on running this, just ask me (mail me) and I'll give my 2cts.
--
Edgar
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <7Gtzh.639$e26.475@newsfe10.lga>
Edgar Gon�alves wrote:
> On Feb 10, 10:24 pm, "Edgar Gon�alves" <···············@gmail.com>
> wrote:
>
>>On Feb 7, 2:33 am, Bill Atkins <················@not-a-real-
>>
>>domain.com> wrote:
>>
>>>In article <························@h3g2000cwc.googlegroups.com>,
>>> "Edgar Gon�alves" <···············@gmail.com> wrote:
>>
>>>>And, I cannot use clisp to build executable
>>>>binaries
>>
>>>You certainly can:
>>
>>> http://clisp.cons.org/impnotes/image.html
>>
>>>Note the :EXECUTABLE parameter. CLISP's executables also tend to be a
>>>good deal smaller than SBCL's.
>>
>>(sorry for the delayed reply)
>>
>>My bad, yes, it produces windows binaries with sizes 1/6 of the sbcl's
>>binaries. And it works great for some cases, but there's a bug in the
>>latest clisp+clsql+ffi combination that makes it quite unusable: even
>>though I can get everything to work on clisp, the executable isn't
>>able to deal with foreign functions properly - it gives me this error:
>>** - Continuable Error
>>FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
>>library
>> :DEFAULT
>>
>>But I suppose this should be fixable, and in the meanwhile I know I
>>can use clisp scripts to get things automated.
>>
>>About the ffi issue, has anyone found a similar problem? I thought I
>>could workarround it by loading the library by hand in my clisp image
>>initial-function, with
>>(cffi:define-foreign-library odbc (t (:default "odbc32")))
>>(cffi:use-foreign-library odbc)
>>
>>but then I get something like this:
>>*** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
>>comes from
>> a previous Lisp session and is invalid
>>
>>This comes when calling the SqlAllocHandle foreign function from lisp,
>>but I don't know what might be going on. Has anyone got this issue out
>>of the way, yet? If so, how? :)
>
>
> Ok, I've come up with a quick (somehow dirty) fix. The problem is
> based on the library definition before the image creation - when we
> load the image and try to access the defined library it won't find the
> pointers. So my trick is solely to load the demanding module (in my
> case, clsql) only after the image is loaded, not before. The following
> does this (clsql is loaded in access.lisp):
>
> (ext:saveinitmem "run-me.exe" :init-function #'(lambda () (load "c:\
> \xpto\\access.lisp") (defpackage #:access (:use :cl) (:export #:main))
> (access:main)) :NORC t :script t :executable t :quiet t)
>
> Anyway, although this might do the trick for a while, it won't clear
> the problem in cffi/clsql/clisp. But many, many thanks, Pascal and
> Bill, for the hint!
>
> I'll post some results, and maybe a howto, after I try a celtk
> executable. It may not be as quick as I may wish,
Well the good news is that your graphics should run as fast as anywhere,
since all that is handed off to OpenGL and hopefully a GPU. The OpenGL
/calls/ still need to be made, but originally I had my OpenGL GUIs
making heavy use of display-lists. Then you would not often even have to
run the Lisp code that renders any given subtree of the scene graph. I
backed off that during a firefight with OpenGL and have not gone back
yet -- too scared to try, and it is too fast without display lists.
And if you are i/o bound, hey, there again you give away nothing cuz the
bulk of the path is in SQL land.
All in all, with CLisp not being all /that/ slow, I cannot imagine a
native-compiled CL being noticeably faster. And since Python is
considered an alternative... :)
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
On Feb 11, 12:44 am, Ken Tilton <·········@gmail.com> wrote:
> Edgar Gonçalves wrote:
> > On Feb 10, 10:24 pm, "Edgar Gonçalves" <···············@gmail.com>
> > wrote:
>
> >>On Feb 7, 2:33 am, Bill Atkins <················@not-a-real-
>
> >>domain.com> wrote:
>
> >>>In article <························@h3g2000cwc.googlegroups.com>,
> >>> "Edgar Gonçalves" <···············@gmail.com> wrote:
>
> >>>>And, I cannot use clisp to build executable
> >>>>binaries
>
> >>>You certainly can:
>
> >>>http://clisp.cons.org/impnotes/image.html
>
> >>>Note the :EXECUTABLE parameter. CLISP's executables also tend to be a
> >>>good deal smaller than SBCL's.
>
> >>(sorry for the delayed reply)
>
> >>My bad, yes, it produces windows binaries with sizes 1/6 of the sbcl's
> >>binaries. And it works great for some cases, but there's a bug in the
> >>latest clisp+clsql+ffi combination that makes it quite unusable: even
> >>though I can get everything to work on clisp, the executable isn't
> >>able to deal with foreign functions properly - it gives me this error:
> >>** - Continuable Error
> >>FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
> >>library
> >> :DEFAULT
>
> >>But I suppose this should be fixable, and in the meanwhile I know I
> >>can use clisp scripts to get things automated.
>
> >>About the ffi issue, has anyone found a similar problem? I thought I
> >>could workarround it by loading the library by hand in my clisp image
> >>initial-function, with
> >>(cffi:define-foreign-library odbc (t (:default "odbc32")))
> >>(cffi:use-foreign-library odbc)
>
> >>but then I get something like this:
> >>*** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
> >>comes from
> >> a previous Lisp session and is invalid
>
> >>This comes when calling the SqlAllocHandle foreign function from lisp,
> >>but I don't know what might be going on. Has anyone got this issue out
> >>of the way, yet? If so, how? :)
>
> > Ok, I've come up with a quick (somehow dirty) fix. The problem is
> > based on the library definition before the image creation - when we
> > load the image and try to access the defined library it won't find the
> > pointers. So my trick is solely to load the demanding module (in my
> > case, clsql) only after the image is loaded, not before. The following
> > does this (clsql is loaded in access.lisp):
>
> > (ext:saveinitmem "run-me.exe" :init-function #'(lambda () (load "c:\
> > \xpto\\access.lisp") (defpackage #:access (:use :cl) (:export #:main))
> > (access:main)) :NORC t :script t :executable t :quiet t)
>
> > Anyway, although this might do the trick for a while, it won't clear
> > the problem in cffi/clsql/clisp. But many, many thanks, Pascal and
> > Bill, for the hint!
>
> > I'll post some results, and maybe a howto, after I try a celtk
> > executable. It may not be as quick as I may wish,
>
> Well the good news is that your graphics should run as fast as anywhere,
I meant /I/ won't probably be as quick as I would want to to try this
out :) But I agree, speed won't be problematic, since almost
everything is done directly in native libraries! Anyway, I treasure
the language much more than the speed it gives me. After all, Knuth
thought us "premature optimization is the root of all evil"!
Edgar
> > > I'll post some results, and maybe a howto, after I try a celtk
> > > executable.
Well not a full howto, but I've jotted up some notes on all problems I
had in the windows binary + MSaccess access + celtk + cffi, and posted
them here: http://carpathia.blogspot.com/2007/02/free-lisp-executables-
in-windows.html
Hope some more newbies like me won't get stuck where I did :)
--
Edgar Gonçalves
From: Ken Tilton
Subject: Today's Sermon... [was Re: clisp, clsql and foreign functions: problems in windows executables]
Date:
Message-ID: <zX1Bh.23$8q6.19@newsfe11.lga>
Edgar Gon�alves wrote:
>>>>I'll post some results, and maybe a howto, after I try a celtk
>>>>executable.
>
>
> Well not a full howto, but I've jotted up some notes on all problems I
> had in the windows binary + MSaccess access + celtk + cffi, and posted
> them here: http://carpathia.blogspot.com/2007/02/free-lisp-executables-
> in-windows.html
>
> Hope some more newbies like me won't get stuck where I did :)
I have been saying for a while that what Lisp needs is more newbies like
you who (a) care enough to fight the good fight and (b) then document
their work.
Too many people using free software view it as a one-way street. The
reality is that sharing code takes a surprising amout of effort. If
nothing comes back from that effort, the effort is a bad investment.
Peter Denno over on Cells-Gtk added value by documenting things as he
learned them, and he is just one of several people who have made it
worthwhile for me to share my code, Frank Goenninger being a stand-out.
The good news about Celtk/Cello is that they are being used heads down
to develop a serious and highly interactive application, so they are
getting a lot of attention. The bad news is that folks can forget about
getting any doc from me, that's my head that is down and anyway the open
source fairy has left the building.
let us pray.
kzo
ps. No screenshots? http://www.tilton-technology.com/cello-shot-06.jpg
--
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
From: Sam Steingold
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <m3abzlsh6k.fsf@loiso.podval.org>
> * Edgar Gonçalves <···············@tznvy.pbz> [2007-02-10 14:24:29 -0800]:
>
> ** - Continuable Error
> FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
> library
> :DEFAULT
this is because SQLAllocHandle is not in libc, but in odbc, so it has to
be defined with
(def-call-out ... (:library "odbc") )
or something similar.
http://clisp.cons.org/impnotes/dffi.html#dffi-default-lib
http://clisp.cons.org/impnotes/dffi.html#def-call-out
> But I suppose this should be fixable, and in the meanwhile I know I
> can use clisp scripts to get things automated.
>
> About the ffi issue, has anyone found a similar problem? I thought I
> could workarround it by loading the library by hand in my clisp image
> initial-function, with
> (cffi:define-foreign-library odbc (t (:default "odbc32")))
> (cffi:use-foreign-library odbc)
I don't know CFFI, so it would help if you posted what this expand to in
CLISP.
--
Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod)
http://camera.org http://memri.org http://ffii.org http://palestinefacts.org
http://thereligionofpeace.com http://jihadwatch.org http://honestreporting.com
20% of people do 80% of work; also 80% of people think they are in those 20%.
On Feb 10, 11:53 pm, Sam Steingold <····@gnu.org> wrote:
> > * Edgar Gonçalves <···············@tznvy.pbz> [2007-02-10 14:24:29 -0800]:
>
> > ** - Continuable Error
> > FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
> > library
> > :DEFAULT
>
> this is because SQLAllocHandle is not in libc, but in odbc, so it has to
> be defined with
> (def-call-out ... (:library "odbc") )
> or something similar.http://clisp.cons.org/impnotes/dffi.html#dffi-default-libhttp://clisp.cons.org/impnotes/dffi.html#def-call-out
Actually, clsql is doing it using this (odbc-ff-interface.lisp):
(def-function "SQLAllocHandle"
((handle-type :short)
(input-handle sql-handle)
(*phenv sql-handle-ptr))
:module "odbc"
:returning :short)
which can be understood, with uffi-compat.lisp's macro:
(defmacro def-function (name args &key module (returning :void))
"Define a foreign function."
(declare (ignore module))
`(cffi:defcfun ,name ,(convert-uffi-type returning)
,@(loop for (name type) in args
collect `(,name ,(convert-uffi-type type)))))
My (small) experiments with other projects tells me that this form
works with most CL implementation. It even works with clisp, but only
if the function is executed in the same image run-time of the
definition (i.e., not when using a saved image with the already
defined function).
>
> > But I suppose this should be fixable, and in the meanwhile I know I
> > can use clisp scripts to get things automated.
>
> > About the ffi issue, has anyone found a similar problem? I thought I
> > could workarround it by loading the library by hand in my clisp image
> > initial-function, with
> > (cffi:define-foreign-library odbc (t (:default "odbc32")))
> > (cffi:use-foreign-library odbc)
>
> I don't know CFFI, so it would help if you posted what this expand to in
> CLISP.
Here it is:
** - Continuable Error
FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
library
:DEFAULT
If you continue (by typing 'continue'): Skip foreign object creation
Break 1 [1]> :bt
<1> #<SYSTEM-FUNCTION SHOW-STACK> 3
(......debugger-error-showing.........)
<10> #<SYSTEM-FUNCTION INVOKE-DEBUGGER>
<11> #<COMPILED-FUNCTION CERROR>
<12> #<SYSTEM-FUNCTION SYSTEM::CERROR-OF-TYPE> 6
<13> #<SYSTEM-FUNCTION FFI::FOREIGN-CALL-OUT> 4
<14> #<COMPILED-FUNCTION ODBC::SQLALLOCHANDLE>
<15> #<COMPILED-FUNCTION ODBC::%NEW-ENVIRONMENT-HANDLE-1>
<16> #<SYSTEM-FUNCTION FFI::EXEC-ON-STACK> 2
<17> #<COMPILED-FUNCTION ODBC:%NEW-ENVIRONMENT-HANDLE>
<18> #<COMPILED-FUNCTION ODBC-DBI:CONNECT>
<19>
#<COMPILED-FUNCTION
#:|38 63 (DEFMETHOD DATABASE-CONNECT (CONNECTION-SPEC
#) ...)-5-1-1-3|>
<20>
#<COMPILED-FUNCTION
#:|38 63 (DEFMETHOD DATABASE-CONNECT (CONNECTION-SPEC #) ...)-5-1-1|
>
<21> #<STANDARD-GENERIC-FUNCTION CLSQL-SYS:DATABASE-CONNECT>
<22> #<STANDARD-GENERIC-FUNCTION CLSQL-SYS:DATABASE-CONNECT>
<23> #<COMPILED-FUNCTION CLSQL-SYS:CONNECT>
<24> #<SPECIAL-OPERATOR PROGN>
EVAL frame for form
(PROGN (CLSQL-SYS:CONNECT '("testcl" "admin" "") :DATABASE-TYPE :ODBC)
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(CLSQL-SYS::%ENABLE-SQL-READER-SYNTAX))
(SETQ ACCESS::PEOPLE (CLSQL-SYS:SELECT 'ACCESS::PERSON)))
<25> #<SPECIAL-OPERATOR UNWIND-PROTECT>
EVAL frame for form
(UNWIND-PROTECT
(PROGN (CLSQL-SYS:CONNECT '("testcl" "admin" "") :DATABASE-
TYPE :ODBC)
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(CLSQL-SYS::%ENABLE-SQL-READER-SYNTAX))
(SETQ ACCESS::PEOPLE (CLSQL-SYS:SELECT 'ACCESS::PERSON)))
(CLSQL-SYS:DISCONNECT))
(.......application-specific/not-relevant........)
This has only pinpointed me what I already knew - the error occurs
when calling the foreign function. Do you need more information from
this error / are you onto something specific?
Thanks,
Edgar
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <vytzh.638$e26.299@newsfe10.lga>
Edgar Gon�alves wrote:
> On Feb 10, 11:53 pm, Sam Steingold <····@gnu.org> wrote:
>
>>>* Edgar Gon�alves <···············@tznvy.pbz> [2007-02-10 14:24:29 -0800]:
>>
>>>** - Continuable Error
>>>FFI::FOREIGN-CALL-OUT: no dynamic object named "SQLAllocHandle" in
>>>library
>>> :DEFAULT
>>
>>this is because SQLAllocHandle is not in libc, but in odbc, so it has to
>>be defined with
>>(def-call-out ... (:library "odbc") )
>>or something similar.http://clisp.cons.org/impnotes/dffi.html#dffi-default-libhttp://clisp.cons.org/impnotes/dffi.html#def-call-out
>
>
> Actually, clsql is doing it using this (odbc-ff-interface.lisp):
> (def-function "SQLAllocHandle"
> ((handle-type :short)
> (input-handle sql-handle)
> (*phenv sql-handle-ptr))
> :module "odbc"
> :returning :short)
>
>
> which can be understood, with uffi-compat.lisp's macro:
> (defmacro def-function (name args &key module (returning :void))
> "Define a foreign function."
> (declare (ignore module))
> `(cffi:defcfun ,name ,(convert-uffi-type returning)
> ,@(loop for (name type) in args
> collect `(,name ,(convert-uffi-type type)))))
>
> My (small) experiments with other projects tells me that this form
> works with most CL implementation. It even works with clisp, but only
> if the function is executed in the same image run-time of the
> definition (i.e., not when using a saved image with the already
> defined function).
This sounds much like the issue raised (only?) by cmucl/sbcl, namely
that those Lisps want the library loaded /before/ you DEFCFUN or its
ilk. So...
Are you still running with your code arranged to make sbcl happy? If so,
just move the lib loads into the /runtime/ app initialization code and
see what happens with clisp.
If that works and you aspire to portability, you'll need to featurize
your code so loading happens at the right time for each lib. Or the
yobbos could fix cmucl/sbcl.
hth,kzo
--
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
From: Sam Steingold
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <m3tzxtqutj.fsf@loiso.podval.org>
> * Edgar Gonçalves <···············@tznvy.pbz> [2007-02-10 16:23:26 -0800]:
>
>> I don't know CFFI, so it would help if you posted what this expand to in
>> CLISP.
what I meant was: do macroexpand until you have only clisp symbols in
the macroexpansion.
The bottom line is: the problem, IIUC, stems from the foreign function
is NOT being associated with the appropriate DLL, so when the image
restarts, it cannot recreate the foreign function.
This is, apparently, because CFFI opens the library separately and then
creates the foreign functions using RTLD_DEFAULT.
To make this work, you have to tell CLISP image to reopen the library on
startup, like this: (FFI::FOREIGN-LIBRARY "odbc").
see
http://clisp.cons.org/impnotes/custom-init-fini.html#init-hooks
http://clisp.cons.org/impnotes/image.html#init-func
--
Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod)
http://iris.org.il http://jihadwatch.org http://pmw.org.il
http://openvotingconsortium.org http://dhimmi.com http://ffii.org
Never trust a man who can count to 1024 on his fingers.
On Feb 11, 2:42 am, Sam Steingold <····@gnu.org> wrote:
> The bottom line is: the problem, IIUC, stems from the foreign function
> is NOT being associated with the appropriate DLL, so when the image
> restarts, it cannot recreate the foreign function.
> This is, apparently, because CFFI opens the library separately and then
> creates the foreign functions using RTLD_DEFAULT.
> To make this work, you have to tell CLISP image to reopen the library on
> startup, like this: (FFI::FOREIGN-LIBRARY "odbc").
> seehttp://clisp.cons.org/impnotes/custom-init-fini.html#init-hookshttp://clisp.cons.org/impnotes/image.html#init-func
I've been making some tests, and nothing seems to work except loading
the clsql code at image-startup. Even if I do the (FFI::FOREIGN-
LIBRARY "odbc32") in the CLISP init-hook, all it does is to tell clisp
where is the SqlAllocHandle code, but it somehow knows the pointer was
made in a previous session, then breaks with:
*** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
comes from a previous Lisp session and is invalid
I've read your thread with Rick Taube about this (http://
www.nabble.com/clisp-win32-and-(ffi::foreign-library-:default)-
t623140.html) , but I still can't figure it out.
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <BjIzh.4$JU2.0@newsfe11.lga>
Edgar Gon�alves wrote:
> On Feb 11, 2:42 am, Sam Steingold <····@gnu.org> wrote:
>
>>The bottom line is: the problem, IIUC, stems from the foreign function
>>is NOT being associated with the appropriate DLL, so when the image
>>restarts, it cannot recreate the foreign function.
>>This is, apparently, because CFFI opens the library separately and then
>>creates the foreign functions using RTLD_DEFAULT.
>>To make this work, you have to tell CLISP image to reopen the library on
>>startup, like this: (FFI::FOREIGN-LIBRARY "odbc").
>>seehttp://clisp.cons.org/impnotes/custom-init-fini.html#init-hookshttp://clisp.cons.org/impnotes/image.html#init-func
>
>
> I've been making some tests, and nothing seems to work except loading
> the clsql code at image-startup. Even if I do the (FFI::FOREIGN-
> LIBRARY "odbc32") in the CLISP init-hook, all it does is to tell clisp
> where is the SqlAllocHandle code, but it somehow knows the pointer was
> made in a previous session, then breaks with:
>
> *** - FFI::FOREIGN-CALL-OUT: #<INVALID FOREIGN-POINTER #x00000000>
> comes from a previous Lisp session and is invalid
>
> I've read your thread with Rick Taube about this (http://
> www.nabble.com/clisp-win32-and-(ffi::foreign-library-:default)-
> t623140.html) , but I still can't figure it out.
>
>
A meta-suggestion is to whittle it down to twenty-lines ending in a call
to SqlAllocHandle so folks can see what you are up to. It was not clear
to me that you were not /also/ loading the library in the saved image,
but seeing the null saved foreign pointer suggests you are not. A
twenty-liner would elim all such guessing.
A second meta-suggestion, perhaps already being followed, is to pester
the cffi list at the same time with this traffic, cross-sharing the
traffic somehow.
A concrete suggestion is that you must defer the defcfuns also. I think
it is legal to move the defcfun's inside the init function after the
use-foreign-library:
(defun init-sql ()
(use-foreign-library sql)
(defcfun...)
(defcfun...))
Another possibility might be to leave the defcfuns at the toplevel and
wrap them in a suitable eval-when (execute? -- I am not so strong on
eval-when, i would just painfully go thru the permutations or ask here).
btw, I estimate the meter on your use of "free" software to have reached
1.1 LWs*, 3LWs if you count the time of elite Lisp gods consulting on
the task. (So I will be able to beat FSW yobbos over the head with this
for years to come--thanks!) :)
hth, kzo
* the FSW currency in which the penny of your time translates to the
price of LW Pro.
--
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
On 2007-02-11 12:24:49 -0500, Ken Tilton <·········@gmail.com> said:
> * the FSW currency in which the penny of your time translates to the
> price of LW Pro.
You know, some people actually do have lots of time but not
lots of dollars. I know that is hard for you to grasp, but
it is true more often than you apparently think.
Michael
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <BBJzh.31$0O1.0@newsfe12.lga>
Michael wrote:
> On 2007-02-11 12:24:49 -0500, Ken Tilton <·········@gmail.com> said:
>
>> * the FSW currency in which the penny of your time translates to the
>> price of LW Pro.
>
>
> You know, some people actually do have lots of time but not
> lots of dollars. I know that is hard for you to grasp, but
> it is true more often than you apparently think.
Yes, yes, yes, as soon as Kenny attacks the FSF suddenly everyone
slaving away at "free" software is just fascinated by the idea of
getting an OS to boot and hails from Mozambique. Then after a few days
you can resume coming home from your $100k jobs every night to curse Linux.
A better retort would have been that, until we know what is going on, it
is not clear that CLisp is any more trouble than LW or ACL would be in
this context. But that would require you to be thinking about the issues
instead of sitting there pathetically day after day looking for a chance
to attack me.
But, hey, what's a killfile for?
On 2007-02-11 18:34:39 +0000, Michael <········@ectospheno.com> said:
> You know, some people actually do have lots of time but not
> lots of dollars. I know that is hard for you to grasp, but
> it is true more often than you apparently think.
We call those people "unemployed" don't we?
Tim Bradshaw <···@tfeb.org> wrote:
+---------------
| Michael <········@ectospheno.com> said:
| > You know, some people actually do have lots of time but not
| > lots of dollars. I know that is hard for you to grasp, but
| > it is true more often than you apparently think.
|
| We call those people "unemployed" don't we?
+---------------
Or "students", which certainly includes many/most "grad students".
Or even "staff" at some educational institutions. I know that when
I was a staff techie in an NMR research group at Emory U. in the 70's
that we always had plenty of time, and usually enough people, but
very little free cash. [The grant money mostly went for the people,
who were paid very little in any case.] So we employed a *lot* of
Wozniak-style bit-twiddley "cleverness" to build add-ons to the
group's DEC PDP-10 that we couldn't afford to buy:
- A home-brew "bus-converter" that let us use cheap, high-density
(for the day) TTL gates to build interfaces instead of the low-
desity, expensive {R,S,T,W}-series cards you were supposed to use
to do I/O with the PDP-10. That, in turn, let us build...
- A 36-port serial interface implemented with only 36 input gates and
36 output registers, the serialization/deserialization being done
with "software bit-banging" using a kind of bit-parallel "SIMD"
style which cost no more than doing a single port. [Only burned
1.6% of the CPU for all 36 lines when idle.]
- A Calcomp plotter interface for under $20 instead of however many
$1000's DEC wanted for one.
- An MDS line printer interface for under $20 instead of however many
$1000's DEC wanted for one.
- Several other interfaces to various bits of laboratory equipment
for $20-50 each, rather than the $500 to $10,000 prices of the
commercial equivalents.
As The Woz himself has been saying during his recent book tour
[paraphrased], everybody should experience at least one time in
their lives when their technical work is *severely* constrained
by cost, or memory size, or a miniscule CPU, or some critical
resource *other* than human time. One learns a quite a lot by
having to make do with very little.
-Rob
p.s. I learned to "think small" on an LGP-30 and a PDP-8 [and
carried those lessons over to the PDP-10 & PDP-11 & MC68000],
but these days I would suggest to new programmers that they try
their hands at programming some model of PIC (e.g., a 16F57 or
a 16F6xx), *in assembler*, to learn how to accomplish a lot with
little. Despite their limitations, they're plenty fast to run
all kinds of fun toys.
Plus, the PICs are *CHEAP*, only a buck or two each, and you can
build a serial programmer for the 16Fxxx parts that works off the
parallel port of your laptop for just few bucks in parts. Numerous
assemblers that run on Windows or Linux/Unix are freely available.
[Or you can buy the PICkit 2 Starter Kit from Microchip for ~$50,
which includes as USB-attached programmer, a demo board (with LEDs,
a pushbutton, and a pot), a PIC16F690 PDIP, and software. But where's
the fun in that?!? ;-} ]
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <CiTzh.78$0O1.68@newsfe12.lga>
Rob Warnock wrote:
> Tim Bradshaw <···@tfeb.org> wrote:
> +---------------
> | Michael <········@ectospheno.com> said:
> | > You know, some people actually do have lots of time but not
> | > lots of dollars. I know that is hard for you to grasp, but
> | > it is true more often than you apparently think.
> |
> | We call those people "unemployed" don't we?
> +---------------
>
> Or "students", which certainly includes many/most "grad students".
>
> Or even "staff" at some educational institutions. I know that when
> I was a staff techie in ...snip...
>
> As The Woz himself has been saying during his recent book tour
> [paraphrased], everybody should experience at least one time in
> their lives when their technical work is *severely* constrained
> by cost, or memory size, or a miniscule CPU, or some critical
> resource *other* than human time. One learns a quite a lot by
> having to make do with very little.
Ha! When I was an impoverished schoolteacher and discovered I could own
my very own computer I literally ate less and bought fewer magazines and
Sunday Times until I had landed an Apple II. While saving I wrote an AI
app on paper in a frickin notebook. If your passion is any less, Lisp
will be lost on you anyway.
Maybe the SBCL yobbos could stop pretending they have a Win32 version so
we do not lose any more users? <sigh>
kzo
--
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
On Feb 12, 3:30 am, ····@rpw3.org (Rob Warnock) wrote:
> As The Woz himself has been saying during his recent book tour
> [paraphrased], everybody should experience at least one time in
> their lives when their technical work is *severely* constrained
> by cost, or memory size, or a miniscule CPU, or some critical
> resource *other* than human time. One learns a quite a lot by
> having to make do with very little.
I agree. But I think this is somehow different than the will-not-pay-
for-software thing, because somehow that has become this pervasive
awfulness which is damaging people's ability to think rationally about
the costs of things and, in fact, has become a cult complete with
leaders (often with beards) and the inevitable ending-up-buried-in-a-
pit-somewhere.
I don't know *how* it's different. For instance I use only film
cameras (actually, not quite only), and furthermore make only optical
prints (no scanning), which looks pretty culty. But, I claim, I'm not
doing it for religious reasons (in particular I don't think film is
better than digital in most cases, and it's certainly far less
convenient in almost all cases), but for rational ones: mostly that I
don't want to soak up my scarce free time sitting in front of a
computer, because I do quite enough of that already. (I also have a
theory that non-digitally-created photography is the only kind where
there will be any value fairly soon, because you get something which
can't be reproduced easily. Not that I ever expect to sell any
prints, since I'm not very good, but ...). Free software people can
make the equivalent claims, and perhaps they are right, I don't know.
> p.s. I learned to "think small" on an LGP-30 and a PDP-8 [and
> carried those lessons over to the PDP-10 & PDP-11 & MC68000],
> but these days I would suggest to new programmers that they try
> their hands at programming some model of PIC (e.g., a 16F57 or
> a 16F6xx), *in assembler*, to learn how to accomplish a lot with
> little. Despite their limitations, they're plenty fast to run
> all kinds of fun toys.
I learnt a great deal by programming 8048s and 8052s in embedded
applications, using a logic scope for debugging...
--tim
From: Frank Goenninger DG1SBG
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <lz4ppstqer.fsf@pcsde001.de.goenninger.net>
Ken Tilton <·········@gmail.com> writes:
> A concrete suggestion is that you must defer the defcfuns also. I
> think it is legal to move the defcfun's inside the init function after
> the use-foreign-library:
>
> (defun init-sql ()
> (use-foreign-library sql)
> (defcfun...)
> (defcfun...))
>
> Another possibility might be to leave the defcfuns at the toplevel and
> wrap them in a suitable eval-when (execute? -- I am not so strong on
> eval-when, i would just painfully go thru the permutations or ask
> here).
As I understand the issues the following sequence should help:
(eval-when (:load-toplevel :compile-toplevel)
(use-foreign-library SQL)
(defcfun ...)
... )
So the library gets loaded whenever a C function definition is about
to occur.
Just guessing, though!
Hth
Frank
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <L3Lzh.43$3P6.15@newsfe09.lga>
Frank Goenninger DG1SBG wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>A concrete suggestion is that you must defer the defcfuns also. I
>>think it is legal to move the defcfun's inside the init function after
>>the use-foreign-library:
>>
>>(defun init-sql ()
>> (use-foreign-library sql)
>> (defcfun...)
>> (defcfun...))
>>
>>Another possibility might be to leave the defcfuns at the toplevel and
>>wrap them in a suitable eval-when (execute? -- I am not so strong on
>>eval-when, i would just painfully go thru the permutations or ask
>>here).
>
>
> As I understand the issues the following sequence should help:
>
> (eval-when (:load-toplevel :compile-toplevel)
> (use-foreign-library SQL)
> (defcfun ...)
> ... )
>
> So the library gets loaded whenever a C function definition is about
> to occur.
But the trick (apparently--whaddoiknow?) is /not/ to do this at compile
time, because apparently (I use that word so much) CLisp is writing
something down somewhere and getting upset when at run time it sees
something different.
In ACL and LW I can defcfun at compile-time and not even evaluate
use-foreign-library until run time.
In cmucl and sbcl (I think) you cannot do the defcfun until you have
done the use-foreign-library.
In CLisp, in re a built executable, we seem to have "don't do anything
until runtime if you want to build an exe". Or maybe the real deal is:
it is ok to use a different order during development, just make sure
that at runtime it gets /done again/ in this order: use lib, defcfun,
call func.
That is why I was thinking, if defcfun in an initfunction vs being at
the toplevel does not work (but I have seen such code posted without
causing an outcry), then /maybe/ eval-when would help. Hmm... if I run a
Lisp executable, does "load time" happen? If so, would this be better?:
(eval-when (:load-toplevel)
(use..)
(defcfun...))
jes' thinkin' out loud.
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
From: Frank Goenninger DG1SBG
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <lzbqjvqh1k.fsf@de.goenninger.net>
Ken Tilton <·········@gmail.com> writes:
> Frank Goenninger DG1SBG wrote:
>>
>> As I understand the issues the following sequence should help:
>>
>> (eval-when (:load-toplevel :compile-toplevel)
>> (use-foreign-library SQL)
>> (defcfun ...)
>> ... )
>>
>> So the library gets loaded whenever a C function definition is about
>> to occur.
>
> But the trick (apparently--whaddoiknow?) is /not/ to do this at
> compile time, because apparently (I use that word so much) CLisp is
> writing something down somewhere and getting upset when at run time it
> sees something different.
>
> In ACL and LW I can defcfun at compile-time and not even evaluate
> use-foreign-library until run time.
>
> In cmucl and sbcl (I think) you cannot do the defcfun until you have
> done the use-foreign-library.
>
> In CLisp, in re a built executable, we seem to have "don't do anything
> until runtime if you want to build an exe". Or maybe the real deal is:
> it is ok to use a different order during development, just make sure
> that at runtime it gets /done again/ in this order: use lib, defcfun,
> call func.
>
> That is why I was thinking, if defcfun in an initfunction vs being at
> the toplevel does not work (but I have seen such code posted without
> causing an outcry), then /maybe/ eval-when would help. Hmm... if I run
> a Lisp executable, does "load time" happen? If so, would this be
> better?:
>
> (eval-when (:load-toplevel)
> (use..)
> (defcfun...))
>
> jes' thinkin' out loud.
>
> kt
Ooookkkaaaayyyyy ....
So, for CLisp, we need to ensure that on execution the defcfuns get
executed again - thus creating everything afresh:
(eval-when (:load-toplevel :compile-toplevel :execute)
(use-foreign-library SQL)
(defcfun ...)
... )
Or what? Really wondering if this works...
Cheers
Frank
From: Ken Tilton
Subject: Re: clisp, clsql and foreign functions: problems in windows executables
Date:
Message-ID: <lA4Bh.25$Mw3.17@newsfe10.lga>
Frank Goenninger DG1SBG wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Frank Goenninger DG1SBG wrote:
>>
>>>As I understand the issues the following sequence should help:
>>>
>>>(eval-when (:load-toplevel :compile-toplevel)
>>> (use-foreign-library SQL)
>>> (defcfun ...)
>>> ... )
>>>
>>>So the library gets loaded whenever a C function definition is about
>>>to occur.
>>
>>But the trick (apparently--whaddoiknow?) is /not/ to do this at
>>compile time, because apparently (I use that word so much) CLisp is
>>writing something down somewhere and getting upset when at run time it
>>sees something different.
>>
>>In ACL and LW I can defcfun at compile-time and not even evaluate
>>use-foreign-library until run time.
>>
>>In cmucl and sbcl (I think) you cannot do the defcfun until you have
>>done the use-foreign-library.
>>
>>In CLisp, in re a built executable, we seem to have "don't do anything
>>until runtime if you want to build an exe". Or maybe the real deal is:
>>it is ok to use a different order during development, just make sure
>>that at runtime it gets /done again/ in this order: use lib, defcfun,
>>call func.
>>
>>That is why I was thinking, if defcfun in an initfunction vs being at
>>the toplevel does not work (but I have seen such code posted without
>>causing an outcry), then /maybe/ eval-when would help. Hmm... if I run
>>a Lisp executable, does "load time" happen? If so, would this be
>>better?:
>>
>>(eval-when (:load-toplevel)
>> (use..)
>> (defcfun...))
>>
>>jes' thinkin' out loud.
>>
>>kt
>
>
> Ooookkkaaaayyyyy ....
>
> So, for CLisp, we need to ensure that on execution the defcfuns get
> executed again - thus creating everything afresh:
>
> (eval-when (:load-toplevel :compile-toplevel :execute)
> (use-foreign-library SQL)
> (defcfun ...)
> ... )
>
> Or what? Really wondering if this works...
You have probably seen this by now, if not:
http://carpathia.blogspot.com/2007/02/free-lisp-executables-in-windows.html
...but it occurs to me I do not really understand what went down. From
that description it seems the only change needed was to move
use-foreign-library from the toplevel into the runtime initialization.
ie, I did not see any mention of a need for runtime evaluation of
defcfuns. Oh wait, maybe this is the deal (having reread that):
Toplevel:
(use-f-l..) ;; this bit unnecessary in some Lisps
(defcuns....
(defun main ()
(use-f-l....)
....)
Yes? No?
kzo
--
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
On Feb 15, 9:48 pm, Ken Tilton <·········@gmail.com> wrote:
> Frank Goenninger DG1SBG wrote:
> > Ken Tilton <·········@gmail.com> writes:
>
> >>Frank Goenninger DG1SBG wrote:
>
> >>>As I understand the issues the following sequence should help:
>
> >>>(eval-when (:load-toplevel :compile-toplevel)
> >>> (use-foreign-library SQL)
> >>> (defcfun ...)
> >>> ... )
>
> >>>So the library gets loaded whenever a C function definition is about
> >>>to occur.
>
> >>But the trick (apparently--whaddoiknow?) is /not/ to do this at
> >>compile time, because apparently (I use that word so much) CLisp is
> >>writing something down somewhere and getting upset when at run time it
> >>sees something different.
>
> >>In ACL and LW I can defcfun at compile-time and not even evaluate
> >>use-foreign-library until run time.
>
> >>In cmucl and sbcl (I think) you cannot do the defcfun until you have
> >>done the use-foreign-library.
>
> >>In CLisp, in re a built executable, we seem to have "don't do anything
> >>until runtime if you want to build an exe". Or maybe the real deal is:
> >>it is ok to use a different order during development, just make sure
> >>that at runtime it gets /done again/ in this order: use lib, defcfun,
> >>call func.
>
> >>That is why I was thinking, if defcfun in an initfunction vs being at
> >>the toplevel does not work (but I have seen such code posted without
> >>causing an outcry), then /maybe/ eval-when would help. Hmm... if I run
> >>a Lisp executable, does "load time" happen? If so, would this be
> >>better?:
>
> >>(eval-when (:load-toplevel)
> >> (use..)
> >> (defcfun...))
>
> >>jes' thinkin' out loud.
>
> >>kt
>
> > Ooookkkaaaayyyyy ....
>
> > So, for CLisp, we need to ensure that on execution the defcfuns get
> > executed again - thus creating everything afresh:
>
> > (eval-when (:load-toplevel :compile-toplevel :execute)
> > (use-foreign-library SQL)
> > (defcfun ...)
> > ... )
>
> > Or what? Really wondering if this works...
>
> You have probably seen this by now, if not:
>
> http://carpathia.blogspot.com/2007/02/free-lisp-executables-in-window...
>
> ...but it occurs to me I do not really understand what went down. From
> that description it seems the only change needed was to move
> use-foreign-library from the toplevel into the runtime initialization.
> ie, I did not see any mention of a need for runtime evaluation of
> defcfuns. Oh wait, maybe this is the deal (having reread that):
>
> Toplevel:
>
> (use-f-l..) ;; this bit unnecessary in some Lisps
> (defcuns....
>
> (defun main ()
> (use-f-l....)
> ....)
>
> Yes? No?
Exactly, this is what got my project running error-free. The defcfuns
were already defined, only bound to some foreign library that the
clisp image won't know where it is, apparently.
--
Edgar Gonçalves
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <sjbyh.185$Pf7.163@newsfe11.lga>
Edgar Gon�alves wrote:
> Ok, I've come to a sad, but true conclusion. I cannot rely on SBCL for
> FFI's on windows. This applies to celtk, cell-gtk, etc, but also to
> some aspects of cl-sql. And, I cannot use clisp to build executable
> binaries (even with sbcl, they would be huge, when all I want could
> run in a couple of hundred kilobytes...). I can't get ECL to work
> either, so that pretty much sums my free CL alternatives (am I missing
> anything?).
Money, apparently. Python would be a fine language to use if there were
no such thing as Lisp. Get a job, man!
> Ergo, I must turn to the next best thing for me: Python.
> It's free, portable, well stacked with api's for pretty much
> everything I need. And, it produces binary executables just fine.
> Arrg, I hate to do this, but I have no time to solve all issues with
> the CL way :(
>
> Maybe for my next project I can play with celtk again. In the
> meanwhile, it'll be just a hobby - I'm kinda growing into cells, and
> it's applicability in user interfaces!
I think this SoC project went well: http://pycells.pdxcb.net/
I tried to talk them into doing a PyCeltk but they wanted to do some web
thingy. They left you a shot at fame and fortune. Well, fame. Well...
kzo
--
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
"Edgar Gon�alves" <···············@gmail.com> writes:
> Ok, I've come to a sad, but true conclusion. I cannot rely on SBCL for
> FFI's on windows. This applies to celtk, cell-gtk, etc, but also to
> some aspects of cl-sql. And, I cannot use clisp to build executable
> binaries
Why can you not?
(ext:saveinitmem "pgm.exe" :executable t) doesn't work on MS-Windows?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
On 2007-01-31 16:19:57 -0500, Ken Tilton <·········@gmail.com> said:
> And never ask me about SBCL again. :)
Well, for the time being I think I'm sticking with ltk. It is
trivial to setup, trivial to use, and I don't have to go about
updating the tcl/tk already present on my system. And it works
with every free lisp I've tried it on.
Michael
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <yH8wh.16$Kv2.15@newsfe12.lga>
Michael wrote:
> On 2007-01-31 16:19:57 -0500, Ken Tilton <·········@gmail.com> said:
>
>> And never ask me about SBCL again. :)
>
>
> Well, for the time being I think I'm sticking with ltk.
LTk is a fine package.
> It is
> trivial to setup, trivial to use, and I don't have to go about
> updating the tcl/tk already present on my system.
You mean running the installer from ActiveState? Or unpacking add-ons
into /tcl/lib? Hmmm...
> And it works
> with every free lisp I've tried it on.
Well, we just provided fresh documentation on how un-free is "free", and
the only problem you had was making sure use-foreign-library was invoked
before defcfuns. That is a problem you will have any time you use CFFI.
Your answer to a few install problems seems to be never to move beyond
Tcl/Tk 8.4 and never to use CFFI to talk to any other library. We build
our own prisons.
Anyway, best of luck with your project.
kenzo
--
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
On 2007-01-31 17:27:36 -0500, Ken Tilton <·········@gmail.com> said:
> Your answer to a few install problems seems to be never to move beyond
> Tcl/Tk 8.4 and never to use CFFI to talk to any other library. We build
> our own prisons.
I think you may be confusing me with the other guy who posted in
this thread.
Michael
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <frawh.6$_i4.2@newsfe09.lga>
Michael wrote:
> On 2007-01-31 17:27:36 -0500, Ken Tilton <·········@gmail.com> said:
>
>> Your answer to a few install problems seems to be never to move beyond
>> Tcl/Tk 8.4 and never to use CFFI to talk to any other library. We
>> build our own prisons.
>
>
> I think you may be confusing me with the other guy who posted in
> this thread.
Right, the one to whom I addressed the remark to which you responded. :)
Well, this much stands: good luck with your project!
kzo
--
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
Michael <········@ectospheno.com> wrote:
> ; compiling (DEFSTRUCT V3I ...)
> ; file:
> /Users/michael/usr/share/common-lisp/site/cello/kt-opengl/ogl-utils.lisp
> ; in: DEFSTRUCT V3I
> ; (DEFSTRUCT KT-OPENGL:V3I
> ; (KT-OPENGL::X :TYPE KT-OPENGL:GLINT)
> ; (KT-OPENGL::Y :TYPE KT-OPENGL:GLINT)
> ; (KT-OPENGL::Z :TYPE KT-OPENGL:GLINT))
> ;
> ; caught ERROR:
> ; (during macroexpansion of (DEFSTRUCT V3I ...))
> ; error while parsing arguments to DESTRUCTURING-BIND:
> ; odd number of elements in keyword/value list: (GLINT)
>
> Happens a few times, only pasted one copy. Any idea what I'm doing wrong?
In standard Common Lisp, a defstruct slot description may only contain
options (like :TYPE) if it also has an initform.
--
Juho Snellman
On 29 Jan, 00:10, Ken Tilton <·········@gmail.com> wrote:
> Someone asked about Celtk as a platform for an app, mentioned video as a
Not entirely related but...
...I'm about a month or so away from releasing a 0.1 build of my
"Rubbish Lisp IDE" (yes; unless I come up with a better name before
then, this is what I'm calling it). It's built on LTk which I'm
_mostly_ happy with as it just worked straight from the download.
If I were to move to Celtk what would I gain? I ask mainly because of
potential performance improvements. Does Celtk still use wish to
communicate with Tk? It may be that my performance issues are nothing
to do with wish and more to do with my crappy code. But I find that to
do something quite complicated with Tk (I've built a tabbed UI control
and have paren matching, etc) I end up sending a fair bit of traffic
across process boundaries from time to time. If you've wrapped the
library more directly then I guess it's probably quicker even in the
hands of a fool like me.
I suppose I'd also be interested in what I lose. With LTk I get pretty
comprehensive docs and zero dependencies (well apart from a working
Tcl/Tk installation but I mean no compiling chains of undocumented
Lisp libraries...). Of course, this is mainly because of the use of
wish so I know I can't have it both ways but I guess I'd be reluctant
to give this up. Also, LTk seems to have a very stable API which is
helpful.
Of course I'd also have to re-write everything along the MVC dividing
line but that's obvious...
Genuinely curious,
Phil
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <4bsvh.1734$Jz5.802@newsfe11.lga>
···············@gmail.com wrote:
> On 29 Jan, 00:10, Ken Tilton <·········@gmail.com> wrote:
>
>>Someone asked about Celtk as a platform for an app, mentioned video as a
>
>
> Not entirely related but...
>
> ...I'm about a month or so away from releasing a 0.1 build of my
> "Rubbish Lisp IDE" (yes; unless I come up with a better name before
> then, this is what I'm calling it). It's built on LTk which I'm
> _mostly_ happy with as it just worked straight from the download.
LTk rocks.
>
> If I were to move to Celtk what would I gain?
Cells integration. And...
> I ask mainly because of
> potential performance improvements. Does Celtk still use wish to
> communicate with Tk?
...no. There /is/ tcl-eval where you can shoot across an arbitrary Tcl
string command, but you can get energetic and use the C API instead,
possibly adding CFFI definitions as you need them since we only did as
much as necessary to get our work done. But that does include true
callbacks and event handlers. Verrrrrry nice having those.
> It may be that my performance issues are nothing
> to do with wish and more to do with my crappy code. But I find that to
> do something quite complicated with Tk (I've built a tabbed UI control
> and have paren matching, etc) I end up sending a fair bit of traffic
> across process boundaries from time to time. If you've wrapped the
> library more directly then I guess it's probably quicker even in the
> hands of a fool like me.
The LTk folks report (based on extensive experience not just with LTk
but with SomeOtherTk (Py?) as well) that performance is not an issue
talking to wish. As someone once said, this ain't protein-folding we're
doing. Not sure what to tell you, except, yes, the algorithm is usually
the problem. Otoh, I did not even consider doing OpenGL by sending
opengl commands over a pipe. Cuuuuhhhhh-razzzz-eeeee.
>
> I suppose I'd also be interested in what I lose. With LTk I get pretty
> comprehensive docs...
PWUAHAHAHAHAHAHAHHAHHAHAA!!!!!!!!!!! Sorry, I wasn't ready for that. The
lotsa-widgets demo instantiates every widget and connects them in
interesting ways, what else do you need? meanwhile, if you plunge in and
another sucker...er, interested inquirer get involved I think Frank will
adopt Celtk, give it is own c-l.net project, and then /you/ can document
it? Not interested in writing doc? Believe you me, I understand.
The good news is that the great thing about Ltk and Celtk is that we
have been careful merely to wrap tcl/Tk, not substitute a new API (the
mistake made by the cl-opengl project). So Tcl/Tk doc is Celtk doc, and
questions/problems can go to comp.lang.tcl as well as celtk-devel
(should it ever exist).
>... and zero dependencies (well apart from a working
> Tcl/Tk installation but I mean no compiling chains of undocumented
> Lisp libraries...).
What a wuss! First you want doc (what is wrong with dozens of examples
and the frickin source?!), now you do not want to install anything else.
You'd love Cello. Not!
I think Celtk just needs Cells. This is like saying that if you want
Anna Kournikova to have your baby then you have to sleep with her.
> Of course, this is mainly because of the use of
> wish so I know I can't have it both ways but I guess I'd be reluctant
> to give this up. Also, LTk seems to have a very stable API which is
> helpful.
Stable? The great Russ McManus once said there are two paths to
reliability, never changing your code and always changing it. Guess
which approach I take. (We have to keep Mastenbrook happy and add a new
library every six weeks.)
That said, no, Celtk internals have not changed in ages, and I am able
to drop in things like Tile and QuickTimeTcl and Snack in like an hour.
Full marks to tcl/Tk for this, I think: new stuff is expected to Just
Work /and/ Work Just Like the rest of tcl/tk.
>
> Of course I'd also have to re-write everything along the MVC dividing
> line but that's obvious...
Great fun, tho, with Cells. The big downside is that you /do/ have to
learn Cells, but (a) see above in re Anna and (b) others before you have
pulled it off and (c) if one considers the prior and concurrent art,
well, it looks like all you yobs will be learning the paradigm
eventually -- all your data flow are belong to us automatic state
management mechanisms!
kzo
--
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
On Jan 29, 7:47 pm, Ken Tilton <·········@gmail.com> wrote:
> ···············@gmail.com wrote:
> > ...I'm about a month or so away from releasing a 0.1 build of my
> > It may be that my performance issues are nothing
> > to do with wish and more to do with my crappy code. But I find that to
> but with SomeOtherTk (Py?) as well) that performance is not an issue
> talking to wish. As someone once said, this ain't protein-folding we're
> doing. Not sure what to tell you, except, yes, the algorithm is usually
> the problem. Otoh, I did not even consider doing OpenGL by sending
Yes it's either that or the shoddy graphics card combined with
somewhat heavy GNOME desktop on my machine at work which is
struggling. It seems reasonable on my home computer. I can tweak this
thing forever but I'd rather get _something_ out there and wait for
the abuse to roll in.
> > I suppose I'd also be interested in what I lose. With LTk I get pretty
> > comprehensive docs...PWUAHAHAHAHAHAHAHHAHHAHAA!!!!!!!!!!!
> another sucker...er, interested inquirer get involved I think Frank will
> adopt Celtk, give it is own c-l.net project, and then /you/ can document
> it? Not interested in writing doc? Believe you me, I understand.
It's not that I'm not interested but I still have to write the docs
for my own code.
> The good news is that the great thing about Ltk and Celtk is that we
> have been careful merely to wrap tcl/Tk, not substitute a new API (the
> mistake made by the cl-opengl project). So Tcl/Tk doc is Celtk doc, and
> questions/problems can go to comp.lang.tcl as well as celtk-devel
> (should it ever exist).
This is very true. In fact I was able to bring a small amount of
Tkinter (Python) experience to my LTk coding too which has helped
immensely. It's reassuring that you and Peter know what you're doing.
> >... and zero dependencies (well apart from a working
> > Tcl/Tk installation but I mean no compiling chains of undocumented
> > Lisp libraries...).What a wuss! First you want doc (what is wrong with dozens of examples
> and the frickin source?!), now you do not want to install anything else.
> You'd love Cello. Not!
It's not a case of not wanting to though. It's more a case of spending
ages getting nowhere. When you move to a new language having used
others for a couple of decades, you want to dive in and do something
useful rather than write word count programs (even ones that do it
'functionally'...). So it's a fine line between using your programming
knowledge and not spending months trying to get packages to build.
But this is very much my problem and not yours before you pull another
weird tennis analogy on me :-)
Phil
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <77uvh.24$Zz1.16@newsfe08.lga>
···············@gmail.com wrote:
> It's not a case of not wanting to though. It's more a case of spending
> ages getting nowhere. When you move to a new language having used
> others for a couple of decades, you want to dive in and do something
> useful rather than write word count programs (even ones that do it
> 'functionally'...). So it's a fine line between using your programming
> knowledge and not spending months trying to get packages to build.
I think the only problem you will have is that I use hard-coded
pathnames, so at first you won't find the DLLs to load, then you won't
find the HS yearbook photo, or the movies played by the demo. Someone
got Celtk running recently without asking a question, so I have failed
in my attempt to drive you all to support contracts. Sitting here 24x7
answering email problem reports (not that I get many) probably does not
help.
>
> But this is very much my problem and not yours before you pull another
> weird tennis analogy on me :-)
Anna played tennis?
kzo
--
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
Ken Tilton wrote:
> ...no. There /is/ tcl-eval where you can shoot across an arbitrary Tcl
> string command, but...
That is still the C API Tcl_Eval entry point. Celtk does not launch
wish. So...
> you can get energetic and use the C API instead,
Not "C API instead". What I meant was that often there exists a
dedicated C function (taking good ol' numeric args) corresponding to a
Tcl command string one might pass to the Tcl_Eval C function.
So insted of:
".w.my-button dothis -x 42"
One calls (in C):
Tk_Button_doThis( &btn,0,0,42,NULL);
So you can in Celtk do:
(tcl-eval ".w.my-button dothis -x 42")
Or:
(tk-button-dothis (tk-ptr my-button) :x 42)
After adding a CFFI declaration for dothis.
kzo
--
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
From: Ken Tilton
Subject: Die, CL App Builder! Die!!! [was Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)]
Date:
Message-ID: <wlLvh.10$Os.1@newsfe11.lga>
Ken Tilton wrote:
> Someone asked about Celtk as a platform for an app, mentioned video as a
> requirement. I said, "No can do, unless....". Sixty minutes later (would
> have been less if I knew how to read) I was watching a movie in a Celtk
> window in an embedded QuickTime widget, thanks to:
>
> http://quicktimetcl.sourceforge.net/
>
> (And won't Mastenbrook be thrilled to know I have added another library!
> Of course he will say I am lying....)
>
> Look, case closed kiddies: "CL+Tcl/Tk, perfect together"
>
> Ah. There /is/ a fly in the ointment: QuickTimeTcl is supported only on
> windows and mac os x. But that might just be because the developer did
> not get round to that platform.
Oops. Or it might be because Apple does not provide a Quicktime for
Linux. I googled too fast and saw "Quicktime for Linux", but that turns
out to be a pale imitation unrelated to QT (so they really should not
have picked that name (but I still googled too fast)).
OK, I am busy car-shopping next two days, but then I will ask c-l.net
for a standalone project for Celtk. Should we call it Cells-Tk to stay
in parallel with Cells-Gtk and be more self-documenting/findable?
How about something grandiose, like Common Lisp Application Builder?
Oops, taken. Die, CLAB! Die!!! One window?! Puh-leeeeeezzzze. We could
be CL App Frmework, CL App Platform... ah, no, we want to hook our wagon
to Tcl/Tk's fame and fortune, should not hide that heritage.
I never felt Cells should get top or any billing as in Cells-Gtk.
Lisp-Tk? Taken? Too close to LTk? Common Lisp Tk? TkCL? Nice, package
can be its own nickname. Tie-in with wxCL. Looks like a salt, always a
good thing.
Questions? Comments?
If we advertise this on c.l.tcl we may attract new users to Lisp. They
already understand Cells in a way.
kenzo
--
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
On Jan 30, 12:33 pm, Ken Tilton <·········@gmail.com> wrote:
[...]
> How about something grandiose, like Common Lisp Application Builder?
> Oops, taken. Die, CLAB! Die!!! One window?! Puh-leeeeeezzzze. We could
> be CL App Frmework, CL App Platform... ah, no, we want to hook our wagon
> to Tcl/Tk's fame and fortune, should not hide that heritage.
Why not just CLAPP? Or does that sound too much like a social disease?
Cheers,
Pillsy
From: Ken Tilton
Subject: Re: Die, CL App Builder! Die!!! [was Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)]
Date:
Message-ID: <rROvh.35$tl4.4@newsfe09.lga>
Pillsy wrote:
> Why not just CLAPP? Or does that sound too much like a social disease?
The marketing team did brainstorm that and the social disease
association only recommended it. I am starting to think CL, albeit
accurate, is a cowardly mistake. Lisp, say it loud, say it proud. I will
never forget Franz marketing "AllegroCL...Dynamic Objects!!".
so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
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
On Jan 30, 4:32 pm, Ken Tilton <·········@gmail.com> wrote:
> so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
TkCL - It's probably just the long day but the temptation is to
pronounce that "Too Cool" ;-)
From: Ken Tilton
Subject: Re: Die, CL App Builder! Die!!! [was Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)]
Date:
Message-ID: <OWWvh.120$Os.95@newsfe11.lga>
C Y wrote:
> On Jan 30, 4:32 pm, Ken Tilton <·········@gmail.com> wrote:
>
>
>>so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
>
>
> TkCL - It's probably just the long day but the temptation is to
> pronounce that "Too Cool" ;-)
>
Suuuuuuhhhh-weet! And the alternative pronunciateion noticed belatedly
is "tickle", same as for "Tcl/Tk"!!!!!! Unfortunately tricorder readings
indicate no detectable lifeforms in the Lisp community -- ie, you losers
are unworthy -- the kenster moves on....peace..out.
Ken Tilton <·········@gmail.com> writes:
> Pillsy wrote:
>
>> Why not just CLAPP? Or does that sound too much like a social disease?
>
> The marketing team did brainstorm that and the social disease
> association only recommended it. I am starting to think CL, albeit
> accurate, is a cowardly mistake. Lisp, say it loud, say it proud. I
> will never forget Franz marketing "AllegroCL...Dynamic Objects!!".
>
> so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
Now, having actually spoken all of these out loud I'd vote for
TkLisp
Which -at least to me- sounds like Take Lisp. This is a strong message
- and we can say it loud and be proud. OTOH I don't want to rewrite
code and would want to keep ctk as a package nickname ;-)
'cause it can be proud of its roots, too !
Frank
Frank Goenninger DG1SBG wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Pillsy wrote:
>>
>>
>>>Why not just CLAPP? Or does that sound too much like a social disease?
>>
>>The marketing team did brainstorm that and the social disease
>>association only recommended it. I am starting to think CL, albeit
>>accurate, is a cowardly mistake. Lisp, say it loud, say it proud. I
>>will never forget Franz marketing "AllegroCL...Dynamic Objects!!".
>>
>>so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
>
>
> Now, having actually spoken all of these out loud I'd vote for
>
> TkLisp
>
> Which -at least to me- sounds like Take Lisp. This is a strong message
> - and we can say it loud and be proud. OTOH I don't want to rewrite
> code and would want to keep ctk as a package nickname ;-)
>
> 'cause it can be proud of its roots, too !
Sure, the package nickname for MCL is still CCL, healthy precedent there.
Hmm, there may be a problem with all these variants: they all sound like
it is a Lisp implementation.
kzo
--
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
Ken Tilton wrote:
> Frank Goenninger DG1SBG wrote:
>> Ken Tilton <·········@gmail.com> writes:
>>
>>
>>> Pillsy wrote:
>>>
>>>
>>>> Why not just CLAPP? Or does that sound too much like a social disease?
>>>
>>> The marketing team did brainstorm that and the social disease
>>> association only recommended it. I am starting to think CL, albeit
>>> accurate, is a cowardly mistake. Lisp, say it loud, say it proud. I
>>> will never forget Franz marketing "AllegroCL...Dynamic Objects!!".
>>>
>>> so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
>>
>>
>> Now, having actually spoken all of these out loud I'd vote for
>>
>> TkLisp
>>
>> Which -at least to me- sounds like Take Lisp. This is a strong message
>> - and we can say it loud and be proud. OTOH I don't want to rewrite
>> code and would want to keep ctk as a package nickname ;-)
>>
>> 'cause it can be proud of its roots, too !
>
> Sure, the package nickname for MCL is still CCL, healthy precedent there.
>
> Hmm, there may be a problem with all these variants: they all sound like
> it is a Lisp implementation.
Does TkLispRDie sound like a Lisp implementation? ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Wed, 31 Jan 2007 16:44:47 +0100, Ken Tilton <·········@gmail.com> wrote:
>
>
> Frank Goenninger DG1SBG wrote:
>> Ken Tilton <·········@gmail.com> writes:
>>
>>> Pillsy wrote:
>>>
>>>
>>>> Why not just CLAPP? Or does that sound too much like a social disease?
>>>
>>> The marketing team did brainstorm that and the social disease
>>> association only recommended it. I am starting to think CL, albeit
>>> accurate, is a cowardly mistake. Lisp, say it loud, say it proud. I
>>> will never forget Franz marketing "AllegroCL...Dynamic Objects!!".
>>>
>>> so maybe Tk Lisp? Tk-lisp? Gee, TkCL sure looks nicer.
>> Now, having actually spoken all of these out loud I'd vote for
>> TkLisp
>> Which -at least to me- sounds like Take Lisp. This is a strong message
>> - and we can say it loud and be proud. OTOH I don't want to rewrite
>> code and would want to keep ctk as a package nickname ;-)
>> 'cause it can be proud of its roots, too !
>
> Sure, the package nickname for MCL is still CCL, healthy precedent there.
>
> Hmm, there may be a problem with all these variants: they all sound like
> it is a Lisp implementation.
>
> kzo
>
ClimKiller? :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
>
> ClimKiller? :)
Or forgo the obvious and try an anagram for size.
My Inclement Hacks
From: ·····@mit.jyu.fi
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <eppl6t$f47$1@mordred.cc.jyu.fi>
Ken Tilton <·········@gmail.com> wrote:
> ken (who will be checking here hourly for the McCLIM/QT integration demo
> link -- what? you wusses don't work on Sunday night?)
Well, it's not exactly McCLIM, but CLIM implementation from MCL, that was
running in this screenshot, taken years ago:
http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/toy-story.jpg
So, you beat McCLIM, but not CLIM. Have fun.
Jonne
PS It's pretty sad, that you have to all the time denigrate McCLIM
just to trumpet your own GUI tools. It was fun for the first few
times, now it's just a real downer. Let celltk shine on its own, not
by you speaking ill of others, pretty please.
From: Ken Tilton
Subject: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
Date:
Message-ID: <b60wh.309$s66.22@newsfe10.lga>
> PS It's pretty sad, that you have to all the time denigrate McCLIM
> just to trumpet your own GUI tools.
You're no fun.
kt