[cells-devel] Inheritance from model, not model-object?
Kenny Tilton
kennytilton at optonline.net
Thu Jul 10 22:36:53 UTC 2008
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
More information about the cells-devel
mailing list