cells-devel May 2006

cells-devel@common-lisp.net

7 participants
18 discussions

[cells-devel] Celtk: Text widget API woes
by Frank Goenninger 31 May '06

31 May '06

Hi all: Just a heads up on the behaviour of the text widget: Currently setting the contents of the text widget is done by setting the model value of the widget's model. This causes two steps to be triggered as Tcl commands: 1. Erase text widget to empty display 2. Set new text and display this text Now, if one is reading file contents to be display to the widget by using consequtive calls to read-line and setting each line as the new text widget content only the last line will be displayed, of course. And if this happens to be an empty line then just nothing will appear on the text widget. In case you want to dig in deeper on that subject, well, we're here... Frank

2 5

[cells-devel] New "tutorial/RT code in Cells source tree
by Ken Tilton 30 May '06

30 May '06

I have just uploaded a first rough set of example code which is intended to exercise Cells with a progression of challenges, in the order I might follow when developing a port of Cells to another language, or when validating cells after an enormous upheaval. I call it the tutorial directory, but it could also be a porting guide and a more concise regression test than the random mish-mosh in cells-test. I do plan to put future energy into this code as a regrression test suite, so... watch for a name change? :) kt

1 0

[cells-devel] to propagate or not to propagate...
by Ken Tilton 30 May '06

30 May '06

Turns out the one filter I looked at was already answering either :propagate or :no-propagate, so on the fly I pronounced that a new standard, tweaked the code to respect either in re propagation and otherwise do the usual test of before/after value change. So is this an API change or bug fix? :) ken

1 0

[cells-devel] Filters, anyone?
by Ken Tilton 29 May '06

29 May '06

Wow, just tripped over my own code in support of filters, aka synapses. I think I have to make a change. I manage to eliminate Synapses as distinct objects by /always/ interpreting the second of possibly multiple returned values as a "propagate?" indicator. I thought this would be OK since a slot can hold only one value. But! (c? (floor (^length) 2)) ...ends up feeding the "propagate?" interpretation, so it turned we all have been getting unnecessary propagation where we innocently returned multiple values and the second was non-nil. My proposed solution is to make the kludge even worse. :) A cell acting in the role of a synapse/filter will have to return 'cells::propagate-yes, 'cell::propagate-no, or (I think there was a third value). Only those will be meaningful. Anything else gets thrown away. Thoughts? Alternatives? kt

1 0

[cells-devel] Re: [PyCells] Possibly-useful prior art
by Ken Tilton 27 May '06

27 May '06

