A CodeFlow blog

about live coding and more…

CodeFlow 0.9.12 adds auto-completion


One feature that was missing to CodeFlow until now was true auto-completion of Lua code, i.e. code completion proposals appearing automatically as you type your code, without having to hit the esc key first. Automatic code-completion is probably one of the most important editor features for bringing more comfort and effectiveness to the code-writing experience, and it has been on my to-do list for some time.

And this is precisely the main new feature of the just-released CodeFlow v0.9.12. In this version, code completion proposals appear while typing code, and they can usually be validated with a minimum number of key presses: typically, when the appropriate completion is selected, you can just continue entering the code after the completed word, like in this short example.

And, if you don't like it, automatic code completion can be disabled in the application preferences.

On the debug side, the Lua command editor also features automatic code completion, but there is more: code completion the Lua command editor is now aware of the current callstack-context . What this means is that, when stopped on a breakpoint, you can very easily write commands containing local variables or other symbols available at the line where the selected callstack level is stopped, without worrying about not misspelling variables or method names, as those will be proposed by auto-completion.

And the code editor behavior in case of syntax error in a Lua file has been improved too: code completion now takes into account field and method names defined after the error location; syntax-aware selection, code coloring and variables highlights, all work in the whole source file in case of syntax error. All this is really useful, because transitory syntax errors are quite inevitable when writing code, or dynamically modifying existing code in live coding mode!

As usual, CodeFlow v0.9.12 can be downloaded from celedev's support page or by using the software-update check feature in CodeFlow.


celedev sponsor of mdevcon 2015


mdevcon logo

mdevcon is a great mobile developers conference that takes place every spring in Amsterdam. It focuses not only on iOS, but also on Android and other mobile platforms. The location in Tuschinski Theater in the center of Amsterdam is fantastic, there are plenty of very good talks during the two days of the conference, and with the organization in multiple tracks, you can always find at least one you are interested in.

And, even more important, attendees and speakers are very friendly and passionate about development. I was there last year and I had great conversations with many people during the breaks and evenings.

This are probably the reasons why mdevcon has been put by Ray Wenderlich in the Top 10 iOS Conferences in 2015.

And I'm very pleased to announce today that celedev is a sponsor of mdevcon 2015. If you can come to Amsterdam on March 5-6 2015, mdevcon is definitely worth attending, and I will be happy to meet you there!


CodeFlow 0.9.10 improves debug features


It has been almost two weeks since I released CodeFlow 0.9.10 and it is more than time for me to write a few words about the changes in this version.

CodeFlow v0.9.10, that can be downloaded here, is mostly focused on improving the debug experience when developing code in Lua.

The Lua Command Editor can now interpret commands in the context of the currently-selected call-stack frame. This means that the Command Editor can execute virtually any sequence of Lua code, that would be valid at the current line of the selected call-stack function. Executed code has read / write access to all variables visible at the current source location: this includes local variables, up-values, var-args and free names (i.e. Lua env-aware globals).

CodeFlow also features an improved Variables Inspector that displays more information about the current state of your program: it allows the visualization of masked local variables, and the display of custom Lua environments. In addition, the Variables Inspector now includes a simple type-aware variable editing capability, and other small improvements that make it easier to use and very reliable.

I will illustrate these debug features with a simple screenshot of a test program:

CodeFlow 0.9.10 new debug features

Here the execution is stopped at line 23 in a function named square, where a lot of variable masking takes place.

Variables Inspector

To start with, the function defines a local environment on line 12, that masks the inherited _ENV up-value (that was set at line 4); you can see in the Variable Inspector that the masked _ENV up-value is dimmed but still accessible, and you can easily identify the active _ENV, which is a local variable.

In addition, many variables in the square function are named x. This is really confusing and certainly not a good programming practice, but this is still syntacticly-valid Lua code. Fortunately, the CodeFlow Variable Inspector will help you to clarify things.

The last x in the list is not dimmed, so it is the active variable x; its value has been modified by the last step in the code, as indicated by the yellow highlight on the Craig value. Other variables called x are dimmed, so they are masked; you can locate any them precisely in the source code by selecting it in the variable inspector, like here thexwith value Bob: we can see that it is set on line 21 and never read.

Lua Commands

Now, we can have a look at the Lua Command Editor, in the Lua Console pane. The Lua Console title indicates the context in which the command will be executed, here in function square, line 23. The code of the command is colored appropriately for this context, so it is easier to detect typing errors: you can see that huge and print are colored as up-values, and x is colored as a local variable, which is precisely what we expect.

What happens if we execute the command?

CodeFlow 0.9.10 new debug features

We can see that the values of variables huge and x have been modified (highlighted in yellow), and the console output contains the string printed by the command, with the right value for x.

Other improvements

In addition to these debug-related improvements, CodeFlow v0.9.10 fixes a number of bugs in various parts of the system and improves the reliability of the connection between CodeFlow and target iOS device running the application.

Read More

When Swift meets Lua


The recently-published RedMonk Programming Language Rankings for Q1 2015 provides interesting figures about the relative popularity of programming languages. Stephen O'Grady writes about it:

The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion (Stack Overflow) and usage (GitHub) in an effort to extract insights into potential future adoption trends.

Probably one of the most significant trend in this ranking is the fantastic growth of Swift, the brand new language that Apple introduced at WWDC 2014. In just over seven months, Swift has jumped from nothing to rank 22, and is now at parity with Lua (at rank 23).

RedMonk Top Programming Language Rankings

It goes without saying that this ranking parity between between Swift and Lua is temporary, and we can expect Swift to continue raising in the future rankings.

Nevertheless, having Swift and Lua at parity is an nice coincidence, because Lua is the language we use for live-coding iOS applications in CodeFlow, and more interestingly because both Lua and Swift are two great programming languages that show almost opposite design choices in many areas, and turn out to be very complementary and effective in the job of developing iOS apps.

To illustrate this, let's compare Lua and Swift on a few key aspects.

Simplicity vs. complexity

One thing I like about Lua is the simplicity of the language: the entire Lua 5.2 grammar fits in about 50 lines (or 2 pages in a book). This makes the language really easy to learn, and very logical and pleasant in the daily use. Sure, Lua does not have many fancy language constructs, but everything you need is there, and Lua code tends to stay reasonably concise. And on the performance side, this deliberate minimalism helps to keep the Lua compiler and runtime small and fast, which is a valuable quality for an embedded language.

For Swift, the design team has chosen the exact opposite option: build into the language a large set of syntactic constructs, in which you can almost always find one that fits your needs in a given situation. This makes Swift a very powerful language, and most iOS developers I know are really excited about Swift. But it comes at the price of a high complexity: the Swift grammar takes 20 pages in the book The Swift Programming Language and learning Swift is not a matter of one day or two.

A complex language needs a complex and clever compiler, and Swift is no exception to the rule: Apple has certainly put a massive effort on the Swift compiler, capitalizing on the work they did for llvm and clang, and Swift code execution performances rely heavily on compiler optimizations, as shown by many benchmarks on the web comparing Swift and Obj-C performances in debug and release modes. The language sophistication and its needs for code optimization result in a more CPU-demanding compilation and in a probably higher memory usage by the compiler. But for a compiler designed to be used inside Xcode or from the command line, and not supposed to be embedded in a target application, this choice is fully consistent and (reasonable) CPU/memory consumption is not an issue in this case.

Dynamic vs. compile-time decisions

Lua is a dynamic language, meaning that most decisions that affect the code and data structure of the program are made dynamically at runtime, instead of being pre-calculated during the compilation. For example, Lua's main data structure, the Lua table, is a dictionary that doesn't impose any restriction on the types of acceptable keys or values; it is therefore possible at any time to add a property or a method to an object defined as a Lua table. Another example: when compiling a Lua code chunk, Lua doesn't need any context information about this code chunk's source code dependencies; the result of the compilation is just a regular function that can be stored in any variable or called immediately, as decided by the program loading the code chunk.

This dynamicity brings to Lua the same advantages and issues as in other dynamic languages: a huge freedom and flexibility in your code, which is especially great for live coding, but almost no static check to help you detect obvious errors in your code before executing it.

Swift, on the other hand, is all about compile-time checking and ensuring the safety of your code as much as it can. Which is really good for the safety of your code, and probably not so good for your creativity, since it obliges you to make your code base fully consistent before you start executing it.

Therefore the Swift compiler needs lots of context information when compiling a source file, like the definitions of all external entities used by the compiled source code: modules, other classes... All this information helps the compiler to generate better optimized code than in a dynamic approach. But when the code is running, you can not set a property to an object or change a method in a class (or at least not with the language).

Of course, Swift has some dynamic features, like optionals (variables that can be nil), the AnyObject type (needed for Obj-C interoperability), or failable initializers. But compile-time checks are really at the heart of the language. And especially aspects related to type-checking...

