Re: -[NSThread start] blocks ?!?

[Ken Thomases]

On Sep 26, 2015, at 5:33 PM, Jerry Krinock  wrote:

> In a OS X app, predating Grand Central Dispatch, in the main thread, I create 
> and start a new thread
> 
> NSThread* worker ;
> worker = [[NSThread alloc] initWithTarget:instance
> selector:@selector(beginWithInfo:)
>   object:info] ;
> [worker setName:@“My Worker thread"] ;
> [worker start] ;
> 
> usually this works OK, but sometimes, possibly when the above code executes a 
> second or third time in rapid succession, [worker start] will block forever:

> Looking at the other threads, I see that “My Worker thread” (see Thread 455, 
> below) has been created, and seems to be stuck while trying to *exit*, which 
> I think is weird because if -[NSThread start] blocked until the new thread 
> exitted, that would defeat the purpose of multithreading.  Same thing if, 
> say, My Worker thread executed some kind of “do this on the main thread” call.
> 
> Should not -[NSThread start] always return before running any of my code in 
> the new thread?  So how could this happen?  I’m running OS X 10.11.

It could be a bug in the system libraries, but it could also be any number of 
other things.  For example, a heap smashing bug could have corrupted a 
GCD-internal spin lock variable.  Try running with zombies enabled and see if 
you trip one.  Try building and running with Address Sanitizer.  Run the static 
analyzer on your code and make sure to fix any issues it identifies (or examine 
them thoroughly to determine that they're false positives).

You could also try to reproduce the problem with a very much simplified test 
app.  That would be the first step in filing a bug report, anyway.

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: -[NSThread start] blocks ?!?

[Jerry Krinock]

> On 2015 Sep 26, at 18:03, Quincey Morris 
>  wrote:
> 
> I don’t understand what you’re asking.

I mean that if it is possible for -[NSThread start] to block indefinitely, it 
is not a useable API.  I clicked the “Pause” and “Continue” multiple times in 
Xcode, but each time, in the main thread, the green arrow was stuck at 
-[NSThread start], _dispatch_semaphore_wait_slow() and semaphore_wait_trap().  
It was apparently waiting for a semaphore.

> The scenario I was talking about involved only delays that would eventually 
> be resolved.

OK, I misunderstood.

> All your stack traces have an identical call to _OSSpinLockLockSlow as their 
> second entry. Looks like everything is waiting on a single lock that’s part 
> of the threading machinery.

Interestisng.

> Since you’ve apparently created over 450 threads previously, perhaps you used 
> up kernel resources to the point where whatever took the lock crashed without 
> releasing it?

I should have mentioned that, of those 450 threads, only about 10 were still 
showing in the Debug Navigator, which I presume means that thother 440 have 
finished.

* * *

On 2015 Sep 27, at 03:49, Ken Thomases  wrote:

> It could be a bug in the system libraries, but it could also be any number of 
> other things.  For example, a heap smashing bug could have corrupted a 
> GCD-internal spin lock variable.

Arg.

> You could also try to reproduce the problem with a very much simplified test 
> app.  That would be the first step in filing a bug report, anyway.

Yesterday, this happened once or twice out of 12 trials, while running the last 
10.11 developer preview.  I’ve now updated to the GM candidate and so far good 
after 2 trials.  We’ll see.  I’m not sure I know how to reproduce :(
___

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: Continue application processing with mouse down on a menu

[Scott Ribe]

On Sep 26, 2015, at 12:19 PM, Programmingkid  wrote:
> 
> I just wish there were an easy way for the a task on the main thread to 
> continue to work even if the user is looking at a menu. Using multiple 
> threads has a lot of problems associated with it.

A simple way to interleave execution of two different tasks without using 
threads? You're essentially wishing for magic fairy dust.

Yes, there are ways to interleave two tasks without threads, but building a 
little finite state machine that interleaves between them, or coming up with 
some co-routine implementation and then yielding at key points, as in the old 
days of cooperative multi-processing, have way more problems than multiple 
threads.

If you have computation that needs to keep running without blocking menu 
tracking and other event handling, you need to put it on its own thread, period.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: Continue application processing with mouse down on a menu

[Scott Ribe]

On Sep 26, 2015, at 12:00 PM, Programmingkid  wrote:
> 
> I did try using a separate thread, but that caused part of the application to 
> stop responding to events. 

A background thread will *not* cause your application to stop responding to 
events. You need to go back and look more closely at what was happening there. 

Did you block on the main thread waiting for the background thread to finish? 
Of course waiting in the main thread would stop event processing, so you would 
need to post an event from the background thread when it is done, not block on 
the main thread. (Alternatively, you could have the main thread somehow check 
periodically if the bg thread is done, but in most cases calling 
performSelectorOnMainThread from the bg thread is a very easy way to get 
results back into the main thread, much easier than having the main thread 
"poll", and worrying about correct synchronization of that polling.)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: -[NSThread start] blocks ?!?

[Jens Alfke]

> On Sep 27, 2015, at 6:50 AM, Jerry Krinock  wrote:
> 
> I mean that if it is possible for -[NSThread start] to block indefinitely, it 
> is not a useable API. 

It’s not. The new thread will start when the kernel's scheduler gives it time. 
That’s technically indefinite, but realistically microseconds, or at most 
milliseconds. The point is that it’s not guaranteed to happen before the 
calling thread (or any other non-blocked thread in any process) gets to run.

—Jens
___

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

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

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

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

How to get remote metadata

[Gerriet M. Denkmann]

I want to get some metadata for a remote file.
I tried:

NSString *path = @"/Public/UNIDATA/Blocks.txt";
NSURL *icuBlocksUrl = [ [ NSURL alloc ] initWithScheme: @"http"  host: 
@"unicode.org"  path: path ];
NSArray *keys = @[ NSURLContentModificationDateKey, NSURLCreationDateKey, 
NSURLFileSizeKey ];
NSError *outError;
NSDictionary *icuDict = [ icuBlocksUrl resourceValuesForKeys: keys  error: 
&outError ];

Now icuDict is non-nil but empty.

What am I doing wrong?

Gerriet.

P.S.

Just seen in small print: “This method applies only to URLs that represent file 
system resources.”

So this is not expected to work. What else can I do?



___

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 get remote metadata

[Mike Abdullah]

> On 27 Sep 2015, at 18:08, Gerriet M. Denkmann  wrote:
> 
> I want to get some metadata for a remote file.
> I tried:
> 
> NSString *path = @"/Public/UNIDATA/Blocks.txt";
> NSURL *icuBlocksUrl = [ [ NSURL alloc ] initWithScheme: @"http"  host: 
> @"unicode.org"  path: path ];
> NSArray *keys = @[ NSURLContentModificationDateKey, NSURLCreationDateKey, 
> NSURLFileSizeKey ];
> NSError *outError;
> NSDictionary *icuDict = [ icuBlocksUrl resourceValuesForKeys: keys  error: 
> &outError ];
> 
> Now icuDict is non-nil but empty.
> 
> What am I doing wrong?
> 
> Gerriet.
> 
> P.S.
> 
> Just seen in small print: “This method applies only to URLs that represent 
> file system resources.”
> 
> So this is not expected to work. What else can I do?

Probably the best thing to do is to use NSURLSession to send a HEAD request to 
the server, and pick the information you want out of the response headers.


___

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

Drawing many different strings quickly

[Ben]

Hi list,

I'm needing to draw somewhere in the order of 1,000,000 different strings in a 
scrollable grid view and am struggling to get performance that I am happy with.

After profiling, most of my time is spent in drawing text into the view.

My first attempt was simply to use NSString's drawInRect:withAttributes:. The 
attributes dictionary was cached between calls. This is not too bad for shorter 
strings, but slows down dramatically once longer strings need to be drawn 
truncated.

My second attempt has been to use my own NSTextStorage/Container/LayoutManager 
trio and draw using NSLayoutManager. This is faster when many strings are the 
same, but worse when most are different. I don't know in advance what the 
strings will be so must assume they are all unique.


Can anyone suggest what I should look into next? My requirements are as follows:

- Assume around a million unique strings to be drawn
- Not all strings to be drawn at once, a scroll view is being used and I am 
using responsive scrolling to pre-draw areas. The problem occurs when quickly 
scrolling a large distance
- Longer strings will be truncated to a single line under 200px wide
- All strings to be drawn in the same font/size/colour
- I can target the current (or current+1) OS version if that makes any 
difference


Any pointers or suggestions gratefully accepted!

- Ben
___

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: Drawing many different strings quickly

[Quincey Morris]

On Sep 27, 2015, at 10:42 , Ben  wrote:
> 
> - Not all strings to be drawn at once, a scroll view is being used and I am 
> using responsive scrolling to pre-draw areas. The problem occurs when quickly 
> scrolling a large distance

I think your answer is in this statement. Assuming you’re drawing the strings 
in drawRect of a custom view, and the size and position of the grid cell 
containing each string doesn’t depend on the metrics of any other string, then 
the cost of this kind of interface is the number of strings you can *see* at 
once (less than 50 surely), not the number of strings in your data model. 
Responsive scrolling may make the smaller number a bit larger, but if you’re 
getting performance problems from this, you’re likely doing something wrong.

But …

> The problem occurs when quickly scrolling a large distance

There it is, really. What I said before applies only when the scrolled view 
isn’t scrolling. When it is, you can *see* many more strings at essentially the 
same time.

What’s the answer to this question: If you quickly scroll across 10,000 
strings, how many strings is your drawRect drawing? 10,000? Less? More? You 
need to do some analysis to find out what you’re actually doing.

Are you using the dirtyRect parameter of drawRect to limit which strings you 
draw? Are you using ‘getRectsBeingDrawn:count:’ or ‘needsToDrawRect:’ to limit 
drawing even further? Have you tried using a table view?

Ultimately, if your drawing technique can’t keep up with fast scrolling, you’re 
going to have to *stop* drawing when it starts to lag, and catch up when 
scrolling slows or stops.

P.S. You didn’t say whether this is OS X or iOS. I think responsive scrolling 
is OS X only, so I’m guessing that’s the 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

o Swift generics, y no can I haz u dispatch correctly?

[has]

Hi all,

So, as part of my ongoing quest to discover all the exciting ways in 
which Swift can perplex and frustrate me†, I'm trying to solve the last 
major blocker on my SwiftAE project 
(https://bitbucket.org/hhas/swiftae), which is how to use Swift's static 
typing to determine how NSAppleEventDescriptors are unpacked.


The ideal solution would be to define each application command as a 
generic method like this:


func someCommand(ARGS) -> T {

   let resultDesc = self.appData.sendAppleEvent(ARGS)

// unpack() should introspect T and use that information to coerce
// resultDesc to the corresponding AE type before unpacking it:

let result = self.appData.unpack(resultDesc, returnType: T.self)

return result as! T
}

and define a non-generic `AppData.unpack()` method that uses 
introspection to pull the `returnType` argument to bits.


Alas, Swift 2's type introspection sucks absolutely monkey nuts, so 
AFAIK it currently isn't possible to pull apart parameterized types such 
as Array to see how they're constructed. (Except, perhaps, by 
getting and parsing its string representation (euwww) and I'm not quite 
that desperate yet.) So, as a workaround, I've been trying to overload 
my `unpack` methods so that the generics system pulls apart the Swift 
type for me.


For atomic types (Bool, Int, String, NSURL, etc) this approach works 
fine: I can just use a big ol' conditional/switch to test if 
T.self==Bool.self, T.self==Int.self, etc. and use that to coerce and 
unpack AEDescs which are similarly atomic (typeBoolean, typeInteger, 
etc). The problem is how to do the same for Array<> and Dictionary<> 
types, since to unpack the corresponding typeAEList and typeAERecord 
AEDescs we also need to know the type(s) of the Array/Dictionary 
elements. For example, if the user writes:


let result = appObj.someCommand as Array

then T will be Array, so the resultDesc should be coerced to 
typeAEList and each of its items should be coerced to typeUnicodeText 
before unpacking it as the specified Swift types.


After a few attempts, I finally found the following overloaded `unpack` 
methods †† seemed to distinguish between atomic and non-atomic Swift types:



class AppData {

// unpack sequence type (e.g. Array)
func unpackT.Generator.Element>(desc: Any, returnType: T.Type) -> T {

print("unpack sequence of \(U.self)")
return desc as! T
}

// unpack atomic type (e.g. String)
func unpack(desc: Any, returnType: T.Type) -> T {
print("unpack atomic value \(T.self)")
return desc as! T
}
}

This works exactly as intended when `AppData.unpack()` is called directly:

let d = AppData()

d.unpack([1,2], returnType: [Int].self) // correctly calls 
`unpack()`



The problem is, it all falls apart again when `AppData.unpack()` is 
called from another generic method:


class Commands {
func get(v:Any) -> T {
return d.unpack(v, returnType: T.self) as T
}
}

Commands().get([3,4]) as [Int] // incorrectly calls `unpack()`

Dunno why, but this time the Swift compiler picks the less specific 
`unpack` implementation instead of the one that's got SequenceType 
stamped all over its signature. (Bet Dylan never had this problem...)


Mind, it still wouldn't be the end of the world if Swift only let us 
express constraints such as this:


// unpack atomic type (e.g. String)
func unpack(...) -> T {
...
}

but alas, once again we hit the point where Swift's type system stops 
pretending to be a formal set algebra and proves to be just another 
bunch of ad-hoc compiler kludges in the grand old tradition  of C.


Adding another `returnType` parameter and plastering the calling code 
with ludicrous amounts of type info makes absolutely no difference either:


class Commands {
func get(v:Any, returnType: T.Type) -> T {
return d.unpack(v, returnType: T.self) as T
}
}

let result: [Int] = Commands().get([3,4], returnType: [Int].self) 
as [Int] // still incorrectly calls `unpack()`


Whatever it was that made `unpack(desc, returnType:)` work the first 
time around appears to be a one-trick pony.


So I'm kinda jiggered again by the complexities and vagaries of 
SwiftLang... (and this is even before I start thinking about how the 
smoking hell I'll ever handle sum types, as it's not uncommon for 
application commands to return more than one possible type of value).


So please please please, anyone got any ideas, answers, magic, etc? 
(Swift engineers particularly - after all, this is a great opportunity 
to kick its tyres and figure how to make it more robust and less ornery.)


Many thanks,

has


† This damn project is taking me far too long to complete, and it's got 
me cursing Swift as much as I curse AppleScript (and that is a LOT of 
cursing). I'd love to see Swift pro

Re: -[NSThread start] blocks ?!?

[John Daniel]

> In a OS X app, predating Grand Central Dispatch, in the main thread, I create 
> and start a new thread
> 
> NSThread* worker ;
> worker = [[NSThread alloc] initWithTarget:instance
> selector:@selector(beginWithInfo:)
>   object:info] ;
> [worker setName:@“My Worker thread"] ;
> [worker start] ;
> 
> usually this works OK, but sometimes, possibly when the above code executes a 
> second or third time in rapid succession, [worker start] will block forever:

There is no way to tell what is causing the deadlock without knowing exactly 
what is happening relating to:
1) instance
2) beginWithInfo:
3) info

If this code pre-dates GCD, you could have all kinds of nasty stuff going on. 
All of the items I listed above are shared. They may, or may not, need to be 
protected by locks. There is no way to tell without dumping virtually your 
entire program.

I strongly suggest looking into adopting GCD instead. It dates to 10.5, so you 
aren’t giving up too much backwards compatibility. Data sharing using serial 
queues is safer and more robust by design. You will still need to ensure that 
any shared access uses that serial queue, but I find GCD much more 
straightforward. You may end up blocked in a semaphore again, but it will be 
your own semaphore and you can more easily debug it.

John 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

ARC, blocks, capture variables

[Scott Ribe]

Given a block instance var named fun:

fun = ^void () {[self ...];};

Results in the warning:

"Capturing 'self' strongly in this block is likely to lead to a retain cycle"

But I know that it does not result in a retain cycle, because I nil out fun at 
the appropriate time. So how to get rid of the warning?

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: o Swift generics, y no can I haz u dispatch correctly?

[Quincey Morris]

On Sep 27, 2015, at 15:02 , has  wrote:
> 
> The problem is, it all falls apart again when `AppData.unpack()` is called 
> from another generic method:
> 
>class Commands {
>func get(v:Any) -> T {
>return d.unpack(v, returnType: T.self) as T
>}
>}

I think you’re falling foul of one of two things:

1. Swift has generics, not templates. They say. (I never know exactly what that 
means either, but I think it’s relevant here.) AFAIK, Swift won’t “carry” the 
original parameterized type through to other call sites and use it for further 
specialization. In the above example, T is unconstrained, so I don’t think it 
satisfies the stricter of the ‘unpack’ generic definitions, even though the 
type it happens to represent does.

2. Swift has known difficulties in choosing a more-specific specialization when 
some of the generic declarations have more than one type parameter, as your 
first ‘unpack’ does. I don’t know if this is a bug or a necessary limitation, 
but I have one bug report in about this and have seen other examples in the 
forums.

After playing around with it in a playground for a while, I found this solution:

> func unpack (v: [U], type: [T].Type) -> [T] {
>   return [0 as! T]
> }
> 
> func unpack (v: U, type: T.Type) -> T {
>   return 0 as! T
> }
> 
> func get (v: U) -> T {
>   return unpack (v, type: T.self)
> }
> 
> func get (v: [U]) -> [T] {
>   return unpack (v, type: [T].self)
> }
> 
> let a = get (1) as Int // produces 0
> let b = get ([2,3]) as [Int] // produces [0]

It ought to be simpler than this, but there’s still something going wrong with 
choosing the correct ‘get’ based on *just* the return types. I’m using the 
other input parameter to make this distinction, assuming that it’s an array if 
the result is an array, which may not be true in your case.

But maybe there’s something in this that helps you.

(P.S. If you want to ask questions like this, you could/should take them to the 
Swift forum in devforums. There are people who hang out there to whom this sort 
of thing is date night and red roses afterwards. Those are the people I think 
you need.)

___

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, blocks, capture variables

[Quincey Morris]

On Sep 27, 2015, at 17:17 , Scott Ribe  wrote:
> 
> But I know that it does not result in a retain cycle, because I nil out fun 
> at the appropriate time. So how to get rid of the warning?

IIRC you can simply assign ‘self’  to a local variable just before assigning to 
‘fun', and use the local variable name instead of ‘self’ inside the block.

The other approach I’ve used, when I have control the signature of the block, 
is to pass ‘self’ as a parameter to the block invocation. This may actually 
avoid the reference cycle completely.



___

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, blocks, capture variables

[Scott Ribe]

On Sep 27, 2015, at 7:03 PM, Quincey Morris 
 wrote:
> 
> IIRC you can simply assign ‘self’  to a local variable just before assigning 
> to ‘fun', and use the local variable name instead of ‘self’ inside the block.

Well, that does work. Thanks!

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: Drawing many different strings quickly

[Graham Cox]

Hi Ben,

You may find that responsive scrolling is actually making things worse in this 
case, because many more strings than you can see are being drawn, and string 
drawing is expensive. Have you tried opting out of responsive scroling?

Apart from that, usual advice applies - draw the very minimum you need for the 
dirty area of the view. Strings are problematic, in that the bounding rectangle 
is hard to know in advance - calculating that requires the string be laid out, 
and there goes your time. Note that [NSString drawInRect:attributes:] creates a 
NSLayoutManager and associated components, does the drawing, then discards all 
the layout stuff, so it’s very inefficient. Your idea of reusing a 
NSLayoutManager for all your strings should give better performance, because a) 
you’re not recreating it every time and b) it caches quite a lot of layout info 
between calls (which is why you saw a speed up when the strings were the same).

