Luna v0.3a fixes a compatibility problem with some unicode characters such as chinese ones. Sorry about it and thanks wtof1996 for reporting it.
It also skips the UTF-8 BOM added by some text editor to the .lua file to convert. Hopefully the popup ”An error was found in the format of this document” won’t annoy you anymore.
oclua (v0.1a) has also been rebuilt with this Luna to you let you use the new OS 3.2 Lua API.
The release of a possible official on-calc Lua editor is being too much delayed by TI. oclua was more of a proof-of-concept than an application ready to use. Fortunately yatto has worked on a nice editor called LuaCS which you can find on the French tiplanet.org. It features syntax highlighting, code snippets and indentation. Translation of menus is under way. It doesn’t yet offer native integration of a code runner and must be used together with oclua. Levak has started to work on this in his own (currently unstable) fork .
TI’s integration of Lua in the TI-Nspire was a first step for an officially supported true development experience, but is far from being complete. Let us put these projects to good use and explore how we can benefit from the new OS 3.2 Chimpmunk-based physics engine!
v0.3 of Luna is now available!
- This version can generate Lua programs compatible with OS v3.2′s new Lua API. Thanks to jimbauwens for the hint.
- It also fixes conversion issues with Lua scripts and documents which contain special characters. The whole UTF-8 encoding space is now supported, just make sure to save your input file in UTF-8.
Luna is a lightweight, portable, command-line Lua to TNS converter for TI-Nspire developers. It has been used for now nearly a year by Windows, Mac and Linux users as an alternative to TI’s official SDK to streamline their Lua development cycle. It is also used to generate custom TI-Nspire documents with full control on their format.
Luna powers Deep Thought online Lua converter and tiplanet.org’s nCreator, a Web-based Notes editor.
Thanks to all of you who gave their votes to oclua and/or Luna for ticalc.org‘s 2011 edition of the “Program of the Year” series. There were good competitors this year, congrats to the winners!
This is a bug fix release that should get rid of random crashes with some Lua scripts.
Luna v0.2a is now available, which fixes nasty bugs making it sometimes unusable. Sorry for the inconvenience, and thanks to Goplat and Levak. Make3D can now be fully converted with Luna, either the debug version or the library version.
You should also have a look at Levak’s useful script for nspire_emu to dump XML documents of arbitrary size, that can be combined with his other script to extract a Lua source code written on-calc with oclua.
I’m pleased to announce the availability of Luna v0.2!
This version adds support for arbitrary TI-Nspire “problems” conversion from XML format to TI-Nspire TNS documents compatible with OS 3.0.2 and above. This could not easily be done on the latest OS versions before, because TI took the sad decision to protect its OS from interoperability with third-party user tools.
Suppose you now want to build a computer tool that generates TI-Nspire documents with Notepad widgets.
1) Build the problem template: on nspire_emu, create a new document with a Notepad widget (“Add notes”). Put a debugger breakpoint to export the document in XML form, before it is compressed and encrypted: on a non-CAS OS 3.0.1, you would use something like:
k 10032AA0 +x
[save the document here]
w problem.xml r1 400
[repeat if the problem is bigger than 1024 bytes to get each problem chunk]
Some alternative methods such as copying from TI-Nspire Software and exporting the content with Levak’s clipboard dumper may also be used instead, or as adriweb suggests for Mac users the “Clipboard Viewer” available with XCode in /developer/Applications/Utilities/.
You will get an XML document that looks like (the Notepad only contains a “Hello world” here, the TI-Nspire XML format is indeed quite verbose):
<?xml version="1.0" encoding="UTF-8" ?>
<prob xmlns="urn:TI.Problem" ver="1.0" pbname="">
<sym></sym><card clay="0" h1="10000" h2="10000" w1="10000" w2="10000"><isDummyCard>0</isDummyCard><flag>0</flag>
<wdgt xmlns:np="urn:TI.Notepad" type="TI.Notepad" ver="2.0"><np:mFlags>1024</np:mFlags><np:value>3</np:value>
<np:fmtxt><r2dtotree><node name="1doc"><node name="1para"><node name="1rtline"><leaf name="1word">hello </leaf><leaf name="1word">world<cursor index="0"/></leaf></node></node></node></r2dtotree></np:fmtxt></wdgt></card></prob>
2) Write your problem generator based on this template
3) Integrate Luna with your generator:
luna problem.xml outdoc.tns
Quite easy, isn’t it? :)
[update 2011/09/21] Levak tells me his Make3D program which features a Lua plugin system can now be built with Luna and its XML converter for compatibility with OS 3.0.2 and later! Minor encoding issues had to be worked around, we’re looking further into them.
Luna is the first third-party Lua script converter for TI-Nspire compatible with OS 3.0.2. It defeats the useless compression and encryption layers described in earlier posts.
Long-time TI-Nspire users, you now won’t need to pay for a Computer Software licence to code in Lua.
Developers, you won’t click and click and click anymore to convert/test/run your programs as you have to with the official kit.
Linux users, here is a portable tool.
Hackers, this can be a good base to build (or rewrite) third-party TI-Nspire document generators.
Enthusiasts, support for C and ARM on OS 3.x might not be so far…
I like this sound of openness and happiness, don’t you too?
I finally could find a couple of hours to go further on the converter.
As you remember the OS 3.x TNS file format has 4 layers: 1) XML compression, 2) zlib compression, 3) triple-DES encryption and 4) zip wrapper. 4) and 3) are now supported by the converter, but it fails miserably on the inflate() call for 2) with a Z_DATA_ERROR… The deflated 512-byte block to inflate seems OK, and can be inflated on the computer side without problem.
What could be wrong?
[edit 2011/08/01] 2) (zlib compression) now passes! the zlib stream needs to be produced with a negative windowBits parameter, to avoid emitting a zlib header.
And now probably the last step: 1) (the XML compression) fails at the 13th 512-byte block of the Lua sample program I use, in the TNS decryption loop…
So a TNS file entry compressed with the unknown “D” method is:
- XML-compressed by the OS with a custom binary XML method
- deflated with zlib
I was curious about 1) and 3).
I first checked that XML-compressing a Lua script from a skeleton (similarly to what the current third-party Lua converters for OS 3.0.1 do) is quite easy without needing to implemented the patented algorithm, thus avoiding any legal issues. This is good news.
I also had a closer look at the encryption algorithm. It is actually an OpenSSL-based Triple-DES encryption in ECB mode (thanks Google Code Search for making ARM code so much clearer). The 3 keys are probably embedded in the OS although I didn’t bother to look where exactly. Computer-side encryption tests confirm that the 3 keys I found are the good ones.
Integrating this into to a new Lua converter compatible with OS 3.0.2 should now be easy :)
Considering the release of TI-Nspire OS 3.0.2 I have both good and bad news:
- The upcoming Ndless v3.0, compatible with OS 3.0, is under development, and I was hoping to share an alpha version soon
- TI sadly took with OS 3.0.2 the decision to block third-party Lua development, preferring to force developers to wait for an official release of their SDK. Fortunately Lua scripts can still be saved on OS 3.0.1 and transferred back to OS 3.0.2 to run them.
- Some of the most active contributors to the unofficial Lua runtime documentation unfortunately accepted to beta-test the upcoming TI SDK, probably under NDA, and now may have difficulties to contribute on both sides
- The forthcoming v3.0 of Ndless depends on Lua for its installation
The “D” compression method of TNS documents introduced in the latest OS versions that prevents third-party tools to TNS files was by-passed by LUA2TNS and the other (now blocked) Lua converters. I have looked a bit closer at it this morning, and it appears that an XML file (document or problem) included in a TNS file this way is first XML-compressed with a patented method, inflated with zlib, then probably encrypted.
So what does this mean for us? Implementing a third-party converter which includes the XML compression required by OS 3.0.2 is impossible without being exposed to legal action. Compressing XML is surely a bright idea to optimize storage space, but there were many open binary XML encoding methods available that did not require TI to invest (probably specifically for the TI-Nspire) in a new one. Unless they want to wrap the device with fiddle-proof legal tape.
I’m now considering extending Ncubate, the enhanced nspire_emu, with a Lua script conversion feature.