I'm using CocoaHTTPServer and RoutingHTTPServer, and when a request comes in,
my handler block is called on some arbitrary thread. The run loop associated
with it has kCFRunLoopDefaultMode.
I have code that creates an NSTimer and invokes a block passed to it. This
works fine when called from th
On Oct 21, 2014, at 3:15 AM, Rick Mann wrote:
> I'm using CocoaHTTPServer and RoutingHTTPServer, and when a request comes in,
> my handler block is called on some arbitrary thread. The run loop associated
> with it has kCFRunLoopDefaultMode.
>
> I have code that creates an NSTimer and invokes
> On Oct 21, 2014, at 01:46 , Ken Thomases wrote:
>
> On Oct 21, 2014, at 3:15 AM, Rick Mann wrote:
>
>> I'm using CocoaHTTPServer and RoutingHTTPServer, and when a request comes
>> in, my handler block is called on some arbitrary thread. The run loop
>> associated with it has kCFRunLoopDefa
> On 21 Oct 2014, at 4:58 pm, Rick Mann wrote:
>
> I'm simulating a device that takes a substantial amount of time to respond to
> a series of REST HTTP request (to support automated testing). I'm writing an
> OS X app to do this. I was trying to avoid running the timer on the main
> thread b
10.10, Xcode 6.1, using Arc.
The following code works fine, with USE_INVOCATION defined or not:
#define USE_INVOCATION (or commented out)
- (NSSet *)doSomethingWith: (NSArray *)listOfActions onSet: (NSSet *)originSet
{
NSSet *inputSet = originSet;
for( NSString *curSel
> On Oct 20, 2014, at 10:53 PM, Rick Mann wrote:
>
> Sigh, I figured it out. Not only do you have to use NS_ENUM, the enumeration
> members MUST begin with the name of the enumeration.
Example please ... I feel unfulfilled.
-rags
___
Cocoa-dev m
> On Oct 21, 2014, at 09:18 , Raglan T. Tiger wrote:
>
>
>
>
>> On Oct 20, 2014, at 10:53 PM, Rick Mann wrote:
>>
>> Sigh, I figured it out. Not only do you have to use NS_ENUM, the enumeration
>> members MUST begin with the name of the enumeration.
>
>
> Example please ... I feel unfulf
> On Oct 21, 2014, at 11:38 AM, Rick Mann wrote:
>
>> On Oct 21, 2014, at 09:18 , Raglan T. Tiger wrote:
>>
>>> On Oct 20, 2014, at 10:53 PM, Rick Mann wrote:
>>>
>>> Sigh, I figured it out. Not only do you have to use NS_ENUM, the
>>> enumeration members MUST begin with the name of the enu
> On Oct 21, 2014, at 2:44 AM, Gerriet M. Denkmann wrote:
>
> 10.10, Xcode 6.1, using Arc.
>
> The following code works fine, with USE_INVOCATION defined or not:
[...]
> Without USE_INVOCATION defined, I get some compiler warning about potential
> leaks, because selector is unknown.
>
> But
> On Oct 21, 2014, at 13:13 , Greg Parker wrote:
>
> NS_ENUM or NS_OPTIONS is required for Swift to import it.
>
> The name prefix is not required. If I recall correctly, the Swift importer
> has some heuristics to omit any shared prefix from the Swift names, but if
> there is no prefix then
On Oct 21, 2014, at 13:33 , Rick Mann wrote:
>
> Honestly, though, I don't see why Swift can't just deal with "plain" enums.
Because it’s not an Obj-C compiler?
I suspect that the reason you saw the “incomplete” behavior is that you
declared the enum in two parts:
> enum McpSweepState
> {
>
> On Oct 21, 2014, at 14:26 , Quincey Morris
> wrote:
>
> On Oct 21, 2014, at 13:33 , Rick Mann wrote:
>>
>> Honestly, though, I don't see why Swift can't just deal with "plain" enums.
>
> Because it’s not an Obj-C compiler?
>
> I suspect that the reason you saw the “incomplete” behavior is
On Oct 21, 2014, at 14:35 , Rick Mann wrote:
>
>> On Oct 21, 2014, at 14:26 , Quincey Morris
>> wrote:
>>
>> Honestly, though, I don’t see why you can’t just deal with writing enums the
>> “compatible” way.
>
> Because the file whence it comes is part of a library of C++ code that also
> ha
> On Oct 21, 2014, at 14:54 , Quincey Morris
> wrote:
>
> On Oct 21, 2014, at 14:35 , Rick Mann wrote:
>>
>>> On Oct 21, 2014, at 14:26 , Quincey Morris
>>> wrote:
>>>
>>> Honestly, though, I don’t see why you can’t just deal with writing enums
>>> the “compatible” way.
>>
>> Because the
On Oct 21, 2014, at 16:25 , Rick Mann wrote:
>
> But the names of the elements all have to start with the type name, and that
> means not only changing the entire code base that uses the header, but also
> changing the naming convention used by that code base. Sure, we can do it,
> but it'll i
> On Oct 21, 2014, at 4:25 PM, Rick Mann wrote:
>
> But the names of the elements all have to start with the type name
This should not be the case. Please provide an example of the ObjC and Swift
code you're using.
Here's mine:
// ObjC header: no type name prefix on enumerators
typed
I've created a sample project showing the behavior and submitted it with radar
#18730653.
> On Oct 21, 2014, at 17:09 , Greg Parker wrote:
>
>
>> On Oct 21, 2014, at 4:25 PM, Rick Mann wrote:
>>
>> But the names of the elements all have to start with the type name
>
> This should not be the
> On Oct 21, 2014, at 5:45 PM, Rick Mann wrote:
>
> I've created a sample project showing the behavior and submitted it with
> radar #18730653.
Thanks for the bug report. There is a Swift importer bug here. Your enumerators
all have a common name prefix, but that name prefix differs from the
> On Oct 21, 2014, at 18:13 , Greg Parker wrote:
>
>
>> On Oct 21, 2014, at 5:45 PM, Rick Mann wrote:
>>
>> I've created a sample project showing the behavior and submitted it with
>> radar #18730653.
>
> Thanks for the bug report. There is a Swift importer bug here. Your
> enumerators all
NSAlert has: - (void)beginSheetModalForWindow:(NSWindow *)sheetWindow
completionHandler:(void (^)(NSModalResponse returnCode))handler
NSModalResponse has three values: Stop, Abort, Continue - none of which bear
any resemblance with the buttons: Default, Alternate, Other in my NSAle
>
> The suggested alternative is NSAlertFirstButtonReturn, etc., which have
> values, which very much unlike the actual returned values.
Those values worked for me found by trial an error because the documentation
and headers made no sense at all. I was working in swift and found
this code to
On Oct 21, 2014, at 10:59 PM, Gerriet M. Denkmann wrote:
> NSAlert has: - (void)beginSheetModalForWindow:(NSWindow *)sheetWindow
> completionHandler:(void (^)(NSModalResponse returnCode))handler
>
> NSModalResponse has three values: Stop, Abort, Continue - none of which bear
> any
Even the old selector-based one could return NSModalResponse values - I saw it
happen once in some over-paranoid code that had a switch for the resultCode and
an assert in the default case. Surprise, it wasn't handling Abort.
NSSavePanel doc shows it as just
- (void)beginSheetModalForWindow:(N
23 matches
Mail list logo
