headers
stéphane ducasse | 1 Jun 2006 13:06
Picon
Picon
Favicon

[ANN] SummerTalk 2006

Please distribute widely

ESUG is proud to announce the Summertalk 2006

	http://www.esug.org/promotionactions/summertalk2006/

Stef and Serge Stinckwich (on the behalf of ESUG)

Here is a description

This program is here to help students work on open-source Smalltalk  
projects. The European Smalltalk User Group (http://www.esug.org/)  
will fund 5 students during the summer.

Each of student supporting organization or student will receive 1500  
euros. Each student will work under the guidance of a mentor  
accredited by ESUG. The money will be distributed in 3 steps: start,  
middle and end of the project.

The selection process done by ESUG will take into account whether the  
student will be supervised, if there is an infrastructure to help him  
as well as a the relevance of the topic for the community and the  
trust in the mentor.

The code developed during this program has to be released under the  
MIT Licence.

When and Process

Running from from June 15th, 2006 through September 15th, 2005.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roel Wuyts | 1 Jun 2006 15:03
Picon
Picon
Favicon

identityHash and become: question

Hello,

I have a question regarding identityHash and become. Consider the  
following piece of code:

| assoc1 assoc2 assoc1Hash assoc2Hash |
assoc1 := Core.Association key: 1 value: 3.
assoc1Hash := assoc1 identityHash.
assoc2 := Core.Association key: 4 value: 7.
assoc2Hash := assoc2 identityHash.
assoc2 become: assoc1.
assoc2 identityHash = assoc2Hash	

Is it guaranteed that the last line always is true ?

This strikes me as bizarre. but in the comment of identityHash both  
could be possible. On the one hand it says that "for objects that are  
not == the hash values might or might not be the same" (which sounds  
reasonable to me). On the other hand, it says "The identityHash value  
does not change across the life of the object". I'm lost at what  
happens in the end. Any suggestions ?

--
Roel
Permalink | Reply | 12 comments |
headers
Reinout Heeck | 1 Jun 2006 16:01
Picon
Favicon

Re: identityHash and become: question

Roel Wuyts wrote:
> Hello,
> 
> I have a question regarding identityHash and become. Consider the 
> following piece of code:
> 
> | assoc1 assoc2 assoc1Hash assoc2Hash |
> assoc1 := Core.Association key: 1 value: 3.
> assoc1Hash := assoc1 identityHash.
> assoc2 := Core.Association key: 4 value: 7.
> assoc2Hash := assoc2 identityHash.
> assoc2 become: assoc1.
> assoc2 identityHash = assoc2Hash   
> 
> 
> Is it guaranteed that the last line always is true ?
> 
> This strikes me as bizarre.

Me too, this seems like a bug to me.
Become is implemented by swapping the pointers to the object bodies in 
the corresponding object table entries.

If identityHash is cached in the OT (I don't know if this is true) then 
these hash entries should be swapped too IMO.

R
-

> but in the comment of identityHash both
(Continue reading)

Permalink | Reply | 9 comments |
headers
Terry Raymond | 1 Jun 2006 16:35

RE: identityHash and become: question

At first glance your thinking appears correct. However,
suppose you are using the identity hash as a uuid for
an object and you do a become. The uuid should now be
the same as the new object, not the old because you are
using the uuid as an integer reference. This is precisely
what your example code does.

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      traymond <at> craftedsmalltalk.com
<http://www.craftedsmalltalk.com>
===========================================================
> -----Original Message-----
> From: Roel Wuyts [mailto:Roel.Wuyts <at> ulb.ac.be]
> Sent: Thursday, June 01, 2006 9:03 AM
> To: vw-nc
> Subject: identityHash and become: question
> 
> Hello,
> 
> I have a question regarding identityHash and become. Consider the
> following piece of code:
> 
> | assoc1 assoc2 assoc1Hash assoc2Hash |
> assoc1 := Core.Association key: 1 value: 3.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin McClure | 1 Jun 2006 18:50
Favicon

Re: identityHash and become: question

Roel Wuyts wrote:
> Hello,
> 
> I have a question regarding identityHash and become. Consider the 
> following piece of code:
> 
> | assoc1 assoc2 assoc1Hash assoc2Hash |
> assoc1 := Core.Association key: 1 value: 3.
> assoc1Hash := assoc1 identityHash.
> assoc2 := Core.Association key: 4 value: 7.
> assoc2Hash := assoc2 identityHash.
> assoc2 become: assoc1.
> assoc2 identityHash = assoc2Hash   
> 
> 
> Is it guaranteed that the last line always is true ?

I believe so.

> 
> This strikes me as bizarre. 

#become: *is* bizarre. It actually changes the identity of objects, 
which is non-intuitive at best.

That said, I think this is the correct behavior. #identityHash should 
depend on the object's identity, not its class or state. An object's 
state can be changed by instance variable assignment, its class can be 
changed by #adoptInstance:, but only #become: changes its identity.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vassili Bykov | 1 Jun 2006 19:05
Favicon

Re: identityHash and become: question

> If identityHash is cached in the OT (I don't know if this is true) then 
> these hash entries should be swapped too IMO.

It is true, identityHash is a 14 bit value stored in the object header 
(a more appropriate term than an object table entry). As Terry already 
pointed out, the values should not be swapped, or at least this is not a 
cut-and-dry proposition. Basically, it's a question of what object 
identity really is. Is identity something inherent in the object, or is 
it in the relationship between the rest of the world and this object?

Historically, Smalltalk "always" subscribed to the latter viewpoint. 
#identityHash is a replacement of #asOop. asOop was a selector in ST-80 
understood by any object and returning its index in the OT. (The inverse 
operation was called #asObject, a method of integers). #asOop was used 
as hash function by IdentitySet and IdentityDictionary. When object 
table as an array of objects was eliminated and the concept of an oop as 
a table index disappeared, #identityHash was introduced to keep identity 
hashed collections working. Obviously, the behavior of #identityHash 
with respect to #become: repeats the original behavior of #asOop--and 
both imply that identity is in the references, not in the object. 
Becomes swaps identities, not just switches references.

--

-- 
Vassili Bykov <vbykov <at> cincom.com>

[:s | s, s printString] value: '[s: | s, s printString] value: '
Permalink | Reply | 8 comments |
headers
Reinout Heeck | 1 Jun 2006 22:18
Favicon

Re: identityHash and become: question

Given the asOop history this all makes sense, however since  we now  
have a random number as the 'oop' the whole thing makes less sense.  
Terry still uses the identityHash as an oop (eg in the  
ProcessMonitor) but given that this oop is only 14 random bits there  
is a lot of potential for clashes.

I wasn't introduced to Smalltalk during this asOop timeframe so as a  
relative newbie seeing the selector name xxxHash I'd expect it to  
behave along the lines of #hash, ie connected to the object, not to  
the references.
Moreover I find the concept of 'swapping references' a very easy one  
to reason about and as you observed the current identityHash behavior  
runs counter to that way of reasoning.

I would have been helped a lot if the comment of identityHash  
explained this history of using asOop as a reference rather than  
seeing identityHash as an aspect of the object. 	(Or as Roel noted  
the current comment is broken in the light op #become:)

Would changing it's behavior to the expected one (by Roel and me at  
least ;-) break any code?
It would be one of those enhancements towards 'regularizing' the VW  
base image and making it easier to grok for newcomers. IOW are there  
still significant abuses of identityHash as an oop or would it 'just  
work'?  (Assuming #become: is never used on a Process the  
ProcessMonitor wouldn't break ;-)

Can people here tell me the behavior of identityHash across becomes  
in other dialects please, I'm curious now...
(Continue reading)

Permalink | Reply | 7 comments |
headers
Terry Raymond | 1 Jun 2006 23:35

RE: identityHash and become: question

Reinout

If you consider that the identity hash is used as the
index into the IdentityDictionary it has to work as it
is currently implemented. Otherwise, if you become the key
then when you do the next lookup you will get the old
object instead of the swapped object.

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      traymond <at> craftedsmalltalk.com
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Reinout Heeck [mailto:reinz <at> desk.org]
> Sent: Thursday, June 01, 2006 4:19 PM
> To: vw-nc
> Subject: Re: identityHash and become: question
> 
> Given the asOop history this all makes sense, however since  we now
> have a random number as the 'oop' the whole thing makes less sense.
> Terry still uses the identityHash as an oop (eg in the
> ProcessMonitor) but given that this oop is only 14 random bits there
> is a lot of potential for clashes.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michel Tilman | 1 Jun 2006 23:56
Picon
Favicon

Re: identityHash and become: question

Now you can create identity sets with multiple equal (==) elements,  
which is also weird:

| p1 p2 set |

p1 := 0 <at> 0.
p2 := 1 <at> 1.
set := IdentitySet new.
set add: p1; add: p2.
p2 oneWayBecome: p1.
set => IdentitySet (0 <at> 0 0 <at> 0) with two == elements

michel

On 01 Jun 2006, at 23:35, Terry Raymond wrote:

> Reinout
>
> If you consider that the identity hash is used as the
> index into the IdentityDictionary it has to work as it
> is currently implemented. Otherwise, if you become the key
> then when you do the next lookup you will get the old
> object instead of the swapped object.
>
> Terry
>
> ===========================================================
> Terry Raymond       Smalltalk Professional Debug Package
> Crafted Smalltalk
> 80 Lazywood Ln.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vassili Bykov | 2 Jun 2006 00:30
Favicon

Re: identityHash and become: question

Reinout Heeck wrote:
> Would changing it's behavior to the expected one (by Roel and me at 
> least ;-) break any code?
 >
> It would be one of those enhancements towards 'regularizing' the VW base 
> image and making it easier to grok for newcomers. IOW are there still 
> significant abuses of identityHash as an oop or would it 'just work'?  

The problem here is not with abuses of #identityHash as #anOop, it's 
with using it for the intended purpose. If #become: swaps identity 
hashes, then after

	anIdSet add: foo.
	foo become: bar.

the following will be true as expected:

	anIdSet anySatisfy: [:any | any == foo]

but this:

	anIdSet includes: foo

will be false with probability very close to 1, unless #become: also 
takes care to find each identity-hashed collection the receiver or the 
argument are elements/keys of and rehash it.

The thing here is that current behavior of identityHash has deeper 
justification than only compatibility with asOop. In Smalltalk, we 
always work with objects through references and never directly, so
(Continue reading)

Permalink | Reply | 1 comment |

Gmane