Date   

Re: Repeating timer firing way to fast

Quincey Morris
 

On May 22, 2018, at 04:15 , Jonathan Taylor <jonathan.taylor@...> wrote:

and therefore the timer callback blocks

It seems to me that this could be regarded as a bug in your design. The consequence of blocking, at a higher conceptual level, is that it destroys the concept of timing which is essential to your task.

One alternative is to use the timer callback *only* to decide whether it has been 4 or more seconds since the last time the secondary process action finished (or, more than 4 seconds since it last started, *and* that it has finished), and, if so, to trigger the action asynchronously. The precise details will depend on how you want the system to behave in the face of delays.

Or, you could switch to a recurring NSTimer. That has an API contract about what happens when scheduled firings are missed:

"After a repeating timer fires, it schedules the next firing for the nearest future date that is an integer multiple of the timer interval after the last scheduled fire date, within the specified tolerance. If the time taken to call out to perform a selector or invocation is longer than the specified interval, the timer schedules only the next firing; that is, the timer doesn't attempt to compensate for any missed firings that would have occurred while calling the specified selector or invocation.”


Re: Repeating timer firing way to fast

Jon Gotow
 

Not knowing how your code is structured, this may be a dumb question, but just to check:

Are you certain that you're not creating multiple timers somehow? I've mistakenly done this when creating timers in response to an event and the event occurs in extra, unexpected circumstances.

- Jon

On May 22, 2018, at 5:15 AM, Jonathan Taylor <jonathan.taylor@...> wrote:

Hi all,


I’ve been trying to figure out what happened on an overnight run of the code that drives our scientific experiment, and I’m seeing logs that imply that a timer has been firing much more rapidly than intended. I’m hoping somebody can help me figure out why, and what I should be changing.

The calls that set up the timer can be condensed down to:

timerSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, DISPATCH_TIMER_STRICT, dispatch_get_main_queue());
dispatch_source_set_event_handler(timerSource, myHandler);
dispatch_source_set_timer(timerSource, dispatch_time(DISPATCH_TIME_NOW, repeatIntervalNs), repeatIntervalNs, flexibilityNs);

where repeatIntervalNs is 4*NSEC_PER_SEC and flexibilityNs is 2*NSEC_PER_SEC. The CPU is under fairly high load from multithreaded code all night, but normally the timer fires on average every 4 seconds. Note that I have specified DISPATCH_TIMER_STRICT in a perhaps-misguided attempt to protect against the fact that occasionally, under unusually high load I presume, the timer was not firing for 30 seconds or more at a time. However, the problem that I am seeing in practice is that (in this overnight run, at least) the timer was firing at a rate of up to 200 times per second! All I am trying to achieve with this periodic timer is to check in with the secondary process and provide it with a status update.

The perhaps-unusual thing here is that the timer callback makes a function call via an NSConnection to a secondary process. Sometimes that secondary process is busy (for seconds at a time) and therefore the timer callback blocks. My theory is that what is happening is that the OS is building up a “backlog” of timer callbacks that it wants to make - many more, indeed, than than it would make if it really was firing every ~4secs.

None of this is a huge problem (except that it’s led to an enormous log file!), but it makes me worry that I am going about all of this the wrong way. What do people think? Is this a terrible way to achieve what I want to achieve, for some reason? Does it seem plausible that the number of timer callbacks would be disproportionately high like this? Any suggestions most welcome!

Cheers
Jonny



Repeating timer firing way to fast

Jonathan Taylor
 

Hi all,


I’ve been trying to figure out what happened on an overnight run of the code that drives our scientific experiment, and I’m seeing logs that imply that a timer has been firing much more rapidly than intended. I’m hoping somebody can help me figure out why, and what I should be changing.

The calls that set up the timer can be condensed down to:

timerSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, DISPATCH_TIMER_STRICTdispatch_get_main_queue());
dispatch_source_set_event_handler(timerSource, myHandler);
dispatch_source_set_timer(timerSource, dispatch_time(DISPATCH_TIME_NOWrepeatIntervalNs), repeatIntervalNs, flexibilityNs);

where repeatIntervalNs is 4*NSEC_PER_SEC and flexibilityNs is 2*NSEC_PER_SEC. The CPU is under fairly high load from multithreaded code all night, but normally the timer fires on average every 4 seconds. Note that I have specified DISPATCH_TIMER_STRICT in a perhaps-misguided attempt to protect against the fact that occasionally, under unusually high load I presume, the timer was not firing for 30 seconds or more at a time. However, the problem that I am seeing in practice is that (in this overnight run, at least) the timer was firing at a rate of up to 200 times per second! All I am trying to achieve with this periodic timer is to check in with the secondary process and provide it with a status update.

The perhaps-unusual thing here is that the timer callback makes a function call via an NSConnection to a secondary process. Sometimes that secondary process is busy (for seconds at a time) and therefore the timer callback blocks. My theory is that what is happening is that the OS is building up a “backlog” of timer callbacks that it wants to make - many more, indeed, than than it would make if it really was firing every ~4secs. 

None of this is a huge problem (except that it’s led to an enormous log file!), but it makes me worry that I am going about all of this the wrong way. What do people think? Is this a terrible way to achieve what I want to achieve, for some reason? Does it seem plausible that the number of timer callbacks would be disproportionately high like this? Any suggestions most welcome!

Cheers
Jonny


Re: The Correct Place to Migrate my NSDocument

Bill Pitcher
 

I’m going to mark this as working now:

Set my DocumentController subclass as the main shared NSDocumentController
func applicationWillFinishLaunching(_ notification: Notification) {
_ = DocumentController.init()
}

class DocumentController: NSDocumentController {

override func makeDocument( withContentsOf contentsURL: URL,
ofType typeName: String) throws -> NSDocument {

if typeName == “CurrentVersion” {
return try super.makeDocument( withContentsOf: contentsURL, ofType: typeName)
}
let holdDocument = try self.makeUntitledDocument(ofType: "CurrentVersion") as! Document
try holdDocument.updateFromURL(fromURL: contentsURL)
return holdDocument
}
}

In the Document write the updateFromURL(fromURL: URL) that does the conversion and flag the document as self.hasBeenUpgraded = true
self.updateChangeCount(.changeDone) (this ensures the changes are saved if the user quits without saving)

when the document window has been displayed check hasBeenUpgraded and NSAlert the user that the Untiled Document has been upgraded.

NOTE: Document Type set to “Viewer" in Info.plist does NOT set NSDocument isInViewingMode, it does NOT open the document in an Untitled document. overriding isInViewingMode to true does disable Saving and messes with other options in the File menu, I gave up to this route.

Comments still very welcome!

cheers
Bill Pitcher
bill@...

On 13/05/2018, at 11:46 AM, Bill Pitcher <bill@...> wrote:

This works but it’s not right and throws a yucky message

let holdDoc = try NSDocumentController.shared.openUntitledDocumentAndDisplay(false) as! Document
// set the updated data
holdDoc.documentQuestions = self.documentQuestions
// show the new document
holdDoc.makeWindowControllers()
holdDoc.showWindows()
holdDoc.updateChangeCount(.changeDone)
// cancel
throw NSError(domain: "Application", code: 1002, userInfo: [NSLocalizedDescriptionKey : "File Updated", NSLocalizedRecoverySuggestionErrorKey : "The new Untitled document has the information for " + (self.fileURL?.path)! ] )

From Apple’s - Additional Document Type Considerations
"If you want to automatically convert them to be saved as your new type, you can override the readFrom... methods in your NSDocument subclass to call super and then reset the filename and type afterwards. You should use setFileType: and setFileURL: to set an appropriate type and name for the new document. When setting the filename, make sure to strip the filename extension of the old type from the original filename, if it is there, and add the extension for the new type.”

But from NSDocument
"You cannot use this property to change the document’s format after it has already been opened or saved. This property records only the initial document format used when first opening or saving the file."

Call super what??? "Expected '.' or '[' after ‘super'"

Bill Pitcher
bill@...



On 12/05/2018, at 4:32 PM, Bill Pitcher <bill@...> wrote:

I have an App that needs to be upgraded (thanks App Store) and I want the new App to Open and migrate it’s old documents to the new versions document. With the new File Type and Extension.

All good, I can open both types in "override func read(from data: Data, ofType typeName: String) throws”.
And the internal data is all good.

But when it saves (Including the automagical save when quitting) the new migrated data gets put into the old file, keeping the old DocumentType and Extension. (If I change the file extension manually in Finder it then opens fine)

I get the feeling that either I’m no doing this in the right place or I’m missing something obvious.

Any advice or examples greatly appreciated.

cheers
Bill Pitcher
bill@...






Re: The Correct Place to Migrate my NSDocument

Bill Pitcher
 

This works but it’s not right and throws a yucky message

let holdDoc = try NSDocumentController.shared.openUntitledDocumentAndDisplay(false) as! Document
// set the updated data
holdDoc.documentQuestions = self.documentQuestions
// show the new document
holdDoc.makeWindowControllers()
holdDoc.showWindows()
holdDoc.updateChangeCount(.changeDone)
// cancel 
throw NSError(domain: "Application", code: 1002, userInfo: [NSLocalizedDescriptionKey : "File Updated", NSLocalizedRecoverySuggestionErrorKey : "The new Untitled document has the information for " + (self.fileURL?.path)! ] )

From Apple’s - Additional Document Type Considerations
"If you want to automatically convert them to be saved as your new type, you can override the readFrom... methods in your NSDocument subclass to call super and then reset the filename and type afterwards. You should use setFileType: and setFileURL: to set an appropriate type and name for the new document. When setting the filename, make sure to strip the filename extension of the old type from the original filename, if it is there, and add the extension for the new type.”

But from NSDocument
"You cannot use this property to change the document’s format after it has already been opened or saved. This property records only the initial document format used when first opening or saving the file."

Call super what??? "Expected '.' or '[' after ‘super'"

Bill Pitcher
bill@...



On 12/05/2018, at 4:32 PM, Bill Pitcher <bill@...> wrote:

I have an App that needs to be upgraded (thanks App Store) and I want the new App to Open and migrate it’s old documents to the new versions document. With the new File Type and Extension.

All good, I can open both types in "override func read(from data: Data, ofType typeName: String) throws”.
And the internal data is all good.

But when it saves (Including the automagical save when quitting) the new migrated data gets put into the old file, keeping the old DocumentType and Extension. (If I change the file extension manually in Finder it then opens fine)

I get the feeling that either I’m no doing this in the right place or I’m missing something obvious. 

Any advice or examples greatly appreciated.

cheers
Bill Pitcher
bill@...








Audio stops playing when screens goes dark after screen lock.

Antonio - SintraWorks
 

Hi,

I have a metronome app that is able to play audio in the background just fine. It even continues playing when the screens is locked. That is, until the screen goes dark after a few seconds. Playback stops, but it returns if I press any button that lights up the screen again.

I have Background Modes ON (Audio, Airplay and PiP checked), and set up my audio session with the following code:

    AVAudioSessionCategoryOptions option = flag ? AVAudioSessionCategoryOptionMixWithOthers : 0;
    if (![session setCategory:AVAudioSessionCategoryPlayback
                  withOptions:option
                        error:&setCategoryError]) {  }

A.f.a.i.k. this should be sufficient to ensure playback continues when the screen goes to sleep. I’ve had earlier incarnations of this app behave successfully with this feature since around 2010. I haven’t been able to figure out what caused this since its latest major release.

Any ideas what I might be overlooking or doing wrong?

- António


The Correct Place to Migrate my NSDocument

Bill Pitcher
 

I have an App that needs to be upgraded (thanks App Store) and I want the new App to Open and migrate it’s old documents to the new versions document. With the new File Type and Extension.

All good, I can open both types in "override func read(from data: Data, ofType typeName: String) throws”.
And the internal data is all good.

But when it saves (Including the automagical save when quitting) the new migrated data gets put into the old file, keeping the old DocumentType and Extension. (If I change the file extension manually in Finder it then opens fine)

I get the feeling that either I’m no doing this in the right place or I’m missing something obvious.

Any advice or examples greatly appreciated.

cheers
Bill Pitcher
bill@...


Re: update Localization

Chris Hanson
 

On May 11, 2018, at 7:16 AM, Michael Babin <mbabin@...> wrote:

On May 8, 2018, at 5:08 PM, Chris Hanson <cmhanson@...> wrote:

PS - There were substantial improvements to Xcode’s translation infrastructure in Xcode 9.3, so for anyone else out there who has used it before, please try it out with Xcode 9.3.

Any pointers to information on what changed? I looked through the Xcode Release Notes (https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW1), but did not see any mention of these changes or their effect(s). Only a mention of the added LOCALIZED_STRING_MACRO_NAMES build setting.

I don’t have any detailed list of what changed in Xcode 9.3 that I can share, sorry.

Speaking generally, the only changes anyone should notice should be positive; much of the underlying infrastructure related to localization in Xcode was substantially updated, but that should be invisible to developers except insofar as there should be many fewer issues encountered in common workflows.

  -- Chris
  -- who works on Xcode, including its localization support


Re: update Localization

Michael Babin
 

On May 8, 2018, at 5:08 PM, Chris Hanson <cmhanson@...> wrote:

PS - There were substantial improvements to Xcode’s translation infrastructure in Xcode 9.3, so for anyone else out there who has used it before, please try it out with Xcode 9.3.

Any pointers to information on what changed? I looked through the Xcode Release Notes (https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW1), but did not see any mention of these changes or their effect(s). Only a mention of the added LOCALIZED_STRING_MACRO_NAMES build setting.


Re: Opaque text in NSTextField

Gerriet M. Denkmann
 

To answer my own question:

On 11 May 2018, at 11:44, Gerriet M. Denkmann <g@...> wrote:

I have an NSTextField (macOS 13.4, Xcode Version 9.3 (9E145)) which says:

textColour Generic Gray colorspace 1 1
backGroundColour NSCalibratedWhiteColorSpace 0 0.4

This, I guess, means all white and all opaque text.
And partly translucent black background.

The background is partly translucent as expected.
But the text comes out as semi-translucent grey.

How can I get really white opaque text?
textField.stringValue = someString;

When I look at the attributedStringValue I see Generic Gray colorspace 1 0.5

So I do:
NSMutableAttributedString *mus = [ textField.attributedStringValue mutableCopy ];
[ mus addAttribute: NSForegroundColorAttributeName value: textField.textColor range: NSMakeRange(0, someString.length) ];
textField.attributedStringValue = mus;

I have no idea who changes the alpha of textColor from 1 to 0.5 and why.

Gerriet.


Opaque text in NSTextField

Gerriet M. Denkmann
 

I have an NSTextField (macOS 13.4, Xcode Version 9.3 (9E145)) which says:

textColour Generic Gray colorspace 1 1
backGroundColour NSCalibratedWhiteColorSpace 0 0.4

This, I guess, means all white and all opaque text.
And partly translucent black background.

The background is partly translucent as expected.
But the text comes out as semi-translucent grey.

How can I get really white opaque text?

Gerriet.


Re: update Localization

Chris Hanson
 

The main idea for Cocoa localization is that your source artifacts are the “the truth” for your development region (by default English): You use the real strings in NSLocalizedString() macros and in your xib and storyboard files

Then, when you’re ready to localize your application, you export for localization from Xcode to produce an XLIFF file that contains translatable strings. At the point of export, you can also choose to include existing translations in that XLIFF file, so your translators know what work they don’t have to do.

When your translator returns an updated XLIFF file for a given localization, you then import that to Xcode and it puts the appropriate content in the resources for just that language, replacing whatever was there previously. Because of the ability to include existing translations in the exported XLIFF, this shouldn’t be a big deal; strings that were present before should still be present, and strings that are no longer present should be omitted.

  -- Chris

PS - There were substantial improvements to Xcode’s translation infrastructure in Xcode 9.3, so for anyone else out there who has used it before, please try it out with Xcode 9.3.


On May 7, 2018, at 11:18 PM, Gerriet M. Denkmann <g@...> wrote:

I have an app (macOS 13.4, Xcode Version 9.3 (9E145)) which was localised (Xcode did some magic for me).

Now I made some changes.
Is there a way to update the Localizable.string, MainMenu.strings, etc. without destroying the stuff I already have translated?

I.e. things no longer existing should be removed (or commented out) and new stuff should be added.

Gerriet.






update Localization

Gerriet M. Denkmann
 

I have an app (macOS 13.4, Xcode Version 9.3 (9E145)) which was localised (Xcode did some magic for me).

Now I made some changes.
Is there a way to update the Localizable.string, MainMenu.strings, etc. without destroying the stuff I already have translated?

I.e. things no longer existing should be removed (or commented out) and new stuff should be added.

Gerriet.


Re: struct return of nil

Sean McBride
 

On Fri, 27 Apr 2018 11:57:15 +0700, Gerriet M. Denkmann said:

Is this guaranteed to work in the future?
See also:
<http://sealiesoftware.com/blog/archive/2012/2/29/objc_explain_return_value_of_message_to_nil.html>

Sean


Re: struct return of nil

Quincey Morris
 

On Apr 26, 2018, at 21:57 , Gerriet M. Denkmann <g@...> wrote:

Is this guaranteed to work in the future?

Yes:


“Working with nil

"Note: If you expect a return value from a message sent to nil, the return value will be nil for object return types, 0 for numeric types, and NO for BOOL types. Returned structures have all members initialized to zero."

This wasn’t true in the past, but at some point the clang compiler was changed to ensure a predictable result with a struct return type. (It isn’t true of the GCC compiler, AFAIK.)



struct return of nil

Gerriet M. Denkmann
 

macOS 13.4; Xcode Version 9.3 (9E145).

This is (I believe) documented to work:

NSString *answer = …
if ( answer.length == 0 )
{
// works for answer = nil or answer = “” (empty string)
answer = @“No answer given”;
};

But what about this:

NSImage *image = …
if ( NSEqualSizes( image.size, NSZeroSize ) )
{
// works for image = nil or non-nil image with zero size
image = … some default image instead …
};

Is this guaranteed to work in the future?

