I don't see what's wrong with doing both Most people will only have one or the other anyways, making their choice fairly obvious.

But at least in the community, I think the available tools and programmability of the respective calculators will influence the purchasing choices of a lot of us, and as we build programs and games and tools, that's likely to influence a lot of end users such as students as well. Thus far we have tools that in my experience make it easy and fun to write powerful C programs for the Prizm; now we need to see if this is as fun and powerful, equally so, or less so.

Indeed. If the Lua capabilities they gave us aren't nearly as good, then we can keep primarily advertise the Prizm as the community preferred calculator. From what I've seen so far, NLua is pretty decent as it has great built in graphical functions, but I don't see them being any better than equally the same ones written in C for the Prizm.

If we could write Lua code on the Nspires themselves, then that would be a fairly significant advantage, but currently that's not the case, correct? As far as I understand it, you can't encrypt and sign Lua documents on-calc, although I believe you can type them?

There's no on-calc editor for Lua, although I think that text editor _can_ be used for writing some Lua code. The document containing the text then needs to be opened on the computer side with TINCS, and copied and pasted to other files...

The problem with an on-calc Lua editor in Lua is that I don't think "NLua" has a file IO Lib. That would prevent any type of var access at all.

Of course, the actual Lua code is stored in ASCII form in its XML document, so a C-based editor would be fairly trivial. Plus, it would require no PC transfers. Now that would be awesome.

What if TI gave us an OS with a shell, and the root password? After all, Nucleus is a UNIX OS, right?

Nucleus has some (partial ?) POSIX compatibility layer, but at its core, it's the Nucleus API

But Lua is non-existent on OSes that have been hacked for C, and C doesn't exist on OSes that have been give to us with Lua, so for now that would actually be a bit impossible (With C at least)

well, yeah, but here's to hoping for ndless 3.0

Yeah, but before we worry about all that, I think it's worth at least putting in a good-faith effort to use TI's tools, since they've at least implied they may be willing to soften their position towards us.

You can access variables (such as strings, expressions and matrixes) in the current document, just not out of the document.
I'm planning to make an on-calc editor one of these day's (after I finished Blockbreaker Lua). My plan is to have 2 lua programs in one document, one which is the editor and saves the Lua code in a variable, and the other loads and executes the Lua in the variable. Pretty simple

That sounds pretty straightforward, but that would mean that every document that contains a program you want to edit has to contain a full copy of the editor as well, does it not?

Yes, but you can very easily remove the editor when you are done

Ah, that seems logical and like a decent idea. I take it that this is still something you've been planning and haven't tried implementing yet, though? I hope you'll keep us updated.

Have you read the posts on Omni about the French pocket 84. Looks like TI is back to their same old tricks. The evidence suggests that they are still out to screw us and the only thing that has changed is that they acknowledged the presence of Lua but of course they couldn't deny it.

Since I've been busy with other stuff, I yesterday told another Lua programmer on Onmnimaga about mine ideas, and I asked him if he could make it. So he started, and yesterday evening we make good progress

Ooh, sounds useful! Plus, can't you copy and paste docs in the main menu anyways? That way, you copy the editor, name it after your prog, edit the prog, remove the editor, and bingo, a finished product, right?

[/quote]
Yeah, I guess they would be stupid to not produce pre-production models.[/quote]

Ever notice how ti ignores the customer? I am convinced that ti puts out prototypes or pre-production calcs not to let the customer participate in the design process, but to use the customer as a free software testing service.

I am also convinced that as a result of the success that ti had with their calc's many years ago, which was blind luck, ti clearly thinks they are gifted and only they know what a calculator design should be. Unfortunately what happened years ago doesn't apply to today, as demonstrated by the lack of market acceptance of the nspire series, which after being out for 5 years is still not taking over the ti-83/84/89/or Voyage market.

I remind myself that you can tell a fool but you cannot tell them much, so I expect ti to continue to pour money down the nspire rathole when they should be updateing their other well recieved products with rechargable batteries, color screens, better 3-d graphing, and especially all the capabilities that competiting calculators have.

Speaking of competiting capabilities, the nspire series is mathematically weak and I have not bought it and will not buy it for that reason. Why on earth people spend their money on a weak product is beyond my compehension. So please clue me in.

The monopoly has a close gridlock position with teachers, and are able to sway them to buy just about anything they sell, even if it is weak.

But teachers still tell their students to buy 84s

My school bought a bunch of new calcs just last year/ Number of nspires they bought: 0. Every single one was an 84+, meaning every single one had MathPrint, and the missing RAM.