How about PromiseKit

[bamx23]

I've found interesting library here: http://promisekit.org/ It simple to implement something like that AFNetworking+PromiseKit.m. And here a guide how to setup subspec http://promisekit.org/pods/ It's simple and may be useful for someone.

[kevincon]

Adding a subspec for opt-in PromiseKit support sounds good to me. Feel free to work on it if you like. Promises are fun. :)

[ws233]

Could you give a few examples, how it can be applicable in the project?

[ws233]

Ah. I think I got what you were talking about! You didn't say about applications of this library, did you? Instead, you want the framework could create promises and send all the related events, do you? Seems intresting, if that's an idea.

[bamx23]

Yep, that's I mean. Just additional optional feature for our library.

[ws233]

Just curious. Could this optional feature be optionally compiled? Is it a good idea to enclose all the code related to this feature with #if #endif? I just worry that all these runtime stuffs will dramatically decrease framework performance, won't it? Should we allow user to turn on/off this feature specifing compile time parameter, like #define USE_PROMISES for example?

[kevincon]

I was under the impression that making the promise stuff a CocoaPod subspec would mean that it would only be compiled in the framework if the user installs both the "base" spec and the "promise" subspec. We could exclude the promise-related source files from the "base" spec and only include it in the "promise" subspec (as they show in the example in the link above): http://promisekit.org/pods/

[ws233]

That's an imazing thing! But I think it only works with pods. For those, who use dependent projects in their workspaces that doesn't make a trick.

[yoiang]

Coincidentally I've made a simple PromiseKit extension for Tesseract OCR iOS!

When I have time to I'd be happy to add it as a subspec, in the meantime I've put it up as a gist. It's in Swift, apologies of that complicates things, let me know if it should be rewritten: Gist

Unfortunately I'm unclear how to get extended recognize() failure information, is there a mechanism right now? If not that would be greatly appreciated!

Cocoapod Subspecs work by allowing you to define a set of additional source files, Cocoapod dependancies, preprocessor definitions... (see here for all info) so it's quite easy to have a separate set of source for the PromiseKit extension that only gets added, along with PromiseKit itself, when someone specifies to include the subspec.

Personally, I've had mixed experience with Cocoapod subspecs, unless they're very simple they complicate the library as a whole. More recently I've been building the extension as a separate Cocoapod to force a level of separation.

[ws233]

@yoiang, first of all, let me thank you a lot for your participation!

Second,

Unfortunately I'm unclear how to get extended recognize() failure information, is there a mechanism right now? If not that would be greatly appreciated!

By default the upstream tesseract prints the error logs to the stderr. So as I know it's possible to open an input stream from stderr and read logs from there. It's gonna be a good feature to have it in our wrapper, since so far there is no function to return the error explanation from tesseract. But we should think twice, how it should be implemented, since the error mechanism is quiet different from that usual in iOS.

Third, If you are not sutisfied with stderr there is a way to print error logs to the file: https://code.google.com/p/tesseract-ocr/wiki/FAQ#How_can_I_make_the_error_messages_go_to_tesseract.log_instead_of But instead of the command line you should use an initializator with configFileNames parameter.

@kevincon, what do you think, do we need to add an error recognition and generation functionality in our wrapper? I mean, so far the developper cannot understand the reason of the wrapper function fail, so they cannot interact with this fail at all. Perhaps, it's a great idea and we should add a ticket for this?

[kevincon]

I'm not sure I understand why the promise kit subspec needs extended recognize() failure information, but anyway I don't think we need to add any mechanism to get error messages because we can tell if recognize() failed (as in the gist when you check the return value of that function), and the developer can use the messages that Tesseract prints to stderr (which I believe show up in Xcode's logs, right?) to diagnose why the error occurred.

Moreover I don't think trying to parse the logs from stderr is a good idea because if the user is using other libraries in their project, then stderr may contain other error messages from the other libraries. I don't think we would have a good way to selectively look for Tesseract-specific stderr log messages, would we?

[ws233]

Yup, I forgot that an app may have other 3rd party libraries, which could print to stderr. In such case we definetely cannot parse such logs. So just forget about my idea. That's not a universal case.

[yoiang]

Hey y'all, thanks for the responses!

Regarding error response from the library: PromiseKit or not, what I was describing was when building a product that includes the library a programatic interface for the rest of an application to respond to different error situations in the library. I don't have enough insight yet into fine tuning Tesseract to know whether all errors in operating Tesseract should be shown to the user the same way but my gut says they'd need a different experience depending on the situation.

For example, if your app allowed the user to download language data after installation and for some reason one of those language datas were corrupted the app should be able to respond to Tesseract saying so, and perhaps redownload the language data.

This probably should be made into a separate issue, the thread is going on a tangent ;)