Saturday, 17 March 2018

Regular Expressions in Swift 4

I have recently been looking at converting some of my Xojo code to Swift, more of an exercise to see how easy it is, rather than anything productive.
However, I found that using regular expressions in Swift was not as straight forward as in some languages, like Xojo, Javascript and C#.

The following example will show what you need to do to find a pattern in a string and print each match to the console:

if let regPattern = try? NSRegularExpression(pattern: pattern, options: []) {
    let matches = regPattern.matches(in: text, options: [],
                                     range: NSRange(location:0, length: text.count))
    for match in matches {
        for n in 0..<match.numberOfRanges {
            let range = match.range(at: n)
            let start = self.index(self.startIndex,
                                   offsetBy: range.lowerBound)
            let end = self.index(self.startIndex,
                                 offsetBy: range.upperBound)
            let substring = String(self[start..<end])
            print(substring)
        }
    }

}

As you can see, this is a lot to do for a simple regex search.

To simplify this, I have created some extension methods for the String class, that allow you to accomplish this with far less effort. These methods overload each other, to allow reducing complexity, whilst still allowing the full range of options, should it be required:

extension String {

    func regex(_ pattern:String, options: NSRegularExpression.Options,
               matchingOptions: NSRegularExpression.MatchingOptions,
               range: NSRange) -> [[String]] {
        var result = [[String]]()
        if let regPattern = try? NSRegularExpression(pattern: pattern,
                                                     options: options) {
            let matches = regPattern.matches(in: self, options:
                matchingOptions, range: range)
            for match in matches {
                var matchArray = [String]()
                for n in 0..<match.numberOfRanges {
                    let range = match.range(at: n)
                    let start = self.index(self.startIndex,
                                           offsetBy: range.lowerBound)
                    let end = self.index(self.startIndex,
                                          offsetBy: range.upperBound)
                    let substring = String(self[start..<end])
                    matchArray.append(substring)
                }
                result.append(matchArray)
            }
        }
        return result
    }

    func regex(_ pattern:String, options: NSRegularExpression.Options,
               matchingOptions: NSRegularExpression.MatchingOptions)
        -> [[String]] {
        return self.regex(pattern, options: options,
                          matchingOptions: matchingOptions,
                          range:NSRange(location:0, length:self.count))
    }

    func regex(_ pattern:String, options: NSRegularExpression.Options)
        -> [[String]] {
        return self.regex(pattern, options: options, matchingOptions: [])
    }

    func regex(_ pattern:String) -> [[String]] {
        return self.regex(pattern, options: [])
    }

}

These methods return an array of match arrays. In each of the match arrays, the first element is the entire match, whilst each of the subsequent elements match the capture blocks from the regular expression.
Working from the top to bottom, the methods reduce the complexity exposed to the user, allowing them to only use the options required.
If we start with the first method, you can see that it takes the full range of options for a regular expression search. This can be called by:

let matches = text.regex(pattern, options: [],
                         matchingOptions: [],
                         range: NSRange(location:0, length:text.count))

The next method assumes the range is the full size of the string:

let matches = text.regex(pattern, options: [],
                         matchingOptions: [])

The next method assumes that the matching options are the default:

let matches = text.regex(pattern, options: [])

The final method assumes the regular expressions requires the default options:

let matches = text.regex(pattern)

As you can see, we can reduce the code down to a very manageable call.

To see the results of the match, we can simply iterate over the returned array:

for match in matches {
    for item in match {
        print(item)
    }
}

Now we no longer need to mess around with the ranges and manually extract the strings from the text.

Wednesday, 12 July 2017

To var or not to var

Bit of a change for this post.

When C# 3.0 was released by Microsoft, the var keyword was introduced.
This new keyword allowed the implicit typing of variables, according to their context in the source code. Unfortunately, this new feature has caused some confusion and some problems with readability of code. Therefore, this brief document aims to outline what var is, how it works and when (and when not) to use it.

What is var?

var allows us, as programmers, to reduce the amount of typing when declaring variables. For value types, this doesn’t really make much difference, but for complex reference types, this can reduce the amount of typing a great deal:

e.g.
dictionary<string,dictionary<string,List<int>>> complexItem = new dictionary<string,dictionary<string,List<int>>>();
can be replaced with:
var complexItem = new dictionary<string,dictionary<string,List<int>>>();

Not only does this reduce typing, and slightly enhance readability, it also reduces the possibility of errors in the declaration as we are only having to type out the structure of the type once.
var does this inference at compile time, not runtime. This means that when the compiler finds the above line, it translates it to:

