Recently, I’ve been occupied with shipping out LiveCode 7 branded T-Shirts to purchasers of our special 7 launch bundle. Visualising all you guys and gals unpacking the parcel and wearing the T-Shirt got me thinking about what people wear, why, and how it affects their day to day activities. 

While we were designing the T-Shirt, I discovered that some members of staff have strong views about what kind of shirt they will wear, and what they won’t. We do have the full spectrum here in the team, from staff members its an effort to persuade to wear at least something without holes in, to those who would not be seen dead in any kind of T-Shirt and don’t own a pair of jeans. We have a  “Smart Casual” official policy for our staff, which I think is a kind of extension of our company culture, and reinforces our desire for a workplace where people are creative, comfortable, and valued. Having staff turn up wearing scruffy jeans and baggy tshirts leads to a general air of disreputableness and disrespect, but insisting on a shirt and tie every day would make most of our development team very uncomfortable.

However, I myself and many of you, our users, work from home. Does it matter what I wear? Or what you wear? I think it does. Theoretically, I could sit here at my computer wearing a dressing-gown and slippers, and none of you would be any the wiser (aside from the risk of a sudden Skype with video).  In practice, I dress if not as formally as I would for the office, at least respectably. I don’t feel I would do as good a job if I did not dress for it. It would be a very interesting experiment to run! So interesting that a little googling finds that studies have in fact been run on this question. Enclothed Cognition is the term being invented for the concept. Apparently wearing a doctors lab coat while performing intelligence tests results in better performance – but only if you are told it’s a doctors lab coat, not if you think it’s an artists jacket.

Which brings me on to my thoughts on confidence. Dressing in clothes you like gives you more confidence, which you then are able to project onto your work and your interactions with others. Confidence is attractive therefore you look and work better in clothes you like. So, if you like our LiveCode 7 T-Shirt, you’re going to look great wearing it! Care to send us a photo? 

What do you think? Does it matter what you wear? If you work at home, do you dress up for work? 

I recently read this article, which had me chuckling for a week. Do read it, it’s brilliant. But it got me thinking. Really, the LiveCode offices are not your typical place to work, and LiveCode is not your typical programming language. It’s Easier with LiveCode.

Our development team are a pretty happy bunch overall (unless they’re faking it really really well!). I think this is down to a number of things. We expect you to work hard, but we also listen to your input, and there is a certain amount of flexibility in the working hours. Some members of our team regularly spend a day working from home – others prefer always to work from the office. We have monthly whole team meetings, where every member of the company presents their work for the month. This leads to a feeling of inclusiveness – I may not always understand Mark Waddingham’s presentation but I have at least a vague idea of where the tech is heading! Equally, the tech team gets an overview of what is happening in marketing or customer support.

Pets Galore

Possibly the relaxed atmosphere is assisted by the Office Dogs.

Developers in Training?

I frequently get asked why the servers running our hosting service have such odd names. Meg, Diesel, Tio, Jasmine, Pancake … what’s that all about? Well, they are the names of the office pets. A number of members of staff have pets who regularly come in to the office, providing entertainment and light relief. Your code not doing what you wanted? That bug proving intractable? Spend a few minutes playing tug of war with Tio, or throw the squirrel for Meg, and the problem may magically resolve itself. No, I cannot tell you why Arnaud’s cat (now sadly deceased) was called Diesel. You’d have to ask him that.

Programmers and Beards

An interesting phenomenon – almost all of our team have beards. And some have an uncanny resemblance to each other. I’m not sure why this is, does coding attract this genotype, or does working in code all day cause long hair and beards?

Spot the difference: Ali Lloyd and Sebastian Nouet.

We’re a creative bunch, and coding after hours for the sheer joy of it seems to be the norm, rather than the exception. A case in point – shortly after coming to work for us, we discovered that Fraser Gordon had a love of Raspberry Pi… to the point where he had picked up the embryonic LiveCode implementation for this platform and turned it into something useable, in his spare time. Way to go Fraser – don’t forget to sleep sometimes.

Yes, its definitely not a typical place to work. But friendly, fun and awash with creative atmosphere.

We’re hiring

Do you like dogs? Love working long hours for a deadline? Got some serious Programming Experience and credentials? Have a beard? Apply here.