You could try some additional caching of your own, e.g. the bounding rect of a 
known string, so that you can tell without needing layout again whether the 
string intersects the dirty region of the view (as tested by -needsToDrawRect:, 
not whether it intersects the overall dirtyRect). This is only worthwhile if 
your strings are repeated frequently enough, it’s not going to help if they’re 
all different. You could also try precalculating the bounding rects on a 
separate thread rather than doing that as part of drawing/scrolling so that the 
drawing part isn’t held up by the calculation. It can mean labels “pop in” to 
view as you scroll which might be unacceptable.

Getting this to perform well is hard, but it can be done. One of my apps draws 
maps which can consist of many, many thousands of textual labels drawn at 
arbitrary positions in varying styles. Using tricks as described it scrolls 
smoothly.

—Graham


> On 28 Sep 2015, at 3:42 am, Ben  wrote:
> 
> Hi list,
> 
> I'm needing to draw somewhere in the order of 1,000,000 different strings in 
> a scrollable grid view and am struggling to get performance that I am happy 
> with.
> 
> After profiling, most of my time is spent in drawing text into the view.
> 
> My first attempt was simply to use NSString's drawInRect:withAttributes:. The 
> attributes dictionary was cached between calls. This is not too bad for 
> shorter strings, but slows down dramatically once longer strings need to be 
> drawn truncated.
> 
> My second attempt has been to use my own 
> NSTextStorage/Container/LayoutManager trio and draw using NSLayoutManager. 
> This is faster when many strings are the same, but worse when most are 
> different. I don't know in advance what the strings will be so must assume 
> they are all unique.
> 
> 
> Can anyone suggest what I should look into next? My requirements are as 
> follows:
> 
> - Assume around a million unique strings to be drawn
> - Not all strings to be drawn at once, a scroll view is being used and I am 
> using responsive scrolling to pre-draw areas. The problem occurs when quickly 
> scrolling a large distance
> - Longer strings will be truncated to a single line under 200px wide
> - All strings to be drawn in the same font/size/colour
> - I can target the current (or current+1) OS version if that makes any 
> difference
> 
> 
> Any pointers or suggestions gratefully accepted!
> 
> - Ben
> ___
> 
> 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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.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: Continue application processing with mouse down on a menu

[Programmingkid]

On Sep 27, 2015, at 10:33 AM, Scott Ribe wrote:

> On Sep 26, 2015, at 12:19 PM, Programmingkid  
> wrote:
>> 
>> I just wish there were an easy way for the a task on the main thread to 
>> continue to work even if the user is looking at a menu. Using multiple 
>> threads has a lot of problems associated with it.
> 
> A simple way to interleave execution of two different tasks without using 
> threads? You're essentially wishing for magic fairy dust.

You are right. 

> Yes, there are ways to interleave two tasks without threads, but building a 
> little finite state machine that interleaves between them, or coming up with 
> some co-routine implementation and then yielding at key points, as in the old 
> days of cooperative multi-processing, have way more problems than multiple 
> threads.
> 
> If you have computation that needs to keep running without blocking menu 
> tracking and other event handling, you need to put it on its own thread, 
> period.

I realize this now. Thank you everyone for your input


___

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: -[NSThread start] blocks ?!?

[Jerry Krinock]

On 2015 Sep 27, at 17:01, John Daniel  wrote:

> There is no way to tell what is causing the deadlock without knowing exactly 
> what is happening relating to:
> 1) instance
> 2) beginWithInfo:
> 3) info

Thank you, John.  You are referring to what my secondary thread is doing.  My 
point is that if we can’t at least rely on -[NSThread start] returning before 
the secondary starts, there is no way for a seconary thread to call back to the 
main thread without possibility of deadlock.  It’s a defect in NSThread.

> Data sharing using serial queues is safer and more robust by design.

OK, if it is a defect in NSThread, GCD might not have this defect.  I’ll 
consider that. Thank you.

Jerry


___

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: Drawing many different strings quickly

[Jens Alfke]

Use an NSTableView. It knows how to manage unlimited numbers of rows 
efficiently.

--Jens
___

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

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

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

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

Re: -[NSThread start] blocks ?!?

[Jens Alfke]

—Jens 

> On Sep 27, 2015, at 8:49 PM, Jerry Krinock  wrote:
> 
>  My point is that if we can’t at least rely on -[NSThread start] returning 
> before the secondary starts, there is no way for a seconary thread to call 
> back to the main thread without possibility of deadlock.

Why?

You do realize that people managed to use NSThread successfully for years 
before GCD was introduced.

But if you don't like NSThread's behavior, just use GCD instead.

--Jens
___

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

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

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

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

Re: -[NSThread start] blocks ?!?

[Charles Srstka]

> On Sep 27, 2015, at 11:18 PM, Jens Alfke  wrote:
> 
>> On Sep 27, 2015, at 8:49 PM, Jerry Krinock > > wrote:
>> 
>> My point is that if we can’t at least rely on -[NSThread start] returning 
>> before the secondary starts, there is no way for a seconary thread to call 
>> back to the main thread without possibility of deadlock.
> 
> Why?
> 
> You do realize that people managed to use NSThread successfully for years 
> before GCD was introduced.
> 
> But if you don't like NSThread's behavior, just use GCD instead.

1. The fact that NSThread is now apparently using dispatch semaphores 
internally suggests that it is no longer implemented the same way that it was 
back when it was the preferred threading mechanism on OS X.

2. The fact that NSThread hasn’t been the preferred threading mechanism for 
quite some years suggests that it may no longer be as thoroughly tested by 
Apple as well as GCD is.

I’d definitely move to GCD, if it were me.

Charles

___

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

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

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

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

Re: -[NSThread start] blocks ?!?

[Ken Thomases]

> On Sep 27, 2015, at 8:49 PM, Jerry Krinock  wrote:
> 
> My point is that if we can’t at least rely on -[NSThread start] returning 
> before the secondary starts, there is no way for a seconary thread to call 
> back to the main thread without possibility of deadlock.

No, this isn't true.  The only requirement is that -[NSThread start] is _free_ 
to return _once_ the new thread has started.  That doesn't mean it _will have_ 
returned.  There's no guarantee that -start will return before the new thread 
starts and there never has been.  In fact, it would be very difficult to 
implement such a guarantee.

Now, obviously, you're encountering buggy behavior where -[NSThread start] is 
stuck for some reason.  It's not yet clear whether the bug is in your code or 
in Cocoa.

-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: How to get remote metadata

[Gerriet M. Denkmann]

> On 28 Sep 2015, at 00:31, Mike Abdullah  wrote:
> 
> 
>> On 27 Sep 2015, at 18:08, Gerriet M. Denkmann  wrote:
>> 
>> I want to get some metadata for a remote file.
>>  
>> Just seen in small print: “This method applies only to URLs that represent 
>> file system resources.”
>> 
>> So this is not expected to work. What else can I do?
> 
> Probably the best thing to do is to use NSURLSession to send a HEAD request 
> to the server, and pick the information you want out of the response headers.

Excellent. Just what I needed. Thanks a lot!

One question though:
The NSHTTPURLResponse allHeaderFields dictionary contains keys like: 
“Content-Length” and “Last-Modified”.
Are these standardized or might other sites use other keys like 
“Modification-Date” or “Nbr-of-Bytes” ?

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

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

Re: How to get remote metadata

[Quincey Morris]

On Sep 27, 2015, at 22:43 , Gerriet M. Denkmann  wrote:
> 
> The NSHTTPURLResponse allHeaderFields dictionary contains keys like: 
> “Content-Length” and “Last-Modified”.
> Are these standardized or might other sites use other keys like 
> “Modification-Date” or “Nbr-of-Bytes” ?

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Response_fields 


___

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