Phillip, Nice write-up. Random notes: What I discovered is quite cool. The Cells system *automatically discovers* dynamic dependencies, without having to explicitly specify that X depends on Y, as long as X and Y are both implemented using cell objects. <g> And that is part of why Cells is pretty much all-or-nothing for a developer: I have not tried to figure out the threshhold, but above what I think is a very low one, all application semantics must be expressed declaratively as Cell rules. Otherwise imperative code gets left out of the action as the automatic dataflow engine does its thing. The corollary being your "as long as" qualifier: my declarative rules are crippled if some important datapoint is not a Cell. For the first seven years of Cells development, when in doubt I started out a new slot/attribute as a non-Cell, bending over backwards if you will not to force the mechanism where it should not go. The default :cell meta-attribute was nil until just recently. But in each case, soon enough it turned out I would need them to be Cells. Just recently "true" became the default for :cell. Specifically, the cells system understands how to make event-based updates orderly and deterministic, in a way that peak.events cannot. It may be of interest that this orderliness is relatively new to Cells. For the longest time and in the most intense applications I got away with murder. Strangely, it was development of a RoboCup client that forced Cells to "grow up". One especially interesting bit is that the Cells system can "optimize away" dependencies or subscriptions when their subjects are known to be constant values. I was quite surprised at how much faster this made Cells run. I'm also wondering if a Cells-like system couldn't also be used to implement STM (Software Transactional Memory) to allow for atomic operations even in the presence of threads. All reads and writes are controlled by the cells system, so it can in principle abort and retry a "transaction", by waiting until *something changes* that would affect the transaction's ability to succeed. We have a Google SoC project over on the Lisp side to implement STM, and yes, I am excited about that making Cells viable in a multi-threaded situation. Mind you, I had never heard of STM before this proposal landed on our doorstep, nor do even have much idea of what is available to applications when it comes to dealing with threads, but looking at how Cells manages data integrity I know it will need help to survive threads. STM looks like a great fix. However, seeing how the Cells paradigm works, it seems to me that it should be pretty easy to establish the convention that side-effects should be confined to non-rule "observer" code. Right, it is just a convention, but I think one that gets easier to follow because the engine provides a simple way to say "do this when the time is right". experience w/e.g. peak.binding attributes shows that it's rare to want to put side-effects into pull-oriented rules. "We could do it, but it would be wrong." Really, the principal downside to Cells is wrapping your head around the idea that *everything* should be treated as pull-oriented rules. Yes, it really is a paradigm shift, one it takes a long time to internalize. What I noticed was that, if I decided to add a significant new mechanism to the system, after about two hours of coding I would be having increasing difficulties and start to get a vague "bad feeling". Then I would realize that I had, from long habit, fallen back into an imperative style. Hence the "bad feeling". Because the code was all new, it did not grow naturally from the Cell-based model. if it had, It would of course been done originally in the declarative style. I have encouraged Ryan, the PyCells author, not to allow backdoors to the Cells engine, precisely because of this. The big win comes from the declarative paradigm, and developers will not climb that learning curve if they can avoid it. SImple human nature. Cells makes one think harder up front in return for all sorts of good things later, and that is a tradeoff I have always liked to make as a developer. There are some operations (such as receiving a command and responding to it) that seem to be more naturally expressed as pushing operations, where you make some decisions and then directly update things or send other commands out. Exactly! A spreadsheet is a steady-state thing (here are the values, here is the computed other state) and using Cells to express static reality is a snap. Otoh, imperative code is all about change, so it is great for handling events. We use ephemeral Cells to model events (they take on a value, propagate, then revert to null silently, without propagating), but one still can end up thinking pretty hard when it comes to events. I think the most frightening "rule" I have written was for a Timer class implemented by the Tcl "after" command. Actually, you can still do that, it's just that those updates or commands force another "virtual moment" of time into being, where if you had made them pull-driven they could've happened in the *same* "virtual moment". So, it's more that pull-based rules are slightly more efficient than push-based ones, which is nice because that means most developers will consider it worth learning how to do it the pull way. ;) That and the straitjacket I hope PyCells keeps from Cells. Anyway, there is a *lot* of interesting food for thought, here. For example, you could create object validation rules using cells, and the results would be automatically recomputed when something they depended on changed. Not only that, but it would be possible to do atomic updates, such that the validation wouldn't occur until *after* all the changes were made -- i.e., no false positives. Of course, you'd get the resulting validation errors in the *next* "time quantum", so you'd need to make the response to them event-driven as well. It's definitely a slippery slope. :) For example, this deterministic model of computation seems to resemble "object prevalence" (e.g. Prevayler) in that everything (even the clock) is deterministic, changes are atomic, and I/O occurs between logical moments of time. I haven't thought this particular link through very much yet, it's just an intriguing similarity. Nice call. I have heard the Cells data integrity model maps nicely onto the transaction model of AllegroCache, a persistent Lisp object database. The head-exploding part is figuring out how to get errors to propagate backwards in time, so that validation rules (which run in the "next moment") could appear to cause an error at the point where the values were set. Sounds like you want at least one Undo. What about a "fail now or forever hold your peace" policy? cheers, kenny

1 0

[cells-devel] Cello Rizng
by Ken Tilton 27 May '06

27 May '06

GUI fans might want to start tracking the Cello list for ongoing development. Celtk is fine and with its Togl widget even does OpenGL, but Cello makes the Celtk/Togl come alive with: FTGL -- anti-aliased texture, polygon, outline, pixmap, bitmap, extruded, and one I ma forgetting fonts GraphicsMagick/ImageMagick -- awesome graphic file handling and more OpenAL -- fun with 3D sound Much more sophisticate dframework, esp. in re widget Geometry. Speaking of OpenAL, it looks as if the Tcl "Snack" library will provide terrific real-time audio synthesis (but that would be true for Celtk as well). Anyway, if you download Cello now (a) most of it is yet to be resurrected but (b) if you can get demo NeHe-06 running (1) you are pretty good at getting hairy libraries running and (2) i think you will enjoy it. :) Meanwhile, PyCells is bringing some attention this way: http://www.eby-sarna.com/pipermail/peak/2006-May/002545.html kt

1 0

[cells-devel] Celtk2 installation
by John Landahl 27 May '06

27 May '06

So I'd like to try out the new! improved! Celtk2 under Linux/SBCL, but I'm having some installation problems. First I found that I had a really old version of CFFI (thanks, Ubuntu!). After installing the latest CFFI tarball, I still get the following error: * (require :celtk) ; loading system definition from /usr/local/lib/sbcl/site-systems/cffi.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM CFFI {A9D14D1}> as CFFI ; loading system definition from /usr/local/lib/sbcl/site-systems/cells.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM :CELLS {AD05B69}> as CELLS debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {B29D0D1}>: When attempting to read the slot's value (slot-value), the slot CFFI::TO-C-DYNAMIC-EXPANDER is missing from the object #<CFFI::FOREIGN-BUILT-IN-TYPE :UNSIGNED-LONG>. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {B48D421}> on #<ASDF:CL-SOURCE-FILE "tk-structs" {B46B491}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {B48D421}> on #<ASDF:CL-SOURCE-FILE "tk-structs" {B46B491}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD SLOT-MISSING (T T T T)) #<unavailable argument> #<unavailable argument> #<unavailable argument> #<CFFI::FOREIGN-BUILT-IN-TYPE :UNSIGNED-LONG> CFFI::TO-C-DYNAMIC-EXPANDER SLOT-VALUE NIL) Any hints on where to go next?

