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
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> 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?
pwuahahaha... so I am debugging a tooltip for the little icons by which
students can select a problem (they only see one at a time, that might
change) and the tooltip has to be cool cuz it has to show them the
wysiwyg math problem so it is not just a text string and in the case of
problems they enter (they can enter any problem) I have to look at the
first step of the problem and so I do and then I noticed... omigod. I am
capturing the first step in a closure that generates the tooltip that is
a view of the math expression (which at the top is boxed so it gets
mutated (never replaced)) so who can tell me what happens to the tooltip
if I leave the mouse over the icon while typing in the problem?
pwuahhahahahah!!!!!!
Meanwhile Windows Explorer still cannot figure out how to show me new
files until I find and select "Refresh view". pwuahahahahahaha!!!!!!
:)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On May 19, 1:16 pm, Ken Tilton <···········@optonline.net> wrote:
> Ken Tilton wrote:
> > 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?
>
> pwuahahaha... so I am debugging a tooltip for the little icons by which
> students can select a problem (they only see one at a time, that might
> change) and the tooltip has to be cool cuz it has to show them the
> wysiwyg math problem so it is not just a text string and in the case of
> problems they enter (they can enter any problem) I have to look at the
> first step of the problem and so I do and then I noticed... omigod. I am
> capturing the first step in a closure that generates the tooltip that is
> a view of the math expression (which at the top is boxed so it gets
> mutated (never replaced)) so who can tell me what happens to the tooltip
> if I leave the mouse over the icon while typing in the problem?
> pwuahhahahahah!!!!!!
>
> Meanwhile Windows Explorer still cannot figure out how to show me new
> files until I find and select "Refresh view". pwuahahahahahaha!!!!!!
>
Time for cl-explorer, or, naah, why be modest, cl-windows
> :)
>
> kenny
>
Mirko
Ken Tilton wrote:
> Maximum dependency chain is 41 which is kinda inconceivable to me (who
> was strangely too lazy to print the chain out--
Still lazy, but I figured it out without looking. It had to be the
sixteen problems. I lay out Algebra problems by placing them in an
ix-row-flow container. GUI containers are about the only place I use a
cells hack that lets a parent define rules for slots of its children.
This way widgets never worry about in what kind of container they sit,
row or stack, tho at runtime their geometry slots end up with rules
providing rowy or stacky behavior. Anyway...
(defmd ix-row-flow (...)
:kid-slots
(lambda (self)
(ecase (orientation .parent)
(:vertical
(list
(mk-kid-slot (px :if-missing t)
(c_? (^px-self-centered (justify .parent))))
(mk-kid-slot (py)
(c_? (py-maintain-pt
(eko (nil "psib-pb")
(^prior-sib-pb self (spacing .parent))))))))
(:horizontal
(list
(mk-kid-slot (py :if-missing t)
(c_? (py-self-centered self (justify .parent))))
(mk-kid-slot (px)
(c_? (px-maintain-pl
(^prior-sib-pr self (spacing .parent)))))))))))
Those two last lines are the answer to the question "41?": px (my
horizontal coordinate within my container) is computed releative to my
prior sibling's position. So with sixteen problems, the last one ends up
with a dependency chain sixteen longer than the intution would suggest
looking at the parent-child depth of the GUI structure.
The neat thing is that for some reason I decided to resize the window
while testing and the problems re-wrapped. And no one had written the
code to do that. It was Just There.
To be honest, I have to rein that in a bit: the GUI wiggles around too
much as is. Sit, GUI! Stay! <sigh> Programming....
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Ken Tilton wrote:
>
>> Maximum dependency chain is 41 which is kinda inconceivable to me (who
>> was strangely too lazy to print the chain out--
>
>
> Still lazy, but I figured it out without looking.
That'll teach me. I kinda knew it, too, cuz I could sworn when I
arranged for the row-flow to still line up the columns nicely that I had
had one big computation figure out a table of nice positions then looked
up by each widget by an index (it's position amongst the list of all
widgets, duh). So where's the 41? No more guessing:
0> new dd champ from user 41 :down-to <2175:a opnds/mx5809:� = (n7 q)>
0> end at opnds :of mx-product
0> called by implicitp :of mx-product
0> called by ipp :of mx-product
0> called by char-w :of mx-product
Holy cripes! The product wants to know if it is implicit or not to see
if it should miraculously appear. A product can change status based as
editing changes its operands. "xy" can be implict, my software forces
"x2" to be typed (and appear) as x*2 (where the asterisk is actually a
nice multiplication dot).
I might change this, btw. It is a little scary for the user, and I did
see a textbook show something like (x-y)2 which I thought was horrid but
still.
btw, sorry to beat a drum (ha!) but this is one reason academics do not
write applications -- this bit of the task is as time-consuming as it is
un-fun.
Anyway, it looks as if the product (well, the char width in font
metrics) is checking to see if the operands are such that explicitude is
mandated.
Anyway, we now start climbing up the nested math structure (which is at
once view and model, I learned over the course of about oooohhhhh
300kloc of C how much fun it was to separate those (not!!!!!!!!!!!!))
On belay! Climbing!
0> called by p-offset :of mx-variable (poffset = (cons px py))
0> called by px :of mx-variable (px = x (hz) position in parent's
coordinate system)
0> called by ll :of mx-product (ll = local left, my left bound in my
coordimate system)
0> called by p-offset :of mx-product
0> called by px :of mx-product
0> called by lr :of mx-difference
0> called by p-offset :of mx-difference
0> called by py :of mx-difference
0> called by lt :of mx-theq
0> called by size-delta :of mx-parens
Parens are a nuisance, especially if we want to use nice anti-aliased
fonts but still dynamically accept parnethesized math of arbitrary size).
0> called by bk-ascii-left :of mx-parens
0> called by bk-ends :of mx-parens
0> called by char-w :of mx-parens
heh-heh: while you are typing the software automatically bounces a given
pair of parens from () to [] to {} depending on the depth. I won't take
this opportunity to ask the academics out there what part of attention
to detail they do not understand... doh!
Climbing!!!
0> called by p-offset :of mx-theq
0> called by px :of mx-theq
0> called by ll :of mx-parens
0> called by p-offset :of mx-parens
0> called by px :of mx-parens
0> called by ll :of mx-product
0> called by p-offset :of mx-product
0> called by px :of mx-product
0> called by lr :of mx-sum
0> called by p-offset :of mx-sum
0> called by px :of mx-sum
0> called by lr :of mx-equality
0> called by p-offset :of mx-equality
0> called by px :of mx-equality
0> called by ll :of mx-theq
0> called by lr :of arcade-prb-view
Oh. My. God. We are finally out of the math to the conventional GUI
components, a problem view. What was that, 80% of the 41?!
And these problems are not editable. PWUAHAHAHAHAHHAHAA! All I need do
is define (probably) a special *make-editable* and have the math-makers
Do the Right Thing(tm) when constructing a math expression never to change.
Some other time, tho, she is plenty fast as is.
0> called by fixed-col-width :of arcade-examples-examples
0> called by max-per-row :of arcade-examples-examples
0> called by lr :of arcade-examples-examples
0> called by gui-geometry::row-flow-layout :of arcade-examples-examples
There it is, the single calculation deciding the regular layout even
though in a dynamically reflowing way.
0> called by lb :of arcade-examples-examples
0> called by lb :of ix-stack
0> called by lb :of arcade-examples
0> called by lb :of ix-stack
That was fun.
kenny
> It had to be the
> sixteen problems. I lay out Algebra problems by placing them in an
> ix-row-flow container. GUI containers are about the only place I use a
> cells hack that lets a parent define rules for slots of its children.
> This way widgets never worry about in what kind of container they sit,
> row or stack, tho at runtime their geometry slots end up with rules
> providing rowy or stacky behavior. Anyway...
>
> (defmd ix-row-flow (...)
> :kid-slots
> (lambda (self)
> (ecase (orientation .parent)
> (:vertical
> (list
> (mk-kid-slot (px :if-missing t)
> (c_? (^px-self-centered (justify .parent))))
> (mk-kid-slot (py)
> (c_? (py-maintain-pt
> (eko (nil "psib-pb")
> (^prior-sib-pb self (spacing .parent))))))))
> (:horizontal
> (list
> (mk-kid-slot (py :if-missing t)
> (c_? (py-self-centered self (justify .parent))))
> (mk-kid-slot (px)
> (c_? (px-maintain-pl
> (^prior-sib-pr self (spacing .parent)))))))))))
>
> Those two last lines are the answer to the question "41?": px (my
> horizontal coordinate within my container) is computed releative to my
> prior sibling's position. So with sixteen problems, the last one ends up
> with a dependency chain sixteen longer than the intution would suggest
> looking at the parent-child depth of the GUI structure.
>
> The neat thing is that for some reason I decided to resize the window
> while testing and the problems re-wrapped. And no one had written the
> code to do that. It was Just There.
>
> To be honest, I have to rein that in a bit: the GUI wiggles around too
> much as is. Sit, GUI! Stay! <sigh> Programming....
>
> kzo
>
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
> Ken Tilton wrote:
>>
>>
>> Ken Tilton wrote:
>>
>>> Maximum dependency chain is 41 which is kinda inconceivable to me
>>> (who was strangely too lazy to print the chain out--
>>
>>
>> Still lazy, but I figured it out without looking.
>
> That'll teach me. I kinda knew it, too, cuz I could sworn when I
> arranged for the row-flow to still line up the columns nicely that I
> had had one big computation figure out a table of nice positions then
> looked up by each widget by an index (it's position amongst the list
> of all widgets, duh). So where's the 41? No more guessing:
>
> 0> new dd champ from user 41 :down-to <2175:a opnds/mx5809:� = (n7 q)>
> 0> end at opnds :of mx-product
> 0> called by implicitp :of mx-product
> 0> called by ipp :of mx-product
> 0> called by char-w :of mx-product
>
> Holy cripes! The product wants to know if it is implicit or not to see
> if it should miraculously appear. A product can change status based as
> editing changes its operands. "xy" can be implict, my software forces
> "x2" to be typed (and appear) as x*2 (where the asterisk is actually a
> nice multiplication dot).
>
> I might change this, btw. It is a little scary for the user, and I did
> see a textbook show something like (x-y)2 which I thought was horrid
> but still.
>
> btw, sorry to beat a drum (ha!) but this is one reason academics do
> not write applications -- this bit of the task is as time-consuming as
> it is un-fun.
>
> Anyway, it looks as if the product (well, the char width in font
> metrics) is checking to see if the operands are such that explicitude
> is mandated.
>
> Anyway, we now start climbing up the nested math structure (which is
> at once view and model, I learned over the course of about oooohhhhh
> 300kloc of C how much fun it was to separate those (not!!!!!!!!!!!!))
>
> On belay! Climbing!
>
> 0> called by p-offset :of mx-variable (poffset = (cons px py))
> 0> called by px :of mx-variable (px = x (hz) position in parent's
> coordinate system)
>
> 0> called by ll :of mx-product (ll = local left, my left bound in my
> coordimate system)
>
> 0> called by p-offset :of mx-product
> 0> called by px :of mx-product
> 0> called by lr :of mx-difference
> 0> called by p-offset :of mx-difference
> 0> called by py :of mx-difference
> 0> called by lt :of mx-theq
> 0> called by size-delta :of mx-parens
>
> Parens are a nuisance, especially if we want to use nice anti-aliased
> fonts but still dynamically accept parnethesized math of arbitrary
> size).
>
> 0> called by bk-ascii-left :of mx-parens
> 0> called by bk-ends :of mx-parens
> 0> called by char-w :of mx-parens
>
> heh-heh: while you are typing the software automatically bounces a
> given pair of parens from () to [] to {} depending on the depth. I
> won't take this opportunity to ask the academics out there what part
> of attention to detail they do not understand... doh!
>
> Climbing!!!
>
> 0> called by p-offset :of mx-theq
> 0> called by px :of mx-theq
> 0> called by ll :of mx-parens
> 0> called by p-offset :of mx-parens
> 0> called by px :of mx-parens
> 0> called by ll :of mx-product
> 0> called by p-offset :of mx-product
> 0> called by px :of mx-product
> 0> called by lr :of mx-sum
> 0> called by p-offset :of mx-sum
> 0> called by px :of mx-sum
> 0> called by lr :of mx-equality
> 0> called by p-offset :of mx-equality
> 0> called by px :of mx-equality
> 0> called by ll :of mx-theq
> 0> called by lr :of arcade-prb-view
>
> Oh. My. God. We are finally out of the math to the conventional GUI
> components, a problem view. What was that, 80% of the 41?!
>
> And these problems are not editable. PWUAHAHAHAHAHHAHAA! All I need do
> is define (probably) a special *make-editable* and have the
> math-makers Do the Right Thing(tm) when constructing a math expression
> never to change.
>
> Some other time, tho, she is plenty fast as is.
>
> 0> called by fixed-col-width :of arcade-examples-examples
> 0> called by max-per-row :of arcade-examples-examples
> 0> called by lr :of arcade-examples-examples
> 0> called by gui-geometry::row-flow-layout :of arcade-examples-examples
>
> There it is, the single calculation deciding the regular layout even
> though in a dynamically reflowing way.
>
> 0> called by lb :of arcade-examples-examples
> 0> called by lb :of ix-stack
> 0> called by lb :of arcade-examples
> 0> called by lb :of ix-stack
>
> That was fun.
>
> kenny
>
>> It had to be the sixteen problems. I lay out Algebra problems by
>> placing them in an ix-row-flow container. GUI containers are about
>> the only place I use a cells hack that lets a parent define rules
>> for slots of its children. This way widgets never worry about in
>> what kind of container they sit, row or stack, tho at runtime their
>> geometry slots end up with rules providing rowy or stacky
>> behavior. Anyway...
>>
>> (defmd ix-row-flow (...)
>> :kid-slots
>> (lambda (self)
>> (ecase (orientation .parent)
>> (:vertical
>> (list
>> (mk-kid-slot (px :if-missing t)
>> (c_? (^px-self-centered (justify .parent))))
>> (mk-kid-slot (py)
>> (c_? (py-maintain-pt
>> (eko (nil "psib-pb")
>> (^prior-sib-pb self (spacing .parent))))))))
>> (:horizontal
>> (list
>> (mk-kid-slot (py :if-missing t)
>> (c_? (py-self-centered self (justify .parent))))
>> (mk-kid-slot (px)
>> (c_? (px-maintain-pl
>> (^prior-sib-pr self (spacing .parent)))))))))))
>>
>> Those two last lines are the answer to the question "41?": px (my
>> horizontal coordinate within my container) is computed releative to
>> my prior sibling's position. So with sixteen problems, the last one
>> ends up with a dependency chain sixteen longer than the intution
>> would suggest looking at the parent-child depth of the GUI
>> structure.
>>
>> The neat thing is that for some reason I decided to resize the
>> window while testing and the problems re-wrapped. And no one had
>> written the code to do that. It was Just There.
>>
>> To be honest, I have to rein that in a bit: the GUI wiggles around
>> too much as is. Sit, GUI! Stay! <sigh> Programming....
Kenny,
that's kind of a very good way of shedding some light on the inner
workings of Cells and Cello!
You definitely should add something like this explanation to the (I
almost stopped here ;-) documentation of Cells and Cello...
How did you turn on those cool debug prints?
Cheers
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank "frgo" a.k.a DG1SBG wrote:
>
> How did you turn on those cool debug prints?
New code. Look for count-model and c-depend-depth in md-utilities.lisp
next time I commit.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en