dictionary<string,dictionary<string,List<int>>> complexItem = new dictionary<string,dictionary<string,List<int>>>();

This means that the variable created is not the same as a dynamic variable, and it can only be used in this way if the type is obvious (to the compiler) at compile time.

When not to use var?

var cannot be used in a declaration of a variable if the variable is not initialised:
var unintialisedVariable; // Compile time error
var should also not be used if the type is not obvious when reading the source code:
var newVariable = functionReturningAValue(); // What does this function return?
In this situation, the compiler will be able to determine the type, but it is not immediately obvious to anyone reading the source code. Therefore, the reader would have to find the function declaration to determine the type of the variable.



Saturday, 12 March 2016

Komodo IDE and PHPUnit

For about 2 years now, I have been using Komodo IDE from ActiveState for web development, and on the whole I have been very satisfied with it. There are a couple of issues that have arisen, but normally there is some way to get around them with a minor change of workflow.
However, one issue has consistently bothered me, so I thought it was time I investigated a way to fix the issue: PHPUnit testing.
Out of the box, Komodo will not do unit testing for PHP, so the first thing I had to do was download PHPUnit. Do do this, I needed to install wget using home-brew (for more information about this, go to http://brew.sh).
So, once wget is installed, I followed the instructions on the PHPUnit website to install PHPUnit globally so that it would be accessible no matter where it was called from:

wget https://phar.phpunit.de/phpunit.phar
chmod +x phpunit.phar
sudo mv phpunit.phar /usr/local/bin/phpunit

Thinking that would be it, I created a small test case:

<?php 
class TestClass extends PHPUnit_Framework_TestCase { 
public function testMethod() {  
      $this->assertTrue(TRUE);  
} 
} 
?>

With a simple test plan:



Executing the test, however, resulted in no output. Obviously something was wrong.
After trawling through the Komodo forums and StackOverflow, and little bit of Googling... I came across an unofficial fix for this on GitHub: Komodo PHPUnit Harness
I had found other solutions, but this one seemed the simplest, and I like simple... less to go wrong.

After download the source from the github, and quickly reading the documentation, I realised that I needed to move the PHPUnit executable to part of the Komodo application package. Simply done with this:

sudo mv /usr/local/bin/phpunit '/Applications/Komodo IDE 9.app/Contents/Resources/python/komodo/harnesses/php/Base/PHPUnit.phar'

Note: if you are just doing this without making the mistake I originally made, you don't need to move PHPUnit to /usr/local/bin, just copy it directly to '/Applications/Komodo IDE 9.app/Contents/Resources/python/komodo/harnesses/php/Base'

Then I copied the new versions of HarnessSelector.php and Printer.php into the same folder, over-writing the existing ones.

Again I tried the test plan in Komodo:


Yay! Success!

Now only two things remain:

  1. An easy way to create unit test modules
  2. Code completion for the unit test classes

The first part is easy. I created an empty test case class, basically the same as the class I created before. This I then saved in the templates folder: ~/Library/Application Support/KomodoIDE/9.3/templates/My Templates.
Now I can create a new test case file from the File Menu in Komodo, by selecting New->File From Template...

The code completion is a little trickier, but was still quite simple. Komodo has the ability to read in files from a folder to aid code completion. The setting for this can be found in the Preferences window of Komodo:


This setting allows us to point to the PHPUnit source, however, I didn't have that yet... so back to Github to download the source: PHPUnit

Once I had that, and unzipped it, I wanted to keep everything neat and self contained, so I copied the relevant folder from the source to the test harness within the Komodo package. I only really needed the Framework folder in the source, so that's all I copied to /Applications/Komodo IDE 9.app/Contents/Resources/python/komodo/harnesses/php.

Unfortunately, the preferences window wouldn't allow me to select a folder within a bundle, so I ended up editing the prefs.xml stored in ~/Library/Application Support/KomodoIDE/9.3 manually. I found the String node of the XML with the id attribute of phpExtraPaths, and changed the  value of that node to: /Applications/Komodo IDE 9.app/Contents/Resources/python/komodo/harnesses/php/Framework

I actually did this last step twice because I had Komodo open the first time and it restored the original setting when I closed it. So, if you are doing this, make sure Komodo is not open when you edit the prefs.xml.

As you can see in the following shot, I now have code completion for PHPUnit.


The downside of all this is that I will need to redo these steps whenever Komodo IDE is updated, but it does now allow me to enjoy the benefits of unit testing in my PHP projects from within the Komodo IDE.


Saturday, 20 February 2016

Keyboard Issues with OS X Lion And Above

This may well be old news to some people, but it is only a recent discovery for me.
I was working on a small application that needed a custom text input field, however, when I was testing it, I couldn't get certain keys to repeatedly call the MouseDown event, and yet others did.
I found this very frustrating, and I must admit, I was beginning to think that there was something wrong with my Macbook. So I fired up TextEdit and tried using the auto repeat feature of the keyboard there.
What I discovered was, certain keys allowed repeated input (turns out mainly only symbols), some keys (certain letters and all the numbers) just sent a single keydown event to the application and others showed a popup:

Apples useful character selector
So I found out what was happening, turns out that Apple had changed the behaviour of my keyboard to make it more iOS like. In normal day to day use, this would be fine: it's not often I need to write a string of repeating characters. However, for the development work I was doing, I didn't want to see this behaviour. Now, being a normal(?), rational person, I thought that I would find the solution to my problem in System Preferences. Surely Apple would have allowed quite a fundamental change to be toggled on or off there. But no, I could not find anything that would allow me to change this behaviour.
Next port of call... Google. After a quick search, I discovered another blog post, this one by Adam Dachis, over at Lifehacker. In that post, Adam describes the very same issue I was having, although it looks like it has been in existence for at least five years.
Adam also gives a very nice Terminal command that can turn this feature off (for those of you that are not familiar with Terminal, it can be found in Applications->Utilities):

defaults write -g ApplePressAndHoldEnabled -bool false

It is also possible to re-instate this behaviour by changing the 'false' to 'true':

defaults write -g ApplePressAndHoldEnabled -bool true

Once you have issued either of these commands, you will nee to re-open your window that you are using to type into as it needs to be initialised with this new setting.
I understand why Apple have made this change, not only does it merge the behaviour of iOS and OS X, but in an increasingly global society, it is nice to have easy access to these characters. However, I do think that they made a mistake by not allowing users to turn this off, or on, whenever it is required.

Monday, 17 August 2015

String Extensions

Like many programmers, I find myself adding and removing characters from either the end or the beginning of strings a lot. It's a simple process, to add to the end of a string, we use:

// s = original string, containing "Hello World"
// n = new value to be added containing "!"
s = s + n //s now contains "Hello World!"

or to add to the beginning of the string, we can just as easily write:

s = n + s // s now contains "!Hello World!"

Retrieving and removing the end, or beginning, of a string is a little more complex, but still very straight forward.
For example, to get the last character from a string, and then removing it can be accomplished by:

// Assumes that s is a string that contains "Hello World"
v = s.Right(1) // v now contains "d"
s = s.Left(s.Len() - 1) // s now contains "Hello Worl"

And to get the first character, whilst removing it, we can use:

// Assumes that s is a string that contains "Hello World"
v = s.Left(1) // v now contains "H"
s = s.Right(s.Len() - 1) // s now contains "ello World"

Simple right?

Why would I need to even address this?

Well, I like simplicity, particularly in my code. I like it to be readable, even if I forget to comment.

To make these simple exercises even simpler, I took a leaf out of Javascript's array handling.
In Javascript, we have four methods for adding and removing items from the ends of an array: push, pop, shift and unshift.

pop and shift remove and return the last or beginning, respectively, element in the array whilst also removing that element from the array.
push and unshift will add the passed elements (yes, you can pass more than one) to the array, either at the end or the beginning.

So, I took this and applied to to the string type in Xojo, with a slight enhancement:
I didn't want to create a subclass the string type (in fact, Xojo won't allow you to do that anyway), so I decided to extend it, with the Extends keyword (as I showed in Extending The Date Class). Although it is not possible to subclass the intrinsic data types in Xojo, we are able to extend then, adding methods as we would for a class.

First off, I'll show you the Pop and Unshift methods:

Sub Push(Extends ByRef s As String, Value As String)
  s = s + Value
End Sub

Sub Unshift(Extends ByRef s As String, Value As String)
  s = Value + s
End Sub

As the eagle eyed amongst you have noticed, I have included the ByRef keyword as well as Extends. This allows us to affect the object, or datatype, being extended. If we didn't use the ByRef keyword, then any changes we made to the datatype would be lost when we exit the method.
Now, if I want to append something to a string, I can simply use the following:

// Assuming s = "Hello" and v = " World"
s.Push(v) // s now holds "Hello World"

Or we could do this:

// Assuming s = "World" and v = "Hello "
s.Unshift(v) // s now holds "Hello World"

To compliment these methods, I created the Pop and Shift methods. These, however, work a little differently to the Javascript originals. Normally, Pop and Shift return a single element from the Javascript array, however, as I sometimes need to get the first 2, or more, characters from the string, I have made these functions accept a parameter that allows me to specify the number of characters to retrieve:

Function Pop(Extends ByRef s As String, NumChars As Integer = 1) As String
  If NumChars < 1 Then NumChars = 1
  
  Dim ReturnValue As String = s.Right(NumChars)
  
  s = s.Left(s.Len() - NumChars)
  
  Return ReturnValue
End Function

Function Shift(Extends ByRef s As String, NumChars As Integer = 1) As String
  If NumChars < 1 Then NumChars = 1
  
  Dim ReturnValue As String = s.Left(NumChars)
  s = s.Right(s.Len() - NumChars)
  
  Return ReturnValue
End Function

Again, we are paying the extended string by reference. This is because we are removing characters from the string. The methods also return the removed characters. So, no if I want to get the last two characters of a string, and remove them from the original, I can use:

// Assuming s contains "Hello World"
v = s.Pop(2) // v now contains "ld" and s contains "Hello Wor"

If I wanted the first two characters, I would use:

v = s.Shift(2)

I have given the NumChars parameter a default of -1. I have also put conditions in the method to prevent the methods receiving a value for NumChars less than 1.

If I only want the first character, I can omit the NumChars parameter all together:

v = s.Shift()

and if I only want the last character, I can use:

v = s.Pop()

I don't know if you'll find these methods useful, but I find they save me a little typing and make my code a tad bit more readable.

If you would like to use them, feel free. Either copy and paste the code form here, or you can download them from here.

One small caveat, I use Xojo 2014 r2.1, which doesn't have the new framework. This may already be in the new framework, or this code might have issues. If anyone would like to test it in a later version of Xojo and let me know, I would be grateful.

Monday, 27 July 2015

BASIC or not?

Since my last post, there has been a discussion on the Xojo forums about the things I said. Most of it has been very positive, and I am grateful to the responses and subsequent discussion that has arisen. However, there is one thing that has been mentioned a couple of times that I would like to address, and I want to do it here as it could possibly clarify what I said before.

Some people think that I should not refer to the underlying language of Xojo as BASIC, and that is a fair point, it is no longer strictly BASIC, but it does have it's roots in the language. Hell, it was once called RealBasic.

Xojo, in my opinion, is an evolution of the BASIC language. BASIC, for those that don't know, is an acronym for Beginners All-puporse Symbolic Instruction Code. This does not mean that is is only for beginners any more.

It was originally design in 1964 as an easier language for non-programmers to be able to create software for mathematics and scientific pursuits. It then became the favoured language for home computers during the 80's during the boom in the market with most home computers having a BASIC interpreter either built in or available as a cartridge add-on (notable exception being the Jupiter Ace, which used Forth).

At that time, the language was fairly limited in what it could do, and the structure of the language also meant that without careful planning, the code could become rather unwieldy and unmanageable. However, the popularity of the language meant that developers continued to evolve it. This involved adding proper functions and subroutines, custom data types and now full object oriented features.
So, the BASIC of today is now very different to the language first developed in the 60's, but does that mean that it is no longer BASIC? Personally, I would argue that it IS still BASIC. The language retains a lot of it's roots, and unlike some other languages, whilst there are some ANSI standards for the language, BASIC developers have always added their own quirks to the language.

In conclusion, I think that Xojo (the language) is BASIC in the same way that the language of Delphi is Pascal. Both have their roots in their respective original languages, but both have exceeded the originals.

Does this make Xojo any less desirable, useable or important? Not at all, today it is a very capable and strong language.

For more information about the origins of BASIC, take a look at Wikipedia

Monday, 20 July 2015

Why Xojo?


Why do I use Xojo?

When talking to my peers in the software industry and they ask what I primarily use for application development, I get a number of reactions when I tell them Xojo. At first I normally get a response that indicates that they have never heard of Xojo. After explaining what it is, the next question is "why not use the standard tools, such as Objective-C for OS X or Visual C++ for Windows?".
In order to answer these questions, let me first give you. Brief history as to how I discovered Xojo. 

