Andy Chambers wrote:

I got the js-escape working better last night and went on to try and fill out the apropos demo but ran into some difficulties.

I may need to rethink the macrology because when I put the following into the web-apropos model, I just got a list of progvs.

(mk-div () (mk-ul () (loop for func in (apropos-list "prog") collect (mk-li () (mk-text func)))))

Don't feel bad, that is frequent "gotcha" even for loop veterans (and it is loop, not macrology, slowing you down (somewhat abbreviated): (loop for x in (apropos-list "prog") collect (let ((x x)) ;; shadow the "x" abused by loop (mk-text x)))

Also, only changes to attributes are getting propagated to the updates slot, not changes to kids.

Hey, just send me the latest code and I'll figure it out. If you do not have aserve working, we can probably figure it out with a test harness that writes updates to the console. I would make a top-level class: (defmd xh-driver () search-string (exported-only ...other input slots and really any slot you need to make this go... (xml (driven-xml))) (defun driven-xml (mk-page (loop for match in (apropos-list (search-string (u^ xh-driver))) when (or (exportedp match) (not (exported-only (u^ xh-driver)))) collect [xml for this symbol]))) Then (just typed in, polish required): (defun test-xh () (let ((d (make-instance 'xh-driver :search-string "prog" ;; no changes intended :exported-only (c-in nil)))) ;; changes intended (with-oa-updates-to-stream t ;; or "test.txt" (loop repeat 2 do (setf (exported-only d) (not (exported-only d)))))) with-oa-updates-to-stream is left as an exercise. It needs OA to always work by writing to some stream (*browser*? *xml-updates*?) and then you just bind that to t or some *sys-something* or an open file stream. I toggled both ways to test both /starting/ with nil and /changing/ to nil.

In short, I'm still plugging away at this but I might be further away from producing something useful than it has seemed so far. Sorry if I've got people's hopes up. Its just the typical time estimates of an inexperienced programmer.

haha, I think you are closer than you realize. Just send up flares early and often.

I'm going to go back to celtk and try to understand the way it does things a bit better and see if there's anything fundamental I've missed. I should maybe code the apropos thing in celtk to check how the user code should look and make similar sort of code work for the web.

Here's a quick question. If you want to make the kids of a mk-stack dependant on some other field in celtk, do you have to explicitly (make-instance 'stack :kids (c? ...) or should you still be able to use (mk-stack () ...)

mk-stack by default wraps what follows in a recalculating rule: (defmacro def-mk-inline (name (unlabelled labelled)) `(defmacro ,name ((&rest initargs) &rest kids) (if (evenp (length initargs)) `(make-instance ',',unlabelled :fm-parent *parent* ,@initargs :kids (c? (the-kids ,@kids))) `(make-instance ',',labelled :fm-parent *parent* :text ,(car initargs) ,@(cdr initargs) :kids (c? (the-kids ,@kids)))))) (def-mk-inline mk-row (frame-row labelframe-row)) (def-mk-inline mk-stack (frame-stack labelframe-stack)) kt

Another thought and generally useful Cells debugging tips... Andy Chambers wrote:

Here's a quick question. If you want to make the kids of a mk-stack dependant on some other field in celtk, do you have to explicitly (make-instance 'stack :kids (c? ...) or should you still be able to use (mk-stack () ...)

If something is not changing even though I wrote a rule for it, the first thing I might do is add a print statement inside the rule itself to (a) make sure it runs at least once and then (b) to see if it is running even though I thought it was not. Two different investigations might get spawned there. If a rule runs once and does not run again I inspect the instance that owns the slot and look to see if the cell struct is in the .cells slot or the .cells-flushed slot. If it is in the latter it means that the rule did not read any other slot that met all these requirements: 1. it is a cell slot (the default, overridden by saying :cell nil) 2. the slot of the instance read was mediated by a cell which... 3. ...itself had not been flushed. If a rule does not read any such slot it will never get run again so Cells pulls it out of action (but keeps it in the flushed list for debugging). btw, if you inspect a ruled cell you will discover that the code for the cell gets captured in a slot of the cell struct, again for debugging purposes. You can also inspect the slots for callers and useds (silly name, I know, I do that sometimes). If all is well you should see a cell for the slot .kids in the .cells list. That alone tells you it depends on /something/ and is still in the game. My next question would be to look at the captured code for the rule, and also look to see if the expected used other cell is in the useds list. Other investigations flow from that. If I am flushed, why are the slots I used not Cells or why did they get flushed. If I am not flushed and I have the right dependencies, why aren't they talking to me? Are /they/ changing? Debug observers on input cells can confirm they are changing. btw, I just thought of something going in the other direction that would make things /overactive/: I guess you will be handing a lot of strings, and the default "unchanged" test is EQL. You might want to specify: :unchanged-if 'string= ...or something. More as I thnk of it. kt