John, Sorry, it was late, I reacted too hastily. That error message looks wild, not sure what to make of it. Unfortunately, I have no Linux system. But the original developers of LTk use Linux and are looking at Celtk these days. I have not heard from them, but a query on the cells-devel mailing list might turn up someone using both Linux and Celtk.

Otherwise, it might helpt to track down tk-format-now and tweak it so that the branch to display messages sent to Tk always fires, then see (a) if those messages look okay (post them to cells-devel) and (b) how far you get before Celtk dies.

<br><br>kt<br><br><br><div><span class="gmail_quote">On 4/5/06, <b class="gmail_sendername">John Landahl</b> <<a href="mailto:john@landahl.org">john@landahl.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> Right at the top of ltktest-cells-inside.lisp you will find:<br>><br>> #+test-ltktest<br>> (progn<br>>   (cells-reset 'tk-user-queue-handler)<br>>   ; ...huge comment elided....<br>>   (tk-test-class 'ltktest-cells-inside))

<br><br>Yep, saw that, and I suppose I expected that loading celtk would set<br>test-ltktest.  Removing the #+ and re-evaluating does startup the<br>test.<br><br>However, the result is a bunch of errors and a big traceback.  Here's

<br>what looks like the most useful chunk:<br><br>0> numparse | :=> 42read-data:UNKNOWNcolor name "systembuttonface"<br><br>read-data:INVALIDcommand name ".cv-scroller.test-canvas"<br><br>INVALIDCOMMANDNAME.cv-scroller.test-canvasUNKNOWNCOLORNAMEsystembuttonfaceBADWINDOWPATHNAME.cv-scroller.test-canvasINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popCANREAD.cv-scroller.test-canvas.bkg-pop.bkg

<br>An error of type READER-ERROR has occured: READER-ERROR on #<TWO-WAY-STREAM<br>                                                             :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>

<br>                                                             :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>:<br>illegal terminating character after a colon: #\<br>0: (SB-DEBUG:BACKTRACE

<br>    536870911<br>    #<SB-SYS:FD-STREAM for "a constant string" {AFCDB01}>)<br>1: (LTK::TRIVIAL-DEBUGGER #<READER-ERROR {AA34AF1}> #<unavailable argument>)<br>2: (INVOKE-DEBUGGER #<READER-ERROR {AA34AF1}>)

<br>3: (ERROR READER-ERROR)<br>4: (SB-IMPL::%READER-ERROR<br>    #<TWO-WAY-STREAM<br>      :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}><br>      :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>

<br>    "illegal terminating character after a colon: ~S")<br>5: (SB-IMPL::READ-TOKEN<br>    #<TWO-WAY-STREAM<br>      :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}><br>      :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>

<br>    #\:)<br>6: (READ-PRESERVING-WHITESPACE<br>    #<TWO-WAY-STREAM<br>      :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}><br>      :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>

<br>    NIL<br>    NIL<br>    T)<br>7: (READ-PRESERVING-WHITESPACE<br>    #<TWO-WAY-STREAM<br>      :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}><br>      :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>

<br>    NIL<br>    NIL<br>    NIL)<br>8: (LTK::MAIN-ITERATION :BLOCKING T)<br>9: ((LAMBDA ()))<br>10: ((LABELS LTK::USE-DEBUGGER)<br>     #<FUNCTION LTK::TRIVIAL-DEBUGGER><br>     #<CLOSURE (LAMBDA #) {AA3477D}>)

11: (LTK:MAINLOOP :SERVE-EVENT NIL) I'm running SBCL 0.9.11 on Linux, if it matters.  My Tk version is 8.4. > No, but do compare it to 'ltktest-cells-inside to get a feel for how > Cells transforms development.

I definitely will.  I'd very much like to do more declarative programming where it makes sense, and (as you and others have pointed out) UIs are a natural fit.  So it will be good to compare your approach to the more usual (less intelligent) approach.

<br>--<br>John Landahl <<a href="mailto:john@landahl.org">john@landahl.org</a>><br><a href="http://landahl.org/john">http://landahl.org/john</a><br></blockquote></div><br>