Le 02/09/2013 12:02, Stéphane Ducasse a écrit :

ok I read the big thread and what would be a solution?

Updating OSProcess? It's just that the code which does the platform selection is already quite interesting due to platform differences, and I'm not sure how I should update it for Pharo3. Suggestions? OSProcess class>>osVersion osVersion "After Squeak version 3.6, #osVersion was moved to SmalltalkImage. Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages." "self osVersion" ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #osVersion]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) osVersion Thierry

On Sep 2, 2013, at 11:20 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Hi,

sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess?

I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess.

Thanks,

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 Stef On Sep 2, 2013, at 2:21 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Stef,

a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ?

If I write something like

(Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ].

Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk?

Thanks,

Thierry

Le 02/09/2013 12:02, Stéphane Ducasse a écrit :

...

ok I read the big thread and what would be a solution?

On Sep 2, 2013, at 11:20 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Hi,

sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess?

I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess.

Thanks,

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On 2 September 2013 16:41, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Le 02/09/2013 16:07, Stéphane Ducasse a écrit :

what we could do is to not deprecate now the methods?

...

Then we can deprecate them when we release 3.0

When starting pharo4? That would be perfect :)

I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no?

(or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name])

When was Smalltalk>>os introduced ?

i don't remember.. but it been a while ago.

Smalltalk os name => 'Mac OS' Smalltalk os version => '1083'

Thierry

Stef

...

On Sep 2, 2013, at 2:21 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Stef,

...

a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ?

If I write something like

(Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ].

Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk?

Thanks,

Thierry

Le 02/09/2013 12:02, Stéphane Ducasse a écrit :

...

ok I read the big thread and what would be a solution?

On Sep 2, 2013, at 11:20 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Hi,

...

sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess?

I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess.

Thanks,

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Best regards, Igor Stasenko.

Le 03/09/2013 10:28, Henrik Johansen a écrit :

On Sep 2, 2013, at 4:41 , Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Le 02/09/2013 16:07, Stéphane Ducasse a écrit :

...

what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0

When starting pharo4? That would be perfect :)

I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no?

(or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name])

When was Smalltalk>>os introduced ?

Thierry

3.5 years ago ;) http://forum.world.st/Worth-reading-discussion-on-Smalltalk-vs-SmalltalkImag... It's been included since Pharo 1.1/Squeak 4.1, so it's a reasonable default path.

Though, better use Smalltalk os platformName (which should work in all versions since the above mentioned), writing a test for whether #name is the "correct" method to use ala 3.0 would be an interesting exercise since it's also implemented for older returns of Smalltalk os, but with a different meaning. *cough* find a better selector for 3.0? *cough* I think OSPlatform is one of those packages which tries to work on Squeak 3.6 and up, and in that case you still need more fallbacks.

Cheers, Henry

Thanks Henry for the info. However, I'm sure platformName (and platformSubtype) will be deprecated in Pharo sooner or later... leaving us with another deprecation. At least the deprecation warning seems to be pointing to that. At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 03/09/2013 12:56, David T. Lewis a écrit :

On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote:

...

At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did).

My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then?

I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests?

...

Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else.

Is there a standard way to test for implementation/version on all Squeak and Pharo versions ?

No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :)

I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry

Dave

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 03/09/2013 13:36, David T. Lewis a écrit :

On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote:

...

Le 03/09/2013 12:56, David T. Lewis a ?crit :

...

On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote:

...

At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did).

My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then?

I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image.

Can I give up on trying to run OSProcess tests?

The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog.

If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure).

Ok.

Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak.

Thanks. Thierry

Dave

...

...

...

Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else.

Is there a standard way to test for implementation/version on all Squeak and Pharo versions ?

No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :)

I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository?

Thierry

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example): in OSProcess class isPharo3AndLater "Test if we are on Pharo 3.0" ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ] platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use." "self platformName" self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName

Thanks! Dave

...

...

Dave

-- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... :) Thierry Le 03/09/2013 14:22, Camillo Bruni a écrit :

bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository.

I think all-in-one solutions only result in bad code..

On 2013-09-03, at 08:48, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Le 03/09/2013 13:36, David T. Lewis a écrit :

...

On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote:

...

Le 03/09/2013 12:56, David T. Lewis a ?crit :

...

On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote:

...

At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did).

My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then?

I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image.

Can I give up on trying to run OSProcess tests?

The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog.

If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure).

Ok.

...

Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak.

Thanks.

Thierry

...

Dave

...

...

...

Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else.

Is there a standard way to test for implementation/version on all Squeak and Pharo versions ?

