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!
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
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)
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.
@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!
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 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
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
@lowne - Iām glad to see that LiveCodea as āmade a babyā ! 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 ?
@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
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 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.
@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 ?
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.