Gerriet.


[OT] Experienced Freelance Mac and iOS Developer available

Dave
 

Hello All,

I’m looking for remote work on Mac and iOS.

I have over 25 years experience on the Mac and iOS since the first iPhone.

I’ve recently finishing a long contract where I gained a *lot* of experience in Accessibility on the Mac.

I’m looking for remote work and will be willing to work for less than the market rate in return for this flexibility.

If you’d like to see my CV/Resume please drop me a line privately.

All the Best
Dave


Re: NSData base64Encoding vs. base64EncodedStringWithOptions

Alex Zavatone
 

On Apr 13, 2018, at 12:05 PM, Ben Kennedy <ben-groups@...> wrote:

On Apr 13, 2018, at 9:39 AM, Alex Zavatone <zav@...> wrote:

- What did the deprecated base64Encoding do with the line endings? How long were lines and what happened at a line ending?
I haven't tested this, but I would imagine that it produced no line endings at all (i.e., a string containing only base64 alphabet).

The typedef for NSDataBase64EncodingOptions, 0 is given the text, NSDataBase64Encoding64CharacterLineLength, indicating that a line is 64 characters.
No it doesn't:

NSDataBase64Encoding64CharacterLineLength = 1UL << 0,
The enum defines a bit mask. The above declaration contains a shift. It equals 1.

-ben
DOH. I think it’s time for me to update my glasses prescription.

Thank you.


Re: NSData base64Encoding vs. base64EncodedStringWithOptions

Ben Kennedy
 

On Apr 13, 2018, at 9:39 AM, Alex Zavatone <zav@...> wrote:

- What did the deprecated base64Encoding do with the line endings? How long were lines and what happened at a line ending?
I haven't tested this, but I would imagine that it produced no line endings at all (i.e., a string containing only base64 alphabet).

The typedef for NSDataBase64EncodingOptions, 0 is given the text, NSDataBase64Encoding64CharacterLineLength, indicating that a line is 64 characters.
No it doesn't:

NSDataBase64Encoding64CharacterLineLength = 1UL << 0,
The enum defines a bit mask. The above declaration contains a shift. It equals 1.

-ben


Re: NSData base64Encoding vs. base64EncodedStringWithOptions

Alex Zavatone
 

From the docs:

Discussion

By default, no line endings are inserted. 

If you specify one of the line length options (NSDataBase64Encoding64CharacterLineLength or NSDataBase64Encoding76CharacterLineLength) but don’t specify the kind of line ending to insert, the default line ending is Carriage Return + Line Feed.

Does this mean that we need to pass in nil as an option to obtain the default case?

Thank you.

Alex Zavatone

On Apr 13, 2018, at 11:39 AM, Alex Zavatone <zav@...> wrote:

Xcode 9.2, iOS 11.2, Objective-C


Looking at the header for NSData, and base64EncodedStringWithOptions: NSDataBase64EncodingOptions,

the options are these starting on line 50 of NSData.h:

typedef NS_OPTIONS(NSUInteger, NSDataBase64EncodingOptions) {
    // Use zero or one of the following to control the maximum line length after which a line ending is inserted. No line endings are inserted by default.
    NSDataBase64Encoding64CharacterLineLength = 1UL << 0,
    NSDataBase64Encoding76CharacterLineLength = 1UL << 1,

    // Use zero or more of the following to specify which kind of line ending is inserted. The default line ending is CR LF.
    NSDataBase64EncodingEndLineWithCarriageReturn = 1UL << 4,
    NSDataBase64EncodingEndLineWithLineFeed = 1UL << 5,

}

Questions

- What did the deprecated base64Encoding do with the line endings?  How long were lines and what happened at a line ending?

The typedef for NSDataBase64EncodingOptions, 0 is given the text, NSDataBase64Encoding64CharacterLineLength, indicating that a line is 64 characters.  

The documentation for this states that “NSDataBase64Encoding64CharacterLineLength Set the maximum line length to 64 characters, after which a line ending is inserted.”.

The comment on line 52 for NSDataBase64Encoding64CharacterLineLength states something different.     // Use zero or one of the following to control the maximum line length after which a line ending is inserted. No line endings are inserted by default. 

It states that a line ending is inserted and no line endings are inserted by default.

- Which is the default value, 0?  nil?   I’d expect that it is 0, but the documentation for 0 states that a line ending is inserted and that no line endings are inserted by default.  If 0 is the default, how is this possible?

- What happens for NSDataBase64Encoding76CharacterLineLength?

Can someone please clarify what Apple’s confusing documentation doesn’t?

Thank you,

Alex Zavatone

881 - 900 of 1460