Administrator
|
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?
Sean
Cheers,
Sean |
On Sat, Jun 16, 2012 at 5:41 AM, Sean P. DeNigris <[hidden email]> wrote: I was expecting "PackageOrganizer default packageOfClass: FileSystemError" to 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 -- Mariano http://marianopeck.wordpress.com |
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 <[hidden email]> 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 > |
In reply to this post by Mariano Martinez Peck
Marcus proposal is good: map RPackage with MCPackage, tag the subcategories (RPackage allow adding attributes).
That solve all problems with few difficulties (and well... with time packages will adapt) this provides a transparent migration path, which is what we need. Esteban
On Jun 16, 2012, at 12:06 PM, Mariano Martinez Peck wrote:
|
Administrator
|
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
Cheers,
Sean |
Administrator
|
In reply to this post by Stéphane Ducasse
I understand your frustration, but if we can't discuss important new features on the developers list... wt#$@?!
Cheers,
Sean |
On Sat, Jun 16, 2012 at 2:44 PM, Sean P. DeNigris <[hidden email]> wrote:
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.
|
In reply to this post by Sean P. DeNigris
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-tp4635069p4635097.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by Guillermo Polito
> 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. oh yes :) I really appreciate your systematic effort to help. Indeed if we can remove Change notifier and revise the announcements raised it will make our life easier. Stef |
Administrator
|
In reply to this post by EstebanLM
I'm not sure I completely understand... So MCPackages will become RPackages, and subcategories will become RPackages tagged to indicate they belong to a parent package? Adapt how?
Cheers,
Sean |
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? :) On 17 June 2012 16:08, Marcus Denker <[hidden email]> wrote: > > 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 > > -- Best regards, Igor Stasenko. |
In reply to this post by Sean P. DeNigris
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, Not really better RingPckage. Ideally we should be able to use ring instead of MCdefinitions. MCPackage are just code model of package > and subcategories will become RPackages tagged to indicate they belong to a > parent package? > > > EstebanLM wrote >> >> with time packages will adapt >> > Adapt how? > > -- > View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p4635210.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by Igor Stasenko
> Guys, we should hack this together.
> When is next sprint? :) Next friday? Stef |
On 17 June 2012 23:17, Stéphane Ducasse <[hidden email]> 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 am still clueless, why system tools cannot speak directly with object(s) under the question, if necessary? -- Best regards, Igor Stasenko. |
On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <[hidden email]> wrote: --
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 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, Eliot |
On 18 June 2012 01:13, Eliot Miranda <[hidden email]> wrote:
> > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 17 June 2012 23:17, Stéphane Ducasse <[hidden email]> 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. > > 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. |
On Sun, Jun 17, 2012 at 6:30 PM, Igor Stasenko <[hidden email]> wrote:
IIABDFI, KISS
best, Eliot |
In reply to this post by Igor Stasenko
On Jun 18, 2012, at 12:46 AM, Igor Stasenko wrote: > On 17 June 2012 23:17, Stéphane Ducasse <[hidden email]> 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)? This is just that the code to fill up the list is just using the wrong initialization (it should not wrap ring objects) There is no need for Ring objects there. Ring objects are only needed for remote package browsing, method versions, change recorder. Now we should just sit with ben and look at the filling up of the tools. > I am still clueless, why system tools cannot speak directly with > object(s) under the question, if necessary? See above. > > > -- > Best regards, > Igor Stasenko. > |
In reply to this post by Igor Stasenko
On Mon, Jun 18, 2012 at 12:46 AM, Igor Stasenko <[hidden email]> wrote:
This is working in my latest 2.0 image :^) |
Free forum by Nabble | Edit this page |