2 2

[cells-devel] Celtk better
by Ken Tilton 25 May '06

25 May '06

Worked out all known issues shutting down a window, but will not be surprised if more arise. Always a delicate balance dealing with a foreign GUI. Did not bother to move Gears/Opengl demo under Celtk source module. Maybe tomorrow. Maybe. kt

1 0

[cells-devel] Celtk "Hard to Kill" interim release
by Ken Tilton 24 May '06

24 May '06

basically this release is just trying to get on the same page with Stu who is patching like crazy to bring SBCL/Linux on-line. Thx, Stu. The "Hard to Kill" bit reflects the past 24-hours work fighting tooth and nail with Tcl/Tk to bring down a Tk window gracefully. Thought I had it working and then on the last round of tests hit something new (pretty sure this is just something about also getting timers quiesced, which ironically is what started me on this mess 48hrs ago). Meanwhile, I have applied a lot of Stu's patches (Stu, you never got back to me on the Tugl use-lib -- that is in the interp startup now, does not need to be at the toplevel unless it turns out SBCL needs it there.) and want to see how close I got applying them manually as I did while I continue to fight it out with Tcl/Tk. I will also bring the Gears demo back under Celtk since 3d is so much fun, but anyone who wants to test it will have to load it separately: the core Celtk package will load and run without cl-opengl. kenny

1 0

[cells-devel] Celtk and SBCL (and linux)
by Stu Glaser 24 May '06

24 May '06

