Posted on

Windows

I’ve been running Macintosh machines for quite some time as my primary development environment. Recently I’ve been having to spend a lot of my time running Windows for my work and I’m finding it a lot less painful than I thought I would. Windows 10 has vastly improved over Windows 8 (although the bar was set very low on that on).

The Windows Subsystem for Linux makes doing a lot of things that were tricky under Windows in the past much easier. There are a few applications like Omnigraffle that I miss and I’ve yet to find an email client that feels right, but the thing I’m missing the most is my own QueryThing application that I’ll release for MacOS one of these days. There are many database query tools available for Windows but none of them works quite the way I want to work.

Now all I have to do is rewrite QueryThing to be a cross platform tool and I’ll be happy wherever I have to code 😉

Posted on

Apps

I’ve been making some apps recently.  One for the new Windows 8 modern UI and one for iOS using swift.  One was a joy to code, the other was not 😉

Swift is an interesting language and I look forward to writing more code in it.  C# is also a nice language, however writing code for “modern” Windows apps is much harder than it should be.  This is mainly because many of the more useful parts of the .Net API just are available any more 🙁  No System.Data was the real problem for me and meant that I had to roll my own database access layer on top of a SQLite database.  An app that should have taken a couple of days to whip up took a couple of weeks.  Every time I thought I was getting somewhere I would hit yet another assembly or class that wasn’t available, or worked slightly differently to the “normal” way things should work.

Both apps are working now, so I’m happy 🙂

Posted on

Drobo Pro/FS

After working through it a bit more it appears that the problem is actually in the Drobo Dashboard.  For some reason it is refusing to show the “Drobo ProFS”.  I loaded up the 1.8.4 version of the Drobo Dashboard and it sees the unit just fine but doesn’t allow much to be configured.  Maybe I will need to write my own client to get at all the functionality….

Posted on

Titanium Appcelerator == yuck

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.

Posted on

VMWare or Parallels?

Since Parallels released the new version of their Mac virtualization software recently and it reportedly works under OS X Yosemite (10.10), I decided to give it a go.  Converting my Linux VMs was a breeze, but converting my Windows 7 VM wasn’t as much fun.  The Windows VM converted perfectly, Windows itself on the other hand decided it needed to re-authorize.  Once I sorted all that mess out (another story for another time), I was able to get back to work.

So far I’m pleased with the performance of Parallels Desktop 10 for Mac.  It seems to be running better than when I was using VMWare Fusion 6.0.  I don’t have any solid numbers on this, but the fans in my Mac seem to not run as often under Parallels.  Booting my main Linux VM is almost instantaneous, and my Windows 7 VM seems to be running really well 🙂

Posted on

Swift Parser Generation

I’ve been fascinated by the Scala language since I first saw it. I’ve been fortunate enough to be able to use Scala in a couple of projects. One of the parts of the Scala standard library I really like is the parser combinator stuff.  I’ve been spending a bit of time recently playing with some ideas as to how something like it could be made for the new Swift language from Apple and I’ve made a first cut here.

It still needs a lot of work, but at the moment it is usable.  What I’m thinking is I will use it as the basis of a much nicer one that follows the Scala version more closely now that I have a better understanding of how Swift works.  I doubt I’ll be able to make it a nice as the Scala one, but I may be able to get close with any luck 🙂

 

Posted on

The first stage of my port of pegged to Swift is successful :)

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.

typealias MathFunction = (a: Double, b:Double, inout x:Int) -> Double
var counter = 0
class Executor {
    var fn: MathFunction
    init(fn: MathFunction) {
        self.fn = fn
    }
    func execute(a: Double, b: Double) -> Double {
        return fn(a: a, b: b, x: &counter)
    }
}
Posted on

Swift compiler is crashing for me :(

I’ve been spending a bit of time having a play with Apple’s Swift.  So far I find the language to be interesting.

It seems to be missing a few things.  Working with strings is a real pain 🙁  Hopefully this will be fixed in later versions of the language/compiler.

I’m also hitting many problems with the Xcode 6.0 beta crashing, but more annoyingly after getting a fairly large amount of Swift code ready it seems to be crashing the compiler 🙁

I’m trying to port the pegged parser generator to swift.  The first step is to update the existing tool to generate swift as output.  This I got working fairly quickly, then it was down to fixing the various syntax errors and learning how things are done in Swift.  Now there are no syntax errors, but it still won’t compile 🙁  Ah well.  Maybe I should just have a go at writing one from scratch 😉

Posted on

Apples Swift Langauge

I’ve been playing with the new language from Apple called Swift.  It looks like it might be interesting, especially if they open it up so it can be used on other platforms.

I’ve whipped up a little test app that includes a nicer way to work with NSTimer objects from Swift as the usual way is a bit of a pain.

 

Posted on

Objective-C to Java and back again via JNI and Unix pipes

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 🙂