Grease and Mocking

Recently I changed the way I develop my projects. Before I just had a local installation of gemstone and developed everything on this. Having the same gemstone installation on my remote server it is really easy to deploy stuff. That means there is less that will go wrong.

Now I'm on my way to change the kind of development. I like to develop everything in pharo and deploy it then on gemstone. So I'm starting to face platform incompatibilities. I read an article about grease and understand that it tries to build a common denominator for the core classes in smalltalk. So it tries to be a standard somehow to develop towards.

On the other hand there are things that point in the opposite direction. These are methods that are necessary for one platform but not for another one. One solution to this is to add a dummy implementation to the platform that is missing the method in order to have proper working code. Another option is to add convenience methods to a platform that doesn't have it. This leads to a platform superset.

There is the MockGemstone package that deals with the additions of methods between gemstone and squeak. Until now it was sufficient for me to use. But it seems that squeak and pharo are diverging. I think that the Mocking approach stops being easy if there are more than two participants. Adding pharo would need a Mocking package for every single combination of source and destination platform.  Taking an pragmatic approach this could work but I don't know if it is of much use later on.

Assuming those mocking packages exist, Metacello could solve a bigger problem. When installing a mocking package I just specify the target platform and metacello selects automatically the right source-target combination. I don't know if this is feasible. So a few opinions from your side might shed me some light.

