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 <[hidden email]> 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 > > > |
Administrator
|
In reply to this post by David T. Lewis
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
Cheers,
Sean |
In reply to this post by Hannes Hirzel
On Jan 22, 2013, at 5:27 PM, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 > >> > >> > >> > > > |
In reply to this post by Sean P. DeNigris
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 |
In reply to this post by David T. Lewis
On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <[hidden email]> 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).
|
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 <[hidden email]>wrote: > > > On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote: > > > > > > On Jan 22, 2013, at 5:27 PM, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>wrote: >> >>> On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote: >>>> >>>> On Jan 22, 2013, at 5:27 PM, H. Hirzel <[hidden email]> 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 ;) > Marcus |
On Jan 23, 2013, at 7:28 AM, Marcus Denker <[hidden email]> 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. > 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 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |