Re: Exiting non-POSIX threads?

[Graham Cox]

On 30/07/2013, at 7:43 PM, Quincey Morris  
wrote:

> On Jul 30, 2013, at 10:26 , Graham Cox  wrote:
> 
>> How often have you encountered an unexpected exception from some low-level 
>> code you don't own under circumstances you can't control? If your app 
>> crashed every time you'd soon have a reputation for unreliability that is in 
>> all probability undeserved. On balance it's better to carry on with some 
>> minor glitch than "quit unexpectedly".
> 
> Surely the problem with this perspective is that the uncaught exception 
> results in an abrupt transfer of control from the point of the exception back 
> to (approximately) [NSApplication sendEvent:]?
> 
> If you don't own the low-level code where the exception was thrown, you can 
> have no confidence that non-stack data structures being maintained by that 
> code -- along with all of the intermediate levels of calling code -- are in 
> any usable state.
> 


I totally agree - from the point of view of a developer.

However, from the point of view of a) the user and b) the director of a company 
making and selling apps, it's not what you want to happen. Any crash is 
unacceptable - it makes the app look flaky and the user will lose faith in it 
and probably lose their data too. The vast majority of exceptions in practice 
are benign - much better to effectively ignore them and continue as best you 
can (which is very often with 100% functionality) than crash. If there are 
cases that come up that can be handled better, then those handlers can be added 
in later.

As an example, I had one recently where under very specific circumstances, the 
user could end up pushing the code into inverting a transform that had no 
inverse, e.g. a divide by zero. The Core Graphics framework throws an exception 
if you do that, but the specific circumstances had not been caught in testing 
because it was such a weird corner case. If my app crashed at that point, it 
would look very serious indeed, whereas the actual outcome for the user was a 
very minor graphical glitch. I now add a handler for that case that puts things 
back in a good state, but simply ignoring the original exception wasn't a 
disaster either.

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Kyle Sluder]

On Wed, Jul 31, 2013, at 12:07 AM, Graham Cox wrote:
> However, from the point of view of a) the user and b) the director of a
> company making and selling apps, it's not what you want to happen.

Within the past year or so, we moved all our apps to crashing on
uncaught exceptions. This change was supported by our CEO. And as far as
I'm aware, OmniFocus has _always_ crashed on uncaught exceptions.

Because crashing is better than corrupting the user's data.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[BUG?] LSUIElement=YES and NSWorkspaceDidTerminateApplicationNotification

[Stephane Sudre]

Is it a known bug that the
NSWorkspaceDidTerminateApplicationNotification notification is not
sent for applications whose LSUIElement key is set to YES?

I've found an entry for this in StackOverflow but the explanations
provided to the original poster are forgetting the LSUIElement factor.

Mac OS X 10.7.5.
___

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: Exiting non-POSIX threads?

[Scott Ribe]

On Jul 30, 2013, at 11:51 PM, Oleg Krupnov  wrote:

> One downside
> of it though is that the user should launch the crashed app at least
> one more time.

Which is why he specifically mentioned the option of an external watchdog 
process.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Oleg Krupnov]

> Which is why he specifically mentioned the option of an external watchdog 
> process.

This seems like an overkill. Every app needs some kind of crash
reporting, are you suggesting to accompany each app with a watchdog
process? Besides, the user might think your app is a spyware when he
sees the watchdog process in Activity Monitor.
___

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: Exiting non-POSIX threads?

[Scott Ribe]

On Jul 31, 2013, at 8:23 AM, Oleg Krupnov  wrote:

> Every app needs some kind of crash
> reporting, are you suggesting to accompany each app with a watchdog
> process?

