There has been a buzzword circulating round for a long time now – Values.  What are Values you say? 

Values are the intrinsic elements that underpin our behaviour, in this case, that of LiveCode, and they should relate to our day to day experience at work.  It may seem cheesy, but when we are around people we share common values and beliefs with, we feel safe and secure.  When we are happy, we have a more positive outlook on all aspects of life – our environment, colleagues, and from LiveCode’s perspective, the way we work.

At LiveCode, our people are our most precious resource, which is the catalyst for a healthy company.  We actively strive to create a fair and balanced partnership with every individual as they are on the frontline, communicating with our community and representing LiveCode daily.  The relationships we build and the service we provide are key to building a successful brand and more importantly, ensuring everyone has bought into our ethos.  That starts with making people feel valued.

A great entrepreneur of our time said:

“Your culture really is one of the most important things of your company, it’s who you are, it’s why customers choose you.  Build a great company which you would want to do business with yourself.  If you get this right, your culture is right”.

–       Sir Richard Branson

 We start making our people feel valued by showing them trust, providing development opportunities, and practising what we preach.  With this in mind, we recently concluded an activity to renew our Vision and create our Values. 

Our Vision is that Everyone Can Create Apps and that is at the heart of LiveCode.  The role technology plays in our lives is going to grow and we believe we can contribute to empowering people to get the most out of technology in all its forms.

Our Values are simple.  We value every team member, every customer, and the wider community in which we operate.  We value diversity and offer an atmosphere where ideas are welcomed.  We care – personally and professionally.  We are an open-minded company and a great place to work.  We innovate and are always at the forefront of technology.

I am enjoying my time at LiveCode.  We have always looked after our Community and with our Values now clearly articulated (they have always driven the company, we’ve just formalised them), there is equal focus internally.  Happy people = a ready supply of LiveCode ambassadors and a brand people will hear about at a national and global level.

The number seven is interesting, and not just because there are no uninteresting numbers. For one reason or another the number has taken on a mystical quality in various cultures, not least in the office where it now surely holds the distinction of being the ‘most said number of the year’. Incidentally, we are not in general numerologically inclined, but hexakosioihexekontahexaphobes will be pleased to hear that there will probably not be another maintenance release after 6.6.5, despite what would have been the serendipitous proximity of Hallowe’en, the perfect date to unleash it.

There seems to be a certain memorable quality conferred on any set of seven things, and as such seven has become the de facto target for the quantity of a would-be interesting collection. Science, literature and life are littered with examples – Wonders of the Ancient World, colours of the rainbow, deadly sins, to name but a few. 

I am a fan of puzzles. These can be various sorts of puzzles, although the ones that really get my attention are the sort that are generally only found in a so-called “puzzle hunt”. To the uninitiated, these are strange variations on the traditional puzzle – they contain no instructions, and there is always an answer (usually a single word or phrase) as opposed to just a puzzle in a solved state. It turns out that sets of seven is a relatively common theme for these puzzles. Here are two examples (one from a puzzle hunt that is ongoing):

Li Ven Se Tt Le

Quadratum

The point is, for me working from start to finish on LiveCode 7 was in many ways similar to the process of solving a puzzle hunt. In fact, it probably ought to be similar in precisely seven ways, so lets see if I can shoehorn this section into a thematic format. I present a Buzzfeed style list:

Why working on LiveCode 7 is similar to solving a puzzle hunt. 

1. There is a way in

Since there are no instructions, the best puzzles tend to have an early hook to bring you into the world it inhabits. This can be any number of things, perhaps it has the presentation of a traditional puzzle such as a crossword, or perhaps it has some basic questions to answer, images to identify, facts to gather. Sometimes all you have is a pun in the title.

At the beginning of the refactoring project, my main task was to separate evaluation and execution in LiveCode syntax. Every function, command, operator, control structure, and constant in the language of LiveCode has a syntax class which is responsible for resolving expressions or performing actions in the appropriate way. We wanted the resolution of  subexpressions to be completely distinct from the execution. 

 In the first cases I encountered, this could be as easy as simply creating a new function in the engine, cutting a section of the syntax class implementation, and pasting it into the new function. Of course even in a simple case, one needs to read what is actually happening to make sure it is the correct thing to do. This was my way in; learning about LiveCode syntax and how it works; being brought into its world.

