sorry but I do not have the energy to discuss that publicly and via email. The problem is that lot of people want a lot… and my energy is limited. Stef On Jun 16, 2012, at 12:06 PM, Mariano Martinez Peck wrote:

On Sat, Jun 16, 2012 at 5:41 AM, Sean P. DeNigris <sean@clipperadams.com> wrote: I was expecting "PackageOrganizer default packageOfClass: FileSystemError" to return "FileSystem-Core" but it returned "FileSystem-Core-Kernel", which is not a package. It's a category, but it's packaged in "FileSystem-Core". Is this a bug? Will PackageOrganizer go away when RPackage takes over?

We have been discussing this with Esteban last Monday. Indeed, there is something that does not work. With PackageInfo or whatever (before RPackage) you used to have a package and categories. So for example, the *Monticello* package Fuel has several categories: Fuel-Clusters, Fuel-Collections, Fuel-Errors, etc. From what I can see in RPackage, those categories are called packages as well.

So... I can get the RPackage for each of those categories:

(RPackageOrganizer default packageNamed: 'Fuel-Clusters') classes -> ok (RPackageOrganizer default packageNamed: 'Fuel-Collections') classes -> ok etc...

The problem is that so far you *cannot* get a RPackage representing a Monticello package. This is because a Monticello package could be represented as a *list* of RPackages. How do I get the classes of the monticello package Fuel? (RPackageOrganizer default packageNamed: 'Fuel') classes -> does not work

The problem is that 'Fuel' is considered as an individual RPackage (just as Fuel-Clusters, Fuel-Collections, etc). This problem is that

MCPackage >> correspondingRPackage

| symbol | symbol := Symbol readFromString: '#', self name. ^ RPackageOrganizer default packageNamed: symbol ifAbsent: [ nil ]

answers *one* RPackage where actually should be a list. So for example for the MCPackage of 'Fuel' I should get a list of all RPackages (Fuel-Clusters, Fuel-Collections, etc). Then I can do the inject:into or whatever if I want to ask/calculate sutff (like #classes and #extensionMethods).

Cheers

Sean

-- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Mariano http://marianopeck.wordpress.com

On Sat, Jun 16, 2012 at 2:44 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:

Stéphane Ducasse wrote

...

sorry but I do not have the energy to discuss that publicly and via

email.

...

The problem is that lot of people want a lot… and my energy is limited.

I understand your frustration, but if we can't discuss important new features on the developers list... wt#$@?!

Haha, He will not discuss, but we can :). The migration is also painful right now because system events are a mess. We have SystemChangeNotifier and SystemAnnouncer, and there is a nice hack to keep both working. SystemAnnouncer is registered to SystemChangeNotifier and old system events are magicly coerced, transformed(whatever name you want to put) into system announcements. And RPackage suffers because some clients of it, sends inconsistent events like: - method recategorized when the method was removed - a method removed event with an obsolete class that has no information - recategorizations with categories in nil??? So, my heart tells me that we have to clean that slowly also to lower the system's entropy. I've already moved some SystemChangeNotifier users to System announcer, there are left the senders of #notify:ofAllSystemChangesUsing: and some tests. So, there is a nice spot to attack. Once events are tammed, the Rpackage integration with the rest of the system will be cleaner and clear.

-- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p4635... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

sean this is not that we cannot discuss :) this is that I'm physically tired too. So I need to rest and somebody has to do the stuff at the end. Stef On Jun 16, 2012, at 2:44 PM, Sean P. DeNigris wrote:

Stéphane Ducasse wrote

...

sorry but I do not have the energy to discuss that publicly and via email. The problem is that lot of people want a lot… and my energy is limited.

I understand your frustration, but if we can't discuss important new features on the developers list... wt#$@?!

-- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p4635... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

EstebanLM wrote

Marcus proposal is good: map RPackage with MCPackage...

That sounds right to me... Mapping packages 1:1 with categories seems like perpetuating the "category = package" hack I thought we were trying to finally fix... Sean -- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p4635... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Jun 17, 2012, at 4:05 PM, Sean P. DeNigris wrote:

EstebanLM wrote

...

Marcus proposal is good: map RPackage with MCPackage, tag the subcategories (RPackage allow adding attributes).

I'm not sure I completely understand... So MCPackages will become RPackages,

Yes.

and subcategories will become RPackages tagged to indicate they belong to a parent package?

No. the *classes* will be tagged with the sub-category. There will only be one RPackage. Marcus -- Marcus Denker -- http://marcusdenker.de

Guys, we should hack this together. When is next sprint? :)

Next friday? Stef

On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 17 June 2012 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

...

Guys, we should hack this together. When is next sprint? :)

Next friday?

Yeah,.. because i still found things which i fail to understand in SystemNavigation: some while ago we kind of decided that best would be to match the protocol(s) of CompiledMethod and RGMethodDefinition, so you can use either one or another or mix of them as a model for browsers/lists etc including SystemNavigation.

But it looks like we're still not there:

methods := Object methodDict values. SystemNavigation default browseMessageList: methods name: 'Object methods'

