[squeak-dev] Bug in object finalization?

I didn't get much response to the last mail concerning
ObjectFinalizer.

In short, Object>>finalizationRegistry is a WeakRegistry
which itself utilizes a WeakKeyDictionary. Not using
a WeakIdentityKeyDictionary prevents the finalization of
equal objects.

There was a test in 3.9 testing this (it failed). In 3.10
the test got removed but I think it is a bug.

What do you think?

Norbert

Norbert Hartl <norbert <at> hartl.name> writes:
Wasn't 3.10 team policy to remove known bugs/failure tests from image?

> What do you think?

Maybe see also

http://bugs.squeak.org/view.php?id=6347

>
> Norbert
>

Norbert Hartl wrote:
> There was a test in 3.9 testing this (it failed). In 3.10
> the test got removed but I think it is a bug.
>
> What do you think?

The test itself is buggy (see http://bugs.squeak.org/view.php?id=6347)
but once you fix the test it illustrates a problem in WeakRegistry which
needs to use a WeakIdentityKeyDictionary instead of a WeakKeyDictionary.

Cheers,
   - Andreas

On Wed, 2008-06-18 at 09:22 -0700, Andreas Raab wrote:

On Wed, 2008-06-18 at 09:22 -0700, Andreas Raab wrote: Ok, what I said. Do you see an harmful side effects by exchanging
the dictionary?

Norbert

Norbert Hartl wrote:
No - we've fixed this a long time ago in our code base.

Cheers,
   - Andreas

Andreas Raab wrote:
Thanks for not sharing

Dilbert Dogbert a écrit :
> Andreas Raab wrote:
>> No - we've fixed this a long time ago in our code base.
>
> Thanks for not sharing
>

Can't speak for Andreas, but would i be asked so kindly that i'm not
sure i would be more inclined to share.

Let's be more positive!
Thanks for taking time to share in squeak-dev finally.

Nicolas

nicolas cellier wrote:
> Dilbert Dogbert a écrit :
>> Andreas Raab wrote:
>>> No - we've fixed this a long time ago in our code base.
>>
>> Thanks for not sharing
>>
>
> Can't speak for Andreas, but would i be asked so kindly that i'm not
> sure i would be more inclined to share.

Oh don't worry I'm pretty thick-skinned. The only disappointing part is
that the above poster (who happens to be a well-renowned member of the
Squeak community btw) thinks that I wouldn't instantly recognize his
style. I mean "Dilbert Dogbert"? Come on, you might have just as well
signed with your real name ;-)

> Let's be more positive!
> Thanks for taking time to share in squeak-dev finally.

You're welcome. Interestingly, the exchange that sparked this fix
included both Tim and John. Seems like they didn't consider this to be
uber-critical either.

Cheers,
   - Andreas

On Wed, Jun 18, 2008 at 2:44 PM, Andreas Raab <[hidden email]> wrote:
> nicolas cellier wrote:
>>
>> Dilbert Dogbert a écrit :
> "Dilbert Dogbert"? Come on, you might have just as well signed with your
> real name ;-)

Well, if I had tried to be that obvious, I would have used my real name ;-)

Michael

Well the *real* issue here is that VM level fixes just aren't properly  
tracked and place in the VM or NOT placed in the VM. The process I'm  
afraid just relies on too many
folks remembering to check the bugs, acting on email flows to the vm-
dev list or squeak list.

What I would propose is say a monthly or even quarterly meeting/
mailing? to co-ordinate the process to a better degree to ensure yes  
or no this fix is going into the VM.

On Jun 18, 2008, at 2:44 PM, Andreas Raab wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

But, while we are on it:
what could we do to make it easier -meaning not imposing even more
stress/work on top of release stress etc- for the different "forks"
(Croquet, Sophie, Pharo, Seaside, etc) to make fixes
available/accessible?
The semaphore fixes back then got me thinking about this, but I'm
still not sure what a solution would be.
Basically one would need to be able to easily see changes across a
variety of repository and image versions. A central source database
maybe?

Michael

Michael Rueger wrote:
> But, while we are on it:
> what could we do to make it easier -meaning not imposing even more
> stress/work on top of release stress etc- for the different "forks"
> (Croquet, Sophie, Pharo, Seaside, etc) to make fixes
> available/accessible?
> The semaphore fixes back then got me thinking about this, but I'm
> still not sure what a solution would be.
>  
There are several ideas in the pipeline and several options therein.

1. DeltaStreams - A better change-set that is revertable and knows more
of the context of the fixes. It can conditionally apply fixes if the
code it is changing is as expected.

2. Installer mantis fixBug: 1234.