Hi all, I'm trying to get Celtk working on SBCL. I've attached a patch with several bugfixes. Much still does not work, however, I have managed to display the "one-button-window" demo (though it crashes immediately after display. Sometime later I will have questions. Celtk still crashes often in finish-business, and I'm not yet familiar enough with cells to perform the fixes. I made a change in item-pictorial that I'm not certain about. In lotsa-widgets, tcl chokes when I use :bitmap in mk-bitmap: debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {A549481}>: Tcl error: bitmap "/home/stu/tmp/cells/Celtk/x1.xbm" not defined I changed it to :file and added a -file entry in deftk bitmap. That fixed the first error, but created a new one (which occurs later): debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {A549481}>: Tcl error: unknown option "-file" I'm not sure how to proceed here. Any help would be great. Lastly, anonymous CVS access would be great. It would certainly help for creating patches and for keeping my sources updated. Regards, -Stu Glaser diff -c old-Celtk/composites.lisp Celtk/composites.lisp *** old-Celtk/composites.lisp Mon May 15 00:15:37 2006 --- Celtk/composites.lisp Tue May 23 04:00:59 2006 *************** *** 85,91 **** #+wishful (ewish :initarg :ewish :accessor ewish :initform nil :cell nil) ;; vestigial? (title$ :initarg :title$ :accessor title$ :initform (c? (string-capitalize (class-name (class-of self))))) ! (dictionary :initarg :dictionary :initform (make-hash-table :test 'string-equal) :accessor dictionary) (tkwins :initform (make-hash-table) :reader tkwins) (xwins :initform (make-hash-table) :reader xwins) (callbacks :initarg :callbacks :accessor callbacks --- 85,91 ---- #+wishful (ewish :initarg :ewish :accessor ewish :initform nil :cell nil) ;; vestigial? (title$ :initarg :title$ :accessor title$ :initform (c? (string-capitalize (class-name (class-of self))))) ! (dictionary :initarg :dictionary :initform (make-hash-table :test 'equalp) :accessor dictionary) (tkwins :initform (make-hash-table) :reader tkwins) (xwins :initform (make-hash-table) :reader xwins) (callbacks :initarg :callbacks :accessor callbacks diff -c old-Celtk/item-pictorial.lisp Celtk/item-pictorial.lisp *** old-Celtk/item-pictorial.lisp Tue May 2 01:57:22 2006 --- Celtk/item-pictorial.lisp Tue May 23 04:00:59 2006 *************** *** 31,36 **** --- 31,37 ---- -activebackground -disabledbackground -bitmap + -file -activebitmap -disabledbitmap -foreground diff -c old-Celtk/run.lisp Celtk/run.lisp *** old-Celtk/run.lisp Tue May 16 19:40:55 2006 --- Celtk/run.lisp Tue May 23 04:00:59 2006 *************** *** 39,45 **** (tk-app-init *tki*) (tk-togl-init *tki*) (tk-format-now "proc TraceOP {n1 n2 op} {event generate $n1 <<trace>> -data $op}") ! (tcl-create-command *tki* "do-on-command" (get-callback 'do-on-command) 42 0) (with-integrity () (setf *tkw* (make-instance root-class)) --- 40,46 ---- (tk-app-init *tki*) (tk-togl-init *tki*) (tk-format-now "proc TraceOP {n1 n2 op} {event generate $n1 <<trace>> -data $op}") ! (tcl-create-command *tki* "do-on-command" (get-callback 'do-on-command) 42 (null-pointer)) (with-integrity () (setf *tkw* (make-instance root-class)) *************** *** 85,88 **** (force-output *tkw*) (setf *tkw* nil)) ! (run-window root-class)) \ No newline at end of file --- 86,89 ---- (force-output *tkw*) (setf *tkw* nil)) ! (run-window root-class)) diff -c old-Celtk/tk-events.lisp Celtk/tk-events.lisp *** old-Celtk/tk-events.lisp Tue May 16 19:40:55 2006 --- Celtk/tk-events.lisp Tue May 23 04:00:59 2006 *************** *** 35,41 **** (tkwin :pointer) (mask :int) (proc :pointer) ! (client-data :int)) (defcenum tk-event-type ;; do not try to generate masks from these! "Ok for interpreting type field in event, but not for (expt 2 etype) to get mask" --- 35,41 ---- (tkwin :pointer) (mask :int) (proc :pointer) ! (client-data :pointer)) (defcenum tk-event-type ;; do not try to generate masks from these! "Ok for interpreting type field in event, but not for (expt 2 etype) to get mask" diff -c old-Celtk/tk-interp.lisp Celtk/tk-interp.lisp *** old-Celtk/tk-interp.lisp Tue May 16 16:17:15 2006 --- Celtk/tk-interp.lisp Tue May 23 04:00:59 2006 *************** *** 36,50 **** (define-foreign-library Tcl (:darwin (:framework "Tcl")) ! (:windows (:or "/tcl/bin/Tcl85.dll"))) (define-foreign-library Tk (:darwin (:framework "Tk")) ! (:windows (:or "/tcl/bin/tk85.dll"))) ;; Togl (define-foreign-library Togl (:darwin (:or "/opt/tcltk/togl/lib/Togl1.7/libtogl1.7.dylib")) ! (:windows (:or "/tcl/lib/togl/togl17.dll"))) (defctype tcl-retcode :int) --- 36,57 ---- (define-foreign-library Tcl (:darwin (:framework "Tcl")) ! (:windows (:or "/tcl/bin/Tcl85.dll")) ! (:unix "libtcl.so") ! (t (:default "libtcl"))) (define-foreign-library Tk (:darwin (:framework "Tk")) ! (:windows (:or "/tcl/bin/tk85.dll")) ! (:unix "libtk.so") ! (t (:default "libtk"))) ;; Togl (define-foreign-library Togl (:darwin (:or "/opt/tcltk/togl/lib/Togl1.7/libtogl1.7.dylib")) ! (:windows (:or "/tcl/lib/togl/togl17.dll")) ! (:unix "/usr/lib/Togl1.7/libTogl1.7.so")) ! ! (use-foreign-library Togl) (defctype tcl-retcode :int) *************** *** 233,239 **** (defun argv0 () #+allegro (sys:command-line-argument 0) ! #+lispworks (nth 0 (io::io-get-command-line-arguments))) (defun tk-interp-init-ensure () (unless *initialized* --- 240,247 ---- (defun argv0 () #+allegro (sys:command-line-argument 0) ! #+lispworks (nth 0 (io::io-get-command-line-arguments)) ! #+sbcl (nth 0 sb-ext:*posix-argv*)) (defun tk-interp-init-ensure () (unless *initialized* diff -c old-Celtk/widget.lisp Celtk/widget.lisp *** old-Celtk/widget.lisp Tue May 16 19:40:55 2006 --- Celtk/widget.lisp Tue May 23 04:00:59 2006 *************** *** 78,84 **** (defun tk-create-event-handler-ex (widget callback-name &rest masks) (let ((self-tkwin (widget-to-tkwin widget))) ! (assert (plusp self-tkwin)) (trc nil "setting up widget virtual-event handler" widget :tkwin self-tkwin) (tk-create-event-handler self-tkwin (apply 'foreign-masks-combine 'tk-event-mask masks) --- 78,84 ---- (defun tk-create-event-handler-ex (widget callback-name &rest masks) (let ((self-tkwin (widget-to-tkwin widget))) ! (assert (not (null-pointer-p self-tkwin))) (trc nil "setting up widget virtual-event handler" widget :tkwin self-tkwin) (tk-create-event-handler self-tkwin (apply 'foreign-masks-combine 'tk-event-mask masks)

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel May 2006