My poor little Nabaztag rabbit is feeling the heavy weight of years. Modern WiFi means it is having trouble connecting to newer access points so I need another solution. With that in mind I decided to have a go at replacing the guts with something a little more modern and the ESP32 sounded perfect. I’ve gotten the firmware to compile and run on the the ESP32 but it needs more RAM for it to be fully functional. The ESP32 WROOM modules don’t have enough but the WROVER modules should be pleanty big enough. Hopefully once my WROVER module arrives I should be able to continue the development.
Today I spent quite a bit of time trying to get ASDF to find my local packages on my Windows development machine. It turns out that since ASDF 3.1.5 the place to put the config files has moved. Now the config file needs to be placed in
There’s a couple of hours of my life I’m never getting back 😉
After spending considerable time recently working on a fairly simple iOS app using Titanium Appcelerator I have come to the conclusion that I am never going to use it again if I can avoid it. The app size isn’t too much of a problem, but the fact that even this simple app crashes on startup on some devices makes me very nervous. I was hesitant to use the product at the start of the project, but the client wanted to be able to produce an Android app from the same code base, so I agreed. I suspect that I would have been able to build both apps from scratch using the native tools by now even though I’ve never made a production Android app before. Live and learn I guess.
I have managed to get the Objective-C version of pegged to spit out a parser using Swift rather than Objective-C 🙂
It’s getting late, so I really should get some sleep.
I finally figured out what was causing the compiler to crash. The following code will crash the Swift compiler unless the inout parameter to the block type is removed.
I’ve been thinking for a while that prototyping stuff with the DIP PIC32 parts should be easier, so I built something over the weekend to make that a reality.
Instead of this:
I can now start with this:
It is just the bare minimum to get a DIP PIC32 part up and running with USB support. I’m pretty happy with the results so far. Now all I need to do is get a USB boot loader that fits in under 3Kb and I can use the Chipkit32 stuff with these little guys 😉
I’ve been working on a piece of software for some time now that is almost ready for a public release. For part of it I needed to connect to various databases, some of which are only accessible via JDBC. My problem is that my app is written in Objective-C. For the first version of my app this wasn’t a problem as Apple was promoting their brand new Objective-C to Java bridge and everything worked really nicely. That was until a couple of years ago when Apple decided to deprecate the Java bridge. I rewrote that code to use JNI and all was good. Then Apple brought out the Mac App store but announced that it would not accept any apps that link directly to the JVM. This causes a problem for me as without the JDBC drivers the usefulness of my app is greatly reduced.
I looked into various ways of embedding the JVM into my app, but the problem with doing that was that it increased my app from less than 10Mb to around 100Mb. I wasn’t too happy about that to say the least, so I looked into providing a way to make my app optionally use the system JVM allowing the Java support to be turned off. This worked pretty well unless the machine didn’t have a JVM installed in which case my app would refuse to load due to linkage failures. So, I had the bright idea to use Apples “new” XPC feature. I reorganised my JNI code to allow it to be called from an XPC process and found that the security settings meant that the JVM could not access any of the JDBC driver files in my app bundle. I got around that by using a folder shared with a process group. This allows the JDBC drivers to be loaded, but then I found that for some reason the JNI code that had been running very nicely for a couple of years didn’t like running inside an XPC process and would fail randomly with strange errors. On top of that I found that the process of going from Java, through JNI to Objective-C, then from the XPC process over to the main app was very slow and was especially noticeable with some of my larger data sets.
In desperation I decided to abandon the JNI code altogether and see if I could communicate from the main app to the java code in some other way. In the end I created a Java JDBC connector that communicates with the main app via a pair of Unix pipes. I have found this to amazingly fast and extremely reliable. Instead of the data going through several transformations from Java, through to JNI and then to Objective-C and so on it now goes directly from the Java code in a special serialised format directly into the Objective-C code via the pipes. It works really well 🙂
Time for bed. I’ve successfully hacked an app I need for work to do something it is not supposed to do 🙂 A little reverse engineering, byte patching and single stepping through machine code and I now have it being quite naughty 🙂
I’ve been using a new disassembler a lot over the last couple of weeks called Hopper. I’m finding it to be well worth the money. So much so that I initially purchased it through the Apple App store, and then purchased it again directly from the developer so I could get access to the latest version more quickly.
It has many of the features of IDA Pro at a fraction of the cost!