Re: Property synthesis trouble - 32 vs 64 bit builds

[Graham Cox]

> On 6 Jul 2016, at 7:10 AM, Jonathan Taylor  
> wrote:
> 
> Quicktime. My code has been 32-bit only since I first wrote it, because I 
> make use of the APIs in QuickTime/ImageCompression.h for encoding movies.


Not really quite on-topic, but if you are having to switch to a whole new API, 
a possible alternative is to use ffmpeg. You can just embed the binary in your 
app and wrap it in a NSTask. I just did this for a very specific video encoding 
requirement I had and it was (in my case) a far simpler exercise than learning 
the necessary AVFoundation API. I had it working in about an hour as opposed to 
probably several days, and most of that hour was figuring out how to correctly 
pass command line parameters to NSTask.

It might seem sagreligious to some not to use a native API if one is available, 
but OTOH, sometimes the best tools are the ones to hand.

—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: Prioritize my own app's disk access

[Jens Alfke]

> On Jul 5, 2016, at 2:40 PM, Jonathan Taylor  
> wrote:
> 
> As far as the quality of service goes, I can't see the APIs for that (looking 
> in the 10.9 SDK, at least). Am I looking in the wrong place?

IIRC, QoS was added in 10.10.

> I confess that currently I am using pure cocoa -writeToFile:atomically calls. 
> I am fully aware that this is very unlikely to be the best way to do high 
> performance IO, but it's great in terms of convenience.

It probably just opens the file and issues one big write call, which is pretty 
efficient.

The ways to get more efficient would be to stream the data, if that’s possible 
— instead of computing everything and then writing it, write the data 
incrementally while the computation is going on. That interleaves CPU and I/O 
tasks. It also lowers memory usage, which will help avoid paging.

If the data is too big to fit in RAM but has to be generated up-front, the best 
approach might be to create the file first, memory-map it as writeable, and 
then use the mapped address space as the buffer you write the data into.

—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: Prioritize my own app's disk access

[Jonathan Taylor]

Thanks everyone for your replies on this second question of mine. Some 
responses below:

On 5 Jul 2016, at 18:20, Quincey Morris  
wrote:

> What worries me about the Darwin-level (i.e. Unix-level) API suggestions that 
> others have made is that you don’t know how these interact with Cocoa apps. 
> You didn’t actually say whether your app is a Cocoa app, but if so …

It is indeed a cocoa app.

> I think the best modern approach is to route your CPU and IO usage via GCD. 
> That is, from the point where some callback gives you raw video, use 
> dispatch_async to schedule the processing on a GCD queue, and use the GCD I/O 
> primitives to actually do the I/O.
> That will allow you to specify a quality of service (“user interactive” is 
> the highest), which should interact properly with other apps, e.g. the Finder 
> doing a large copy.
> That should take care of CPU and IO. For memory, I agree with Jens that you 
> should preallocate and reuse memory buffers, rather than re-allocating them, 
> as far as possible.

Interesting. I know and love GCD queues, but have not played with the I/O 
stuff. As far as the quality of service goes, I can't see the APIs for that 
(looking in the 10.9 SDK, at least). Am I looking in the wrong place? Text 
search for variants on "user interactive" haven't brought up anything for me in 
the "dispatch" folder.

If I am honest, I suspect I will probably leave things as-is - the for the same 
pragmatic reasons I mentioned in my other email. Unless and until I have 
problems with i/o throughput when my own app is running unmolested, I think 
I'll probably just reiterate advice to users not to leave large copy operations 
running in the background while also recording to disk! I thought I would ask 
the question just in case there was an easy solution I should know about, but 
it sounds as if (understandably) any solution would be fairly involved and 
require some structural changes to my code. That's not to say that it isn't 
very interesting to broaden my mind and understand better what APIs are out 
there, for the next time...


On 5 Jul 2016, at 17:19, Jens Alfke  wrote:

> In addition to increasing I/O priority, there may be other ways to make your 
> disk writes more efficient. For example you can preallocate space for the 
> file before writing to it. Writing in larger chunks may also help. (Of course 
> you may have tried these already.)

