The programming language Lua has been around for fifteen years, and has recently gained significant traction as an introductory scripting language. As I mentioned when I first announced the LuaZM project, the TI-Nspire CX has had Lua for about a year now, Texas Instruments' uneasy relationship with hobbyist programmers notwithstanding. I'm proud to release the first beta of LuaZM to the public, along with documentation on the current features of the core program and its included libraries. Create your own .lua programs, then use LuaZM's handy graphical file browser to select a program and run it. LuaZM also includes a command line where you can test out commands and functions. LuaZM is a semi-port of Lua 5.2.1. Please try out this beta, give me feedback, and start publishing your own Prizm Lua programs! Compatibility layers for Nspire and LuaFX programs may be coming soon. Special thanks go to Juju and AHelper for the PrizmIO console library and the File Browser GUI respectively.

Download & Read More
LuaZM v0.1 - Casio Prizm Lua Interpreter
LuaZM reference documentation

You should add functions to scroll the screen of your clipping rectangle and to save it and restore it later (as in luaFX).

I think a compatibility layer for luaFX programs is possible, but some functionnalities will be difficult to make it compatible (I mean the file library and the module system). For the other functions, it is not quite difficult: add '(' and ')' to the .lua where it is needed, load a different library.

Yet another promising project from the guys at Cemetech. I'm specially excited for the (both standard and Prizm/Nspire-specific) libraries that hopefully are coming...

Also, I miss a cursor in the console... not being able to go back and insert text is a pain.

I figured out a clean screenshot not taken with a camera on an actual Prizm would be nice, so here it is...
Unfortunately your method for capturing keyboard keys doesn't work on the emulator, so I couldn't open the About screen or print an epic "Hello Moon" message




gbl08ma gets more and more annoyed that people don't use standard GetKey syscalls when possible...

Wow, this is awesome.

Is it possible to write in lowercase in the command line?

EDIT:

My program I made will not run.

Code:



Here is the file: https://dl.dropbox.com/u/63621708/calcs/progs/luaZM/test.lua

Writing in lowercase is a bit cumbersome/buggy but I think the idea is to switch between caps and lowercase with the OPTN key.

Ah, OK.

Does anyone know why my program will not work though? It says there is a problem near <eof>.

To be fair, it's not very game-friendly to use the syscalls, as they're a lot slower, can't detect more than one key at once, etc. I found a nice solution is to build two versions of the addin in question: one for hardware, and one that's (mostly) emulator friendly. Perhaps Kerm should consider the same And to Kerm specifically, I'm totally trying this out today.

The problem with not using GetKey in hardware is that you are unable to take screenshots and do things like turning off the calculator (without adding additional code for it like Kerm did in Graph3DP).

I personally like the suggestion Ashbad used in his Pong and Raptor games: when the custom keyboard routines detect the Menu key, Shift+AC or Shift+7, they do a standard GetKey syscall so that the special events are handled.

Yes, PrizmIO needs the modifier keys changed up; they're currently nonsensical. I have made suggestions to Juju about it, and since he's planning to make a lot of changes to PrizmIO based on my suggestions, I didn't bother making the changes myself yet. No sense doing it twice if he's going to get to it soon. If he's not, though, I'll just do it myself. Here were my suggestions:
http://www.cemetech.net/forum/viewtopic.php?p=188440#188440
Oh, and for what it's worth, PrizmIO currently uses Ashbad's system to check if keys are currently pressed or held.

Flyingfisch: Although that should work, what do you have against calling the functions directly? Is it faster that way? I'll try your code on my Prizm and see how it runs.

Edit: As requested, here is a list of planned features for LuaZM before 1.0:
:: Either get a fixed PrizmIO or fix PrizmIO
:: Finish overhauling IO library and include it. Add serial port support.
:: Finish overhauling OS library and include it.
:: Decide whether to include the Coroutines library
:: Decide whether to make a LuaFX compatibility layer or just port over (some or all) of the ten existing LuaFX programs.

I guess I don't call functions directly because it seems like just about all LuaFX programs call them like that. I don't know if that is just veb's preference or not, but I have been doing it that way for quite a while.

So, while it may be faster (I don't know), I do it because I always have. Should I call them directly instead?

I suspect it might be slightly faster to do it that way. Can you use the zmg.ticks() function wrapped around 1000 calls of some function written both ways to see what the relative speeds are?

Yes, it faster:

local clear = zmg.clear
clear ()

first part : local clear = zmg.clear
search the global zmg
find the index clear
put the result in an upvalue

second part : clear()
load the upvalue
call it

and the other way: zmg.clear()
search the global zmg
find the index clear
call it


Then if we call a function multiple times, the first way is faster.

well, sure, but could I can't get any lua progs to work for me. Maybe it has something to do with me using linux line breaks or me using linux formats? I think mine is in UTF-8...

Ah, UTF-8 is encoding, it doesn't understand UTF-8. Try ANSI encoding.

Oh, ok.

I just tried an experiment with the following code:

Code:


The former method averaged 0.000125 seconds (125 microseconds) per call, while the latter method averaged 0.000141 seconds (141 microseconds) per call. A small but measurable difference, which would be amortized for more complex calls than drawPoint.

Is there an implemented text input routine for LuaZM?

Yes, there is; it was one of the last ZMG routines that I added:

http://prizm.cemetech.net/index.php?title=LuaZM_Reference#zmg.drawText.28.29

Oh, cool.

Why don't you import the io standard library instead of adding it to zmg?

EDIT:
Just looked at the docs. I didn't mean to draw text, i meant to get user input from the command line.

Those are going to be part of the io library. print() prints to the command line for now, but there's no read() or readline() function yet.