During the last month I have been switching between translating the IDE to Greek, and refining LC 6.7 and 7.0 releases, in terms of fixing bugs. Some bugs are quite easy to fix. Some others though, can be quite tricky. The first thing to do is locate where the bug comes from, and the next step is to actually fix it. In some cases, tracking down the cause of the bug is not that obvious. However, if you can find a previous version of the code where the bug was not present, then you can use some Git tools to find the specific commit in the history which introduced the bug. You could try to check out each commit, build it, and check if the bug is present or not. Usually there are a large number of commits, so this can take a really long time. This is a linear search. Hopefully, we can do much better by doing a binary search.  This is where the git bisect command comes in.

What is git bisect?

Git bisect is an extremely useful command in the Git version control system. The bisect command does a binary search through your commit history to help you identify which commit introduced an issue. It is quite quick. Imagine that between a working version of the code and a buggy one, there are a few hundreds commits, say N. Using git bisect requires only log(N) steps!

How to use it?

1. You start by specifying two states, a bad and a good one. A state can be a commit hash, a branch name, or a tag name:

In this example, HEAD is the current revision (ie the bad one), and 6.7.0-dp-6 is a tag of a good revision.

2. We then test it for the presence of the bug. We inform Git if the bug is there by running git bisect good, or git bisect bad:

3. Repeating the same process bring us closer to the faulty commit:

4. If we ever arrive at a commit that won’t build for a known or irrelevant reason, or if we just don’t know if the specific revision is good or bad, then we simply run git bisect skip. It doesn’t define it as good or bad, picks a neighbor commit and moves on:

5. Voilà! We fould the commit that introduced the bug!

After finding the problematic commit, we can see the diffs in github, and find out the cause of the bug.

6. We then move back to the HEAD (git bisect reset) and fix the bug!

Building LiveCode 

We have been very busy in the RunRev office this period. Among all the other things we are doing, we are producing Release Candidates for both LiveCode 6.7 and 7.0. In the meantime, we are fixing some bugs that were introduced  as a result of the iOS 8 release. These fixes will be contained in LiveCode 6.6.4, and then rolled up to 6.7 and 7.0. They include updates in various parts (engine code, IDE code, dictionary entries, release notes etc).

When everything is ready, all these different pieces have to be brought together to a complete product, and nicely packed within an installer. This is done through the process of building. After building the installers are uploaded to http://downloads.livecode.com/livecode/ webpage, but are not immediately accessible to the public. At this point, they are thoroughly tested, not only by RunRev developers, but also sometimes by some of our most experienced community members. Once we make sure that everything works as expected, the installers become public and are available for all the users to download.

The first time I did a build was for LiveCode 6.7 DP5, and since then I have done most of the 6.7 builds. In this post. I will briefly describe you the process of building, as I first experienced it.

I was really surprised to find out that for building LiveCode, we use … LiveCode(!),  for a significant percentage of the process. Theoretically, it is possible for 100% of the process. However, in order to resolve more easily merging conflicts between the various bugfixing or feature branches, we use some other tools as well.  

The LiveCode stack that is used contains facilities for building LiveCode engines, docs, notes, installers, and server engines for all platforms. It looks like this:

 (I have slightly changed the location of the buttons to fit the width of this post!)

The first thing to do is make sure that all pending and already reviewed pull requests are merged  into the develop branch of the main LiveCode GitHub repository. If not, we have to merge them, and resolve conflicts, if any. After that,  the develop branch is ready to start building from. Note that the develop branch is used only for LiveCode 6.7 builds. For other LiveCode versions, different branches are used.  

Then, using the above stack, we generate the public key in the Environment stack. This is used to sign the LiveCode app, and is needed for the commercial license activation.

The next step is the actual build of the LiveCode engines, for both the community and commercial version, for each platform. We use Xcode for MacOS and iOS, a top level Makefile (that references Makefiles in each relevant folder) for Linux, Visual Studio for Windows, and a script that builds all the binary components and necessary Java support for Android. Alternatively, we could just use the above stack, select all platforms (apart from Linux x64) and click Build Engines button. However, it is easier to track down and fix any errors that may occur if you follow the first approach. 

