Re: Exact semantics of NSThread executation states?

[Glenn L. Austin]

> On Jul 12, 2016, at 2:52 PM, Sean McBride  wrote:
> 
> Hi all,
> 
> NSThread has at least 3 execution state properties: executing, finished, 
> cancelled.  Alas, the docs don't say much about what they mean beyond 
> circular definitions like "A Boolean value that indicates whether the 
> receiver is executing".
> 
> I have code where I create an NSThread, add a runloop source, then invoke 
> "start" on the thread.  I have assumed that once I invoke "start" that 
> "isExecuting" should give YES.  Literally:
> 
>   [myThread start];
>   assert([myThread isExecuting]);
> 
> On 10.11.5 and earlier this *seems* to always be true, but on 10.12b2 it's 
> not.  I'm trying to understand if my assumption was wrong or if it's an OS 
> bug.

There's no guarantee that a thread will be running at exit of -[NSThread start] 
-- only that it has been scheduled for execution. The lower-level pthread APIs 
also don't guarantee that the thread will start executing when the thread is 
created.

In reality, there's a fourth state -- scheduled -- that comes before executing. 
 Most of the time you don't need to worry about it.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Exact semantics of NSThread executation states?

[Sean McBride]

Hi all,

NSThread has at least 3 execution state properties: executing, finished, 
cancelled.  Alas, the docs don't say much about what they mean beyond circular 
definitions like "A Boolean value that indicates whether the receiver is 
executing".

I have code where I create an NSThread, add a runloop source, then invoke 
"start" on the thread.  I have assumed that once I invoke "start" that 
"isExecuting" should give YES.  Literally:

[myThread start];
assert([myThread isExecuting]);

On 10.11.5 and earlier this *seems* to always be true, but on 10.12b2 it's not. 
 I'm trying to understand if my assumption was wrong or if it's an OS bug.

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: specifying UIInterfaceOrientationMask

[Quincey Morris]

On Jul 12, 2016, at 11:25 , William Squires  wrote:
> 
> what dumb Swift feature am I overlooking now?

It’s an OptionsSet now, so you specify compound values with an array literal 
form. In Swift 3, with API swiftification, it’ll be something like:

return [.portrait, .landscapeLeft]

In Swift 2.2, the names may be slightly different.



___

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: specifying UIInterfaceOrientationMask

[Steve Christensen]

So, (UIInterfaceOrientationMask.Portrait | 
UIInterfaceOrientationMask.LandscapeLeft) doesn't work?


> On Jul 12, 2016, at 11:25 AM, William Squires  wrote:
> 
> In iOS 8, I would (in a view controller):
> 
> ...
> override func supportedInterfaceOrientations() -> Int
> {
> return Int(UIInterfaceOrientationMask.Portrait.rawValue) | 
> Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue)
> }
> ...
> 
> but this no longer works in iOS 9, as the method signature is now:
> 
> func supportedInterfaceOrientations() -> UIInterfaceOrientationMask
> 
> instead. So how do I cast the Int result above to a 
> UIInterfaceOrientationMask? I tried the obvious:
> 
> return 
> UIInterfaceOrientationMask(Int(UIInterfaceOrientationMask.Portrait.rawValue) 
> | Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue))
> 
> but Xcode complains that UIInterfaceOrientationMask doesn't have an 
> initializer that takes "Int".
> 
> so what dumb Swift feature am I overlooking now?


___

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: Best way to model something that's drawable (i.e. has a visual representation in the UI)

[Alastair Houghton]

On 12 Jul 2016, at 19:11, William Squires  wrote:
> 
> Normally, of course, models shouldn't know anything about UI, and vice versa, 
> but what about when the models themselves represent something visual that the 
> UI needs to draw...

[snip]

> In this case, it makes sense that the object with the information needed to 
> draw, is the model object itself…

[snip]

> So, in my app, the view's drawRect: method will [snip] ask for all the model 
> objects that are visible within its bounds rect [snip] and will then iterate 
> over them, asking them to draw themselves, now that the graphics context is 
> properly set up.

This is the direct approach, and it’s a perfectly valid way to do things.  The 
other option is to implement a Renderer object that uses the Visitor pattern 
(which, in a dynamic language like Objective-C, you might implement by 
dynamically generating the method name on the basis of the class name passed 
in; or in a static language like C++ or Swift, you might choose to do it by 
overloading a “draw” method).  The direct way is usually faster; the Visitor 
approach has the advantage that you can easily implement different renderers 
without all the model objects needing to know what to do.

> The question is, if my GameObject (base class) defines a drawRect(bounds: 
> CGRect) itself, and the code in the UIView subclass' drawRect: method passes 
> a CGRect (which is within it's own bounds) to the model's drawRect:, will the 
> code in the model's drawRect: "see" the graphics context of the UIView, so 
> that you can set the stroke or fill color using the setStroke() and setFill() 
> methods on UIColor, as well as anything else that may require that context, 
> such as lower-level calls to CoreGraphics?

Yes.  Cocoa keeps track of the current graphics context.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

specifying UIInterfaceOrientationMask

[William Squires]

In iOS 8, I would (in a view controller):

...
override func supportedInterfaceOrientations() -> Int
{
return Int(UIInterfaceOrientationMask.Portrait.rawValue) | 
Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue)
}
...

but this no longer works in iOS 9, as the method signature is now:

func supportedInterfaceOrientations() -> UIInterfaceOrientationMask

instead. So how do I cast the Int result above to a UIInterfaceOrientationMask? 
I tried the obvious:

return 
UIInterfaceOrientationMask(Int(UIInterfaceOrientationMask.Portrait.rawValue) | 
Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue))

but Xcode complains that UIInterfaceOrientationMask doesn't have an initializer 
that takes "Int".

so what dumb Swift feature am I overlooking now?


___

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

Best way to model something that's drawable (i.e. has a visual representation in the UI)

[William Squires]

Normally, of course, models shouldn't know anything about UI, and vice versa, 
but what about when the models themselves represent something visual that the 
UI needs to draw (like in a drawing/painting program, or - in my case - 
GameObject instances that can be objects found in the "dungeon" that the player 
in the game can see and possibly interact with)?

In this case, it makes sense that the object with the information needed to 
draw, is the model object itself (since it has all the properties needed, such 
as visible, passable, floorImage, etc...), but the model objects have no 
graphics context to draw into (that's the responsibility of the drawRect: 
method of a UIView subclass). So, in my app, the view's drawRect: method will 
get a reference to it's view controller, and ask for all the model objects that 
are visible within its bounds rect (and considering the "camera" view rect 
which is managed by the view controller), and will then iterate over them, 
asking them to draw themselves, now that the graphics context is properly set 
up.

Otherwise, the UIView subclass' drawRect: method becomes unwieldy as it is then 
too coupled to the model objects (i.e. it would - for each model object - have 
to determine what class they are, then have custom drawing code to actually 
draw what the model represents) This is too brittle, and is one reason to use 
polymorphism via subclassing to define behaviors specific to a particular class 
of object.

The question is, if my GameObject (base class) defines a drawRect(bounds: 
CGRect) itself, and the code in the UIView subclass' drawRect: method passes a 
CGRect (which is within it's own bounds) to the model's drawRect:, will the 
code in the model's drawRect: "see" the graphics context of the UIView, so that 
you can set the stroke or fill color using the setStroke() and setFill() 
methods on UIColor, as well as anything else that may require that context, 
such as lower-level calls to CoreGraphics?


___

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