Here is an example of one of the more simple refactoring tasks. At the other extreme, refactoring the chunk object was completed with approximately 20 commits. 

2. It consists of a multitude of multi-stage processes

Another thing that distinguishes puzzle hunt style puzzles is the fact that they are generally multi-stage puzzles. There is rarely just one thing to do to get the answer. Sometimes it is not clear how many things will have to be done to complete the puzzle. The analogy here is clear – the many tasks necessary for the completion of the refactoring project all tended to break down into multiple subtasks. On a number of occasions, the details of the later stages of a task were not revealed to us until we had to do them. Of course, like some puzzles, this means that some stages of the project were fairly epic. Some lasted days, others weeks, still others months. That is to be expected, I suppose, when dealing with something on this scale. But the fact that the work would apparently have taken one person almost a decade to complete still boggles my mind. 

Usually a puzzle hunt will try and have a wide variety of puzzle types, testing many areas of skill: linguistic, logical, mathematical, artistic and musical puzzles abound. There is a certain polymathic requirement when dealing with the LiveCode engine too. While most of the engine is written in C++, parts of it are in Objective C, and parts of it are in Java, and when you are supporting many different platforms that means dealing with different APIs from all the operating systems. Just like a puzzle hunt, you have to be prepared to acquire a new skill just for one specific task. You often find yourself becoming an expert in rather strange areas. Like Roller coasters and knot theory. 

3. Organisation is paramount

The elements of the refactoring project that went the most smoothly were of course those for which we had been able to dedicate a good amount of time to planning and tracking. The trail of spreadsheets and documents in my Google Drive is longer than my virtual arm. This also relates in part to the previous point. The more subdivided the task, the easier the documentation of progress, and the better documented the progress, the more that progress is a boon to the project as a whole.

 I and the rest of my puzzle team have frequently found that a suitable organisation of the information gathered is sufficient to spark the next idea, or to unstick oneself. I’m trying to get the phrase “Sometimes it takes looking at different data on three laptop screens to work out how to solve a 3d maze and apply those directions to a Rubik’s cube (last page)” into general usage, but I’m not sure it will catch on.

Refactoring is in itself just a form of organisation. The codebase now is far more readable than it was before; which of course was one of the motivations for undertaking the project in the first place. It is important for people to be able to contribute to an open source project, and clearly the easier it is to understand what is already there, the easier it is to contribute. 

4. It involves looking at a lot of unfamiliar Unicode codepoints

And sometimes understanding them

And sometimes knowing how they are made up

And sometimes switching to different keyboard layouts

 Changing LiveCode’s internal string representation to accommodate Unicode has taught me untold amounts about the scripts used in various countries around the world. The integration of the text shaping library Harfbuzz (so that scripts such as Arabic, Khmer, and Devanagari look as they should on Android devices), amongst other things, resulted in an input source list that looks like this:

On one occasion, such keyboard switching had me completely locked out of my Ubuntu virtual machine, due to not being able to switch to English layout without logging in, but also not being able to actually type any of the characters in my password without switching to English layout. 

5. It requires concentration and attention to detail

Sometimes this is attention to small details in situations where there is not much information. Or in the case of this puzzle, extreme attention to detail (warning: attempting to solve the latter puzzle is a surefire route to madness). Other times it is a case of not trying to understand everything that you’re looking at, just the relevant parts. Like this. The aforementioned chunk object is so fundamental to LiveCode that even a slight mistake in refactoring it caused the LiveCode IDE equivalent of the blue screen of death (which happens to be a white rectangle with the “revLibURL” button on it).

 When replacing c-strings with MCStringRefs in the code, it was frequently the most efficient strategy to merely ensure that the behaviour was identical to what it was before, without completely understanding what the function was doing as a whole. 

6. It sometimes feels like it will never be finished

Getting stuck is a fact of life. Even more so a fact of puzzle hunts. Puzzles have a phase known as ‘extraction’, whereby the answer is obtained using all of the information that has been gathered and worked out. This can be as simple as using some numbers to index some words, or an acrostic that appears after sorting alphabetically. Other puzzles have more intricate extractions mechanisms, and some of the most beautiful involve iteration of procedures from previous parts of the puzzle. In any case, extraction can be very difficult, and it is therefore a very common place to get stuck.

Likewise, the period of time between being “basically” finished with LiveCode 7 and actually being finished felt like an eternity. I say actually finished, obviously there are some things to clean up, some residual bugs and so on. But we’re putting away the syntax caravan, and work is already underway on the widgets and themes project that will form the basis of LiveCode 8. In fact, I would like to get the phrase “putting away the syntax caravan” into general usage to mean almost finished. “How’s that novel coming along?” “Well, it’s not done, but I’m putting away the syntax caravan, if you know what I mean.” “No, I don’t know what you mean, Ali. Stop saying that.”

7. There are many ‘aha’s

The ‘aha’ or lightbulb moment is probably the reason why people who do these puzzles do them. It can be quite exhilarating, the joy of discovery, and is certainly quite addictive. One of the closest real-world experiences to the idealised puzzle ‘aha’ is solving a programming problem. There is a huge amount of satisfaction that comes from finishing off anything, particularly if it has involved an element of mystery, triumph over adversity, and especially if it is completely and utterly epic in scale. The refactoring project ticks all these boxes as far as I’m concerned. And there were ‘aha’ moments in spades. 

Caveat: Why working on LiveCode 7 is not at all similar to solving a puzzle hunt

I mentioned before that there is always an answer to a puzzle hunt puzzle. There is also usually a ‘metapuzzle’, which involves using all the answers to all of the individual puzzles in the hunt. Well, here’s where the analogy completely breaks down. There is not single phrase answer to the LiveCode engine. Like a more traditional puzzle, the best we can say is that it is in a more ‘solved’ state than it was when we started. But that is still deeply satisfying, and a goal I’m happy to have spent my first two years working towards.

Solutions:

Quadratum

Please Remain Seated

Contortionist

English Expectations

Cryptograf

Symphony from the Old World

Circulus In Probando

Team Statistics

and finally

The LiveCode Engine

For the past month I’ve been delving deep into the LiveCode IDE, with the purpose of preparing the product to be localised, so that strings in the UI are in the users’ language of choice. Simultaneously, I have been learning a new programming language myself. 

One of the newest members of the LiveCode Development team, I joined in September fresh out of University looking forward to immersing myself in the world of software development, and picking up a new programming language to boot. I was excited to learn LiveCode, and seeing how well I’d be able to pick it up – as surely that’s the point, after all. 

After a day of settling in and getting myself set-up and ready to work, I began my first project, localising the IDE. Initially, the project required me to trawl through reams of LiveCode script, looking for strings that would need translating, making a note of these strings and passing these strings through a dummy function. The dummy function just returned the strings in all capitals, making it easy to see what had been “translated” and what hadn’t. Ultimately, the localisation function would return the string in the user’s selected language, but for now the project just required that the IDE was prepared for translation and everything that would need eventual translating was documented. 

The first stage of the project, while laborious, was an excellent learning curve for me. I was able to get in to the nitty-gritty of the product, see LiveCode being put to use and begin to write a small amount of LiveCode script of my own. I also got to see the ups and downs of changing the IDE through the IDE – a challenge in and of itself – instantly being able to see changes made or managing to break the IDE with one typo! It also highlighted how the product wasn’t designed with localisation in mind, as I came upon obstacles to translation such as images with English text in them.

The next stages, which I am working on now, involve me preparing the strings for translation, creating a tool for the translators and writing the localisation function. It was in these stages of the project that I was really able to start writing my own LiveCode script. Not only was I able to start doing this with relative ease, with some questions for specific situations, I quickly found myself able to fire off script in LiveCode as if I were writing some text in English. Having done a bit of programming at University and an internship in mobile development, I am not a complete novice when it comes to programming. However, I was impressed at how natural programming in LiveCode felt and I’m pleased to be part of a project that is making the product more accessible to budding developers around the world. 

Encouraging Children to Code

Another three unlikely suspects to combine into a JoJo Blog Post about coding? Well, maybe not! 

Who: Facebook, HRH Prince Andrew the Duke of York and Peter Capadli, the most recent appointment to play the notorious Time Traveller, Dr. Who! 

Why: To encourage children to learn to code of course! 

See it now? Not quite? OK, I shall explain..  

There is a growing revolution in the UK and Europe to encourage children to code and to raise awareness of the capacity for children to code from a much younger age. The ideal is that all children will have access to tools to allow them to develop programs and apps, making the digital world an integrated part of their everyday life, in a way that suits them. 

The discussion of coding is far more prevalent now than it ever was and it is easy to see why. By capturing young minds we set a path for the future and by educating them and providing them with the right tools, we support them in their journey. 

Many businesses are striving to be a part of this revolution, so why are these particular people standing out in striving to support this cause? Well in a sea of articles, these are the ones that most interested me.. and after all it is MY Blog Post, so I thought I would share!

Facebook has joined forces with other industry influencers (including Microsoft and Rovio) and has formed a coalition to launch a pan-European online platform to drive participation in coding.

In September, coding in English schools was made mandatory for all children aged between 5 and 16 years old. Particularly interesting then is to hear that 3 young coding enthusiasts from the UK have beaten off European competition to win the gaming contest. 

The Kodu Kup is where teams from the UK faced competition from Portugal, Finland, Norway, Belgium, Greece, Lithuania and Estonia to battle to a Dragons’-Den style final, complete with selling pitch! 

One of the most enlightening statements I read came from one of the Team Winners, Alfie, who felt that the team work involved and playing to its strengths was key to their success. He said:

Speaking recently at the TeenTech Awards, presented at Buckingham Palace, HRH Prince Andrew said there needs to be a “culture of enterprise” to help young people turn technology ideas into commercial products and suggested that coding would be a key part of skills required. 

The Prince is patron of the Awards, which encourages young people to “recognise that science and technology are the basis of how we are going to be prosperous in the future”. The Awards competition which aims to encourage teenagers to get involved in inventing and designing was developed by science television presenter Maggie Philbin and backed by actor Stephen Fry and Top Gear presenter James May. 

Of course you’re screaming.. get to the good bit – WHY is Dr. Who involved??

 It was announced at the beginning of September that the British Broadcasting Corporation (BBC) had published computer programming study guides, quizzes and other support materials on its Bitesize site to coincide with the newly introduced computing curriculum in England. They have also revealed details of several programming themed children’s programs set to air late autumn.

 Uh-huh.. Dr Who???

Well my favourite initiative – as I am a total Dr Who geek*.. yes, you may laugh – was announced yesterday.

In an article featured in the Technology section, the BBC unveiled the launch of their new Dr Who game, in which you take control of a ‘friendly’ Dalek and navigate a series of challenges. Rather than just your standard game, the challenges involve you solving different problems using coding, to move onto the next level. 

The online game, aimed at 6-12 year olds, is voiced by Peter Capaldi, the Doctor himself and was written by Doctor Who TV series writer, Phil Ford. 

The game will be available to play for free on the CBBC website from Wednesday October 22 and I know I am going to be giving it a bash.. will you? 

Have you seen any interesting articles, blog posts or competitions lately, aimed at getting children into coding? Do share!

*JoJo Hernandez is our Finance Director, Fashion Lover & self confessed *Whovian! 

If you like to tinker with maths and are looking for more exotic operators, for example to calculate the Factorial or the Fibonacci series, then this is something you are going to have to implement yourself in LiveCode. But there is no need to despair, this can be done pretty much with a single line, wrapped in a function definition.

MATHS HAZARD – You may skip the following paragraph if you are not a friend of mathematical definitions.

The Factorial of a non-negative number n can be defined as the product of all of its positive integers that are less than or equal to n, with the Factorial of 0 returning 1. The operator for Factorial is denoted by an exclamation mark (!), allowing us to write the operation as follows: n!

The following example demonstrates how Factorial is calculated for the number 6:

6! = 1*2*3*4*5*6 = 720

Now this does not seem to be too much of an issue to implement or write, but how do you go about writing a function in LiveCode that does all the heavy lifting for you, so that you do not have to write a long sequence of multiplications?

Well, there are fundamentally two algorithmic approaches you could consider. These are iteration and recursion. They both operate in quite different ways and have advantages and disadvantages.

Let us look at the iterative approach first, as this is possibly the programming paradigm most people are familiar with. 

We create a function that takes an argument for which we are calculating the Factorial product. This function then cycles through all the positive integers that are less than or equal to the initial argument and multiplies all of these integers together. The function result is the Factorial result.

function factI x
  local tProduct = 1
  local tCounter
  repeat with tCounter = 1 to x
     multiply tProduct by tCounter
  end repeat
  return tProduct
end factI

Now in order to implement this algorithm we need two local variables and a repeat loop. This keeps track of the result as it is being updated through each iteration of the loop. But what if you really do not want to be bothered with local variables and loops and keeping track of data?

Well, meet recursion. Recursion can remember all the data that is specific to an instance of a function call. This means that we can pretty much throw most of the code away that we use in the iterative approach. Yes, we do not need local variables and we do not need a repeat loop. In fact, we can calculate the Factorial of a number with a single line of code in a function.

A recursive implementation usually contains some kind of condition check so it knows when to stop and when to call itself. This has been implemented in the following code using an “if then else statement”. If we are below a certain value stop, otherwise call the function again, but with a changed argument.

function factR x
  if x < 2 then return 1 else return factR (x - 1) * x
end factR

Now that was not too painful, but what is actually going on here that allows us to write code that is so much shorter?

Consider calculating 6! and let us expand how factR calls itself at each recursive level:

Level 1: factR(6)
Level 2: (factR(5) * 6)
Level 3: ((factR(4) * 5) * 6)
Level 4: (((factR(3) * 4) * 5) * 6)
Level 5: ((((factR(2) * 3) * 4) * 5) * 6)
Level 6: (((((factR(1) * 2) * 3) * 4) * 5) * 6)
               (((((1 * 2) * 3) * 4) * 5) * 6) = 720

Note: The parentheses demonstrate the execution order at each level and are not intended to be interpreted in a mathematical sense. The commutative law applies.

So this gives us a total of 6 calls to the function factR for 6! 

Another number sequence we mentioned in the beginning is that of Fibonacci. This sequence received its name from Leonardo of Pisa who published the historical mathematics book “Liber Abaci” around 1202. Leonardo of Pisa was also know by the name Fibonacci.

This Fibonacci number sequence starts: 1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,. . .

 This sequence has fascinated mathematicians for centuries and reveals remarkable patterns that are very much linked to natural structures, such as the formation of shells, branches and even the arrangement of the seeds in sunflowers. My particular interest is the use of the Fibonacci numbers for the close approximation of the Golden Ratio.

A Fibonacci number is generated by calculating the sum of the previous two numbers in the Fibonacci sequence. This operation is quite different to that used to derive the Factorial number sequence, never the less, it is possible to also wrap this into an iterative and recursive implementation.

Calculating the Fibonacci numbers iteratively requires additional local variables, compared to calculating the Factorial numbers. We step through all of the Fibonacci numbers and create the next ones by adding the previous two numbers together.

function fibI x
  local tFirst = 1, tSecond = 1
  local tCounter, tSum
  repeat with tCounter = 3 to x
     put tFirst + tSecond into tSum
     put tSecond into tFirst
     put tSum into tSecond
  end repeat
  return tSecond
end fibI

 In order to implement this algorithm we need four local variables and a repeat loop. As with the Factorial calculation, this keeps track of the result as it is being updated through each iteration of the loop.

The recursive approach can again do away with local variables and the repeat loop, creating the implementation as follows:

 function fibR x
  if x < 3 then return 1 else return fibR (x-1) + fibR (x-2)
end fibR

 Now I am not going to demonstrate how the recursive levels are expanded here and would like to leave this for the reader to explore. What I would like to add is that calculating the Fibonacci number for 6 calls fibR a total of 15 times.

Now recursion (or meta programming as it is sometimes referred to) is great as it can really reduce your code and hide a lot of the complexity, but beware. Some algorithms are better suited to recursion than others, and recursion can be computationally more expensive than iterative approaches. For example, calculating 20! calls factR 20 times, and that is great. Calculating the Fibonacci number of 20 calls fibR a staggering 13529 times.

Ah, the good ol’ Android Emulator….Many a support request has come in regarding this, mainly to complain of how dog slow it can be especially in comparison to the iOS simulator.

The main reason for the speed difference between both is that the Android “Emulator” is physically emulating the software and hardware of actual devices whereas the iOS “simulator” is only simulating the iOS operating system and has full access to all of the system resources (e.g. CPU, GPU etc)

With the above in mind, an Android Emulator is good if you’re starting with Android development or if you are in a pinch but ideally testing your application on a physical device gives you the best experience and doesn’t leave you wanting to pull your hair out.

With that being said, there is an alternative “Emulator” that I have used in the past and it has also recently been brought to our attention via support (Thanks Fulvio), which provides far superior performance compared to Google’s “out of the box” Emulator.

The software in question is Genymotion and is available to download from:

http://www.genymotion.com/

There are many versions available, but the Free version should provided you with everything you need to get testing your apps at super speed!

Now, its not a simple case of installing Genymotion and off you go, there are few things required in order to make this emulator work with a LiveCode built Android App. In order to save you from throwing your computer off the wall, I will now go through the GenyMotion setup step-by-step 🙂

Here we go:

1. The first thing you will want to do is download Genymotion and install it on your system.  

2. Genymotion runs an emulator within a Virtual machine with Virtualbox being the software that it uses for this purpose. So, the next thing to do is head over to https://www.virtualbox.org/ then download and install the latest release of Virtualbox.

3. We are now at a stage where we can run the Genymotion executable, so let’s do this.

Once launched, it will present you with the following screen. Select “yes”:

4. You will now be presented with the “Virtual Device Creation Wizard”. In order to create a new device, you will need to sign in with your Genymotion account. After you have signed-in, you will be presented with a list of emulator copies of all of the latest Android Devices.

5. For simplicity, I am going to create an emulator using the first option of “Custom Phone- 4.4.1-API 16 768 x 1280”. So I select this, and press “Next”. This then allows me to name my emulator, I leave the name as its default value and press “next” again. This will then proceed to download this emulator for use:

If all goes as expected, a “The virtual device has been successfully created” message screen will appear:

6. After the device is created, press “Finish”. This will take you back to the “Your devices” screen. From here, you can select your device and press “Start”:

7. After around 10 seconds of loading ( Retina MacBookPro), the emulator is up and running and oh my…..is it fast!

8. Now fire up LiveCode, and if you already have this setup for Android development and have a stack open which has its deployment platform set to Android, you should see the Genymotion emulator in the list of “Test Targets”..so good, so far 🙂

9. Now…try to deploy your stack to the emulator… uh oh….”Houston, we have a problem”

The error that occurs in the emulator is due to the incompatible architecture that a LiveCode built Android APK uses. LiveCode builds ARM based Android standalones (as around 99% of Android devices use this architecture) whereas, Genymotion is built on x86 architecture.

Don’t worry, I haven’t strung you along and there is a solution to this which involves installing an ARM translation library. All of this is explained in the following XDA developer post-

http://forum.xda-developers.com/showthread.php?t=2528952

With the main steps we need being 1 – 4

So basically, you have to download the ARM translation installer zip, drag it onto the Genymotion emulator, accept the flash and restart the emulator after the flashing has finished. (to restart, simply quit the emulator and re-launch)

10. Now if everything has went as planned, you should now be able to deploy to the emulator from within LiveCode 🙂

TAADAA! Here we have Sheepherder running in Genymotion with the performance being on par with any physical device.

Thats it! I hope you find this useful when it comes to testing your LiveCode Android Apps along with making  your Android development a more enjoyable,fun and stress free experience 🙂

Please let us know how you get on in the comments below or if you have any other emulator related tip/tricks