cells-devel April 2008

cells-devel@common-lisp.net

9 participants
36 discussions

[cells-devel] Re: [cells-gtk-devel] lots of circular cells in cells-gtk3?
by Ken Tilton 14 Apr '08

14 Apr '08

Peter Hildebrandt wrote: > Mea culpa, just found the culprit in my own code. > > So the problem arises when I access (id self) in initialize-instance > :after of the widget class. > > No idea why, but removing that reference solves it. LOL. I was just looking at this and scratching my head: (defmodel gtk-object (family) (..... (id :initarg :id :accessor id :initform (c? (without-c-dependency .... (let ((id (apply (symbol-function (new-function-name self)) (new-args self)))) (gtk-object-store id self) id)))) Oh, I see. The applied function of course is collecting slot values for object creation, many mediated by rules. I guess the easiest fix would be a quick: (let ((cells::*call-stack* nil)) (without-c-dependency ...all else the same...)) But you are still a sinner going after a celled slot in initialize-instance. Can you move that to md-awaken? (Then I have not had enough coffee since my nap to figure out if you will still need the fix.) kt

1 0

[cells-devel] Handling not-to-be'd kids and how to do an input slot for kids
by Peter Hildebrandt 14 Apr '08

14 Apr '08

Ken, as discussed in the ECLM thread: > I look forward to the IR, maybe you have run into something I want to add > to Cells to better handle things going away (a frequent problem). In my > latest app I am running into a lot of problems with what is generally called > referential integrity, specifically external references to kids that have > been not-to-be'd. eg, my window's keep a reference to the "focus", which > might be in a math problem the student decides to delete. uh-oh. Sprinkling > (setf (focus w) nil) all over the place broke down when it ended up erasing > a new value that had been set by code that tried to handle the problem by, > say, moving the focus to the next problem when deleting the current problem. What happens in my case is that I have one family observing another like (defmodel observer (family) () (:default-initargs :kids (kids-list? (loop for kid in (kids (value self)) collecting (make-instance 'observer :value kid :fm-parent *parent*))))) Then, when we remove a kid in the observed tree, its kids are declared md-dead *before* the observers on those are disposed of, and immediately cells complains about accessing a dead cell. I am at a loss here, so any insight is greatly appreciated. My second question sounds really simple: I want to define a list of kids in an input slot, like (make-instance 'node :kids (c-in (list (make-instance 'node)))) Obviously I am missing the :fm-parent initarg here, so it won't work. But: How do I get the :fm-parent properly assigned for a (c-in initform)? Thanks, Peter

2 11

[cells-devel] Research has revealed!
by Frieda 13 Apr '08

13 Apr '08

Recent discoveries in herbal science have shed new light on the subject of penis enlargement. Research has revealed that your penis has the ability to grow beyond its current size when fully erect. Like all the other muscles in your body, your penis is actually designed to grow! http://www.qunebtoh.com/

1 0

[cells-devel] baby steps
by Ken Tilton 13 Apr '08

13 Apr '08

The attached works a tiny little bit. Running hunch, starting the server with the snippet at the top of example.lisp, running (reload), and then navigating to 8000/apropos I see three symbols matching the initial value of "md-slot-v". Deleting the "v" and then tabbing I see eight values matching "md-slot-". This required especially telling the handler creater not to expect "/apropos" as the prefix to subsequent messages (in fact ( i just defaulted if the name did not match apropos. Oh, you will also see hijinx where I store nodes by name as well as by ID, because I got back (("term" . "md-slot-")...) not (("i1234" . etc)) even though I see openair.js returns the id. Go figger. Oh. I may have really screwed up. At one point it seemed only the changed field (the search term) was being sent, suddenly I see the "pkg" as well, perhaps meaning there is no need to keep a copy of the client-side-data as you will see I am maintaining. Obviously I have no idea what is going on, perhaps I am seeing "pkg" only as a fluke behavior of pop-up menus (maybe if they are uninitialized they choose the first value and then that looks like a change to be transmitted?) I am clueless. If browsers always send all non-nil attributes with every request (a) that sounds like a waste and (b) we can lose the client-side-data hash table. Hopefully (a) is not the case (and anyway I thought /we/ were deciding what to send...hmmm, I am starting to like my theory about pop-up menus). whew! learning curves are exhausting, but fun. This seems to be working. I would love to feature this at eclm 2008 beacuse it shows how Cells interconnect values, how Cells facilitate the driving of an alien framework by a Lisp framework, and finally because it is Web 2.0, something folks might actually be interested in. Hang on. I just edited in some "<-kt" prefixed comments, and am attaching again example.lisp. I decided to retest and, whoa, a problem resurfaced: the whole thing simply stops working. I got stuck on this earlier and was just recompiling here and there with new debug statements and it started working again. That suggests, btw, that there is a defparameter or something that gets reset by the file being recompiled and reloaded (but I tried a full recompile and that did not help). Anyway, I am sure it is something stupid, and it is too late for me to stare at. kt ;; -*- mode: Lisp; Syntax: Common-Lisp; Package: cells; -*- #| Hunchncells -- Cells, Parenscript, and HTML Copyright (C) 2008 by Andy Chambers This library is free software; you can redistribute it and/or modify it under the terms of the Lisp Lesser GNU Public License (http://opensource.franz.com/preamble.html), known as the LLGPL. This library is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the Lisp Lesser GNU Public License for more details. |# ;; from Ken Tilton <kennytilton(a)optonline.net> ;; to achambers.home(a)gmail.com (Yes, this is you.) Learn more, ;; date Thu, Apr 3, 2008 at 3:15 PM ;; subject Re: [cells-devel] undersold aspect of cells ;; ;; A an interactive Lisp apropos is a good idea. The ACL gui version does ;; not search as the user types, but for fun we could do that, perhaps ;; doing it both ways to show before/after live during the talk. The ACL ;; dialogue has a checkbox for "exported only" and a pop-up menu of known ;; packages to choose-from to limit search to one package. A checkbox ;; next to it says "All" and means ignore whatever might be selected ;; (most UIs have a top item that says "All". anyway...). Then there is a ;; radio group of four buttons that also imits search to functions, ;; classes, variables, or all. Results are displayed in a scrolling list ;; with seven columns: name, package, function, setf, var, class, and ;; exported. Several of those are just booleans with an "x" showing if, ;; eg, the symbol has a function, a setter, a class, or is exported. The ;; var column shows var or con if it is a constant. The columns are ;; resizeable (bit of a frill). ;; Oh, and the input field is also a pop-up of the query history (which ;; would not make sense if each keystroke was treated as a new query. ACL ;; has a "search" button instead. Otherwise, the results pane is rebuilt ;; as the other filters are changed--the user does not have to hit Search ;; each time. ;; Anyway, I would be tempted to reinvent that as far as widget sets ;; allow: checkbox, radio button/group, the straight "search" button, ;; popup menus, and a multi-column scrolling grid view, input of course, ;; and then any decorative frames, say, to group the radio buttons. ;; Bonus points for a double-click taking them to the CLHS. :) ;; ;; (in-package :openair) (progn (declaim (optimize (debug 3) (speed 0) (safety 1) (compilation-speed 0)))) #+test (progn (when (and (boundp '*oa*) *oa*) (trc "stopping" *oa*) (hunchentoot:stop-server *oa*) (setf *oa* nil))) #+ughh (setf (log-file) "hunch.txt") (defparameter *oa* nil) #+test (let ((x (start-server :port 8000 :dispatch-table *dispatch-table*))) (setf *oa* x) (setf (log-file) "hunch.txt") ;; <-kt accomplished nothing (trc "got server" x) ;(hunchentoot:stop-server x) (describe x)) (defun reload () (cells-reset) (reset-sessions) (setf *catch-errors-p* nil *dispatch-table* (list ; (test-page "/check-test" 'web-checkbox) (test-page "/apropos" 'web-apropos) (create-folder-dispatcher-and-handler "/js/" "/mainline/js/")))) (defmd web-checkbox (page) (status (c? (param? "STATUS"))) (kids (c? (the-kids (mk-div () (mk-form (:action "get") (mk-checkbox "Status: " status) (mk-div () (mk-text (status (u^ web-checkbox)))))))))) (defmd web-apropos (page) (title "Lisp Apropos") (style "style.css") ;; <-kt all attributes moved into value slots of corresponding nodes (kids (c? (trc "page kids rule entry!!!!!!!!" self .cause) (the-kids (mk-div () (mk-form (:action "get") (mk-label (:for "term") "Apropos: ") (mk-input (:md-name :term :name :term :value (c-in "md-slot-v"))) ;; <-kt start somewhere for easier testing (mk-checkbox "Exported: " exported-only-p) (mk-label (:for "pkg") "Package: ") (mk-select (:md-name :pkg :name "pkg" :id "pkg") ;; <-kt was there an extra (list... here? Not needed (loop for pkg in (subseq (list-all-packages) 0 10) collect (let ((pkg pkg)) (mk-option () (mk-text (package-name pkg)))))) (mk-text (c? (if (fm^v :pkg) "on" "all"))) (mk-div (:id :result) (mk-ul () (loop for match in (bwhen (search (fm^v :term)) (let ((a (apropos-list search nil ;; (fm^v :pkg) <-kt- this started sneaking in, I punted (fm^v 'exported-only-p)))) (trc "got match count" (length a) search (fm^v :pkg) (fm^v 'exported-only-p)) (subseq a 0 (min 10 (length a))))) ;; <-kt- just making debugging manageable do (trc "piling up match" (^id) match) collect (let ((match match)) (mk-li () (mk-text match)))))))))))) (defun test-web-apropos () (cells-reset) (reload) #+nah (let ((app (mk-web-app (:prefix "testwa" :request (c-in nil)) (make-instance 'web-apropos :fm-parent *parent*)))) (declare (ignorable app)) (inspect app))) (defun test-request (self &rest req) (trc "test req" req) (describe req) (setf (request self) req) (loop for (h . xh) in (updates self) unless (loop for (h2 . nil) in (updates self) thereis (unless (eq h h2) (when (fm-ascendant-p h2 h) (trc nil "suppressing redundant" h :seeing-ascendant h2 (id h2)) t))) do (trc "bingo changed" h (id h)) (trc "new xhtml" xh) finally (setf (updates self) nil))) (defvar *web-app* nil) (defun test-page (path resource-class) (lambda (request) (trc "bingo request!!!!" request path resource-class) (start-session) (let ((root (or (session-value 'root) (progn (print "creating new web-app...") (mk-web-app (:prefix path :request (c-in request)) (make-instance resource-class :fm-parent *parent*)))))) (setf *web-app* root) (setf (session-value 'root) root) (assert (null (updates root))) ;; <-kt stumped at one point, then the issue just went away (setf (request root) request) (handler root))))

1 0

[cells-devel] Re: [cells-gtk-devel] Re: Anything new for me to show off at ECLM 2008?
by Ken Tilton 12 Apr '08

12 Apr '08

Peter Hildebrandt wrote: > Well, there's something wrong with the cells cvs again, so it would > not let me commit my latest changes. You can grab the latest version > here: > > http://www.washbear-network.de/fritz/pub/cells-gtk3.zip Hmmm, a little trouble there. PicoZip on WinXP cannot read it, WinZip on Vista (my new laptop for the eclm talk) complains but then seems to open it. The complaint looks like winzip just is not handling Vista. Maybe just tar.gz it? I appreciate the trouble you took making a zip, btw. Question 2: the above does not include a Cells directory (unless the expansion broke). I will be trying to build it (looks like I have to hack the ACL .lpr files for a while) in the meantime. > > My suggestions: > > (1) Cairo Drawing Area > > I have the cairo drawing area thing working by now and put in a simple > example (creates boxes and circles and random positions, then they > react on mouse over, can be selected, dragged around, and you can use > a select box (like in windows explorer) to select and move many shapes > at once). I finally took the time and get the kids slot to work > properly, so you can have ruled kids slots on your drawing primitives > and have cells create other shapes for you (say, you want to draw a > sun -- then you start with a yellow filled circle and have a kids rule > creating some lines for the rays. The number of rays may depend on a > widget (and so can the length), and you have a "declarative drawing"). Isn't that fun? I remember when we made kids a Cell (almost immediately). I was sure the wheels would fall off. It Just Worked(tm) and I started to suspect Cells would scale pretty well. > > (2) Tree View > >>From the stuff present in the demo I personally like the tree view > example, since it lets you explore the actual object hierarchy of the > demo. I don't even know whethe something like this could be done in C > at all. Omigod! I did an inspector at one point and used it to inspect the inspector window itself. Then I navigated down to the actual widgets in view and watched as the inspector showed things like the mouse-over state dynamically (without asking the inspector to refresh). I seem to recall adding some Cells internals to make it work, tho. In this screenshot: http://www.tilton-technology.com/cloucell.jpg ...the widget being inspected is the four-widget row just above "Class: Ixrow". > > (3) Cells Tree View > > Works like a charm -- as long as you don't delete stuff from the > observed structure (I ran into a conceptual problem with cells3 here, > gonna ask you on the cells list when I have the time to deal with > that). Anyway, I deactivated the delete button, and the rest is still > pretty nice. I look forward to the IR, maybe you have run into something I want to add to Cells to better handle things going away (a frequent problem). In my latest app I am running into a lot of problems with what is generally called referential integrity, specifically external references to kids that have been not-to-be'd. eg, my window's keep a reference to the "focus", which might be in a math problem the student decides to delete. uh-oh. Sprinkling (setf (focus w) nil) all over the place broke down when it ended up erasing a new value that had been set by code that tried to handle the problem by, say, moving the focus to the next problem when deleting the current problem. Man, imperative programming sucks. :) > > (4) Threading > > It is relly nice and lispy to use the repl to change properties of the > windows currently displayed and to add and remove widgets > interactively (especially if you have a background in C) -- but I > don't know whether that works in MS Windows. Just checked, > bordeaux-threads on windows does not support Allegro. Bummer. I will be doing repl stuff during my talk -- ACL runs a separate process from the IDE to execute Lisp. We just need to have a breather in the event loop handling to give the IDE enough cycles to be responsive. > > (5) MAYBE: cells-ode + open gl > > That'd be really neat -- if I figure out the opengl drawing area and > port my current physics simulator code to cells-ode as a backend plus > gtk-gl as a front end. They say there's a weekend coming up, so stay > tuned. OK, don't make yourself crazy on my account. In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew! cheers, ken

4 5

[cells-devel] Re: How do I do this in JS?
by Ken Tilton 12 Apr '08

12 Apr '08

Andy Chambers wrote: > On Fri, Apr 11, 2008 at 11:28 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > >>Instead of using gensyms to name (ID) interesting fields (not DIVs) I want >>to use their names, and do so as a path down from the page, so the id for >>the term input element would be, eg, "apropos.term" or "apropos/term". Then >>the Lisp-side tree of instances becomes its own dictionary (no need for >>mirroring slots on the page instance) and then we'll never have a problem >>with duplicates -- well, if we have a list of identical structures we'll get >>into a subscript as well, so how would I encode that? Suppose instead of >>just listing matches each match contained a checkbox to indicate (I don't >>know) show CLHS entry and then boom they hit enter and multiple entries >>appear. Well, they need the checkbox to have a path: >>apropos/match[42]/show-clhs. Is this where we do "apropos/match.42/clhs" as >>an ID? I guess I am asking what are the limitations on the id name >>characters. > > >>From the spec... > > ID and NAME tokens must begin with a letter ([A-Za-z]) and may be > followed by any number of letters, digits ([0-9]), hyphens ("-"), > underscores ("_"), colons (":"), and periods ("."). > > I hadn't actually noticed this before and assumed that anything would > be ok but went ahead and checked. > > However, this might not matter so much because you can do the thing > you want with jquery selectors and filters. Instead of a slash, you > use ">", and instead of [42], you use :nth-child(42) > > apropos/match[42]/show-clhs would then be > $("#apropos > #match :nth-child(42) > #show-clhs) Cool. Maybe I can leave this idea to you to implement? The idea would be to have a path slot on every node that for things which wold never change was nil and for anything else searched up to the first parent with a path and used that plus the symbol-name of its own :md-name which can be coded as a Lisp symbol such as 'term or :term (formatted into a JQ-acceptable selector as a string). One instance can reference another with (fm-other :term) or (fm^ :term) if the node is not a child (I can clean up all that whacky inter-model referencing syntax like fm-other and dm^), the only one who has to worry about the JQ names on the Lisp side is the bit that pipes things over to the browser and handles the (now) POSTs. I think widget values can be handled as usual in Cells apps: if it is an input field, just say c-in or c-input or c?n. We will only get POSTs from input fields, and Cells will allow those to be setf'ed when they come in. The page can have an equal hashtable to speed location of a CLOS instance given its JQ ID. An observer on the JQ path can stuff this dictionary, or just have the rule itself do it before returning the value: :jq-selector (c? (let ((n (symbol-name (md-name self))) (sa (jq-selector-above self)) (s (if sa (conc$ sa " > " sa) n)))) (setf (gethash s (jq-dict (u^ web-app))) self) s)) Something like that. > >> This may be easier than I thought! I was feeling the caffeine, now I am not. <g> Better you than me if you like where I am going with this. My one question is the same we had with cl-ode -- observers do not know which way a value is going. Observers now get passed the Cell (a very recent change) so we can use that: only ruled cells are headed outbound. I am just not sure that holds up -- what of we have an input Cell reserved for setting in reponse to things happening on the server? Well, we could say those still do not get propagated out to the browser -- those should be slots on the model, not widgets in the DOM. If we want a widget in the DOM to reflect that value (yes, this feels right) we just have a widget with a rule that says: (mk-text (c? (server-load (u^ web-app)))) Well, in that case I guess we would have a server instance as the parent of the web-app (remember when I said fm-top might not hold up?) but you get the idea. And even if this input=inbound, ruled=outbound breaks down we have the trick we are doing with cl-ode: simply flag the cell itself for direction. Hmmm, pardon the rambling, but we do have c?n slots. They run whenever something global changes to provide a default the user can override by typing, but meant to be re-defaulted if they go back and change this overarching other parameter. ie, I have changed the item selection so the size and color get re-defaulted, I am starting over. So this would be a two-way slot... it would mostly work except that the observer on xhtml will see a ruled /and/ input cell and not know if it should push it onto the updates. Hmmm. This is to be expected, we are once removed from the action. The first thing that pops into my head is a second dictionary, this time keying the jq selector to the value we know is over on the client side. The observer on xhtml can simply check that the new-value is not already on the client side. When we get posts, the first thing we do is record that that value is already on the client-side, before injecting the value into the Lisp model. Speaking of which, I guess inputs will come over one at a time as you have things set up, but if you think you'll ever get into bundling them up and sending over multiple inputs, we should apply another trick from cl-ode and control propagation (so multiple setf's look like one to the model). whew. I would gone back and edited all that but it may help for you to see my thought path (and maybe something in there sounds better to you than where I ended up). Man, you jumped in at the deep end, eh? :) kt ps. I CCed Peter H because he is the mover behind cl-ode and I thought he'd enjoy seeing the cross-pollenation. k

1 0

[cells-devel] [openair] Changes to get CSS styles working ...
by Frank Goenninger 11 Apr '08

11 Apr '08

Needed to make a small change in defmodel page: The lines with the :style got changed to: (:link :rel "stylesheet" :type "text/css" :href (^style)) Now CSS file loading works for me ... Cheers, Frank

1 0

[cells-devel] Re: Problem with request
by Ken Tilton 11 Apr '08

11 Apr '08

Ken Tilton wrote: > I made the change so the little indicator to the right of the package > pop-up says either "on" or "all" and that worked when I selected a > package. But then I clicked on exported-only and the tag reverted to > all. I had a lisp (describe request) in the processing stream and can > see why: > > #<HUNCHENTOOT::REQUEST @ #x21aa559a> is an instance of > #<STANDARD-CLASS HUNCHENTOOT::REQUEST>: > The following slots have :INSTANCE allocation: > HEADERS-IN ((:USER-AGENT > . "Mozilla/5.0 (Windows; U; Windows NT 5.1; > en-US) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13") > (:CACHE-CONTROL . "max-age=0") > (:X-REQUESTED-WITH . "XMLHttpRequest") > (:ACCEPT-LANGUAGE . "en-US") > (:ACCEPT-ENCODING . "gzip, deflate") > (:REFERER . "http://localhost:8000/apropos") > (:ACCEPT . "*/*") > (:COOKIE > . > "hunchentoot-session=3%3a0b9ec45ad30835f959590b891dc5ddee") > (:CONNECTION . "keep-alive") > (:HOST . "localhost:8000")) > METHOD :GET > URI "/apropos/EXPORTED-ONLY-P?EXPORTED-ONLY-P=on" > SERVER-PROTOCOL :HTTP/1.1 > CONTENT-STREAM #<FLEXI-STREAMS::FLEXI-BINARY-LATIN-1-IO-STREAM @ > #x219f7132> > COOKIES-IN (("hunchentoot-session" > . "3:0b9ec45ad30835f959590b891dc5ddee")) > GET-PARAMETERS (("EXPORTED-ONLY-P" . "on")) > POST-PARAMETERS NIL > SCRIPT-NAME "/apropos/EXPORTED-ONLY-P" > QUERY-STRING "EXPORTED-ONLY-P=on" > SESSION #<HUNCHENTOOT::SESSION @ #x21862422> > AUX-DATA NIL > RAW-POST-DATA NIL > > The get-parameters just shows the effected field. Is that something we > are doing? I would say we could change rules to say (or (param?...) > .cache), but I recall you said... well, that was attributes, nothing is > said if the attibute goes away or something. OK, I have been thinking. We like the granularity, so these get-parameters -- er, why aren't they post parameters? -- should not be treated as they are now as definitive of all the data, they just signify specific updates to the model. So I am thinking we take a different approach and simply loop over the values received and SETF the model slots, which should be c-in or c?n if they need to calculate an interesting initial value for a field based on other info. I will play with this. Meanwhile, I see a parameter on the server that says output-chunking is true -- in the request handler instead of bunging them all into a single string can we just write them one at a time to page and trust hunch to chunk them? kt

2 2

[cells-devel] OpenAIR: Doesn't work for me any more ...
by Frank Goenninger 11 Apr '08

11 Apr '08

Andy, I have tried to get this to work: --- BEGIN OF FILE --- (in-package #:openair) (defvar *web-app*) (defparameter *server* nil) (defun ht-monitor-page (path resource-class) (lambda (request) (start-session) (let ((root (or (session-value 'root) (mk-web-app (:prefix path :request (c-in request)) (make-instance resource-class :fm-parent *parent*))))) (setf *web-app* root) (setf (session-value 'root) root) (setf (request root) request) (handler root)))) (defmd ht-monitor (page) name ip-address term :title ":: HUNCHENTOOT MONITOR ::" :style "/css/ht-monitor.css" :name (c? (server-name *server*)) :ip-address (c_? (server-address *server*)) :term (c-in "") :kids (c? (the-kids (mk-div () (mk-text (c? (conc$ "Name: " (name (u^ ht-monitor))))) (mk-div () (mk-text (c? (conc$ "IP Address: " (ip-address (u^ ht- monitor))))))) (mk-form (:action "get") (mk-label (:for "i") (mk-text "Input: ")) (mk-input (:name "i" :id "i" :-type "text" :value (c? (reverse (term (u^ ht- monitor))))))) (mk-div () (mk-text (c? (conc$ "Reversed: " (reverse (term (u^ ht-monitor))))))) ))) (defun start-ht-monitor () (cells-reset) (reset-sessions) (setf *catch-errors-p* nil) (setf *print-circle* nil) (setf *dispatch-table* (list (ht-monitor-page "/ht-monitor" 'ht-monitor) (create-static-file-dispatcher-and-handler "/index.html" "/Users/frgo/projects/gt/app/ht-monitor/index.html") (create-folder-dispatcher-and-handler "/css/" "/Users/frgo/projects/gt/app/ht-monitor/css/") (create-folder-dispatcher-and-handler "/js/" "/opt/common-lisp/openair/js/"))) (when *server* (hunchentoot:stop-server *server*)) (setq *server* (hunchentoot:start-server :name "frgo's HT MONITOR" :port 4242 :dispatch-table *dispatch-table* ))) (export! start-ht-monitor) --- END OF FILE --- Symptoms: 1. No updates received from Web browser 2. When trying to update a slot on a page model I do not get any update of the Web page ... Is the git repo somehow in an "intermediate state" ? - I seem to remember you saying so in some email. Appreciate your feedback. Best, Frank

3 13

[cells-devel] [openair] redundant updates and mk-checkbox
by Andy Chambers 09 Apr '08

09 Apr '08

Hi Kenny, Just a quick note to mention various updates.... - reinstated the serverless test suite so that it works alongside hunch http://gitorious.org/projects/hunchncells/repos/mainline/commits/4c7bb90927 - added the mk-checkbox macro http://gitorious.org/projects/hunchncells/repos/mainline/commits/4a0795cb3 - prevention of redundant updates http://gitorious.org/projects/hunchncells/repos/mainline/commits/aa110dfe069 Cheers, Andy

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel April 2008