On Fri, Apr 4, 2008 at 6:20 PM, Ken Tilton kennytilton@optonline.net wrote:
Here's the latest source. I went back to making it work with hunchentoot becuase of the sessions thing. Is there a nice way to optionally depend on some library. The best I came up with was to put :use-hunch, or :use-aserve in *features* before loading and then have different defsystem forms for each case (like Edi does with cl-ppcre sort of). I suppose allegro users would probably always want to use aserve so maybe we'd just use #+allegro.
So what's up with that loop gotcha. Is that because of we're collecting a macro form?
I'll see if that's the problem.
-- Andy
Andy,
Just a quick note to say one of the source files (macros?) still had the hunchncells as the in-package form. Is it possible you sent the wrong source or were having problems because of a package mismatch?
kt
Git source also has the :hunchencells package reference. No mentioning of an :openair package definition.
// Frank
Am 04.04.2008 um 21:18 schrieb Ken Tilton:
Andy,
Just a quick note to say one of the source files (macros?) still had the hunchncells as the in-package form. Is it possible you sent the wrong source or were having problems because of a package mismatch?
kt _______________________________________________ cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
Frank Goenninger wrote:
Git source also has the :hunchencells package reference. No mentioning of an :openair package definition.
Thx. If none then Andy just has not committed, cuz I only saw one :hunchncells (no "e" in this hunchen) all else was :openair.
And it was my screw-up, somehow /I/ got a file mixed up in there.
Unfortunately I am on win32 and getting git there looks a little paingul, so Andy is being kind enough to spoonfeed me ZIPs. :)
kt
On 2008-04-04 16:31, Ken Tilton wrote:
Unfortunately I am on win32 and getting git there looks a little paingul,
There is a quite simple installer including all important dependencies:
http://msysgit.googlecode.com/files/Git-1.5.4-preview20080202.exe
It is said to be merged with mainline git in near future.
Ingo Bormuth wrote:
On 2008-04-04 16:31, Ken Tilton wrote:
Unfortunately I am on win32 and getting git there looks a little paingul,
There is a quite simple installer including all important dependencies:
http://msysgit.googlecode.com/files/Git-1.5.4-preview20080202.exe
It is said to be merged with mainline git in near future.
Brilliant! Thanks so much, and it is a nice installer indeed, lots of very good detail over what gets created and easily controlled.
Andy, I have now downloaded what you had using this command:
git clone git://gitorious.org/hunchncells/mainline.git
...while in my working directory of openair, so I now have all your code in \openair\mainline. We can leave the zips behind any time you are ready to commit.
Lemme know when that is done and I will bravely try to update. The on-line git doc actually looks pretty good, but any tips on the following would help:
picking up your latest version in toto committing anything I do so (a) it does not tromp on everything and (b) you can merge with it
thx again, Ingo.
kenny
I am wondering if we even need the content trick to detect what needs transmitting. Consider this very slightly modified (and untested) xml rule:
(defun xmlrule (class html-attrs) `(c? (with-output-to-string (s) (with-html-output (s nil :prologue nil) (,(intern (symbol-name class) :keyword) ,@(loop for (cl-meth attr) in html-attrs append `(,(intern (symbol-name attr) :keyword) (,cl-meth self))) ;; (^x) -> (x self) ,@(loop for (cl-meth attr) in '((id id) (cls class) (title title) (style style)) append `(,(intern (symbol-name attr) :keyword) (,cl-meth self))) ;; (^x) -> (x self) (str (apply #'concatenate 'string (loop for k in (^kids) ;; got to see kids change ;; but not if same kid changes its xml: collecting (without-c-dependency (xhtml k))))))))))
Now the observer on xmlrule just pushes the string onto the updates slot as an assoc of (cons self (^xhtml)) and the transmitter simply skips any entry who has any ascendant also in the updates list.
What would be fun would be the custom xget or xlookup extension I suggested. Then we let the browser do the work of assembling the xhtml and then simply have an observer that transmits xhtml when it changes, because all references to kids would look like:
(loop for k in (^kids) collecting `(<xlookup ,(xuid k)>))
... or whatever the syntax would be.
The nice thing here is the added efficiency. What if the apropos search parameters are changed to say "exported only"? Instead of sending over the whole list of exported functions afresh, we send over only a new list of xlookups because their xhtml bodies are all over there already. How cool is that?
And once the demp gets fleshed out and a single match is its own div with multiple columns we are seriously reducing traffic.
Thoughts?
kt
-
Andy Chambers -
Frank Goenninger -
Ingo Bormuth -
Ken Tilton