Re: Customizing a Mac Installer Package
Hi, I'm also planning to do a graphic installer with the app i'm working on. I found this helper cocoa app, BSD licensed, that seem interesting. I've only played with it a bit but i haven't started working on the installer, so i can't bring any experience of successfulness yet. It's called Packages - http://bit.ly/1gsYeCG I'm not affiliated to the authors of this application. 2014-01-30 Charles Srstka cocoa...@charlessoft.com: On Jan 29, 2014, at 11:36 AM, Bradley O'Hearne br...@bighillsoftware.com wrote: Hello, I am working on an app which for the present version, must be installed via an installer package. The next version will be a Mac App Store app, so this won’t be a concern then. But for the time being, the app has its own package installer. In Xcode (current version), when you create and distribute an archive, and attempt to export the option for “Mac Installer Package” it creates an installer package that we need to customize. Presently we are using the sorely outdated and deprecated PackageMaker app which came with auxiliary tools several Xcode versions ago. Aside from the obvious reasons this is undesirable, it makes building a two-step process where it only need be one, and also has presented some signing issues in the past. What I am trying to accomplish is being able to customize the installer with some simple branding and addition of a few extra files which need to be installed, and I would like do drive it all from Xcode, such that exporting the “Mac Installer Package” in the UI creates this custom installer — I don’t know if there’s a way to have that process hook a config file, or something like that, but that’s the idea. Can this be done, and if so, can someone point me in the right direction? Have a look at the pkgbuild(1) and productbuild(1) command line tools, and see if they are capable of building a package which is customized to your specifications. If so, you can put the appropriate invocations into your build scripts. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/vanniparronchi%40gmail.com This email sent to vanniparron...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Legal Opinion on GCUndoManager
It's not the defining but the calling. If your code calls a method with the same name as an Apple private method you, at least in the iOS store get auto rejected. I see it in the dev forums constantly. At analysis time there's no way of knowing what object the method is called on so the signature counts and the analyser looks for method calls. If Graham's own code called that method then I think he'd get a rejection, but merely defining it (and letting the framework call it) doesn't trip up the detector. Whether Apple would reject apps which define methods like that if they knew about it is unknown. On 30 Jan, 2014, at 13:24, Jerry Krinock je...@ieee.org wrote: On 2014 Jan 29, at 13:03, Keary Suska cocoa-...@esoteritech.com wrote: unfortunately it [GCUndoManager] is not App Store safe … as it relies on a private method call for proper NSDocument change tracking… I just spent the last half hour studying this and wrote my own concise legal opinion arguing why GCUndoManager is OK. Now having read Graham’s post, it’s probably redundant. But I’m posting it here anyhow in case I or anyone else ever needs it :) Although -[NSUndoManager _processEndOfEventNotification:] is a non-public API, -[GCUndoManager _processEndOfEventNotification:] is NOT a non-public API. As a matter of fact, it is not even an Apple API! It’s the same as if I defined a class CorePerformer and innocently named a method -[CorePerformer _corePerformAction]. There also happens to be an Apple non-public method -[NSMenuItem _corePerformAction]. Certainly my definition should not result in an app store rejection. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Customizing a Mac Installer Package
On Thursday, January 30, 2014, Vanni Parronchi vanniparron...@gmail.com wrote: Hi, I'm also planning to do a graphic installer with the app i'm working on. I found this helper cocoa app, BSD licensed, that seem interesting. I've only played with it a bit but i haven't started working on the installer, so i can't bring any experience of successfulness yet. It's called Packages - http://bit.ly/1gsYeCG I've used it, and it works well. Comes highly recommended from me. I'm not affiliated to the authors of this application. 2014-01-30 Charles Srstka cocoa...@charlessoft.com: On Jan 29, 2014, at 11:36 AM, Bradley O'Hearne br...@bighillsoftware.com wrote: Hello, I am working on an app which for the present version, must be installed via an installer package. The next version will be a Mac App Store app, so this won't be a concern then. But for the time being, the app has its own package installer. In Xcode (current version), when you create and distribute an archive, and attempt to export the option for Mac Installer Package it creates an installer package that we need to customize. Presently we are using the sorely outdated and deprecated PackageMaker app which came with auxiliary tools several Xcode versions ago. Aside from the obvious reasons this is undesirable, it makes building a two-step process where it only need be one, and also has presented some signing issues in the past. What I am trying to accomplish is being able to customize the installer with some simple branding and addition of a few extra files which need to be installed, and I would like do drive it all from Xcode, such that exporting the Mac Installer Package in the UI creates this custom installer -- I don't know if there's a way to have that process hook a config file, or something like that, but that's the idea. Can this be done, and if so, can someone point me in the right direction? Have a look at the pkgbuild(1) and productbuild(1) command line tools, and see if they are capable of building a package which is customized to your specifications. If so, you can put the appropriate invocations into your build scripts. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/vanniparronchi%40gmail.com This email sent to vanniparron...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
I too don’t get it. And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? On 30 Jan 2014, at 12:49, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 11:53, Rui Pacheco rui.pach...@gmail.com wrote: And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? I would say that message sending is very different indeed: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html An Obj-C can load code dynamically at run time see: NSBundle -load. This makes it possible for an Obj-C object to modify the messages that it can respond to at run time. This may sound rather abstract but it is extremely useful for writing extensible applications that load up their functionality from plugin bundles. You can also load frameworks dynamically in this way - though it is more common to use the dynamic linker. A lot of Cocoa based languages and Cocoa bridges use this technique to access framework based functionality. The possible behaviours of a C# or C++ are largely defined at compile time. The actual behaviour of an Objective-C application will only be revealed at runtime. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
When writing code you get the impression that you’re just calling methods. The type system may make the language more malleable, but when writing normal Core Data driven apps, you’re calling methods on objects. And I wonder if some of the things you highlighted couldn’t be done with well defined interfaces when using other languages. On 30 Jan 2014, at 13:10, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 11:53, Rui Pacheco rui.pach...@gmail.com wrote: And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? I would say that message sending is very different indeed: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html An Obj-C can load code dynamically at run time see: NSBundle -load. This makes it possible for an Obj-C object to modify the messages that it can respond to at run time. This may sound rather abstract but it is extremely useful for writing extensible applications that load up their functionality from plugin bundles. You can also load frameworks dynamically in this way - though it is more common to use the dynamic linker. A lot of Cocoa based languages and Cocoa bridges use this technique to access framework based functionality. The possible behaviours of a C# or C++ are largely defined at compile time. The actual behaviour of an Objective-C application will only be revealed at runtime. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
Le 30 janv. 2014 à 12:49, jonat...@mugginsoft.com a écrit : On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? We're not talking about code sharing, we are talking about dynamic library. It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. And I'm not even mentioning the fact that it is possible to build incompatible code from the same sources, depending the C++ features you enable (RTTI, …) The problem is limited with STL as most of it is just templates and the STL dylib itself contains very few code. While trying to expose a stable API and ABI in a dynamic library is possible, it is very complex or require some nasty construct like pimpl (which does not solve the virtual method issues). Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
The recent flood of language philosophy is informative and interesting but doesn't address the issues I am interested in. My case is one of using the C++ std lib for the containers to work with traversing a special DAG graph. I've not found any C or Obj-C code that provides those and I see no reason to write them myself when C++ has them. On 2014-01-29, at 12:13 PM, Abdul Sowayan asowa...@vectorworks.net wrote: Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Well, I’m not clear as to what information you’re trying to find. Can you elaborate? Abdul In answer to Abdul's question there a a few things that immediately come to mind: The 2005 paper by Josh Anon (I have a pdf) mentions (0) The next thing to notice is that we’re mixing #import and #include directives here. It’s not a problem at all for the compiler. In fact, we could use: #import iostream and things would be fine. Actually, using #import is preferable to #include, because #import automatically makes sure the file’s only included once as opposed to having to #ifdef files we #include. Still true? (1) Before we begin coding, note that Objective-C++ classes, protocols, and categories cannot be declared within a separate namespace (nor can a C++ namespace be declared within an Objective-C++ object) Everything must be within the global namespace. Obviously true - no namespaces in Obj-C. (2) Just make sure to link against libstdc++ and Cocoa (or Foundation) in your Xcode project when you write your own code. Naturally. (3) Notice that we’ve intermixed Objective-C’s reference counting memory management with C++’s memory management. We cannot call delete on an Objective-C object, and we cannot call -release on a C++ variable. True even with ARC. (4) When do we need to use ifdef cplusplus or ifdef objc these days? etc... thanks Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 01:28, Eric Wing ewmail...@gmail.com wrote: - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. But don't forget, Obj-C is a pure superset of C and you can always use good old C to get the same performance benefits if you don't need/want the Obj-C features. Other really high performance situations deal with cache and memory layout and it turns out that much of the C++ standard library is not well suited for dealing with this and going back to POD types and essentially C (if not assembly) is often better for performance. Well, I'd rather use a barely-OO language like C++ than go down to procedural with C++ and get all those buffer overruns back ... -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 12:49, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? In short, method look-up depends on order of methods (so deleting a method breaks calls to all methods below it) and it suffers the fragile base class problem both for instance variables *and* methods. With the classic runtime, ObjC only had fragile base classes for ivars, since method lookup goes by SEL. With the modern runtime (iOS or Mac-64-bit), not even that anymore. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 12:53, Rui Pacheco rui.pach...@gmail.com wrote: I too don’t get it. And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? No, they're very different. If you're curious, I blogged how C++ dispatches method calls under the hood in this article: http://orangejuiceliberationfront.com/runtime-time/ The sample code included with it implements the ObjC approach of actually looking stuff up by name. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 14:35, Peter Teeson ptee...@icloud.com wrote: The recent flood of language philosophy is informative and interesting but doesn't address the issues I am interested in. My case is one of using the C++ std lib for the containers to work with traversing a special DAG graph. I've not found any C or Obj-C code that provides those and I see no reason to write them myself when C++ has them. On 2014-01-29, at 12:13 PM, Abdul Sowayan asowa...@vectorworks.net wrote: Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Well, I’m not clear as to what information you’re trying to find. Can you elaborate? Abdul In answer to Abdul's question there a a few things that immediately come to mind: The 2005 paper by Josh Anon (I have a pdf) mentions (0) The next thing to notice is that we’re mixing #import and #include directives here. It’s not a problem at all for the compiler. In fact, we could use: #import iostream and things would be fine. Actually, using #import is preferable to #include, because #import automatically makes sure the file’s only included once as opposed to having to #ifdef files we #include. Still true? Sure. They both just paste the code into the file. It's just that #import checks whether it already did the file in this compilation unit, #include doesn't. (1) Before we begin coding, note that Objective-C++ classes, protocols, and categories cannot be declared within a separate namespace (nor can a C++ namespace be declared within an Objective-C++ object) Everything must be within the global namespace. Obviously true - no namespaces in Obj-C. Is that a typo that it says Objective-C*++*? It should say Objective-C classes. C++ classes in ObjC++ can be in namespaces. Objective-C classes in ObjC++ files can't (and clang actually makes that an error, while GCC just ignored the namespace). There is no such thing as an Objective-C++ class. That's one of the main distinctions, both class systems are separate. (3) Notice that we’ve intermixed Objective-C’s reference counting memory management with C++’s memory management. We cannot call delete on an Objective-C object, and we cannot call -release on a C++ variable. True even with ARC. Although ARC works on ObjC pointers in ivars of C++ objects. (And since C++ objects are the same as structs to the C++ compiler, they also work on structs under the ObjC++ compiler) (4) When do we need to use ifdef cplusplus or ifdef objc these days? You use #ifdef __cplusplus when you plan to use C++ code (including those darned extern C statements) in headers that get included by C or ObjC source files. You use #ifdef __OBJC__ when you plan to use ObjC code in headers that get included in C++ or C source files. Also keep in mind that you can't just #ifdef out a method in a C++ class that takes an ObjC argument, as that will have the C++ file get a different offset for all following functions than the ObjC++ file. Also, since C++ overloads by type, You can't change the type of an ivar or parameter to a method or function, because then it will get a different name. I go into more detail about all this in the NSBrief podcast, just listen to that. etc... Too vague :-p -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 30 Jan 2014, at 15:09, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 30 Jan 2014, at 01:28, Eric Wing ewmail...@gmail.com wrote: - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. But don't forget, Obj-C is a pure superset of C and you can always use good old C to get the same performance benefits if you don't need/want the Obj-C features. Other really high performance situations deal with cache and memory layout and it turns out that much of the C++ standard library is not well suited for dealing with this and going back to POD types and essentially C (if not assembly) is often better for performance. Well, I'd rather use a barely-OO language like C++ than go down to procedural with C++ and get all those buffer overruns back ... procedural with *C* I meant. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On Jan 29, 2014, at 4:44 PM, Graham Cox graham@bigpond.com wrote: On 30 Jan 2014, at 8:03 am, Keary Suska cocoa-...@esoteritech.com wrote: Absolutely, and I have found it invaluable to troubleshoot state issues, but unfortunately it is not App Store safe (read: basis for rejection), as it relies on a private method call for proper NSDocument change tracking... It does? I'm using it in an App Store app without it ever having come up as an issue. Have you actually had this flagged as an issue by The Keepers Of The Store™? If you're referring to: - (void) _processEndOfEventNotification:(NSNotification*) note I'm not sure that counts as using private API as such. It's just a stub for a method that NSDocument calls on its undo manager, and as you can see it's only a notification handler (containing no code). It's needed because NSDocument doesn't check whether the undo manager implements it before calling it, so it will cause an unrecognised selector exception if it's not there, but it's not actually calling any private API itself anywhere - NSDocument is. It doesn't matter if you are calling it, or if the framework is calling it - you are effectively using the private API. Method names with leading underscores are defined as private methods, reserved for Apple. From https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-1003829-BCIBDJCA (emphasis mine) Private Methods In most cases, private method names generally follow the same rules as public method names. However, a common convention is to give private methods a prefix so it is easy to distinguish them from public methods. Even with this convention, the names given to private methods can cause a peculiar type of problem. When you design a subclass of a Cocoa framework class, you cannot know if your private methods unintentionally override private framework methods that are identically named. Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private. From this fact follow two recommendations. • Don’t use the underscore character as a prefix for your private methods. Apple reserves this convention. (One work around would be to implement doesNotRecognizeSelector: and ignore it there, and this would also make it future safe for when new private methods are added - in the mean time, file a bug asking that NSUndoManager can be fully replaceable with publicly declared methods only). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Horizontol scroller not enabled in IB
Using Xcode 5.0.2 in Mac OS 10.9.1, I created a Cocoa document app, replacing the templated text field with a textview. After making the necessary connections, everything worked as intended. I then went into Document.xib and checked Show Horizontal Scroller in the Bordered scroll view (in addition to the default vertical scroller). All this with no AutoLayout constraints. When I ran the app, the horizontal scroller was visible but did not have a scroll bar (text wrapped around) and I got the following error message from LLDB: ** Layout still needs update after calling -[NSScrollView layout]. NSScrollView or one of its superclasses may have overridden -layout without calling super. Or, something may have dirtied layout in the middle of updating it. Both are programming errors in Cocoa Autolayout. The former is pretty likely to arise if some pre-Cocoa Autolayout class had a method called layout, but it should be fixed. ** Did I miss something? Thanks. -- Michael P. McLaughlin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 2014 Jan 30, at 07:39, glenn andreas gandr...@me.com wrote: in the mean time, file a bug asking that NSUndoManager can be fully replaceable with publicly declared methods only Thank you, Glenn, but I don’t think so. All of that stuff regarding underscores is “should”, not “must”, and it is not in the Mac App Store Review Guidelines. More importantly, in the other thread “Legal Opinion on GCUndoManager, Gideon King reported that his app with GCUndoManager was approved by the Mac App Store. “If it ain’t broke, don’t fix it” is often good advice, particularly when dealing with corporate bureaucracies. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On Thu, Jan 30, 2014, at 10:28 AM, Jerry Krinock wrote: On 2014 Jan 30, at 07:39, glenn andreas gandr...@me.com wrote: in the mean time, file a bug asking that NSUndoManager can be fully replaceable with publicly declared methods only Thank you, Glenn, but I don’t think so. All of that stuff regarding underscores is “should”, not “must”, and it is not in the Mac App Store Review Guidelines. More importantly, in the other thread “Legal Opinion on GCUndoManager, Gideon King reported that his app with GCUndoManager was approved by the Mac App Store. “If it ain’t broke, don’t fix it” is often good advice, particularly when dealing with corporate bureaucracies. Jerry, you can argue all you like, but we've been rejected for merely *referencing* verboten selectors, in point releases we've submitted that did not touch code anywhere near the flagged reference. Apple will do what Apple will do, whenever Apple feels like it. If you want to avoid rejections, avoid referencing private API at all. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
How did you factor out the application logic from the UI rendering? On 30 Jan 2014, at 21:16, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 2014-01-30, at 2:20 PM, Kyle Sluder k...@ksluder.com wrote: … Apple will do what Apple will do, whenever Apple feels like it. If you want to avoid rejections, avoid referencing private API at all. --Kyle Sluder Alternatively avoid the App store (and save 30%)…..grin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 2014-01-30, at 3:16 PM, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder That's a good and useful reply to address my concerns. Thanks… Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 2014-01-30, at 3:23 PM, Rui Pacheco rui.pach...@gmail.com wrote: How did you factor out the application logic from the UI rendering? On 30 Jan 2014, at 21:16, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder I don't know how Jo did it but in my case the model will (most likely need to) be C++ and the UI (which is merely for interim progress reporting and debugging) will be Obj-C, mainly Cocoa. The main process does not need a GUI. Last time I seriously used Obj-C++ was back in the Xcode 3 days so just wanted to find out what has changed. Jo's answer is most comforting. Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
Hi Rui, On 31/01/2014, at 9:23 AM, Rui Pacheco wrote: How did you factor out the application logic from the UI rendering? If you mean our application logic, it essentially comes down to abstraction. The application is C++ and sits on our application framework, similar to Qt or wxWidgets. The application framework is also mostly C++ and it mainly uses a bridge pattern to interface with platform specific back ends. On the Mac this back end is Cocoa (Obj-C++), on Windows it's Win32 and on Linux the UI specific parts are empty as the app runs as a CLI render node. The application itself has no knowledge of the underlying API. Well, that's not entirely true as the framework is designed to be thin so the application can get to platform specific stuff if need be, but that's the idea anyway. All UI elements are created programatically, so we don't use nibs on the Mac. In fact I do use IB to design the Mac interface when needed but I have a tool which generates an XML file from the nib, and the XML file is parsed by the framework to generate the UI. It's a bit old school but I use IB 3 and a Carbon nib for this, as that is sufficient for my needs. It does mean I have to do some tweaking to account for layout differences at times. Regards, Jo Meder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
Is this documented somewhere? On 30 Jan 2014, at 22:26, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On Jan 30, 2014, at 1:38 PM, Peter Teeson ptee...@icloud.com wrote: ...so just wanted to find out what has changed. Support for most of C++11 :-) :-) :-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
Google Taligent. (Snicker, snicker, snicker...) They actually wrote a good book on the subject, which was very effective at convincing most sane people to JUST NOT EVEN TRY THAT ;-) Anyway, this has *nothing* to do with Cocoa, OS X, iOS or Xcode. It's just C++, and such things are covered to varying extents in many many C++ books. On Jan 30, 2014, at 2:35 PM, Rui Pacheco rui.pach...@gmail.com wrote: Is this documented somewhere? On 30 Jan 2014, at 22:26, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/scott_ribe%40elevated-dev.com This email sent to scott_r...@elevated-dev.com -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On Jan 30, 2014, at 1:35 PM, Rui Pacheco rui.pach...@gmail.com wrote: Is this documented somewhere? These are well-known problems but I don't know if there's authoritative documentation. (And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them.) Some good places to start reading: http://en.wikipedia.org/wiki/Fragile_binary_interface_problem http://en.wikipedia.org/wiki/Fragile_base_class Web searches for [fragile base class] will turn up zillions of other documents. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On 1/30/14, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful -- generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. --Jens And there's more... The compilers can do name mangling differently, so if you switch compilers or change the version of the same compiler, there is a chance that the binaries won't be compatible. And to re-iterate on what Jens just said, this kind of problem gets intertwined with the C++ standard library. This generally means you can't mix standard libraries and potentially different versions of the same standard library. Android is one of the best (worst?) examples of this. Android makes developers choose from 3-4 different compiler versions (multiple versions of gcc and clang), and then also makes you pick which C++ standard library you want to use (a minimal Android one, STLport, GNU, and potentially the new clang one). All of these are incompatible so you can't mix and match. 4x4 means you have 16 ways you can blow up your code. Static linking and only exposing extern C APIs can help in some cases, but more often than not, I've dealt with people/libraries/SDKs who don't understand this (but really need to) and they are not doing this which has forced me to work around all sorts of bad situations. And I've already encountered people who've run into the same problem on Mac/iOS with libstdc++ and libc++ because they didn't understand this. I've been fortunate that most of the stuff I've dealt with doesn't use C++ exceptions because I think that is another headache area. As for rules, I don't know any centralized place. The problem is that C++ is so complex and ABI stability is not a goal. In addition, some rules/behaviors are not obvious on how things will be impacted. One example issue that caught both me and Apple off-guard was during the 10.5 time frame, Apple redefined GLenum trying to get stuff 64-bit ready. Under 32-bit, the GLenum type was changed from long (in 10.4 and before) to int (in 10.5). Under 32-bit, sizeof(long) == sizeof(int) == 4-bytes. (In 64-bit, sizeof(long) == 8-bytes, sizeof(int) == 4-bytes) So in C 32-bit, binary compatibility is preserved and this is perfectly fine to do which is why the change was okayed. But under C++, even though both types are 4-bytes under 32-bits, the gcc/C++ name mangling treat int and long as fundamentally different types. Thus binary compatibility is broken if you try linking two pieces of code that use different types for GLenum. I suppose this is technically up to the compiler and its chosen name mangling, but the end result is that this made it impossible to ship a C++ framework binary that worked on both 10.4 and 10.5. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 5 Obj-C++
On Jan 30, 2014, at 2:14 PM, Jens Alfke j...@mooseyard.com wrote: And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them. I bet those same partisans would be the first to the barricades to complain about the performance downsides of any C++ runtime implementation that did try to improve ABI fragility. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 31 Jan 2014, at 2:39 am, glenn andreas gandr...@me.com wrote: One work around would be to implement doesNotRecognizeSelector: and ignore it there, and this would also make it future safe for when new private methods are added That sounded like a better solution. However, the documentation states: If you override this method, you must call super or raise an NSInvalidArgumentException exception at the end of your implementation. In other words, this method must not return normally; it must always result in an exception being thrown. So, cavalierly ignoring that advice, I swallow that one selector by doing nothing, and sure enough, NSDocument crashes. If I throw the exception as advised, it does not gain me anything. So right now, the private stub is the only solution unless, as you say, Apple allow genuine substitution of the class based solely on public API. That's not going to help for existing OS (nor for the foreseeable future, as I can imagine Apple are not going to move on this anytime soon, if ever). I will file a radar however. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 31 Jan 2014, at 11:30 am, Graham Cox graham@bigpond.com wrote: I will file a radar however. Radar: 15953047 --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On Jan 30, 2014, at 16:30 , Graham Cox graham@bigpond.com wrote: However, the documentation states: If you override this method, you must call super or raise an NSInvalidArgumentException exception at the end of your implementation. In other words, this method must not return normally; it must always result in an exception being thrown. Yeah, that wasn’t the right place to do it. The correct place sounds like ‘forwardInvocation:’, about which the documentation states: A forwardInvocation: method can act as a distribution center for unrecognized messages, parceling them out to different receivers. Or it can be a transfer station, sending all messages to the same destination. It can translate one message into another, or simply “swallow” some messages so there’s no response and no error. A forwardInvocation: method can also consolidate several messages into a single response. What forwardInvocation:does is up to the implementor. However, the opportunity it provides for linking objects in a forwarding chain opens up possibilities for program design. Alternatively and more simply, it seems, you could return nil from ‘forwardingTargetForSelector:’. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 31 Jan 2014, at 11:59 am, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jan 30, 2014, at 16:30 , Graham Cox graham@bigpond.com wrote:
However, the documentation states:
If you override this method, you must call super or raise an
NSInvalidArgumentException exception at the end of your implementation. In
other words, this method must not return normally; it must always result in
an exception being thrown.
Yeah, that wasn’t the right place to do it. The correct place sounds like
‘forwardInvocation:’, about which the documentation states:
A forwardInvocation: method can act as a distribution center for
unrecognized messages, parceling them out to different receivers. Or it can
be a transfer station, sending all messages to the same destination. It can
translate one message into another, or simply “swallow” some messages so
there’s no response and no error. A forwardInvocation: method can also
consolidate several messages into a single response. What
forwardInvocation:does is up to the implementor. However, the opportunity it
provides for linking objects in a forwarding chain opens up possibilities
for program design.
Alternatively and more simply, it seems, you could return nil from
‘forwardingTargetForSelector:’.
Hmmm. Unfortunately neither of these seem to do the trick.
First, -forwardingTargetForSelector: appears to return nil by default, so
returning nil for that particular case doesn't do anything special.
So, adding to the triumvirate of the other mechanism, I'm still getting the
doesNotRecogniseSelector exception. Here's what I've done:
- (BOOL)respondsToSelector:(SEL) aSelector
{
if( aSelector == @selector(_processEndOfEventNotification:))
return YES;
... [other code]
}
- (NSMethodSignature*) methodSignatureForSelector:(SEL) aSelector
{
if( aSelector == @selector(_processEndOfEventNotification:))
return [NSMethodSignature methodSignatureForSelector:aSelector];
...[other code]
}
- (void)forwardInvocation:(NSInvocation*)
invocation
{
if([invocation selector] == @selector(_processEndOfEventNotification:))
return;
...[other code]
}
The [other code] stuff is because as an undo manager these methods are also
used for capturing the invocations from client code when the UM is used in
non-proxy mode.
I'm fairly familiar with the -forwardInvocation: mechanism as I've used it here
in GCUndoManager and in other code as a general forwarding solution, so unless
I'm just being particularly dense today, it looks like that should work. And
yet it doesn't, so I'm missing someting here.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On Jan 30, 2014, at 17:42 , Graham Cox graham@bigpond.com wrote:
- (BOOL) respondsToSelector:(SEL) aSelector
{
if( aSelector == @selector(_processEndOfEventNotification:))
return YES;
... [other code]
}
Shouldn’t this return NO for that selector? The NSObject documentation didn’t
show this as part of the ‘forwardInvocation:” process. In fact, I wouldn’t be
surprised if returning YES *disables* the ‘forwardInvocation:’ path.
Incidentally, I originally envisaged that you would use NSStringFromSelector,
rather than using @selector. Since, we’re hypothesizing, there’s an automated
verification tool involved in the approval process, it might be that the mere
presence of a private @selector compiled into your executable might be grounds
for rejection.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 31 Jan 2014, at 12:57 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jan 30, 2014, at 17:42 , Graham Cox graham@bigpond.com wrote:
- (BOOL) respondsToSelector:(SEL) aSelector
{
if( aSelector == @selector(_processEndOfEventNotification:))
return YES;
... [other code]
}
Shouldn’t this return NO for that selector? The NSObject documentation didn’t
show this as part of the ‘forwardInvocation:” process. In fact, I wouldn’t be
surprised if returning YES *disables* the ‘forwardInvocation:’ path.
I don't think it should be NO. In other cases where I've used the forwarding
mechanism, I return YES if I can forward to another object, and that works just
fine.
The documentation states:
Note that if the receiver is able to forward aSelector messages to another
object, it will be able to respond to the message, albeit indirectly, even
though this method returns NO.
That implies that it doesn't actually matter what you return. To check anyway,
I changed it to NO and get the same result (unrecognised selector exception).
Setting breakpoints on my forwarding code, it's never called. I'm a bit puzzled
by this. So far, only the stub method approach seems to work.
Incidentally, I originally envisaged that you would use NSStringFromSelector,
rather than using @selector. Since, we’re hypothesizing, there’s an automated
verification tool involved in the approval process, it might be that the mere
presence of a private @selector compiled into your executable might be
grounds for rejection.
I usually do selector comparisons using == and @selector(...). I do that a fair
bit, so if it's wrong, I need to know. Aren't these just comparing the
addresses of C strings in a big global table?
It's hard to know what the automated tool does. All I can say for sure is that
I've never been rejected for this particular usage. I have fallen foul of using
other private API once upon a time in other places, so it's not that the code
hasn't been run through the tool. In that case I was calling a private method,
not just stubbing one out as here.
I believe this usage is safe (for now), but certainly if a cleaner solution can
be found that would be great, because I know a few people are using this code
and I do too, and would like to continue doing so. The thought of going back to
opaque NSUndoManager gives me the willies.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
On 2014 Jan 30, at 18:15, Graham Cox graham@bigpond.com wrote:
I believe this usage is safe (for now), but certainly if a cleaner solution
can be found that would be great,
Yesterday before I convinced myself that this was a non-issue, I tried the
following code:
+ (void)load {
SEL aSEL = NSSelectorFromString(@_processEndOfEventNotification:) ;
class_addMethod(self, aSEL, (IMP) doNothingIMP, @@:@);
}
void doNothingIMP(id self, SEL _cmd) {
NSLog(@Nothing doing!);
}
I tested it twice (saving a document), and it worked. That is, it logged
Nothing doing!” (3 times for each save) and raised no exceptions.
Note that I’m referencing _processEndOfEventNotification: as a string instead
of @selector(). I agree with Quincey’s implication that a string seems less
likely to raise App Store Hackles than a @selector(), but truly we’re all just
guessing.
On 2014 Jan 30, at 11:20, Kyle Sluder k...@ksluder.com wrote:
we've been rejected for merely *referencing* verboten selectors
What do you mean by that, Kyle? In a string? @selector()?
Y’all know that one could go further and obfuscate the string
@_processEndOfEventNotification:”, by breaking it up into several pieces,
reversing it, etc., and ultimately reconstructing it into a mutable string.
You have to be tricky enough to outwit the compiler, which will optimize out
anything which is too boneheaded. But it can be done.
Again, in my opinion, none of this is necessary because either the string or
the SEL is OK, as is Graham's original code. But I appreciate that preventing
the issue with trickery is way better than spending hours to “win” a legal
battle.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Preserving undo actions on deleted targets
I just noticed a couple mistakes in the code I threw in yesterday. Should be…
void doNothingIMP(id self, SEL _cmd, NSNotification* note) {
NSLog(@Nothing doing!);
}
+ (void)load {
SEL aSEL = NSSelectorFromString(@_processEndOfEventNotification:) ;
class_addMethod(self, aSEL, (IMP) doNothingIMP, v@:@);
}
but it works either way, with our without the mistakes :))
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Memory issue with ALAssetLibrary
When I use *ALAssetLibrary:assetForURL:resultBlock:failtureBlock *to retrieve full screen images from camera roll, the allocated memory never release until the app enters the background. My guess is the system keeps the cache for the images somewhere. Is there anyway to force the system to release these memory? While the app is entering the background, what kind of memory does the system automatically release? Thanks, Peng ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
What iOS device?
I want (for logging purposes only) to know the kind of iOS device being used. UIDevice model or localizedModel returns just iPhone, but I want something like iPhone 4s or iPad Air etc. NSProcessInfo physicalMemory can be used to distinguish between some models, but not all. Then there is sysctlbyname(hw.model,...) but this returns cryptic stuff like: J71AP or N94AP. Is there some official table to convert this to something more readable? (There is http://theiphonewiki.com/wiki/Model_definition_file but I would like something coming from Apple). What else can be done? Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: What iOS device?
I came across this the other day. Have you already looked at this? http://stackoverflow.com/questions/448162/determine-device-iphone-ipod-touch-with-iphone-sdk On Fri, Jan 31, 2014 at 1:19 AM, Gerriet M. Denkmann gerr...@mdenkmann.dewrote: I want (for logging purposes only) to know the kind of iOS device being used. UIDevice model or localizedModel returns just iPhone, but I want something like iPhone 4s or iPad Air etc. NSProcessInfo physicalMemory can be used to distinguish between some models, but not all. Then there is sysctlbyname(hw.model,...) but this returns cryptic stuff like: J71AP or N94AP. Is there some official table to convert this to something more readable? (There is http://theiphonewiki.com/wiki/Model_definition_file but I would like something coming from Apple). What else can be done? Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com This email sent to rejek...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: What iOS device?
On 31 Jan 2014, at 13:45, KappA rejek...@gmail.com wrote: I came across this the other day. Have you already looked at this? http://stackoverflow.com/questions/448162/determine-device-iphone-ipod-touch-with-iphone-sdk Thanks for this link. They are using hw.machine instead of hw.model which gives less cryptic results (like iPhone4,1 instead of N94AP). An official API would be better still. But this is something I can live with. Kind regards, Gerriet. On Fri, Jan 31, 2014 at 1:19 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I want (for logging purposes only) to know the kind of iOS device being used. UIDevice model or localizedModel returns just iPhone, but I want something like iPhone 4s or iPad Air etc. NSProcessInfo physicalMemory can be used to distinguish between some models, but not all. Then there is sysctlbyname(hw.model,...) but this returns cryptic stuff like: J71AP or N94AP. Is there some official table to convert this to something more readable? (There is http://theiphonewiki.com/wiki/Model_definition_file but I would like something coming from Apple). What else can be done? Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