Even if this would work it would only solve the problems partially. I only spoke about additions. But what about conflicting methods. How should these be solved? The split:/join: methods have been added to the MockGemstone (I don't even think they are part of squeak). And they are present in my pharo installation (the dev images have the splitjoin package installed). But they work the opposite way. In squeak you would do

'/a/b/c/' split: '/'

and in pharo you would do

'/' split: '/a/b/c/'

How can I solve this in my present environment?

I wrote this mail because I'm just glueless how to solve that problems and I have the strong opinion I need a more general solution to it not to face that problems on a daily basis which would be very annoying.

Norbert

On Sat, Feb 13, 2010 at 5:58 AM, Norbert Hartl <[hidden email]> wrote:
> Now I'm on my way to change the kind of development. I like to develop everything in pharo and deploy it then on gemstone. So I'm starting to face platform incompatibilities. I read an article about grease and understand that it tries to build a common denominator for the core classes in smalltalk. So it tries to be a standard somehow to develop towards.

A common denominator, yes, but also through additions (it is not only a subset).

> There is the MockGemstone package that deals with the additions of methods between gemstone and squeak. Until now it was sufficient for me to use. But it seems that squeak and pharo are diverging. I think that the Mocking approach stops being easy if there are more than two participants. Adding pharo would need a Mocking package for every single combination of source and destination platform.  Taking an pragmatic approach this could work but I don't know if it is of much use later on.

Dale has said in the past that they are fully intending to do this,
but I agree it has some practical limitations.

> Even if this would work it would only solve the problems partially. I only spoke about additions. But what about conflicting methods. How should these be solved? The split:/join: methods have been added to the MockGemstone (I don't even think they are part of squeak). And they are present in my pharo installation (the dev images have the splitjoin package installed). But they work the opposite way. In squeak you would do
>
> '/a/b/c/' split: '/'
>
> and in pharo you would do
>
> '/' split: '/a/b/c/'
>
> How can I solve this in my present environment?

Speaking on from a Seaside/Grease context, we simply wouldn't use that
method. We would add it to our Slime code critics rules to make sure
we didn't and we would either work around with other standard methods
or add a new method (either in agreement with the other platforms or
possibly prefixed by "grease").

Julian

----- "Norbert Hartl" <[hidden email]> wrote:

| Recently I changed the way I develop my projects. Before I just had a
| local installation of gemstone and developed everything on this.
| Having the same gemstone installation on my remote server it is really
| easy to deploy stuff. That means there is less that will go wrong.
|
| Now I'm on my way to change the kind of development. I like to develop
| everything in pharo and deploy it then on gemstone. So I'm starting to
| face platform incompatibilities. I read an article about grease and
| understand that it tries to build a common denominator for the core
| classes in smalltalk. So it tries to be a standard somehow to develop
| towards.
|
| On the other hand there are things that point in the opposite
| direction. These are methods that are necessary for one platform but
| not for another one. One solution to this is to add a dummy
| implementation to the platform that is missing the method in order to
| have proper working code. Another option is to add convenience methods
| to a platform that doesn't have it. This leads to a platform
| superset.
|
| There is the MockGemstone package that deals with the additions of
| methods between gemstone and squeak. Until now it was sufficient for
| me to use. But it seems that squeak and pharo are diverging. I think
| that the Mocking approach stops being easy if there are more than two
| participants. Adding pharo would need a Mocking package for every
| single combination of source and destination platform.  Taking an
| pragmatic approach this could work but I don't know if it is of much
| use later on.
|
| Assuming those mocking packages exist, Metacello could solve a bigger
| problem. When installing a mocking package I just specify the target
| platform and metacello selects automatically the right source-target
| combination. I don't know if this is feasible. So a few opinions from
| your side might shed me some light.
|
| Even if this would work it would only solve the problems partially. I
| only spoke about additions. But what about conflicting methods. How
| should these be solved? The split:/join: methods have been added to
| the MockGemstone (I don't even think they are part of squeak). And
| they are present in my pharo installation (the dev images have the
| splitjoin package installed). But they work the opposite way. In
| squeak you would do
|
| '/a/b/c/' split: '/'
|
| and in pharo you would do
|
| '/' split: '/a/b/c/'
|
| How can I solve this in my present environment?
|
| I wrote this mail because I'm just glueless how to solve that problems
| and I have the strong opinion I need a more general solution to it not
| to face that problems on a daily basis which would be very annoying.
|
| Norbert

Norbert,

As far as #split: is concerned, I was able to track the method being introduced into GLASS back in 2007 by Otto Behrens:

  OB-GemStone-Platform-OM.18 (09/14/07, 20:30:59)
  - Merged FinWorksTools_g

So #split: started life as an extension from the FinWorks tool.

Then in 2008 I moved the method into the Squeak package (incorrectly):

  Squeak-dkh.95 (02/14/08, 09:41:20)
  - moved CharacterCollection and Symbol extensions from
    OB-GemStone-Platform to Squeak

The #split: method is used in some other methods that ultimately support gemstone-specific implementations of OB methods - it should be very easy to fix that collision problem.

So the short answer is that you've uncovered a very old bug:)

The longer answer is that I expect to be creating 3 packages when the need arises: SqueakCommon (the current Squeak package), Squeak, and Pharo. The Squeak and Pharo packages will contain methods/classes that are unique to each platform.

There is no expectation that there would be a Pharo compatibility layer on top of the Squeak compatibility layer on top of GLASS ... The Pharo and Squeak packages would not be loaded together.

So when you fire up a GLASS instance you will choose whether you want to use the Squeak or Pharo compatibility and load the appropriate package (using Metacello).

In the long run, I would like to have 100% compatibility, but the long run would have to be pretty long for that to happen. In theory, the compatibility layer will be no more difficult to manage than it is for the maintainers of Squeak and Pharo. When it comes to Pharo, the more that they partition things up into packages, the easier it can be maintain the compatibility layer...

From an operational perspective, right now, i don't expect all of the development to go through me. If you have a compelling reason to use a method from Pharo that isn't in the compatibility package, I would expect you to add a test and the method to the Pharo compatibility package so that others could benefit (and they would do the same thing)....

If you are trying to write code that runs on Squeak and Pharo, then for GLASS you can pick either the Squeak or Pharo compatibility mode to run your app.

If you wonder how I think we can pull this off, I just point to the fact that in 3.0 we are running ruby code on top of GemStone Smalltalk, so running another variant of Smalltalk on top of GemStone Smalltalk is not that far-fetched:)

Dale

On 16.02.2010, at 00:51, Dale Henrichs wrote:

Great, that is something I heard a lot of times in the last 10-15 years ;)

> The longer answer is that I expect to be creating 3 packages when the need arises: SqueakCommon (the current Squeak package), Squeak, and Pharo. The Squeak and Pharo packages will contain methods/classes that are unique to each platform.
>

Ok, I just wanted to know what people think should be done. This is fine for me.

> There is no expectation that there would be a Pharo compatibility layer on top of the Squeak compatibility layer on top of GLASS ... The Pharo and Squeak packages would not be loaded together.
>
Good. I think making it the other way round is just asking for trouble.
A pharo compat package would be great. I don't really understand what squeakCommon could be but it sounds good :) For me it is just that I don't want to add things to the squeak package without having to double check every time.

Norbert

Norbert,

I will be submitting a bug on the #split: problem, and I will start moving towards a Pharo/Squeak split structure.

I have just about finished my work on integrating the MetacelloRepository configurations into the GLASS configurations and will start aiming towards addressing the GLASS.230-dkh.231 upgrade issues (finally). So this will be a good time to introduce the split structure as well.

The SqueakCommon idea is that 80% of the methods are common between Squeak and Pharo, so there shouldn't be duplication in separate packages. The pharo and squeak packages would only have to deal with exceptions as they occur.

Dale
----- "Norbert Hartl" <[hidden email]> wrote:

| On 16.02.2010, at 00:51, Dale Henrichs wrote:
|
| >
| > ----- "Norbert Hartl" <[hidden email]> wrote:
| >
| > | Recently I changed the way I develop my projects. Before I just
| had a
| > | local installation of gemstone and developed everything on this.
| > | Having the same gemstone installation on my remote server it is
| really
| > | easy to deploy stuff. That means there is less that will go wrong.
|
| > |
| > | Now I'm on my way to change the kind of development. I like to
| develop
| > | everything in pharo and deploy it then on gemstone. So I'm
| starting to
| > | face platform incompatibilities. I read an article about grease
| and
| > | understand that it tries to build a common denominator for the
| core
| > | classes in smalltalk. So it tries to be a standard somehow to
| develop
| > | towards.
| > |
| > | On the other hand there are things that point in the opposite
| > | direction. These are methods that are necessary for one platform
| but
| > | not for another one. One solution to this is to add a dummy
| > | implementation to the platform that is missing the method in order
| to
| > | have proper working code. Another option is to add convenience
| methods
| > | to a platform that doesn't have it. This leads to a platform
| > | superset.
| > |
| > | There is the MockGemstone package that deals with the additions
| of
| > | methods between gemstone and squeak. Until now it was sufficient
| for
| > | me to use. But it seems that squeak and pharo are diverging. I
| think
| > | that the Mocking approach stops being easy if there are more than
| two
| > | participants. Adding pharo would need a Mocking package for every
| > | single combination of source and destination platform.  Taking an
| > | pragmatic approach this could work but I don't know if it is of
| much
| > | use later on.
| > |
| > | Assuming those mocking packages exist, Metacello could solve a
| bigger
| > | problem. When installing a mocking package I just specify the
| target
| > | platform and metacello selects automatically the right
| source-target
| > | combination. I don't know if this is feasible. So a few opinions
| from
| > | your side might shed me some light.
| > |
| > | Even if this would work it would only solve the problems
| partially. I
| > | only spoke about additions. But what about conflicting methods.
| How
| > | should these be solved? The split:/join: methods have been added
| to
| > | the MockGemstone (I don't even think they are part of squeak).
| And
| > | they are present in my pharo installation (the dev images have
| the
| > | splitjoin package installed). But they work the opposite way. In
| > | squeak you would do
| > |
| > | '/a/b/c/' split: '/'
| > |
| > | and in pharo you would do
| > |
| > | '/' split: '/a/b/c/'
| > |
| > | How can I solve this in my present environment?
| > |
| > | I wrote this mail because I'm just glueless how to solve that
| problems
| > | and I have the strong opinion I need a more general solution to it
| not
| > | to face that problems on a daily basis which would be very
| annoying.
| > |
| > | Norbert
| >
| > Norbert,
| >
| > As far as #split: is concerned, I was able to track the method being
| introduced into GLASS back in 2007 by Otto Behrens:
| >
| >  OB-GemStone-Platform-OM.18 (09/14/07, 20:30:59)
| >  - Merged FinWorksTools_g
| >
| > So #split: started life as an extension from the FinWorks tool.
| >
| > Then in 2008 I moved the method into the Squeak package
| (incorrectly):
| >
| >  Squeak-dkh.95 (02/14/08, 09:41:20)
| >  - moved CharacterCollection and Symbol extensions from
| >    OB-GemStone-Platform to Squeak
| >
| > The #split: method is used in some other methods that ultimately
| support gemstone-specific implementations of OB methods - it should be
| very easy to fix that collision problem.
| >
| > So the short answer is that you've uncovered a very old bug:)
| >
|
| Great, that is something I heard a lot of times in the last 10-15
| years ;)
|
| > The longer answer is that I expect to be creating 3 packages when
| the need arises: SqueakCommon (the current Squeak package), Squeak,
| and Pharo. The Squeak and Pharo packages will contain methods/classes
| that are unique to each platform.
| >
|
| Ok, I just wanted to know what people think should be done. This is
| fine for me.
|
| > There is no expectation that there would be a Pharo compatibility
| layer on top of the Squeak compatibility layer on top of GLASS ... The
| Pharo and Squeak packages would not be loaded together.
| >
| Good. I think making it the other way round is just asking for
| trouble.
|
| > So when you fire up a GLASS instance you will choose whether you
| want to use the Squeak or Pharo compatibility and load the appropriate
| package (using Metacello).
| >
| > In the long run, I would like to have 100% compatibility, but the
| long run would have to be pretty long for that to happen. In theory,
| the compatibility layer will be no more difficult to manage than it is
| for the maintainers of Squeak and Pharo. When it comes to Pharo, the
| more that they partition things up into packages, the easier it can be
| maintain the compatibility layer...
| >
| > From an operational perspective, right now, i don't expect all of
| the development to go through me. If you have a compelling reason to
| use a method from Pharo that isn't in the compatibility package, I
| would expect you to add a test and the method to the Pharo
| compatibility package so that others could benefit (and they would do
| the same thing)....
| >
| > If you are trying to write code that runs on Squeak and Pharo, then
| for GLASS you can pick either the Squeak or Pharo compatibility mode
| to run your app.
| >
| > If you wonder how I think we can pull this off, I just point to the
| fact that in 3.0 we are running ruby code on top of GemStone
| Smalltalk, so running another variant of Smalltalk on top of GemStone
| Smalltalk is not that far-fetched:)
| >
| A pharo compat package would be great. I don't really understand what
| squeakCommon could be but it sounds good :) For me it is just that I
| don't want to add things to the squeak package without having to
| double check every time.
|
| Norbert

