I really enjoy writing tests. It’s great to ensure that a new piece of functionality will never be broken, or that a bug will never be reintroduced. It’s doubly satisfying when something previously untestable becomes testable, when a certain level of struggle or ingenuity is required to work out how to test something, or when a test is particularly (perhaps even maximally) succinct.
read moreFixing Bugs
by Panagiotis Merakos on April 14, 2014 3 commentsThe in-app purchasing feature I was working on during the previous months is now finished, and is available in LC 6.7 DP1. So, in the meantime, before moving to a new project, I had the chance to do some bug-fixing. It was my first exposure to bug-fixing, and I have to admit that it was more interesting than I imagined! To begin with, I started browsing our bug database in the Quality Control Center. The steps for fixing a bug are three: reproduce – find where it comes from – fix!
I thought that as a beginner, I should start with something relatively easy, so I tried to sort out some crash-related bugs. I believe these are easier to fix, or at least easier to reproduce and find the exact line of code where the crash occurs. This can be done by trying to run LC in the IDE with the debugger active and see what line of code it stops on. Well, this isn’t necessarily the line that contains the bug, but you know you are close! If you step backwards, you will find where the actual bug occurs. Using this method, I fixed a couple of bugs. Not surprisingly, modifying the same single line of code, fixed three different bugs that at a first glance seemed unrelated.
The next category of bugs I tried to fix were the “platform-specific ones”. In this kind of bug, the LC functions that were reported to misbehave, usually communicated with particular System functions that were deprecated. The fix to these bugs required more time. I had to search the web for the new up-to-date System functions, and replace the deprecated ones.
After that, I felt I was ready to face some harder bugs! I tried different categories, android orientation-related bugs, engine architecture-related bugs, engine objects-related bugs and some more. When I could not fix a bug, I tried to post a helpful comment or provide a workaround. In any case, either being successful in resolving these bugs or not, I enjoyed it because it gave me the opportunity to gain a deeper understanding on how the engine works. Moreover, I was impressed with how much attention to detail the LiveCode users that reported some bugs pay! I remember a bug where the user had reported that in a specific version of LC, the “unlock cursor” command delayed by one(!) pixel, meaning that when you unlock, the cursor had to be moved a pixel (at least) for the change to take effect. Impressive!
read moreThe pains of integration
by Michael McCreary on March 24, 2014 4 commentsThe price of a ready made curry at the local supermarket has gone down. This is a good thing. The portion size of a ready made curry at the local supermarket has also gone down. Out of proportion to the price drop. This is a bad thing. And it’s what I’m attributing the yelps of anguish to that can be regularly heard around the RunRev office at the moment.
Or it could be the pains of integration. You see, several long running projects are now coming together. And this means integrating several months of hard work into a single LiveCode installer. Which is far, far harder than you can ever imagine. The build process is almost entirely automated. But due to the complexity of the process and the number of platforms to support, there are so many points at which it can fail. And as soon as you solve one problem, several others appear to take its place.
It’s these final steps that developers find so frustrating. After months of implementing new features, you think the all the hard work is done. But in reality, it’s only just begun. It’s almost enough to force developers to get up and microwave their own curries.
The dreaded rebuild
We have an automated test system that we run on all new builds. This ensures that all releases we put out are of the highest quality. This is a good thing. The test system has a habit of spotting critical bugs moments before we’re about to push the release button. This is a bad thing. Especially if it’s last thing on a Friday. Often, the fix itself is trivial. But the dreaded rebuild that follows is usually not.
Dependencies are supposed to make the build process smoother. But it seems they fail when you most need them: Fraser once told me that if you so much as look at libSkia funny, it will decide a full rebuild is needed. I believe him. We have a dog in the office named Pancake and she’s always looking at me funny. I can only assume she gives the same treatment to libSkia. I’m not laying blame though. I think that’s just what her face looks like.
The future
Within the next few months several new and exciting versions of LiveCode will be released. This is a good thing. For the next few months, us LiveCode developers will be spending all our time fixing bugs and refining features. Well, this is a good thing, for you at least…
read more
Recent Comments