No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :)

I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository?

Thierry

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example):

in OSProcess class

isPharo3AndLater "Test if we are on Pharo 3.0"

^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ]

platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use."

"self platformName"

self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName

...

Thanks! Dave

...

...

Dave

-- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 03/09/2013 21:04, Camillo Bruni a écrit :

On 2013-09-03, at 09:36, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5...

exactly, and for each Pharo version there is a different branch of OSProcess.

Sometimes, you just have to go with how the software you are using and updating is handling this adaptation... If it's something by you, I won't hesitate to branch and fork :)

well, once you start working on git you see the advantages of branches ;) too bad that the monticello tools do not properly support this feature.

Yes, I was thinking of how to use git branches for gitfiletree:// repositories and couldn't find a right way to integrate it into Monticello, apart from displaying the current branch when browsing a git repository. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote:

Le 03/09/2013 13:36, David T. Lewis a ?crit :

...

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example):

in OSProcess class

isPharo3AndLater "Test if we are on Pharo 3.0"

^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ]

The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major >= 3 ]]]. ^false Dave

platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use."

"self platformName"

self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName

...

Thanks! Dave

...

...

Dave

-- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

-- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 04/09/2013 08:38, Marcus Denker a écrit :

On Sep 4, 2013, at 4:52 AM, "David T. Lewis" <lewis@mail.msen.com> wrote:

...

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote:

...

Le 03/09/2013 13:36, David T. Lewis a ?crit :

...

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example):

in OSProcess class

isPharo3AndLater "Test if we are on Pharo 3.0"

^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ]

The idea is right, but the details can be a PITA ;-)

- In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime.

- There are no implementors of #major in Squeak (but this can be rewritten using #perform:).

- In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments.

Why do you need to support Squeak 3.8? This is how many years old?

I really do not understand this idea to be compatible to all old versions ever.

I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works.

In the end it will just make sure that no progress is possible at all.

I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 04/09/2013 09:40, Marcus Denker a écrit :

...

...

...

Why do you need to support Squeak 3.8? This is how many years old?

I really do not understand this idea to be compatible to all old versions ever.

I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works.

...

In the end it will just make sure that no progress is possible at all.

I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well.

Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize).

Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3?

But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed.

I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions.

In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly?

I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Le 04/09/2013 10:06, Marcus Denker a écrit :

On Sep 4, 2013, at 10:00 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Le 04/09/2013 09:40, Marcus Denker a écrit :

...

...

...

...

Why do you need to support Squeak 3.8? This is how many years old?

I really do not understand this idea to be compatible to all old versions ever.

I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works.

...

In the end it will just make sure that no progress is possible at all.

I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well.

Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize).

Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3?

No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do what we did in Pharo3 in Pharo2, then these Problems are in Pharo2.

...

...

But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed.

...

In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly?

I can undestand that.

I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it.

But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0.

What is a solution other than stopping development and declaring Pharo as finished as it is?

No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni]. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

I don't understand where the tragedy is.. you want your production code to work in Pharo 2.0? Write it to work well in 2.0, don't care about 3.0 or any other future possible changes. Want your code to work on bleeding-edge 3.0 image? Refactor/do the changes to make it work.. leave 2.0 behind. You want both? So, keep 2 separate versions for each version of system. You just have to accept that there is no code which will magically stay compatible with all old and all possible future versions without any changes. On 4 September 2013 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:

On Sep 4, 2013, at 10:18 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

...

...

...

But it is clear that this is a fine line: one persons fix is the

others persons bug, so we tend to be conservative.

...

...

But nevertheless, all show-stopping bugs should be fixed.

...

In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly?

I can undestand that.

I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it.

But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0.

What is a solution other than stopping development and declaring Pharo as finished as it is?

No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff.

Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only "solution" is to stop doing, then the pain stops but there will be no future.

e.g. imagine we would say: "Yes, you convinced us to stop. Pharo is finished". Then someone else would develop "SuperSmalltalk" which is more or less what Pharo 6 would have been, and it's even released around that time.

What will the reactions of the Pharo users be?

-> "I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago!"

?

...

And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users.

For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do:

Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix.

...

You have 2.0 users who have things to say and who are able to correct

things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni].

...

Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it?

Marcus

-- Best regards, Igor Stasenko.

Le 04/09/2013 11:27, Marcus Denker a écrit :

On Sep 4, 2013, at 10:18 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

...

...

...

But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed.

...

In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly?

I can undestand that.

I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it.

But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0.

What is a solution other than stopping development and declaring Pharo as finished as it is?