Installer can install individual fixes as defined by a small script on
mantis. So if you are preparing an image that needs something particular
then this is very useful.

3. Installer/LevelPlayingField - has slots for loading fixes into older
images.

The main aim of this is to free up Monticello from having to be
backwards and forwards compatible with every possible image version.
LevelPlayingField takes responsibility for the differences between
squeaks/forks and  possibly even spoons.

4a.  Installer install: 'MinorFixes'.

A published list of MinorFixes on http://installer.pbwiki.com/MinorFixes 
can have a different list for each squeak/fork version. (Better
implementation is Sake/Tasks - see below)

4b.  Installer install: 'YourPackage' - As above but under a different
name.  If you place your own custom installer script on
installer.pbwiki.com then you can publish a different version of that
script for each squeak/fork version. These different scripts can install
fixes where needed. e.g. We could have a script - Installer install:
'FixesForServers'.
(Better implementation is Sake/Packages - see below)

5. Sake/Packages.

Sake/Packages is an alternative to Universes, there are package
definitions for each version of squeak. These package definitions can
also call up fixes from mantis if required. You can load all of the
package definitions for all squeak versions into your image. ( Installer
install: 'PackagesAllVersions' ) This allows you to do what you suggest:

> Basically one would need to be able to easily see changes across a
> variety of repository and image versions. A central source database
> maybe?
>
> Michael
6. Sake/Tasks.

A published set of tasks for each version of squeak. A task can have
prerequisites and conditions, and can also apply fixes and document the
fixes that are/have been applied.

7. Source Code Database

Currently in development, was tabled for inclusion in 3.10

8. Spoon's Source Management

Another uber-database

between these options we should be able to manage something

Keith

2008/6/19, Michael Rueger <[hidden email]>:
> But, while we are on it:
>  what could we do to make it easier -meaning not imposing even more
>  stress/work on top of release stress etc- for the different "forks"
>  (Croquet, Sophie, Pharo, Seaside, etc)

Seaside is _not_ a fork. We only touch stuff that lies outside Seaside
with class extensions, no overrides. We do not even fix http servers.
Even if reported bugs and our patches are ignored for years. Seaside
is just your average Smalltalk project.

Cheers
Philippe

On Wed, 2008-06-18 at 16:23 -0700, Michael Rueger wrote:
> But, while we are on it:
> what could we do to make it easier -meaning not imposing even more
> stress/work on top of release stress etc- for the different "forks"
> (Croquet, Sophie, Pharo, Seaside, etc) to make fixes
> available/accessible?

> The semaphore fixes back then got me thinking about this, but I'm
> still not sure what a solution would be.
> Basically one would need to be able to easily see changes across a
> variety of repository and image versions. A central source database
> maybe?

I would see it the other way round. The forks forked as there wasn't
a way to do it centralized. Every measure that takes this approach
is IMHO suspect to fail :) What id needed at least is that every release
team has a public changelog and source repository. This way a release
team of one fork could easily see what others have done and incorporate
it in the own fork.

I could image some sort of centralized notification about accepted
fixes. This could be a wiki page with a table where each release
team enters the accepted fixes as a row and the forks are the
columns

             squeak     croquet    pharo
fixThat.2      +          X
fixThis.1      X          +          -

So fixThis.1 is a patch from squeak (X). the croquet team accepted
and incorporated the change (+) and the pharo (you rebels!!) declined
it (-). fixThat.2 is a fix from croquet that squeak accepted and pharo
didn't do anything until now.

This may sound like a cheesy solution but it is easy to do and it
doesn't depend on a common external system or common source code loaded
as prerequisite

Norbert

Norbert Hartl wrote:

> I would see it the other way round. The forks forked as there wasn't
> a way to do it centralized. Every measure that takes this approach
> is IMHO suspect to fail :) What id needed at least is that every release

Oh, I meant it the other way round.

> I could image some sort of centralized notification about accepted
> fixes. This could be a wiki page with a table where each release
> team enters the accepted fixes as a row and the forks are the
> columns


That is close to what I was thinking about. Basically a server that
would pull in all sources from all available sources/repositories, so
you could look at e.g. class Semaphore and see who did which changes to
the class. Right now you have to basically go through all repositories,
see where they might have touched Semaphore. Which is almost impossible,
taking into account overrides and class extensions (that's why I
mentioned Seaside, even if it isn't a fork in that sense, I agree).

Michael

On Thu, 2008-06-19 at 08:37 -0700, Michael Rueger wrote: That would be a good project. I was just proposing a solution that
is doable immediately without having the conclusion that "tools are
missing!" :)

Where is this historical reopsitory of all old versions?

Norbert