mpw

#!/usr/local/bin/dscsh

@implementation NSObject(mapping)

-map:dict
{
	return [dict objectForKey:self];
}

-roundedTo100

mpw

#!/usr/local/bin/dscsh

@interface DSCDump: NSObject
@end

@implementation DSCDump



-(void)dumpFile:aFile

mpw

 Compiling file Stores.subproj/MPWAbstractStore.m ...
Stores.subproj/MPWAbstractStore.m:60:50: error: array subscript is not an integer
                id subDescription=descriptionDict[key];
                                                 ^~~~
Stores.subproj/MPWAbstractStore.m:61:26: error: array subscript is not an integer
                storeDict[key] = [self mapStore:subDescription];
                         ^~~~
Stores.subproj/MPWAbstractStore.m:187:6: error: use of undeclared identifier '_name'
    [_name release];
     ^

mpw

libdispatch efficiency tips

I suspect most developers are using the libdispatch inefficiently due to the way it was presented to us at the time it was introduced and for many years after that, and due to the confusing documentation and API. I realized this after reading the 'concurrency' discussion on the swift-evolution mailing-list, in particular the messages from Pierre Habouzit (who is the libdispatch maintainer at Apple) are quite enlightening (and you can also find some good tweets from him on the subject).

• https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/date.html
• https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/date.html

My take-aways are:

• You should have very few queues that target the global pool. If all these queues are active at once, you will get as many threads running. These queues should be seen as execution contexts in the program (gui, storage, background work, ...) that benefit from executing in parallel. Start with few of them, reuse