[Pharo-project] Must OSPlatform class>>osVersion be deprecated?
Why is OSPlatform class>>osVersion deprecated but OSPlatform class>>platformName is not? My suggestion would be to comment #osVersion as being a synonym for #version, but do not deprecate it. That would enable use of "Smalltalk os version", and it would also support "OSPlatform osVersion", both of which make logical sense. It would also maintain support for external packages that rely on #osVersion to figure out platform differences. The reason that I am asking is that I am trying to find a way to make OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis. I quite honestly cannot figure out any way to add Pharo 2.0 without breaking one more more of the other supported images. If OSPlatform class>>osVersion did not raise a deprecation warning, then I could make it work. Thanks, Dave
Dave I wonder why you can't check for Smalltalk at: #OSPlatform and if that exists go for OSPlatform osVersion Neither Squeak nor Cuis do have an OSPlatform class. Then you go for Smalltalk os version Am I missing something here? --Hannes On 1/21/13, David T. Lewis <lewis@mail.msen.com> wrote:
Why is OSPlatform class>>osVersion deprecated but OSPlatform class>>platformName is not?
My suggestion would be to comment #osVersion as being a synonym for #version, but do not deprecate it. That would enable use of "Smalltalk os version", and it would also support "OSPlatform osVersion", both of which make logical sense. It would also maintain support for external packages that rely on #osVersion to figure out platform differences.
The reason that I am asking is that I am trying to find a way to make OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis. I quite honestly cannot figure out any way to add Pharo 2.0 without breaking one more more of the other supported images. If OSPlatform class>>osVersion did not raise a deprecation warning, then I could make it work.
Thanks, Dave
On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Dave
I wonder why you can't check for
Smalltalk at: #OSPlatform
and if that exists go for OSPlatform osVersion
We deprecated that⦠but I can un-deprecate.
Neither Squeak nor Cuis do have an OSPlatform class.
Then you go for Smalltalk os version
This works in Pharo 2.0â¦
Am I missing something here?
--Hannes
On 1/21/13, David T. Lewis <lewis@mail.msen.com> wrote:
Why is OSPlatform class>>osVersion deprecated but OSPlatform class>>platformName is not?
My suggestion would be to comment #osVersion as being a synonym for #version, but do not deprecate it. That would enable use of "Smalltalk os version", and it would also support "OSPlatform osVersion", both of which make logical sense. It would also maintain support for external packages that rely on #osVersion to figure out platform differences.
The reason that I am asking is that I am trying to find a way to make OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis. I quite honestly cannot figure out any way to add Pharo 2.0 without breaking one more more of the other supported images. If OSPlatform class>>osVersion did not raise a deprecation warning, then I could make it work.
Thanks, Dave
On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Dave
I wonder why you can't check for
Smalltalk at: #OSPlatform
and if that exists go for OSPlatform osVersion
We deprecated that? but I can un-deprecate.
Neither Squeak nor Cuis do have an OSPlatform class.
Then you go for Smalltalk os version
This works in Pharo 2.0?
Yes, "Smalltalk os version" is right for Pharo 2.0. I'm looking for a way to modify the following method so that it adds support for Pharo 2.0, so that it continues to work in the other images, and so that it does not raise deprecation warnings or DNUs in any of the images. OSProcess class>>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." ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #osVersion]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) osVersion Dave
Am I missing something here?
--Hannes
On 1/21/13, David T. Lewis <lewis@mail.msen.com> wrote:
Why is OSPlatform class>>osVersion deprecated but OSPlatform class>>platformName is not?
My suggestion would be to comment #osVersion as being a synonym for #version, but do not deprecate it. That would enable use of "Smalltalk os version", and it would also support "OSPlatform osVersion", both of which make logical sense. It would also maintain support for external packages that rely on #osVersion to figure out platform differences.
The reason that I am asking is that I am trying to find a way to make OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis. I quite honestly cannot figure out any way to add Pharo 2.0 without breaking one more more of the other supported images. If OSPlatform class>>osVersion did not raise a deprecation warning, then I could make it work.
Thanks, Dave
On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <lewis@mail.msen.com>wrote:
On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Dave
This works in Pharo 2.0?
Yes, "Smalltalk os version" is right for Pharo 2.0.
I'm looking for a way to modify the following method so that it adds support for Pharo 2.0, so that it continues to work in the other images, and so that it does not raise deprecation warnings or DNUs in any of the images.
Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).
On Tue, Jan 22, 2013 at 01:51:56PM -0800, Chris Cunningham wrote:
On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <lewis@mail.msen.com>wrote:
On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Dave
This works in Pharo 2.0?
Yes, "Smalltalk os version" is right for Pharo 2.0.
I'm looking for a way to modify the following method so that it adds support for Pharo 2.0, so that it continues to work in the other images, and so that it does not raise deprecation warnings or DNUs in any of the images.
Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).
No, Pharo 2.0 is writing console output whenever an exception occurs, so catching the exception is not good. But not raising the exception in the first place works just fine ;) Dave
On Jan 22, 2013, at 11:55 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Jan 22, 2013 at 01:51:56PM -0800, Chris Cunningham wrote:
On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <lewis@mail.msen.com>wrote:
On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Dave
This works in Pharo 2.0?
Yes, "Smalltalk os version" is right for Pharo 2.0.
I'm looking for a way to modify the following method so that it adds support for Pharo 2.0, so that it continues to work in the other images, and so that it does not raise deprecation warnings or DNUs in any of the images.
Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).
No, Pharo 2.0 is writing console output whenever an exception occurs, so catching the exception is not good. But not raising the exception in the first place works just fine ;)
I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility. Marcus
On Jan 23, 2013, at 7:28 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).
No, Pharo 2.0 is writing console output whenever an exception occurs, so catching the exception is not good. But not raising the exception in the first place works just fine ;)
I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility.
Ok, this should end up in the image by tomorrow: Issue 7306: un-deprecate OSPlatform osVersion for compatibility http://code.google.com/p/pharo/issues/detail?id=7306
On Wed, Jan 23, 2013 at 03:08:57PM +0100, Marcus Denker wrote:
On Jan 23, 2013, at 7:28 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).
No, Pharo 2.0 is writing console output whenever an exception occurs, so catching the exception is not good. But not raising the exception in the first place works just fine ;)
I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility.
Ok, this should end up in the image by tomorrow:
Issue 7306: un-deprecate OSPlatform osVersion for compatibility http://code.google.com/p/pharo/issues/detail?id=7306
Thank you :)) Dave
David T. Lewis wrote
I am trying to find a way to make OSProcess... work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis
I've been thinking a lot about keeping OSP working well on all our favorite St platforms. Metacello was designed specifically to address this type of problem, which I'm sure will multiply as squeak and pharo evolve. I wonder if MetaC works with Cuis... If not, and for older versions of Squeak/Pharo, there could be a Gofer/Installer script like the one for FFI, or - easier for users but maybe a little more work - the multiple packages could be loaded in each supported platform and re-commited as a single platform-specific package e.g. OSProcessSqueak44, OSProcessPharo20; so development would be done w. MetaC, and users can simply download one package. This would also free us from the branching that currently exists to figure out which system we're on. Are you open to committing to the multiple-package path going forward and relying on MetaC to manage these incompatibilities? Sean -- View this message in context: http://forum.world.st/Must-OSPlatform-class-osVersion-be-deprecated-tp466434... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Jan 22, 2013 at 09:15:32AM -0800, Sean P. DeNigris wrote:
David T. Lewis wrote
I am trying to find a way to make OSProcess... work on Pharo 2.0, Pharo1.x, and the various versions of Squeak and Cuis
I've been thinking a lot about keeping OSP working well on all our favorite St platforms. Metacello was designed specifically to address this type of problem, which I'm sure will multiply as squeak and pharo evolve. I wonder if MetaC works with Cuis... If not, and for older versions of Squeak/Pharo, there could be a Gofer/Installer script like the one for FFI, or - easier for users but maybe a little more work - the multiple packages could be loaded in each supported platform and re-commited as a single platform-specific package e.g. OSProcessSqueak44, OSProcessPharo20; so development would be done w. MetaC, and users can simply download one package. This would also free us from the branching that currently exists to figure out which system we're on. Are you open to committing to the multiple-package path going forward and relying on MetaC to manage these incompatibilities?
Metacello will certainly handle this, and I certainly don't mind as long as I don't get stuck doing the maintenance chores for all the different images. I don't want to do Metacello configs for Squeak (because it is not necessary) or Cuis (I don't know if it is possible and I don't have the time), but it would be a good approach to support the more rapid rate of change in Pharo. My first preference would be to have the OSProcess package be clever enough to adapt to the various image variations, but that may not be feasible if the images get too different. Maybe we are at that point now, in which case maintaining Metacello configurations for Pharo 2.0, 1.4, etc would be the right thing to do. Dave
participants (5)
-
Chris Cunningham -
David T. Lewis -
H. Hirzel -
Marcus Denker -
Sean P. DeNigris