This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - NecroBumpist
136
« on: August 18, 2011, 11:31:49 am »
That's a possibility.
I couldn't find the original cable, so I stole one from this weird USB-laptop speaker thingy. I'll continue searching for another cable.
137
« on: August 18, 2011, 11:27:43 am »
It should have caused a segfault in the loadstring() function.
It does with normal Lua, maybe it's just not a problem on ARM. Oh well.
Anyway, what software am I supposed to use to update to OS 3 ?
I downloaded the 3.0.2.1791 .tno from TI's website, and the TI NSpire Student Software, but that seems to be a trial, and isn't recognizing my calculator. (then again, I'm not using the cord that came with it)
Any suggestions ?
138
« on: August 18, 2011, 11:08:28 am »
Damn, that's pretty cool.
What FPS does it run at ?
139
« on: August 18, 2011, 10:43:31 am »
Huh, I guess they must have modified Lua. And that's a good point about the LuaJIT ARM release date, I hadn't even though about that.
Welp,
I dare someone to go run this on their calculator (likely to segfault):
loadstring(('').dump(function()X''end):gsub('\2%z%z%zX','\0\0\0'))()
The above is just one of many problems with Lua's bytecode implementation.
I guess now I'll go load OS 3 onto mine, and experiment with a few other bytecode exploits I know of.
Thanks for the info Lionel.
140
« on: August 18, 2011, 12:46:35 am »
Good, TI finally made a smart decision.  LuaJIT is insanely fast compared to normal Lua. Can you explain a little bit more (as you're there )
Having "..." as a function parameter will cause that function to accept any number of inputs. Lua 5.0.* (I think) was the last version to official support converting of variable arguments into a table which is automatically localized (the 'arg' variable). Lua 5.1.4 has compatibility with this feature, LuaJIT does not by default (I think you can enable it). While this is good news for speed, it's bad news for the one exploit I mentioned, as LuaJIT uses a different bytecode format, and the exploit probably isn't viable. Not to mention I've been working on a complex Lua assembler for other things and when I saw NSpire 3 uses Lua I got excited, but I guess that won't be of much use here :'(
141
« on: August 18, 2011, 12:25:27 am »
Okay, I can't find my Nspire, and I've yet to update it to 3.0, so if any one can run the following code for me, that would be wonderful. local function test(...)
if arg then
print("Lua") -- might have to replace print() with a graphics API call, I haven't use it yet
else
print("LuaJIT");
end
end
test(1, true, 'cool');
LuaJIT handles variable argument functions differently than normal Lua, which is why the above would discern the two. Sorry, but I don't know the graphics API, as I said, I've yet to start messing around  Also, did TI keep the loadstring() function, or did they clear that out for security reasons ? If they kept it, it opens the doors for at least one potential exploit, and the possibility of optimized Lua assembly (though TI-Basic is still probably faster)
142
« on: August 17, 2011, 11:51:13 pm »
Does TI utilize LuaJIT (not sure if the ARM port is compatible with this processor) ?
143
« on: August 17, 2011, 11:49:12 pm »
string.find() actually has two more parameters.
The first being an integer (can be negative), which describes where to begin searching the string,
The second being a boolean, if true, string patterns are ignored.
print(string.find("herp()", "(", 0, true)) --> 5 5
|
Show Posts