Yes. (Unless you're distributing through the Mac App Store.)

> Besides, the user might think your app is a spyware when he
> sees the watchdog process in Activity Monitor.

Why? "MyApp_CrashReporter" shouldn't raise any red flags, especially if you 
give the user the *decision* as to whether to allow this or not--and if you 
don't, it really is spyware anyway--mild spyware, for an innocuous purpose, but 
regardless, sending yourself information about your user's activity without 
your user's permission is exactly that.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exiting non-POSIX threads?

[Fritz Anderson]

On 31 Jul 2013, at 9:23 AM, Oleg Krupnov  wrote:

>> Which is why he specifically mentioned the option of an external watchdog 
>> process.
> 
> This seems like an overkill. Every app needs some kind of crash
> reporting, are you suggesting to accompany each app with a watchdog
> process? Besides, the user might think your app is a spyware when he
> sees the watchdog process in Activity Monitor.

Yes.

It has these advantages:

• It the practice of almost every high-end third-party developer I've 
encountered. Perhaps I am biased by my opinion that applications are high-end 
if they adopt this practice.

• It assures the user that the developer will receive the report. I have no 
such faith in Apple's crash reporter.

It has these defenses:

• By definition, the best way to do a job is not "overkill," a term that isn't 
to be confused with "more work for the developer."

• People don't run ps(1) or Activity Monitor. Those who do see dozens of 
processes they can't identify. Those who pass that threshold know enough to 
look for the parent process (your application). Those who can't do that, and 
kill it, deserve what they get; they haven't lost any of the functionality they 
expect.

• A small, sleeping process consumes practically no resources. There is no 
cause for horror.

— F


___

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

Search options

[dangerwillrobinsondanger]

I have two questions. 
The simple one, if a file is invisible to the user but was previously visible 
(say renamed with a . prefix) can it still be found by NSMetadataQuery searches?

The more open ended one, 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. 

Thanks
JJ


___

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: CALayer autoresizing difficulties

[Andreas Mayer]

Am 31.07.2013 um 07:39 schrieb livinginlosange...@mac.com:

> [_playLayer setAutoresizingMask:kCALayerMinXMargin | kCALayerMaxXMargin | 
> kCALayerMinYMargin | kCALayerMaxYMargin];

> According to this code, the CALayer should be centered, and as the NSView's 
> bounds change, the CALayer's frame should adjust to stay centered in the view 
> while the layer's bounds don't change. However, my special CALayer's bounds 
> grow as I expand my main view.

I think it works exactly the opposite way.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/WorkingWithAViewHierarchy.html#//apple_ref/doc/uid/TP40002978-CH4-SW12

(This is about views, not layers. But I'm pretty sure they didn't invert the 
logic for layers only.)

---
NSViewWidthSizable
If set, the view's width changes proportionally to the change in the 
superview's width. Otherwise, the view's width does not change relative to the 
superview's width.
---

Which makes sense since kCALayerNotSizable is zero.


Andreas
___

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

Slow down a scroller?

[Steve Mills]

Is there any way to make a scroller less touchy? We have a couple cases where 
the horizontal scroller isn't controlling pixel movements of the view, but is 
used for more granular movements (rounded to the beginning of each measure in a 
musical score). It doesn't take much to flick it from 0 to 1 in this case, and 
it's impossible to swipe slowly enough to achieve measure-by-measure scrolls.

I've tried multiplying the thumb proportion by even large numbers like 100, but 
it doesn't seem to affect its sensitivity at all. Any ideas?

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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: [BUG?] LSUIElement=YES and NSWorkspaceDidTerminateApplicationNotification

[Jerry Krinock]

On 2013 Jul 31, at 06:32, Stephane Sudre  wrote:

> Is it a known bug that the NSWorkspaceDidTerminateApplicationNotification 
> notification is not
> sent for applications whose LSUIElement key is set to YES?

The *behavior* is known, at least by me, and is as you say, Stephane.  The 
question is: Does Apple consider it to be a bug?

The documentation of NSWorkspaceDidTerminateApplicationNotification states that 
it is "posted when an application finishes executing".  Is an application 
running with LSUIElement considered to be an "application"?  Unfortunately, 
NSWorkspace documentation throws out the word "application" like that in quite 
a few places without a precise definition.

This is likely one of those cases where it would be safe to assume that Apple 
will not change ("fix") the behavior, because to do so might break apps 
expecting the old behavior.

Have you filed a bug on this and has there been any response?  If not, I'll 
file one because I too use this notification and would at least like the 
behavior to be properly documented.
___

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

[Jerry Krinock]

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?

If not, you can still use my Cocoa wrapper…

http://github.com/jerrykrinock/ClassesObjC/blob/master/SSYCarbonSearcher.m

Demo project…

http://github.com/jerrykrinock/SSYCarbonSearcher



___

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

Connect to Server on LAN over WiFI

[koko]

I just need some direction here.

Given a server on a LAN how do I connect to the server, i.e what iOS API do I 
use?

-koko
___

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: Connect to Server on LAN over WiFI

[Nick Zitzmann]

On Jul 31, 2013, at 11:35 AM, koko  wrote:

> I just need some direction here.
> 
> Given a server on a LAN how do I connect to the server, i.e what iOS API do I 
> use?

What kind of server? What protocol does the server use? What are you trying to 
accomplish?

Nick Zitzmann



___

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: Connect to Server on LAN over WiFI

[Alex Zavatone]

Well, for one, you've got to start by telling us what type of "server" it is.  
AFP, HTTP,  SMB, VNC,  WebDAV, SQL/PHP, what kind of "server" do you want to 
talk to and what kind of tasks do you expect to do?

You may want to read up on the URL Loading System Programming Guide and the 
File System Programming Guide if this is for any file based operations.  

On Jul 31, 2013, at 1:35 PM, koko wrote:

> I just need some direction here.
> 
> Given a server on a LAN how do I connect to the server, i.e what iOS API do I 
> use?
> 
> -koko
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Connect to Server on LAN over WiFI

[koko]

On Jul 31, 2013, at 11:56 AM, Alex Zavatone  wrote:

> URL Loading System Programming Guide

Just what I was looking for … thanks!

-koko
___

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

Initializing a NSMutableString an odd way

[Vincent Habchi]

Folks,

I apologize if this question looks stupid or contrived. Here it is: is it 
permissible to use [@“” mutableCopy] to initialize (or reset) a NSMutableString 
instead of the more classical [[NSMutableString alloc] init]?

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Mike Abdullah]

On 31 Jul 2013, at 19:09, Vincent Habchi  wrote:

> Folks,
> 
> I apologize if this question looks stupid or contrived. Here it is: is it 
> permissible to use [@“” mutableCopy] to initialize (or reset) a 
> NSMutableString instead of the more classical [[NSMutableString alloc] init]?

Yes.


___

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: Initializing a NSMutableString an odd way

[Vincent Habchi]

Le 31 juil. 2013 à 20:15, Mike Abdullah  a écrit :

>> I apologize if this question looks stupid or contrived. Here it is: is it 
>> permissible to use [@“” mutableCopy] to initialize (or reset) a 
>> NSMutableString instead of the more classical [[NSMutableString alloc] init]?
> 
> Yes.

Thanks! (No side effect?)

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/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  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: Initializing a NSMutableString an odd way

[David Duncan]

On Jul 31, 2013, at 11:25 AM, Vincent Habchi  wrote:

> 
> Le 31 juil. 2013 à 20:15, Mike Abdullah  a écrit :
> 
>>> I apologize if this question looks stupid or contrived. Here it is: is it 
>>> permissible to use [@“” mutableCopy] to initialize (or reset) a 
>>> NSMutableString instead of the more classical [[NSMutableString alloc] 
>>> init]?
>> 
>> Yes.
> 
> Thanks! (No side effect?)


Why would there be? Your just asking for a mutable copy of an empty string. It 
should be equivalent to [[NSMutableString alloc] initWithString:@""]
--
David Duncan


___

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

[Ken Thomases]

On Jul 31, 2013, at 11:52 AM, Jerry Krinock wrote:

> 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 haven't worked with it, but I think that the searchfs() system call is what 
underlies those routines at the BSD/POSIX layer.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/searchfs.2.html

Regards,
Ken


___

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: Initializing a NSMutableString an odd way

[Fritz Anderson]

On 31 Jul 2013, at 1:28 PM, David Duncan  wrote:

> On Jul 31, 2013, at 11:25 AM, Vincent Habchi  wrote:
> 
>> 
>> Le 31 juil. 2013 à 20:15, Mike Abdullah  a écrit :
>> 
 I apologize if this question looks stupid or contrived. Here it is: is it 
 permissible to use [@“” mutableCopy] to initialize (or reset) a 
 NSMutableString instead of the more classical [[NSMutableString alloc] 
 init]?
>>> 
>>> Yes.
>> 
>> Thanks! (No side effect?)
> 
> 
> Why would there be? Your just asking for a mutable copy of an empty string. 
> It should be equivalent to [[NSMutableString alloc] initWithString:@""]

Or [NSMutableString string].

— F



___

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: Initializing a NSMutableString an odd way

[Ken Thomases]

On Jul 31, 2013, at 1:45 PM, Fritz Anderson wrote:

> On 31 Jul 2013, at 1:28 PM, David Duncan  wrote:
> 
>> On Jul 31, 2013, at 11:25 AM, Vincent Habchi  wrote:
>> 
>>> 
>>> Le 31 juil. 2013 à 20:15, Mike Abdullah  a écrit :
>>> 
> I apologize if this question looks stupid or contrived. Here it is: is it 
> permissible to use [@“” mutableCopy] to initialize (or reset) a 
> NSMutableString instead of the more classical [[NSMutableString alloc] 
> init]?
 
 Yes.
>>> 
>>> Thanks! (No side effect?)
>> 
>> 
>> Why would there be? Your just asking for a mutable copy of an empty string. 
>> It should be equivalent to [[NSMutableString alloc] initWithString:@""]
> 
> Or [NSMutableString string].

With ARC, yes.  With MRR, they're different in terms of ownership.

Regards,
Ken


___

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

[Jerry Krinock]

On 2013 Jul 31, at 11:29, Ken Thomases  wrote:

> I haven't worked with it, but I think that the searchfs() system call is what 
> underlies those routines at the BSD/POSIX layer.
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/searchfs.2.html

Interesting.  This was my first time looking at searchfs(), but it's deja vu of 
PBCatalogSearchSync() or PBCatalogSearchAsync(), especially the crazy structs / 
parameter blocks.  And yes, the PBCatalogSearch stuff does seem to be the 
*higher* level API, because they feature the asynchronous flavor, which 
searchfs() does not.


___

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: Initializing a NSMutableString an odd way

[Vincent Habchi]

Thanks to all for answering,

> Why would there be? Your just asking for a mutable copy of an empty string. 
> It should be equivalent to [[NSMutableString alloc] initWithString:@«  »]

But much slower I expect, since it creates a NSString, takes a mutable copy, 
then implicitly releases the constant empty NSString.

BTW, what’s the difference between [[NSMutableString alloc] init] and 
[[NSMutableString alloc] initWithString:@“”]?

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Sandor Szatmari]

I think there are some overlooked subtleties as @"" is a string literal.  
Retain and release are pretty much meaningless to it.

Sandor Szatmari

On Jul 31, 2013, at 15:28, Vincent Habchi  wrote:

> Thanks to all for answering,
> 
>> Why would there be? Your just asking for a mutable copy of an empty string. 
>> It should be equivalent to [[NSMutableString alloc] initWithString:@«  »]
> 
> But much slower I expect, since it creates a NSString, takes a mutable copy, 
> then implicitly releases the constant empty NSString.
> 
> BTW, what’s the difference between [[NSMutableString alloc] init] and 
> [[NSMutableString alloc] initWithString:@“”]?
> 
> 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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [BUG?] LSUIElement=YES and NSWorkspaceDidTerminateApplicationNotification

[Stephane Sudre]

I will file one because I consider that even if LSUIElement is set,
it's still an application (otherwise there would no point in returning
an running application instance when launched using NSWorkspace APIs)

On Wed, Jul 31, 2013 at 6:28 PM, Jerry Krinock  wrote:
>
> On 2013 Jul 31, at 06:32, Stephane Sudre  wrote:
>
>> Is it a known bug that the NSWorkspaceDidTerminateApplicationNotification 
>> notification is not
>> sent for applications whose LSUIElement key is set to YES?
>
> The *behavior* is known, at least by me, and is as you say, Stephane.  The 
> question is: Does Apple consider it to be a bug?
>
> The documentation of NSWorkspaceDidTerminateApplicationNotification states 
> that it is "posted when an application finishes executing".  Is an 
> application running with LSUIElement considered to be an "application"?  
> Unfortunately, NSWorkspace documentation throws out the word "application" 
> like that in quite a few places without a precise definition.
>
> This is likely one of those cases where it would be safe to assume that Apple 
> will not change ("fix") the behavior, because to do so might break apps 
> expecting the old behavior.
>
> Have you filed a bug on this and has there been any response?  If not, I'll 
> file one because I too use this notification and would at least like the 
> behavior to be properly documented.
> ___
>
> 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/dev.iceberg%40gmail.com
>
> This email sent to dev.iceb...@gmail.com



-- 
Packaging Resources - http://s.sudre.free.fr/Packaging.html

___

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: [BUG?] LSUIElement=YES and NSWorkspaceDidTerminateApplicationNotification

[Peter Ammon]

On Jul 31, 2013, at 9:28 AM, Jerry Krinock  wrote:

> 
> On 2013 Jul 31, at 06:32, Stephane Sudre  wrote:
> 
>> Is it a known bug that the NSWorkspaceDidTerminateApplicationNotification 
>> notification is not
>> sent for applications whose LSUIElement key is set to YES?
> 
> The *behavior* is known, at least by me, and is as you say, Stephane.  The 
> question is: Does Apple consider it to be a bug?
> 
> The documentation of NSWorkspaceDidTerminateApplicationNotification states 
> that it is "posted when an application finishes executing".  Is an 
> application running with LSUIElement considered to be an "application"?  
> Unfortunately, NSWorkspace documentation throws out the word "application" 
> like that in quite a few places without a precise definition.
> 
> This is likely one of those cases where it would be safe to assume that Apple 
> will not change ("fix") the behavior, because to do so might break apps 
> expecting the old behavior.
> 
> Have you filed a bug on this and has there been any response?  If not, I'll 
> file one because I too use this notification and would at least like the 
> behavior to be properly documented.

Yes, NSWorkspace does not post DidTerminate notifications (and a few others) 
for background and UIElement apps. This is one of those historical quirks that 
must be maintained for bug compatibility.

The more modern -[NSWorkspace runningApplications] method gives you a list of 
all applications, including background and UIElement. You can use KVO to 
observe this property, and be notified when apps are launched or terminated.

Hope that helps!




___

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: Initializing a NSMutableString an odd way

[Fritz Anderson]

On 31 Jul 2013, at 2:28 PM, Vincent Habchi  wrote:

> Thanks to all for answering,
> 
>> Why would there be? Your just asking for a mutable copy of an empty string. 
>> It should be equivalent to [[NSMutableString alloc] initWithString:@«  »]
> 
> But much slower I expect, since it creates a NSString, takes a mutable copy, 
> then implicitly releases the constant empty NSString.

NSString literals are baked into the application binary, and couldn't be 
deallocated if you tried. They are interned, so the code sample at the end of 
this message prints the same addresses for foo and empty no matter how you use 
them (even the product of -copy).

> BTW, what’s the difference between [[NSMutableString alloc] init] and 
> [[NSMutableString alloc] initWithString:@“”]?

The latter is redundant.

— F


___

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: Initializing a NSMutableString an odd way

[Greg Parker]

On Jul 31, 2013, at 12:28 PM, Vincent Habchi  wrote:
> David Duncan wrote:
>> Why would there be? Your just asking for a mutable copy of an empty string. 
>> It should be equivalent to [[NSMutableString alloc] initWithString:@«  »]
> 
> But much slower I expect, since it creates a NSString, takes a mutable copy, 
> then implicitly releases the constant empty NSString.

For giggles I tried some NSMutableString allocation patterns into my 
microbenchmark test harness. 

Simple alloc/init is the fastest:

100  [[[NSMutableString alloc] init] release]
102  [[NSMutableString new] release]
109  [NSMutableString string]  // ARC enabled
117  [[@"" mutableCopy] release]
119  @autoreleasepool { [NSMutableString string]; }  // ARC disabled
129  [[[NSMutableString alloc] initWithString:@""] release]

(Smaller numbers are better. Numbers are getrusage(RUSAGE_SELF) time for 
1000 iterations, normalized to fastest=100. Your mileage may vary.)

ARC and non-ARC scores are the same within measurement noise, except for 
[NSMutableString string] where ARC can optimize the autoreleased return value 
so the test doesn't need to spin the autorelease pool. Note th


> BTW, what’s the difference between [[NSMutableString alloc] init] and 
> [[NSMutableString alloc] initWithString:@“”]?

Semantically there's no difference: you get the same string with the same 
retain count.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Gary L. Wade]

On 7/31/2013 1:01 PM, "Greg Parker"  wrote:


>Simple alloc/init is the fastest:
>
>100  [[[NSMutableString alloc] init] release]
>102  [[NSMutableString new] release]
>109  [NSMutableString string]  // ARC enabled
>117  [[@"" mutableCopy] release]
>119  @autoreleasepool { [NSMutableString string]; }  // ARC disabled
>129  [[[NSMutableString alloc] initWithString:@""] release]
>
>(Smaller numbers are better. Numbers are getrusage(RUSAGE_SELF) time for
>1000 iterations, normalized to fastest=100. Your mileage may vary.)
>

Yeah, those numbers make sense from a "theoretical" standpoint (i.e.
without looking at the source code).  The +new call theoretically calls
+alloc/-init so would be slightly slower due to three method calls
(+new/+alloc/-init) and the -init call theoretically can do very little
until actual data is supplied while the others with actual data might add
the overhead of defining the actual data; theoretically, an empty string
is more data than no data yet to be filled.
--
Gary L. Wade
http://www.garywade.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: Initializing a NSMutableString an odd way

[Vincent Habchi]

Greg,

thanks for diverting some of your time testing this. As someone already 
commented, the results are somehow consistent with “common sense”, whatever 
that means (cf. below).

> ARC and non-ARC scores are the same within measurement noise, except for 
> [NSMutableString string] where ARC can optimize the autoreleased return value 
> so the test doesn't need to spin the autorelease pool. Note th

The end of your message somehow got lost in the cyberspace.

I thus suppose that to “clean” a NSMutableString, it is faster to recreate 
another one rather than use -deleteCharactersInRange: with a range covering the 
whole string.

Thanks again so much to everybody for your enlightening advice.

Vincent

—
“Common sense is the collection of prejudices acquired by age eighteen.” A. 
Einstein.



___

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: Initializing a NSMutableString an odd way

[Greg Parker]

On Jul 31, 2013, at 1:32 PM, Vincent Habchi  wrote:
> Greg Parker wrote:
>> ARC and non-ARC scores are the same within measurement noise, except for 
>> [NSMutableString string] where ARC can optimize the autoreleased return 
>> value so the test doesn't need to spin the autorelease pool. Note th
> 
> The end of your message somehow got lost in the cyberspace.

The spurious text was an editing error. No content was harmed.


> I thus suppose that to “clean” a NSMutableString, it is faster to recreate 
> another one rather than use -deleteCharactersInRange: with a range covering 
> the whole string.

Not necessarily. If you have long string and you want to clear it and re-fill 
it with another long string, then it may be faster to use 
-deleteCharactersInRange: in order to avoid memory re-allocation overhead. But 
that possibility depends on precise implementation details of NSMutableString.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Sandor Szatmari]

Why not [aMutableString setString:@""];?

Sandor Szatmari

On Jul 31, 2013, at 16:32, Vincent Habchi  wrote:

> Greg,
> 
> thanks for diverting some of your time testing this. As someone already 
> commented, the results are somehow consistent with “common sense”, whatever 
> that means (cf. below).
> 
>> ARC and non-ARC scores are the same within measurement noise, except for 
>> [NSMutableString string] where ARC can optimize the autoreleased return 
>> value so the test doesn't need to spin the autorelease pool. Note th
> 
> The end of your message somehow got lost in the cyberspace.
> 
> I thus suppose that to “clean” a NSMutableString, it is faster to recreate 
> another one rather than use -deleteCharactersInRange: with a range covering 
> the whole string.
> 
> Thanks again so much to everybody for your enlightening advice.
> 
> Vincent
> 
> —
> “Common sense is the collection of prejudices acquired by age eighteen.” A. 
> Einstein.
> 
> 
> 
> ___
> 
> 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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Vincent Habchi]

Le 31 juil. 2013 à 22:38, Greg Parker  a écrit :

> Not necessarily. If you have long string and you want to clear it and re-fill 
> it with another long string, then it may be faster to use 
> -deleteCharactersInRange: in order to avoid memory re-allocation overhead. 
> But that possibility depends on precise implementation details of 
> NSMutableString.

So I guess profiling is once more everybody’s friend.
Thanks anyhow once more for taking the time to answer my very minor inquiry.

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing a NSMutableString an odd way

[Alex Zavatone]

On Jul 31, 2013, at 4:01 PM, Greg Parker wrote:

> On Jul 31, 2013, at 12:28 PM, Vincent Habchi  wrote:
>> David Duncan wrote:
>>> Why would there be? Your just asking for a mutable copy of an empty string. 
>>> It should be equivalent to [[NSMutableString alloc] initWithString:@«  »]
>> 
>> But much slower I expect, since it creates a NSString, takes a mutable copy, 
>> then implicitly releases the constant empty NSString.
> 
> For giggles I tried some NSMutableString allocation patterns into my 
> microbenchmark test harness. 

I'm rather fascinated with these and wrote the one that profiled the speed of 
all variable classes and functions of Lingo back in the Director days.

Once we knew just how fast each of the variable allocations and functions took 
when compared to each other, this made it really easy to determine what 
approaches not to use in the interests of performance, or where we could change 
code for the sake of readability over performance.

By any chance is this harness open or is it a private project?  Of course, we 
have instruments, but it would be rather great to simply be able to plug in 
some operations and know the speed of them and their speed relative to each 
other.

> Simple alloc/init is the fastest:
> 
> 100  [[[NSMutableString alloc] init] release]
> 102  [[NSMutableString new] release]
> 109  [NSMutableString string]  // ARC enabled
> 117  [[@"" mutableCopy] release]
> 119  @autoreleasepool { [NSMutableString string]; }  // ARC disabled
> 129  [[[NSMutableString alloc] initWithString:@""] release]
> 
> (Smaller numbers are better. Numbers are getrusage(RUSAGE_SELF) time for 
> 1000 iterations, normalized to fastest=100. Your mileage may vary.)
> 
> ARC and non-ARC scores are the same within measurement noise, except for 
> [NSMutableString string] where ARC can optimize the autoreleased return value 
> so the test doesn't need to spin the autorelease pool. Note th
> 

Your note got cut off near the en







___

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: [BUG?] LSUIElement=YES and NSWorkspaceDidTerminateApplicationNotification

[Jerry Krinock]

On 2013 Jul 31, at 12:46, Stephane Sudre  wrote:

> I will file one because I consider that even if LSUIElement is set, it's 
> still an application (otherwise there would no point in returning an running 
> application instance when launched using NSWorkspace APIs)

Although you are correct (a "running application" is indeed an "application"), 
your bug should ask that the NSWorkspaceDidTerminateApplicationNotification 
*documentation* be clarified, because, as Peter Ammon confirmed, it's way too 
late for Apple to change the behavior.

On 2013 Jul 31, at 12:47, Peter Ammon  wrote:

> The more modern -[NSWorkspace runningApplications] method gives you a list of 
> all applications, including background and UIElement. You can use KVO to 
> observe this property, and be notified when apps are launched or terminated.

I'll try that.  Thanks!



___

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