Variables vs. values typing

For the developer, probably the most visible difference between Lua and Swift is the way they handle typing.

Swift relies on variables typing. Swift has a strong, but rather classic, object-oriented typing system, and an important part of Swift compile-time check rules are related to guarantying the consistency of variables usage with the corresponding variable declaration types.

On the other side, in Lua, variables are not typed, only values are. Which mean that every value belongs to one of the 8 base types defined by Lua, and that a value always carries its own type with it. A Lua variable is simply a neutral container that can accept a value of any type. This is very flexible, but it puts on the developer's shoulders the task of checking the actual type of a variable, where necessary in the code.

Similarities

Actually Lua and Swift are not opposite in every aspect. On some points, they are even quite close. Here are some examples:

  • None of them is derived from C, so they do not suffer from C major flaws: Lua syntax was originally inspired by Niklaus Wirth's Modula languages, and for Swift, its designers made the courageous and excellent decision to drop C compatibility, and to create a brand-new safer state-of-the-art programming language.

  • Both include a certain level of extensibility in their syntax: in Lua you can do rather important customization (e.g. defining your own object model in Lua) through the clever use of metatables and metamethods; in Swift, language features like operator overloading, custom operators and generics give you the ability to extend the language syntax.

  • In both, functions can have multiple return values: in Lua, a return statement simply accepts a sequence of expressions, e.g. return a, b, c, which is fully consistent with Lua multiple assignment syntax; in Swift, a function can specify multiple return values by specify a tupple as result type, and then use return (a, b, c).

  • Both do not require semicolons at the end of instructions, but accept them to force statement separation if needed.

Beyond the language

The object here is not to claim that Lua is better than Swift, or Swift better than Lua. That would obviously be pointless, as both are great programming languages. What this short comparison shows, however, is that Lua and Swift have strength in different areas, related to their respective philosophies, design choices and implementation tradeoffs.

And actually, the programming language is only a part of a bigger development picture. Another important part of this picture is the IDE. The main role of an IDE is not to provide a text editor showing fancy colors in your source code; it is to make your whole development activity easier and more effective.

To achieve this goal, good IDEs include features that compensate for the main limitations of the programming language used. Examples of this can be found in our preferred IDEs: Xcode has the Playground for Swift, that allows you to interactively develop and experiment simple Swift programs; and CodeFlow adds extensive runtime checks to Lua when invoking native methods, that brings type errors detection and preserve the stability of the target app during live development.

Playing with Swift or Lua

If you want to go further and make up your own mind about both languages, here are some valuable resources:

  • For Swift, you can go to Apple Swift Resources page, where you will find lots of documentation and the download link for Xcode, in case you don't already have it. Then create a new playground in Xcode and enter some swift code in it.

  • For Lua, various language documentation can be found on lua.org, and my personal IDE recommendation for writing Lua code is to use CodeFlow, even if you don't target iOS apps. CodeFlow can be downloaded here, and it can be freely used as a pure Lua playground. To do this, create a new Lua project in CodeFlow (Menu File->New) and, in the project window, select the Local Lua Context target to run and debug the code locally inside CodeFlow.

    Local Lua Context in CodeFlow

Read More

CodeFlow 0.9.9: the power of structs


0.9.9 is a great version number for a software. And this is precisely the version number of the new CodeFlow beta, available since yesterday in the downloads section of celedev website.

What is new in this version?

  • Major improvements in the use of C structs from the Lua code: CodeFlow now supports an object-oriented syntax for structs, that makes the code more concise and readable, and enables you to very easily define your own struct methods. This new feature is described in more details below in this post.

  • A better bindings libraries management adapted to the various iOS SDK versions available on the host computer. In particular, CodeFlow can now automatically select the default SDK corresponding to the version of Xcode installed on your development machine. And if you select a specific SDK for your CodeFlow project, CodeFlow will open the associated Xcode project with the right Xcode version for this SDK (on OS X Yosemite only). Really convenient for testing projects that use a beta iOS SDK version!

  • The fix of several problems that could make CodeFlow crash under OS X 10.10 Yosemite.

  • And of course many smaller improvements and bug fixes.

CodeFlow Bindings libraries adopt a new format with this version and need to be updated. In addition, CodeFlow Bindings for iOS 8.2 SDK have been upgraded to match the beta 2 SDK version released by Apple a few days ago.

