LiveCode 9 contains so many new features that it’s almost impossible to cover them all in detail in a single blog post. So I’m not going to try. There have been several other blog posts along the way detailing specific features, which will be linked in the course of this blog – see these for more information.

Instead, I present the inside story of LiveCode 9.0, as it happened. The story has two main threads. The first is the ability to access to libraries and platform APIs written in other languages, aka the community-funded ‘Infinite LiveCode’  project. While the initial implementation of LiveCode Builder included simple C library support, we have extended this to support accessing more complex C libraries, Objective-C and Java. We have also refined the native layer support – there is more to come on this front in the 9 series, particularly for Windows and Linux. So we owe a huge thank you all who contributed, financially and/or otherwise, to achieve this goal.

The second thread is the refinement and rounding out of the HTML5 platform, to the point where it’s possible to deploy great professional apps. Having delivered the community-funded HTML5 deployment option, we have been steadily adding to the feature set. We are approaching  feature-completeness in terms of what is possible with the current infrastructure, and will be continuing to work on this in the coming months with the aim of achieving as much parity with the other platforms as we can.

Along the way we have added many other features, some of which support the above aims, and some of which are completely tangential. Highlights include:

• SVG support in the image object
• Emoji support in the field object
• Autocomplete in the script editor
• Remote debugging

Timeline of Nine

This timeline shows the number of additional tests run in each release, the number of PRs merged, the number of bugs fixed; plus Infinite LiveCode features in red, and HTML5 features in blue.

Some of the numbers of additional tests run may look excessive, but they are actually correct – for example, between DP 9 and DP 10 we added a server test runner, meaning most of the 40,000 odd tests run on the standalone engine were also run on the server engine. Between DP 8 and 9 we added tests for strict compilation on all IDE stacks (albeit many of them skipped for now). We also added tests for extracted docs from all extensions and improved the tests for dictionary syntax; 9.0 is also the first release where the requirement to add a test where possible when submitting fixes and features has been in place throughout its development.

9 DP 1: “Community Docs”

One area that saw a lot of activity prior to the release of 9 DP 1 was the dictionary. We had not long before converted the docs from XML to the ‘lcdoc’ format so that they would be easier to modify. This turned out to be relatively successful: over half of the 165 PRs that went into 9 DP 1 were docs modifications, largely from @asayd and @seaniepie. Also, there were several PRs that look like this:

These made our builds stricter, thereby removing more hard to spot coding errors. These can be good candidates for DP releases, as they provide good foundations for future development, but can often have subtle or unintended consequences or changes in behavior. The other major internal change that occurred during this DP was running continuous integration tests on Mac as well as Linux.

9 DP 2: “Virtual Machine Refactor”

Another release in which most of the large changes were internal – in this case some essential refactoring work on the LiveCode Builder virtual machine to support future development, and provide the basis for Infinite LiveCode. More than anything, it was this phase of the project that would have been much harder to do without the community funding – it’s essential for moving forward, but doesn’t immediately produce nice shiny features that give a return on the resources invested. This release was not entirely inward-facing though – we also added one of the most powerful features to the HTML5 engine – the do … as javascriptsyntax. This enables you to  call into the web page from your HTML5 standalone. See this blog post for further information.

New extensions:

• Spinner widget
• Command-line option parsing script library
• OAuth2 script library

9.0 DP 3 & 4: “Trundling Along”

As you can see from the timeline, the 9 DP 3 release was somewhat low-key, other than the additional tests which mainly came from testing docs extracted from extensions. DP 4 contained support for multi-module extension loading which will prove crucial to cross-platform native widgets – of which more later. Otherwise, as is typical of these early 9 DPs, the release contained a swathe of community-contributed documentation updates and fixes.

9.0 DP 5: “Defect Resolution”

One of the tools we use for identifying code issues is ‘Coverity Scan’ – a static analysis tool which is free for open-source projects. Searching for ‘coverity’ in the LiveCode git repo reveals how valuable this tool has been for us- over 100 pull requests, many of which fix multiple identified issues – from things like dead code identification (which can turn out to reveal something serious, for example if some code you thought was running actual never does) to buffer overruns and uninitialized variable access.

Unfortunately, after the overhaul of DP 7, our Travis builds take longer than the maximum allowed time when the time taken for Coverity static analysis is added. In order to reinstate this invaluable service, we need to rework the build system so that a few more third-party libraries are prebuilt (like CEF, OpenSSL, and ICU are). This would be very beneficial in general – especially when you consider the fact that we build Skia (among other things) more than 10 times for every build – taking into account the number of pull requests that have gone into 9.0, including retries, failed builds etc, I suspect it has been built in excess of 10,000 times by our build system in the course of getting to 9.0 GM.

Another somewhat ‘internal’ change for this DP was updating the Mac builds to support C++11 features (of which more to come in the aforementioned DP 7)

New extensions:

• MIME library
• Remote debugger
• Script profiler

9 DP 6: “Java”

9.0 DP 6 saw the first version of the Java Foreign Function Interface (FFI). See the associated blog post for some sample code. This allowed basic access to the Android API, instantly making a large portion of the built-in functionality available to LiveCode apps. We also added a java utility library, providing the ability to convert between some LiveCode and Java types. This served simultaneously as a watershed moment for LiveCode’s Android deployment, and also as a genuine proof-of-concept for Infinite LiveCode in general, providing a rough template for the Objective-C FFI to come. This work would likely have been applied rapidly to create some initial Android extensions, were it not for…

9 DP 7: “Yak Shave”

It pains me to even cast my mind back to DP 7. It is the release that brought the phrase “Yak shave” rapidly into the LiveCode lexicon.

What’s the emoji for yak shave?

— Wynn Netherland (@pengwynn) January 15, 2014

The complications arose due to a seemingly fairly straightforward commission to add emoji support to the LiveCode field. The task as we saw it would consist of updating the third-party graphics library Skia. This would indeed have been the simple task we thought, and only taken a week or so, if it had merely been a case of grabbing the Skia source code and updating any uses of changed APIs. Actually, even if this was ‘all’ we had to do, it would have taken most of the 3 months it took to release 9.0 DP 7.

The first problems arose when the version of Skia we needed required C++11 support. Some of our existing toolchains were OK in this regard, (recall this was added for Mac back in DP 1) and some weren’t. Even if we were being as conservative as possible, there’s no practical way for us to maintain source code that uses different Skia versions for different platforms. This meant updating toolchains for pretty much every platform we support. OK, maybe not such a huge task if everything works out ok, but we also continue to release the 8.1 series. Updated toolchains can cause unknown instabilities – as such it is not suitable for maintenance releases. Therefore the first task, prior to updating Skia, was to change the build system so that we could build different releases using different toolchains.

Here is a sneak peek at our buildbot-generated builder status page, post- DP 7:

If you’ve ever wondered what goes on behind the scenes of a LiveCode release, some of it for sure involves staring at this page. It is almost exactly three years since the birth of LiveCode’s automated build system Prior to this, every release was done on machines in the office, building every platform *manually*.

Another build-process nicety that was much nastier at the time was the matter of ICU, OpenSSL and CEF prebuilts. At the time of DP 7 these were done manually also. Shared libraries can be very sensitive to the context they are built in, and there were many issues that arose because of subtly different toolchains used in building the prebuilts to those used in building the engine.

Finally these issues were ironed out; thankfully in the last year we have had the time and will to add prebuilts builders to our build system, meaning we can build updated versions very easily, and need only concern ourselves with updating any API calls that have changed.

A particularly difficult toolchain update was presented by Windows. We needed to update Windows builds to use Visual Studio 2015 instead of 2010. We also needed to work on the build system to support the updated Windows toolchain.

This turned out to be a very tricky task as the way we were building for Windows previously (using Wine on Linux) no longer worked. We had to purchase space on the Windows cloud server Azure, and port *all* of our build scripts to Python instead of shell script as the latter don’t run on Windows. Finally we had to ensure that buildbot worked to build Windows using the new toolchain, which involved quite a bit of fettling with Windows server.