This afternoon, for one reason and another, I am temporarily disconnected from the internet, and I’m finding it pretty traumatic. I’m using the time to write a blog post, but even this simple activity is hampered by my inability to look up things online, check my facts on Wikipedia, and locate suitable images to illustrate my points.

Which really is the point of today’s post. Our lives these days are governed by connections and many of the apps we write can be seen as collections of information gathered, often live, from the wonderful world wide web at our fingertips. So many apps are data driven, grabbing information as it is needed and serving it up to the end user, hot from the grill. For example, my desktop calendar has of its own volition located the calendar on my phone and now startles me daily by popping up notifications and reminders when I least expect them. In my defence, some of these events were not even entered by me, they are events created by other users whose calendars talk to my calendar, which then talks to my phone and reminds me I should now be somewhere entirely different, doing something I wish I had been allowed to forget about. Push notifications in action. Terrific.

LiveCode is excellent glue. It’s great at sticking together content from a wide variety of sources and making it available in one place (your app) in a tidy way (your lovely app interface) so that the end user gets a beautiful seamless experience. At one end of the spectrum you could pull together images from a users camera, data from a website, messages from other users and create, perhaps, a fabulous recipe app that lets you take a picture of the meal you created and share it with friends. Or at the other end it could be used to create a heavy duty app for crunching through masses of data and finding trends or specific information, with its easy database connectivity. Big Data is Big Business and LiveCode is good at it.

I find all the uses that our users find for LiveCode fascinating. These days, the apps created are rarely isolated self-contained items, they are part of our interconnected lifestyle, and participating to a greater or lesser extent in the huge global network that is the World Wide Web.

You could say LiveCode is truly live.

6.1.2 Released
We are pleased to announce the release of LiveCode 6.1.2. This is a stable release containing more than 30 bug fixes and support for xCode 5.0 and iOS 7. We would recommend all 6.1 users upgrade to this release. It is available for both Community and Commercial users. If you have a Commercial 6.x license this release will have automatically become available in your LiveCode account.

The principle reason for existance for this minor point release is to add support for the latest iOS, however as usual we have taken the opportunity to fix various issues and squeeze in a number of enhancements for your delight. Here’s what 6.1.2 has for you.

Engine Changes

iOS 7/Xcode 5 Support
Support has been added to the engine and IDE to allow for iOS builds using Xcode 5.0. This means that OS 10.8 users (required by Xcode 5.0) will need to have Xcode 5.0 installed and set up in LiveCode’s preferences in order to produce Arm v7 builds. Arm v6 builds will still be produced using Xcode 4.4 (the last version to support Arm v6).

The table below details the versions of Xcode LiveCode requires on each platform to produce the given build type. In order to produce universal builds both the Arm v6 and Arm v7 Xcode SDKs will be required.

In addition to the above, the new iOS 7 icon sizes can be specified in the standalone builder. They are sized as follows:

• Retina iPhone: 120×120
• iPad: 76×76
• Retina iPad: 152×152

Better Quality Printing on Mac
When printing on Mac, two things have been improved. The first is that semi-transparent groups (with default ink – copy / srcOver) will render directly rather than being rasterized first. The second is that PNG and JPEG images will pass their data directly through to the printer driver. The end result is that scaled images will print at higher resolution than they did before in many more cases.