I confess that currently I am using pure cocoa -writeToFile:atomically calls. I 
am fully aware that this is very unlikely to be the best way to do high 
performance IO, but it's great in terms of convenience. Again, I'm afraid (in 
the very specific context of a not-that-widely-distributed program running on 
dedicated computers) my question was fishing for a low-hanging fruit that might 
allow me a quick fix that left my own code as-is but encouraged the Finder to 
play nicely along with my not-entirely-optimal code :-)

> Using wired memory for your buffers is also a good idea, since if any of 
> those buffers get paged out things will really go to hell.

Buffer paging is indeed what eventually brings the program (and machine) to its 
knees if things go *really* badly wrong in terms of a backlog. I'm not seeing 
how this would solve a fundamental problem of i/o bandwidth being inadequate, 
but I can see that this would be a good thing to do in terms of preventing some 
*transient* condition from tipping things from one stable state (streaming to 
disk successfully) to another stable, but disastrous, state (thrashing the disk 
due to paging, meaning the frames can't be saved fast enough, more backlog, 
more thrashing, etc).

> Also, I assume you’ve profiled the code and are confident that it’s being 
> constrained by I/O bandwidth and not CPU time? (It’s possible that I/O 
> requests made by real-time threads get higher priority; I can’t remember if 
> this is the case, as it’s a long time since I’ve had to deal with this sort 
> of stuff.)

Yes. Definitely measured as an i/o bandwidth issue in this case. I am presuming 
(though have not profiled on this level of detail) that the problem is 
primarily one of seek times on a magnetic disk - a Finder copy going on in the 
background is competing with my own writes in terms of where the disk head 
needs to be...
___

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: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

On 5 Jul 2016, at 22:22, "Gary L. Wade"  wrote:
> You might need to write some lower level stuff, but some of the things in 
> there can be done, albeit differently. Apple knows I've submitted a number of 
> bugs and incident reports to get codecs supported in later frameworks. Do the 
> same. It may happen.


... ah, and I've just seen this reply from Gary as well. That's good to know - 
maybe I should take a fresh look if I do commit to the switch to a 64-bit build.
___

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: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

>> Quicktime.
> 
> Oh, you poor thing. That’s one nasty API. (Actually dozens of nasty APIs.) O_o

Yep. I rely on code that I worked out years ago, with the help of examples on 
the internet, and I do my best to leave that code untouched!

>> My code has been 32-bit only since I first wrote it, because I make use of 
>> the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
>> understanding (as of last time I checked) that no equivalent functionality 
>> is available in the newer APIs.
> 
> AVFoundation is supposed to be the replacement for QuickTime, and definitely 
> supports video encoding. I’ve only used it for audio, though, so I don’t know 
> the details of its video support.

Unless it has been enhanced, I think the support for proper compression was 
lacking, and as a result any generated movie files would be enormous.

___

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: Property synthesis trouble - 32 vs 64 bit builds

[Gary L. Wade]

You might need to write some lower level stuff, but some of the things in there 
can be done, albeit differently. Apple knows I've submitted a number of bugs 
and incident reports to get codecs supported in later frameworks. Do the same. 
It may happen.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Jul 5, 2016, at 2:10 PM, Jonathan Taylor  
> wrote:
> 
> Quicktime. My code has been 32-bit only since I first wrote it, because I 
> make use of the APIs in QuickTime/ImageCompression.h for encoding movies. 
> It's my understanding (as of last time I checked) that no equivalent 
> functionality is available in the newer APIs.


___

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: Property synthesis trouble - 32 vs 64 bit builds

[Jens Alfke]

> On Jul 5, 2016, at 2:10 PM, Jonathan Taylor  
> wrote:
> 
> Quicktime.

Oh, you poor thing. That’s one nasty API. (Actually dozens of nasty APIs.) O_o

> My code has been 32-bit only since I first wrote it, because I make use of 
> the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
> understanding (as of last time I checked) that no equivalent functionality is 
> available in the newer APIs.

AVFoundation is supposed to be the replacement for QuickTime, and definitely 
supports video encoding. I’ve only used it for audio, though, so I don’t know 
the details of its video support.

—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: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Thanks everyone for your replies - some responses below:

On 5 Jul 2016, at 20:55, Greg Parker  wrote:
> A synthesized property must use one of the following types of storage:
> 1. An ivar in that class that @synthesize creates.
> 2. An ivar in that class that you defined yourself.
> 
> @synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit 
> macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars 
> would make it too easy to accidentally change ivar layout and break 
> compatibility.
> 
> No platform allows @synthesize to bind to a superclass ivar. That would make 
> it too easy to accidentally bind to an unrelated superclass ivar when you 
> really wanted to create a new ivar.

That last statement is a surprise to me. I had believed that the 32-bit code I 
posted was doing just that - MutableSettings binding its property to the ivar 
in ImmutableSettings. Certainly it's not clear to me how that statement *and* 
your statement that #1 is not supported on 32-bit could both be true (there is 
no backing ivar that I declare in the mutable subclass). I also ~think~ the 
code is working correctly on a 32-bit platform (and has been for several years).

I'm not meaning to be argumentative, just trying to get my head around this :-) 
  

On 5 Jul 2016, at 18:12, Quincey Morris  
wrote:
> I’d recommend a different approach, especially if there’s no behavior for the 
> property other than getting or setting an instance variable (which I assume, 
> because you’re trying to use synthesis):
> [...]
> It may sound weird to make the property (internally) settable in an immutable 
> class, but the instance variable is always modifiable in the superclass 
> anyway, so it’s kinda the same thing. Having a private setter there doesn’t 
> really change anything.

Interesting. It does indeed sound weird, but I agree that it shouldn't actually 
be any different to what I'm currently doing. I might just give that a go!

Does this approach have any specific advantages compared to the approach 
suggested by Keary (i.e. basically don't do any synthesis, and just write a 
getter in the base class and a setter in the subclass)?

> Side note:
> 
> Why are you even supporting 32-bit architectures on the Mac? The only good 
> reason I can think of is if you must still update users running OS X 10.5. 
> Users of 10.6.8 and above can (and should) use 64-bit versions of apps.

Quicktime. My code has been 32-bit only since I first wrote it, because I make 
use of the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
understanding (as of last time I checked) that no equivalent functionality is 
available in the newer APIs. That, plus a big dose of "if it ain't broke, don't 
fix it", as a scientist for whom this Cocoa application of mine is a very 
helpful tool for me and my colleagues, but is just a means to an end rather 
than a product in its own right.

I have only now started looking at 64 bit (knowing I am losing the quicktime 
functionality) because I wanted to look at interfacing with libraries that are 
64-bit only.
___

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: Property synthesis trouble - 32 vs 64 bit builds

[Greg Parker]

> On Jul 5, 2016, at 9:27 AM, Jens Alfke  wrote:
> 
>> On Jul 5, 2016, at 4:36 AM, Jonathan Taylor  
>> wrote:
>> 
>> It surprises me that I have to write different synthesis code for 32- or 
>> 64-bit builds
> 
> It’s because they use different Obj-C runtimes. For compatibility reasons, 
> 32-bit Mac apps still use the old runtime, while 64-bit apps (and all iOS 
> apps) get to use the new improved runtime.
> 
> One of the differences between the runtimes is how instance variables are 
> accessed, and I think your particular situation — trying to synthesize a 
> property backed by an _inherited_ ivar — is an edge case.

A synthesized property must use one of the following types of storage:
1. An ivar in that class that @synthesize creates.
2. An ivar in that class that you defined yourself.

@synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit 
macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars 
would make it too easy to accidentally change ivar layout and break 
compatibility.

No platform allows @synthesize to bind to a superclass ivar. That would make it 
too easy to accidentally bind to an unrelated superclass ivar when you really 
wanted to create a new ivar.


-- 
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: Prioritize my own app's disk access

[Michael David Crawford]

If it's a dedicated workstation, it should be OK to require a RAID 0.
That won't affect anyone's priority, but all disk I/O will be divided
among two or more disks.

Alternatively, dedicate a single drive only to video, with your other
drive being for everything else.
Michael David Crawford, Baritone
mdcrawf...@gmail.com

  One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light.


On Tue, Jul 5, 2016 at 10:20 AM, Quincey Morris
 wrote:
> On Jul 5, 2016, at 05:36 , Jonathan Taylor  
> wrote:
>>
>> suggestions that might be relevant here
>
> What worries me about the Darwin-level (i.e. Unix-level) API suggestions that 
> others have made is that you don’t know how these interact with Cocoa apps. 
> You didn’t actually say whether your app is a Cocoa app, but if so …
>
> I think the best modern approach is to route your CPU and IO usage via GCD. 
> That is, from the point where some callback gives you raw video, use 
> dispatch_async to schedule the processing on a GCD queue, and use the GCD I/O 
> primitives to actually do the I/O.
>
> That will allow you to specify a quality of service (“user interactive” is 
> the highest), which should interact properly with other apps, e.g. the Finder 
> doing a large copy.
>
> That should take care of CPU and IO. For memory, I agree with Jens that you 
> should preallocate and reuse memory buffers, rather than re-allocating them, 
> as far as possible.
>
> ___
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@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: Prioritize my own app's disk access

[Quincey Morris]

On Jul 5, 2016, at 05:36 , Jonathan Taylor  
wrote:
> 
> suggestions that might be relevant here

What worries me about the Darwin-level (i.e. Unix-level) API suggestions that 
others have made is that you don’t know how these interact with Cocoa apps. You 
didn’t actually say whether your app is a Cocoa app, but if so …

I think the best modern approach is to route your CPU and IO usage via GCD. 
That is, from the point where some callback gives you raw video, use 
dispatch_async to schedule the processing on a GCD queue, and use the GCD I/O 
primitives to actually do the I/O.

That will allow you to specify a quality of service (“user interactive” is the 
highest), which should interact properly with other apps, e.g. the Finder doing 
a large copy.

That should take care of CPU and IO. For memory, I agree with Jens that you 
should preallocate and reuse memory buffers, rather than re-allocating them, as 
far as possible.

___

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: Property synthesis trouble - 32 vs 64 bit builds

[Quincey Morris]

On Jul 5, 2016, at 04:36 , Jonathan Taylor  
wrote:
> 
> @interface ImmutableSettings : NSObject
> {
>BOOL_myFlag;
> }
> @property (readonly) BOOL myFlag;
> @end
> 
> @interface MutableSettings : ImmutableSettings
> @property (readwrite) BOOL myFlag;
> @end
> 
> @implementation ImmutableSettings
> 
> -(id)init
> {
>if (!(self = [super init]))
>return nil;
>_myFlag = true;
>return self;
> }
> @synthesize myFlag = _myFlag;
> 
> @end

You have to remember that there’s no magic behind properties. Each class has 
(potentially) a getter method, a setter method and an instance variable, which 
makes a total of 6 (potential) things across 2 classes. When one is a subclass 
of the other, that’s 3 opportunities for conflicts and ambiguities about which 
thing is meant at any given place in the code. Different versions of the 
compiler detect and complain about different ambiguities.

I’d recommend a different approach, especially if there’s no behavior for the 
property other than getting or setting an instance variable (which I assume, 
because you’re trying to use synthesis):

— In ImmutableSettings.h, declare “myFlag” as a readonly property. This is its 
public definition.

— In ImmutableSettings.m, add a class extension “@interface ImmutableSettings 
()” that redeclares “myFlag” as readwrite.

— Synthesize the property in ImmutableSettings.m, producing both getter and 
setter. Note, however, that the setter is not available publicly.

— In MutableSettings.h, redeclare “myFlag” as a readwrite property. This makes 
it available publicly.

— In MutableSettings.m, say “@dynamic myFlag;” to indicate that the accessors 
will be provided at runtime (by the parent class in this case). If you needed 
custom behavior in the setter, you could simply provide an override to 
setMyFlag: too. Do not synthesize the property in this class.

It may sound weird to make the property (internally) settable in an immutable 
class, but the instance variable is always modifiable in the superclass anyway, 
so it’s kinda the same thing. Having a private setter there doesn’t really 
change anything.

Alternative approach:

If the “myFlag” property is always and forever YES in the superclass, then 
don’t synthesize anything in that class, but write a custom setter that simply 
return YES. That saves a little bit of memory by not having an instance 
variable at all. The just synthesize the readwrite property in the subclass in 
the normal way. In the subclass, synthesize the readwrite property normally.

Side note:

Why are you even supporting 32-bit architectures on the Mac? The only good 
reason I can think of is if you must still update users running OS X 10.5. 
Users of 10.6.8 and above can (and should) use 64-bit versions of apps.

___

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: Property synthesis trouble - 32 vs 64 bit builds

[Jens Alfke]

> On Jul 5, 2016, at 4:36 AM, Jonathan Taylor  
> wrote:
> 
> It surprises me that I have to write different synthesis code for 32- or 
> 64-bit builds

It’s because they use different Obj-C runtimes. For compatibility reasons, 
32-bit Mac apps still use the old runtime, while 64-bit apps (and all iOS apps) 
get to use the new improved runtime.

One of the differences between the runtimes is how instance variables are 
accessed, and I think your particular situation — trying to synthesize a 
property backed by an _inherited_ ivar — is an edge case.

You could ask this on the objc-language mailing list to see if any gurus can 
weigh in.

—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: Prioritize my own app's disk access

[Jens Alfke]

You might try asking on the darwin-userlevel mailing list.

In addition to increasing I/O priority, there may be other ways to make your 
disk writes more efficient. For example you can preallocate space for the file 
before writing to it. Writing in larger chunks may also help. (Of course you 
may have tried these already.)

Using wired memory for your buffers is also a good idea, since if any of those 
buffers get paged out things will really go to hell.

Also, I assume you’ve profiled the code and are confident that it’s being 
constrained by I/O bandwidth and not CPU time? (It’s possible that I/O requests 
made by real-time threads get higher priority; I can’t remember if this is the 
case, as it’s a long time since I’ve had to deal with this sort of stuff.)

—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: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Thanks for that information - that’s very helpful. It sounds from what you are 
saying as if there is nothing wrong with me redefining the *property* in the 
subclass (as read-write), but that it’s just the synthesis itself that is the 
problem? Assuming that is the case, I can easily(*) rectify that by writing 
explicit setters/getters, so I will do that.

(*) there are rather a lot of these properties in the actual original code, but 
it just involves a lot of typing!


On 5 Jul 2016, at 16:12, Keary Suska  wrote:

> 
>> On Jul 5, 2016, at 5:36 AM, Jonathan Taylor  
>> wrote:
>> 
>> I have a problem with property synthesis in my code, which I hope somebody 
>> can advise on. I find I have to write different property synthesis code for 
>> 32- or 64-bit builds in order to avoid compiler errors.
>> 
>> A minimal demonstration of the problem can be found below - build as part of 
>> a fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I 
>> have to write different synthesis code for 32- or 64-bit builds - and this 
>> then makes me worry that I am doing something more fundamentally wrong. Can 
>> anyone comment (or explain)?
>> 
>> [I appreciate that this code may be old-fashioned in style - I am not even 
>> sure what is or is not the recommended style these days. It seems to work 
>> though - and, importantly, as far as I can tell the synthesized property 
>> myFlag on MutableSettings *does* map to the same backing variable, even on a 
>> 64-bit build where I am not able to specify the backing variable in the 
>> synthesis statement]
> 
> 32 vs 64 is likely coincidental, and probably has more to do with compiler 
> differences. I.e., at that time, there were additional compiler “features” 
> for 64 bit vs 32 bit. So my thought is that what you are doing is wrong in 
> both cases, but you are simply getting different compiler errors.
> 
> The essential issue I believe is that you cannot re-synthesize in a subclass. 
> You will have to specify the setter explicitly. The issue in the second 
> (64-bit) case is that when you specify @synthesize with an instance variable 
> you are specifying a *new* instance variable on that class, but the compiler 
> correctly warns you that that instance variable has already been defined in 
> the superclass and therefore cannot also be defined in the subclass. The 32 
> bit compiler seems to be letting you get away with this error, but it could 
> have horrible unintended consequences.

___

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: Prioritize my own app's disk access

[Jonathan Taylor]

Thanks Alastair. Mark Allan’s email set me off reading things in that area, and 
I am indeed reading the man page for setiopolicy_np at this very moment!

Certainly sounds like the API I am looking for although, as you say, it’s not 
clear where the “default” policy fits into the hierarchy. The man page states 
that [IOPOL_IMPORTANT] "is the default I/O policy for new threads”, and so if 
true then that would suggest that all a program can do is DOWNgrade its 
priority. However, the man page is evidently not entirely correct, based on the 
result you got, so who knows!

I also wonder what priority the Finder would use for copying a folder. I might 
hope it would set itself to STANDARD or THROTTLE; if it does do that, then that 
would suggest that even this is not proving enough to prevent my code getting 
backlogged…


