cells-devel

cells-devel@common-lisp.net

567 discussions

[cells-devel] trc strangeness
by Andy Chambers 12 Jun '08

12 Jun '08

Hi All, I've just come across some unintuitive behavior in trc that maybe you're interested in. I was writing the following unit-test for openair and the (check (search "status" ...) was failing, even though the trc just above it showed that "status" was clearly in the output. Turns out, when you just (princ (update chkbx)), the value that appears is "STATUS" (which is what I should have been testing for anyway). It was just baffling though to have trc tell me that the strings should match, but when the test actually runs, they don't. I think this is because I still don't understand properly how print and friends work. (deftest test-updates () (cells-reset) (princ #\Newline) (let* ((app (mk-web-app (:prefix "/app") (make-instance 'md-name-test :fm-parent *parent*))) (page (car (resource app))) (chkbx (fm-other :status :starting page))) (declare (ignorable app page chkbx)) (check (search "value='off'" (xhtml chkbx))) (add-post app "STATUS" "on") (check (search "value='on'" (xhtml chkbx))) (trc "upd" (update chkbx)) (check (search "status" (update chkbx))) (check (search "value=\\'on\\'" (update chkbx))))) -- Andy

2 1

[cells-devel] Where is each project?
by Stu Glaser 12 Jun '08

12 Jun '08

It's not the lack of documentation. I don't even know where to start. Where is the main web page for each of cells, celtk, cello, and cells-gtk? Where are the source code repositories for each? Is there a central location for the tidbits of documentation that exist? Also, what's the status of each. Actively developed, "finished", or left to rot? KT, which are you working on the most? Thanks, -Stu P.S. It would be real nice to have a canonical git repository for each on github or gitorious.

4 4

Fwd: [cells-devel] Where is each project?
by Andy Chambers 11 Jun '08

11 Jun '08

>> P.S. It would be real nice to have a canonical git repository for each >> on github or gitorious. > > I know CVS is quite old and people use darcs, git, svn, and mercurial > these days, but what advantage is it exactly that we would get from > migrating to git? There is a repo for celtk on gitorious. It includes an extra "expander" widget that I created and leaves out some of the allegro specific stuff that's in vanilla celtk. I've never really worked seriously with any other VCS but here's some of the things I like about Git. 1. encourages frequent commits (since commits can be done locally) 2. easy to create branches (and easier to merge them) 3. a nice interface to the history of your project (gitk) 4. a really nice emacs-mode (M-x git-status, M-x git-annotate) 5. easy creation of tarballs (git archive HEAD >project.gz) It interoperates nicely with cvs so there's no problem with setting up a repo on gitorious whose master branch simply mirrors the cvs repo. I think I sent a message to the list a while back that shows the steps I took to do this for celtk. -- Andy -- ---- Andy Chambers Formedix Ltd

1 0

[cells-devel] How to get free quality visitors to your website?
by Targeted＠common-lisp.net 09 Jun '08

09 Jun '08

No Matter what you are selling - Hit-Booster will send targeted visitors to your website! Within 15 minutes you will have your own website traffic generator that will bring in an ever increasing amount of hits to your websites! Automatically This software is perfect for bringing real traffic to your site... even if... it's an affiliate link where you have no control over the website content! For Full Details please read the attached .html file Unsubscribe: on attached html file click on contact form

1 0

[cells-devel] Re: [cells-gtk-devel] cells-gtk3 without libcellsgtk
by Ingo Bormuth 02 Jun '08

02 Jun '08

Hi Peter, sorry for that late reply. Due to a misbehaving progmailrc your last mail was sorted into the cells-devel folder where I didn't read it. Please find the following patched attached: 0001-Remove-clisp-hack.patch Complete removes the clisp-call-next-method hack as I think it's no longer needed at all. See below. 0002-In-cells3-def-c-output-was-renamed-to-defobserver.patch Renames remaining occurrences of 'def-c-output'. I wonder why there weren't any errors as the macro was removed from cells3. 0003-Inactivate-optional-stuff-by-default.patch Inactivate optional features (threads, cairo, opengl and libcellsgtk) by default. I think it's more convenient to activate those when needed instead of patching the .asd files all the time. Test-gtk.asd still does exactly this. > > 2. Also if used in a single threading environment (like clisp) > > (g-thread-init...) and (gdk-threads-init) do get called which > > results in an error. > > Hmm, I never changed that, I think. They were always called in > cells-gtk if IIRC. However, if it does no harm to leave them out, > then that seems the right thing to do. > > Are you on windows or linux? I'm just guessing, but it might be the > case that it is a GTK issue and not a cells-gtk issue whether to call > them: On linux GTK supports threads, so it might be necessary to call > those (even if you don't use threads yourself). On windows it > doesn't, so maybe you can't call them. In this case, we should > condition on :unix vs. :windows. But again, I'm just guessing. If > you're on linux, then forget everything I said. I'm primarily on sbcl/linux. Recently I started to maintain the project for clisp/windows. As far as I remember thought, I realized the described problem have way down on clisp/linux. > As to the call-next-method thing, the background is this: > > [...] > > I'd suggest you just go ahead and deactivate all > those calls (e.g by conditioning on :no-progn-combination instead of > :clisp), which should remove those warnings. As mentioned above I decided against ':no-progn-combination'. In my opinion the call-next-method hack is of little use since '(:method-combination progn)' was removed for clisp in 'cells.lisp'. Please tell me in case I'm wrong here so I can change the patch. Thanks again (everybody) Ingo _______________________________________________________________ Schon gehört? Der neue WEB.DE MultiMessenger kann`s mit allen: http://www.produkte.web.de/messenger/?did=3016

2 1

[cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?!
by Frank Goenninger 25 May '08

25 May '08

I have the following definition: ;; A task is a container for ops. A task holds its ops as kids. So, when a ;;; task is called the task will call its kids. (defmd task (family) (.md-name :accessor id :initarg :id) fn-code thread state nr-ops :id (c-in (gensym "GNC.APP.TASK-")) :fn-code (c-in nil) :thread (c-in nil) :state (c-in nil) :nr-ops (c? (loop for kid in (^kids) counting (eql (type-of kid) 'op) into ops-count finally (return ops-count)))) Now, when I do > (setq self (make-instance 'task)) TASK1 > (setq my-kid (make-kid 'task)) TASK 2 > (^nr-ops) 0 ... and this should now be 1, no ? Or what's the right way to add kids ? Thx for feedback! Best, Frank

3 5

[cells-devel] dependancy problem (I think)
by Andy Chambers 24 May '08

24 May '08

(defmd page (html) (xdefs (c? (fm-collect-if self (lambda (k) (not (eq (find-class 'text) (class-of k)))))))) (xhtml (c? (with-output-to-string (s) (with-html-output (s nil :prologue t :indent t) (:html (:head (:title (str (^title))) (:script :type "text/javascript" :src "/js/jquery.js") (:script :type "text/javascript" :src "/js/openair.js") (:script :type "text/javascript" (format t "defs = { ~{~a~} }; " (loop for def in (^xdefs) collect (format t "~s: ~s" (md-name def) (xhtml def))))) (:style :type "text/css" :href (^style))) (:body (:div :id "banner" (:h1 (str (^title)))) (:div :id "content" (str (apply #'concatenate 'string (loop for k in (^kids) collecting (without-c-dependency (xhtml k))))))))))))) Adding the xdefs rule above makes cells ask me to "see listener for cell rule cycle diagnostics". What does this mean? Is there another way of writing this rule to avoid this? I get the same error if I wrap the rule in a without-c-dependancy but I'm not sure what this means anyway. Cheers, Andy -- ---- Andy Chambers Formedix Ltd

1 0

[cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings
by Peter Hildebrandt 21 May '08

21 May '08

SBCL kept bugging me with style-warnings when compiling defmd/defmodels for the first time. Wrapping the defclass part of defmodel in an eval-now! fixes it nicely: ; ------- defclass --------------- (^slot-value ,model ',',slotname) (eval-now! ;; suppress style warning in SBCL, ph (prog1 (defclass ,class ,(or directsupers '(model-object)) ;; now we can def the class I committed that to CVS today. Lemme know whether anything breaks. Peter

3 3

[cells-devel] How does cells deal with in-place modification of slot values?
by Larry Clapp 20 May '08

20 May '08

See subject. In other words, say I have a class with two slots, a and b, with b sort-of dependant on a: (defmodel test () ((a :initarg :a :initform (c-in (list 'a)) :accessor a) (b :initarg :b :initform (c? (car (^a))) :accessor b))) (defmethod print-object ((self test) stream) (print-unreadable-object (self stream :type t :identity t) (format stream "a: ~S, b: ~S" (^a) (^b)))) (setf *a* (make-instance 'test)) CELLS 11 > *a* #<TEST a: (A), b: A 22ED4D93> CELLS 12 > (setf (car (a *a*)) 'd) D CELLS 13 > *a* #<TEST a: (D), b: A 22ED4D93> Slots a and b are now out of sync. What's the ideo-cells-ic way to do this? What I'm really trying to do is wrap a class around somebody else's object. The internal state of the object changes, and I'd like to figure out some way to make the Cells system aware of the change. "Native" use of the object is something like this (some-other-package:perturb-test self) Do I need to wrap perturb-test too? e.g. (defmodel test () ((a :initarg :a :initform (c-in (list 'a)) :accessor a) (a-changed :initform (c-in 0) :accessor a-changed) (b :initarg :b :initform (c? (and (^a-changed) (car (^a)))) :accessor b))) (defmethod print-object ((self test) stream) (print-unreadable-object (self stream :type t :identity t) (format stream "a: ~S, b: ~S" (^a) (^b)))) (setf *a* (make-instance 'test)) (defun perturb-test (self y) (prog1 (setf (car (^a)) y) (incf (^a-changed)))) CELLS 34 > *a* #<TEST a: (D), b: D 200A742F> CELLS 35 > (perturb-test *a* 'e) E CELLS 36 > *a* #<TEST a: (E), b: E 200A742F> -- Larry

3 4

[cells-devel] Cells stats just posted to CLL under "I never did this before"
by Ken Tilton 19 May '08

19 May '08

Traversed a real world (look it up) Cells model (pretty much a control bar, two list boxes with a total of less than 20 items, then a display of sixteen algebra problems with <gasp> each algebraic node implemented by its own model (cells-powered class) instance) [such that 2+4 would be four clos instances counting a top-level container I use] culling stats: Surprisingly few instances: 438, and a little more than half of those to cover the math nodes. Hmm, just realized that might make this model unrepresentative -- or will any big, realistic model involve half the instances being from one small but vital subtree of the overall OO hierarchy? As predicted, the silver bullet: an average of 1-2 (I had guessed 2-3, but on reflection that sounds right) dependencies per ruled cell (the silver bullet being natural decomposition of what Brooks took to be ineluctable (his word was "intrinsic") complexity arising from exponentially climbing interdependence as kinds of states grew). Cells created: 7000 Ruled cells: 5800 Input cells: 1200, a shocker, but 1000 are kludges to avoid insane dependency on the mouse position that is trivial to handle imperatively (well, by an observer on the mouse position cell) and another hundred are similarly multitudes of OS-event hooks used so not everyone ends up sitting there waiting on (and processing) every click event. Ruled cells optimized away (no dependencies found): 2000 No surprise there, always had big savings from cell optimization. Intriguing histogram of length of dependency chain (ignore column one, my trace function does something with real time): time count length of dependency chain 18569 ... 1 ... (:DEP-DEPTH 39) 18570 ... 1 ... (:DEP-DEPTH 40) 18572 ... 2 ... (:DEP-DEPTH 36) 18575 ... 3 ... (:DEP-DEPTH 35) 18578 ... 3 ... (:DEP-DEPTH 41) 18586 ... 8 ... (:DEP-DEPTH 22) 18594 ... 8 ... (:DEP-DEPTH 25) 18602 ... 8 ... (:DEP-DEPTH 28) 18610 ... 8 ... (:DEP-DEPTH 31) 18618 ... 8 ... (:DEP-DEPTH 30) 18635 ... 17 ... (:DEP-DEPTH 34) 18655 ... 20 ... (:DEP-DEPTH 21) 18677 ... 22 ... (:DEP-DEPTH 18) 18699 ... 22 ... (:DEP-DEPTH 37) 18723 ... 24 ... (:DEP-DEPTH 33) 18751 ... 28 ... (:DEP-DEPTH 27) 18787 ... 36 ... (:DEP-DEPTH 24) 18843 ... 56 ... (:DEP-DEPTH 32) 18903 ... 60 ... (:DEP-DEPTH 17) 18964 ... 61 ... (:DEP-DEPTH 15) 19029 ... 65 ... (:DEP-DEPTH 38) 19094 ... 65 ... (:DEP-DEPTH 12) 19172 ... 78 ... (:DEP-DEPTH 19) 19251 ... 79 ... (:DEP-DEPTH 9) 19331 ... 80 ... (:DEP-DEPTH 14) 19413 ... 82 ... (:DEP-DEPTH 20) 19501 ... 88 ... (:DEP-DEPTH 23) 19591 ... 90 ... (:DEP-DEPTH 29) 19683 ... 92 ... (:DEP-DEPTH 26) 19811 ... 128 ... (:DEP-DEPTH 6) 19997 ... 186 ... (:DEP-DEPTH 11) 20214 ... 217 ... (:DEP-DEPTH 16) 20524 ... 310 ... (:DEP-DEPTH 8) 20921 ... 397 ... (:DEP-DEPTH 13) 21329 ... 408 ... (:DEP-DEPTH 5) 21936 ... 607 ... (:DEP-DEPTH 10) 22553 ... 617 ... (:DEP-DEPTH 4) 23295 ... 742 ... (:DEP-DEPTH 7) 24101 ... 806 ... (:DEP-DEPTH 3) 27277 ... 3176 ... (:DEP-DEPTH 2) I like the outliers at some of the depths, again probably because of the (unusual?) distribution of instance classes. Anyway... Maximum dependency chain is 41 which is kinda inconceivable to me (who was strangely too lazy to print the chain out-- well, I actually was gunshy because of a fascinating problem here: traversing the dependency graph "the other way" (from user to used) was computationally ridiculous! I had to do some memoizing! Yet going the other way (propagating from basically OS event forward to dependents) is crazy fast. Clearly a Message From God, just not sure what. Anyway...) I mean, yeah, it (the chain of 41) is GUI-geometry related and I guess comes from the position of some high-level container being dependent (eventually) on the font metrics of the denominator of the fraction in the product in the sum on the right side of the equation... Buddha covered this, the universe being one vast web of cause and effect amongst universally interconnected stuff -- anyway, looks like some simple lockdowns could reduce that a lot, but the app is pretty snappy as is. Calling up the sixteen problems (going from a list item not implemented so it shows zero problems) shows that cost in isolation (timing columen deleted this time): 308 ... (:MD-AWAKEN) Those are new model instances coming to life, mostly math 2321 ... (:C-AWAKEN) Cells needed by those instances to mediate their slots. Again, probably 900 low-functionality input cells as an optimization trick. 5927 ... (:MD-INSTALL-CELL) Hang on, that is the real cell count. Oh, OK. the count :c-awaken gets hit during md-awaken only if a scan of the slots of a new instance finds a nascent cell. Cells can be awakened JIT if some other new cell asks for them and this happens roughly 3606/5927th of the time. 665 ... (:C-OPTIMIZED) Take away the input cells (they cannot be optimized away) and we are looking at 40% optimization of ruled Cells into fixed values. 3911 ... (:CPROPAGATE) 16148 ... (:ENSURE-VALUE-IS-CURRENT) That be the dataflow. Lots of ensure current, but you wanted data integrity, right? kt

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
57
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel