Re: Get file argument

[Jean-Daniel Dupas]

> Le 4 sept. 2016 à 20:48, Jens Alfke  a écrit :
> 
> 
>> On Sep 4, 2016, at 4:56 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> Is there also a way to get the file argument without having an NSApp,
>> i.e. can my program somehow obtain the file argument *before* creating
>> the NSApp object or is that impossible?
> 
> Perhaps through LaunchServices, or by implementing its own AppleEvent handler 
> for the ‘odoc’ event.
> 
> I do still feel that your attempt to build this 3rd-party code wrapper by 
> avoiding the normal Cocoa application/event loop is a mistake. You’re going 
> to run into one problem after another by going completely against the grain 
> of the framework like this.
> 

Whatever you do, you still have to pull the incoming events, else you Apple 
Event won’t be dispatched. As the canonical way to do that is though NSApp, I 
don’t now if this is possible.



___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 19:33, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
>> 
>> Le 24 août 2016 à 18:50, David Duncan <david.dun...@apple.com> a écrit :
>> 
>> 
>>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay <j...@szuhay.org> wrote:
>>> 
>>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>>> into a viewRect
>>> with 
>>> 
>>> CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>>> 
>>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>>> currently use 1024x1024
>>> but could easily make them 512x512 or 768x768.
>>> 
>>> So my question is, “Is is more efficient to draw the layer into a smaller 
>>> viewRect (down-sample) 
>>> or into a larger ViewRect (up-sample)?” 
>>> 
>>> Or does it even matter?
>> 
>> It depends on if quality or performance matters more.
>> 
>> Downsampling is generally more expensive because you have to deal with more 
>> data and so you become more easily bandwidth limited, but at the same time 
>> if you must resample an image, down sampling generally produces better 
>> quality. Upsampling is the opposite of all that.
>> 
>> So if performance matters more than quality, then you probably want to 
>> upsample.
>> 
> 
> Moreover, the performance will greatly depends the sampling algorithm you 
> choose. CGImage provide a couple of algorithms with different tradeoff (see 
> CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).

Just for the record, here is a link with different technics available on OS X 
to do that: 

http://nshipster.com/image-resizing/


> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 18:50, David Duncan  a écrit :
> 
> 
>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay  wrote:
>> 
>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>> into a viewRect
>> with 
>> 
>>  CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>> 
>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>> currently use 1024x1024
>> but could easily make them 512x512 or 768x768.
>> 
>> So my question is, “Is is more efficient to draw the layer into a smaller 
>> viewRect (down-sample) 
>> or into a larger ViewRect (up-sample)?” 
>> 
>> Or does it even matter?
> 
> It depends on if quality or performance matters more.
> 
> Downsampling is generally more expensive because you have to deal with more 
> data and so you become more easily bandwidth limited, but at the same time if 
> you must resample an image, down sampling generally produces better quality. 
> Upsampling is the opposite of all that.
> 
> So if performance matters more than quality, then you probably want to 
> upsample.
> 

Moreover, the performance will greatly depends the sampling algorithm you 
choose. CGImage provide a couple of algorithms with different tradeoff (see 
CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).


___

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: Class is implemented in both

[Jean-Daniel Dupas]

> Le 15 août 2016 à 18:02, Jens Alfke <j...@mooseyard.com> a écrit :
> 
> 
>> On Aug 15, 2016, at 11:34 AM, Jean-Daniel Dupas <mail...@xenonium.com 
>> <mailto:mail...@xenonium.com>> wrote:
>> 
>> No, You can have only one PCH per project. That said, you can define a 
>> second one that include the first one for your second project.
> 
> I think you meant to say you can have only one PCH per _target_.

Of course. Thanks for the correction. 

___

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: Class is implemented in both

[Jean-Daniel Dupas]

> Le 15 août 2016 à 15:27, Trygve Inda  a écrit :
> 
>> 
>>> On Aug 15, 2016, at 3:41 AM, Stephane Sudre  wrote:
>>> 
>>> . you could redefine the class name in the .pch of one project.
>> 
>> +1 — I’ve had to do this before, and it works fine. Just add
>> #define MyDisplayManager MyDisplayManager_PP
>> or whatever.
>> 
>> The caveat is that of course IB doesn’t read the PCH, so you’ll have to
>> manually change the class name in any nibs it may appear in.
>> 
>> —Jens
> 
> Both projects share a common pch. Is there a way to add a second pch to just
> one of them?

No, You can have only one PCH per project. That said, you can define a second 
one that include the first one for your second project.



___

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: undomanger performance

[Jean-Daniel Dupas]

> Le 1 mai 2016 à 01:42, Quincey Morris <quinceymor...@rivergatesoftware.com> a 
> écrit :
> 
> On Apr 30, 2016, at 12:49 , Jean-Daniel Dupas <mail...@xenonium.com 
> <mailto:mail...@xenonium.com>> wrote:
>> 
>> Maybe registering the changes is not executed immediately but deferred until 
>> the end of the current event loop cycle
> 
> There’s no “maybe” about it. By default, the undo manager groups all undo 
> actions registered between iterations of the run loop into a single top-level 
> group.

There is other way to group action that deferring the registration until the 
end of the event loop. That’s why I said maybe.


___

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: undomanger performance

[Jean-Daniel Dupas]

Just my 2 cents. 

Maybe registering the changes is not executed immediately but deferred until 
the end of the current event loop cycle, so the undo manager can group them 
into a single operation.

In such case, it would mean that what you think is the undo registration is 
just a call to schedule the real operation and is relatively fast, but the real 
works take much more time and is deferred until the end of the current event 
handling.

> Le 30 avr. 2016 à 21:39, Georg Seifert  a écrit :
> 
> Hi
> 
> My app deals with an object tree that can have millions of leaves. It is 
> possible to run an operation on all of them. Each will register its own 
> change with the undo manager. The hole operation might tale a few second (the 
> last line in the trace below). But after my operation is finished, there is 
> another operation triggered by the system that takes much longer than the 
> original task and it blocks the UI. It is directly linked to the undo 
> registration, if I disable it, this does not happen. 
> 
> Running Time  Self (ms)   Symbol Name
> 26258.0ms   81.3% 0,0 _dispatch_mgr_thread  0x4ef18d
> 26258.0ms   81.3% 0,0  _dispatch_mgr_thread
> 26258.0ms   81.3% 0,0   _dispatch_mgr_invoke
> 26250.0ms   81.2% 0,0_dispatch_mgr_queue_drain
> 26248.0ms   81.2% 48,0_dispatch_queue_drain
> 26168.0ms   81.0% 1,0  _dispatch_client_callout
> 26141.0ms   80.9% 97,0  _dispatch_source_set_timer3
> 25561.0ms   79.1% 25561,0_dispatch_timers_update
> 481.0ms1.4%   8,0_dispatch_resume_slow
> 2.0ms0.0% 2,0_dispatch_queue_wakeup
> 8.0ms0.0% 0,0   free
> 6.0ms0.0% 6,0   dispatch_release
> 6.0ms0.0% 6,0   _os_object_release
> 4.0ms0.0% 4,0   dispatch_resume
> 1.0ms0.0% 1,0   nano_free_definite_size
> 1.0ms0.0% 0,0   
> 12.0ms0.0%12,0 OSAtomicEnqueue
> 9.0ms0.0% 4,0  gcd_queue_item_complete_hook
> 6.0ms0.0% 1,0  _dispatch_continuation_free_to_cache_limit
> 3.0ms0.0% 2,0  
> _dispatch_introspection_queue_item_dequeue_hook
> 1.0ms0.0% 1,0  DYLD-STUB$$free
> 1.0ms0.0% 0,0  
> 2.0ms0.0% 2,0 _dispatch_introspection_callout_return
> 7.0ms0.0% 6,0_dispatch_cache_cleanup
> 1.0ms0.0% 0,0_dispatch_timers_run
> 4162.0ms   12.8%  0,0 Main Thread  0x4ef176
> 
> Does anyone has an idea what’s going on?
> 
> Thanks
> Georg Seifert
> Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Value of the MAC_OS_X_VERSION_MIN_REQUIRED macro

[Jean-Daniel Dupas]

It is unsafe to use availability conditional in headers.
You can’t guarantee that the framework client will has the same settings that 
what was used to compile the framework.

That said, if you want to use weak when compiling for ARC and assign otherwise, 
you can just use #if __has_feature(objc_arc)


> Le 20 févr. 2016 à 19:00, Ilya Kulakov  a écrit :
> 
> Hi,
> 
> I would like to add support for ARC's weaks to my framework that supports Mac 
> OS X down to 10.6
> 
> My current solution is:
> 
> #if defined(MAC_OS_X_VERSION_MIN_REQUIRED) && MAC_OS_X_VERSION_MIN_REQUIRED 
> >= 1070
>@property (weak) NSObject *delegate;
> #else
>@property (assign) NSObject *delegate;
> #endif
> 
> However, the value of MAC_OS_X_VERSION_MIN_REQUIRED is always 1070 despite of 
> set Deployment Target (I compile on 10.11).
> Why is it so and what solution could I use in my situation?
> 
> Best Regards,
> Ilya Kulakov
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Can an NSArray ever have a count of -1?

[Jean-Daniel Dupas]

> Le 20 févr. 2016 à 07:28, Quincey Morris 
>  a écrit :
> 
> On Feb 19, 2016, at 22:14 , Gerriet M. Denkmann  wrote:
>> 
>> Is there (yet) a Swift version of ‘[NSString stringWithFormat: “%08lx”, 
>> (someCast) someValue]’ ?
> 
> No, and yes, and no, and yes.
> 
> There is currently AFAIK no such native formatting syntax in Swift print 
> statements, so “no”.
> 
> But you can of course use ‘String (format: “%08lx”, someCast (someValue))’. 
> This isn’t actually cheating, because Swift has its own implementation of the 
> entire NSString API. There’s no bridging to NSString objects involved in 
> these functions, so “yes”.
> 
> But you can’t *use* this API in Swift unless you import Foundation. Without 
> the import, Swift will pretend it doesn’t have those String APIs, though it 
> really does, so “no”.
> 
> But starting with Swift 3, later this year, Foundation will migrate natively 
> into Swift — for all supported Swift platforms, such as Linux — so I assume 
> there will be some kind of native String formatting syntax, so “yes”, though 
> whether it will use the same format strings as Cocoa, I don’t know.


Even if swift is planning to provide a Foundation framework, one of the strong 
requirement is that it must be source compatible with the Apple Foundation, as 
that is the one that will be used on Apple platforms. So if it does not behave 
like NSString, it should be considered a bug.


___

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: Can an NSArray ever have a count of -1?

[Jean-Daniel Dupas]

> Le 19 févr. 2016 à 22:29, Jens Alfke  a écrit :
> 
> 
>> On Feb 19, 2016, at 1:17 PM, Jim Adams  wrote:
>> 
>>   SLogInfo(@"Starting csi %ld count %d", csi, sortedEvents.count);
>> 
>> In the console I see:
>> INFO: Starting csi -1 count -1
>> The very next line crashes when the sortedEvents are accessed. What could 
>> cause the array to have a -1 count?
> 
> You’re using the wrong format strings for both of those parameters.
> 
> csi is 64-bit so you need %lld. The formatter sees %ld and thinks it’s 32-bit 
> not 64-bit, so it skips the wrong amount of space on the stack when going to 
> the next parameter, which is why you then get a bogus value for the count.
> 
> Also, NSArray.count is of type NSUInteger, which is unsigned, and has 
> different sizes on different platforms. The right format specifier is either 
> %lu (in a 32-bit app) or %llu (in 64-bit).

Not exactly. %d is for 32 bit signed integer, but %ld is for signed long, and 
so is the right formatter for NSInteger value (which is a typedef alias of 
long) and 64 bit integer on 64 bit platform.

%lld is for signed long long and is the same as long for most platform.




___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

> Le 11 févr. 2016 à 02:16, Ben Kennedy  a écrit :
> 
>> On 10 Feb 2016, at 5:00 pm, Gary L. Wade  
>> wrote:
>> 
>> You've made my point. None of my friends would even bother with looking at 
>> the certificate for his site (assuming that's his site from his email 
>> address) and move on. At worst, they'd call me and I'd say don't go there 
>> since I don't want them to screenshot that and text it to me to figure it 
>> out.
> 
> No, you are misunderstanding me.  My point is that it may not be valid to 
> assume the web server at 213.186.33.24 (to which xenonium.com resolves) will 
> answer to HTTPS with a cert for "xenonium.com".
> 
> For example, https://213.186.33.24 presents the same "hostname mismatch" 
> alert, because the cert is not named for "213.186.33.24".
> 
> Conduct the same exercise for any A record returned for www.apple.com, and 
> you'll also get this result.  Completely expected.
> 
> Now, if Jean-Daniel has stated definitively that https://xenonium.com is 
> expected to serve up a matching certificate, you have an argument I would 
> agree with.  But for all we know (unless I've missed it), he's serving his 
> material at https://ssl13.ovh.net.
> 
> b

Sorry for the confusion. I’m not taking about that web site. It is on a 
mutualized hosting platform that forces me to pay to install a certificate that 
match my hostname.

If I need to distribute secure content from that site, I can use the 
alternative access URL https://ssl13.ovh.net/~xenonium/ 
.





___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

> Le 10 févr. 2016 à 05:48, Trygve Inda  a écrit :
> 
>> If your hosting provider still charges an arm and a leg for SSL, switch.
> 
> I need SSL for multiple subdomains. My host (Pair Networks) charges $449/yr
> for such a certificate. That seems really expensive. What are others paying
> for this? I have been very happy with Pair as we run a complex server setup
> with multiple cron jobs, custom C programs etc.
> 

I pay 0$ and can have as many domains as I want on my certificactes. I’m using 
let'sencrypt  for all my servers. It requires some setup but it’s free and 
works very well.

https://letsencrypt.org 

> I also see no way to add an SSL certificate to a CNAME'd site at Amazon S3:
> 
> download.xericdesign.com CNAME
> s3.amazonaws.com/download.xericdesign.com/
> 
> Trygve
> 
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

OK. I did watch the POC and it appears this is not in the update process, but 
in the check for update that the attack occurs.

> Le 9 févr. 2016 à 23:27, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
> I agree. I can’t see how that can work with a properly configured Sparkle, 
> that is an App that accepts only properly signed update.
> 
> 
>> Le 9 févr. 2016 à 23:22, Graham Cox <graham@bigpond.com> a écrit :
>> 
>> Thanks for the heads-up Jens.
>> 
>> Is it enough to change the SUFeedURL to https (if your server supports it, 
>> which ours does), or does it also require the library to be updated? The 
>> comment you link doesn’t clarify it for me - it mentions WebView, but I’m 
>> not clear about how Sparkle is using Webview - wouldn’t it just request the 
>> appcast directly, parse it and then download the update notes if it finds an 
>> update BEFORE opening a webview? Other than displaying the update notes I 
>> don’t see why Sparkle would open a Webview, but my understanding of how it 
>> works could well be wrong.
>> 
>> There’s another thing too. Even if the appcast feed were compromised and an 
>> “update” containing malware were injected, it would still have to be signed 
>> correctly using the developers private key which Sparkle checks before 
>> installing the update. So even if it got that far it would surely fail at 
>> that step?
>> 
>> —Graham
>> 
>> 
>> 
>>> On 10 Feb 2016, at 8:10 AM, Jens Alfke <j...@mooseyard.com> wrote:
>>> 
>>> Ars Technica has an article today about a vulnerability in the Sparkle 
>>> auto-update framework, which can allow an attacker to hijack an app update 
>>> check to install malware on the user’s Mac:
>>> 
>>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
>>> 
>>> The clearest description of the bug is in this comment:
>>> 
>>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/?comments=1=30615427#comment-30615427
>>> 
>>> Basically: If your app uses a version of Sparkle older than 1.13 — like 
>>> every single Sparkle-using app on my computer :( — and the updates are 
>>> delivered over a non-HTTPS connection, you’re vulnerable (or rather, your 
>>> users are.)
>>> 
>>> The attack’s not trivial: it requires someone to tamper with the appcast 
>>> RSS feed being received by Sparkle, at the time that it checks for an 
>>> update. Most likely this would be by poisoning the DNS on a shared router 
>>> and pointing your domain to their server; or else they could compromise the 
>>> router to sniff the HTTP traffic and inject the payload into the stream.
>>> 
>>> The best fix is to upgrade your server to use HTTPS. If your hosting 
>>> provider still charges an arm and a leg for SSL, switch.
>>> In addition (or as the second-best fix if you can’t go SSL), download the 
>>> latest Sparkle and update your app project to use it.
>>> 
>>> —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/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

I agree. I can’t see how that can work with a properly configured Sparkle, that 
is an App that accepts only properly signed update.


> Le 9 févr. 2016 à 23:22, Graham Cox  a écrit :
> 
> Thanks for the heads-up Jens.
> 
> Is it enough to change the SUFeedURL to https (if your server supports it, 
> which ours does), or does it also require the library to be updated? The 
> comment you link doesn’t clarify it for me - it mentions WebView, but I’m not 
> clear about how Sparkle is using Webview - wouldn’t it just request the 
> appcast directly, parse it and then download the update notes if it finds an 
> update BEFORE opening a webview? Other than displaying the update notes I 
> don’t see why Sparkle would open a Webview, but my understanding of how it 
> works could well be wrong.
> 
> There’s another thing too. Even if the appcast feed were compromised and an 
> “update” containing malware were injected, it would still have to be signed 
> correctly using the developers private key which Sparkle checks before 
> installing the update. So even if it got that far it would surely fail at 
> that step?
> 
> —Graham
> 
> 
> 
>> On 10 Feb 2016, at 8:10 AM, Jens Alfke  wrote:
>> 
>> Ars Technica has an article today about a vulnerability in the Sparkle 
>> auto-update framework, which can allow an attacker to hijack an app update 
>> check to install malware on the user’s Mac:
>>  
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
>> 
>> The clearest description of the bug is in this comment:
>>  
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/?comments=1=30615427#comment-30615427
>> 
>> Basically: If your app uses a version of Sparkle older than 1.13 — like 
>> every single Sparkle-using app on my computer :( — and the updates are 
>> delivered over a non-HTTPS connection, you’re vulnerable (or rather, your 
>> users are.)
>> 
>> The attack’s not trivial: it requires someone to tamper with the appcast RSS 
>> feed being received by Sparkle, at the time that it checks for an update. 
>> Most likely this would be by poisoning the DNS on a shared router and 
>> pointing your domain to their server; or else they could compromise the 
>> router to sniff the HTTP traffic and inject the payload into the stream.
>> 
>> The best fix is to upgrade your server to use HTTPS. If your hosting 
>> provider still charges an arm and a leg for SSL, switch.
>> In addition (or as the second-best fix if you can’t go SSL), download the 
>> latest Sparkle and update your app project to use it.
>> 
>> —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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

Maybe an issue cause you use __weak reference which zeroed for some reason.
Can you try to use __unsafe_unretained instead and see what happen ?

> Le 5 févr. 2016 à 14:46, Dave <d...@looktowindward.com> a écrit :
> 
> 
>> On 5 Feb 2016, at 13:34, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>> 
>> And obviously, you also add - encodeWithCoder: and -initWithCoder: methods 
>> in your custom classes.
> 
> Yes, see my other thread, it decodes all the other fields but not the (weak) 
> back links get set to nil most of the time…….
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

That is your need, not your problem. 

To archive an object graph (cyclic or not), you just do [NSKeyedArchiver 
archiveRootObject:graph toFile:@"myfile"];



> Le 5 févr. 2016 à 14:28, Dave <d...@looktowindward.com> a écrit :
> 
> Hi,
> 
> See my other thread on this list which explains it fully  - 
> "Archive/Unarchive Problem/Question?”.
> 
> Basically I need to save/restore a Network of Custom Objects…..
> 
> All the Best
> Dave
> 
>> On 5 Feb 2016, at 13:18, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>> 
>> You don’t tell use what is your problem. You can perfectly encode any 
>> structure using Keyed archivers (whether there is cycles and backlinks).
>> 
>>> Le 5 févr. 2016 à 14:13, Dave <d...@looktowindward.com> a écrit :
>>> 
>>> Hi,
>>> 
>>> I’m having problems with Back Links when Archiving/Unarchiving an Object. I 
>>> found the text below at:
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
>>> 
>>> 
>>> Root Object
>>> 
>>> An object graph is not necessarily a simple tree structure. Two objects can 
>>> contain references to each other, for example, creating a cycle. If a coder 
>>> follows every link and blindly encodes each object it encounters, this 
>>> circular reference will generate an infinite loop in the coder. Also, a 
>>> single object can be referenced by several other objects. The coder must be 
>>> able to recognize and handle multiple and circular references so that it 
>>> does not encode more than one copy of each object, but still regenerate all 
>>> the references when decoding.
>>> To solve this problem, NSCoder introduces the concept of a root object. The 
>>> root object is the starting point of an object graph. To encode an object 
>>> graph, you invoke the NSCoder method encodeRootObject:, passing in the 
>>> first object to encode. Every object encoded within the context of this 
>>> invocation is tracked. If the coder is asked to encode an object more than 
>>> once, the coder encodes a reference to the first encoding instead of 
>>> encoding the object again.
>>> 
>>> NSCoder does not implement support for root objects; NSCoder’s 
>>> implementation of encodeRootObject: simply encodes the object by invoking 
>>> encodeObject:. It is the responsibility of its concrete subclasses to keep 
>>> track of multiple references to objects, thus preserving the structure of 
>>> any object graphs.
>>> 
>>> The last paragraph seems pertinent to my problem, so do I need to do 
>>> something special for “weak”, back links in order to “keep track of 
>>> multiple references to objects”? If so could some please tell me how to do 
>>> this? I’m really struggling to get something out the door and was advised 
>>> to use the Keyed Archiver/Unarchiver as it would be the simplest 
>>> implementation……
>>> 
>>> Is this any other documentation or sample code available? There are plenty 
>>> of trivial examples out there, no nothing I can find that works for weak 
>>> back links, although according to all the Apple Blurb I can find, it is 
>>> possible, they just don’t tell you how to do it that I can find!
>>> 
>>> Thanks in Advance for Any Help
>>> 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/mailing%40xenonium.com
>>> 
>>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

And obviously, you also add - encodeWithCoder: and -initWithCoder: methods in 
your custom classes.

> Le 5 févr. 2016 à 14:33, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
> That is your need, not your problem. 
> 
> To archive an object graph (cyclic or not), you just do [NSKeyedArchiver 
> archiveRootObject:graph toFile:@"myfile"];
> 
> 
> 
>> Le 5 févr. 2016 à 14:28, Dave <d...@looktowindward.com> a écrit :
>> 
>> Hi,
>> 
>> See my other thread on this list which explains it fully  - 
>> "Archive/Unarchive Problem/Question?”.
>> 
>> Basically I need to save/restore a Network of Custom Objects…..
>> 
>> All the Best
>> Dave
>> 
>>> On 5 Feb 2016, at 13:18, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>>> 
>>> You don’t tell use what is your problem. You can perfectly encode any 
>>> structure using Keyed archivers (whether there is cycles and backlinks).
>>> 
>>>> Le 5 févr. 2016 à 14:13, Dave <d...@looktowindward.com> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> I’m having problems with Back Links when Archiving/Unarchiving an Object. 
>>>> I found the text below at:
>>>> 
>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
>>>> 
>>>> 
>>>> Root Object
>>>> 
>>>> An object graph is not necessarily a simple tree structure. Two objects 
>>>> can contain references to each other, for example, creating a cycle. If a 
>>>> coder follows every link and blindly encodes each object it encounters, 
>>>> this circular reference will generate an infinite loop in the coder. Also, 
>>>> a single object can be referenced by several other objects. The coder must 
>>>> be able to recognize and handle multiple and circular references so that 
>>>> it does not encode more than one copy of each object, but still regenerate 
>>>> all the references when decoding.
>>>> To solve this problem, NSCoder introduces the concept of a root object. 
>>>> The root object is the starting point of an object graph. To encode an 
>>>> object graph, you invoke the NSCoder method encodeRootObject:, passing in 
>>>> the first object to encode. Every object encoded within the context of 
>>>> this invocation is tracked. If the coder is asked to encode an object more 
>>>> than once, the coder encodes a reference to the first encoding instead of 
>>>> encoding the object again.
>>>> 
>>>> NSCoder does not implement support for root objects; NSCoder’s 
>>>> implementation of encodeRootObject: simply encodes the object by invoking 
>>>> encodeObject:. It is the responsibility of its concrete subclasses to keep 
>>>> track of multiple references to objects, thus preserving the structure of 
>>>> any object graphs.
>>>> 
>>>> The last paragraph seems pertinent to my problem, so do I need to do 
>>>> something special for “weak”, back links in order to “keep track of 
>>>> multiple references to objects”? If so could some please tell me how to do 
>>>> this? I’m really struggling to get something out the door and was advised 
>>>> to use the Keyed Archiver/Unarchiver as it would be the simplest 
>>>> implementation……
>>>> 
>>>> Is this any other documentation or sample code available? There are plenty 
>>>> of trivial examples out there, no nothing I can find that works for weak 
>>>> back links, although according to all the Apple Blurb I can find, it is 
>>>> possible, they just don’t tell you how to do it that I can find!
>>>> 
>>>> Thanks in Advance for Any Help
>>>> 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/mailing%40xenonium.com
>>>> 
>>>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

You don’t tell use what is your problem. You can perfectly encode any structure 
using Keyed archivers (whether there is cycles and backlinks).

> Le 5 févr. 2016 à 14:13, Dave  a écrit :
> 
> Hi,
> 
> I’m having problems with Back Links when Archiving/Unarchiving an Object. I 
> found the text below at:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
> 
> 
> Root Object
> 
> An object graph is not necessarily a simple tree structure. Two objects can 
> contain references to each other, for example, creating a cycle. If a coder 
> follows every link and blindly encodes each object it encounters, this 
> circular reference will generate an infinite loop in the coder. Also, a 
> single object can be referenced by several other objects. The coder must be 
> able to recognize and handle multiple and circular references so that it does 
> not encode more than one copy of each object, but still regenerate all the 
> references when decoding.
> To solve this problem, NSCoder introduces the concept of a root object. The 
> root object is the starting point of an object graph. To encode an object 
> graph, you invoke the NSCoder method encodeRootObject:, passing in the first 
> object to encode. Every object encoded within the context of this invocation 
> is tracked. If the coder is asked to encode an object more than once, the 
> coder encodes a reference to the first encoding instead of encoding the 
> object again.
> 
> NSCoder does not implement support for root objects; NSCoder’s implementation 
> of encodeRootObject: simply encodes the object by invoking encodeObject:. It 
> is the responsibility of its concrete subclasses to keep track of multiple 
> references to objects, thus preserving the structure of any object graphs.
> 
> The last paragraph seems pertinent to my problem, so do I need to do 
> something special for “weak”, back links in order to “keep track of multiple 
> references to objects”? If so could some please tell me how to do this? I’m 
> really struggling to get something out the door and was advised to use the 
> Keyed Archiver/Unarchiver as it would be the simplest implementation……
> 
> Is this any other documentation or sample code available? There are plenty of 
> trivial examples out there, no nothing I can find that works for weak back 
> links, although according to all the Apple Blurb I can find, it is possible, 
> they just don’t tell you how to do it that I can find!
> 
> Thanks in Advance for Any Help
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: View-based NSTableView and ending editing with "return"

[Jean-Daniel Dupas]

> Le 24 janv. 2016 à 09:51, Arved von Brasch  a écrit :
> 
> Hello list,
> 
> After putting it off for too long, I’m migrating to view-based NSTableViews.  
> I’ve worked through most of the conversion problems I’ve had, and am 
> generally pretty happy.  There is, however, one problem I haven’t been able 
> to solve.
> 
> I have a NSButton in the same window as my table.  The button has “return” as 
> a key-equavlent.  This worked fine with a cell-based NSTableView, but with a 
> view-based table, ending editing in the table with a “return” key press 
> always triggers the NSButton as well.  This is obviously undesirable 
> behaviour, but I can’t work out an obvious place to intercept the “return” 
> key press and discard it.
> 
> My attempts thus far have been messing around with a subclass of the 
> NSTableView. I’m thinking this is probably wrong, and I should be subclassing 
> the NSTextField instead, but my experience with such things is minimal, and 
> my Google-Fu has failed me in finding someone else with a similar problem.  
> So, my question is if anyone can give me a pointer to how to go about this.
> 
> Thanks in advance,
> Arved

You may try too use the TextField delegate methods, especially:

- (BOOL)control:(NSControl 

 *)control textView:(NSTextView 

 *)textView doCommandBySelector:(SEL)command

You can detect that this is a return if the selector match 
@selector(insertNewline:), and in such case, return true to inhibit the event.

Return false in all other cases.


___

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 joys of people using valueForKey to get objects out of a dictionary.

[Jean-Daniel Dupas]

> Le 10 nov. 2015 à 19:52, Alex Zavatone  a écrit :
> 
> 
> On Nov 10, 2015, at 12:35 PM, Greg Weston wrote:
> 
>> 
>> 
>>> It's been about 4 or 5 years since I made this mistake but I've just seen a 
>>> massive swath of code where every access of a dictionary object is using 
>>> valueForKey instead of objectForKey.
>>> 
>>> I've got a few examples of why this is a "really bad idea"™, 
>> 
>> I would like to see these examples, because I can't think of any reason why 
>> it should be a bad idea. Per the documentation, it's a wrapper around 
>> objectForKey: with one special case.
> 
> I'm looking at a large chunk of code that uses all dictionary object access 
> using valueForKey.  All of it is wrapped within @try/@catch blocks, implying 
> that the original authors ran into lots of exceptions being raised and they 
> didn't know why.
> 
> My main inclination for using objectForKey over valueForKey to access the 
> object for a key within a dictionary is that objectForKey is actually a 
> dictionary method while valueForKey is a method declared in the 
> NSKeyValueCoding.h file.
> 
> I did find this example on SO yesterday, and this important issue with 
> regards to missing keys.
> 
> http://stackoverflow.com/questions/1062183/difference-between-objectforkey-and-valueforkey
> 
> 
> Here's a great reason to use objectForKey: wherever possible instead of 
> valueForKey: - valueForKey: with an unknown key will throw 
> NSUnknownKeyException saying "this class is not key value coding-compliant 
> for the key ".
> 
> But according to Charles and Mike comment and my testing, it doesn't - in 
> some cases.
> 
> Take this code on iOS 9:
> NSDictionary *myStuff = [NSDictionary dictionaryWithObjectsAndKeys:@"a", 
> @"A", nil];
> 
> po myStuff 
> {
>A = a;
> }
> 
> po [myStuff valueForKey:@"a"];
> nil
> 
> // Just as Charles and Mike mentioned
> 
> po [myStuff objectForKey:@"a"];
> 
> nil
> // Just as we expect
> 
> But if we remove the @ (obviously unintended), valueForKey causes an 
> EXC_BAD_ACCES while objectForKey reports "error: string literal must be 
> prefixed by '@'".
> 
> And David does state that whether an exception is thrown or not is 
> implementation dependent.  
> 
> From what Greg showed and in my testing, valueForKey will crater if you use 
> an @ in your key name, something I haven't seen until I tested it.
> 
> If we're not using @ within our key names, I haven't seen much here that 
> indicates why it's dangerous, nor why the code I'm looking at that uses 
> valueForKey on dictionaries needs to be wrapped in @try/@catch statements.
> 
> 
> For what we're doing on a daily basis, if we're not using @ within our keys, 
> I still can't see anything concrete besides "objectForKey is an NSDictionary 
> method" while "valueForKey is a KVO method".
> 
> Hmm.  
> 
> Thanks to all for their input on this.  
> 
> - Alex Zavatone
> 

If you don’t want to have to ask yourself if it should be valueForKey or 
objectForKey, just use the new bracket syntax to access dictionary. 

NSDictionary *myStuff = @{ @"A" : @"a" };

myStuff[@"a"]



___

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: API to determine status of System Integrity Protection?

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 01:33, Ed Wynne  a écrit :
> 
> 
> On Sep 13, 2015, at 5:47 PM, Stephane Sudre  wrote:
> That document doesn't mention an API…
 Hence, since that is the current documentation, my conclusion : “Don’t 
 think so”.
>>> There is an API. Much like with sandboxing it just may not be public, which 
>>> means it is inappropriate for discussion here. I’m not sure why Apple 
>>> considers this kind of thing off limits, but that is inappropriate for 
>>> discussion here as well.
>> 
>> I must be missing something but why should there be an API?
> 
> There are many reasons. For example, writing to the areas SIP protects 
> typically requires authorization. Not offering the user an impossible action 
> is a much better UX than letting them go through the trouble of 
> authenticating only to have it fail anyway.

No trying to write in a protected area in the first place is even better. You 
don’t need to check, just don’t do it.

> 
>> - determining whether SIP is on requires to check whether the running
>> OS on 10.11 or later.
> 
> This check is not sufficient since SIP can be disabled.
> 
>> Also it could done by parsing the output of $
>> csrutil status but this would assume the output format will not change
>> in the future.
> 
> Exactly, which makes this a bad option.
> 
>> - determining whether you can write to a file or folder can be done
>> with the usual BSD, Cocoa APIs, can't it?
> 
> Yes and no. Not having the beta (er, GM seed) handy to check, I honestly 
> don’t know if the R/W file system permissions are reported differently when 
> SIP is present and enabled. Based on how sandboxing operates, I would assume 
> they are not.
> 
> But that isn’t to say some things won’t be detectably different, which was 
> the point of my suggestion about secondary checks. They might be possible, 
> but they are still a bad option since they usually fall into the category of 
> undocumented side effects. 
> 
>> - knowing which parts of the file hierarchy are protected is covered
>> by the documentation (Interestingly I've just discovered that
>> /Applications/Utilities is a no trespassing area).
> 
> 
> Except they aren’t protected when SIP is disabled, which was the point of the 
> OP’s question.
> 
> -Ed
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Identifying a specific Mac model

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 12:16, sqwarqDev  a écrit :
> 
> 
> On 14 Sep 2015, at 01:09, John Daniel  wrote:
> 
>> 
>> MacBook8,1 covers all colours of the new MacBook.
>> I am trying to differentiate the silver, from the space grey, from the gold.
> 
> Since the machines are physically identical save the paint job, I don’t think 
> anything like sysctl or any other hardware identifier is going to help you. 
> The only difference I’d imagine between a silver and gold MB would be the 
> catalogue/product number. For example, Mactracker has the following order 
> numbers for the 2015 MB:
> 
>> MF855LL/A (1.1 GHz with 256 GB storage, Silver) MK4M2LL/A (1.1 GHz with 256 
>> GB storage, Gold) MJY32LL/A (1.1 GHz with 256 GB storage, Space Gray) 
>> MF865LL/A (1.2 GHz with 512 GB storage, Silver) MK4N2LL/A (1.2 GHz with 512 
>> GB storage, Gold) MJY42LL/A (1.2 GHz with 512 GB storage, Space Gray)
> 
> The chances of this being coded into the machine itself I’d imagine are zero. 
> If that’s right, then the best you can do is ask your user to enter that 
> information in order to display the correct icon. In lieu of that, your only 
> option is to display a generic icon for the model identifier that you find in 
> the usual way(s).
> 


Apple used to display the right color for iPod icons, why wouldn’t they do it 
too for new MacBook network icon. Especially as the three variants are present 
in the System icons. I’m pretty sure the color is coded somewhere in the 
machine.
___

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: Identifying a specific Mac model

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 15:53, John Daniel  a 
> écrit :
> 
> Thanks for the responses. Unfortunately, Apple is way ahead of all of us.
> 
> The “Model Identifier” (MacBook8,1 et al.) is not sufficient to identify a 
> particular model. It only identifies general families of models. All you have 
> to do is go to My OWC (http://eshop.macsales.com/MyOWC/ 
> ), pick MacBook Pro, and look at the 
> options. 
> 
> The system images are where they should be. I don’t understand Apple’s 
> reasoning, but that is where Apple wants them. 
> 
> I don’t know if Apple even tracks the colour of the retina MacBooks. I don’t 
> have one myself. I haven’t been able to find a serial number online. The 
> serial number generator scripts posted online don’t generate valid serial 
> numbers for this model. 
> 
> Scraping the Apple self-service warranty page might work, but I don’t have 
> any MacBook serial numbers for testing. I really don’t want to parse HTML. 
> Even so, people seem to treat serial numbers as personal information and 
> might freak out if I start sending them over the internet. If I had a few 
> serial numbers for testing, I would know more - or at least something.
> 
> I do extract the last 4 characters and send them to Apple’s support web 
> services to get the “marketing name” like "MacBook (Retina, 12-inch, Early 
> 2015)”. But those names don’t seem to include colour. I know of a few 
> different queries for Apple’s services for technical specifications, possible 
> memory upgrades, OS name, and this marketing name. This is a true web service 
> that returns parseable XML. I don’t know if there is any query that will give 
> me the machine icon.
> 

If you just want to current machine icon, just use + [NSImage 
imageNamed:NSImageNameComputer]



___

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: NSManagedObject, NSString property retain vs copy

[Jean-Daniel Dupas]

 Le 30 juil. 2015 à 18:26, Fritz Anderson fri...@manoverboard.org a écrit :
 
 On 30 Jul 2015, at 11:03 AM, Trygve Inda cocoa...@xericdesign.com wrote:
 
 It seems Apple is using retain rather than copy for NSString properties in
 an NSManagedObject subclass.
 
 I was always under the impression that copy should be used for NSString, so
 why the retain??
 
 For an immutable string, -copy is implemented as a -retain. -copy is a guard 
 against the receiver’s relying on the unchanging contents of a string whose 
 contents can be changed. If the contents cannot in fact be changed, there’s 
 no point in allocating new memory and copying the bytes into it.
 
 It’s an implementation detail; what makes you believe it makes a difference?

If it is in the property declaration, it is not an implementation detail, it is 
part of the public API.

And as the receiver can’t guarantee that a passed NSString is not a 
NSMutableString under the hood, it should always declare property as copy, so 
the fact that some sample code (I guess this is what the op is talking about) 
use retain is dubious.


___

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: Unique ID for a Window?

[Jean-Daniel Dupas]

 Le 29 juil. 2015 à 12:25, Dave d...@looktowindward.com a écrit :
 
 Hi,
 
 For reasons that are too complex to go in to, I need to somehow create a 
 Unique ID that is valid for the life of a Window. The Window I am trying to 
 identify is not owned by my App (think Screen Dump, like “Grab”). 
 
 I ran this code:
 
 CFArrayRef windowList = 
 CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID);
 for (NSMutableDictionary* entry in (NSArray*)windowList) 
 {
NSString* ownerName = [entry objectForKey:(id)kCGWindowOwnerName];
NSInteger ownerPID = [[entry objectForKey:(id)kCGWindowOwnerPID] 
 integerValue];
NSLog(@%@:%ld, ownerName, (long)ownerPID);
 }
 CFRelease(windowList);  
 
 This is the dictionary returned for this Email message:
 
 {
kCGWindowAlpha = 1;
kCGWindowBounds = {
Height = 858;
Width = 1003;
X = 874;
Y = 342;
};
kCGWindowIsOnscreen = 1;
kCGWindowLayer = 0;
kCGWindowMemoryUsage = 3462288;
kCGWindowName = New Message;
kCGWindowNumber = 2895;
kCGWindowOwnerName = Mail;
kCGWindowOwnerPID = 507;
kCGWindowSharingState = 1;
kCGWindowStoreType = 2;
 },
 
 Are one or more of these values guaranteed to be Unique (within the Window 
 List) and not to change during the life-time of the Window? 
 
 Thanks a lot.
 
 All the Best
 Dave

From the Window Services Reference:

kCGWindowNumber
The value for this key is a CFNumberRef 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFNumberRef/index.html#//apple_ref/c/tdef/CFNumberRef
 type (encoded as kCGWindowIDCFNumberType 
https://developer.apple.com/library/mac/documentation/Carbon/Reference/CGWindow_Reference/Constants/Constants.html#//apple_ref/c/macro/kCGWindowIDCFNumberType)
 that contains the window ID. The window ID is unique within the current user 
session. 




___

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 to Swift conversion question

[Jean-Daniel Dupas]

 Le 28 juil. 2015 à 16:03, Eric E. Dolecki edole...@gmail.com a écrit :
 
 The more I stretch to Swift goals, the more I learn. However I've come upon
 a little thing where I am translating code into Swift and quickly stumbled.
 
 *Obj-C:*
 NSValue *keyboardEndFrameValue = [[notification userInfo]
 objectForKey:UIKeyboardFrameEndUserInfoKey];
 
 
 *Swift (the closest I've come):*
 var keyboardEndFrameValue =
 NSValue(notification.userInfo[UIKeyboardFrameEndUserInfoKey])
 

NSValue() is not a cast, it is a constructor.

Should be something like

var keyboardEndFrameValue = 
notification.userInfo[UIKeyboardFrameEndUserInfoKey] as NSValue


 Error for Swift: insert nonretainedObject:
 When I Fix-It with the above suggestion, the error becomes Cannot
 subscript a value of type '[NSObject: AnyObject]?' with an index of type
 'String'
 
 So I then end up with this (but it looks really strange):
 
 var keyboardEndFrameValue = NSValue(nonretainedObject:
 notification.userInfo[UIKeyboardFrameEndUserInfoKey as String])
 
 No warnings or errors, but I wanted to check to see if I'm appeasing the
 compiler but have it wrong.
 
 Thanks,
 Eric
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Swift and parameter names

[Jean-Daniel Dupas]

 Le 30 juin 2015 à 23:46, Quincey Morris quinceymor...@rivergatesoftware.com 
 a écrit :
 
 On Jun 29, 2015, at 15:42 , Rick Mann rm...@latencyzero.com wrote:
 
 Here's an example (and this is what I frequently encounter) where requiring 
 parameter names adds nothing but clutter:
 
   let config = WKWebViewConfiguration()
   self.webView = WKWebView(frame: self.webViewContainer.frame, 
 configuration: config);
 
 I’ve been thinking about this since yesterday, and while I don’t particularly 
 agree that the parameter names are extraneous in *this* case, I can think of 
 a couple of special cases:
 
 1. If the function/method being called has extremely well-known parameters, 
 then I think I’d prefer the function to have a form that omits the names. In 
 particular, CGRect, CGPoint and CGSize:
 
  let rect = CGRect (x: 0, y: 0, width: 10, height: 10) // vs:
  let rect = CGRect (0, 0, 10, 10)
 

Only because you are used to CGRect. QuickDraw used to defined a rect using 
left, top, right, bottom values. Here you assume that your code reader is 
already familiar with the API.

 The point here is that the parameter semantics are known from the *name* of 
 the function, not from the actual parameters. We have this convention 
 already, in the default behavior where the first keyword to a regular 
 function/method is omitted:
 
  doSomethingWithRect (someRect)
 
 
 This is similar to the CGRect initializer case, in that we know from the name 
 what the parameter is (because it tells us, in this case, not necessarily 
 because we knew it in advance).
 
 2. There’s common situation where a variable name very often *is* a parameter 
 keyword. For example:
 
  init (frame: CGRect, configuration: WKWebViewConfiguration) {
  super.init (frame: frame, configuration: configuration)
  }
 
 In this case, the name of the variable in the ‘super’ call *is* the same as 
 the keyword, because that’s a syntactic default in Swift. Under these 
 circumstances, I could see this being allowed:
 
  init (frame: CGRect, configuration: WKWebViewConfiguration) {
  super.init (frame, configuration)
  }
 
 It may or may not be desirable to require that the keywords are all omitted 
 or all retained, or that this would only work for parameter variables (which 
 have a natural relationship to their keyword).
 
 What do you think? This wouldn’t eliminate all the cases you’ve set your 
 sights on, but it would probably remove the most egregious ones. If there’s 
 some consensus here, I’ll file radars.
 
 
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Subclassing a Subclass of SBApplication

[Jean-Daniel Dupas]

Using class extension is probably a safe way to extends such classes.

@interface SXPhotoshopApplication (MyExtension)

- (void)myWrapper;

@end


 Le 29 juin 2015 à 13:54, Dave d...@looktowindward.com a écrit :
 
 Hi,
 
 I’m using the Scripting Bridge, and I was wondering if it ok to subclass 
 SBXXX classes. Basically, I have a header file generated by the “sdp” tool 
 with definitions as below:
 
 And I’d like to subclass this to add some extra wrapping to hide some of the 
 nastiness from the rest of the app and provide a tighter integration with the 
 current app handling. I remember reading somewhere that these classes 
 shouldn’t be subclassed, but I can’t seem to find it again now.
 
 Thanks a lot
 Dave
 
 -
 
 @interface SXPhotoshopApplication : SBApplication
 
 - (SBElementArray *) documents;
 - (SBElementArray *) fonts;
 - (SBElementArray *) notifiers;
 
 @property (copy, readonly) NSNumber *bestType;  // the best type for the 
 object's value
 @property (copy, readonly) NSNumber *defaultType;  // the default type for 
 the object's value
 @property (copy) NSDictionary *properties;  // all of this object's 
 properties returned in a single record
 @property (copy) SXPhotoshopColorValue *backgroundColor;
 @property (copy, readonly) NSString *build;  // the build number of Adobe 
 Photoshop application
 @property (copy) id colorSettings;  // name of selected color settings' set
 @property (copy) SXPhotoshopDocument *currentDocument;  // the frontmost 
 document
 @property SXPhotoshopE050 displayDialogs;  // controls whether or not 
 Photoshop displays dialogs
 @property (copy) SXPhotoshopColorValue *foregroundColor;
 @property (readonly) double freeMemory;  // the amount of unused memory 
 available to Adobe Photoshop
 @property (readonly) BOOL frontmost;  // is Photoshop the frontmost 
 application?
 @property (copy, readonly) NSString *locale;  // language locale of 
 application
 @property (copy, readonly) NSArray *macintoshFileTypes;  // list of file 
 image types Photoshop can open
 @property (copy, readonly) NSString *name;  // the application's name
 @property BOOL notifiersEnabled;  // enable or disable all notifiers
 @property (copy, readonly) id preferencesFolder;  // full path to the 
 preferences folder
 @property (copy, readonly) NSArray *recentFiles;  // files in the recent file 
 list
 @property (copy, readonly) NSString *scriptingBuildDate;  // the build date 
 of the scripting interface
 @property (copy, readonly) NSString *scriptingVersion;  // the version of the 
 Scripting interface
 @property (copy, readonly) SXPhotoshopSettingsObject *settings;  // 
 preference settings
 @property (copy, readonly) NSString *systemInformation;  // system 
 information of the host application and machine
 @property (copy, readonly) NSString *version;  // the version of Adobe 
 Photoshop application
 @property (copy, readonly) NSArray *windowsFileTypes;  // list of file image 
 extensions Photoshop can open
 
 - (void) AETEScriptsScriptsJavaScriptNameName:(NSString *)JavaScriptNameName 
 JavaScriptFileFile:(NSString *)JavaScriptFileFile 
 JavaScriptTextText:(NSString *)JavaScriptTextText 
 JavaScriptDebuggingDebugging:(BOOL)JavaScriptDebuggingDebugging 
 JavaScriptMessageMessage:(NSString *)JavaScriptMessageMessage;  // Photoshop 
 scripting support plug-in
 - (void) open:(id)x as:(SXPhotoshopOpAs)as 
 withOptions:(SXPhotoshopOpenOptions *)withOptions 
 showingDialogs:(SXPhotoshopE050)showingDialogs smartObject:(BOOL)smartObject; 
  // open the specified document file(s)
 - (void) print:(id)x sourceSpace:(SXPhotoshopE945)sourceSpace 
 printSpace:(NSString *)printSpace intent:(SXPhotoshopE130)intent 
 blackpointCompensation:(BOOL)blackpointCompensation;  // print the specified 
 object(s)
 - (void) quit;  // quit the application
 - (NSArray *) PhotoshopOpenDialog;  // use the Photoshop open dialog to 
 select files
 - (NSString *) batch:(NSString *)x fromFiles:(NSArray *)fromFiles 
 from:(NSString *)from withOptions:(SXPhotoshopBatchOptions *)withOptions;  // 
 run the batch automation routine
 - (NSString *) createPDFPresentationFromFiles:(NSArray *)fromFiles 
 toFile:(id)toFile withOptions:(SXPhotoshopPresentationOptions *)withOptions;  
 // create a PDF presentation file
 - (NSString *) createContactSheetFromFiles:(NSArray *)fromFiles 
 withOptions:(SXPhotoshopContactSheetOptions *)withOptions;  // create a 
 contact sheet from multiple files
 - (NSString *) createPhotoGalleryFromFolder:(id)fromFolder 
 toFolder:(id)toFolder withOptions:(SXPhotoshopGalleryOptions *)withOptions;  
 // Creates a web photo gallery
 - (NSString *) createPhotoMergeFromFiles:(NSArray *)fromFiles;  // 
 DEPRECATED. Merges multiple files into one, user interaction required.
 - (NSString *) createPicturePackageFromFiles:(NSArray *)fromFiles 
 withOptions:(SXPhotoshopPicturePackageOptions *)withOptions;  // create a 
 picture package from multiple files
 - (BOOL) featureEnabledName:(NSString 

Re: Scripting Bridge Questions

[Jean-Daniel Dupas]

 Le 25 juin 2015 à 15:13, Dave d...@looktowindward.com a écrit :
 
 
 On 25 Jun 2015, at 13:33, Bill Cheeseman wjcheese...@gmail.com wrote:
 
 
 On Jun 25, 2015, at 8:09 AM, Dave d...@looktowindward.com wrote:
 
 That’s the problem, “sdef and/or “sdp barf when I try to generate the 
 header file and without the header file you are pretty much dead in the 
 water.
 
 
 I haven't noticed a specific description of the failure you're experiencing. 
 Do you get a partial header file, or a header file that contains errors or 
 that causes errors in your Scripting Bridge implementation? I have found in 
 the past that I can manually edit header files generated by sdef/sdp, at 
 least by removing irrelevant declarations that aren't needed or that cause 
 problems, and when I do it right the edited header files work with Scripting 
 Bridge.
 
 
 I get this error:
 
 sdp: enumerator of enumeration e183: missing required name attribute.
 
 and an (very) incomplete file, e.g. most of it is missing.
 

That just means you wrote an invalid sdef file in the first place. 


___

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: Scripting Bridge Questions

[Jean-Daniel Dupas]

 Le 25 juin 2015 à 15:57, Dave d...@looktowindward.com a écrit :
 
 
 On 25 Jun 2015, at 14:48, Bill Cheeseman wjcheese...@gmail.com wrote:
 
 
 On Jun 25, 2015, at 9:13 AM, Dave d...@looktowindward.com wrote:
 
 I get this error:
 
 sdp: enumerator of enumeration e183: missing required name attribute.
 
 
 Can you generate the sdef file separately, then manually edit it to supply 
 the missing required 'name' attribute, and then run sdp on the edited sdef 
 file? You will presumably have to give more than a little thought to what 
 the missing name attribute should be, but maybe you'll hit pay dirt.
 
 I’m looking into doing that now, but I can’t seem to find an editor that will 
 open it, at the moment it’s ONE giant line of text, I renamed it to .xml and 
 tried to open in XCode - same.
 

You can pretty format it using xmllint command line tool.

xmllint --pretty 1 yourfile.xml  your_formatted_file.xml

 Cheers
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Using CFSTR() with const char * variable

[Jean-Daniel Dupas]

That’s not going to work.

__builtin___CFStringMakeConstantString is a special compiler function that 
requires a constant string to work in the first place, as it tells the compiler 
to generate CFString literal.

I doubt the compiler will accept anything else as parameter.


 Le 7 juin 2015 à 03:39, Steve Christensen puns...@mac.com a écrit :
 
 In my prefix file that is used to build precompiled headers, I include the 
 following after #import-ing all the framework headers. It replaces the 
 standard definition with a version that doesn't insert quotes around an 
 unquoted string literal.
 
 #undef CFSTR//(cStr)
 #ifdef __CONSTANT_CFSTRINGS__
 #define CFSTR(cStr)  ((CFStringRef) 
 __builtin___CFStringMakeConstantString(cStr))
 #else
 #define CFSTR(cStr)  __CFStringMakeConstantString(cStr)
 #endif
 
 
 
 On Jun 5, 2015, at 8:02 PM, Carl Hoefs newsli...@autonomy.caltech.edu 
 wrote:
 
 If I use CFSTR() in the following way:
   CFStringRef mystr = CFSTR( This is a string );
 there is no problem.
 
 However, if I use a variable instead of “string” Xcode flags this as an 
 error:
   const char *mystring = This is a string;
   CFStringRef mystr = CFSTR( mystring );
  ^   — Expected )
 
 In CFString.h, CFSTR is defined as:
   #define CFSTR(cStr)  __CFStringMakeConstantString( cStr )
 
 Is it possible to use CFSTR() with a const char * variable?
 
 Xcode 6.3.2
 -Carl
 
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Looking at self = [super init].

[Jean-Daniel Dupas]

 Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
 
 Was just looking at good old object initialization and came across a stupid 
 idea.
 
 For most object initialization, we do this:
 
 - (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self; 
 }
 
 in some cases, the set up within the parens could get pretty long.  In cases 
 like that, I generally set up another method to handle that for organization, 
 but if you're passing objects into into your init method, then you're passing 
 more data again and the code could get less cleaner looking than it could be.
 
 So, I thought, why don't we check if self != [super init] and then 
 immediately return if that is the case?
 
 That would change object initialization to this:
 
 - (id)init {
if (self != [super init]) {
return;
}
 
// Set up stuff here.
// We don't care if this gets long.
// We really don't.  This could go on and on.
   
return self; 
 }

You must at least returns nil in the fast path, else the compiler will not be 
happy.


___

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: Looking at self = [super init].

[Jean-Daniel Dupas]

 Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
 
 Was just looking at good old object initialization and came across a stupid 
 idea.
 
 For most object initialization, we do this:
 
 - (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self; 
 }
 
 in some cases, the set up within the parens could get pretty long.  In cases 
 like that, I generally set up another method to handle that for organization, 
 but if you're passing objects into into your init method, then you're passing 
 more data again and the code could get less cleaner looking than it could be.
 
 So, I thought, why don't we check if self != [super init] and then 
 immediately return if that is the case?
 
 That would change object initialization to this:
 
 - (id)init {
if (self != [super init]) {
return;
}
 
// Set up stuff here.
// We don't care if this gets long.
// We really don't.  This could go on and on.
   
return self; 
 }
 

And now that a reread the code, it is patently wrong.

if (self = [super init]) is a assignment to self not a comparison.

If you want to do a fast path, you have to do

self = [super init];
if (!self)
return nil;




___

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: WTF is happening?

[Jean-Daniel Dupas]

I found only 5 classes that does not responds to isProxy and they are all 
internal classes, so real code will never have to deal with instances of such 
classes.

And all classes prefixed by « OS_ » inherits NSObject and responds to isProxy. 

I run the experiment for myself and do not doubt the result.

 Le 15 déc. 2014 à 12:12, Charles Jenkins cejw...@gmail.com a écrit :
 
 During the course of this thread, Maxthon has given us code that would enable 
 us to run the experiment for ourselves. I do not doubt him.
 
 —
 
 Charles Jenkins
 
 
 On Monday, December 15, 2014 at 2:31 AM, Maxthon Chan wrote:
 
 My class scanning returned several OS* classes that does not conform to 
 NSObject protocol.
 
 On Dec 15, 2014, at 00:29, Clark S. Cox III clarkc...@gmail.com 
 (mailto:clarkc...@gmail.com) wrote:
 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
 
 What makes you think that Object is used in *any* of those places?
 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com 
 (mailto:garyw...@desisoftsystems.com) wrote:
 
 Are you saying that Apple's well-documented approach to see if an object 
 is derived from NSProxy does not work? If that's the case, you need to 
 submit a bug report to Apple. That's a serious issue that only Apple can 
 help you with.
 
 If you are using objects not derived from NSObject nor NSProxy, then 
 change your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info 
 (mailto:m...@maxchan.info) wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class 
 is interested. But due to the nature of this class scanning before I can 
 make sure that the class derives from NSObject I cannot call any method 
 on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 (mailto:garyw...@desisoftsystems.com) wrote:
 
 If all you care about is if an object is a proxy or not, look at 
 isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info 
 (mailto:m...@maxchan.info) wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
 if (c == other)
 return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com 
 (mailto:k...@ksluder.com) wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”? The error
 says you’re accessing past the end of a string.
 
 
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 mailto: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 
 http://lists.apple.com/
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com 
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com
 
 This email sent to clarkc...@gmail.com mailto:clarkc...@gmail.com
 ___
 
 Cocoa-dev mailing list 

Re: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 13:31, Uli Kusterer witness.of.teacht...@gmx.net a écrit :
 
 On 15 Dec 2014, at 12:42, Jean-Daniel Dupas mail...@xenonium.com wrote:
 I found only 5 classes that does not responds to isProxy and they are all 
 internal classes, so real code will never have to deal with instances of 
 such classes.
 
 Maxthon is iterating over the classes in the system. Even internal classes to 
 the OS show up in that list, so I really don't see how he would *not* have to 
 be able to at least deal with their presence.
 

Fair enough, but I didn’t got any issue while dealing with theses classes. I 
managed to query if they responds to a selector, got there superclass and more.

 Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
 simply has each image representation subclass add itself to an NSArray from 
 its +initialize method. I'd think that'd be less fragile than walking the 
 entire class list.

I fully agree on that. Relying on class iteration is generally a design flaw. 
It is too fragile to be used in a reliable and futur proof way.
But I don’t think you can rely on +initialize to register subclasses as 
initialize will not be called until the someone try to use the target class (or 
one of it’s subclass).

You can use +load but should probably be careful when doing so as there is no 
guarantee about the class loading order AFAIK. 


___

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: WTF is happening?

[Jean-Daniel Dupas]

bool isSubclass(Class cls, Class superclass) {
if (class_respondsToSelector(object_getClass(cls), 
@selector(isSubclassOfClass:))) {
return [cls isSubclassOfClass:superclass];
}
}

 Le 15 déc. 2014 à 16:49, Maxthon Chan m...@maxchan.info a écrit :
 
 But I still need some way to tell them from NSObject/NSProxy decedents from 
 my class walking. Any method calling will cause a crash there.
 
 On Dec 15, 2014, at 23:48, Clark S. Cox III clarkc...@gmail.com wrote:
 
 That does not mean that they're using Object only that they're using a 
 base class other than NSObject or NSProxy. Why can't you just ignore 
 such classes?
 
 Sent from my iPhone
 
 On Dec 14, 2014, at 23:31, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 My class scanning returned several OS* classes that does not conform to 
 NSObject protocol.
 
 On Dec 15, 2014, at 00:29, Clark S. Cox III clarkc...@gmail.com 
 mailto:clarkc...@gmail.com wrote:
 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
 
 What makes you think that Object is used in *any* of those places?
 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com 
 mailto:garyw...@desisoftsystems.com wrote:
 
 Are you saying that Apple's well-documented approach to see if an object 
 is derived from NSProxy does not work? If that's the case, you need to 
 submit a bug report to Apple. That's a serious issue that only Apple can 
 help you with.
 
 If you are using objects not derived from NSObject nor NSProxy, then 
 change your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/ http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class 
 is interested. But due to the nature of this class scanning before I 
 can make sure that the class derives from NSObject I cannot call any 
 method on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 mailto:garyw...@desisoftsystems.com wrote:
 
 If all you care about is if an object is a proxy or not, look at 
 isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/ http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have 
 to implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
  if (c == other)
  return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com 
 mailto:k...@ksluder.com wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The 
 error
 says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 mailto: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 
 http://lists.apple.com/
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com 
 

Re: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 19:45, Fritz Anderson fri...@manoverboard.org a écrit :
 
 I can be dense. Do I understand correctly that
 
 - You have an application that ideally should run continually.
 
 - It accepts plugins that provide one or more classes.
 
 - Those classes must at least observe a protocol; otherwise there would be no 
 sensible way to use them.
 
 - They must have unique names.
 
 - As is typical of ObjC plugins, the classes are packaged in a dynamic 
 library; and as is typical, the library is wrapped in a package directory, 
 which your application has registered with Launch Services as a package, of a 
 certain type and edit/view/associate relationship to your application. I'm 
 sure this is so in your case, as plugins typically need to carry resource 
 files.

Just for the record, typical Obj-C plugins are packaged in loadable bundle 
(MH_BUNDLE), which are a different binary object kind than dynamic library 
(MH_DYLIB).

 - If a package, the plugin might carry an Info.plist file — plugins commonly 
 do.
 
 - You mean to load and unload plugins dynamically, as they appear and 
 disappear in a designated directory, without interrupting the application.
 
 Do I follow you so far? If so, I have some comments.
 
 You can't unscramble the egg: Dynamically-loaded classes can be loaded any 
 time you like, but they cannot be reloaded or unloaded. Surely you know this; 
 surely I misunderstand (or am behind the times).
 
 If you are (practically) committed to a package structure with an Info.plist, 
 why can't you add an array key listing the names of the provided classes? 
 Or for that matter, a text file containing the names? That's one of the 
 things NSBundle is for. It is a universal practice. Just works is a great 
 ideal, but one can expect someone who knows how to build a dynamic library to 
 understand such things.
 
 The declared classes might not implement the required methods, but that's 
 easy and safe to detect once they are loaded. If you must reject, your duty 
 ends when you log the problem and put up an alert.
 
 Am I missing something?
 
— F
 
 
 On Dec 15, 2014, at 11:59 AM, Maxthon Chan m...@maxchan.info wrote:
 
 What I am doing here is to determine a format handling class based on file 
 extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect 
 and allow one plugin to include multiple format handling classes. Also since 
 I am creating an open system I don’t want to require other plugin writers to 
 register their classes, instead the main code shall discover plugins on its 
 own.
 
 This means that the main code will not be able to call any plugin classes 
 methods so +initialize never get called. Also your approach means that the 
 main code will hold a strong reference to the plugin code which prevents 
 plugin unloading.
 
 Class walking may be fragile, but it is fragile enough to allow plugins to 
 come and go easily without having to restart the main code.


___

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: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 21:36, Greg Parker gpar...@apple.com a écrit :
 
 
 On Dec 15, 2014, at 11:02 AM, Jean-Daniel Dupas mail...@xenonium.com wrote:
 
 Le 15 déc. 2014 à 19:45, Fritz Anderson fri...@manoverboard.org a écrit :
 
 - As is typical of ObjC plugins, the classes are packaged in a dynamic 
 library; and as is typical, the library is wrapped in a package directory, 
 which your application has registered with Launch Services as a package, of 
 a certain type and edit/view/associate relationship to your application. 
 I'm sure this is so in your case, as plugins typically need to carry 
 resource files.
 
 Just for the record, typical Obj-C plugins are packaged in loadable bundle 
 (MH_BUNDLE), which are a different binary object kind than dynamic library 
 (MH_DYLIB).
 
 MH_BUNDLE is no longer typical. The only advantage of MH_BUNDLE is that you 
 might be able to unload it, but you probably shouldn't try. Feel free to use 
 MH_DYLIB for all of your plugin needs.

It is typical in the sense that Xcode defaults to mach-o type bundle when 
creating a plugin project and most (if not all) Apple provided plugins are 
bundle (as are most third party plugins).

 (libobjc prevents unloading of any MH_DYLIB containing Objective-C metadata. 
 It does not summarily disallow unloading of MH_BUNDLE, but there's a long 
 list of caveats that make bundle unloading unusable except in rare 
 situations.)



___

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: WTF is happening?

[Jean-Daniel Dupas]

The Object class is not used anywhere is OS X. It is deprecated and should have 
been removed from the runtime long time ago. 

The OS X kernel does not even include obj runtime, so it can’t possibly use the 
Object class. Mach port are integer that represent kernel object and not 
classes.

The root class for all OS Object (XPC, GCD, …) is NSObject (which live in the 
runtime too).

If you find subclasses of Object, you are obviously doing something wrong.

 Le 13 déc. 2014 à 20:57, Maxthon Chan m...@maxchan.info a écrit :
 
 NSProxy checking actually work, but throwing those classes that derive from 
 Object class (note I used capitalised O here, the old Object class from early 
 NeXT times, also used heavily in OS X kernel, GCD and Mach ports) into the 
 mix means that no method can be sent before class is determined. I would 
 suggest Apple add one runtime function class_isSubclassOfClass() that mirrors 
 the functionality of NSObject and NSProxy method isSubclassOfClass so that 
 derivatives of the old Object class can be detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com wrote:
 
 Are you saying that Apple's well-documented approach to see if an object is 
 derived from NSProxy does not work? If that's the case, you need to submit a 
 bug report to Apple. That's a serious issue that only Apple can help you 
 with.
 
 If you are using objects not derived from NSObject nor NSProxy, then change 
 your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class is 
 interested. But due to the nature of this class scanning before I can make 
 sure that the class derives from NSObject I cannot call any method on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 wrote:
 
 If all you care about is if an object is a proxy or not, look at isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of a 
 certain class. Before any NSObject method can be issued I have to check 
 if it is actually NSObject or NSProxy derivative instead of an Object 
 derivative that does not support NSObject methods. This calls for runtime 
 equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
if (c == other)
return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will file 
 a bug report to Apple and ask them to add this, as it is useful in class 
 scanning and i am using this technique heavily in jailbreak detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The error
 says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: How does the Swift Darwin module work?

[Jean-Daniel Dupas]

AFAIK, variadic C functions are not (yet) callable from swift code.


 Le 18 oct. 2014 à 20:37, Rick Mann rm...@latencyzero.com a écrit :
 
 I need access to fcntl, so I thought I'd do what Apple does with Darwin. But 
 I don't actually see how to do that. They create Darwin.stdio.fopen(), for 
 example. But then how do they call the underlying C fopen()?
 
 For that matter, Swift can call C functions directly in some cases, and not 
 at all in others.
 
 OH! Is it because fcntl is special? Check out its declaration:
 
   int fcntl(int, int, ...) __DARWIN_ALIAS_C(fcntl);
 
 __DARWIN_ALIAS_C is:
 
   #define __DARWIN_ALIAS_C(sym)   __asm(_ __STRING(sym) 
 __DARWIN_SUF_NON_CANCELABLE __DARWIN_SUF_UNIX03) 
 
 So, is there some magic module I can create in Swift to make that accessible 
 to my Swift code?
 
 -- 
 Rick Mann
 rm...@latencyzero.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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.com

-- 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: Why not use path-based API? (was: Loading image resources)

[Jean-Daniel Dupas]

Le 14 sept. 2014 à 10:23, Quincey Morris quinceymor...@rivergatesoftware.com 
a écrit :

 On Sep 14, 2014, at 00:57 , Aandi Inston aa...@quite.com wrote:
 
 Why? Really, why? Certainly there are APIs where we have to use URL's and
 we have to convert the path into a URL, but where a non-deprecated
 path-based URL exists, what current or future obstacles do you foresee? The
 URL doesn't seem to be more predicable or persistent, for example.
 
 It’s not an absolute rule, and it’s certainly possible to defend the use of 
 path APIs, but here are some of my reasons:
 
 1. NSURL-based APIs were introduced *in order to* replace path-based APIs, so 
 using the new APIs maybe helps to future-proof your code. IOW, sometimes 
 Apple gives us hints as to what continents are moving in the API geoscape, 
 and sometimes they do this by replacing APIs with new ones that more or less 
 seem to do the same thing — until later they don’t.
 
 For example, although Cocoa generally requires *file* URLs for non-internet 
 things, it’s possible that in the future we’ll need to locate resources that 
 don’t have a traditional path.
 
 2. I think some path-based APIs had quirks, for example about handling paths 
 that started with a tilde, or other environment-related issues. Generally, 
 NSURL-based APIs are regular in their behavior. However, I don’t have any 
 examples of this difference at hand, and I could easily be wrong about this 
 point.
 
 3. Some NSURL-based APIs improved or corrected the methods that they 
 replaced. For example, the new APIs follow standard conventions for returning 
 errors.
 
 4. Some things can only be done with NSURL-based APIs. For example, sandboxed 
 access to files chosen by users.
 
 Because of #3 and #4, you’re going to be using NSURL at least some of the 
 time, and mixing the two API styles gets messy fast. If you have to pick one, 
 NSURL is the one to pick.
 
 Here are some of the reasons for using path-based APIs:
 
 1. You’re writing a command line utility that’s (e.g.) POSIX-compliant or 
 crosses to other UNIX platforms. In that case, its probably more consistent 
 to stick with paths, unless you have some other reason to deal with URLs.
 
 2. You’ve got existing code that uses path-based APIs, and you can’t justify 
 the time it would take to convert.
 
 Because the above is too long to be useful in response to posts on other 
 issues, I decided to reduce it to “You should use URL-based equivalents 
 generally.”
 

One other point is that NSURL API abstract the way you access a file and let 
you transparently use different concept to reference a file like 'file 
reference'.


___

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 is the modern Cocoa way to send an Apple Event to yourself?

[Jean-Daniel Dupas]

Le 22 août 2014 à 07:24, Daryle Walker dary...@mac.com a écrit :

 I changed my app from implementing -application:openFile: to 
 -application:openFiles: in my application delegate. Then, I noticed that my 
 Open File menu command directly calls my window creation function, and I 
 decided to change the action handler to call -application:openFiles: instead. 
 Later I realized that changing a global via -replyToOpenOrPrint: to the 
 application object may not be a good idea if said object doesn’t expect it 
 (like outside of application launch). So now I want to re-reimplement the 
 open-file action handler by calling the open-file Apple Event to myself. 
 Looking through the modern Apple docs, I see all sorts of stuff about 
 handling Apple Events, but nothing about sending them. Help.

I think you can use NSWorkspace. It will generate the same events than the one 
send when you try to open a file from the Finder.



___

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: Translating to Swift

[Jean-Daniel Dupas]

In fact, this is actually exactly equivalent to you sample. Global and class 
variable initialization on Swift is performed lazily and is implemented using 
dispatch_once().

And after a second thought, I think that it should be 'let' and not 'var', and 
you don't want the pointer to be changed after initialization.

I don't remember if static class variable are supported yet, but if they are, 
you can also use one instead of a global.

Le 14 août 2014 à 20:44, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 
 
 On 13 Aug 2014, at 17:35, Jean-Daniel Dupas mail...@xenonium.com wrote:
 
 At global scope
 
 var sharedThing : Thing = Thing();
 
 
 Excellent. Just what I needed.
 
 But: is this thread-safe? What if several threads are trying to use the 
 sharedThing? The Swift book doesn't mention the word thread.
 
 Kind regards,
 
 Gerriet.
 
 Le 13 août 2014 à 12:30, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :
 
 
 How could I translate this to Swift?
 
 + (Thing *)sharedThing
 {
 static Thing *commonThing;
 static dispatch_once_t justOnce;
 dispatch_once( justOnce, ^void
 {
 commonThing = [ [ Thing alloc ] init ];
 }
 );
 
 return commonThing;
 }
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Translating to Swift

[Jean-Daniel Dupas]

At global scope

var sharedThing : Thing = Thing();

Le 13 août 2014 à 12:30, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 
 How could I translate this to Swift?
 
 + (Thing *)sharedThing
 {
   static Thing *commonThing;
   static dispatch_once_t justOnce;
   dispatch_once( justOnce, ^void
   {
   commonThing = [ [ Thing alloc ] init ];
   }
   );
   
   return commonThing;
 }
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Common Date between Swift and ObjC

[Jean-Daniel Dupas]

You can use an enum. The compiler treats them as constant and they are 
available both in Obj-C and Swift.

Le 12 août 2014 à 20:04, Paul Scott psc...@skycoast.us a écrit :

 Except the compiler cannot treat them as constants for optimization.
 
 Paul
 
 On Aug 12, 2014, at 10:57 AM, Gerriet M. Denkmann gerr...@mdenkmann.de 
 wrote:
 
 
 On 13 Aug 2014, at 00:52, Jeff Kelley slauncha...@gmail.com wrote:
 
 Gerriet,
 
 You should be able to make a constant variable, not a preprocessor 
 definition, and import the file that declares it in your project’s bridging 
 header. Something like this:
 
 in Constants.h:
 extern const NSInteger kParameterA;
 
 in Constants.m:
 const NSInteger kParameterA = 17;
 
 Then, in your bridging header, you’d import Constants.h.
 
 Sounds like a good idea. I will try it tomorrow.
 Thanks a lot!
 
 
 Kind regards,
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: app icon for Launchpad

[Jean-Daniel Dupas]

That's probably a Launchpad icon caching issue. I don't know where it used to 
cache icons though.

Le 17 juin 2014 à 05:35, Roland King r...@rols.org a écrit :

 My OSX app has an icon. It shows in the dock when active, it shows on 
 Alt-Tab, it shows in the Applications folder, however in Launchpad I get the 
 generic OSX Application Icon. 
 
 I'm using Images.xcassets for my icons (it's a fairly new project). What do I 
 need to have for Launchpad to show the icon? 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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++