On 5 Jul 2016, at 16:34, Alastair Houghton  wrote:

> On 5 Jul 2016, at 13:36, Jonathan Taylor  
> wrote:
>> 
>> This is a long shot, but I thought I would ask in case an API exists to do 
>> what I want. One of the roles of my code is to record video to disk as it is 
>> received from a camera. A magnetic hard disk can normally keep up with this, 
>> but if the user is also doing other things on the computer (e.g. long file 
>> copy in the Finder) then we are unable to keep up, and accumulate an 
>> ever-increasing backlog of frames waiting to be saved. This eventually leads 
>> to running out of memory, thrashing, and an unresponsive computer. Dropping 
>> frames is not an option. In this case, the computer is a dedicated 
>> workstation running my code, so it *is* correct for me to consider my code 
>> to be the number 1 priority on the computer.
>> 
>> What I am wondering is whether there is some way I can communicate this 
>> requirement, to cause other apps such as the finder to get disk access at 
>> lower priority. Or alternatively, a way that I can demand high priority 
>> temporarily, at times when I identify that we have accumulated a save 
>> backlog?
> 
> Take a look at get/setiopolicy_np().  It isn’t clear from the documentation 
> exactly what the default behaviour is; when I tried calling getiopolicy_np() 
> I got IOPOL_DEFAULT, which isn’t even mentioned as a value on the man page, 
> but you may find that setting your thread/process’s IO policy to 
> IOPOL_IMPORTANT solves your problem.


___

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: Prioritize my own app's disk access

[Alastair Houghton]

On 5 Jul 2016, at 13:36, Jonathan Taylor  wrote:
> 
> This is a long shot, but I thought I would ask in case an API exists to do 
> what I want. One of the roles of my code is to record video to disk as it is 
> received from a camera. A magnetic hard disk can normally keep up with this, 
> but if the user is also doing other things on the computer (e.g. long file 
> copy in the Finder) then we are unable to keep up, and accumulate an 
> ever-increasing backlog of frames waiting to be saved. This eventually leads 
> to running out of memory, thrashing, and an unresponsive computer. Dropping 
> frames is not an option. In this case, the computer is a dedicated 
> workstation running my code, so it *is* correct for me to consider my code to 
> be the number 1 priority on the computer.
> 
> What I am wondering is whether there is some way I can communicate this 
> requirement, to cause other apps such as the finder to get disk access at 
> lower priority. Or alternatively, a way that I can demand high priority 
> temporarily, at times when I identify that we have accumulated a save backlog?

Take a look at get/setiopolicy_np().  It isn’t clear from the documentation 
exactly what the default behaviour is; when I tried calling getiopolicy_np() I 
got IOPOL_DEFAULT, which isn’t even mentioned as a value on the man page, but 
you may find that setting your thread/process’s IO policy to IOPOL_IMPORTANT 
solves your problem.

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

Re: Prioritize my own app's disk access

[Mark Allan]

Have you tried to nice/renice your process ID? I know that works for CPU usage 
but I'm not sure about other hardware resources.

A cursory glance at the man pages for getpriority & setpriority seem to 
indicate that network and disk IO can be lowered in priority so I would try 
that first to see if it also works to increase priority.

Mark

> On 5 Jul 2016, at 1:36 pm, Jonathan Taylor  
> wrote:
> 
> This is a long shot, but I thought I would ask in case an API exists to do 
> what I want. One of the roles of my code is to record video to disk as it is 
> received from a camera. A magnetic hard disk can normally keep up with this, 
> but if the user is also doing other things on the computer (e.g. long file 
> copy in the Finder) then we are unable to keep up, and accumulate an 
> ever-increasing backlog of frames waiting to be saved. This eventually leads 
> to running out of memory, thrashing, and an unresponsive computer. Dropping 
> frames is not an option. In this case, the computer is a dedicated 
> workstation running my code, so it *is* correct for me to consider my code to 
> be the number 1 priority on the computer.
> 
> What I am wondering is whether there is some way I can communicate this 
> requirement, to cause other apps such as the finder to get disk access at 
> lower priority. Or alternatively, a way that I can demand high priority 
> temporarily, at times when I identify that we have accumulated a save backlog?
> 
> I can see reasons why this is probably not possible, but I thought I’d ask if 
> anyone has any suggestions that might be relevant here.
> Thanks for any suggestions
> Jonny.



___

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: Property synthesis trouble - 32 vs 64 bit builds

[Keary Suska]

> On Jul 5, 2016, at 5:36 AM, Jonathan Taylor  
> wrote:
> 
> I have a problem with property synthesis in my code, which I hope somebody 
> can advise on. I find I have to write different property synthesis code for 
> 32- or 64-bit builds in order to avoid compiler errors.
> 
> A minimal demonstration of the problem can be found below - build as part of 
> a fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I 
> have to write different synthesis code for 32- or 64-bit builds - and this 
> then makes me worry that I am doing something more fundamentally wrong. Can 
> anyone comment (or explain)?
> 
> [I appreciate that this code may be old-fashioned in style - I am not even 
> sure what is or is not the recommended style these days. It seems to work 
> though - and, importantly, as far as I can tell the synthesized property 
> myFlag on MutableSettings *does* map to the same backing variable, even on a 
> 64-bit build where I am not able to specify the backing variable in the 
> synthesis statement]

32 vs 64 is likely coincidental, and probably has more to do with compiler 
differences. I.e., at that time, there were additional compiler “features” for 
64 bit vs 32 bit. So my thought is that what you are doing is wrong in both 
cases, but you are simply getting different compiler errors.

The essential issue I believe is that you cannot re-synthesize in a subclass. 
You will have to specify the setter explicitly. The issue in the second 
(64-bit) case is that when you specify @synthesize with an instance variable 
you are specifying a *new* instance variable on that class, but the compiler 
correctly warns you that that instance variable has already been defined in the 
superclass and therefore cannot also be defined in the subclass. The 32 bit 
compiler seems to be letting you get away with this error, but it could have 
horrible unintended consequences.

> @interface ImmutableSettings : NSObject
> {
>BOOL_myFlag;
> }
> @property (readonly) BOOL myFlag;
> @end
> 
> @interface MutableSettings : ImmutableSettings
> @property (readwrite) BOOL myFlag;
> @end
> 
> @implementation ImmutableSettings
> 
> -(id)init
> {
>if (!(self = [super init]))
>return nil;
>_myFlag = true;
>return self;
> }
> @synthesize myFlag = _myFlag;
> 
> @end
> 
> @implementation MutableSettings
> // This is very odd - I get errors on 64-bit builds if I specify a backing 
> variable for synthesis,
> // but I get errors on 32-bit builds if I *don't* specify a backing variable!?
> #if defined(__x86_64__)
>// On 32-bit builds I get an error here:
>// "Synthesized property 'myFlag' must either be named the same as a 
> compatible instance variable or must explicitly name an instance variable"
>@synthesize myFlag;
> #else
>// On 64-bit builds I get an error here:
>// "Property 'myFlag' attempting to use instance variable '_myFlag' 
> declared in super class 'ImmutableSettings'"
>@synthesize myFlag = _myFlag;
> #endif

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

Prioritize my own app's disk access

[Jonathan Taylor]

This is a long shot, but I thought I would ask in case an API exists to do what 
I want. One of the roles of my code is to record video to disk as it is 
received from a camera. A magnetic hard disk can normally keep up with this, 
but if the user is also doing other things on the computer (e.g. long file copy 
in the Finder) then we are unable to keep up, and accumulate an ever-increasing 
backlog of frames waiting to be saved. This eventually leads to running out of 
memory, thrashing, and an unresponsive computer. Dropping frames is not an 
option. In this case, the computer is a dedicated workstation running my code, 
so it *is* correct for me to consider my code to be the number 1 priority on 
the computer.

What I am wondering is whether there is some way I can communicate this 
requirement, to cause other apps such as the finder to get disk access at lower 
priority. Or alternatively, a way that I can demand high priority temporarily, 
at times when I identify that we have accumulated a save backlog?

I can see reasons why this is probably not possible, but I thought I’d ask if 
anyone has any suggestions that might be relevant here.
Thanks for any suggestions
Jonny.
___

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

Cocoa UI preservation - simple example

[Dragan Milić]

