I chose this article’s title to try and grab your attention. Well, the product is still the same and does the same. The only difference is one that is under the hood. And as such it is your job – should you choose to accept it – to marvel at the benefits that the new old parsing engine brings us.
The parsing of HTML necessary for my DTCoreText open source project is done entirely with the sophisticated use of NSScanner. But it has been long on my list to rewrite all of this parsing with a the industry standard libxml2 which comes preinstalled on all iOS devices. Not only is this potentially much faster in dealing with large chunks of HTML. It probably is also more intelligent in correcting structural errors of the HTML code you throw at it.
In part 1 of this series I showed you how to add the libxml2 library to your project and explained the basic concepts of using libxml2 for parsing any odd HTML snippet into a DOM. In this here part 2 we will create an Objective-C based wrapper around libml2 so that we can use it just like NSXMLParser, only for HTML.
In my previous article about Sub-Projects in Xcode I showed you how you can have an Xcode project as a dependency. The advantage of this is that you can update your library from within the same project and debug into the sub-project’s code.
One thing that was not immediately obvious was how you deal with the problem that Xcode cannot find your sub-project’s library headers. Hence this writeup.
Besides fixing several bugs reported by users this release focusses on implementing a new custom-built super-charged strings scanner.
- FIXED: missing strings file no longer aborts import
- FIXED: added – Button for deleting tokens
- FIXED: deletion of wrong row
- FIXED: over-escaping of \ on writing strings files
- FIXED: wrong token name updated on enter key
- FIXED: search filter not reset on adding a new token
- FIXED: Previous/Next buttons in wizard cease to function
- NEW: replaced genstrings with high-speed custom implementation (>20x speed improvement)
- NEW: support custom localization macro prefix
This new version does no longer support 32-bit because the new strings scanner was implemented using ARC. We hope that this does not inconvenience any of our existing uses. But then again, serious developers are on a 64 bit machine anyway since Snow Leopard…
The new version has been submitted to Apple today.
Over the past week I’ve been working on DTLocalizableStringScanner or in short genstrings2. The original genstrings dates back to the NeXtStep days. You know how it is “never change a winning team” BUT “the good is the enemy of the great”, because if something kind of works, why change it?
Besides of the other problems I’ve alluded to in my previous article genstrings is very slow. Internally it is written in Objective-C as you can tell from the occasional stack trace when it crashes again. But it was created in a time when Macs did only have single CPU cores and when we did not have the awesome LLVM with ARC, GCD and multi-threading.
LEGO’s Life of George game brings together 5 worlds like nothing else before:
- 8-Bit Design
- LEGO bricks
- manual interaction, a “touch interface” if you will
- computer vision for gamification
Let’s have a quick look at this fun pastime that is all the rage.
Actually I am on vacation, but I couldn’t help myself using the breather to work on a little hobby project. This I shall reveal to you today!
If you localize your apps (iOS or Mac regardless) you are probably used to working with genstrings. Probably painfully working, which is why we built the Mac app Linguan which remote-controls genstrings and merges the results with your previously existing tokens.
But genstrings has several big problems.
Imagine me getting a mani-pedi during the Christmas holidays. No, really! We have a lady come to our house regularly and doing all willing feet.
Somehow our casual conversion came to the iPhone. Now imagine this healthcare professional telling me:
“For me the iPhone is no option because it does not work with the gloves we use”.
One does not have to say THAT to me twice. This myth was begging to be busted.
Sometimes you want to tell somebody how you fixed a problem in their code, but for some reason the code is not on github so you cannot send them a pull request. If you felt really smart then you might put the changes you made into an e-mail, like “in file1.m:102 you change it to x, in file2.m:54 you make change y”. Thought this doesn’t really help the developer you are trying to help. Even when following your change instructions to the letter it is a tedious and error-prone method of applying your changes. Thanks to M. Douglas McIlroy, Adjunct Professor at Dartmouth Colleague – one of the early Unix pioneers – there is a better way. He invented the form of diff that we are using today to get the Difference between two versions of a file. And Larry Wall who invented the patch command which can take a diff file and effectively apply it to files. Read more