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