[Jean-Daniel Dupas]

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: Can CFUUIDCreateString() return lowercase characters?

[Jean-Daniel Dupas]

According to the current CF sources, CFUUIDCreateString() returns an uppercase 
string.

But if I really want to know what I get, I would rather use the libuuid 
functions provided by the system: uuid_unparse_lower() and uuid_unparse_upper().

See man uuid for details.


Le 21 janv. 2014 à 11:21, Markus Spoettl ms_li...@shiftoption.com a écrit :

 Hi,
 
  up until now I've been assuming that CFUUIDCreateString() returns strings 
 using uppercase letters. There's lots of empirical evidence that it does do 
 that, but nothing in writing.
 
 NSUUID's -UUIDString documentation also suggests uppercase characters being 
 used, but doesn't commit to it either.
 
 Anyone with authority here to confirm that assumption?
 
 Regards
 Markus
 -- 
 __
 Markus Spoettl
 ___
 
 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: RSA and libcrypto

[Jean-Daniel Dupas]

Le 14 janv. 2014 à 18:20, Jens Alfke j...@mooseyard.com a écrit :

 
 On Jan 14, 2014, at 1:19 AM, jonat...@mugginsoft.com wrote:
 
 As Jens comments the security APIs are ridiculously opaque. 
 Perhaps this is seen as a necessity in the serious world of crypto - perhaps 
 it is just hard to avoid. However, it is a liability.
 
 Crypto is inevitably sort of complex, but Apple’s to blame for some bad (and 
 downward-trending) API design and poor documentation. Other crypto APIs that 
 I’ve seen are much clearer.
 
 By comparison libcrypto is pretty straightforward.
 The only problem with retaining it is the extra complexity involved in 
 integrating the static library build into the project and upgrading the 
 source.
 
 My reservation about using libcrypto would be key storage. The Keychain is a 
 pretty great thing — a secure place to store keys that’s well-integrated into 
 the OS. I don’t know how OpenSSL stores keys, but if it’s using some other 
 mechanism, it’s probably less secure.
 
 This thread should probably move to apple-cdsa (which is the 
 fittingly-obscure name for the security/crypto mailing list.)
 

Just in case it was not mentioned in the thread, SecTransform supports RSA. You 
can use SecEncryptTransformCreate() with an asymmetric key.

Anyway, the full list of what can be done is demonstrated in the 
CryptoCompatibility sample code:

https://developer.apple.com/library/mac/samplecode/CryptoCompatibility/Introduction/Intro.html

For each possible action, it provides a way to perform it using CDSA, 
SecTransform, and iOS specific code.


-- 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: libcrypto linking problem in Leopard

[Jean-Daniel Dupas]

Le 3 janv. 2014 à 08:15, Appa Rao Mulpuri appar...@ivycomptech.com a écrit :

 Hi List,
 
 I am using Mac OS X 10.8 SDK for the development and deployment target set to 
 Mac OS 10.5. I am using libcrypto dylib in my code base, application is 
 working fine in all the OS, except in Leopard. Application is failing to 
 launch in Leopard and giving the Library not loaded error.
 
 Library not found: /usr/lib/libcrypto.0.9.8.dylib
 Reason: no suitable image found.
 
 I tried to build the application on mavericks with libcrypto.0.9.7.dylib by 
 updating the libcrypto.dylib alias in 
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib,
  but no luck. Its giving me compile time errors saying symbols not found.
 
 I primarily wants to move to Mavericks for my regular development and take 
 advantage of LLVM compiler for its greater speed (compared with GCC).
 
 http://stackoverflow.com/questions/2616738/linking-to-libcrypto-for-leopard 
 gone though this url. Solution is available if you are using the 10.6 SDK for 
 development. To make it work with 10.6 SDK + Xcode 5, copied 10.6 and 10.7 
 sdks into 
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/,
  but unfortunately Xcode 5 is not displaying them in the Build settings 
 window.
 
 Is there any way to get rid of the libCrypto linking issue?
 
 Regards,



The simplest advice is don't use libcrypto.

If you just need simple functionality, you may have a look at the CommonCrypto 
API which is partially available on 10.5 ( I think Digest and Cryptors where 
available at this time).

If you need something more complex, you should use the Security framework, 
unfortunately the whole 10.5 API (CDSA) has been deprecated in favor of a 
cleaner but incompatible API.

So you will have to write the code twice if you want to support 10.5 and be 
futur proof.


-- 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: Preferences caching?

[Jean-Daniel Dupas]

Le 28 nov. 2013 à 12:05, Bill Cheeseman wjcheese...@gmail.com a écrit :

 
 On Nov 27, 2013, at 7:14 PM, Shane Stanley sstan...@myriad-com.com.au wrote:
 
 On 28 Nov 2013, at 7:53 AM, Graham Cox graham@bigpond.com wrote:
 
 I guess if/when it crops up again we’ll just have to navigate the 
 unfortunate user through the command line.
 
 Or write a one-line AppleScript script:
 
 do shell script defaults delete ...
 
 Save it as a code-signed app, send it to them, and tell them to 
 double-click. A lot easier than navigating Library folders for the average 
 user.
 
 
 Did the AppleScript I posted to this thread yesterday not make it to the list?
 

It does. I got it.

-- 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: Sending a message to a Toll free bridge

[Jean-Daniel Dupas]

Le 25 nov. 2013 à 10:23, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 The documentation states: CFArray is “toll-free bridged” with its Cocoa 
 Foundation counterpart, NSArray. This means that the Core Foundation type is 
 interchangeable in function or method calls with the bridged Foundation 
 object. Therefore, in a method where you see an NSArray * parameter, you can 
 pass in a CFArrayRef
 
 Does this also mean: any message you can send to an NSArray, you can send 
 also to an CFArrayRef?
 
   NSFont *fo = [ NSFont fontWithName: @Thonburi size: 0 ];
   CTFontRef font = (__bridge CTFontRef)fo;
   CFArrayRef tags = CTFontCopyAvailableTables ( font, 0 );
   NSArray *tagsArray = CFBridgingRelease(tags);
   // next  line prints: class __NSCFArray count: 18
   NSLog(@%s class %@ count: %lu,__FUNCTION__, [tagsArray class], 
 [tagsArray count]);
 
 So sending messages to an CFArrayRef seems to be ok. Or not?
 
 But then this line crashes:
 
   NSString *tagDescription = [ tagsArray description ];
 
 My mistake? My false assumption?

You just hit a corner case. Toll free bridging is supported only for 
collections of objects compatible with id. 
CTFontCopyAvailableTables() is one of the very few API that returns a 
CFArrayRef that contains plain int value, and so cannot be safely converted to 
NSArray.

An other well known corner case is when you try to cast a CFMutableDictionary 
into a NSMutableDictionary. The later requires that key are copyable objects 
while the former support other types of keys.

Except such cases, you should be able to call any NSArray method on a 
CFArrayRef.

-- 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: waitUntilDone: parameter when performing selector on main thread

[Jean-Daniel Dupas]

Le 12 nov. 2013 à 15:26, Graham Cox graham@bigpond.com a écrit :

 I’m just thinking about the use of 
 -performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best 
 way to think about the waitUntilDone parameter. The situation is updating a 
 UI from another thread, using this to punt the update to the main thread (in 
 fact the progress bar situation discussed earlier this week).
 
 I assume if I pass NO, the request is queued and processed once per event 
 loop. If I pass YES, there is some sort of lock which sleeps my thread until 
 the main thread completes the task.
 
 So passing NO, my worker thread can proceed as fast as it can, but the main 
 thread could back up and end up lagging (and also queuing a lot of redundant 
 updates, like a progress value where really only the latest matters). If I 
 pass YES, my worker thread is going to get throttled by the main thread.
 
 Is this just one of those cases where you have to judge the best approach, or 
 is there a better way to determine when to pass YES or NO?
 
 Currently, I generally pass NO, and my worker threads are not updating the 
 progress too often anyway - I mod the count so that it only updates every 50 
 or 100 iterations. The UI seems to keep up fine. What do others do?
 

My rule is simply to never pass NO. In a world where async is the new standard, 
waiting for a thread to complete should really never be used. 

Updating your UI more than 60 times per seconds is useless as the update will 
never be pushed to the screen, and the UI thread should be able to deal with 60 
messages per seconds smoothly, so don't bother with premature optimisation, and 
keep it simple.
And even 60 times per seconds is probably too much anyway. Just make sure your 
worker thread does not push too much updates.

-- 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: MP4 video playback on Mavericks - Where's a good place to start?

[Jean-Daniel Dupas]

Le 12 nov. 2013 à 17:01, Bryan Vines bkvi...@me.com a écrit :

 Good morning all,
 
 I'm toying with a project to play short video, stored in my app's bundle. I 
 had thought to use QTKit and a QTMovieView, but I can't locate the 
 QTMovieView in Interface Builder.
 
 Apple has a QTKit tutorial, Creating a Simple QTKit Media Player 
 Application, but this is built around Xcode 3.2 and makes use of 
 QTMovieView, which again I'm not seeing. Is AVKit and the AVPlayerView the 
 way to do this in Mavericks?
 

Yes, AVKit is a new framework introduced in Maverick for movie playback.

 Unfortunately I've only had one cup of coffee today and as a result my 
 Google-fu is weak. I appreciate any guidance as to which way I should go, and 
 where to start looking.
 
 Thanks!
 --
 Bryan Vines

-- 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: waitUntilDone: parameter when performing selector on main thread

[Jean-Daniel Dupas]

Le 12 nov. 2013 à 17:45, Graham Cox graham@bigpond.com a écrit :

 
 On 12 Nov 2013, at 4:12 pm, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 My rule is simply to never pass NO
 
 
 Did you mean YES? (i.e. always pass NO). Others seem to be saying the 
 opposite.
 

My bad, Of course, always pass NO and never wait.

 —Graham

-- 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: Speed of Arc on iPhone

[Jean-Daniel Dupas]

Le 1 nov. 2013 à 08:38, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 Messing with an iPhone app (iOS 7.0.3) Release build on Xcode Version 5.0.1 
 (5A2053) I noticed that by switching Arc off in two crucial files the speed 
 of some operation almost doubled.
 
 So: are there any rules of thumb what to do and what not to do to avoid an 
 Arc slowdown?
 
 Or: are there situations in which Arc is better not used?


Yes, when profiling tells you it is in a hot path.

The compiler is conservative and anytime it has some doubt, it will 
retain/release an object. 
If profiling shows some that code where you now it is safe to avoid this 
additional retain/release is hot, you can help the compiler by using 
__unsafe_unretain to annotate the managed variable.

-- 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: C functions

[Jean-Daniel Dupas]

Le 19 oct. 2013 à 15:01, Uli Kusterer witness.of.teacht...@gmx.net a écrit :

 On 19 Oct 2013, at 01:17, Shane Stanley sstan...@myriad-com.com.au wrote:
 On 19 Oct 2013, at 3:15 AM, Uli Kusterer witness.of.teacht...@gmx.net 
 wrote:
 
 this is what you'd do if you wanted to make e.g. CoreFoundation APIs 
 accessible to a scripting language
 
 That's along the lines of what I had in mind, although in this case for 
 basic things like the trig functions in Math.h.
 
 So, is this supposed to just directly hand off some standard functions you 
 decide to map into your library, like PHP exposes most of the standard C 
 library? In that case I’d probably just write a little script that generates 
 wrappers that translate between your language’s calling convention and the 
 one of the C library, and enter them in a global variable with a struct that 
 maps the plain-text name to the function pointer.
 
 Whether you actually want to regex-parse the headers (like I did here for my 
 Hammer programming language: 
 https://github.com/uliwitness/Forge/blob/master/headerimport.php) or whether 
 you want to just hand-write a short, easily parsed list of the functions and 
 their argument types is up to you. The latter requires less maintenance if 
 you plan to only selectively import a few native calls, as regex-parsing of 
 C/ObjC headers is rather optimistic and tends to break every couple of system 
 releases.
 

To parse C/Obj-C/C++ headers, you can also use libclang which is design to do 
that. I used it to parse C header and generate boilerplate code some times ago, 
and it worked quite well with very few code to write on my side.

 If you, on the other hand, want to support creation of actual headers by 
 users of your language and adding of new functions w/o recompiling, you’re 
 prolly best off with a foreign function interface like libffi.
 
 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/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: How test whether Mac app is running in Xcode?

[Jean-Daniel Dupas]

Le 15 oct. 2013 à 18:50, Jens Alfke j...@mooseyard.com a écrit :

 
 On Oct 15, 2013, at 9:10 AM, Bill Cheeseman wjcheese...@gmail.com wrote:
 
 I can't talk about the why? part of my question in public because it's an 
 issue unique to Mavericks. Let me just say that a certain common category of 
 applications is going to want to know how to do this in Mavericks, for good 
 and sufficient reason.
 
 OK … sounds like you should take the question to Apple’s developer forums, 
 then, where you can talk about 10.9.
 
 What I find interesting is that NSWorkspace's -frontmostApplication and 
 -menuBarOwningApplication and NSRunningApplication's currentApplication 
 return different results in different circumstances.  … My guess is that the 
 fact that one of them returns Xcode at launch is a bug that nobody has 
 noticed, and I therefore shouldn't rely on it anyway
 
 I agree, it’s almost certainly a bug.
 
 So I need a reliable way to find out. I know there is a way
 
 There’s definitely a way. As an existence proof, the first thing I thought of 
 when you asked is the infamous behavior of iTunes — if you attach a debugger 
 to iTunes and then try to play any DRM-protected content, iTunes will 
 intentionally crash. It’s a way to deter people from either extracting the 
 decoded media data, or reverse-engineering the DRM. (Probably not a very 
 foolproof way...)


Nope.
The crash is not cause by iTunes.
iTunes tells the kernel it should not be attached, and the kernel kills it if 
somebody try to do it. iTunes never knows if somebody try to attach debug it.

-- 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: RunLoop in Helper Tool

[Jean-Daniel Dupas]

XPC is based on GCD. There is chance that your request handling occurs in a GCD 
thread and not on the main thread.

[NSRunLoop currentRunLoop] returns the current thread run loop. If you are not 
on the main thread, it will not work.

Try that instead: CFRunLoopStop(CFRunLoopGetMain());


Le 15 sept. 2013 à 10:32, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 I have a Helper Tool, running as root, started via SMJobBless and 
 communicating vie Xpc.
 
 Works fine, but:
 1. it cannot stop (CFRunLoopStop),
 2. Timers never fire
 3. NSRunLoop currentMode returns nil.
 
 Maybe all three things are related.
 
 To 1:
 
 if ( asked to quit )
 {
   NSRunLoop *currentRunLoop = [ NSRunLoop currentRunLoop ];
   CFRunLoopRef rl = [ currentRunLoop getCFRunLoop ];
   NSLog(@%s will stop runloop %p,__FUNCTION__, rl); //  rl ≠ 
 NULL
   CFRunLoopStop ( rl );   //  runLoop will NOT stop
 }
 
 Helper Tool main:
 
 int main(int argc, const char * argv[])
 {
   @autoreleasepool
   {
   NSString * bundleIdentifier = [[NSBundle mainBundle] 
 bundleIdentifier]; 
   NSXPCListener *listener = [[NSXPCListener alloc] 
 initWithMachServiceName: bundleIdentifier ];
   listener.delegate = ...;
   [listener resume];
   NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];
   [ currentRunLoop run ];
   }
   
return EXIT_SUCCESS;
 }
 
 
 ___
 
 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: RunLoop in Helper Tool

[Jean-Daniel Dupas]

Le 15 sept. 2013 à 16:23, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 
 On 15 Sep 2013, at 16:42, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 XPC is based on GCD. There is chance that your request handling occurs in a 
 GCD thread and not on the main thread.
 
 Correct. NSThread tells me:
 mainThreadNSThread: 0x7f92b14096a0{name = (null), num = 1} 
 currentThread NSThread: 0x7f92b3502cf0{name = (null), num = 2}
 
 
 [NSRunLoop currentRunLoop] returns the current thread run loop. If you are 
 not on the main thread, it will not work.
 
 NSRunLoop *currentRunLoop = [ NSRunLoop currentRunLoop ];
 CFRunLoopRef rl1 = [ currentRunLoop getCFRunLoop ];   //  mode = 
 nil
 
 CFRunLoopRef rl2 = CFRunLoopGetMain ();   //  
 mode = kCFRunLoopDefaultMode
 
 
 Try that instead: CFRunLoopStop(CFRunLoopGetMain());
 Tried it. Even tried stopping both run loops, but to no avail. The helper 
 tool just will not quit.
 
 But maybe I will be able to make my NSTimers work now having a better 
 understanding of what is going on.
 

Now that you mention it, I remember it is not possible to stop a [NSRunLoop 
run] call (at least not in a reliable way).

See the -[NSRunLoop run] documentation for an alternative way to do that, or 
just call exit() as others have suggested.

-- 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: 64-bit iOS

[Jean-Daniel Dupas]

You should never be using int in the first place except for API that are 
already using int, like many libc functions return type.

Use the types that fit the API you are using, and if you have to write some 
API, use types from stdint.h that fit your need.

Le 14 sept. 2013 à 16:37, vipgs99 vipg...@gmail.com a écrit :

 So do I need replace all int to NSInteger?
 On 13-9-11 3:50, Fábio Bernardo wrote:
 I don't get the advantage... What I am missing?
 
 —
 Fábio Bernardo
 
 On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe scott_r...@elevated-dev.com
 wrote:
 
 Well, since nobody else has commented, let me be the first to say:
 YES! YES! YES! THANK YOU APPLE!!
 -- 
 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/me%40fbernardo.org
 This email sent to m...@fbernardo.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/vipgs99%40gmail.com
 
 This email sent to vipg...@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/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: 64-bit iOS

[Jean-Daniel Dupas]

This is the contrary. In Obj-c all pointers are effectively double size, but in 
Java, they are not.

See “Compressed oops at 
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
 

Le 11 sept. 2013 à 00:18, Paul Franz paul.p.fr...@gmail.com a écrit :

 Should be interesting to see how this plays out. When it comes to Java, when 
 you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing so. 
 The main reason has to do with pointers. All pointers double in size. The 
 effect might be less in a Objective-C program.
 
 Paul Franz
 
 On Sep 10, 2013, at 5:47 PM, Tom Davie tom.da...@gmail.com wrote:
 
 
 On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 
 For ARM, 64 bit matters because the instruction set has been updated to 
 provider better performances.
 
 I just hope the performance boost provided by this architecture change will 
 be enough to balance the slow-down due to the increase of instruction and 
 pointer size.
 
 Note, this was actually more significant on x86, where most of the mess 
 caused by CISC (like having bugger all registers) got sorted out.
 
 Tom Davie
 ___
 
 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/paul.p.franz%40gmail.com
 
 This email sent to paul.p.fr...@gmail.com
 

-- 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: ARC vs Manual Reference Counting

[Jean-Daniel Dupas]

Le 11 sept. 2013 à 09:03, Marcel Weiher marcel.wei...@gmail.com a écrit :

 Hi John!
 
 On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote:
 
 On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote:
 [Optimizations in ARC are there to mitigate pessimizations]
 
 For what it’s worth, the autorelease optimization was planned; the 
 performance problem it solves was extremely predictable, since it’s actually 
 a noticeable performance problem in MRC code as well.
 
 Glad to hear that the performance problems that the optimizations were 
 designed to mitigate were identified early, hope this also resulted in fewer 
 Café Macs dinner tickets.  :-)
 
 Worth noting: trying to micro-optimize retains and releases by naively 
 opting files out of ARC is a great way to defeat the autorelease 
 optimization; if you do this and care about performance, I strongly suggest 
 using +1 returns. 
 
 I don’t think that would be a good target or reason for opting out.  In fact, 
 I have a protocol where I have a +1 return that I am thinking of turning ARC 
 on for so I don’t have to do that any longer.  :-)
 
 More likely performance reasons/targets for opting out are things like inline 
 reference counts and, especially, object caches.  For me they generally bring 
 factors of improvement, if not orders of magnitude, when applicable (wasn’t 
 it CoreGraphics that had problems with their object cache no longer working 
 on GC, thus killing performance?)   Being able to mix-n-match and opt out is 
 definitely one of the awesome features of ARC.
 
 On the inline reference counts:  when I was doing my recent tests on 
 archiving performance, I suddenly found that object creation (1M objects) was 
 taking longer than expected.  Adding an inline retain count *halved* the 
 running time for creating the object graph (155ms vs 300ms)!  I have to admit 
 I was bit surprised that the difference would be this big, considering the 
 intrinsic cost of object creation.(Out of curiosity I tested it with ARC 
 and it took 400ms)
 
 Also of note: the ARC optimizer relies on being able to see how objects are 
 used, so code that’s using dusty old “I don’t ever want to write 
 retain/releases workarounds like literally making every temporary variable 
 a property is basically asking to be pessimized.
 
 You misunderstand (I am likely blame for that for not expressing myself 
 clearly):   the temporary variables I use accessors for are the (very few) 
 ones that have strange enough lifetimes that you see retain/release code for 
 them in the middle of methods.  Quite often, they already live in instance 
 variables, but are just accessed in an ad-hoc fashion.  Using accessors for 
 them really is (or should be) a no-brainer.  Sometimes there are asynchronous 
 loops that use a local variable in a similar fashion.
 
 Using instance variables for ALL method temporaries would be silly…in essence 
 it would be using the ARC strategy, but without the optimizer running to get 
 rid of most of the damage, ouch!
 
 Overall, while we’re happy to see that some people see performance 
 improvements, our expectation going in was always that ARC would cause some 
 regressions,
 
 That is also what I would have expected, given what I know about it.
 
 It’s interesting that the “group consensus” I find both on the webs/tutorials 
 and also here, sometimes tacit, sometimes not, is that ARC is a performance 
 win.  Note how the claim that ARC was faster went unremarked, whereas the 
 finding of a slowdown created immediate negative reaction (“did you test?”, 
 “you must have made a mistake”), fortunately mostly in good humor.

I think this common misbelief come from the fact that when Apple released ARC, 
they have claimed a non negligible performance win for retain/release and 
autorelease operations. While this is true, it does not give any clue about the 
global impact of ARC.

 
 and that while in most code those would be lost in the noise, in some cases 
 people would need to help ARC out with things like __unsafe_unretained.
 
 Hmm…I always thought that __unsafe_unretained was for instance variables, but 
 given what you just wrote, I guess it could be used for normal automatic 
 variables to opt them out of ARC? 
 

Yes. it works to disable ARC for arguments and other local variables. I managed 
to reduce the ARC impact a little further by applying it to some arguments in 
hot paths.


-- 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: 64-bit iOS

[Jean-Daniel Dupas]

Le 11 sept. 2013 à 11:31, Vincent Habchi vi...@macports.org a écrit :

 Mostly, this is not going to change anything. You will see your code size 
 increase, because unless you use PIC, you’ll have to store 64-bit addresses 
 instead of 32. There will be more cache misses as your memory space becomes 
 sparse. It will surely run faster, but not because the bus size has been 
 increased, but because the number of GPR is doubled, thereby allowing some 
 optimizations during scheduling and context switching.

The increase of GPR is far to be the only architecture change between arm7 and 
AArch64 (assuming AArch64 is what Apple is using).

 But what bother me most, is that I don’t really see the point. A smartphone 
 is a phone, it is neither a web server nor a huge database machine nor a 
 supercomputer. Who wants to mmap 5 GiB files on a phone? Which process needs 
 more than 2 GiB at most? Seriously? Will it make you reading your mail 
 faster, loading webpages instantaneously? Will your calendar feel snappier? 
 Besides marketing and advertisement, nobody really needs that amount of 
 power. We’re not going to simulate galaxy dynamics on an iPhone, or derive 
 the flow lines around the next fighter of the US Air Force… The iPhone 3S 
 already delivers a more than sufficient experience for the vast majority of 
 users. Besides, embedded programming is about optimizing and stuffing the 
 most in the tiniest space…