When I switched to a Mac, back in 2006, I had come from a Delphi development background. I had just spent the last three years using nothing but Delphi for virtually all of my software. However, making the switch from Windows meant that I needed to find a new development system. At the time, I was not aware that OS X came with developer tools (possibly it didn't, but I'm not sure). So I started to look for a Delphi equivalent for Mac. That led me to Lazarus, the FreePascal IDE that was purportedly cross platform. Unfortunately, at that time, Lazarus required X11 to be installed for OS X, not only for development, but also on the target machine. This was not really acceptable to me, so I moved on. 
My next find was RealBasic. Having also worked with Visual Basic in the past, I was intrigued by this system. RealBasic was supposed to be cross platform, using native controls and allowed for rapid development. I could write on a Mac and compile for Linux, Windows and Mac without the need to use a non-Mac computer. So, I bought a licence.
RealBasic has since been renamed, twice: Firstly to RealStudio, and now Xojo.

Since then, I have also brought my skills for Objective-C and, Apple’s new language, Swift up to date and can comfortably use these. Lazarus has also ditched the requirement for X11, so that is no longer an issue for me.

So why am I still using Xojo?
I think the best way to explain would be to list the pros and cons, that I have discovered, regarding the language:

Cons:
  • It is not free. Unlike Xcode (for Swift and Objective-C) and Lazarus, Xojo is not free and requires the purchase of a license for development (rather, I should say, for distribution, Xojo, Inc do allow you to download the IDE for free and program away, but to create stand alone binaries, you do need a license).
  • It is slow. Actually, that’s not a really fair statement. What I should say, is that applications written in Xojo do not perform as quickly as application written with the official tools. However, most of the time, that is not an issue, the only time I have encountered a problem with speed was with a very graphic intensive application.
  • It’s not as widely supported. As it is not one of the more common languages out there, resources can be a little difficult to find.
  • Not all platform features are supported. This needs qualifying. Not all platform features (Windows, OS X or Linux) are supported “out of the box”. However, Xojo does allow access to the platform API’s. Which does bring me on to my next point…
  • Xojo, Inc are always playing catchup. This does seem like an odd thing to say, but it is true. As this is a third party development system, the Xojo team can only address new features AFTER they are announced. 
  • Fiddly submission to the Mac App Store. With Xcode, I can submit apps to the App Store with very few clicks. However, to do this with Xojo, I either need to go to the command line, or use a third party tool, such as App Wrapper.

That’s a few cons, and for some people it might be enough to turn them away from Xojo. But now we get to the pros:

Pros:
  • Cross platform development. Even though I mainly develop for OS X, having the ability to recompile the same source for Windows or Linux is a blessing. I have even been commissioned to write a Windows application in the past, all of which (besides final testing) was done on my Mac.
  • Native controls. Whether you are on Mac, Windows or Linux, Xojo will mostly use native controls. There are some that are not (e.g. Listbox), but most of the time, it is very hard to see any difference.
  • Fantastic community. I know I mentioned in the cons about the difficulty in finding resources, however, when you do find those resources, they are normally excellent and well supported. Not to mention the very active, and friendly, Xojo forums.
  • API access. As I stated above, Xojo allows you access to all the API’s of the operating system. On OS X, this includes the frameworks. Whilst it can be fiddly, it can be done.
  • The debugger is easy to use. I know this is an odd “pro” to include, but after having used the Xcode debugger for a couple of projects, I have really come to appreciate the Xojo debugger.
  • Rapid development. I can create an application in a couple of days that could potentially take me a week in other languages.
  • Easy to understand. Whilst I know that BASIC is not everyone’s cup of tea, and I also know that some still see it as a “toy” language, I find the syntax very easy to read. This is also one of the reasons I used to use Delphi over C++, it’s just easier to read, and therefore debug.
  • Xojo promotes good programming. What? How did that get here? But it’s true. Because there are times when an algorithm can be very processor intensive, this can slow the application down. I addressed this in the past by re-writing apps in Objective-C, however, with some careful planning and clever coding, Xojo can perform the required tasks at the required speed. So in this way, it does promote better programming.

That’s just a few of the pros and cons. I could list a lot more, and I am sure I have missed some that other Xojo users would have included. In my opinion, most of the cons can be negated by programming techniques, careful planning, or (in the case of App Store submission) inexpensive third party applications.

I know that Xojo is not for everyone. There are times when I will use Swift or Objective-C for a change, but it is a very useful tool that shouldn’t be overlooked in the industry.  
The upshot is if the end application works and does what it’s supposed to, does it matter what language is used?