No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff.

Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only "solution" is to stop doing, then the pain stops but there will be no future.

You're arguing the extreme there :) Forced march to 3.0 seems difficult and counter productive to me, that's all.

e.g. imagine we would say: "Yes, you convinced us to stop. Pharo is finished". Then someone else would develop "SuperSmalltalk" which is more or less what Pharo 6 would have been, and it's even released around that time.

What will the reactions of the Pharo users be?

-> "I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago!"

?

I'm sure you are good enough to convince people to switch to 3.0 even if 2.0 has no bugs. And there will still be new things for 4.0, 5.0, 6.0, ... Many things in store for 3.0 are very interesting and motivating; it's just that, given the state of things, I have to wait and get 2.0 fixed as well as possible. And get ready to transition to 3.0 as smoothly as possible (and repeat for the next version)...

...

And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users.

For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do:

Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix.

...

You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni].

Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it?

That's the point :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

...

...

Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize).

Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3?

No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact.

...

But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed.

I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions.

I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions.

This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0.

...

In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly?

I can undestand that.

I'm not sure :) Because I regularly figure out that **I** do NOT understand how exactly it is difficult and demanding energy to produce something good.

I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it.

But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get touched by these bugs.

1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0.

this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and the story will never ends. Stef

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On Sep 6, 2013, at 9:33 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Le 05/09/2013 22:04, Stéphane Ducasse a écrit :

...

...

...

...

Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize).

Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3?

No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact.

As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works (who did it, already? Sean? Sven?).

no, we don't bah, we have 2S, which would be the "2.5" if you want. Also Sean made something to install some new issues from 3 in the older version... but that's not a new version, is just that Sean wanted to have some things immediately :)

...

...

...

But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed.

I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions.

I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions.

This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0.

I'll do.

...

...

I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it.

But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get touched by these bugs.

...

1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0.

this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and the story will never ends.

And there I can only disagree with you.

* I do want you on an unstable Pharo, something moving and changing fast to be able to aim for the sky and bring me a smile for what tomorrow will bring me... * I want a stable Pharo, because this is where my work takes place, and there bugs should really get fixed... * I want old stable Pharo(s), because, if my work goes into production, it may stay there for years. * And I want a nice path from today's stable to the next stable to be able to port my code as soon as possible (for example, we did OSProcess this time... but I believe there is a chance this work will have to be done again before 3.0 is released ;))

Insisting for 3.0 based developpement means I require additional code to the core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for 3.0 is extremely difficult, with very disruptive changes coming often. And one get tired of complaining; at one point I just open a bugfix, create a slice and add a line to my image building makefiles to load the bugfix because bickering about whether it should be integrated or not isn't worth the time spent on it.

So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze), and 4.0 alpha (experimental), and maybe different teams for handling each of those (and releases on a six months basis?).

that's not possible because that implies manpower that we do not have, and thats, so far, a reality that will not change in the near future. So, what we have is: stable branch (now 2.0), unstable branch (now 3.0), and when we release pharo3, that will become stable and the next branch will be unstable, while 2.0 will fade out. the effort of maintaining multiple versions is exponential, not linear.

Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On Sep 6, 2013, at 2:12 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Le 06/09/2013 12:34, Esteban Lorenzano a écrit :

...

On Sep 6, 2013, at 9:33 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

...

Le 05/09/2013 22:04, Stéphane Ducasse a écrit :

...

...

...

...

Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize).

Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3?

No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact.

As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works (who did it, already? Sean? Sven?).

no, we don't bah, we have 2S, which would be the "2.5" if you want. Also Sean made something to install some new issues from 3 in the older version... but that's not a new version, is just that Sean wanted to have some things immediately :)

This looks like a very nice 2.0.

So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability. Marcus

Goubier Thierry wrote

Le 06/09/2013 14:13, Marcus Denker a écrit :

...

So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability.

I'm OK for that. 3.0 is just plainly too unstable, and this is the way it should be. But 2.0 shouldn't be considered a dead platform ;)

I feel the same pain and was motivated enough to create my special interim version mentioned above. And, having previously backported autocompletion (for 1.4 iirc), I can verify that backporting requires significant manpower. I introduced bugs which I then felt compelled to spend many hours fixing (instead of working) because I had broken production software. Given our massive vision, I feel that manpower is better spent moving forward. And I am willing to deal with the pain of feeling one step behind development if it gets us to the system of our dreams. ----- Cheers, Sean -- View this message in context: http://forum.world.st/OSProcess-for-Pharo3-0-tp4706087p4707036.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On 09/05/2013 05:01 AM, David T. Lewis wrote:

On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote:

...

Why do you need to support Squeak 3.8? This is how many years old?

I really do not understand this idea to be compatible to all old versions ever.

I do not think that there is any right or wrong answer to this, it is perhaps a matter of personal perspective. For me, much of my professional experience is related to supporting manufacturing operations for a large commercial company. In this environment, the ability to engineer solutions to new problems without disrupting existing operations is critical. To me, a failure related to software changes is not just a red mark on a unit test, it is a significant emotional event if I cause a manufacturing plant to stop production (thankfully this has rarely happened in my career so far, knock wood).

So maybe this makes me "conservative", but from my point of view the ability to deliver future versions of software that work without breaking older versions is a matter of good engineering discipline, and I stand by that as a matter of principle.

This is a very good principle :). As an example, at 3DICC we are currently on Squeak4.1, but I think it wasn't that long ago that it was 3.8 based. Of course, all things come to an end. But with larger systems the life cycles are often unbelievably long. regards, Göran

On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote:

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote:

...

Le 03/09/2013 13:36, David T. Lewis a ?crit :

...

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example):

in OSProcess class

isPharo3AndLater "Test if we are on Pharo 3.0"

^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ]

The idea is right, but the details can be a PITA ;-)

- In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime.

- There are no implementors of #major in Squeak (but this can be rewritten using #perform:).

- In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments.

I did not check the other Pharo versions.

Something like this might work:

isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major >= 3 ]]]. ^false

I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype ==> 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? Dave

On Wed, Sep 04, 2013 at 02:17:29PM +0200, Marcus Denker wrote:

On Sep 4, 2013, at 2:13 PM, David T. Lewis <lewis@mail.msen.com> wrote:

...

On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote:

...

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote:

...

Le 03/09/2013 13:36, David T. Lewis a ?crit :

...

Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository.

Here it is (at least an example):

in OSProcess class

isPharo3AndLater "Test if we are on Pharo 3.0"

^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major >= 3 ] ]

The idea is right, but the details can be a PITA ;-)

- In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime.

- There are no implementors of #major in Squeak (but this can be rewritten using #perform:).

- In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments.

I did not check the other Pharo versions.

Something like this might work:

isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major >= 3 ]]]. ^false

I am also checking the platform subtype implementation (OSProcess platformSubtype).

In Pharo:

Smalltalk os subtype ==> 'i686'

This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC).

Is this intentional?

I don't think so.

Marcus

Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. Dave

On Thu, Sep 05, 2013 at 11:18:27AM +0200, Goubier Thierry wrote:

Thanks.

I have merged -dtl.33 and two more change in OSProcess-Base-ThierryGoubier.35 on http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ (osVersion and vmVersion), if you want to merge them as well.

Thanks!

I have a question: are you sure about the perform: #delete in OSProcess class>>#deleteFileNamed: ? ensureDelete/ensureDeleted have a different behavior than #delete.

No, I am not sure about this. It is probably a bug. If you have a correction, I appreciate it. Thanks a lot for your help :) Dave

On Thu, Sep 05, 2013 at 03:31:06PM +0200, Goubier Thierry wrote:

Le 05/09/2013 14:19, David T. Lewis a ?crit :

...

On Thu, Sep 05, 2013 at 11:18:27AM +0200, Goubier Thierry wrote:

...

Thanks.

I have merged -dtl.33 and two more change in OSProcess-Base-ThierryGoubier.35 on http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ (osVersion and vmVersion), if you want to merge them as well.

Thanks!

...

I have a question: are you sure about the perform: #delete in OSProcess class>>#deleteFileNamed: ? ensureDelete/ensureDeleted have a different behavior than #delete.

No, I am not sure about this. It is probably a bug. If you have a correction, I appreciate it.

OSProcess-Base-ThierryGoubier.36 in the same place: http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/

I merged your fixes back into the OSProcess repository. Thank you :-) Dave

On 2013-09-02, at 11:07, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0

I would say the exact opposite, deprecate methods as early as possible If I deprecate a method now, - it is deprecated in the current dev version 3.0 dev - it is deprecated in the next release 3.0 stable - it is removed in the next dev version 4.0 dev so the current behavior is correct. For these issues apply the following strategy: - the latest stable version should load in 2.0 (1.4 is dead) - the latest dev version should most probably work in 3.0 So in this case, OSProcess could be easily updated to use 'Smalltalk os' since that exists already in 2.0, and nobody should even care developing or backporting software for 2.0.