So I'm trying to use AFNetworking library for REST services on a project I want to build on my 2006 Macbook. The Macbook is a first-gen 2006 32-bit Core Duo w/ snow leopard.
I'm fairly new to Objective-C development and I'm following the tutorial to get started with AFNetworking here: https://github.com/AFNetworking/AFNetworking/wiki/Getting-Started-with-AFNetworking
Using xcode 4.2 my problem is that right away when I create a new project and try and build I get: Semantic Issue - Synthesized property 'window' must either be named the same as a compatible ivar or must explicitly name ivar.
I checked the Build Settings of my new project and for some reason xcode by default assumes 64-bit Intel architecture when my machine is 32bit?! weird. I swapped it to 32-bit and this is where the error came up.
So I can correct this Semantic Issue now by explicitly creating my own window instance var in AppDelegate via:
NSWindow * _window;
I read about this on building out for 32bit objc:
Synthesizing a property without instance variables which seems VERY common (lack of ivar declarations) in lots of public github project code I see. Is everyone forcing 64-bit on us now or just too lazy to create the instance vars? :(
So my problem is that it looks like AFNetworking library was built out for 64-bit Intel because when I add AFNetworking to my project I get the same Semantic Issue ivar errors all over the place. Looking at the library code there are no explicit instance variables declared throughout the code for any properties.
Am I completely screwed here? I could fix this situation by manually creating instance vars for all the properties but this would be such a pain for long-term project maintenance.
I guess what I'm wishing here is that there was some sort of compiler flag that I could add that would fix this all in one-shot?? but I'm guessing that I'm out of luck and it's simply time to trash this Macbook and pickup a new modern one.
Automatically synthesized instance variables require the "modern" Objective-C runtime which is only available on 64-bit machines. So, unfortunately you are correct that you can't just set a compiler flag to fix this. The solution is indeed to add instance variable declarations for the properties in the class(es) you're trying to use.
I'm not sure that's so difficult that it's worth throwing out your computer... That said, the conveniences offered by the modern runtime are pretty tempting to developers, and you're not likely to see a lot of new code going forward that maintains support for 32-bit Macs. Apple only sold 32-bit Intel Macs for a short time, and Lion requires a 64-bit Mac, so the proportion of people using 32-bit Macs is already quite small, and rapidly getting smaller.
Related
I am creating a project in maverics(using xcode 5.1.1) ,for 64 bit its running fine but for 34 bit it is giving error.
while running on 34 bit getting this error "-fobjc-arc is not supported on platforms using the legacy runtime"
to remove above error disabled ARC,but i need ARC also
so is there any way to create a project in Maverics using ARC on 32 bit
The 64-bit transition guide for OSX states quite clearly that ARC on OSX is only supported on 64bit.
Applications that target OS X v10.7 and later should take advantage of automatic reference counting (ARC). This technology frees you from having to manually retain and release objects, and in so doing, often fixes latent bugs in applications.
ARC is supported only in the new Objective-C runtime, which is supported only in 64-bit applications. For this reason, most new development should be 64-bit.
The Carbon framework will soon be deprecated in the near future.
My first question is whether the deprecation is targeted towards a particular release i.e. whether it's incompatible with 64-bit machines?
Also, since it is known to be deprecated, we are working towards removing the Carbon dependencies and using Cocoa framework instead. While removing some, I came across the use of EventRecord struct defined in the Events.h file. What should be the Cocoa equivalent of the above struct i.e. I should be able to loop through the Event records while using cocoa too.
Carbon does work with 64-bit machines, but it doesn’t work in a 64-bit mode, it works in 32-bit mode. You definitely want off it.
Cocoa has NSEvents (NSEvent.h), but a lot of what EventRecord appears to cover just isn’t relevant in Cocoa. Like, you don’t have to worry about “this portion of the window was uncovered” events—the system just calls “-drawRect:” on your NSView subclass.
I have looked into at least 6 different SQL Lua extensions, and they all seem to have their latest version compatible with up to version 5.1 of Lua. I have had zero success in implementing any of them into my current project which uses Lua 5.2, with the best case scenario ending in either silent program crashes or attempt to call global 'module' (a nil value).
I am not the original project owner, so I am trying not to be forced into changing the source code for it (though more recently, I have even gone down that road now).
And often times, it is unclear if these crashes are related to the way the project itself operates, the way the project implements Lua (as a static library), the way that Lua tries to implement it's extensions, the way the extensions implement their dependencies, a versioning conflict, or some sort of crazy combination of each. It's practically impossible to debug a silent crash in this manner, because the source of evil could literally be anything.
As the answer states in this question, I have even tried supporting the module function (which most lua sql extensions utilize, but was deprecated in 5.2), but the program still crashes or just complains about a seemingly infinite amount of missing dependencies. And after spending hours of tracking down (what would seem to be) all of the dependencies it would complain about, it still crashes.
Changing the project's source code to use the Lua 5.1 source appears to break the functionality of the project, resulting in various compiler errors regarding missing 5.2-related functions. Linking the MySQL C/C++ connector to the project results in rather vague runtime errors, which seem to conflict with the way the project implements Lua 5.2.
Are there ANY sqlite/MySQL extensions out there which actually work with Lua 5.2 on a 32-bit Windows machine? Preferably, "out-of-the-box" precompiled binaries with Lua source/ffi bindings?
OR alternatively, are there any clear instructions on how to get this set up properly, without having to scavenge through separate instructions across the web for each required assembly?
Having recently read up a on Objective-C it strikes me as a fairly neat language with plenty of cool features.
I have no intention of doing any iPhone development, however I understand that GCC is able to compile Objective-C code and so I wanted to know - Is Objective-C a viable alternative language to C99 for Windows development?
In particular:
Is anyone currently doing Windows development using Objective-C?
Are there any runtime components that would need to be distributed with my applications?
I understand that Objective-C is a superset of C, does this mean that it is possible to use any C-compatible library? (for example the Windows API)
Would I get garbage collection in my applications?
I've found Cocotron and GNUstep which are often mentioned when talking about using Objective-C on other platforms, however as GCC can already be used to compile Objective-C I don't really understand why I would need these.
Are there any other pitfalls or traps I might run in attempting Windows development using Objective-C?
With respect to your first question, I don't know if anyone is seriously doing development on windows with Objective-C, but there may be, though those numbers would probably be less than those doing serious work with a language like whitespace.
Secondly, you would need, at a minimum the objective-c runtime. There are two runtimes, NeXT's (now Apple's) runtime, and the GNU Objective-C runtime. They are not compatible. If you are on a non-NeXT and non-Apple platform, such as windows, you have no choice, GNU runtime only.
Objective-C is a superset of C, and yes you can use the Win32 API if you so desire directly in your objective-c code. As well, you would only get garbage collection if you use a conservative collector, and it ties in with the libraries you're using. In short: No.
What GCC has is support for the objective-c language, and runtime, no standard library. What the GNU objc runtime provides you with in terms of a standard library, is two objects: Object, and NXConstantString class, which is needed to support the #"" syntax. Object is merely a base class. Not very useful, eh? This is why frameworks like Cocotron and GNUstep exist — to give you access to an implementation of OPENSTEP/Cocoa.
Regarding pitfalls or traps, yeah: Your application, even using Cocotron or GNUstep may never be portable to the Mac for instance, or you may get bit by things like typed selectors in the GNU objc runtime, or a plethora of other problems. Let me finish answering this by posing another question: What pitfalls or traps might you run into targeting .NET? I'm sure some if not most of those apply in this case too. Standard pitfalls and traps apply.
I hope this helps.
There is no mature solution yet. If you develop the solution itself, you can do it anyway. But if you're not, it's not the time.
For compiler tools, there is LLVM/Clang which are open-source under BSD license.
The compiler is sponsored by Apple, so it compiles Objective-C completely, and is becoming primary compiler for Apple. So compiler is no problem anymore.
Problem is runtime environment library. Objective-C language is depends it's runtime to execute. The runtime defines all behavior of object system and some more. Runtime environment library is core system and different with framework library like Cocoa or Quartz. in .NET, it's CRE, not .NET framework class library.
Without runtime, program cannot be executed like .NET program executed on Windows without .NET runtime.
For more details, check this conversation:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html
The Objective-C Runtime Reference says:
“Deprecated” below means “deprecated in Mac OS X version 10.5 for 32-bit code, and disallowed for 64-bit code.”
and I would like to use class_setSuperclass in Max OS X version 10.5 even though I still can do it the compiler gives warning telling me its deprecated but it still builds and the Bundle is still usable.
My question is what would be the equivalent in Max OS X 10.5?
On a guess using it is probably not a good idea. I know with the shift towards 64 bit several things in the runtime changed and didn't have a replacement.
The docs even explicitly say not to touch, and doesn't give exception to that.
You can however use class_addMethod to add functionality to a given preexisting class. However, that is also doable via categories.
You can use class_replaceMethod to override a method as well, another possible method is to use a category (or class_addMethod) to add a replacement method. Then using method_exchangeImplementations you can swap them so as to have the original still available for calling.
In general though most of this is kinda dark voodoo, and unless you're comfortable with and willing to test a lot, I'd look for an alternative design.
There may not be a direct equivalent.
I know every time I've played with the class hierarchy at runtime I've been burned. You should be able to achieve the same results, albeit more verbosely via delegation, and I'd imagine that's what they want.