On Jan 30, 2008 3:23 PM, Elod Kironsky kironsky@grisoft.cz wrote:

Hm, if DynamicProtocols can be easily installed into the image from the Universe Browser, then I would say, just leave it to the developers then :-)

What do you think the 'dev' in dev-images means ? :-) This image has been created and is maintained for developers only.

Does the "traits" button is System Browser comes from DynamicProtocols?

Not at all.

On Jan 30, 2008 4:03 PM, Damien Cassou damien.cassou@gmail.com wrote:

...

Does the "traits" button is System Browser comes from DynamicProtocols?

Not at all.

Dumb question: What *are* they used for in the dev image when turned on?

Dumb question: What *are* they used for in the dev image when turned on?

Real answer, from memory, dynamically computed method protocols, just look at the list of categories in your preferences under dynamic protocols. Interesting idea, but Squeak's UI is slow enough as it is, it doesn't have extra cycles to spare.

Ramon Leon http://onsmalltalk.com

On 30-Jan-08, at 9:38 AM, Ramon Leon wrote:

...

Dumb question: What *are* they used for in the dev image when turned on?

Real answer, from memory, dynamically computed method protocols, just look at the list of categories in your preferences under dynamic protocols. Interesting idea, but Squeak's UI is slow enough as it is, it doesn't have extra cycles to spare.

Which is, if you think about it, a quite ridiculous state of affairs. Ten years ago with machines that struggled to achieve tinyBenchmark figures of 3 million bc/sec we were able to use the UI tolerably. My current machine manages 544 million bc/sec - 180 times as fast - and yet the UI is if anything slower and less usable. And this is in a plain 3.9 image without the cpu-sucking dynamic protocols!

Insane.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.

On Jan 30, 2008 5:54 PM, Jason Johnson jason.johnson.081@gmail.com wrote:

On Jan 30, 2008 4:03 PM, Damien Cassou damien.cassou@gmail.com wrote:

...

...

Does the "traits" button is System Browser comes from DynamicProtocols?

Not at all.

Dumb question: What *are* they used for in the dev image when turned on?

Dynamic Protocols computes method categories automatically. For example, you have a category for the long method (more than 10 lines), a category for debugging methods (with a self halt), a category for required methods (sent but not implemented)... If there is no method in a category, it is not displayed.

On Jan 30, 2008 3:48 PM, Petr Fischer petr.fischer@praguesoft.cz wrote:

Keep DynamicProtocols preinstalled in dev-image and set preference option to false by default (dynamicProtocolActivation).

This was my idea too.

I agree. The popup is also a bt annoying in the long term. I also got the impression that at each doit I did the protocols got recomputed....arghh

Stef

On Jan 30, 2008, at 4:28 PM, Ramon Leon wrote:

...

...

Keep DynamicProtocols preinstalled in dev-image and set preference option to false by default (dynamicProtocolActivation).

This was my idea too.

Damien Cassou

I'd think the things pre-installed are the ones that mostly everyone uses, like Shout and OmniBrowser. You long ago moved optional packages to the Universe, why would DynamicProtocols be any different?

Ramon Leon http://onsmalltalk.com

Nice catch. May be add a bug report because it would be that tool builders can rely on good information notification.

Stef

On Feb 3, 2008, at 4:07 PM, Zulq Alam wrote:

stephane ducasse wrote:

...

I also got the impression that at each doit I did the protocols got recomputed....arghh

You are correct. Each instance of OBCodeBrowser is registered to be notified of all system changes. Notification triggers regeneration of dynamic protocols.

A "do it" or "print it" is evaluated using Compiler>>#evaluate:in:to:notifying:ifFail:logged: which triggers this notification.

Confusingly, when you "debug it", this notification isn't sent. The code is compiled and executed but no notification is sent.

But, if you debug something that does change the system like: "Object compile: 'dude ^ ''sweet'''" then a notification is triggered.

I conclude that either "debug it" isn't correctly notifying or "do it"/"print it" are sending out unnecessary notifications.

With regard to dynamic protocols, none of this should matter if it were fast enough although it would help to reduce the number of times they are regenerated.

Regards, Zulq.

At Wed, 30 Jan 2008 08:22:16 -0700, Ramon Leon wrote:

...

Hi,

as the developer of both the Dynamic Protocols and the dev-images, I have included the firsts into the latter some times ago. I found them quite useful at that time. However, they slow down a lot the UI (which is already very slow). So, my question is:

Who wants me to continue including the dynamic protocols in the dev-images?

Is there anyone using them?

Bye

-- Damien Cassou

I vote remove them, first thing I do is disable them. As long as they're available on the universe like everything else, for those who want to install them.

Ramon Leon http://onsmalltalk.com

I agree. We should remove them if they're disabled by default. DocumentationInformations for newcomers in Script Manager (documentation->dynamicProtocols) is far enough (hoping developers have a good RTFM practice) to be informed about their existence.

-- Martial Boniou

Hey Zulq - way to go with investigating the problem! :)

The point of declaring interests precisely is that it allows the system to make the right space/time trade offs. Declaring interest in everything is quite likely to create (memory) problems worse than those it solves. Let me give a little background.

Squeak, like other Smalltalks and some other modern IDEs, has a Shared Code Model, which is used for pretty much all editing and viewing. It is pretty minimal, and well optimized for straight forward tasks, like compact storage in memory, execution, editing, history viewing. Of course, people want to do and see more that what is on the surface, in the model - people want a real time lint tool, they want to see required (unimplemented, but self sent) methods and so forth - these are Model Extensions (MEs). And of course they want them to appear in real time, at low latency, so the MEs need to be cached. But caching every computation possible over all the code in the image is insane, so we require tools to declare Explicit Interests - tell me in advance what you might ask, then I can cache just that.

With regard to what Zulq did - I'm almost sure the tools are not actually interested in Local Sends, per se. But what is happening is that some of the dynamic categories use other MEs that use LocalSends for their calculations. You see, we have Layered Extensions, because sometimes its worth caching some intermediate results, not just end results. So what you want to do is make sure that the tools declare interest in what they actually ask about, and then make sure that each Model Extension declares interest in any temporary values it uses, such as Local Sends. In particular, a quick check shows that the dynamic protocols do not express interests in RequiredSelectors - fixing this would probably improve things significantly. In an old demo tool I wrote that did this, RequiredSelectors were shown in real time.

What I summarized above is a pattern language for smart, efficient code analysis tools, described in a pattern paper by Andrew Black and myself [1]. I think it has many potential applications in Squeak. I would not be surprised if it can be used to improve the responsiveness of the existing tools - if someone is interested.

[1] http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf

Daniel

Zulq Alam wrote:

Hi Damien,

I like the dynamic protocols but don't use them because of the performance impact.

I was curious and profiled it. It looks like the local send cache is not being used as no interests are being declared.

In the code below I declare interest in everything. I'm not sure about the ramifications of this.

When cached it is almost usable - perhaps with some tweaking this excellent feature could be more widely used.

Regards, Zulq.

protocols := DynamicProtocols allAvailableProtocols. class := Object.

" clear caches " protocols asArray collect: [:dp | dp invalidateCache]. LocalSends current initialize.

TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. " 9.69 seconds "

TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. " 6.44 seconds - improvement from caches in dynamic protocols themselves"

" declare interest in everything (maybe wrong) " LocalSends current noteInterestOf: nil in: ProtoObject; noteInterestOf: nil inAll: ProtoObject allSubclasses.

" prime local send caches " TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. "6.49 seconds "

" local sends cached " TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. "0.69 seconds "

Damien Cassou wrote:

...

Hi,

as the developer of both the Dynamic Protocols and the dev-images, I have included the firsts into the latter some times ago. I found them quite useful at that time. However, they slow down a lot the UI (which is already very slow). So, my question is:

Who wants me to continue including the dynamic protocols in the dev-images?

Is there anyone using them?

Bye

Thanks you. It is a pattern paper, so that any existing examples would be welcome, and if you use them, any further experience is also of interest.

Daniel

itsme213 wrote:

"Daniel Vainsencher" danielv@tx.technion.ac.il wrote

...

[1] http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf

Very nice paper, thank you.

Sophie

Your changes sound like valuable infrastructure, not only for model extensions. To help them get included, I suggest you introduce them in small, well explained pieces. Note that classes are rather tricky objects, and class changes are tricky operations. Be careful... have tests.

Daniel

Matthew Fulmer wrote:

...

[1] http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf

On page 22 of this paper, you mentioned that the notification mechanism should tell you the previous values of classes and methods for the purpose of cache invalidation.

Goran and I made just these changes to SystemChangeNotifier in Squeak as part of our DeltaStreams project; now, when classes, methods, and class comments are changed, a notification with both the old and new version is sent. It is completely backward-compatible with the old SystemChangeNotifier protocol, as far as we can tell:

http://map.squeak.org/packagebyname/deltastreamfixes

In the future (a month or two), I'm going to augment the notifier again to support grouping of related changes, such as all changes involved in loading a package, filing-in a changeset, or loading a bug-fix, so that the enhanced logging features of DeltaStreams can show system changes at more the level the user made them; loading a package was a single-action to them; the log should show it as a single action.

Hi Zulq,

I don't have time to invest in this project. However, the repository is open. Feel free to commit anything you think appropriate. If you made any progress, let me know. Ask me any question you might have on the code, I'll be very happy to answer. I think that is it quite simple and there is not much code (most of the computation is done by another project which I didn't write).

Thank you

On Jan 30, 2008 5:59 PM, Zulq Alam me@zulq.net wrote:

Hi Damien,

I like the dynamic protocols but don't use them because of the performance impact.

I was curious and profiled it. It looks like the local send cache is not being used as no interests are being declared.

In the code below I declare interest in everything. I'm not sure about the ramifications of this.

When cached it is almost usable - perhaps with some tweaking this excellent feature could be more widely used.

Regards, Zulq.

protocols := DynamicProtocols allAvailableProtocols. class := Object.

" clear caches " protocols asArray collect: [:dp | dp invalidateCache]. LocalSends current initialize.

TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. " 9.69 seconds "

TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. " 6.44 seconds - improvement from caches in dynamic protocols themselves"

" declare interest in everything (maybe wrong) " LocalSends current noteInterestOf: nil in: ProtoObject; noteInterestOf: nil inAll: ProtoObject allSubclasses.

" prime local send caches " TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. "6.49 seconds "

" local sends cached " TimeProfileBrowser spyOn: [protocols collect: [:dpClass | dpClass on: aClass] thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]]. "0.69 seconds "

Damien Cassou wrote:

...

Hi,

as the developer of both the Dynamic Protocols and the dev-images, I have included the firsts into the latter some times ago. I found them quite useful at that time. However, they slow down a lot the UI (which is already very slow). So, my question is:

Who wants me to continue including the dynamic protocols in the dev-images?

Is there anyone using them?

Bye