PackageOrganizer packages vs. categories

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

--
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.

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.

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 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.

But it looks like we're still not there:

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