Next, in case there are updates in the IDE, we have to get them from the LiveCode SVN repository. Apart from the updates in the IDE code, we must make sure we get the newest IDE-related bugfix notes, if any. The notes have to be put in a separate folder, so as to be exported automatically into the release notes. At this point, the hard work is done. The remaining part is just clicking buttons on the above LiveCode stack.

So, we go back to our stack, and click Build Docs and then Build Notes button. Afterwards, we select Community from the drop-down menu, tick Windows, Linux and Mac OS X and click Build Tools (this creates the installers) and then Build Server. Next, we do the same for Commercial. 

Now, everything is ready and all we need to do is upload the binaries to the RunRev server. We use FileZilla for that. Finally, we press the Archive button, to make them appear in the download page.

It was very interesting to be involved in the whole building cycle. Special thanks to Michael for always being there to help 🙂

Things are running smoothly regarding the update of the player object. In this post I will briefly describe what has been done so far.

The first step was the refactoring of the MCPlayer related code. Formerly, the MCPlayer class used ifdefs in most functions, based on whether it was using the ‘platform player’, ‘quicktime’, or was on Linux. Now, MCPlayer is split into two classes in separate files (player-legacy.cpp/.h and player-platform.cpp/.h). The former is the pre-platform API version; the latter the platform API version. This made it easier to update the platform-player version to use its own controller.

The next step was to implement a custom controller bar. For the reasons described in the previous blog post for Multimedia on Mac OS, we had to implement our own controller. After some discussion, and some research on the appearance of modern video controllers, we are almost there! Below is a preview of the current, and probably final version.

Because some users may not like this color, we thought it is better to make it customisable. So we added some properties to the player object. In fact, we tied in some existing properties that were not used for the player object. For example, the hiliteColor. For the player object, the hiliteColor is the color of the played area, as well as the color of the volume area in the volume popup window. It is also the color of a button background when this button is clicked. So, if you don’t like the purple color that is set by default, all you have to do is add a new button (or just type in the message box) with the following code:

on mouseUp

set the hiliteColor of player 1 to red 

end mouseUp 

The result is the following:

In the player object, you can also set the foreColor, which is the color of the selected area, i.e. the color of the area between the selection handles. This is dark grey by default.

Modify the code in your button, to change both the hiliteColor and the foreColor: 

on mouseUp

set the hiliteColor of player 1 to “127,255,0″

set the foreColor of player 1 to “106,156,56”

end mouseUp

The result is the following:

Finally, we had to move from Quicktime/QTKit to AVFoundation. This transition is now done, and the new player object seems to work perfectly with the AVFoundation APIs. Some tweaks have still to be done, in order to ensure similar (or at least as similar as possible) behaviour with the old Quicktime/QTKit controller. Next, and final step as far as the player object is concerned, is to test it thoroughly and fix any bugs that may arise.

The current project I am working on is about multimedia on MacOS. It includes replacing all  multimedia functionality (in the player object, revVideoGrabber external etc)  in LiveCode to use the latest Mac APIs (AVFoundation, introduced in OSX 10.7). All these multimedia capabilities rely on the QuickTime/QTKit APIs. But Apple recently deprecated QuickTime APIs. This means that apps that use QuickTime will be rejected in the AppStore submission.

 So, after transitioning the existing Quicktime/QTKit code to AVFoundation, users should be able to submit a multimedia based app to the AppStore for their OS 10.7 customers and above.

 The problem is that the new APIs do not provide the same functionality as the original QuickTime API, so we must ensure that we will provide our users with the same feature set they are currently used to. For example, the player control bar. QTKit’s controller is broken in OSX 10.7+ and AVFoundation does not have a controller until OSX 10.9. This means that we need to write our own custom controller.  

 I have almost finished implementing the custom controller, at least as far as the functionality is concerned. It probably needs a bit more work to look prettier! 

Below are both the QTKit controller and our custom controller, as implemented so far. Note that the selection handles are broken in QTKit controller on OSX 10.7+

The next stage is to update the LiveCode player object and all other multimedia functionality in the engine to use the newest AVFoundation APIs, as well as to implement a QTKit/AVFoundation version of the revVideoGrabber, since it too relies on the deprecated QuickTime API.