macOS i386 and Dictionary Subscripting?

[ArtOfWarfare]

I'm on an iMac with an Intel Core 2 Duo processor - that's x86_64, right?

I'd like to support both i386 and x86_64, so I list both as the Valid Architectures for my build.

Throughout my application, I use Dictionary Subscripting.

If I have Build Active Architecture Only set to Yes, everything works just fine.

If I have Build Active Architecture Only set to No, I get a lot of issues of two types:

1 - (Error) Everyplace I used Dictionary Subscripting, it says "Semantic Issue - Array subscript is not an integer"

2 - (Warning) For almost all of the properties* in my project, it complains because I haven't used @dynamic, @synthesize, or defined my setters and getters for them.

*There are a few "properties" I have in my project which aren't actually backed by iVars and instead are just readonly things declared as properties that have getters I defined to just calculate a value on the fly to return. It doesn't complain about those.

So, why are these errors and warnings popping up if I have Build Active Architecture Only set to NO but not if I have it set to YES?

My application runs on machines running OS X 10.5.0 and I do have customers still running it on i386 machines... I'd really like to hear that I can still support them without having to rewrite my code to not use dictionary subscripting...

 

[Giuly]

All of these new language features require the modern Objective-C runtime. This runtime is used on all architectures for iOS, and 64-bit x86 (x86_64) on the Mac. These features are not supported when targetting i386 on the Mac.

Looks like somebody is going back to initWithObjects:andKeys:, addObject:forKey:, setObject:forKey: and objectForKey:.

Or you try/port this.

Or force <0.5% of your user base to upgrade.

 

[ArtOfWarfare]

Looks like somebody is going back to initWithObjects:andKeys:, addObject:forKey:, setObject:forKey: and objectForKey:

But I just fell in love with Dictionary Subscripting! It's not fair! Not fair I tell you!

Or you try/port this.

Thanks for that; I'll look at it!

Or force <0.5% of your user base to upgrade.
Image

They're a vocal bunch! I had multiple requests to support computers that old. I have some myself.

 

[gnasher729]

They're a vocal bunch! I had multiple requests to support computers that old. I have some myself.

I think we've been there before. Anybody using a 32 bit Mac today isn't going to spend money. Ignore them. They are not worth the money. And I'm saying that as the owner of a 2006 MacBook that is still working fine.

I can see that you want to keep your customers happy. But you keep them more happy by making money, staying in business, and producing new versions, than by catering to a tiny minority that tries to force you to do extra work that doesn't pay you and doesn't benefit 99% of your potential customers.

I suspect that those complaining are people who, like me, have more than one Mac, purchased the app for their newest Mac, and since it is free they want a copy for their older Mac as well. So they are not actually buying anything.

 

[ArtOfWarfare]

I think we've been there before. Anybody using a 32 bit Mac today isn't going to spend money. Ignore them. They are not worth the money. And I'm saying that as the owner of a 2006 MacBook that is still working fine.

I can see that you want to keep your customers happy. But you keep them more happy by making money, staying in business, and producing new versions, than by catering to a tiny minority that tries to force you to do extra work that doesn't pay you and doesn't benefit 99% of your potential customers.

I suspect that those complaining are people who, like me, have more than one Mac, purchased the app for their newest Mac, and since it is free they want a copy for their older Mac as well. So they are not actually buying anything.

This is exactly who they are, and given one of the selling points of the app is it lets you monitor all of your batteries associated with any of your Macs from any of your Macs, it has to work on all of your Macs (that can download from the Mac App Store.)

 

[chown33]

Chalk it up to bad planning on your part. You either bite the bullet and de-embrace dictionary subscripting, or you ignore the i386 customers. Or maybe you figure out a work-around, if there is one.

If i386 was a critical requirement, you should have been compiling for i386 from the first moment you started using dictionary subscripting. The absence of the feature would then have been immediately obvious, and you could have made a decision at that time about which path to take. It's much better to know the tradeoffs up front than to discover them after committing to a path that may prove to be untenable.

As it now stands, you have to make a business decision about which investment you're more willing to lose. You can lose the investment in time & code for dictionary subscripting, which lets you keep the investment in i386 customers. Or you can lose the investment in i386 customers to keep the investment in dictionary subscripting code. Or you can invest more time and code in trying to come up with a work-around that lets you keep both, with a non-zero possibility of failure, leaving you with only the two original alternatives and no viable work-around. I see no other alternatives, and the first two are mutually exclusive.

So, why are these errors and warnings popping up if I have Build Active Architecture Only set to NO but not if I have it set to YES?

What does the description for that option in Xcode tell you?

Do you understand what the Active Architecture is? If the Active Architecture is x86_64, how does that affect what's compiled?

http://developer.apple.com/library/...uild_Setting_Reference/build_setting_ref.html

 

[ArtOfWarfare]

Chalk it up to bad planning on your part. You either bite the bullet and de-embrace dictionary subscripting, or you ignore the i386 customers. Or maybe you figure out a work-around, if there is one.

If i386 was a critical requirement, you should have been compiling for i386 from the first moment you started using dictionary subscripting. The absence of the feature would then have been immediately obvious, and you could have made a decision at that time about which path to take. It's much better to know the tradeoffs up front than to discover them after committing to a path that may prove to be untenable.

As it now stands, you have to make a business decision about which investment you're more willing to lose. You can lose the investment in time & code for dictionary subscripting, which lets you keep the investment in i386 customers. Or you can lose the investment in i386 customers to keep the investment in dictionary subscripting code. Or you can invest more time and code in trying to come up with a work-around that lets you keep both, with a non-zero possibility of failure, leaving you with only the two original alternatives and no viable work-around. I see no other alternatives, and the first two are mutually exclusive.



What does the description for that option in Xcode tell you?

Do you understand what the Active Architecture is? If the Active Architecture is x86_64, how does that affect what's compiled?

http://developer.apple.com/library/...uild_Setting_Reference/build_setting_ref.html

I can't for the life of me figure out why the architecture would make any difference though. Does it not generate code that is identical to what is generated for NSArray's objectAt: and NSDictionary's objectForKey: (method names may not be exact.) ? Those methods compile fine on all architectures, so why wouldn't this new notation?

Clang is open source - correct? So can I just go ahead and modify Clang to fix what seems to me must be a bug?

 

[chown33]

I can't for the life of me figure out why the architecture would make any difference though. Does it not generate code that is identical to what is generated for NSArray's objectAt: and NSDictionary's objectForKey: (method names may not be exact.) ? Those methods compile fine on all architectures, so why wouldn't this new notation?

My first guess is that the feature is tied in with a bunch of other features that aren't supported on the older runtime architecture. One may wish it were more modular, but whatever the reason, it may not be.

Clang is open source - correct? So can I just go ahead and modify Clang to fix what seems to me must be a bug?

Take a look. Let us know what you find.


Maybe the feature really is available to all supported architectures, but there's an architecture-specific flag in your project that has the unfortunate (and possibly undocumented) side-effect of disable support for dictionary subscripting. You could determine that by creating a completely new test project, telling it the archs are i386 & x86_64, compiling for all archs, then writing code that uses subscripting.

If you want a definitive answer, you should make a test case for it. Possibly after a careful reading of the release notes regarding the feature, to avoid another investment of time & code that's ultimately fruitless.

 

[JoshDC]

This document discusses new Objective-C features in depth:

http://clang.llvm.org/docs/ObjectiveCLiterals.html

And gives the following explanation:

An Objective-C subscript expression occurs when the base operand of the C subscript operator has an Objective-C object pointer type. Since this potentially collides with pointer arithmetic on the value, these expressions are only supported under the modern Objective-C runtime, which categorically forbids such arithmetic.

The modern Objective-C runtime is not supported on i386 and so you can not use subscripting when targeting i386.

 

[ArtOfWarfare]

This document discusses new Objective-C features in depth:

http://clang.llvm.org/docs/ObjectiveCLiterals.html

And gives the following explanation:



The modern Objective-C runtime is not supported on i386 and so you can not use subscripting when targeting i386.

So the modern runtime would have to be ported to i386? What would that entail?

 

[chown33]

So the modern runtime would have to be ported to i386? What would that entail?

Likely far more work than it would take to change your source to not use object subscripting.

Just the fact that one would have to test the port on all possible i386 target machines would lead me to discount such a port as a viable alternative.

 

[ArtOfWarfare]

Likely far more work than it would take to change your source to not use object subscripting.

Just the fact that one would have to test the port on all possible i386 target machines would lead me to discount such a port as a viable alternative.

I'm getting the sense you're trying to push me in a certain direction... (Kidding. I used subscripts 30-40 times in the program. Rewriting without them won't take long... It'll just be saddening to see my code get a bit more difficult to read.)

 

[Catfish_Man]

So the modern runtime would have to be ported to i386? What would that entail?

First you'd have to get a job at Apple on the Objective-C team*, then convince them that this was a priority, then do some extremely difficult porting work that they've so far been unable to do themselves.

Writing your own ObjC runtime is not a realistic option.


*alternatively, start from the open source one, and cross your fingers that there are no internal-only bits left out of it

 

[ArtOfWarfare]

First you'd have to get a job at Apple on the Objective-C team*, then convince them that this was a priority, then do some extremely difficult porting work that they've so far been unable to do themselves.

Writing your own ObjC runtime is not a realistic option.


*alternatively, start from the open source one, and cross your fingers that there are no internal-only bits left out of it

I was under the impression it was all open source?

 

[Catfish_Man]

I was under the impression it was all open source?

Possibly. I'm less familiar with the exact details of the runtime source. CoreFoundation though, while open source, is missing chunks, even in the middle of functions.

 

[PatrickCocoa]

Not that you asked, but . . .

. . . it will be far more economical to simply refund the purchase price to anyone who both has an i386 and asks for their money back. You're losing money on rewriting the code, you will lose orders of magnitude less if you give that subset of users their money back.

At the same time as you refund their money, point them to a competitor's product that does something similar and supports i386. This will show you to be a reasonable person and should reduce some (but not all!) of the blowback. Also, if you think deviously like me, you're transferring your support issues to a competitor.

You're trying to solve your users' problems, but you're not their servant. You get to choose who your customers are.

 

[ArtOfWarfare]

. . . it will be far more economical to simply refund the purchase price to anyone who both has an i386 and asks for their money back. You're losing money on rewriting the code, you will lose orders of magnitude less if you give that subset of users their money back.

At the same time as you refund their money, point them to a competitor's product that does something similar and supports i386. This will show you to be a reasonable person and should reduce some (but not all!) of the blowback. Also, if you think deviously like me, you're transferring your support issues to a competitor.

You're trying to solve your users' problems, but you're not their servant. You get to choose who your customers are.

I have no competition. I'll probably just write a CPP macro that replaces indexes with proper NSArray and NSDictionary references if the architecture is i386... I don't know much about writing them but I think they're flexible enough to handle this (and it'll make for a learning experience.)

While I'm on the topic of supporting old things, it looks like 10% of Mac users are still running Leopard or older... possibly I should move back my minimum OS requirement to before 10.6.6, which is what it's at right now... I'm not certain but I think the newest things it's using (besides index notation) is a few drawing calls that were added in 10.5 (currently the version limit is just set as the oldest version the Mac App Store is on, but there's really no reason to do that.)

http://chitika.com/os-x-version-distribution

 

[ArtOfWarfare]

Looks like somebody is going back to initWithObjects:andKeys:, addObject:forKey:, setObject:forKey: and objectForKey:.

Or you try/port this.

Or force <0.5% of your user base to upgrade.
Image

Here's the problem: the customers who bulk buy Battery Status are schools and organizations with too tight a budget to buy hundreds of newer Macs, but they can afford to buy hundreds of copies of Battery Status. It took until recently to realize that that's why a disproportionate amount of my customers are stuck with old hardware and OSes.

 

[Giuly]

Given that the Mac also has libarclite for older versions of OS X, I'm amazed that nobody has ported the iOS-Subscripting headers to the Mac by now.

 

[ArtOfWarfare]

Given that the Mac also has libarclite for older versions of OS X, I'm amazed that nobody has ported the iOS-Subscripting headers to the Mac by now.

They were released for Mac at the same time as for iOS. The issue is they only support 64 bit intel chips, not 32 bit intel chips (which, admittedly, Apple only used in a few lines for a few months. Still, many of my customers have them.)