Is become: still Platform dependently one or two way?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Is become: still Platform dependently one or two way?

jtuchel
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/6683db22-d959-43a6-ac6b-1093d1e4806d%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Seth Berman
Hi Joachim,

@see this discussion also: https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f77cef87-324c-4d59-85e9-fc1d0a64f76f%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

jtuchel
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;">https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/52e8c352-85a5-4730-9bd2-358b7b38a91c%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Seth Berman
Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;">https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/165a29e5-5ef4-4482-8810-8fef0294b899%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

jtuchel
Oh, maybe I should have mentioned I was checking on 9.1, so if you worked on this method's comment in 9.2x, this is probably obsolete...




Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:
Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;">https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5ac37f6f-6ff6-49da-ad12-7dd186f42bb9%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Seth Berman
Hi Joachim,

No, its unsurprisingly the same. 
I would love to say the team has the time to validate the correctness of old 1996 comments in a codebase our size...but that just wouldn't be true:)
However, we are happy to clarify for folks that request it.

- Seth

On Thursday, April 2, 2020 at 8:10:59 AM UTC-4, Joachim Tuchel wrote:
Oh, maybe I should have mentioned I was checking on 9.1, so if you worked on this method's comment in 9.2x, this is probably obsolete...




Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:
Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;">https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4ac0257-0c46-4973-bed3-7aa19ba04b7f%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Hans-Martin Mosner-3
In reply to this post by jtuchel
Am Donnerstag, 2. April 2020 12:56:50 UTC+2 schrieb Joachim Tuchel:
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

If you create the real objects just before you do the #become: and don't reference them later there should be no difference.
Variables which previously held the proxies will point to the real objects now in any implementation.
In a one-way become implementation, the variable in which the newly created object was held will still hold it, while in a two-way become implementation it will point to the proxy now. If you forget this variable, there is no difference anymore.
One think that still might be different is the treatment of object hash - in a two-way become system, the objects exchange their hashes, too. This is not possible in a one-way become.

As Seth already pointed out, VA is going to stay with the one-way become, so you should not expect issues. However, if you want to write portable code that works with a two-way become, you should definitely not use "become: nil" as it will break your image.

Cheers,
Hans-Martin

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1d6c51e9-9173-4335-ab8b-e1a7616fd8d7%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Douglas Swartz
In reply to this post by Seth Berman
Historical content:  I worked with VA Smalltalk as early as version three. At that time, VA used one way become on Windows and Unix.  I suppose it's possible the MVS mainframe version used two way.  

I suspect the comment dates back to Envy/Smalltalk and OTI where they were delivering Smalltalk versions for various platforms. 

On Thu, Apr 2, 2020, 7:14 AM 'Seth Berman' via VA Smalltalk <[hidden email]> wrote:
Hi Joachim,

No, its unsurprisingly the same. 
I would love to say the team has the time to validate the correctness of old 1996 comments in a codebase our size...but that just wouldn't be true:)
However, we are happy to clarify for folks that request it.

- Seth

On Thursday, April 2, 2020 at 8:10:59 AM UTC-4, Joachim Tuchel wrote:
Oh, maybe I should have mentioned I was checking on 9.1, so if you worked on this method's comment in 9.2x, this is probably obsolete...




Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:
Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,


We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4ac0257-0c46-4973-bed3-7aa19ba04b7f%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAF3kYMXG0iymZBHNxiPkHXB-jVVzyQYfnk10B77tAQZGBGABbA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Is become: still Platform dependently one or two way?

Richard Sargent
Administrator
In reply to this post by Seth Berman
On Thursday, April 2, 2020 at 4:56:34 AM UTC-7, Seth Berman wrote:
Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

Given my other recent post, consider factoring out the current implementation into a #oneWayBecome: method and using it explicitly. That would make it easier for people to use the two-way become when they want to and to explicitly distinguish when they need a one-way become, and yet have the eternal default implementation.

Well named code is always better than comments for explain what is being done. Let the comments explain the why.


- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.
This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim



Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ&#39;;return true;">https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.
I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"
That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.
 
Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?
We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2a28f858-735b-4bcf-94ea-33752900832e%40googlegroups.com.