Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Denis Kudriashov]

Hi Eliot.

I know and I only talk about new messages. I am not trying to rethink full
meta model of Smalltalk.
By the way #class is very common message and it is handy to use short name.
But pinning messages will be used rarely in very specific applications. So
no much sense to preserve them in short version.

2017-09-12 18:05 GMT+02:00 Eliot Miranda :

> Hi Denis,
>
>
> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov 
> wrote:
>
> I am really wonder guys. I thought you are not big funs of Object protocol.
> Current pinning messages are a new set of very generic messages in the
> Object.
>
>
> Yes, and that's because this is a fundamental property of all
> non-immediate objects.  Do you object to the #class message?  Should it be
> #classObject because it might conflict with #class used in an educational
> or socioeconomic model?  All objects other than immediates can move.
> Pinning stops that movement.  It applies generally.  So the protocol
> belongs in Object.
>
>
>
> About Norbert idea.
> - bePinnedObject is not bad convention. But I would prefer the memory
> suffix because it reflects the low level behaviour.
>
> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano :
>
>> yes, me :)
>>
>> I do not see a reason to change them, tbh.
>> for me they are comprensible as they are now and it does not adds more
>> information pinInMemory or pinMemory.
>>
>> Esteban
>>
>>
>> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
>>
>> Anybody else?
>>
>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek :
>>
>>>
>>>
>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
>>>
 Hi.

 We now have very generic message names:
 - pin
 - unpin
 - setPinned:
 - isPinned

 Problem that they collide with possible domain related names.
 For example I implemented pinning of tabs in Calypso and I found that I
 overrides #pin and #isPinned messages. Then I fix it with different names.
 Probably menus also uses pin word but without overrides

 What you think about renaming pinning messages? Something like:
 - pinMemory

>>>
>>> I would use pinInMemory
>>>
>>> -- Pavel
>>>
>>>
 - unpinMemory
 - isMemoryPinned
 - setPinnedMemory:
 - pinMemoryDuring: (if we will introduce it)

 I think it is easy to do now because not much code uses pinning

>>>
>>>
>>
>>
>

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Eliot Miranda]

Hi Denis,


> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov  wrote:
> 
> I am really wonder guys. I thought you are not big funs of Object protocol.
> Current pinning messages are a new set of very generic messages in the Object.

Yes, and that's because this is a fundamental property of all non-immediate 
objects.  Do you object to the #class message?  Should it be #classObject 
because it might conflict with #class used in an educational or socioeconomic 
model?  All objects other than immediates can move.  Pinning stops that 
movement.  It applies generally.  So the protocol belongs in Object.


> 
> About Norbert idea.
> - bePinnedObject is not bad convention. But I would prefer the memory suffix 
> because it reflects the low level behaviour.
> 
> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano :
>> yes, me :)
>> 
>> I do not see a reason to change them, tbh.
>> for me they are comprensible as they are now and it does not adds more 
>> information pinInMemory or pinMemory.
>> 
>> Esteban
>> 
>> 
>>> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
>>> 
>>> Anybody else?
>>> 
>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek :
 
 
 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
> Hi.
> 
> We now have very generic message names:
> - pin
> - unpin
> - setPinned:
> - isPinned
> 
> Problem that they collide with possible domain related names. 
> For example I implemented pinning of tabs in Calypso and I found that I 
> overrides #pin and #isPinned messages. Then I fix it with different names.
> Probably menus also uses pin word but without overrides
> 
> What you think about renaming pinning messages? Something like:
> - pinMemory
 
 I would use pinInMemory
 
 -- Pavel
  
> - unpinMemory
> - isMemoryPinned
> - setPinnedMemory:
> - pinMemoryDuring: (if we will introduce it)
> 
> I think it is easy to do now because not much code uses pinning
 
>>> 
>> 
> 

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[H. Hirzel]

On 9/12/17, Denis Kudriashov  wrote:
> I am really wonder guys. I thought you are not big funs of Object protocol.
> Current pinning messages are a new set of very generic messages in the
> Object.
>
> About Norbert idea.
> - bePinnedObject is not bad convention.

>But I would prefer the memory
> suffix because it reflects the low level behaviour.
+1


> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano :
>
>> yes, me :)
>>
>> I do not see a reason to change them, tbh.
>> for me they are comprensible as they are now and it does not adds more
>> information pinInMemory or pinMemory.
>>
>> Esteban
>>
>>
>> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
>>
>> Anybody else?
>>
>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek :
>>
>>>
>>>
>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
>>>
 Hi.

 We now have very generic message names:
 - pin
 - unpin
 - setPinned:
 - isPinned

 Problem that they collide with possible domain related names.
 For example I implemented pinning of tabs in Calypso and I found that I
 overrides #pin and #isPinned messages. Then I fix it with different
 names.
 Probably menus also uses pin word but without overrides

 What you think about renaming pinning messages? Something like:
 - pinMemory

>>>
>>> I would use pinInMemory
>>>
>>> -- Pavel
>>>
>>>
 - unpinMemory
 - isMemoryPinned
 - setPinnedMemory:
 - pinMemoryDuring: (if we will introduce it)

 I think it is easy to do now because not much code uses pinning

>>>
>>>
>>
>>
>

Re: [Pharo-dev] Tricky Metaclass>>binding

[Guillermo Polito]

I don't know... I found the idea of having a Metaclass binding strange...

I mean,
- metaclasses are not stored in any name dictionary such as Smalltalk
- nobody references them directly in source code but by their direct classes

The metaclass binding is there just for one thing really: methods need an
association to know their class in case they have to do a super send. And
transitively this is a compiler problem also. But anybody else accesses
metaclasses' bindings.
​

Re: [Pharo-dev] About Git support for windows

[Peter Uhnák]

>
> Just a random idea, how about each time writing timestamps to
> a different file name "timestamps.$HashOfClassSourceFile"
> Then git would never complain of a conflict(??).
>

If I understand your proposal correctly, that would imo result in the
following:

accumulating endless list of timestamps.XXX files (there are no conflicts
and thus no mechanism to get rid of them)
still having conflict, because the #sourceHash is different (any two
independent changes to a line will trigger conflict)
plus added complexity and a lot more reading/processing CPU/disk required

P

[Pharo-dev] [OOPS @ SAC 2018] Extended submission deadline: Sept. 25

[Nick Papoylias]

**
  OOPS 2018 Call for Papers
Object-Oriented Programming Languages and Systems
   http://oops.disi.unige.it/OOPS18
**

Technical Track at the 33rd ACM Symposium on Applied Computing, SAC 2018
https://www.sigapp.org/sac/sac2018/index.html

April 9 - 13, 2018
Pau, France

- Important Dates

Submission of regular papers and SRC abstracts
*September 25, 2017 (extended deadline)*
Paper and SRC notifications
November 10, 2017
Paper and SRC camera-ready copies
November 25, 2017
Author registration
December 10, 2017
SAC 2018
April 9 - 13, 2018

- Track Chair

Davide Ancona (davide.anc...@unige.it)
DIBRIS, University of Genova, Italy

- SAC 2018

For the past thirty two years, the ACM Symposium on Applied Computing (SAC)
has been a
primary gathering forum for applied computer scientists, computer
engineers, software
engineers, and application developers from around the world.

SAC 2018 is sponsored by the ACM Special Interest Group on Applied
Computing (SIGAPP) and
is hosted by hosted by Université de Pau et des Pays de l'Adour (UPPA),
Pau, France.

- Call For Student Research Abstracts

Graduate students seeking feedback from the scientific community on their
research ideas
are invited to submit original abstracts of their research work in areas of
experimental
computing and application development related to SAC 2018 Tracks. The
Student Research
Competition (SRC) Program is designed to provide graduate students the
opportunity to meet
and exchange ideas with researchers and practitioners in their areas of
interest.

- OOPS Track: Aims and Topics

Object-oriented programming (OOP) has become the mainstream programming
paradigm for
developing complex software systems in most application domains.

However, existing OO languages and platforms need to evolve to meet the
continuous demand
for new abstractions, features, and tools able to reduce the time, effort,
and cost of
creating object-oriented software systems, and improving their performance,
quality and
usability.

To this aim, OOPS is seeking for research advances bringing benefits in all
those typical
aspects of software development, such as modeling, prototyping, design,
implementation,
concurrency and distribution, code generation, analysis, verification,
testing, debugging,
evaluation, deployment, maintenance, reuse, and software evolution and
adaptation.

The specific topics of interest for the OOPS track include, but are not
limited to, the
following:

*Aspects and components
*Code generation, and optimization, just-in-time compilation
*Context-oriented programming
*Databases and persistence
*Distribution and concurrency
*Dynamic and scripting languages
*Evaluation
*Feature Oriented Software Development and Programming
*Formal verification
*Internet of Things technology and programming
*Integration with other paradigms
*Interoperability, versioning and software evolution and adaptation
*Language design and implementation
*Modular and generic programming
*Reflection, meta-programming
*Runtime verification and monitoring
*Safe, secure and dependable software
*Static analysis
*Testing and debugging
*Type systems and type inference
*Virtual machines

OOPS offers a great opportunity to the OOP community to gain visibility,
and to
exploit the inter-disciplinary nature of SAC.

- Submission Instructions

Prospective papers should be submitted to the track in pdf format using the
START
submission system for regular and SRC papers available through the SAC 2018
home page.

Submission of the same paper to multiple tracks is not allowed; all papers
should
represent original and previously unpublished works that are currently not
under review in
any conference or journal. Both basic and applied research papers are
welcome.

SAC 2018 will use double-blind reviewing; to facilitate this, author
name(s) and
institution(s) must be omitted, and references to authors' own related work
should be in
the third person.

The format of the paper must adhere to the sig-alternate style
(http://www.acm.org/sigs/publications/proceedings-templates).

Full papers are limited to 8 pages, in camera-ready format, included in the
registration
fee. Authors have the option to include up to two (2) extra pages at
additional fee of
US$80 per page.

Papers accepted as posters are limited to 3 pages, in camera-ready format,
included in the
registration fee. Authors have the option to include only one (1) extra
page at additional
fee of US$80.

SRC abstracts are limited to 2 pages, in camera-ready format, included in
the registration
fee. No extra pages are allowed.

Papers that fall short the above requirements are subjected to rejection.
All papers must
be submitted by September 15, 2017. For more information please visit the
SAC 2018 home
page.

- Proceedings

Accepted papers will 

Re: [Pharo-dev] About Git support for windows

[Ben Coman]

On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano 
wrote:

>
> On 10 Sep 2017, at 10:56, Henrik-Nergaard  wrote:
>
> Everyone who used filetree with metadata can tell it is super annoying and
>
> destroys the complete experience.
> There has been a fix for this on the issue tracker for some time:
> https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-
> metadata-in-order
>
>
> that’s not related. Timestamp conflicts are related two different users
> touching exactly same part of source: conflict guaranteed, no matter the
> order.
>

Just a random idea, how about each time writing timestamps to
a different file name "timestamps.$HashOfClassSourceFile"
Then git would never complain of a conflict(??).

I haven't thought that through a lot.  I guess with a git merge you end up
with two "timestamps" files with different stamps for the same method so
its unclear which to use - so the timestamps file might include the hash of
the method source, so regardless of the mechanism to merge the
ClassSourceFile, you can work back to the timestamp.

For example...
Morph class>>announcer  {
#sourceHash : '264011013dab93d02fb5c0f0f68eaa64063bc750',
#category : #accessing,
#timestamp : ' 8/31/2017 05:26:11'
}

where...
(SHA1 new hashMessage: '[

^ announcer ifNil: [ announcer := Announcer new ].
]') hex   "  ==> '264011013dab93d02fb5c0f0f68eaa64063bc750'  "


Maybe a lot of holes in the idea, but I thought it worth stimulating a few
neurons out there.
cheers -ben


> btw, Tonel export order is deterministic and it will always output same
> data in same way.
>
> Esteban
>
>
> Best regards,
> Henrik
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>
>

Re: [Pharo-dev] Tricky Metaclass>>binding

[Marcus Denker]

> On 12 Sep 2017, at 11:32, Denis Kudriashov  wrote:
> 
> I found interesting trick in system: the way how class side perform #binding 
> message:
> 
> Metaclass>>binding
>   "return an association that can be used as the binding
>To share it between methods, reuse an existing one if possible"
>   ^self methodDict 
>   ifEmpty: [nil -> self]
>   ifNotEmpty: [:dict | dict anyOne classBinding]
> 
> It leads to interesting behaviour of class without class side methods:
> 
> NewClass class binding == NewClass class binding "==> false"
> 
> Generally I discovered in the logic which decode class of method in last 
> literal. Interesting that for instance side methods it is always represented 
> by GlobalVariable. And for class side methods it is always general 
> Association.
> 
> Can we make this behaviour more consistent? And will it improve the system? 
> (I thing about possible complications to bootstrap).
> 
> As solution I would introduce new kind of LiteralVariable: ClassBinding with 
> two subclasses InstanceSideBinding and ClassSideBinding. They will take place 
> in last method literal.
> InstanceSideBinding will be used in Smalltalk dictionary for classes instead 
> of GlobalVariable. 
> And it will keep variable with class side binding. So the trick will be not 
> needed anymore. 
> 
> So what do you think?

It would be nice to improve it.. I like the idea of a ClassBinding subclass 
(this way it is distinct from Global Vars, too). The only question of adding 
one ivar to ca. 5000 Objects 
is not too much.. do we get enough out of it for that amount of memory?
Maybe there is some other possibility?

Marcus

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Denis Kudriashov]