Thanks for this remainder, but I think we all already know that 620k is enough 
for anyone…

-- 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: ARC vs Manual Reference Counting

[Jean-Daniel Dupas]

ARC is a combination of compiler and runtime technologie.

The compiler generates call to the runtime, so if you see a lot of ARC specific 
calls in the profiler, you can know if the impact is due to ARC or not.

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support


Le 11 sept. 2013 à 17:15, Sean Roehnelt s...@yellowmatter.com a écrit :

 ARC is compile time, not runtime, so I don't see how it could…
 
 On Sep 9, 2013, at 1:18 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 And does the profiler explicitly shows that ARC runtime code is the culprit ?

-- 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: 64-bit iOS

[Jean-Daniel Dupas]

For ARM, 64 bit matters because the instruction set has been updated to 
provider better performances.

I just hope the performance boost provided by this architecture change will be 
enough to balance the slow-down due to the increase of instruction and pointer 
size.

Le 10 sept. 2013 à 22:01, Abdul Sowayan asowa...@vectorworks.net a écrit :

 Scott,
 
 I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and 
 there is no virtual memory. Until you exceed the 4 gig limit, I don't see why 
 this matters.
 
 Abdul
 
 Sent from my iPhone
 
 On Sep 10, 2013, at 3:44 PM, Scott Ribe 
 scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com wrote:
 
 Well, since nobody else has commented, let me be the first to say:
 
 YES! YES! YES! THANK YOU APPLE!!
 
 --
 Scott Ribe
 scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com
 http://www.elevated-dev.com/
 (303) 722-0567 voice
 
 
 
 
 ___
 
 Cocoa-dev mailing list 
 (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/asowayan%40vectorworks.net
 
 This email sent to asowa...@vectorworks.netmailto:asowa...@vectorworks.net
 ___
 
 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: Unicode chars in string

[Jean-Daniel Dupas]

Le 9 sept. 2013 à 09:54, Tom Davie tom.da...@gmail.com a écrit :

 
 On 9 Sep 2013, at 09:13, Damien Cooke dam...@smartphonedev.com wrote:
 
 Hi all,
 I am pulling my hair out here trying to replace the unicode (r) symbol with 
 \\00ea in a string.  Is there a way of doing this as the NSString is a 
 unicode String so it is interpreting it.  As convenient that might be to 
 most people it is killing me here.
 
 NSStrings already support unicode quite happily.  clang will even let you use 
 unicode directly in the source, so [string 
 stringByReplacingOccurancesOfString:@“r” withString:@“somethingElse”] will 
 work happily, as will [string stringByReplacingOccurancesOfString:@“→” 
 withString:@“⤜”].
 

This is true only if your sources are encoding in UTF-8 (which is the only 
encoding supported by clang AFAIK, and the only encoding that should ever be 
used anyway).

-- 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: ARC vs Manual Reference Counting

[Jean-Daniel Dupas]

Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit :

 
 On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote:
 
 Thirded. I thought I wouldn't like it. As soon as I didn't have to manage 
 retains and releases of temporary objects, the discipline completely left my 
 mind. Now whenever I go back to non-ARC code I invariably make a ton of 
 memory management errors, most of which are caught by the analyzer.
 
 --Kyle Sluder
 
 On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote:
 
 Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d 
 find weird errors that would be caused by some over-released object. We cut 
 a ton of code with ARC, and in the end we saw reliability go up and 
 actually even some performance.
 
 ARC is a win. The only place it really got a bit hairy was CF objects. I 
 wish ARC would work with them a bit more.
 
 On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote:
 
 They’re a _lot_ easier. It might not look that way when you’re reading 
 about all the details, or converting existing code, because then you’re 
 focusing on the rare edge cases. But for the most part when actually coding 
 you can simply ignore ref-counting. Your code becomes more compact and 
 readable, and you’re less likely to make mistakes.
 
 I *completely* agree with you with regards to memory management being hard to 
 get reliably right (not hard to get right, hard to get reliably right), and 
 weird errors all the time caused by memory management going wrong.  ARC is a 
 major boon in this regard.
 
 However, I have to say, I have had the complete opposite experience with 
 regards to performance.  Having measured various projects before and after 
 converting to ARC, I have seen numbers between 30% and 100% slowdown with 
 ARC.  The average is probably around 50%.  I have never seen performance 
 improve when using ARC.


And does the profiler explicitly shows that ARC runtime code is the culprit ? 

-- 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: ARC vs Manual Reference Counting

[Jean-Daniel Dupas]

Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit :

 
 On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 
 Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit :
 
 
 On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote:
 
 Thirded. I thought I wouldn't like it. As soon as I didn't have to manage 
 retains and releases of temporary objects, the discipline completely left 
 my mind. Now whenever I go back to non-ARC code I invariably make a ton of 
 memory management errors, most of which are caught by the analyzer.
 
 --Kyle Sluder
 
 On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote:
 
 Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d 
 find weird errors that would be caused by some over-released object. We 
 cut a ton of code with ARC, and in the end we saw reliability go up and 
 actually even some performance.
 
 ARC is a win. The only place it really got a bit hairy was CF objects. I 
 wish ARC would work with them a bit more.
 
 On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) 
 wrote:
 
 They’re a _lot_ easier. It might not look that way when you’re reading 
 about all the details, or converting existing code, because then you’re 
 focusing on the rare edge cases. But for the most part when actually 
 coding you can simply ignore ref-counting. Your code becomes more compact 
 and readable, and you’re less likely to make mistakes.
 
 I *completely* agree with you with regards to memory management being hard 
 to get reliably right (not hard to get right, hard to get reliably right), 
 and weird errors all the time caused by memory management going wrong.  ARC 
 is a major boon in this regard.
 
 However, I have to say, I have had the complete opposite experience with 
 regards to performance.  Having measured various projects before and after 
 converting to ARC, I have seen numbers between 30% and 100% slowdown with 
 ARC.  The average is probably around 50%.  I have never seen performance 
 improve when using ARC.
 
 
 And does the profiler explicitly shows that ARC runtime code is the culprit 
 ? 
 
 Yes, it does.  If you’d like an example to verify this behaviour with, play 
 with converting https://github.com/beelsebob/CoreParse to ARC, and profiling 
 the result.  This is the example that showed 100% slowdown initially.  The 
 last time I tried this with with Xcode 4.5, and after I’d added a bunch of 
 extra autorelease pools all over the place which reduced ARC’s overhead to 
 “only 50%.  This in itself suggests to me that ARC causes a significant 
 increase in the number of autoreleased objects (which surprised me given the 
 runtime optimisation to get rid of autorelease/retain pairs in callee/caller).

I'd be interested to dig a little further in what cause the slowdown. Do you 
have some sample code/file that can be used to stress the library and profile 
it ? 

-- 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: ARC vs Manual Reference Counting

[Jean-Daniel Dupas]

Le 9 sept. 2013 à 11:54, Tom Davie tom.da...@gmail.com a écrit :

 
 On 9 Sep 2013, at 11:49, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 
 Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit :
 
 
 On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 
 Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit :
 
 
 On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote:
 
 Thirded. I thought I wouldn't like it. As soon as I didn't have to 
 manage retains and releases of temporary objects, the discipline 
 completely left my mind. Now whenever I go back to non-ARC code I 
 invariably make a ton of memory management errors, most of which are 
 caught by the analyzer.
 
 --Kyle Sluder
 
 On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote:
 
 Bingo. We’ve been working with Cocoa/Obj-C for many years, and still 
 we’d find weird errors that would be caused by some over-released 
 object. We cut a ton of code with ARC, and in the end we saw 
 reliability go up and actually even some performance.
 
 ARC is a win. The only place it really got a bit hairy was CF objects. 
 I wish ARC would work with them a bit more.
 
 On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) 
 wrote:
 
 They’re a _lot_ easier. It might not look that way when you’re reading 
 about all the details, or converting existing code, because then you’re 
 focusing on the rare edge cases. But for the most part when actually 
 coding you can simply ignore ref-counting. Your code becomes more 
 compact and readable, and you’re less likely to make mistakes.
 
 I *completely* agree with you with regards to memory management being 
 hard to get reliably right (not hard to get right, hard to get reliably 
 right), and weird errors all the time caused by memory management going 
 wrong.  ARC is a major boon in this regard.
 
 However, I have to say, I have had the complete opposite experience with 
 regards to performance.  Having measured various projects before and 
 after converting to ARC, I have seen numbers between 30% and 100% 
 slowdown with ARC.  The average is probably around 50%.  I have never 
 seen performance improve when using ARC.
 
 
 And does the profiler explicitly shows that ARC runtime code is the 
 culprit ? 
 
 Yes, it does.  If you’d like an example to verify this behaviour with, play 
 with converting https://github.com/beelsebob/CoreParse to ARC, and 
 profiling the result.  This is the example that showed 100% slowdown 
 initially.  The last time I tried this with with Xcode 4.5, and after I’d 
 added a bunch of extra autorelease pools all over the place which reduced 
 ARC’s overhead to “only 50%.  This in itself suggests to me that ARC 
 causes a significant increase in the number of autoreleased objects (which 
 surprised me given the runtime optimisation to get rid of 
 autorelease/retain pairs in callee/caller).
 
 I'd be interested to dig a little further in what cause the slowdown. Do you 
 have some sample code/file that can be used to stress the library and 
 profile it ? 
 
 Sure, there’s a simple example at https://github.com/beelsebob/ParseTest/, 
 alternatively, you can profile the test cases included with CoreParse.


Interesting. Actually, after doing a naive ARC migration I find a 30%slow-down 
on this sample.  

It look like the main slowdown is induced by an increase of retain/release 
calls introduced by extra-safety.

Each time you send a message to an object, the compiler assumes the object may 
be released by the message, and so if you need to use this same object again 
after the message, the compiler make sure it was not released by including a 
retain/release.

For instance, CPItem isEqual: method implemented like this:

[object isItem]  (object-xxx == xxx)

ends up generating something like this:

object_retain(object);
[object isItem]  (object-xxx == xxx)
object_release(object),

And such method are in hot path (as they are used for hash collection lookup).

Unfortunately, I don't know how to tell the compiler to avoid this useless 
safety.


-- 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: 30x faster JSON date parsing

[Jean-Daniel Dupas]