Finally, we could update Skia’s text rendering backend in order to draw coloured emoji. Provided we could fix a bug introduced in 7.0 preventing emoji on iOS working, and replacing legacy graphics features that were no longer supported by the new Skia, it really felt never-ending.

It never rains but it pours – and alongside the toolchain updates we were busy getting on with Infinite LiveCode for Java. We needed to refactor external library loading, as the code was scattered throughout the engine in many places. Unfortunately changing this along with updating our prebuilt libraries caused some very hard to diagnose issues.

Perhaps we should designate 7 as our unlucky number and skip DP 7s in the future. Also ‘toolchain’ became a ‘verbum non gratum’ in the office, not quite banned outright but you had to be careful using it around Kevin. However we are yet to assign it a euphemism as we have ‘moomin’ to the banned word ‘refactor’, introduced in LiveCode 7. (LiveCode 8 did not add any new banned words to the lexicon).

DP 7 did see the addition of support for Java interfaces, allowing LiveCode Builder handlers to be registered as the targets for Java interface callbacks, such as event listeners – see this blog post for more details. This was essential for doing anything with the Android API that required responding to user input. With this piece of the Infinite LiveCode puzzle, almost everything from the Android API was accessible.

New extensions:

• Message Authentication script library
• Dropbox v2 script library
• Diff script library
• AWS S3 script library
• Android native button widget

9.0 DP 8 & 9: “Objective-C”

Objective-C FFI support was added for Mac in 9.0 DP 8, and for iOS in DP 9. This enabled access to native APIs these platforms. These DPs also saw some improvements to the Java FFI (including the ability to call native methods on the UI thread), plus some general work to make adding new supported languages easier. Another feature for C generally, but also very useful for many parts of the Mac and iOS SDKs, was added in DP 9: C aggregate support. This gives the ability to pass and return simple C structs to and from functions.

On the HTML5 side, a libUrl driver was added in DP 9, allowing the standard LiveCode HTTP methods to be used in HTML5 standalones.

DP 9 was also the first 9 release with a Community Plus edition, which of course means that it was the first to contain autocomplete in the script editor.

New extensions:

• QR code generation script library
• HTTPd script library
• Mac native button widget
• Android native field widget
• Audio Recording library for Android
• Mac Native Field widget
• iOS Native Button widget

9.0 DP 10: “One-Click Test”

Although there was a major step forward for Android extensions in DP 10 (namely the ability to interface with JAR files- archives containing compiled Java classes), since there was an improvement to interfacing native code on all platforms in DP 11, it fits somewhat better there. The other highlight of DP 10 was the HTML5 deploy library.

This enables testing of HTML5 apps with a single click, which turns out to be an incredible time saver! It also makes it easy to launch and test with different browsers.

9.0 DP 11: “Going Native”

The other aim of the Infinite LiveCode project was to enable the use of third-party libraries written in other languages. To this end we added the ability to include and interface first with JAR files in DP 10, and subsequently AAR files (archives containing JAR files, and other assets for Android third-party libraries) in DP 11. Together with support for merging Android manifests, this enabled the inclusion of almost any Java-based Android extensions. We also added extension shared library loading on all platforms (except HTML5, for the time being). Now with the appropriate folder structure, you can simply plug your shared libraries in to LiveCode via a LiveCode builder extension, with very little extra effort. This reduces the collection of third-party C libraries that require using the old externals interface to a set of edge cases- and we will work on eliminating those as they arise. And going via LCB means you don’t need to set up any XCode / Visual Studio / other projects and compile C glue code.

On the HTML5 side, DP 11 contained windowing support – enabling the use not only of multiple stack windows, and things like the go … in window command, but also features of the LiveCode engine that are implemented using transient stack windows – that’s tooltips, dialogs and popup menus.

As if that weren’t enough, aside from the Infinite LiveCode and HTML5 developments this release also saw the first version of SVG support within the LiveCode image object, and the ability to create ‘script library’ extensions using the extension builder. In particular this means you can turn your LiveCode Script utility libraries into extension packages that can be uploaded to the store. See the associated blog post for details on all the features added in DP 11.

New extensions:

• Android toast notification library
• Native map widget for Android, iOS and Mac 64 bit
• Signature widget
• Secure key library for Android, iOS and Mac

9.0 RC 1: “Bonus Features”

Although strictly the last DP in a series should be feature-complete, we did sneak some bonus features into 9 RC 1. We were on a tight release schedule, but didn’t want to delay some really useful (and internally well-tested) features that didn’t impact on the core engine. Indeed, it could be argued that some things like new extensions are out-of-stream anyway, as updates could (and will in the future) be managed through the extensions store.

Thus RC 1 contained native layer support for HTML5 – something we felt it was important to include so that it would be possible to write functional cross-platform widgets in 9.0.

We also added a timezone handling library – this is significant as the extension accesses a small third-party library compiled for all platforms to read timezone information from its resource files, using the code library work from DP 11.

New extensions:

• Timezone library
• HTML5 native button widget

Extensions Store

We are working hard on the first version of our new Extensions Store, which should be ready shortly. It will appear automatically in place of the old one in the Store tab of the Extension Manager.

There are a whole bunch of things we are looking into adding to the store in future iterations, to make things easier and better for uploaders and downloaders alike. These include:

• Allowing you to specify a GitHub url for an extension
• Different licensing / commercial extension options
• Porting all the content from LiveCode Share to the extensions store
• More search options

A couple of previous issues should be mitigated in this iteration of the store, including the following:

• While we work on ways to improve module dependency support, if you have support modules that are required by your extensions, you can use the new multi-module extension building to compile those modules into one bytecode file thereby ensuring your extension can be installed from a single download.
• The 9.0 IDE will recompile any extensions it can, without overwriting the module bytecode file. So extensions made in 8.0 and uploaded to the store can be downloaded and installed in 9.0 (providing no unsupported features are being used – principally the use of the `execute script` syntax in widget lifecycle handlers).

So please get writing extensions! We would love to see the store full of community-authored extensions. As with LiveCode DP releases in general, the best way to influence the direction of the store is to get in early, try it out and give us your feedback. If you are new to writing extensions, check out the extensions course online, and the Extending LiveCode guide in the IDE documentation viewer, or on GitHub

LiveCode 9.0 in the community

Here are some of the ways you played a role in making the 9.0 GM release.

Bug Reports

The following chart shows the top bug reporters for any LiveCode 9.0 release. Note that we do not have statistics for which release the bug was originally reported against, as we try to change the version to the earliest in which a bug appears. As such the chart is skewed towards bugs that turned out to eventually be 9.0 *only* – apologies if you tested 9.0 a lot and kept finding issues from further back!

Way to go Mikey! I would also like to give a special mention to [-hh], who I’m pretty sure did more testing and feeding back on both LiveCode Builder AND HTML5 deployment than anyone, and whose examples and experiments really show what is possible. If one of those H’s doesn’t stand for ‘heroic’ then may I suggest a name change to [-hhh]?

GitHub Contributions

It’s always dangerous to single any particular people out, but I’m going to do so anyway. Around about the time of DP 8, someone popped up on GitHub, prompting various chatter around the office. In an alarmingly short space of time, @bwmilby went from “Who’s this Brian Milby chap?” to “Ooh, I hope Brian Milby decides to work on that” – contributing to all areas of LiveCode: docs, extensions, IDE and engine. Thanks very much Brian! @trevordevore contributed code to the majority of 9.0 DPs – even sneaking pull requests into the short development windows of DP 3 and 4. Apart from the aforementioned docs contributors (@asayd and @seaniepie), @jameshale, @bhall2001 and @BerndN contributed significantly to docs and the IDE, @HedgeHao was very active on the engine side, particularly improving various things in the Android engine, and @mwieder removed a bunch of data files and added a bunch of tests.

Use List and Forums

Firstly I’d like to highlight the LiveCode Builder thread on the forums – this has been extremely helpful in identifying issues and missing features in LiveCode Builder, plus gaps in the documentation, so thank you to everyone who has posted and continues to post in there. Secondly, this thread in the use list on SVG support, which started out as a discussion about naming a new widget, and ended up with the realisation that it would be much better to add the SVG support to the existing image object.