I am really wonder guys. I thought you are not big funs of Object protocol.
Current pinning messages are a new set of very generic messages in the
Object.

About Norbert idea.
- bePinnedObject is not bad convention. But I would prefer the memory
suffix because it reflects the low level behaviour.

2017-09-11 14:16 GMT+02:00 Esteban Lorenzano :

> yes, me :)
>
> I do not see a reason to change them, tbh.
> for me they are comprensible as they are now and it does not adds more
> information pinInMemory or pinMemory.
>
> Esteban
>
>
> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek :
>
>>
>>
>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
>>
>>> Hi.
>>>
>>> We now have very generic message names:
>>> - pin
>>> - unpin
>>> - setPinned:
>>> - isPinned
>>>
>>> Problem that they collide with possible domain related names.
>>> For example I implemented pinning of tabs in Calypso and I found that I
>>> overrides #pin and #isPinned messages. Then I fix it with different names.
>>> Probably menus also uses pin word but without overrides
>>>
>>> What you think about renaming pinning messages? Something like:
>>> - pinMemory
>>>
>>
>> I would use pinInMemory
>>
>> -- Pavel
>>
>>
>>> - unpinMemory
>>> - isMemoryPinned
>>> - setPinnedMemory:
>>> - pinMemoryDuring: (if we will introduce it)
>>>
>>> I think it is easy to do now because not much code uses pinning
>>>
>>
>>
>
>

[Pharo-dev] Tricky Metaclass>>binding

[Denis Kudriashov]

I found interesting trick in system: the way how class side perform
#binding message:

Metaclass>>binding
"return an association that can be used as the binding
To share it between methods, reuse an existing one if possible"
^self methodDict
ifEmpty: [nil -> self]
ifNotEmpty: [:dict | dict anyOne classBinding]

It leads to interesting behaviour of class without class side methods:

NewClass class binding == NewClass class binding "==> false"


Generally I discovered in the logic which decode class of method in last
literal. Interesting that for instance side methods it is always
represented by GlobalVariable. And for class side methods it is always
general Association.

Can we make this behaviour more consistent? And will it improve the system?
(I thing about possible complications to bootstrap).

As solution I would introduce new kind of LiteralVariable: ClassBinding
with two subclasses InstanceSideBinding and ClassSideBinding. They will
take place in last method literal.
InstanceSideBinding will be used in Smalltalk dictionary for classes
instead of GlobalVariable.
And it will keep variable with class side binding. So the trick will be not
needed anymore.

So what do you think?

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

Two other things:

- if you choose to change the priority of the delivery process to the same
priority as the running test process (i.e., 40) you would still need to
tell the scheduler to give some chance to run to the other one. You can do
that by yielding

 Processor yield

- About timeouts: Denis implemented not so long ago an automatic timeout
for tests. So if tests take more than a specified amount they are timed out
and failed by default. Check

TestCase >> defaultTimeLimit
^self class defaultTimeLimit

TestCase class >> defaultTimeLimit
^DefaultTimeLimit ifNil: [DefaultTimeLimit := 1 minutes]

So you may want to use that mechanism to timeout instead of hardcoding the
timeouts of semaphores in each of the tests.

Moreover, the mechanism created by Denis will automatically kill any
processes created during a test run, to ensure you leave the system somehow
"clean". So you may have that into account also.

On Tue, Sep 12, 2017 at 9:46 AM, Guillermo Polito  wrote:

> But the thing is that those processes you are creating for delivery are
> running in priority 30. This means that it may happen that they may not run
> any time soon (even those 200ms) if there are processes scheduled with
> higher priorities.
>
> So, the thing is that test is not a unit test at all. It depends a lot on
> the running environment. Solutions for that:
>  - you change the priority of the delivery process for test purposes
>  - Or, for testing purposes you don't create a new process, you just
> execute synchronously
>
> If you want really to test the fact that you are creating and running a
> separate process, then you should also try to let explicit the processes
> you created run. This means, if the active process that is running the
> tests (usually priority 40) does not suspend itself, no processes of
> priority 30 will be able to run. Ways to suspend the active process and let
> lower priority ones run are:
>  - calling suspend (Processor activeProcess suspend) but this is dangerous
> because somebody should resume it afterwards from a separate process
>  - using a delay
>  - some I/O like sockets or async files
>
> On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka 
> wrote:
>
>> Hi Guillermo,
>>
>> I have not found better solution. Waiting without a timeout threshold is
>> not nice and makes it difficult to run all tests.
>> If you have better idea how to sync and test two processes, I will
>> appreciate it.
>> Otherwise I will use a higher timeout.
>>
>> Cheers,
>> Juraj
>>
>> El 11-09-2017, a las 06:55, Guillermo Polito 
>> escribió:
>>
>> Hi Juraj,
>>
>> think that it may really depend on the machine and the state of the
>> system. Slower slave machines could not really work with that timeout...
>>
>> The question is how could we make such test more robust.
>>
>> On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka 
>> wrote:
>>
>>> Hi,
>>>
>>> I have checked the EventRecorderTests and it works on my computer. The
>>> only reason that it might not work on other cases is that there an assert
>>> for 'semaphore waitTimeoutMSecs: 200’. I can put higher timeout if
>>> necessary. The timeout 200 has worked for couple of years, right?. There
>>> might be another issue.
>>>
>>> Cheers,
>>> Juraj
>>>
>>> El 10-09-2017, a las 10:13, Guillermo Polito 
>>> escribió:
>>>
>>> Hi all,
>>>
>>> Since a couple of builds we have consistently failing the following
>>> tests:
>>>
>>>
>>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2
>>>
>>> 
>>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv
>>>eredDataShouldBeResent
>>>
>>> 
>>>- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh
>>>ouldUnblockWaitingOne
>>>
>>> 
>>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>>estHashMethodNeedsToBeInComparingProtocol
>>>
>>> 
>>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>>estHashMethodNeedsToBeInComparingProtocol
>>>

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

But the thing is that those processes you are creating for delivery are
running in priority 30. This means that it may happen that they may not run
any time soon (even those 200ms) if there are processes scheduled with
higher priorities.

So, the thing is that test is not a unit test at all. It depends a lot on
the running environment. Solutions for that:
 - you change the priority of the delivery process for test purposes
 - Or, for testing purposes you don't create a new process, you just
execute synchronously

If you want really to test the fact that you are creating and running a
separate process, then you should also try to let explicit the processes
you created run. This means, if the active process that is running the
tests (usually priority 40) does not suspend itself, no processes of
priority 30 will be able to run. Ways to suspend the active process and let
lower priority ones run are:
 - calling suspend (Processor activeProcess suspend) but this is dangerous
because somebody should resume it afterwards from a separate process
 - using a delay
 - some I/O like sockets or async files

On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka 
wrote:

> Hi Guillermo,
>
> I have not found better solution. Waiting without a timeout threshold is
> not nice and makes it difficult to run all tests.
> If you have better idea how to sync and test two processes, I will
> appreciate it.
> Otherwise I will use a higher timeout.
>
> Cheers,
> Juraj
>
> El 11-09-2017, a las 06:55, Guillermo Polito 
> escribió:
>
> Hi Juraj,
>
> think that it may really depend on the machine and the state of the
> system. Slower slave machines could not really work with that timeout...
>
> The question is how could we make such test more robust.
>
> On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka 
> wrote:
>
>> Hi,
>>
>> I have checked the EventRecorderTests and it works on my computer. The
>> only reason that it might not work on other cases is that there an assert
>> for 'semaphore waitTimeoutMSecs: 200’. I can put higher timeout if
>> necessary. The timeout 200 has worked for couple of years, right?. There
>> might be another issue.
>>
>> Cheers,
>> Juraj
>>
>> El 10-09-2017, a las 10:13, Guillermo Polito 
>> escribió:
>>
>> Hi all,
>>
>> Since a couple of builds we have consistently failing the following tests:
>>
>>
>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2
>>
>> 
>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv
>>eredDataShouldBeResent
>>
>> 
>>- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh
>>ouldUnblockWaitingOne
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>>