A new version 0.9.9 of the CodeFlow Sample Applications Package is available too. It includes a new application WatchApp1 that shows how to use CodeFlow to develop an Apple Watch app, and updates of existing applications to illustrate the use of structs with the new object syntax.

[Edit 18 Dec. 2014 22:45 CET] As Apple has just released Xcode 6.2 beta 3, CodeFlow Bindings for iOS 8.2 SDK have been updated to match the iOS 8.2 beta 3 SDK. So has the WatchApp1 CodeFlow sample application, which is now compatible with API changes in WatchKit in iOS 8.2 beta 3.

Using structs in Codeflow

Structs are used heavily in C / Objective-C APIs and the iOS SDK is no exception. Data of struct types, like NSRange or CGRect, are used as parameter or return value in many functions and methods of the SDK. To make the use of these functions/methods possible and practical from the Lua code, CodeFlow supports, since many versions, the transparent conversion from a Lua table to a struct parameter, as well as the reading or writing of struct data fields from Lua.

For example:

local myView = self.view -- self.view is a UIView

-- set a struct value with a Lua table
myView.center = { x = 100, y = 256 }

-- use a struct value in Lua
local center = myView.center -- center is a reference to a C struct
center.x = 50 -- set a struct field
print ("The center is (" .. center.x .. ", " .. center.y .. ")") -- get struct fields

In addition to this basic support, CodeFlow 0.9.9 adds two new tools: struct constructors and struct methods: constructors allow the creation in Lua of a struct with a given type, without necessarily creating it from a Lua table; struct methods provide an easy way to manipulate structs or to get information from them, using a unified syntax with objects, and as a result, improving the code consistency and readability.

All struct types known by the program are stores in a global Lua table struct, that provides a specific namespace for struct types and avoids collision with other Lua global variables. The list of types in the struct table can vary from program to program, as it depends of the frameworks used by the CodeFlow project. For example, in the WatchApp1 application, that uses MapKit, Foundation and CoreGraphics, struct contains the following types:

Struct types in the WatchApp1 app

Struct constructors are used like this:

local CGRect = struct.CGRect -- using a local variable makes the use of CGRect more concise and improves performance in the rest of the code

-- create a CGPoint value with the list of its fields
local point1 = struct.CGPoint (0, 150)

-- create a  CGSize value with a Lua table
local size1 = struct.CGSize {width = 200, height = 100 }

-- create a CGRect value with the list of its fields
local rect1 = CGRect (point1, size1)

-- create a CGRect value with the list of its sub-fields
local rect2 = CGRect (50, 65, size1.width, 500)

-- create an empty CGRect (with all fields set to zero)
local rect3 = CGRect()
rect3.origin.x = 10
rect3.origin.y = 15
rect3.size = rect2.Size

Struct methods can be defined by Bindings Libraries or by your Lua code. Two standard methods are defined for every struct type:

  • copy() that duplicates a struct value
  • hasType(someStructType) that tests if a struct value really has the expected type

And as everything in CodeFlow is compatible with live-coding, adding or replacing a struct method can be done at any time, including in live mode while the app is running.

Here are a few examples of using and defining method structs in Lua:

-- this uses local variables from the previous code sample...

-- duplicate a struct value
local point2 = point1:copy()
point2.x = 10 -- this does not modify point1

-- add a method to CGRect
function CGRect:centeredRectWithSize (width, height)
    -- if the method is called with a single parameter, return a square
    height = height or width
    -- create the centered rectangle (note the use of predefined CGRect methods getMidX and getMidY)
    return CGRect (self:getMidX() - width / 2, self:getMidY() - height / 2, width, height)
end

if rect1:hasType(CGRect) then
    local rect4 = rect1:CGRect:centeredRectWithSize(50)
    -- use rect4...
end

You can visualize existing struct methods in CodeFlow Variable Inspector while the app is running, by unfolding a type in the struct global variable:

CGRect methods in CodeFlow Variable Inspector

We can notice here the presence of the centeredRectWithSize method defined in the Lua code (with icon Lua function icon) ; other methods are C functions (with icon C function icon) defined in Bindings Libraries.

Et voilà! This is about all you need to know to use structs in CodeFlow. Quite simple, right?

In any case, as a reminder, CodeFlow beta can be downloaded for free. So do not hesitate to give it a try and to send us your feedback or suggestions, either in the comments of this post, or by sending an email to support@celedev.com.

Read More

Recent posts

