I'm working on a Lua port for the CE:


Right now it's just a REPL that uses the CE port of Nspire I/O for input and output, so it's not actually that useful. But I'd like to add CE-specific libraries to it in the future, and also allow you to run stored programs.

There are a few possible ways of doing that - one would be to specify that a program variable is a Lua program, potentially by putting ?LUA at the top. Then, a hook could detect that and launch the Lua interpreter instead. This wouldn't require a lot of work, but would require me to make a copy of the program that's detokenized, which might take up a lot of memory. It would also require you to run the app at least once to install hooks before any Lua program could be run.

The other option would be to build an editor into the app and store Lua programs in ASCII in appvars. This would require a lot more work (and I'd be more likely to give up on the project before finishing it), but it would allow me to reuse features between the REPL and the editor, give me more customization, and probably be more convenient to write code in. But it would also necessitate some sort of computer-side conversion program, rather than allowing you to use TI-Connect to edit and send programs. It would also require some alternative method to be able to run a program from TI-BASIC.

If you have any thoughts on which you'd prefer, please leave a reply.

Because Lua is very large (over 255 kilobytes), I'm compiling it into an app instead of a program. I have code to generate an unsigned 8ek at the moment, but no way of sending it to a physical calculator. As a result, there's no beta download as of now.

Does that mean there's a way to send it to CEmu?

Of course, it would be rather difficult to get that screenshot otherwise

Anyways, I've finished writing the code to generate an installer program like Cesium uses. Because of how large it is, it splits it up into multiple appvars that all need to be transferred - I might have it bundle them together like the TI-Boy ROM converter does at some point in the future.

Expect the publication of the source soon™, I still have a bit more to clean up with the repository and then I'll put it and the first development build on GitHub.

This is really cool!
Credit was intended to be used for stuff like this, because it doesn't have any kind of special format (straight ASCII) and it does have a computer sided editor

Because of the Texas Instruments key factoring issue? I suppose CEmu doesn't take that into account, because CEmu isn't authorized by TI.

CEmu runs the exact same code that a physical calculator does, which includes the signature check for applications.

Of course, it's much easier to modify what code CEmu runs than it is to do so on a physical calculator.

Right. Though that does make me curious. Has anyone actually successfully created a method for editing the OS so that it no longer checks for signatures -- or, better yet, checks for signatures using a customizable set of keys (stored in an 8xv or something)?

I don't know whether someone has created such a method, which would definitely be useful to users (and a user right, especially for those who bought the calculators: doing whatever we please with the hardware that we own because we bought it). Sadly, it's typically the kind of things whose public release can only trigger serious action by TI, and ultimately hurt users in multiple ways...

Blame the educational systems of a number of major countries worldwide, standardized tests and the people regulating said standardized tests.

Great work, commandblockguy! I think it was before your time at Cemetech: I once ported Lua to the Casio Prizm, but never had the time or inclination to iterate on it. I doubt there's anything in there that would be helpful, as it sounds like the biggest obstacles you're facing are App-related rather than Lua-related, but let me know.

I've added the ability to load programs from appvars with headers, similarly to how Python does it. Right now you have to do dofile "FILENAME" to run a program, but in the future I'd like to add the option to run a program from a GUI. There's also still no way of editing a program on calc.

I'm still trying to figure out how to structure the repository, before I release a development build. I want it to be simple to switch between upstream Lua commits, as well as simple for other contributors to use. There are a few options I'm considering:
* Just throw all the C files into the src/ directory of a toolchain project. This is the simplest, but makes it difficult to upgrade to newer Lua versions in the future.
* Fork the main Lua repository, add CE-specific stuff in its own folder. This makes it trivial to keep Lua up-to-date. However, conceptually, what I'm building isn't really a fork of the Lua library but a program using it, and there's a bunch of minor issues that I think would result from structuring it like this.
* Fork the Lua repository to make a relatively small number of CE-specific changes to the library itself, then make a new project that uses that as a submodule. This would work pretty well, but it splits the code up into two repositories, both of which are only really useful in terms of the other.
* Make the Lua repository a submodule, then use the build system / preprocessor macros to build it the way that I need it. This makes the most sense conceptually, but to actually make it work would be really hacky.

At the moment there are only two places in the Lua library that I'm modifying - the config file, which is intended to be modified, and the function for loading Lua scripts from a file, which I've added a signature check too, similar to how Python source files work. I may also need to modify the OS and I/O libraries in the future; I'm currently not including them in the build since they use functions that aren't available on the CE.

Let me know if you have any opinions on the repository structure - I'm probably overthinking it, but at the same time it's better to change it now than it is later.

I have a suggestion on how to handle Lua as a library:

So, first, you'd have the actual Lua code in an app, because it's big. But this app wouldn't be callable by itself (like usb8x on the monochromes, if you will). Instead it is merely a C library for other programs to use. Then, a C program could use libload to load a library (as an appvar) that is basically just a jump table to the actual library, in the app. During init, it would find the app in memory and SMC the jump table accordingly, of course. Now you have Lua as a dynamically loaded library that can be used in programs. Any programs.

Then you can make a separate program that acts like lua on PCs: it uses the Lua libraries to be a standalone Lua interpreter. This can have a fancy UI, maybe even an editor eventually, and you can add custom libraries however you want.

If you want to, you can also separate the three Lua libraries (lua, lualib, lauxlib) into separate libload appvars.

I can imagine there could actually be quite a big market for C programs that use Lua like this. One could for example make a packager that packages a tiny C loader along the Lua program, that just opens the Lua library and uses it to run the included Lua program. Or shells could have integrated support for running Lua programs. Lua programs could be big. It could become what TI had tried to do with Python. People have been asking for a language more powerful than TI-BASIC but easier than C for ages. This could be it.

And now for the biggest advantage: if someone (for instance, me, if I end up getting the calc for it) were to get Lua running on the Python coprocessor of Python edition calcs, one could just install a different but compatible libload appvar that communicated with the coprocessor instead, and automatically get a speed boost in all programs that use Lua.

(for that matter, anything here could also apply to a hypothetical port of micropython, and maybe people would like that more, but hey, I like Lua :p)

I like that idea. My main concern with it is that it might potentially be confusing to users to have both an app and a program that are called the same thing, especially if one of them doesn't appear to do anything. I suppose you could hide the Lua app by marking it as a language app, but that might also be confusing when people try to figure out why they're getting a memory error.

I think that ideally, we should standardize a interface for LibLoad to load libraries from apps. That way, there's no overhead from keeping a jump table with every single Lua function in it in RAM. Even if it's not implemented right away, I could always make an adapter library that handles it in the meantime.

Can you port this to the TI NSPIRE? Since it’s LUA.

TI-Nspire calculators running OS 3.0.2 or higher (or was it 3.0.1 or 3.1? I forgot) got Lua built-in.

Building on DJ's comment: TI's implementation of Lua on the Nspire is peculiar, in that it has no io.* or os.*, but additional custom platform-specific APIs. It's still Lua, though.