I’m trying to make usage of Cocoa UI preservation API, but it seems I got stuck 
at the very beginning and even after almost two hours of trying to figure out 
what I’m doing wrong, there’s no progress at all. I’m sensing I’m missing 
something obvious, but I don’t know what that would be.

Anyhow, I’ve created a very simple single window application, with (main) 
window, controlled by its accompanying  (main) window controller. The 
controller implementation is fairly simple:


@implementation MainWindowController

- (instancetype)init
{
self = [super initWithWindowNibName:@"MainWindow" owner:self];

if (self)
{
// Some code here.
}

return self;
}

- (void)windowDidLoad
{
[super windowDidLoad];
// Some code here.
}

@end


The application delegate is responsible for preservation and it’s implemented 
exactly like in many examples I’ve found online, as well as in Apple 
documentation:


@interface AppDelegate ()
@property (nonatomic, strong) NSWindowController *mainWindowController;
@end

@implementation AppDelegate

+ (void)restoreWindowWithIdentifier:(NSString *)anIdentifier
  state:(NSCoder *)aState
  completionHandler:(void (^)(NSWindow *, NSError 
*))aCompletionHandler
{
NSWindow *window;

if ([anIdentifier isEqualToString:@"main window"])
{
AppDelegate *delegate = [NSApp delegate];
window = [[delegate mainWindowController] window];
}

aCompletionHandler(window, nil);
}

- (NSWindowController *)mainWindowController
{
if (!_mainWindowController)
{
_mainWindowController = [[MainWindowController alloc] init];

[[_mainWindowController window] setRestorable:YES];
[[_mainWindowController window] setIdentifier:@"main window"];
[[_mainWindowController window] setRestorationClass:[self class]];
}

return _mainWindowController;
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[[self mainWindowController] showWindow:self];
}

- (void)applicationWillTerminate:(NSNotification *)aNotification
{

}

@end


The window itself (loaded from the nib file “MainWindow.xib” contains just one 
tab view, with four tabs.

When I start the application, the window appears just like it was designed in 
the nib file. Then I resize it and change its position on the screen, as well 
as change selected tab of the tab view. Quitting and relaunching the 
application shows the window just like it was designed in the nib files, not UI 
changes were preserved. Themethod never gets executed. Additionally, I 
don’t see any preserved data for the application being saved in the 
“~/Library/Saved Application State/” folder.

Is the code above enough to make this simple UI preservation work, or do I need 
to do something more (and what)?

Thanks in advance.
-- Dragan
___

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

Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Hi all,

I have a problem with property synthesis in my code, which I hope somebody can 
advise on. I find I have to write different property synthesis code for 32- or 
64-bit builds in order to avoid compiler errors.

A minimal demonstration of the problem can be found below - build as part of a 
fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I have 
to write different synthesis code for 32- or 64-bit builds - and this then 
makes me worry that I am doing something more fundamentally wrong. Can anyone 
comment (or explain)?

[I appreciate that this code may be old-fashioned in style - I am not even sure 
what is or is not the recommended style these days. It seems to work though - 
and, importantly, as far as I can tell the synthesized property myFlag on 
MutableSettings *does* map to the same backing variable, even on a 64-bit build 
where I am not able to specify the backing variable in the synthesis statement]

Cheers
Jonny


@interface ImmutableSettings : NSObject
{
BOOL_myFlag;
}
@property (readonly) BOOL myFlag;
@end

@interface MutableSettings : ImmutableSettings
@property (readwrite) BOOL myFlag;
@end

@implementation ImmutableSettings

-(id)init
{
if (!(self = [super init]))
return nil;
_myFlag = true;
return self;
}
@synthesize myFlag = _myFlag;

@end

@implementation MutableSettings
// This is very odd - I get errors on 64-bit builds if I specify a backing 
variable for synthesis,
// but I get errors on 32-bit builds if I *don't* specify a backing variable!?
#if defined(__x86_64__)
// On 32-bit builds I get an error here:
// "Synthesized property 'myFlag' must either be named the same as a 
compatible instance variable or must explicitly name an instance variable"
@synthesize myFlag;
#else
// On 64-bit builds I get an error here:
// "Property 'myFlag' attempting to use instance variable '_myFlag' 
declared in super class 'ImmutableSettings'"
@synthesize myFlag = _myFlag;
#endif

@end

___

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