1
TI-Nspire / Re: Lua workflow
« on: January 01, 2013, 03:05:58 pm »QuoteThe ScITE IDE has the best support of any IDE, but it is windows only.Not sure what you're referring to, as I use SciTE under Linux on a daily basis.
*googles* Heaven, I even found an OS X version using MacPorts. Is this NSpire Lua support or they Ndless only?
QuoteThe worst part of programming for the calculator is that TI makes large projects a major PITA as everything has to be in one large text file.Said large text file can easily be assembled from multiple scattered text files, though
Which is bad! Time spent scrolling is a large part of a programmers job!
I am myself using Intellij with the Nspire Lua Plugin I made for it (latest version here : http://tiplanet.org/forum/archives_voir.php?id=8182 ) which makes coding just plain easy.Thanks for your plugin, it is very useful! I can not get the debugger to work, so I use it when I need to refactor. The Lua plug-in for Eclipse should allow it soon as well.
It has to be used with the "Lua" plugin available on intellij natively (plugin downloader).
After that, I use some bash script to concatenate all my .lua files and finally Luna to generate the .tns from that.
Then I open it on TINCS and/or the calc itself. It doesn't take me a long time since it can be all automated with a keybinding or something.
I know Jim Bauwens has something like that too.
This is not cross-platform compatible and needs manual adjustment. I am suggesting a standard workflow and maybe inline it with the IDE(s).
Also, Jim has in mind some online Nspire SDK too, so indeed he's the person to talk to
He'll see this topic for sure so he'll reply
I do not mean an SDK, but a web-like workflow. Program in normal Lua and test using virtual NSpire (such as PC-Spire) and use scripts to "compile" the code and move it onto a real NSpire. This way we optimize the desktop environment for testing and iterative optimization of code (like a dev machine with local Apache / MySQL) and minimize manual labor needed to "upload" everything onto a real NSpire (like a remote server).
The larger goal is to remove all of set-up and gotchas required of a new developer. The less time we spend customizing our tooling, the better!
(Thank you all for your responses!! Sorry for my english, I am rushed today. Happy new year!)