Blog Post
Aug 1, 2016

CodeFlow 1.0.2

CodeFlow 1.0.2 is a minor release that focuses on improving the Live Application Developer's Experience.

Aug 1, 2016
Blog Post
Jun 16, 2016

CodeFlow 1.0.1 and WWDC 2016

The just-released CodeFlow 1.0.1 brings support for the new iOS 10, tvOS 10 and macOS 10.12 announced at WWDC 2016 this week.

Jun 16, 2016
Blog Post
Jun 9, 2016

CodeFlow turns 1.0

It has been some time since the last beta of CodeFlow, version 0.9.20 was released in January this year. And all this time, we have worked very hard to improve CodeFlow, and to turn it into an effective Application Development System that we love to…

Jun 9, 2016

Last tweets

Jun 8, 2018
@JLJumpertz
✅ Wow, @celedev CodeFlow looks really good in dark mode on macOS 10.14 Mojave! 😃
Still a work in progress, but it took me only a few hours to reach this point, while keeping it compatible with macOS 10.11+ 😎
CodeFlow = live-code native iOS apps in Lua celedev.com
Jun 8, 2018
May 17, 2018
@JLJumpertz
🎉🥂Time-Flow, an iOS app created with @celedev CodeFlow by @alf147 is on the AppStore!
The approval process took less than 24 hours. 😎
#LuaLang #livecoding #iOS
itunes.apple.com/us/app/time-fl…
May 17, 2018
Apr 2, 2018
Minor CodeFlow update today: v1.2.3 fixes an issue with Xcode 9.3. Check for update or download it directly from celedev.com/en/download/
Apr 2, 2018
Feb 12, 2018
New CodeFlow version 1.2.2 today: it solves an error that could occur when calling certain kinds of Swift closures or ObjC blocks from Lua.
Thanks @alf147 for reporting the issue! 😀
Check for update in CodeFlow, or download version 1.2.2 from celedev.com/en/download/.
Feb 12, 2018
Feb 8, 2018
The LuaPanda 🐼sample application has also been updated for CodeFlow 1.2.1.
To get it from GitHub: github.com/celedev/LuaPan…
Feb 8, 2018
Feb 8, 2018
CodeFlow 1.2.1 is now available for upgrade. This is a bugfix release recommended to all users. 😎
Check for update in the appplication,
or download it from celedev.com/en/download/,
or simply read about the changes here: celedev.com/en/download/co…
Feb 8, 2018
Feb 2, 2018
@JLJumpertz
Live iOS app development strikes back!
Version 1.2 of CodeFlow is out, with lots of improved features, for a unique interactive native app development experience. 😀
- download celedev.com/en/download/
- changelog celedev.com/en/download/co…
(by @celedev)
Feb 2, 2018
Dec 7, 2017
🛠New CodeFlow SDK Bindings are available for all supported Xcode versions: 9.2, 8.3, and 7.3. 😊
celedev.com/en/download/
Dec 7, 2017
Aug 9, 2017
🛠CodeFlow SDK Bindings for Xcode 9 beta 5 are available for download. Enjoy! 😊
celedev.com/en/download/
Aug 9, 2017
Jul 11, 2017
New APIs in Xcode 9 / iOS 11 beta 3? CodeFlow supports them from day 1. 😀
🛠 Download updated OS SDK bindings from celedev.com/en/download/
Jul 11, 2017
Jul 2, 2017
CodeFlow 1.1.1 is out, and supports real-time native app development for iOS 11 and macOS 10.13.
Check for update or celedev.com/en/download/
Jul 2, 2017
Dec 5, 2016
@JLJumpertz
"Programming iOS in Lua - A bridge story"
Slides of my talk at Lua Workshop 2016 are here: slideshare.net/jljumpertz/pro…
#lualang #iosdev
Dec 5, 2016
Oct 11, 2016
Little Lua red Panda is now on GitHub! github.com/celedev/LuaPan…
A SceneKit 3D game in #LuaLang with dynamic update of all 3D assets and code
Oct 11, 2016
Oct 3, 2016
CodeFlow 1.0.3 is out!
⚡️ Live SceneKit assets, Sierra support, and more…
celedev.com/en/download/#c…
#lualang #iosdev
Oct 3, 2016
Oct 1, 2016
@aligatr
@Javi @nicklockwood same and also sad they didn't mention Redux realm.io/news/benji-enc… nor @celedev for Live Reloading & Faster iterations
Oct 1, 2016