URL Operations Sometimes Fail on Android
There is a bug in the Android Java HTTP layer which can cause URL operations to fail (https://code.google.com/p/google-http-java-client/issues/detail?id=116). This problem seems to be related to keep-alive connections, thus until this bug is addressed in Android the engine will now turn off keep-alive on startup.

Support for Arm V6 iOS Builds Dropped
The earliest version of iOS supported by LiveCode is 4.3. Since iOS 4.3 only runs on Arm v7 (and newer) devices, support for Arm v6 (and subsequently universal builds) has been dropped. This has in turn simplified the versions of Xcode a user needs to have installed in order to perform iOS device builds:

Applescript Now Works on LiveCode IDE
This issue has been fixed. It was caused by incorrect naming of the rsrc file – it was LiveCode.rsrc rather than LiveCode-Community.rsrc or LiveCode-Commercial.rsrc. (The name of the rsrc file has to match the name of the executable file within the bundle).

Key Code Parameter to RawKey Messages No Longer Always Zero on Mobile
The rawKey messages will now give pass the ASCII code of ASCII characters to rawKeyDown/Up when pressed. This is consistent with the Desktop’s handling of the rawKey messages.

Spaces No Longer Required in Date Formatting
Date format string parsing has been made less strict in its processing, now collapsing one or more spaces together to allow a ‘ ‘ in a format string to match one or more input spaces. Additionally, spaces in the input after a formatting specifier was successfully matched are ignored. With these changes, both “10:41 PM” and “10:41PM” are accepted as valid times; previously, only the former was acceptable.

Caseless Comparison Now Working Correctly on Linux
For Linux distributions having their locale set to something other than ISO8859-1, caseless comparison was not working correctly. This has been fixed.

Ensure Caseless Comparison Works on Linux Server
This problem was fixed on the Desktop as Bug 11160 and has now been iterated to the Server build.

Offline Activation Now Working in Ubuntu
The installer now does not offer to launch LiveCode after installation as root (e.g. via su or sudo) on Linux in order to prevent the product from creating its activation files with the wrong permissions. Instead, LiveCode should be launched in the normal way after installation and activation occurs then.

A full fix list and more details can be found in the release notes for this edition, here.

For more news and articles this week please visit our newsletter, revUp.

Reprinted from revUp, read the rest of our twice monthly newsletter here.

When I work in other languages I’ve come to depend on version control to help me keep track of everything. I would like to see the same productivity increases and extra documentation trail that version control provides in my LiveCode projects. Unfortunately LiveCode files are a binary format which is great if you want to pack a lot of data into a small space but not so great if you want to have a version control system work out the difference between two versions of a file. Most version control systems will just decide if a file is text or binary and if it’s binary just treat any difference as a merge conflict.

It is possible to install additional drivers for these systems to deal with binary files or structured data like xml in a better way than line by line processing. Unfortunately hosted repository sites like GitHub and BitBucket would still see the files as binary so we wouldn’t gain benefits like being able to comment on specific changed lines in a script. Apps like SourceTree (Atlassian’s Git/Mercurial client) also wouldn’t be able to show us the differences. So we need a text based file format.

The lcVCS repository in SourceTree (click to zoom)

Towards the end of last year (I’ve been working on this for a while) I decided I would try and crack this nut. Along the way the project (lcVCS) has been a driver for me to do some work on the LiveCode engine including `_internal resolve image`, `the childControlIDs of group|card`, `the cardIDs of group`, `the properties of object` and `is an ascii string`. Additionally I’ve filed half a dozen bug reports on obscure issues that may not otherwise have been identified such as the minuscule rounding error on gradient ramps I found recently. As a result it requires version 6.1.1 of LiveCode.

At first I took a look at what had been done before. Mark Wieder has done a considerable amount of work on this issue with exported stackFiles saved as XML with a directory structure mirroring the stackFile hierarchy. I made contact and told him I was looking at the problem and he has offered a wealth of advice and been my goto guy on this ever since.

I was inspired by Vincent Driessen’s article ‘A successful Git branching model’ so my focus since the beginning has been to ensure we can have multiple development branches of a LiveCode project open at the same time. That means we need to be able to merge these branches so that changes on both are kept. Mark’s work had proved you could reliably export and import a stackFile. When I came to look at the merge issue, however, I hit some rather large roadblocks.

The first and arguably the easiest to overcome is the fact that stackFiles save everything including things that will almost certainly cause merge conflicts like the rects of resizable stacks, text in fields from your last test etc. So if you have two branches of a project and in both you have resized a resizable stack you would have a merge conflict on that… heaven forbid you have a resizeStack handler! My solution was to dispatch a message to each object just before it is exported so it can reset itself to default settings. In practice I usually handle the message in the card script. Anything that is pure session data should be cleared or reset to its default state. Messages are unlocked while the handler is run so your resizeStack handlers or anything else can execute.

The second major issue is one I’m still struggling with. LiveCode objects each have an ID. The stack ID is actually a place holder for the next object ID to be used on a stack. So IDs in stacks are akin to an auto-incrementing primary key in a database. The problems arise when we have multiple branches of the project all creating objects. In each branch the stack is assigning the next available ID. ID’s are a very common way to refer to objects, for example, an image ID is used as the icon reference in a button. So when merging branches of a project we need to ensure that the merge is robust to ID conflicts.

In lcVCS I’ve handled this by assigning every object a UUID (Universally Unique ID) which is basically a random number so large you would need to generate a billion UUIDs a second for 36 years to have a 10% chance of a conflict. Object references are translated into UUIDs to export the stack and when imported they are translated back. This process allows lcVCS to gracefully handle different objects on different branches having the same ID by allowing a new one to be assigned to one of the objects and updating any references to the object.

Unfortunately this isn’t a simple problem. Not only are IDs used as icons, patterns and behaviors they are also often stored in custom properties. For example, the DataGrid stores it’s row template as an ID. To work around this issue I implemented a plugin scheme so that anyone that has a control or library that stores IDs could add support for their custom property set in lcVCS. One day I hope there will be an engine level solution to this problem but I doubt we will see that for a while.

A related issue is when you have a project with multiple stackFiles you need to ensure that they are imported and exported in the correct order so that everything is found. To deal with this I’ve implemented a project file that maintains an ordered list of the stackFiles in your project.

Lately I’ve been working with Trevor DeVore on Clarify 2. Trevor has been very supportive of lcVCS and Clarify 2 is pioneering the use of it on a more complex project than lcVCS itself (lcVCS exports and imports itself which is fun). One of the things I found is that deeply nested groups can create very long paths in a directory structure that mirrors the stackFile hierarchy. On Unix based systems this is fine but Windows can’t handle paths longer than 260 characters so I had to redesign the directory structure to be much shallower. My hope is that the change was the last major re-design lcVCS will need (it’s had many!).

It’s interesting that when you decide to solve one problem you often end up solving others too. Both lcVCS and the mApp framework are LiveCode plugins. I needed to both use the plugins and work on them and the idea of moving the stackFiles from the plugins folder into their Git repositories every time I wanted to export and commit didn’t appeal so I looked for another solution. When I implemented the project file system I found a solution there by allowing the build path to be outside the repository. lcVCS can now import projects directly into the plugins directory or any other directory for that matter. It then dawned on me that if I provided an easy way for users to search for lcVCS projects, install them locally and to switch between branches or tags in the repository that I would have a great way to deliver open source plugins and libraries. A bit of Googling and I found GitHub has a search API, I could search for the lcVCSProject.json file and it would return all the public lcVCS based projects on GitHub. A few shell calls to Git and I had a list of tags (often version numbers) and branches to put in a switch to button.

lcVCS GitHub search (click to zoom)

So now lcVCS is both a way to help you version control your app, plugin or library and a way to deliver your open source plugin or library into the hands of other LiveCoders just busting to help you out with a contribution or two.

The lcVCS project is open source and licensed under the GPL 3 and is available on GitHub. Because lcVCS imports itself you will also need to get the current versions of the stackFiles which are available from the downloads page under a free or paid account at mergExt. The simplest thing to do is get the stackFiles then add lcVCS as a project so that you can update it as new versions become available. You will also need to install mergJSON (also available under a free or paid account) which is the super fast dual-licensed JSON parser external lcVCS is built on. While you’re there why not check out what mergExt can offer for your apps?

If you’re interested to start using lcVCS I am available for hands on consulting to help you and your team get up and running. There’s also some rules your project will need to follow in order to successfully transition:

If you use IDs in scripts anywhere (such as setting the icon of a button) then replace it with a name based reference.

Implement lcVCSExport handlers to ensure everything is set back to defaults during the export.

If you have any custom objects or libraries that maintain custom property sets that store IDs then implement a plugin to support it. The plugin api is quite simple and there’s a number of examples demonstrating their use. If possible contribute the plugin back to the project so we can maintain them centrally.

Limit object references between stackFiles where possible. Where it’s not possible ensure that there are no circular references. For example, stackFile A has an object reference to an object in stackFile B while stackFile B has an object reference to an object in stackFile A.

Order your stackFiles so that the stackFiles that have object references to objects in other stackFiles are imported and exported after the stackFiles they refer to. The stackFiles list in the lcVCSProjects stack can be re-ordered by drag and drop.

If you have object references to objects that no longer exist (such as icons referencing deleted images) clear the property.