"Jacob Carlborg" <doob@me.com> wrote in message news:go9me9$kg9$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:go88pa$1guq$1@digitalmars.com...
>>> Anders F Björklund wrote:
>>>> Walter Bright wrote:
>>>>
>>>>> Can you upgrade to 10.5 ?
>>>> It's only a few months left to "Snow Leopard",
>>>> then we can play the same game all over again.
>>> Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is worth the effort.
>>
>> Ordinarily, I detest the idea of pulling support for anything as recent as just a few years old. But Apple themselves has a habit of ignoring users of anything except the latest version, so I would think that mac users would be accustomed to the old routine of their OS becoming a deadend the moment a new version comes out. So, in this case, I would think that there may actually be justification in sticking with 10.5+, if you were to so choose.
>
> I would not completely agree with you on this. When you install the developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as default, but you can also choose to install support for older versions. I'm not sure if it's only for 10.3 or also for 10.2.
>
> Then what about Carbon, Classic (don't know if this is still available) and Rosetta, environments and libraries to support older applications.

I was referring more to Apple's own software (which tends to be fairly important when using a mac). For instance I remember not being able to use XCode (instead of Project Builder) because I was on 10.2, and not being able to use certain parts of the "iLife" suite (or newer versions of them) because my OS was merely one point release behind (ie, only about 1.5 years old, at the time). But I dunno, maybe things have been changing since then.

Michel Fortin wrote:
> On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob@me.com> said:
> 
>> Nick Sabalausky wrote:
>>> Ordinarily, I detest the idea of pulling support for anything as recent as just a few years old. But Apple themselves has a habit of ignoring users of anything except the latest version, so I would think that mac users would be accustomed to the old routine of their OS becoming a deadend the moment a new version comes out. So, in this case, I would think that there may actually be justification in sticking with 10.5+, if you were to so choose.
>>
>> I would not completely agree with you on this. When you install the developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as default, but you can also choose to install support for older versions. I'm not sure if it's only for 10.3 or also for 10.2.
> 
> On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2 and 10.3 being PowerPC-only, there's no point trying to compile DMD for them.

You can do that if and only if you don't require newer apis.  If you've been reading this thread, you know that the runtime uses the posix thread apis and those are supported less and less well as you go back in time.  The ability to support the old versions isn't some magic wand that conjures up new features into those old releases.

Later,
Brad

Brad Roberts wrote:
> Michel Fortin wrote:
>> On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob@me.com> said:
>>
>>> Nick Sabalausky wrote:
>>>> Ordinarily, I detest the idea of pulling support for anything as
>>>> recent as just a few years old. But Apple themselves has a habit of
>>>> ignoring users of anything except the latest version, so I would
>>>> think that mac users would be accustomed to the old routine of their
>>>> OS becoming a deadend the moment a new version comes out. So, in this
>>>> case, I would think that there may actually be justification in
>>>> sticking with 10.5+, if you were to so choose.
>>> I would not completely agree with you on this. When you install the
>>> developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as
>>> default, but you can also choose to install support for older
>>> versions. I'm not sure if it's only for 10.3 or also for 10.2.
>> On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using
>> Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2
>> and 10.3 being PowerPC-only, there's no point trying to compile DMD for
>> them.
> 
> You can do that if and only if you don't require newer apis.  If you've
> been reading this thread, you know that the runtime uses the posix
> thread apis and those are supported less and less well as you go back in
> time.  The ability to support the old versions isn't some magic wand
> that conjures up new features into those old releases.
> 
> Later,
> Brad
> 

I was just trying to say that in some cases they do support older systems. I can agree with you that they could support older systems better by updating apis and similar. But somewhere you have to draw a line, if every new api and feature should be available in an older system then what's the point with a new system.

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:go88pa$1guq$1@digitalmars.com...
>> Anders F Björklund wrote:
>>> Walter Bright wrote:
>>>
>>>> Can you upgrade to 10.5 ?
>>> It's only a few months left to "Snow Leopard",
>>> then we can play the same game all over again.
>> Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is worth the effort.
> 
> Ordinarily, I detest the idea of pulling support for anything as recent as just a few years old. But Apple themselves has a habit of ignoring users of anything except the latest version, so I would think that mac users would be accustomed to the old routine of their OS becoming a deadend the moment a new version comes out. So, in this case, I would think that there may actually be justification in sticking with 10.5+, if you were to so choose.

It turns out that Apple doesn't allow OSX prior to 10.5 to be run in a VM, so I can't even generate a test environment for 10.4 unless I track down a spare computer for it.  10.4 may have to remain an unsupported platform simply by necessity.

Brad Roberts wrote:
> Michel Fortin wrote:
>> On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob@me.com> said:
>>
>>> Nick Sabalausky wrote:
>>>> Ordinarily, I detest the idea of pulling support for anything as
>>>> recent as just a few years old. But Apple themselves has a habit of
>>>> ignoring users of anything except the latest version, so I would
>>>> think that mac users would be accustomed to the old routine of their
>>>> OS becoming a deadend the moment a new version comes out. So, in this
>>>> case, I would think that there may actually be justification in
>>>> sticking with 10.5+, if you were to so choose.
>>> I would not completely agree with you on this. When you install the
>>> developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as
>>> default, but you can also choose to install support for older
>>> versions. I'm not sure if it's only for 10.3 or also for 10.2.
>> On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using
>> Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2
>> and 10.3 being PowerPC-only, there's no point trying to compile DMD for
>> them.
> 
> You can do that if and only if you don't require newer apis.  If you've
> been reading this thread, you know that the runtime uses the posix
> thread apis and those are supported less and less well as you go back in
> time.  The ability to support the old versions isn't some magic wand
> that conjures up new features into those old releases.

One somewhat weird issue that we may have to face at some point is that Posix functions whose behavior was changed have had the symbol for the new function changed to _blah$UNIX2003, with the old function left in place.  Since D can't declare symbols like this, we may end up having to add shims in C or post-process object files if it turns out that the old implementation of a function isn't sufficient.  I'd love to hear of a better solution here.

Sean Kelly wrote:
> > One somewhat weird issue that we may have to face at some point is that
> Posix functions whose behavior was changed have had the symbol for the new function changed to _blah$UNIX2003, with the old function left in place.  Since D can't declare symbols like this, we may end up having to add shims in C or post-process object files if it turns out that the old implementation of a function isn't sufficient.  I'd love to hear of a better solution here.

extern(C) void __identifier("blah$UNIX2003")(int);

A beneficial side-effect is that I can finally get rid of all those mixins that are just doing this:

mixin(`void `~name_of_fn~`(int a)
{
    // ... rest of function ...
}`);

:D

  -- Daniel

On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
>
> extern(C) void __identifier("blah$UNIX2003")(int);
>
> A beneficial side-effect is that I can finally get rid of all those mixins that are just doing this:
>
> mixin(`void `~name_of_fn~`(int a)
> {
>    // ... rest of function ...
> }`);

Yes, please, Jesus I'd love that.

Jarrett Billingsley wrote:
> On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep
> <daniel.keep.lists@gmail.com> wrote:
>> extern(C) void __identifier("blah$UNIX2003")(int);
>>
>> A beneficial side-effect is that I can finally get rid of all those
>> mixins that are just doing this:
>>
>> mixin(`void `~name_of_fn~`(int a)
>> {
>>    // ... rest of function ...
>> }`);
> 
> Yes, please, Jesus I'd love that.

Put it as an enhancement request on bugzilla!

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
>>> extern(C) void __identifier("blah$UNIX2003")(int);
>>>
>>> A beneficial side-effect is that I can finally get rid of all those mixins that are just doing this:
>>>
>>> mixin(`void `~name_of_fn~`(int a)
>>> {
>>>    // ... rest of function ...
>>> }`);
>>
>> Yes, please, Jesus I'd love that.
> 
> Put it as an enhancement request on bugzilla!

Your wish is my I'll probably do it if it benefits me too in some way.

http://d.puremagic.com/issues/show_bug.cgi?id=2698

:P

  -- Daniel

Daniel Keep wrote:
> 
> Sean Kelly wrote:
>>> One somewhat weird issue that we may have to face at some point is that
>> Posix functions whose behavior was changed have had the symbol for the
>> new function changed to _blah$UNIX2003, with the old function left in
>> place.  Since D can't declare symbols like this, we may end up having to
>> add shims in C or post-process object files if it turns out that the old
>> implementation of a function isn't sufficient.  I'd love to hear of a
>> better solution here.
> 
> extern(C) void __identifier("blah$UNIX2003")(int);

That would be awesome.

> A beneficial side-effect is that I can finally get rid of all those
> mixins that are just doing this:
> 
> mixin(`void `~name_of_fn~`(int a)
> {
>     // ... rest of function ...
> }`);

I had absolutely no idea that this could be used to generate symbol names that are illegal in D.