Le 9 sept. 2013 à 18:11, Jens Alfke j...@mooseyard.com a écrit :

 Parsing dates from strings can be surprisingly expensive — more than once 
 I’ve seen it show up as the primary hot-spot in code that reads files or 
 parses network data. NSDateFormatter is very flexible, but you pay for that 
 in speed. If you only need to parse a single simple date/time format you can 
 do a lot better.
 
 A couple of days ago Anrurag Mishra wrote a blog post[1] demonstrating that 
 you can get about 14x faster performance (yes, 14 *times* faster) by calling 
 SQLite’s built-in strftime function. (Actually, my experience is that it’s 
 30x faster, but I was probably running on different hardware. YMMV.) His code 
 simply compiles and runs a SQL “SELECT” statement that calls strftime — I 
 decided to do better than that by extracting the C code from SQLite that does 
 the actual parsing, and making a direct API for it. That about doubles 
 performance again. Here are some benchmark results (run on a 2012 MacBook 
 Pro):
 
 [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took  26.97 µsec
 [fg160,160,160;16:34:42.709| [fg0,128,0;[;sqlite3 strftimetook   0.89 
 µsec (30x)
 [fg160,160,160;16:34:46.788| [fg0,128,0;[;-dateWithJSONObject took   0.68 
 µsec (40x)
 [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook   0.47 
 µsec (58x)
 
 (Here CBLParseDate is the raw function that returns a UNIX timestamp, and 
 -dateWithJSONObject is a wrapper method that returns the same time as an 
 NSDate object, which of course has extra overhead.)
 
 Now, the tradeoff is that the optimized code parses only ISO 8601 dates — 
 this is the informal standard used with JSON, so it’s become really common. 
 It looks like “2013-09-09T17:52:12Z”. It’s certainly possible to munge this 
 code to parse a slightly different format, but you’re on your own there!
 
 You can grab my code (which is just a hack-and-slash of Richard Hipp’s SQLite 
 code) from the Couchbase Lite repo[2]. It has no dependencies on anything but 
 the C standard library, so it should be easy to drop into your own projects.
 

Isn't it possible to parse it using the libc function strftime ? How does it 
compare to the other solutions ?

-- 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: NSValue valueWithBytes:objCType:

[Jean-Daniel Dupas]

Le 24 août 2013 à 22:09, Andreas Grosam agro...@onlinehome.de a écrit :

 What's the purpose of NSValue's class method 
 
 + (NSValue *)valueWithBytes:(const void *)value objCType:(const char *)type; ?
 
 It seems, NSValue will simply memcpy the content of value, and somehow 
 determine the size in bytes from the string given in type. Is that reliable 
 at all? (I have major doubts).
 
 
 It also seems, despite making the illusion having knowledge about the 
 underlaying type, NSData fails to compare correctly two NSData objects which 
 have been initialized by the same Objective-C  type.
 
 
 That is, this code is generally unsafe:
 
 struct a_s {
   unsigned char _b;
   long _l;
 };
 
 -(void) foo {
   struct a_s;
 
   // suppose, we scramble some bits on the stack …
 
   a._b = 0;
   a._l = 1;
 
   b._b = a._b;
   b._l = a._l;
 
   NSValue *a_encoded = [NSValue valueWithBytes:a objCType:@encode(struct 
 a_s)];
   NSValue *b_encoded = [NSValue valueWithBytes:b objCType:@encode(struct 
 a_s)];
 
   assert([a_encoded isEqualToValue: b_encoded]);  // May fail!
 }
 
 
 The assert may fail, since apparently NSData simply performs a memcpy. This 
 of course fails miserably if we intended to compare the _struct_ values. 
 
 Nonetheless, NSData pretends to be able to return the correct result when 
 comparing the encoded values. Well, of course this may be considered by 
 NSData as correct - despite it's different to comparing the corresponding 
 struct values - since only NSData knows and defines what makes a NSValue 
 equal to another ;)
 

When compiling a struct, the compiler add padding where needed so that each 
field is aligned as required by the ABI. The padding can contains any value and 
nothing force it to be initialized to 0.
When you memcpy a struct, you include the padding, which can contains anything. 
When you restore the value, all field are restored properly though, but there 
is no guarantee that a memcmp of two struct with all field containing the same 
value will always returns the same result.

 So again, I cannot see where this feature can be ever sensible, and does not 
 simultaneously introduce more harm than use.
 
 Additionally, I'm worried about the fact, that a *particular Apple library* 
 will use the above technique to *compare structs*.


That's not a problem specifics to NSValue. You should know what you do when 
manipulating structs.

-- 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: repeating timer with run now

[Jean-Daniel Dupas]

Le 22 août 2013 à 15:36, Torsten Curdt tcu...@vafer.org a écrit :

 I have some piece of code that I want to run every x seconds but I
 also want to be able to trigger a run now that will reset the
 upcoming cycle.
 
 I think I would know plenty of ways to implement this (ranging from
 simple NSTimer to select() style signaling to threading with
 conditions) but I am looking for the most elegant way - preferably
 with GCD.
 
 Scheduling a block is easy with GCD - but can you also notify that
 block for immediate execution later on?
 
 Just would love to hear opinions on how you would tackle this
 admittedly easy problem the most elegant way.


Why not just keeping a reference on your scheduled block and simply call 
dispatch_async when you want to execute it immediately ?

-- 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: repeating timer with run now

[Jean-Daniel Dupas]

Le 22 août 2013 à 16:08, Torsten Curdt tcu...@vafer.org a écrit :

 Why not just keeping a reference on your scheduled block and simply call 
 dispatch_async when you want to execute it immediately ?
 
 It would not re-schedule the timer. So the block could potentially be
 run twice without much of the desired delay in between.
 
 The logic should be something along the lines of
 
  def run_now
invalidate timer (if there is one running)
run block
schedule timer to run block in x seconds
  end
 
 Just to explain the desire behaviour.


OK, so I think you can just call dispatch_source_set_timer() each time you want 
to immediately execute your timer and reschedule it, passing 'now' as 'start' 
argument and your interval as 'interval' argument.

-- 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: predefined macro iOS vs OS X

[Jean-Daniel Dupas]

Le 17 août 2013 à 17:55, Marcel Weiher marcel.wei...@gmail.com a écrit :

 
 On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote:
 
 On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de 
 wrote:
 On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote:
 Xcode does know this. But if you're building for 32-bit OS X, it will 
 correctly complain.
 
 When I build for Mac OS X CGRect is accepted.
 But when I build for iOS then NSRect creates Use of undeclared identifier 
 NSRect did you mean NSSet
 
 Stop using NSRect in your method prototypes and just use CGRect.
 
 
 This is certainly pragmatic, effective advice.
 
 PetPeeve
 
 However…if you care as much about dependency management as I do (and chances 
 are you don’t), and don’t have a direct dependency on CoreGraphics in that 
 code (and chances are you do), then this is slightly stomach-churning, in 
 addition to pragmatic and effective.

You don't have to add explicit dependency to anything as NSGeometry.h already 
does that for you.
Importing Foundation.h is enough to use CGRect on both OS X and iOS.

-- 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: Major Xcode irritation

[Jean-Daniel Dupas]

Le 12 août 2013 à 22:22, Kyle Sluder k...@ksluder.com a écrit :

 On Mon, Aug 12, 2013, at 01:11 PM, Jens Alfke wrote:
 
 On Aug 12, 2013, at 12:31 PM, Graham Cox graham@bigpond.com wrote:
 
 XCode then refuses to build because the header file mod date no longer 
 matches what was used when the precompiled headers were built.
 
 Really?! Precompiled headers are automatically regenerated if any of the
 headers have been touched. There shouldn’t be any error. What’s the exact
 error?
 
 Not in this case, I'm afraid. I've seen the exact issue Graham
 describes. The compiler simply fails to build, complaining that the PCH
 is older than the headers.
 
 --Kyle Sluder


I guess that as an optimization, Xcode does not check all SDK (or system) 
headers, and just assume they do not change, so it failed to detect the change, 
and do not recompile the precompiled headers.

I also gut similar issues when I replace clang by a more recent version. Doing 
a clean / build had always solve the issue for me.

-- 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: Mixing Obj-C and C methods

[Jean-Daniel Dupas]

While all theses methods may look valid, what not simply use a static variable 
declared in your file ?

Instead of trying to use complex approach to hide the fact you need a global, 
just use one, and don't try to reuse the existing one for things there are not 
designed to do.


static id myCallbackHandler;

void someCallBack() {
[myCallbackHandler handleCallBack];
}

- (void)foo {
myCallbackHandler = self;
callCFunctionWithCallBack(someCallBack);
myCallbackHandler = nil;
}


Le 30 juil. 2013 à 15:44, Maxthon Chan xcvi...@me.com a écrit :

 My common way of handling this would be NSNotificationCenter. It is a 
 singleton so I am always sure that it is there, and I can wrap all parameters 
 into the userInfo dictionary.
 
 Sent from my iPhone
 
 On 2013年7月30日, at 21:19, KappA rejek...@gmail.com wrote:
 
 I sometimes just access my objc-objects from a C thread-proc via the
 AppDelegate (providing there's a trail to the object I need, which there
 usually is)... If the callback void pointer parameter isn't being used for
 something else, you can simply cast the object in there... or if you need
 multiple parameters you can create a struct that stores what you need and
 pass that. Not sure if this helps but figured I'd mention it.
 
 AppDelegate *d = [[UIApplication sharedApplication] delegate];
 
 
 
 On Tue, Jul 30, 2013 at 8:53 AM, lowell lowe...@me.com wrote:
 
 The first two parameters to the function have to be an id and a SEL ...
 
   typedef id (*IMP)(id, SEL, ...);
 
 ... (this is where we get self and _cmd, by the way) followed by the rest
 of the method params, if any.
 
 
 lowell
 
 
 On Jul 30, 2013, at 12:59 AM, Vincent Habchi vi...@macports.org wrote:
 
 Hi everybody,
 
 I have a very simple question: if I embed a C-function (more precisely,
 a callback from an external C-library) in an Obj-C object, can I expect
 this function to behave like a regular method? I.e. can it freely access
 ‘self’ and other attributes?
 
 Thanks a lot!
 Vincent
 
 
 
 
 ___
 
 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/lowellv%40me.com
 
 This email sent to lowe...@me.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/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/xcvista%40me.com
 
 This email sent to xcvi...@me.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/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: Mixing Obj-C and C methods

[Jean-Daniel Dupas]

Le 7 août 2013 à 17:32, Andy Lee ag...@mac.com a écrit :

 On Aug 7, 2013, at 3:47 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 Instead of trying to use complex approach to hide the fact you need a 
 global, just use one, and don't try to reuse the existing one for things 
 there are not designed to do.
 
 
 static id myCallbackHandler;
 
 void someCallBack() {
  [myCallbackHandler handleCallBack];
 }
 
 - (void)foo {
  myCallbackHandler = self;
  callCFunctionWithCallBack(someCallBack);
  myCallbackHandler = nil;
 }
 
 What if instance x does [x foo], and before someCallBack() gets called, some 
 other instance y does [y foo]?  There will be two future calls to 
 someCallBack(), and [y handleCallBack] will be called both times, which is 
 not the desired outcome.  This is a problem with any approach where the 
 callback looks in some global place, whether it's a static variable, a key 
 path from the app delegate, or whatever.

 Even if you are sure you won't run into the problem of the global variable 
 being overwritten, I think routing self through a global like 
 myCallbackHandler is more complex than:

If you intend to use it from multiple threads, so use a tls.

__thread id myCallbackHandler;

I was talking about the case where you have to deal with a poorly design API 
with no context pointer argument.
The case with a context argument should off course be handle the way you 
describe.

 void someCallBack(void *contextPtr) {
   [[(MyClass *)contextPtr autorelease] handleCallBack];
 }
 
 - (void)foo {
   callCFunctionWithCallBack(someCallBack, (void *)[self retain]);
 }
 
 or with ARC:
 
 void someCallBack(void *contextPtr) {
   [(__bridge_retained MyClass *)contextPtr handleCallBack];
 }
 
 - (void)foo {
   callCFunctionWithCallBack(someCallBack, (__bridge_transfer void *)self);
 }
 
 This assumes that the API includes a context pointer, but realistically, how 
 often won't that be the case?  (I don't actually know.)
 --Andy
 
 
 
 Le 30 juil. 2013 à 15:44, Maxthon Chan xcvi...@me.com a écrit :
 
 My common way of handling this would be NSNotificationCenter. It is a 
 singleton so I am always sure that it is there, and I can wrap all 
 parameters into the userInfo dictionary.
 
 Sent from my iPhone
 
 On 2013年7月30日, at 21:19, KappA rejek...@gmail.com wrote:
 
 I sometimes just access my objc-objects from a C thread-proc via the
 AppDelegate (providing there's a trail to the object I need, which there
 usually is)... If the callback void pointer parameter isn't being used for
 something else, you can simply cast the object in there... or if you need
 multiple parameters you can create a struct that stores what you need and
 pass that. Not sure if this helps but figured I'd mention it.
 
 AppDelegate *d = [[UIApplication sharedApplication] delegate];
 
 
 
 On Tue, Jul 30, 2013 at 8:53 AM, lowell lowe...@me.com wrote:
 
 The first two parameters to the function have to be an id and a SEL ...
 
 typedef id (*IMP)(id, SEL, ...);
 
 ... (this is where we get self and _cmd, by the way) followed by the rest
 of the method params, if any.
 
 
 lowell
 
 
 On Jul 30, 2013, at 12:59 AM, Vincent Habchi vi...@macports.org wrote:
 
 Hi everybody,
 
 I have a very simple question: if I embed a C-function (more precisely,
 a callback from an external C-library) in an Obj-C object, can I expect
 this function to behave like a regular method? I.e. can it freely access
 ‘self’ and other attributes?
 
 Thanks a lot!
 Vincent
 
 

-- 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: Mixing Obj-C and C methods

[Jean-Daniel Dupas]

Le 7 août 2013 à 18:34, Andy Lee ag...@mac.com a écrit :

 On Aug 7, 2013, at 12:04 PM, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 If you intend to use it from multiple threads, so use a tls.
 
 __thread id myCallbackHandler;
 
 I did not know about __thread, thanks for this.  By using tls you're 
 effectively having each thread store the info that would have been stored by 
 the implementation of the callback's context pointer, if it had one.
 
 If [x foo] and [y foo] are called in the same thread, then that thread's 
 myCallbackHandler can still get clobbered if the callback is asynchronous.  
 So I guess you'd have to be careful to always call -foo in a separate thread, 
 or implement it to always spawn a thread.

And even with a synchronous API, the TLS approach is fragile as the API as to 
guarantee that the callback is performed on the same thread.

But honestly, if I encounter such API and it does not let me pass a context 
pointer for the callback, I will just avoid it and use something else.

 I was talking about the case where you have to deal with a poorly design API 
 with no context pointer argument.
 The case with a context argument should off course be handle the way you 
 describe.
 
 I see, thanks.
 
 --Andy
 

-- 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: Search options

[Jean-Daniel Dupas]

Le 31 juil. 2013 à 18:52, Jerry Krinock je...@ieee.org a écrit :

 
 On 2013 Jul 31, at 08:45, dangerwillrobinsondan...@gmail.com wrote:
 
 what are the recommended search facilities for searching for things not 
 indexed by Spotlight?  Or am I limited to task wrappers or NSFileManager 
 directory enumerations? Clearly that could take a lot of time and resources 
 to search that way.
 
 Several years ago I looked into this and concluded that the fastest, 
 *reliable* file search on Mac OS X was still the ancient 
 PBCatalogSearchSync() or PBCatalogSearchAsync().  Does anyone know a more 
 modern API which can beat these?

I don't know about modern API, but I know about low level way to query the FS: 
searchfs(3)

I think you can achieve performances equivalent to what you get using 
PBCatalogSearchSync using this function.


-- 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: Mixing Obj-C and C methods

[Jean-Daniel Dupas]

Le 30 juil. 2013 à 10:27, Vincent Habchi vi...@macports.org a écrit :

 Rick,
 
 thanks for answering, because what I found on the Internet seems 
 contradictory. Some say that if the C function is placed inside the 
 implementation block, then it can access attributes as if it were a true 
 Obj-C method; some say otherwise. So it’s a bit difficult to find a 
 definitive answer thereon.

If it is in the implementation block, you can access all private ivar and 
property, but only if you have a reference to self in the first place.

For instance, you can have this:

@implementation Foo {
id privateVar;
}

static inline void internalInlineFunction(Foo *self) {
// do something with self-privateVar.
}

- (void)publicMethod {
internalInlineFunction(self);
}

@end

I'm using this trick when I need inline code (something that can't be done with 
Obj-C method), but for a callback, I would rather just keep it simple and 
simply call a method to handle it.

@implementation Foo

static void callback(void *ctxt) {
// Sidenote; 'self' is a reserved keyword only inside Obj-C method 
body. You can use it freely elsewhere, and it does not have special meaning.
// that's why you have to pass it as explicit parameter.
Foo *self = (Foo *)ctxt;
[self handleCallback];
}

- (void)handleCallback {
// 
}

@end


 
 Having said that, most callback APIs allow you to pass a context parameter 
 that gets passed back to your C callback. Often times, this context 
 parameter is a void* you pass in along with a pointer to your callback 
 function. You can pass self in this parameter when you register the 
 callback, then cast it inside your callback back to MyClass* (or whatever 
 your class is).
 
 Yes, right; it’s a SQLite callback, the first parameter is a void *. I wanted 
 to pass a pointer to a structure containing both a unique query id (out of 
 uuid) and a pointer to self, but got told off by ARC because it apparently 
 forbids to embed pointers to Obj-C objects in C-structs. So I just 
 bridge-cast it to void *.
 
 Assuming the pointer to the struct is named ‘info’ and the field containing a 
 reference to ‘self’ is called ‘this’, [info-this someMethod] as well as 
 info-this-someAttribute are legal, aren’t they?
 
 Thanks a lot!
 Vincent
 
 
 ___
 
 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: Mixing Obj-C and C methods

[Jean-Daniel Dupas]

Le 30 juil. 2013 à 17:25, Scott Ribe scott_r...@elevated-dev.com a écrit :

 On Jul 30, 2013, at 9:08 AM, Andy Lee ag...@mac.com wrote:
 
 I think it's subject to the same criticisms as *any* direct access to ivars, 
 although I agree it feels sketchier when done in plain C for some reason.
 
 Yes. Because what is the point of plain C functions in Objective-C files? 
 Local helpers that are not OOP, and do not go through method dispatch 
 overhead. To turn around and inject direct access to ivars in those is really 
 mixing metaphors.
 
 Which reminds me... instance methods can also directly access the ivars of 
 *other* instances of the same class.
 
 Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
 thing. But I knew it was possible ;-)

I think I don't have a single copyWithZone: implementation that does not use 
this feature.

Foo *copy = [super copyWithZone:];
copy-_myivar = _myivar;

Especially as all ivars are not exposed as properties.


-- 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: The cost of using objects rather than plain C variables

[Jean-Daniel Dupas]

Le 12 juil. 2013 à 08:41, Vincent Habchi vi...@macports.org a écrit :

 Hi!
 
 Sorry for this late answer, I was a bit swamped lately.
 
 NSData wouldn't let you, but NSMutableData would, with methods like 
 appendBytes:length:, appendData:, increaseLengthBy:, etc.  The underlying 
 buffer might have to move around if it cannot be extended in place, just as 
 it would if you use C realloc() calls.
 
 In fact, I overlooked that completely. I just fear building a buffer from 
 zero to something like 400,000 * 3 * 4 bytes = just under 5 MiB would imply 
 too many moves as you mention. 

If you know how large your data will be and want to avoid the realloc cost, you 
can just create your mutable data using -initWithCapacity: .
And even if the size end up to be larger than your initial capacity, the 
mutable data will do the right thing and increase the capacity.

 Now, I am anyway moving towards a binary file that would be fed directly into 
 the buffer rather than needing decoding, and partitioning it into several 
 chunks in order to optimize the number of triangles displayed. I think I’ll 
 use NSData to store these chunks.
 
 Thanks to all for the precious help!
 Vincent
 

-- 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: NSNotFound signed???

[Jean-Daniel Dupas]

Le 12 juin 2013 à 10:14, Oleg Krupnov oleg.krup...@gmail.com a écrit :

 there isn't enough address space to create a NSArray containing even 
 NSIntegerMax pointers.
 
 I knew someone will say this. Who needs more than 640 KB RAM after
 all? :) © Bill Gates
 

This has nothing to do with the amount of available RAM. The limitation is with 
the virtual memory system.
If you can have 2^64 bytes of address space, you can a max store 2^64 / 
sizeof(void *) pointers.

 What if I have sparse array etc.

If you have sparse array, so just don't write it using NSNotFound. We are 
talking about a well defined class and well defined API, not a potential non 
existing API that can use the wrong constant.

 One higher bit is actually twice as many elements. Why having
 NSUInteger at all if you can't use more than NSIntegerMax? This
 doesn't seem right.

Because you want to use an unsigned number to defined the number of element 
(having a negative number of elements does not make sense), and it is pointless 
and inefficient to to defined and used a 56bit integer type on actual 
architectures.

-- 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: NSURLConnection and 404

[Jean-Daniel Dupas]

Le 9 juin 2013 à 11:35, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 This works fine, but blocks my for 1 sec on a good day - who know how long if 
 the net is slow:
 
 url = something/which/might/exist/or/not.gif
 data = [ NSData dataWithContentsOfURL: url options: mask error: outError ];
 
 So I am trying to use NSURLConnection instead. Also works fine.
 
 Only: if my url does not exist, then the old method returned data = nil. Very 
 good.
 
 Using  NSURLConnection I always get some answer - either image data or a 
 lengthy string like:
 
 HTML 4.0 Transitional//EN
 html
   head
   titleError 404 - Page not found/title
   /head
   body bgcolor=#00
 [...]
 
 
 Is there a way to get just the status (in this case 404) without parsing the 
 data?
 I looked at the NSURLConnection delegate methods, but did not find anything 
 which looked appropriate.
 
 Gerriet.

The NSConnectionDelegate protocol has a method that pass you the response:

- (void)connection:(NSURLConnection *)connection 
didReceiveResponse:(NSURLResponse *)response

You can test if the response is of type NSHTTPURLResponse (which should always 
be the case when you send an HTTP request), and then use the 
-[NSHTTPURLResponse statusCode] method to get the status.


-- 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: NSMapTable with C strings as keys

[Jean-Daniel Dupas]

Le 30 mai 2013 à 08:35, Eric Wing ewmail...@gmail.com a écrit :

 On 5/29/13, Jens Alfke j...@mooseyard.com wrote:
 
 On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote:
 
 CFDictionary I did not formally do in the benchmark, but I did run on
 the side for curiosity. I found that the C-string to CFString
 conversion ended up putting it at the bottom of the list in terms of
 performance.
 
 It seems unfair to include the C-string-to-object conversion time in the
 benchmark, if what you’re trying to measure is hash-table performance. Did
 you include that in the benchmarks for the other languages too? (And using
 real Unicode-savvy string objects — I know Python has both types)?
 
 —jens
 
 In my introduction, I was fairly adamant that time lost to impedance
 mis-match should be measured because my interest was real performance
 in using these libraries for projects based in C. That conversion time
 is non-trivial.
 
 And yes, all languages I benchmarked had to go through the same rules
 (i.e. deal with const char*). This is why C++ std::string actually did
 not fare so well compared to some of the other languages. (And the
 magical optimizer did not come to the rescue.) For Python, I was not
 aware of Unicode vs. other APIs. Since the focus was C, I wasn't
 really thinking about Unicode. I used PyDict_SetItemString to insert a
 string (the source code is linked on that page somewhere).
 

I follow Jens on this one. Nothing prevent you to use CFDictionary with a C 
string directly or any other type.
You don't have to create CFString.

-- 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: NSMapTable with C strings as keys

[Jean-Daniel Dupas]

Le 29 mai 2013 à 00:46, Graham Cox graham@bigpond.com a écrit :

 
 On 28/05/2013, at 3:46 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
 
 I'd like to have a dictionary using C strings as keys (because I
 already have const char* strings and would like to spare on creating
 NSString wrappers)
 
 
 For the sake of avoiding something you *assume* to be slow, or inefficient, 
 you've taken the discussion in a direction that is vastly more complicated.
 
 Why not just create NSString wrappers? By using the 
 -initWithBytesNoCopy:length:encoding:freeWhenDone: method you can avoid it 
 copying the actual C string characters, it literally just becomes a thin 
 wrapper.
 
 K.I.S.S.! If you can prove this approach is a problem by actual profiling, 
 then OK, then you can talk about a more complex solution.

It may be a thin wrapper. Unlike with NSData that actually wraps the passed 
buffer, NSString does not make any guarantee about what it does.
My experience is that most of the times, NSString with actually copy the bytes 
and create its own internal representation.

That said, even if NSString creates an internal representation, I agree that 
trying a more complex approach without profiling data is pointless.

-- 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: NSMapTable with C strings as keys

[Jean-Daniel Dupas]

Le 29 mai 2013 à 06:14, Oleg Krupnov oleg.krup...@gmail.com a écrit :

 Why not just create NSString wrappers? By using the 
 -initWithBytesNoCopy:length:encoding:freeWhenDone: method you can avoid it 
 copying the actual C string characters, it literally just becomes a thin 
 wrapper.
 
 In my case it's more about extra calls than extra memory but thanks! Didn't 
 know about this.
 

If method dispatch time is your main problem, just use CFString and 
CFDictionary API.

-- 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: NSMapTable with C strings as keys

[Jean-Daniel Dupas]

Le 28 mai 2013 à 08:25, Oleg Krupnov oleg.krup...@gmail.com a écrit :

 Hi Jens,
 
 I guess you may be right. But… two questions in this regard:
 
 1. I thought that isEqual method is alternative to hash method,
 because searching by key and searching by hash are two mutually
 exclusive methods of looking up values, aren't they?
 

No, they aren't. The hash is used to speed up the lookup.
The HashTable first uses the hash to find in which bucket the element is, and 
as the hash is not guarantee to be unique, it then use the isEqual method to 
determine what element in this bucket in the one you are looking for.

 2. What hash function you'd suggest in my case, that would calculate
 unsigned int on output, for C strings? Because calculating hash
 functions (such as md5) may be computationally expensive, which could
 undermine my entire idea of sparing extra few calls on creating
 NSStrings :)

The main issue with using c string, is memory management of your keys. NSString 
does that using ref counting, but you will have to take care of everything if 
you are using C string.
Avoiding NSString without being sure this will impact the performance is just 
premature optimization.

That said, there is 2 famous hash functions that are usually used for this kind 
of hashing: CityHash (http://code.google.com/p/cityhash/) and MurmurHash 
(http://code.google.com/p/smhasher/)

 Thanks!
 
 On Tue, May 28, 2013 at 9:08 AM, Jens Alfke j...@mooseyard.com wrote:
 
 On May 27, 2013, at 10:46 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
 
 Now, the problem is that sometimes when I try to get a value from the
 table, the MapTableKeyComparator function is not called at all, and
 NSMapGet returns NULL, thought immediate dump of the table shows that
 all previous records are perfectly present in the table.
 
 
 Probably because you haven’t implemented a hash function, only an equals
 function. I’m guessing NSMapTable’s default hash function merely hashes the
 key pointer itself, which means that if you pass it a different pointer to
 an equal C string, it won’t find anything.
 
 —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/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: NSCAssert in OS X and iOS

[Jean-Daniel Dupas]

Le 18 avr. 2013 à 18:31, Jens Alfke j...@mooseyard.com a écrit :

 
 On Apr 18, 2013, at 12:14 AM, Rick Mann rm...@latencyzero.com wrote:
 
 I had an NSAssert with varargs in a C routing in a .mm file. It compiled 
 fine in a Mac OS X app, but the same code in an iOS app bitches about too 
 many arguments. Is that right?
 
 Double-check that the warning isn't in fact correct. Clang has recently 
 (since Xcode 4.5?) gotten better at sanity-checking printf-style parameter 
 lists, which I find to be a real life-saver. It's possible that your iOS 
 target has this warning enabled but the OS X target doesn't.


This is a known issue that was recently solved on OS X. Declaration of NSAssert 
macros in (Obj-)C++ mode are broken (they don't use the vararg macro syntax 
that is supported by recent c++ compiler).

I didn't tried on iOS, but I suspect this is the very same issue that is not 
yet fixed in the SDK you are using.

-- 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: Objective-C Question

[Jean-Daniel Dupas]

Le 14 mars 2013 à 11:12, Richard Heard heard...@gmail.com a écrit :

 Your logic is clearly flawed. This only seems to replace occurrences of $ 
 with the word DOLLAR. 
 
 Also, if you are dealing with large strings, you could always use one of the 
 below idioms to reduce memory pressure.
 
 
 @autoreleasepool { }
 or 
 
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 [pool drain];
 
 -R
 

Or simply work on a mutable string when you plan to mutate it. 

 On 13/03/2013, at 3:07:30 AM, Dave d...@looktowindward.com wrote:
 
 
 On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
 
 On 3/13/13 9:36 AM, Dave wrote:
 
 On 12 Mar 2013, at 21:34, Graham Cox wrote:
 
 
 On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com wrote:
 
 If that is the case, then how do you signal to the compiler/analyzer 
 that you
 are returning a retained object?
 
 In general you shouldn't return a retained object (unless it's temporarily
 retained and will be autoreleased of course)
 
 Why? Where does it say this?
 
 https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
 
 And Autorelease is evil and should never be used if it can be avoided!
 
 Nonsense.
 
 
 Obviously, it isn't evil, but from experience of working on 5 or more major 
 iOS applications, I've found most bugs were caused as a consequence of 
 autorelease, that's why I avoid it if possible. I don't have a problem with 
 memory management, it's simple as long as you follow the rules.
 
 Avoiding autorelease makes it run faster anyway and makes the whole app more 
 robust in general. Autorelease in the wrong hands can cause massive 
 inefficiencies that you'd never code otherwise, here are some examples of 
 what I mean:
 
 -(NSString*) processString:(NSString*) theString
 {
 NSString*myWorkString;
 
 myWorkString = [theString stringByReplacingOccurencesOfSting:@/b 
 with:@BOLD];//1
 myWorkString = [theString stringByReplacingOccurencesOfSting:@/i 
 with:@ITALICS]; //2
 myWorkString = [theString stringByReplacingOccurencesOfSting:@/u 
 with:@UNDERLINE];   //3
 myWorkString = [theString stringByReplacingOccurencesOfSting:@* 
 with:@ASTERISK]; //4
 myWorkString = [theString stringByReplacingOccurencesOfSting:@ 
 with:@AMPERSAND];//5
 myWorkString = [theString stringByReplacingOccurencesOfSting:@$ 
 with:@DOLLAR];   //6
 
 and so on
 
 return myWorkString;
 }
 
 This code creates 5 strings that are not needed and will clog up memory 
 until the runloop is called or the pool is drained. Imagine there were 30 
 such replacements going on and the initial theString is large ( 100K) and 
 there are 100's of these strings.
 
 You don't need a degree in applied meta physics to see where this is going. 
 It's not the fault of autorelease I know, it's the fault on inexperienced 
 developers or people that blindly follow rules.
 
 The underlying problem is that it makes the above method data dependent 
 without really drawing much attention to this fact. I actually had a bug 
 that was caused by this. I worked on an iPad app for an International 
 Newspaper. The App was working ok, until one day it crashed a 5 AM when the 
 new edition was published and the iPad client software downloaded and 
 processed it. When it got to the sports section a method similar to the 
 above (although a lot more complex with a LOT more autorealsed objects) 
 crashed. I got in a 6 AM and it took me a good while to figure out what was 
 wrong. On that particular day, the paper published the football (soccer) 
 league tables for the whole of the UK. Apart from there being a loads of 
 data, it was also heavily attrubuted, bold, italics, colours etc. Well it 
 was too much for the method and when it had built up around 80 to 100 MB of 
 useless autoreleased strings, it crashed!!
 
 There are loads of other problems I come across as a side effect of junior 
 (and sometimes senior) developers using autorelease, but I think the above 
 described above was the worst.
 
 That's why I say it's evil and I avoid it with a vengeance. So why do you 
 think it's a force for good?
 
 Besides all this, is it really so hard to add:
 
 [ release];
 
 It's less typing than autorelease anyway!!!
 
 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/heardrwt%40gmail.com
 
 This email sent to heard...@gmail.com
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or 

Re: Another Gnarly Objective-C Question!

[Jean-Daniel Dupas]

Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit :

 
 On 12 Mar 2013, at 2:08 AM, Graham Cox wrote:
 in a + method, [self class] === self. Once you've got that, you've got it.
 
 
 
 You're overthinking this.
 
 A class method is just an instance method of the class object. No magic at 
 all. So all this confusion you've caused yourself about [super class] and so 
 on is wholly unnecessary to correctly use class methods.
 
 To be very slightly pedantic, the only magic here is 'super' --- sending a 
 message to super (which you can only do from a method implementation) is 
 special syntax that searches for the method starting with the 
 implementation's class's superclass, rather than at the receiver's actual 
 class. Everything else is non-magic. (In general, that's been one of the 
 strengths of ObjC: very little magic.)
 

To be ever more pedantic, there is other magic involved when sending a message 
to a class.
If there is no class method that matches the selector, the runtime will then 
search for instance methods of the root class. So you can use NSObject instance 
(like performSelector:) method on all NSObject subclasses.

http://www.sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html

-- 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: Another Gnarly Objective-C Question!

[Jean-Daniel Dupas]

Le 13 mars 2013 à 18:13, John McCall rjmcc...@apple.com a écrit :

 On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit :
 On 12 Mar 2013, at 2:08 AM, Graham Cox wrote:
 in a + method, [self class] === self. Once you've got that, you've got it.
 
 
 
 You're overthinking this.
 
 A class method is just an instance method of the class object. No magic at 
 all. So all this confusion you've caused yourself about [super class] and 
 so on is wholly unnecessary to correctly use class methods.
 
 To be very slightly pedantic, the only magic here is 'super' --- sending a 
 message to super (which you can only do from a method implementation) is 
 special syntax that searches for the method starting with the 
 implementation's class's superclass, rather than at the receiver's actual 
 class. Everything else is non-magic. (In general, that's been one of the 
 strengths of ObjC: very little magic.)
 
 
 To be ever more pedantic, there is other magic involved when sending a 
 message to a class.
 If there is no class method that matches the selector, the runtime will then 
 search for instance methods of the root class.
 
 Note that this isn't magic really;  it's a quirk of the type system (both 
 formal and dynamic).  The root metaclass is a subclass of the root class.

Yes, nothing is magic if the magician reveals its tricks, that's why he should 
not do that  ;-)

 This can be problematic if you really want your root class to have a layout 
 that's bigger than just an isa field, because the ABI and runtime just 
 hardcode the layout of classes and there is no room for extra fields there — 
 thus you need to be sure that anything using your extra fields is never 
 invoked on a class object.

I usually avoid this kind of issue by not writing root class. The extra fields 
issue is not the only one that a root class can have. Even methods that do not 
access ivars should take care of the Class case (retain/release/autorelease for 
instance).

-- 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: Fast user switching notifications

[Jean-Daniel Dupas]

Le 11 mars 2013 à 23:25, Jean Suisse jean.li...@gmail.com a écrit :

 Dear All,
 
 There may be several approaches to solve the issue I am about to describe, 
 either on the userland side or on the kernel side... or in-between, using a 
 daemon.
 
 Current situation
 A bsd kernel extension communicates with a regular userland application 
 (called theApp). The kext gathers statistics, sends data to the user, takes 
 orders from the user, etc.. There are two-way communications initiated by 
 both sides using control sockets – There may be no market for such app, it is 
 more of investigation tool, but that's irrelevant.
 
 Goal
 I would need to handle fast user switching, so that data sent by the kext are 
 directed towards the user that can actually handle them. This user is the one 
 owning the graphic interface (is there a technical word to say that?).
 
 Issue
 When switching from user(A) to user(B) (using fast user switching for 
 instance), user(A) no longer owns the graphic interface and theApp(A) is no 
 longer able to interact with the user and give the required feedback to the 
 kext. User(B) starts theApp(B) and interacts normally with the kext. Then, 
 when switching from B to A, the same issue occurs in reverse.
 
 Solution
 One approach would be to have theApp(A) launched by user(A) to be notified 
 when user(A) looses access to the graphic interface.
 When switching back to user(A) theApp(A) and theApp(B) would also get 
 notified.
 
 I read this document 
 (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPMultipleUsers/Concepts/UserSwitchNotifications.html),
  but it seems that there is some race condition occurring, maybe as a result 
 of interacting with the kernel (the kext must perform a few tasks before 
 allowing theApp(A) to disconnect and theApp(B) to connect).
 
 Are there any other alternatives, from the userland side ?


There is an other way to track the current user: using the SystemConfiguration 
framework notification:

http://developer.apple.com/library/mac/#qa/qa1133/_index.html

-- 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: Objective-C Question

[Jean-Daniel Dupas]

Le 12 mars 2013 à 20:15, Dave d...@looktowindward.com a écrit :

 
 On 12 Mar 2013, at 18:50, Jens Alfke wrote:
 
 
 On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote:
 
 However, that wouldn't be an idiomatic implementation.  The usual 
 expectation is that allocating methods, like +new methods, construct an 
 object *of type self* (at least).
 
 Are you just quibbling about the prefix “new-“? The specific method +new is 
 expected to create a new instance of the receiving class, yes. There may be 
 a convention (I can’t remember?) that class methods prefixed “new-” are 
 intended to do the same.
 
 I'm not sure if its a convention, but it does make sense, for instance, I've 
 been code like this before.
 
 -(NSDictionary) newDictForSomethingWithInfo:(Info*) theInfo
 {
 // returns an dictionary allocated and initialized
 }
 
 somewhere else in the same class:
 
 myDict = [self newDictForSomethingWithInfo:myInfo];
 
 Which keeps the compiler/analyzer happy in non-ARC and works ok with ARC 
 enabled. If this isn't a convention then it should be IMO unless there is 
 another prefix used? allocDict would work, but this is as bad or as good as 
 new in this respect.
 

According to the clang manual: 
http://clang.llvm.org/docs/LanguageExtensions.html#related-result-types

The related result type can also be inferred for some methods. To determine 
whether a method has an inferred related result type, the first word in the 
camel-case selector (e.g., “init” in “initWithObjects”) is considered, and the 
method will have a related result type if its return type is compatible with 
the type of its class and if:

• the first word is “alloc” or “new”, and the method is a class method, 
or
• the first word is “autorelease”, “init”, “retain”, or “self”, and the 
method is an instance method.

So new prefixed class method should return an instance of the calling class, 
but instance methods are just required to returned a retained object of any 
kind.


-- 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: What is the meaning of idMyProtocol?

[Jean-Daniel Dupas]

http://www.catb.org/esr/faqs/smart-questions.html

Le 18 févr. 2013 à 10:20, Christ Levesque iapplechocol...@me.com a écrit :

 
 ___
 
 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: LSOpenURLsWithRole failure

[Jean-Daniel Dupas]

Le 11 déc. 2012 à 18:12, Vojtěch Meluzín meldaproduct...@gmail.com a écrit :

 Hi,
 
 one of the customers reported that on his 10.8.2 our installer failed to
 even run and in the terminal there was this message:
 
 LSOpenURLsWithRole() failed with error -10810 for the file
 /Users/visa/Downloads/mxxx_7_05_setupmac/mxxx_7_05_setupmac.app.
 
 I have checked that there is no call to the god damn LSOpenURLsWithRole,
 whatever it is. Any ideas what's wrong?


Unfortunately error -10810 means kLSUnknownErr (Unexpected internal error), so 
it does not give much information. 
You may have a look in the Console Utility, sometimes it contains more useful 
message (especially launchd error as it is responsible of launching an app when 
you double clic on it).

Look for something like: 
com.apple.launchd.peruser.501[217]: ([0x0-0x732732].you.bundle.id[10908]) Job 
failed to exec(3) for weird reason: errno code

It may happen when the executable file (Contents/MacOS/exec) in the bundle 
has wrong permission and is not executable.
I sometime see this kind of error when an application archive is uncompress on 
a PC and then copied on the Mac, or when something goes wrong with the download.


-- 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: How to implement readonly property

[Jean-Daniel Dupas]

Le 9 déc. 2012 à 02:27, Richard Heard heard...@gmail.com a écrit :

 Greg, 
 
 So, from what you are saying, either of these snippets should be valid, right?
 
 +(id)sharedInstance{
static id _sharedInstance = nil;
 
   …

OSMemoryBarrier();
return _sharedInstance;
 }

OSMemoryBarrier are not cheap. If dispatch_once uses it only on the write side, 
then it should be faster than forcing a full barrier at each access.

By the way, as nobody mention it until then, all this discussion look like to 
me as pointless premature optimization. If accessing your singleton is a 
bottleneck (and nothing tell us it is), there is probably simpler way to avoid 
this cost.

 vs
 
 +(id)sharedInstance{
static id _sharedInstance = nil;
 
static dispatch_once_t onceToken;
dispatch_once(onceToken, ^{
_sharedInstance = [[super allocWithZone:NULL] init];
});
 
return _sharedInstance;
 }
 
 
 Any massive advantages / disadvantages with either approach?
 
 -Richard
 
 On 08/12/2012, at 4:45:37 PM, Greg Parker gpar...@apple.com wrote:
 
 On Dec 8, 2012, at 11:17 AM, Steve Sisak sgs-li...@codewell.com wrote:
 At 10:24 AM -0800 12/8/12, Kyle Sluder wrote:
 On Dec 8, 2012, at 10:06 AM, Steve Sisak sgs-li...@codewell.com wrote:
 
 Further, if writes were not complete at the end of the block, the 
 construct would besentially useless for its intended purpose.
 
 By the way, you're wrong about this too. All @synchronized does is act as 
 a mutex around a code block. It does not cause the compiler to reorder 
 instructions and issue memory barriers in such a way that initialization 
 is guaranteed to precede assignment from the perspective of all threads.
 
 Please cite a source for this assertion.
 
 Source: me, the author of the current @synchronized implementation. 
 @synchronized performs the same synchronization as a pthread mutex.
 
 
 From:
 
 https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html
 
 If you are already using a mutex to protect a section of code, do not 
 automatically assume you need to use the volatile keyword to protect 
 important variables inside that section. A mutex includes a memory barrier 
 to ensure the proper ordering of load and store operations.
 
 To a close approximation, you should pretend that `volatile` does not exist 
 in C-based languages.
 
 The above says that if you already have mutexes then you do not need 
 `volatile`. The mutex alone does all of the work. 
 
 Conversely, `volatile` with no mutex is also not a safe multithreading 
 pattern.
 
 
 I acknowledge that, without proper memory barriers, double-checked locking 
 is problematic, but am providing an example using a construct which I'm 
 fairly sure uses proper memory barriers.
 
 - (NSDictionary *)someDictionary;
 {
 if (!_someDictionary)
 {
 @synchronized (self)
 {
   if (!_someDictionary)
   {
 // create a temp dictionary (might take some time)
  _someDictionary = temp;
   }
 }
 }
 
 return _someDictionary;
 }
 
 
 The example provided does not use proper memory barriers. 
 
 In general, memory barriers need to occur in pairs, one on each thread. The 
 coordination of the two memory barriers achieves the desired 
 synchronization, so that both sides observe events occurring in the same 
 order.
 
 Mutexes and similar constructs achieve this. The mutex lock() and unlock() 
 procedures form a barrier pair. Code running with the mutex held is 
 therefore correctly synchronized with respect to other code that runs with 
 the mutex held. But code running outside the mutex is not protected, because 
 it didn't call the barrier inside the lock() procedure.
 
 In faulty double-checked locking code, the problem is that the writer has a 
 memory barrier but the reader does not. Because it has no barriers, the 
 reader may observe events occur out of the desired order. That's why it 
 fails. (Here the writer is the thread actually calling the initializer and 
 the reader is a second thread simultaneously performing the double-check 
 sequence.)
 
 (Faulty double-checked locking code has a second problem because the 
 writer-side barrier inside the mutex unlock is the wrong barrier to use with 
 a reader that is not locking the mutex.)
 
 You need to do one of two things to fix the reader side of a double-checked 
 lock:
 * add appropriate barriers to the reader side, or 
 * cheat in a way that is guaranteed to work on all architectures you care 
 about.
 
 dispatch_once() actually cheats. It performs a very expensive barrier on the 
 writer side (much more expensive than the barriers used in ordinary mutexes 
 and @synchronized), which guarantees that no barrier is needed on the reader 
 side on the CPUs that run OS X and iOS. The expensive barrier on the reader 
 side is an acceptable trade-off because the writer path runs only once.
 
 
 -- 
 Greg Parker gpar...@apple.com Runtime Wrangler
 
 
 
 

Re: Notification for if User changes Finder Label on File

[Jean-Daniel Dupas]

You can use the libdispatch to monitor file changes (using 
DISPATCH_SOURCE_TYPE_VNODE).

You can also use a kqueue to look for change on a specific file.  If you want a 
Cocoa wrapper, there is the well known UKKQueue class available on the net.

Both solutions are far more efficient if you have to monitor only a couple of 
files.

Le 20 nov. 2012 à 19:21, Michael Starke michael.sta...@hicknhack-software.com 
a écrit :

 Sorry for asking this question again, but i did not find any more details 
 about how to improve what I want to achive or if the way i do it is the only 
 way to go.
 
 Therfore I'm politly asking again.
 
 Situation is, that I need to watch a file (Volume to be precise) for any 
 changes the user makes to it's label. Currently I have a FSEventStream 
 callback that watches the volume path and I react to 
 kFSEventStreamEventFlagItemXattrMod since this gets modified on a Label 
 change.
 
 Is there a more elegant way to look for this speical change or am I on the 
 right track?
 
 -Michael
 -- 
 ___m i c h a e l   s t a r k e
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com
 
 ___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com
 
 ___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther Straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitzt - dresden
 ___
 
 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: OS_OBJECT_USE_OBJC_RETAIN_RELEASE and xpc_release()

[Jean-Daniel Dupas]

Le 8 nov. 2012 à 14:54, Jerry Krinock je...@ieee.org a écrit :

 Update on email delays:  Greg, sorry it took so long to reply this; I was 
 waiting to see if your email would arrive.  Although I have definitely been 
 foiled by delays of several hours on this list for many months, it appears 
 that the even-longer delays I saw last week were due to IEEE mail servers in 
 New Jersey being hit by Hurricane Sandy.
 
 * * *
 
 On 2012 Nov 03, at 16:28, Greg Parker gpar...@apple.com wrote:
 
 If you build with the 10.8 SDK, and your deployment target is 10.8 or later, 
 then dispatch objects and XPC objects become Objective-C objects. If you use 
 ARC then they are ordinary ARC-managed objects and you do not retain and 
 release them yourself.
 
 You can temporarily revert to the old behavior by defining 
 OS_OBJECT_USE_OBJC=0.
 
 Yes, setting setting -DOS_OBJECT_USE_OBJC=0 in the Compiler Flags of the file 
 calling xpc_release(), which is compiled with ARC, fixed the problem.
 
 Going forward the solution is to remove your manual retain/release calls and 
 let ARC do the work.
 
 Are you saying that if a file is compiled with ARC, I should delete calls to 
 xpc_release()?  Read on…
 
 You might try re-running the ARC migrator on your ARC code and see if it 
 catches them.
 
 The little project was written with ARC from the ground up.  So I just ran 
 Edit ▸ Convert to Objective-C ARC on it, and  was told that No source file 
 changes are necessary.  The call to xpc_release() was not noticed.
 
 So, neither the xpc_release() documentation, nor the ARC migrator indicate 
 that I should remove the call to xpc_release().  Are they both missing the 
 boat?

Assuming you are targeting 10.8, yes you should remove all xpc_retain/release 
and dispatch_retain/release calls. 

-- 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