Must OSPlatform class>>osVersion be deprecated?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Must OSPlatform class>>osVersion be deprecated?

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

Hannes Hirzel
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

Sean P. DeNigris
Administrator
In reply to this post by David T. Lewis
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

Marcus Denker-4
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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

David T. Lewis
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
> >>
> >>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

David T. Lewis
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


cbc
Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

cbc
In reply to this post by David T. Lewis

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).
Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

Marcus Denker-4

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 ;)
>
I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

Marcus Denker-4

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


Reply | Threaded
Open this post in threaded view
|

Re: Must OSPlatform class>>osVersion be deprecated?

David T. Lewis
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