On Mon, Feb 15, 2010 at 7:37 PM, Dale Henrichs
<[hidden email]> wrote:
> Norbert,
>
> I will be submitting a bug on the #split: problem, and I will start moving towards a Pharo/Squeak split structure.
>
> I have just about finished my work on integrating the MetacelloRepository configurations into the GLASS configurations and will start aiming towards addressing the GLASS.230-dkh.231 upgrade issues (finally). So this will be a good time to introduce the split structure as well.
>
> The SqueakCommon idea is that 80% of the methods are common between Squeak and Pharo, so there shouldn't be duplication in separate packages. The pharo and squeak packages would only have to deal with exceptions as they occur.
>

I think I just found one of the areas where they diverge.

The version of from the squeak bootstrap, checks for the existence of
the file and errors out if it doesnt exist.
The version now in pharo, creates the file if it doesnt exist and then opens it.

Sean,

What class and message?

Dale

----- "Sean Allen" <[hidden email]> wrote:

| On Mon, Feb 15, 2010 at 7:37 PM, Dale Henrichs
| <[hidden email]> wrote:
| > Norbert,
| >
| > I will be submitting a bug on the #split: problem, and I will start
| moving towards a Pharo/Squeak split structure.
| >
| > I have just about finished my work on integrating the
| MetacelloRepository configurations into the GLASS configurations and
| will start aiming towards addressing the GLASS.230-dkh.231 upgrade
| issues (finally). So this will be a good time to introduce the split
| structure as well.
| >
| > The SqueakCommon idea is that 80% of the methods are common between
| Squeak and Pharo, so there shouldn't be duplication in separate
| packages. The pharo and squeak packages would only have to deal with
| exceptions as they occur.
| >
|
| I think I just found one of the areas where they diverge.
|
| The version of from the squeak bootstrap, checks for the existence of
| the file and errors out if it doesnt exist.
| The version now in pharo, creates the file if it doesnt exist and then
| opens it.

Well, they are in different spots between pharo and gemstone for the
actual points where the behavious veers off... but... in general

fileNamed

| dir file |

dir := FileDirectory on: '/home/glass'.
file := dir fileNamed: 'file'.


On Thu, Feb 18, 2010 at 4:08 PM, Dale Henrichs
<[hidden email]> wrote:

Thanks, Sean.

I've opened http://code.google.com/p/glassdb/issues/detail?id=52 to track this issue.

Dale

----- "Sean Allen" <[hidden email]> wrote:

| Well, they are in different spots between pharo and gemstone for the
| actual points where the behavious veers off... but... in general
|
| fileNamed
|
| | dir file |
|
| dir := FileDirectory on: '/home/glass'.
| file := dir fileNamed: 'file'.
|
|
| On Thu, Feb 18, 2010 at 4:08 PM, Dale Henrichs
| <[hidden email]> wrote:
| > Sean,
| >
| > What class and message?
| >
| > Dale
| >
| > ----- "Sean Allen" <[hidden email]> wrote:
| >
| > | On Mon, Feb 15, 2010 at 7:37 PM, Dale Henrichs
| > | <[hidden email]> wrote:
| > | > Norbert,
| > | >
| > | > I will be submitting a bug on the #split: problem, and I will
| start
| > | moving towards a Pharo/Squeak split structure.
| > | >
| > | > I have just about finished my work on integrating the
| > | MetacelloRepository configurations into the GLASS configurations
| and
| > | will start aiming towards addressing the GLASS.230-dkh.231
| upgrade
| > | issues (finally). So this will be a good time to introduce the
| split
| > | structure as well.
| > | >
| > | > The SqueakCommon idea is that 80% of the methods are common
| between
| > | Squeak and Pharo, so there shouldn't be duplication in separate
| > | packages. The pharo and squeak packages would only have to deal
| with
| > | exceptions as they occur.
| > | >
| > |
| > | I think I just found one of the areas where they diverge.
| > |
| > | The version of from the squeak bootstrap, checks for the existence
| of
| > | the file and errors out if it doesnt exist.
| > | The version now in pharo, creates the file if it doesnt exist and
| then
| > | opens it.
| >

just submitted this one as well:

http://code.google.com/p/glassdb/issues/detail?id=53&colspec=ID%20Type%20Status%20Priority%20GLASS%20Version%20Owner%20Summary%20bugid


On Thu, Feb 18, 2010 at 4:15 PM, Dale Henrichs
<[hidden email]> wrote: