Re: Obj-C - your thoughts on hiding data members?
> On 28 Jan 2016, at 00:34, Alex Zavatone wrote: > > Ahh, just a little testing shows that well, if it’s not ASCII, it’s not going > to work, period. See? If it ain’t ASCII it ain’t Source Code! lol Dave ___ 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: Obj-C - your thoughts on hiding data members?
Apparently you can't in obj-c, but there appear to be a few tricks on the Swift side of things that are interesting and worth checking out. I saw examples of using option p as the pi character and using it in an assignment statement. But this is objective-c so you're 100% right. Sent from my iPhone > On Jan 28, 2016, at 6:14 AM, Dave wrote: > > >> On 28 Jan 2016, at 00:34, Alex Zavatone wrote: >> >> Ahh, just a little testing shows that well, if it’s not ASCII, it’s not >> going to work, period. > > See? If it ain’t ASCII it ain’t Source Code! lol > > Dave > > ___ > > 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/zav%40mac.com > > This email sent to z...@mac.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: Obj-C - your thoughts on hiding data members?
On 27 Jan 2016, at 12:30, Dave wrote: > I find the “_” very difficult to see and also I tend to think of it as “Apple > Reserved”, which I think it used to be? Still is, for *methods* so for selectors/properties. However, a single underscore is fine for instance variables backing a method, and in fact is the default when auto-synthesizing. And it's also not in violation of the C standard's rules about underscored and double-underscored identifiers (see e.g. here for a good summary of those http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier). Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://stacksmith.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: Obj-C - your thoughts on hiding data members?
> On Jan 28, 2016, at 03:14, Dave wrote: > > >> On 28 Jan 2016, at 00:34, Alex Zavatone wrote: >> >> Ahh, just a little testing shows that well, if it’s not ASCII, it’s not >> going to work, period. > > See? If it ain’t ASCII it ain’t Source Code! lol But that was originally said in response to Unicode in *comments*, not in identifiers. > > Dave > > ___ > > 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/clarkcox3%40gmail.com > > This email sent to clarkc...@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: Trying to understand a permissions failure when writing to ~/Desktop
Now that this is all resolved, the next question - why default to Desktop instead of Documents? I'd expect Documents, and I hate stuff that clutters up Desktop - one of the first things I do on new installs is change the default location of screen captures to Pictures. According to the sandboxing docs, I recall that for sandboxing, there are a certain set of locations where you can save files to without requiring user permission. Your ~/Documents folder is one of them. IIRC, all other locations require user confirmation to save the files. Try saving to the docs folder and/or trying writing to the desktop with sandboxing disabled. On Jan 27, 2016, at 8:42 PM, Graham Cox wrote: > I use -[NSData writeToURL:options:error] to write data to files in a location > generally chosen by the user. That works fine. > > The default location is ~/Desktop, if the user fails to choose anything, or > if the bookmark of the previously chosen location fails to resolve. However, > when I try to write the file I get an error 513, ‘you don’t have permission’, > underlying error 1, operation not permitted’. If the user chooses the Desktop > themselves using the Open panel, it works fine. > > The ~/Desktop permissions seem to be OK - I have readwrite permission on that > folder. > > So something is weird about the URL for ~/Desktop when I create it > programatically as opposed to what NSOpenPanel returns. Note this isn’t a > sandboxed app, so that shouldn’t come into it. > > I create the default URL thusly: > > NSURL* desktopURL = [[NSFileManager defaultManager] > URLForDirectory:NSDesktopDirectory inDomain:NSUserDomainMask > appropriateForURL:nil create:YES error:&error]; > > > I can’t see any obvious difference between the URL here and the one I get > from NSOpenPanel, but there must be one. > > > Any ideas what the problem could be 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: Trying to understand a permissions failure when writing to ~/Desktop
On Jan 28, 2016, at 1:08 AM, Graham Cox wrote: > >> On 28 Jan 2016, at 4:36 PM, Graham Cox wrote: >> >> Why would the OS think an app was sandboxed > > > OK, I think I found the problem. In Build Settings->Code Signing, the “Code > Signing Entitlements” was set to a .entitlements file which is actually > nothing to do with this product. I don’t know where it got that setting from > (I’ve never set it), but it’s wrong. I deleted it and now my app seems to be > happy to write where it wants to and doesn’t create a container. > > I’m supposing that the actual sandboxing entitlements are baked into the code > signature, not just read from a resource file, and that’s where the system > gets its info. > > So Alex, you were right ;) Happy to help. Thinking about how we solved this issue, I admit that I'm bit more spent than normal this week and only glazed over your "it's not a sandboxed app" part of your email, so yeah, bad form on my part. But… When looking at the situation, this screamed to me "well, that's just what Apple tells us a sandboxed app would do". In this case, you reexamined what you assumed was true based on how the app was set up and well, damn. It was an untentionally sandboxed app. As a lot of the reasons why we are here are to solve problems we are having in our Cocoa projects, what I like about this is it shows how we need to revisit our assumptions about what we think is true. I had to do the same thing with our iOS dev account's distribution cert earlier this week. I had assumed that it was the most recent and therefore good. Since I do all the distribution here, I assumed they all were mine and therefore in my keychain with a private key. Well, this one wasn't. Knowing when to revisit our assumptions and double check what we assume to be true can sure save time in a bunch of cases. Now, back to making push notifications work in dev, adhoc and prod on multiple targets. Multiple certificates for everyone! Take 2, they're cheap. > —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: Trying to understand a permissions failure when writing to ~/Desktop
> On Jan 27, 2016, at 22:08, Graham Cox wrote: > > >> On 28 Jan 2016, at 4:36 PM, Graham Cox wrote: >> >> Why would the OS think an app was sandboxed > > > OK, I think I found the problem. In Build Settings->Code Signing, the “Code > Signing Entitlements” was set to a .entitlements file which is actually > nothing to do with this product. I don’t know where it got that setting from > (I’ve never set it), but it’s wrong. I deleted it and now my app seems to be > happy to write where it wants to and doesn’t create a container. > > I’m supposing that the actual sandboxing entitlements are baked into the code > signature, not just read from a resource file, and that’s where the system > gets its info. Correct. If you want to see the entitlements a given app was signed with, you can use: codesign -d --entitlements - .app e.g. % codesign -d --entitlements - /Applications/Preview.app Executable=/Applications/Preview.app/Contents/MacOS/Preview ��qq� http://www.apple.com/DTDs/PropertyList-1.0.dtd";> com.apple.application-identifier com.apple.preview com.apple.developer.maps com.apple.developer.ubiquity-container-identifiers com.apple.Preview com.apple.private.bookkit com.apple.security.app-sandbox com.apple.security.application-groups com.apple.PreviewLegacySignaturesConversion com.apple.security.device.camera com.apple.security.files.downloads.read-write com.apple.security.files.user-selected.read-write com.apple.security.print com.apple.security.temporary-exception.mach-lookup.global-name com.apple.systemuiserver.screencapture keychain-access-groups com.apple.AnnotationKit > So Alex, you were right ;) > > —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/clarkcox3%40gmail.com > > This email sent to clarkc...@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: Trying to understand a permissions failure when writing to ~/Desktop
> On 29 Jan 2016, at 4:51 AM, Lee Ann Rucker wrote: > > Now that this is all resolved, the next question - why default to Desktop > instead of Documents? I'd expect Documents, and I hate stuff that clutters up > Desktop - one of the first things I do on new installs is change the default > location of screen captures to Pictures. I would agree with you entirely. However, some users are… often a little challenged, shall we say, to be polite? They use a feature of the app to write a bunch of files out, but for the life of them they can’t find where they went. So they complain that the app is “non intuitive” or somesuch. So defaulting to the desktop makes it easy for them to see where the files went, and if they have any savvyness at all, they’ll then change it to somewhere else. That said, this little epiosode made us rethink this anyway, since we’ll need it to work sandboxed as well as unsandboxed, so now we’ve defaulted to a folder we make inside ~/Documents, and also added a checkbox (on by default) that reveals the written files in the Finder so that they can’t really miss where they went. —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: The PID of an Application?
I would think so - it'd be pretty sh*tty if it did! (though I wonder what you're going to do with the 20% excess cast-iron?) On Jan 25, 2016, at 11:53 AM, Dave wrote: > Hi, > > Is the PID of an Application 120% cast-iron guaranteed not to change during > the Application’s life span? > > All the Best > Dave > > ___ > > 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/wsquires%40satx.rr.com > > This email sent to wsqui...@satx.rr.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: LGPL code in the Mac App Store?
IIRC, for Mac App Store apps, your app has to perform copy-protection checking itself (i.e, receipt checking); Apple specifically didn’t want to do that themselves so that when the inevitable crack appears in the wild, it doesn’t take out the whole app store - just the apps that the particular crack applies to. iOS, I believe, is different. (it’s been a while since I watched the relevant WWDC videos, though; and I haven’t had to implement such receipt checking myself yet, so take that with appropriate quantities of NaCl). ** I am not a lawyer, nor do I play one on TV, but… I **think** that this section (taken from v3.0 of the LGPL): > 4. Combined Works. > You may convey a Combined Work under terms of your choice that, taken > together, effectively do not restrict modification of the portions of the > Library contained in the Combined Work and reverse engineering for debugging > such modifications, if you also do each of the following: > > • a) Give prominent notice with each copy of the Combined Work that the > Library is used in it and that the Library and its use are covered by this > License. > • b) Accompany the Combined Work with a copy of the GNU GPL and this > license document. > • c) For a Combined Work that displays copyright notices during > execution, include the copyright notice for the Library among these notices, > as well as a reference directing the user to the copies of the GNU GPL and > this license document. > • d) Do one of the following: > • 0) Convey the Minimal Corresponding Source under the terms of > this License, and the Corresponding Application Code in a form suitable for, > and under terms that permit, the user to recombine or relink the Application > with a modified version of the Linked Version to produce a modified Combined > Work, in the manner specified by section 6 of the GNU GPL for conveying > Corresponding Source. > • 1) Use a suitable shared library mechanism for linking with > the Library. A suitable mechanism is one that (a) uses at run time a copy of > the Library already present on the user's computer system, and (b) will > operate properly with a modified version of the Library that is > interface-compatible with the Linked Version. > ...means that the user must be able to modify and re-compile the library, and re-link the executable in toto, and (assuming that no errors were made during the modification phase) have the combined product run. Any code-signing or DRM system that prevented this, would to my eye, seem to violate the LGPL. ** The current version of the Apple Developer Program Agreement states in section 3.3.2 that MAS apps can run plugins, so I would presume that a sandboxed, code-signed MAS app can, in fact, load them. I haven’t actually tried it though (my apps that have a plug-in system, although code-signed, aren’t sandboxed MAS apps). Also, now that I think about it… FWIW, wasn’t there a linker flag that told the system where to look for .dylibs? ___ 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: LGPL code in the Mac App Store?
> Another approach is to make a vanilla non-AppStore copy of the app available > to customers on request, if they want to replace the LGPL library. You’d just > need to find some way for the requestor to prove to you that they bought it > from the App Store. > > —Jens There have been developers who, upon removing their apps from the Mac App Store; had the replacement (non-MAS) version accept the MAS version’s receipt as valid licensing credentials; I suppose you could just post such a copy alongside the sources to the LGPL libraries, and that would allow for the LGPL’s requirements… (again, I’m not a lawyer)... ___ 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