fails miserably.. but if i convert it to #methodReference, it works:

methods := (Object methodDict values). methods := methods collect: #methodReference. SystemNavigation default browseMessageList: methods name: 'Object methods'

and i feel like i was fooled: we replaced one wrapper - MethodDefinition (or what was that?) with another with just different name. But we still cannot use CompiledMethod as a model for lists etc.. so can someone enlighten me, what is then changed, except a name(s)?

I did it a long time ago in VisualWorks 3.0 (IIRC). See below.

I am still clueless, why system tools cannot speak directly with object(s) under the question, if necessary?

The wrapper is a pointer. If one redefines a method when recompiling then the pointer refers to the current version of the method but a direct reference to the method answers the old version. The direct reference prevents the old version being garbage collected but the pointer does not. For these reasons we use methodReference and not direct references. So the use of pointers is necessary to make the tools work as expected. When methods are selected in the method list browser tools, the tools show current versions, not versions as of when they were opened. This is the same as the system browser, which holds onto class names and selectors, not on class objects and method objects. By the way, in the olden days the method list browsers worked with strings that looked like 'Foo selector' and 'Foo class selector:' which were pointers, but painful to parse to indirect to CompiledMethods. I added MethodReference in VisualWorks to replace these large and inflexible strings with explicit pointer objects. Looks like Squeak followed suit. As evidence of painful parsing here's code form the Smalltalk-80 MethodListBrowser: *MethodListBrowser methodsFor: 'method list'* *methodName: selection* | aStream aSymbol | methodName _ selection. selection == nil ifTrue: [selector _ nil. ^ self textMode: #unclassified]. aStream _ ReadStream on: selection. className _ (aStream upTo: $ ) asSymbol. aSymbol _ (aStream upTo: $ ) asSymbol. (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: [aSymbol _ (aStream upTo: $ ) asSymbol]. protocol _ self selectedClass organization categoryOfElement: aSymbol. self selector: aSymbol

-- Best regards, Igor Stasenko.

-- best, Eliot

On Sun, Jun 17, 2012 at 6:30 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 18 June 2012 01:13, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua@gmail.com>

wrote:

...

...

On 17 June 2012 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr>

wrote:

...

...

...

Guys, we should hack this together. When is next sprint? :)

Next friday?

Yeah,.. because i still found things which i fail to understand in SystemNavigation: some while ago we kind of decided that best would be to match the protocol(s) of CompiledMethod and RGMethodDefinition, so you can use either one or another or mix of them as a model for browsers/lists etc including SystemNavigation.

But it looks like we're still not there:

methods := Object methodDict values. SystemNavigation default browseMessageList: methods name: 'Object methods'

fails miserably.. but if i convert it to #methodReference, it works:

methods := (Object methodDict values). methods := methods collect: #methodReference. SystemNavigation default browseMessageList: methods name: 'Object methods'

and i feel like i was fooled: we replaced one wrapper - MethodDefinition (or what was that?) with another with just different name. But we still cannot use CompiledMethod as a model for lists etc.. so can someone enlighten me, what is then changed, except a name(s)?

I did it a long time ago in VisualWorks 3.0 (IIRC). See below.

...

I am still clueless, why system tools cannot speak directly with object(s) under the question, if necessary?

The wrapper is a pointer. If one redefines a method when recompiling then the pointer refers to the current version of the method but a direct reference to the method answers the old version. The direct reference prevents the old version being garbage collected but the pointer does not. For these reasons we use methodReference and not direct references. So the use of pointers is necessary to make the tools work as expected. When methods are selected in the method list browser tools, the tools show current versions, not versions as of when they were opened. This is the same as the system browser, which holds onto class names and selectors, not on class objects and method objects.

By the way, in the olden days the method list browsers worked with strings that looked like 'Foo selector' and 'Foo class selector:' which were pointers, but painful to parse to indirect to CompiledMethods. I added MethodReference in VisualWorks to replace these large and inflexible strings with explicit pointer objects. Looks like Squeak followed suit.

I know it. But the point is, that those tools are subscribed to system changes, and so, if listed method get changed or removed, the tool can update it's list accordingly, without a need to hold indirect pointer.

IIABDFI, KISS

...

As evidence of painful parsing here's code form the Smalltalk-80 MethodListBrowser:

MethodListBrowser methodsFor: 'method list' methodName: selection | aStream aSymbol | methodName _ selection. selection == nil ifTrue: [selector _ nil. ^ self textMode: #unclassified]. aStream _ ReadStream on: selection. className _ (aStream upTo: $ ) asSymbol. aSymbol _ (aStream upTo: $ ) asSymbol. (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: [aSymbol _ (aStream upTo: $ ) asSymbol]. protocol _ self selectedClass organization categoryOfElement:

aSymbol.

...

self selector: aSymbol

...

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

On Mon, Jun 18, 2012 at 12:46 AM, Igor Stasenko <siguctua@gmail.com> wrote:

But it looks like we're still not there:

methods := Object methodDict values. SystemNavigation default browseMessageList: methods name: 'Object methods'

This is working in my latest 2.0 image :^)