xCodea - a live coding environment for large Codea projects

xCodea lets you seamlessly switch working on your Codea project from your iPad to your laptop/desktop (and back), to take advantage of

  • a proper keyboard! :slight_smile:
  • extended screen estate thanks to your 4 monitors
  • your favourite text editor/IDE, with powerful features such as
    • autocompletion
    • refactoring
    • advanced code navigation with fast keyboard shortcuts
  • inline or external documentation always visible
  • being able to easily find and integrate code snippets (or whole libraries) from the internet without interrupting your workflow
  • git (or your favourite SCM) for versioning, experimentation, and team collaboration, integrated into your workflow
  • powerful tools for managing large projects with lots of files and dependencies

And most importantly:

  • your project runs live (on your iPad) - you see the effect of changes in the code in (almost) realtime
  • your project runs in a sandbox - whenever you make a mistake only that part of the code is affected, while the rest of the project keeps running; fix the error and you’re right back in the program flow without restarting anything

Screencast demo (if the embed works)

The code (and a more detailed readme) is here: https://github.com/lowne/xCodea

Criticism, suggestions, bug reports and contributions are more than welcome!

@Iowne - how does it compare with AirCode offered by Codea?

AirCode is utterly fantastic and I fell in love with it. But as stated in the readme, the reason I made this was to overcome AirCode’s limitations (which became apparent to me when my projects started growing beyond 5 tabs or so). From the top of my head (haven’t used AirCode in a while):

  • While the JS editor is really, really nice (and full of undocumented useful shortcuts) it’s no replacement for a full blown IDE (or even SublimeText). Code assist and navigation in particular become sore points after a certain threshold of complexity.
  • It doesn’t natively interface with powerful, mature computer-side tools such as version control
  • It cannot create or delete tabs, nor projects (xCodea cannot create projects as well. I’m hoping Codea 2 lifts this limitation)
  • There’s insufficient feedback overall. For some subtle errors, more than once I had to waste quite some time trying to understand why I wasn’t seeing any changes; shotgun-debugging via print() statements requires keeping the sidebar open, etc.
  • xCodea’s sandbox, while at this stage almost functionally equivalent to the way AirCode works, has some benefits in that xCodea has fine-grained control over the running code. One example would be that the draw() loop keeps running (although admittedly in some cases this might be undesirable). I plan to further this capability by separating (in the sandbox) the draw() loop from the update() loop (which is a pattern not used natively by Codea)

Brilliant work.

Re Aircode vs xCodea, from the video I’m really liking the way this handles errors. I will give it a try and get back to you with more feedback

@lowne amazing work there, looks very useful.

Unfortunately Codea 2.0 doesn’t let you make new projects — but it’s definitely on the list for a minor 2.x update soon. Especially after seeing xCodea.

Shock and awe, this is great work I can’t wait to use it.

Great job!
@Simeon - Any chance of just turning AirCode into a server than we can connect to and use a native editor with?

@Iowne Thats awesome!

@zoyt +1

@Zoyt @Briarfox yes, as soon as I get a chance.

@iowne brilliant. For how long have you been using codea?

@lowne many thanks for sharing this. I mostly work using Air Code and hoped some of these features would be introduced. xCodea provides these and more, so looking forward to trying it!

Thanks everyone! :smiley:
For those who are interested in trying it, I rushed to fill in the setup instructions in the readme. If you have any trouble getting xCodea to work please let me know!
You might need to easy_install some python packages, it’s not mentioned in the readme because eventually I hope to streamline installation via setuptools (or even, if it makes sense, make the server a proper menubar app); please share any difficulties you encounter.
(Also some things like the --root option haven’t really been tested much, if bugs get reported they will be squished) (also Windows is completely untested. Share your findings ye who are courageous)

Re: AirCode @Simeon @Zoyt @Briarfox - that’s exactly xCodea’s endgame :wink: we (Codea users) explore what’s possible, the journey teaches the community what makes sense and is useful and what isn’t, until (hopefully) TwoLivesLeft gifts us with a native, powerful implementation.

For the near(ish) future @Simeon lemme add to the wish list an official API for managing dependencies too. The Info.plist hack seems to have issues with caches and/or Codea itself having the file open. These meta-APIs open up a lot of possibilities for the user-exploration phase :wink:

For the “far” future, I actually have a grand vision for Mac-side Codea (and the Mac runtime would be important in it - but I’m not talking about targeting OSX for deployment). I think that’d be a big opportunity for TwoLivesLeft also business-wise. Codea (the iPad app) is a wonderful “trojan horse” towards a fuller platform. (Or in other words, I agree that Codea is mainly a tool for prototyping, but I don’t necessarily agree with the “obvious” consequences of that statement).

@Jmv38 I must confess I’m a noob - just a few months. The minimal (as in minimal runtime) approach of Codea, and even more the design decisions behind Lua - here’s a good read for those who are interested: http://www.lua.org/doc/hopl.pdf - resonated with some thoughts I have about (va sans dire) learning “programming”. Anyway that’s a different topic (which includes the reason behind the scare quotes) - bottom line is I’ve been breathing lua and Codea since :slight_smile:

@lowne - I’m glad to see that LiveCodea as ‘made a baby’ :slight_smile: ! I haven’t followed it’s development because I thinked no one was interested by this project, and AirCode was easiest to setup for users (mhh there is nno setup that why it’s easiest…). Your implementation and improvements are really good !. Some months ago I’ve started to write a full editor, the main idea of it was to bring a bridge to share all type of resources between Codea and the desktop with scriptable plugins (js/lua) ie: Blender model < IDE plugin read/convert the 3D model and send it to the running project > Codea. All that REPL based. Ok I admit that is a lot of work and I haven’t lot of free time, also I doesn’t feel on using another IDE.
Also, if you’re interested, I’ve some tiny features like proper handling of classes evaluation (class B inherits class A and you update class A), bootstrap Codea from the server (so the Codea dependency is maintained by the server), long polling to avoid polling interval… Maybe we can share/merge our work ?
Unfortunately, I haven’t been able to run xCodea, the easy_install fail on lxml lib.

@Zoyt - AirCode is a server. I’ve been able to reflect projects(folders/lua files) on my desktop and send update to it. I’m close to use AirCode from an external IDE, I’ll post more info on it when/if I have something useable.
@Simeon - Is there any route that AirCode handle to eval a chunk of code (not the a complete tab) without saving it ?

@toffer @lowne Do your little (amazing) creations work on Codea 2.0, becaus i’m going to check anyways

Quick update: many fixes and additions, but mainly:

@Simeon so the assets still (Codea 2) live in flat namespaces inside Documents: and Dropbox:? Or is it possible now to have subfolders?

(boring technical “rant” follows; you’ve been warned)
@toffer whoa, that sounds like a lot of work! I don’t (yet) do anything 3d, but that is precisely the kind of stuff that would help unleash the full potential of the Codea runtime. However I think it’s better to start nimble: such plugins already have a universal entry point into Codea via eval.luac in xCodea/LiveCodea which can be transparently wrapped on-the-fly by higher level scaffolding if required, as long as the target is simply a valid Lua chunk. Once the ecosystem grows sufficiently complex a more robust platform can be built, having a much better idea of the requirements.

About handling class initialisation and inheritance at runtime: I’ve thought long and hard about the problem; I came to the conclusion that the best approach is to do nothing “automagically” in order to avoid surprises to the user and let her handle runtime behaviour in the proper way for the specific project/coding style:

  • Large structural changes should break runtime and force a restart, or hairy bugs might suddenly appear hours later (when the project is finally restarted, cleaning up all the “garbage”) - much harder to deal with them at that point
  • Codea class()es can be easily massaged, but it’s not the only paradigm: Lua allows (actually encourages) one to ad-hoc build whatever paradigm works best for the specific problem, and a specific OOP implementation, or even OOP period, aren’t always the best paradigm. Naked tables and metatables cannot be massaged so easily (or at all - how to robustly handle stuff = nil?), without even considering the infinite variety of possible constructs; so, a situation in which I can MyClass = class() with abandon but have to remember to MyThingie = MyThingie or {} isn’t optimal and will cause bugs (or at least hassles)

Long polling is a good idea! I’ll get it in now :slight_smile:
What do you mean with bootstrapping Codea from the server?

At any rate I’m very much open to contributions! The internets keep saying that github forking is meant just for that :wink: And I’m especially looking forward to see what comes out of your efforts wrt bridge plugins, it’s a fantastic concept with lots of potential.

EDIT: long polling is implemented - xCodea is incredibly responsive with it - but must remain disabled until the http.request bug is fixed :frowning:
A search in the issue tracker turned out nothing, so I filed a bug here: https://bitbucket.org/TwoLivesLeft/core/issue/289/httprequest-with-pending-callbacks-crashes (is this the right place?)

@lowne - You’re right for the class handling initialisation. And glad you have some improvment with long polling. For the bootstrapping, It mean return the bootstrap (xCodea) from the server when the client go to connect. Also, I’ve try the self-contained menubar, but it crash, does it need os x > 10.6 ?

@toffer - I’m afraid it almost certainly needs 10.9 - see https://github.com/lowne/xCodea/issues/5

Thanks, that was what I suspected. No matter, I succeed to install the needed python dependencies.

@lowne would you be able to produce a tiny sample program that reproduces the http crash issue? I will use it to fix the bug.

Nice work! Sounds a bit like my old project that was using node.js as a base.


My sandbox was quite naive, so it’s nice to an ambitious attempt at it! :slight_smile: