[cells-devel] Re: Celtk/Cells3 declarative, dataflow paradigm contrasted with Ltk/imperative paradigm

[Ken Tilton]

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.

kt


On 4/5/06, John Landahl <john at landahl.org> wrote:
>
> > Right at the top of ltktest-cells-inside.lisp you will find:
> >
> > #+test-ltktest
> > (progn
> >   (cells-reset 'tk-user-queue-handler)
> >   ; ...huge comment elided....
> >   (tk-test-class 'ltktest-cells-inside))
>
> Yep, saw that, and I suppose I expected that loading celtk would set
> test-ltktest.  Removing the #+ and re-evaluating does startup the
> test.
>
> However, the result is a bunch of errors and a big traceback.  Here's
> what looks like the most useful chunk:
>
> 0> numparse | :=> 42read-data:UNKNOWNcolor name "systembuttonface"
>
> read-data:INVALIDcommand name ".cv-scroller.test-canvas"
>
>
> 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
> An error of type READER-ERROR has occured: READER-ERROR on
> #<TWO-WAY-STREAM
>                                                              :INPUT-STREAM
> #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>
> :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>:
> illegal terminating character after a colon: #\
> 0: (SB-DEBUG:BACKTRACE
>     536870911
>     #<SB-SYS:FD-STREAM for "a constant string" {AFCDB01}>)
> 1: (LTK::TRIVIAL-DEBUGGER #<READER-ERROR {AA34AF1}> #<unavailable
> argument>)
> 2: (INVOKE-DEBUGGER #<READER-ERROR {AA34AF1}>)
> 3: (ERROR READER-ERROR)
> 4: (SB-IMPL::%READER-ERROR
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     "illegal terminating character after a colon: ~S")
> 5: (SB-IMPL::READ-TOKEN
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     #\:)
> 6: (READ-PRESERVING-WHITESPACE
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     NIL
>     NIL
>     T)
> 7: (READ-PRESERVING-WHITESPACE
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     NIL
>     NIL
>     NIL)
> 8: (LTK::MAIN-ITERATION :BLOCKING T)
> 9: ((LAMBDA ()))
> 10: ((LABELS LTK::USE-DEBUGGER)
>      #<FUNCTION LTK::TRIVIAL-DEBUGGER>
>      #<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.
> --
> John Landahl <john at landahl.org>
> http://landahl.org/john
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060405/72b777fa/attachment.html>