I am curious if this LuaJIT has a potential application / integration into Codea, especially after playing with the ‘Codea within Codea’ project I found by @Simeon the other day. I find working in JIT compiled IDEs a great deal faster than other methods, where the workflow is more similar to the Shader Lab in Codea and the view keeps reflecting changes instantly (the only issue I find with the Shader Lab is the preview is relatively small on my iPad Pro). I recommend checking out GLSLsandbox.com, the KodeLife app for OSX, and JUCE IDE for reference.
I plan to look more into luaJIT as they say there is a substantial performance increase over Lua, and it is very cross platform friendly / portable. I will provide any useful findings if others would like.
I have been working on the initial steps toward some very large scale goals and grown concerned about performance, and trying to decide what place Codea / Lua will be able to have in those projects. I still plan to use Codea regardless, I love creating on the iPad, and using Codea has been such a wonderful and inspiring experience. I have been using it quite prolifically lately with ~50 test projects and 2 substantial prototyped alpha programs.
I want to see if there has been any info on Codea performance when previewed on the iPad app vs compiled into their own apps, and also in relation to Lua and C/C++
I am more proficient with C/C++, but find to be a bit tedious working with, in contrast to the convenience of Lua in Codea which is so much more fun and creative, and the only way I see to potentially make it any more immediate and fun is to add the possibility of working on portions of code while viewing the result.
@AxiomCrux So, Codea isn’t fast enough. You want to see your progress immediately as you key it. Apparently you’re not old enough to have gone thru the process of keying your code into punch cards, putting them on a “to be processed” table when you left work so it would be processed over night. Then when you come back to work in the morning, you would pickup your card deck along with a printout saying you had a syntax error.
Lua in Codea doesn’t get compiled. The performance is the same when running your code in Codea as when running in a stand-alone app (your Lua code gets interpreted by the Codea runtime).
Until recently, Apple didn’t allow code compiling apps on the store. That’s why all the coding apps used interpreted languages like Lua, JavaScript, Python. JIT, a form of compilation, was also not allowed. I imagine, as with everything, there’d be some form of trade off with JIT: the code might run slightly faster, but might take slightly longer to start running if it requires some kind of build phase. This is just my speculation. The nice thing about Codea is that your code does start running the instant you hit that play button.
With recent changes in App Store policy, there are some coding apps that compile code down to some kind of intermediate language, such as Continuous (C#, F#, Xamarin) and Swift Playgrounds. Both of these attempt to compile your code in the background as you type. There can be quite a long pause though when you hit run, before your code starts to execute. It’s a slightly different feel to Codea’s instant play button. I don’t know whether JIT would also be allowed on the App Store now.
This is kind of the same point as Dave made, no matter how fast your tools, you will always face limitations. And that can be a great spur to creativity. If you’re having performance issues, you probably need to look at your code again.
@yojimbo2000 If I’m not mistaken, Codea gets compiled/converted to Bytecode. I don’t know if the whole program gets converted at once or in chunks each time before it’s executed. See the link below where I show how to view the Bytecode.
@dave1707 it is possible that making assumptions about someone to communicate disrespectfully will only provide upset. I doubt that way of communicating will be beneficial in any way, not to you and most definately not to the company you are representing. Do not troll your fans. I have seen many examples of this from you in threads I have read, and it is not ok.
I have a stack of punch cards, no joke.
I was speaking from the point of view of your intended audience, and I don’t see any valid reason that someone would argue AGAINST workflows that **expedite a creative process and reduce tedium… ** and for that matter would provide something that is rare and cutting edge.
@AxiomCrux I’m sure the majority of Codea users have never waited overnight to see the results of any changes they made to their programs. So the way Codea works now is an extreamly fast way to code. I’m not against things getting faster because Codea wouldn’t be as fun as it is it we had to wait hours or even minutes to see the results of program changes. I’m not sure what you mean by the company I’m representing or the fans that I’m trolling. I’m a Codea user just like you or anyone else here. It’s just that I’ve been on this forum for over 5 years and have programming experience that I can share with other users. When I’m not helping other users, I’m keeping the forum clean of spammers and discussions that have nothing to do with Codea. Seeing program results as you key them sounds fine, but the base program has to be constantly scanning everything your keying in and trying to run it. That means there’s a lot of overhead code that’s running that isn’t really needed when you want to just run your code.
@AxiomCruxDave is a volunteer community moderator, he does not represent us as a company and I think most people are aware of that.
Just to clear things up, LuaJIT is a variant of Lua that compiles programs on the fly into machine code much like Java does on Android. I do not believe that this has a substantial effect on the time it takes to execute Lua code as it does this process on demand (as code is executed).
That said, the version of Lua we are using in Codea has diverged from compatibility with LuaJIT and there are likely to be a significant number of bugs and issues introduced by switching in addition to the the substantial amount of time and effort required. In addition I’m not certain if the new rules will be fairly applied to us if we try to switch (most of the time other IDEs get away with a lot more).
Interactive coding (with results updating on the screen as you type) is definitely possible with Codea and we have done some experiments. It is great for simple examples that do not rely on much initial state or have to load any resources. This limits it to fairly basic toy examples, such as those you see in Playgrounds, which is one of the reasons we have not included it.
@AxiomCrux Apparently what I wrote in my initial response wasn’t interpreted as I intended it to be. If that’s the case, then I apologize for it. As @John said, I’m not associated with Codea, but just a user. I’ve been on this forum for over 5 years helping when I can. There are times I probably respond without knowing how someone else might interprete what I write. That’s going to happen when people don’t communicate face to face. I can’t see how you respond to what I said so that I could clarify it. I was trying to imply that Codea is extreamly fast when writing or fixing code and being able to see the results immediately compared to when I first started programming and having to wait hours. If you have a stack of punch cards, then you may have had to wait to see your changes and know what I’m talking about.