Mikko Ahonen wrote:
So i would wait for performance to become a problem. If/when it
does, you can probably uses synaptic Cells to minimize
recomputation, or perhaps the application will suggest a new cells
trick -- recent work on a Cells-ODE had me implement user control
over propagation so one could do a bunch of state changes and
propagate just once. ie, where the user knows multiple state changes
can safely be treated as one, they can now get that by wrapping them
in with-user-propagation (or whatever I called it).
Great. Luckily, the performance will probably not be a problem in this
project.
Kenny wrote:
Welcome to the club. Feels like a free lunch, eh? :)
Based on the past few days' experience allow me to qualify that. Cells
has a cost, but it is a linear one: sorting out dependency screw-ups.
Sometimes I create in one lexical block of code quite a deep structure,
and if I happen not to wrap the initialization of a child in a rule and
that initialization hits another cell (very likely) then the containing
rule of that initialization (which wold have been the factory for that
level of widgets!) ends up dependent on something it should not depeend on.
What is astonishing to me is that this normally works, even though it
means that subtree of the GUI hierarchy was being forever
re-instantiated! But I have become accustomed to being astonished this
way, because it has happened from the beginning: things that should not
work tend to go quite well 99% of the time.
In this case I had a classic foreign reference (my GUI "math keypad"
looked at the Algebra being edited so it could offer little keys for the
variables in use) and when some structure got pulled out from under it
it ended up looking at dead instances. So I just fixed things so the
foreign reference was in a rule and would stay current with the changing
landscape.
One thing that is going on, btw, is improvements for Cells debugging,
including in part me figuring out something I had missed about the ACL
IDE. But re debugging, this brings me round to my main reason for
responding.
At ECLM I was approached after my talk by an engineer from Lispworks. He
astutely guessed that Cells presented challenges for debugging. I
confirmed that one direction of improvement for Cells would be enhance
diagnostics and debugging. But that was not the point I was getting at.
I ended up playfully suggesting CAPI get a Cells layer, hoping to land a
project to do so. The engineer scoffed at the idea, saying there would
have to be a lot of value in it for their customers before they would
consider such a travesty, and he did not see any value. :) Since he
already had seen Cells and how it worked, I suggested to him the problem
might be that he is a compiler person, not an application developer. He
actually assented to this, without budging.
So I have been enjoying greatly that the newest Cells fan is also a
heavy CAPI user, and it was so easy for you to see the advantages.
I am reminded of the first folks shown Visialc. Most were programmers,
one was a businessman. The programmers were bored by it, the businessman
wanted to acquire the product. :)
Sounds like you are doing great with your new product. Good luck with it!
kt
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
