nSquirrelSquirrel on Ti-NspireLast release version (v1.0.1) : https://github.com/Eiyeron/squirrel/releases/tag/nsquirrel_1.0.1 (includes documentation, which the binary linked to this post doesn't)
Project repository : https://github.com/Eiyeron/squirrel/
nSquirrel (interpreter + n2SDLib) branch : https://github.com/Eiyeron/squirrel/tree/nSquirrel
"Squirrel (http://squirrel-lang.org/) is a high level imperative, object-oriented programming language, designed to be a light-weight scripting language that fits in the size, memory bandwidth, and real-time requirements of applications like video games."
(Translation : it's a lightweight script language destined to be embedded in programs like Lua does.)
[spoiler=Base language features]
Although Squirrel offers a wide range of features like:
- - Open Source MIT licence
- dynamic typing
- delegation
- classes & inheritance
- higher order functions
- lexical scoping
- generators
- cooperative threads(coroutines)
- tail recursion
- exception handling
- automatic memory management (CPU bursts free; mixed approach ref counting/GC)
- both compiler and virtual machine fit together in about 7k lines of C++ code and add only around 100kb-150kb the executable size.
- optional 16bits characters strings
- powerful embedding api
- eg. function/classes can be defined by scripts or in C
- eg. objects can fully exist in the VM or be bound to native code
- eg. classes created in C can be extended by scripts or vice-versa
- and more
[/spoiler]
nSquirrel is a fork of this language destined for Ti-Nspires. The core language will be easily embeddable into Ndless projects as the project offers libraries and API to mess with it. Thus, it's included with bindings to n2DLib (https://github.com/n2DLib/n2DLib) to allow playing with the screen and the keyboard.
Instructions :
- Download the archive containing the program (sq.tns) and if wanted, the example scripts.
- Install your sq.tns on your calc's nspire folder
- Now you can launch the interpreter for an interactive session ( quit() to exit it) or launch a .nut script (only after running the exectuable once). NOte that thanks to nspireio, you have to press twice Enter to validate your input.
- The interpreter registering itself to open .nut files, to execute such scripts, you will just have to click on them.
Notes- For further versions, I'll probably provide two versions of the binaries, ones to compile nSquirrel's interpreter (which uses Nspire-IO) and one to be included in projects.
Awesome, now you should be able to make bindings for Nspire specific things besides Nspire-IO (which isn't hard to integrate by the way).
Awesome Eiyeron. If this gets completed and allow everyone to launch the binary directly without much hassle, then this will be a great addition to other Nspire languages. Now we have BASIC, Lua, ASM, C, Python, Javascript and Squirrel. :)
Quote from: DJ Omnimaga on March 30, 2016, 03:10:36 PM
Awesome Eiyeron. If this gets completed and allow everyone to launch the binary directly without much hassle, then this will be a great addition to other Nspire languages. Now we have BASIC, Lua, ASM, C, Python, Javascript and Squirrel. :)
Don't forget C++
Ah yeah, true. I always forget which of the C-compatible calculators (68K, Nspire, 83+, 84+CSE, 84+CE, PRIZM, 9860G, etc) supports C++, C# or not >.<.
I had to cheat my way but it uses now nspireio to show and require input data. The biggest slowing thing is probably nspireio itself for now. The linked build should be working (at least on emulator. I need to find an USB cable).
I need to find a way to avoid the lib using it also. I mostly hacked the binary, but the runtime library uses printf at one place and would probably need another function instead.
That's good to hear. I assume that sprites and such graphics cannot be displayed yet? Also, will this be compatible with the newer TI-Nspire CX CR4 hardware (the one with 240x320 screens flipped sideways instead of an actual 320x240 LCD)?
IIRC nspireio has been updated to support the newer hardware. Though I don't really know how it works from Ndless' side and I probably suppose that a version check is done at every pixel acces (where one-time funptr selection would probably make up for the loss.)
EDIT : tested on calc and it works.
There is a compatibility layer in Ndless 4.2, but if something updates the entire LCD every frame rather than just parts of it, then it will run 50 times slower, while stuff that does partial screen redraw will run 3 times slower. However, there is a way to achieve almost the same speed on newer hardware than older one. Basically, don't rely entirely on the Ndless 4.2 CR4 compatibility layer. :P
That's an interesting project and all but i still think that the Shakespeare Programming Language (https://github.com/drsam94/Spl) is better.
I'm guessing though that you are not planning on supporting nSDL or any graphics library with Squirrel ?
That'd mean integrating with the source, as there isn't any dynamic libraries on ndless. THat's something more or less envisaged. Gotta take some time for it.
Note : Saved yesterday my calc from the weirdest brick : anything editing the flash (editing, creating, deleting files) would be automatically rollbacked. Had to reinstall the OS. >.>
Small latenight update : integrating n2Dlib. Every drawing functions are done, I need to figure what to do to store and manage sprites (blobs or sprites?...), but the rest seems to work
Pushed a new version containing n2DLib and bindings to every drawing function with n2d as prefix (minus drawPolygon), which means :
initBuffering
deinitBuffering
updateScreen
clearBuffer
clearBufferB
clearBufferW
getPixel
setPixelUnsafe
setPixel
setPixelRGB
drawHLine
fillRect
drawSprite
drawSpritePart
drawSpriteScaled
drawSpriteRotated
drawLine
fillRect
fillCircle
fillEllipse
drawString
drawDecimal
drawChar
Note that every function that asks for Rect asks for the four variables instead of said rect.
extern void drawSpriteScaled(const unsigned short*, const Rect*, int, unsigned short);
=> n2d.drawSpriteScaled(sprite, 0, 0, i, i, 0, 0)
For now, to draw a sprite, you need to convert your picture into a n2D sprite, and convert it with this function :
function array_to_blob(array)
{
local b = blob(array[0]*array[1])
foreach(v in array)
b.writen(v, 'w')
return b
}
Sample program:
[spoiler]
function array_to_blob(array)
{
local b = blob(array[0]*array[1])
foreach(v in array)
b.writen(v, 'w')
return b
}
local sprite = array_to_blob([
32, 32, 0x0000,
0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x181f,0x181f,0x181f,0x181f,0x181f,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,
0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x181f,0x181d,0x181d,0x181b,0x181d,0x181b,0x181d,0x181b,0x181d,0x181d,0x181f,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,
0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x181d,0x181d,0x181b,0x181b,0x1819,0x1819,0x1817,0x1817,0x1817,0x1819,0x1819,0x181b,0x181b,0x181d,0x181d,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,
0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x181f,0x181d,0x181b,0x1819,0x1819,0x1817,0x1817,0x1815,0x1815,0x1813,0x1815,0x1815,0x1817,0x1817,0x1819,0x1819,0x181b,0x181d,0x181f,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,
0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x181f,0x181b,0x181b,0x1817,0x1817,0x1813,0x1813,0x1811,0x1811,0x1811,0x1811,0x1811,0x1811,0x1811,0x1813,0x1813,0x1817,0x1817,0x181b,0x181b,0x181f,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,
0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x181f,0x181b,0x181b,0x1817,0x1815,0x1813,0x1813,0x100e,0x100e,0x100e,0x100e,0x100c,0x100e,0x100e,0x100e,0x100e,0x1813,0x1813,0x1815,0x1817,0x181b,0x181b,0x181f,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,
0x0d40,0x0d40,0x0d40,0x181f,0x181b,0x1819,0x1815,0x1815,0x1811,0x1811,0x100e,0x100c,0x100a,0x100c,0x100a,0x100a,0x100a,0x100c,0x100a,0x100c,0x100e,0x1811,0x1811,0x1815,0x1815,0x1819,0x181b,0x181f,0x0d40,0x0d40,0x0d40,0x0d40,
0x0cc0,0x0cc0,0x0cc0,0x181d,0x181b,0x1817,0x1815,0x1811,0x1811,0x100c,0x100c,0x100a,0x100a,0x1008,0x1008,0x1008,0x1008,0x1008,0x100a,0x100a,0x100c,0x100c,0x1811,0x1811,0x1815,0x1817,0x181b,0x181d,0x0cc0,0x0cc0,0x0cc0,0x0cc0,
0x0c40,0x0c40,0x181d,0x181b,0x1817,0x1815,0x1811,0x1811,0x100c,0x100c,0x1008,0x1008,0x1006,0x1006,0x1006,0x1006,0x1006,0x1006,0x1006,0x1008,0x1008,0x100c,0x100c,0x1811,0x1811,0x1815,0x1817,0x181b,0x181d,0x0c40,0x0c40,0x0c40,
0x03a0,0x03a0,0x181d,0x1819,0x1817,0x1813,0x1811,0x100c,0x100c,0x1008,0x1008,0x1006,0x1006,0x1004,0x1004,0x1004,0x1004,0x1004,0x1006,0x1006,0x1008,0x1008,0x100c,0x100c,0x1811,0x1813,0x1817,0x1819,0x181d,0x03a0,0x03a0,0x03a0,
0x0320,0x181f,0x181b,0x1817,0x1813,0x1811,0x100e,0x100c,0x1008,0x1008,0x1006,0x1004,0x1002,0x1004,0x1002,0x1002,0x1002,0x1004,0x1002,0x1004,0x1006,0x1008,0x1008,0x100c,0x100e,0x1811,0x1813,0x1817,0x181b,0x181f,0x0320,0x0320,
0x02a0,0x181d,0x181b,0x1817,0x1813,0x100e,0x100e,0x100a,0x1008,0x1006,0x1006,0x1004,0x1004,0x1002,0x1002,0x1000,0x1002,0x1002,0x1004,0x1004,0x1006,0x1006,0x1008,0x100a,0x100e,0x100e,0x1813,0x1817,0x181b,0x181d,0x02a0,0x02a0,
0x0220,0x181d,0x1819,0x1815,0x1811,0x100e,0x100a,0x100a,0x1006,0x1006,0x1002,0x1002,0x1000,0x1002,0x1000,0x1000,0x1000,0x1002,0x1000,0x1002,0x1002,0x1006,0x1006,0x100a,0x100a,0x100e,0x1811,0x1815,0x1819,0x181d,0x0220,0x0220,
0x181f,0x181b,0x1819,0x1815,0x1813,0x100e,0x100c,0x1008,0x1008,0x1004,0x1004,0x1002,0x1002,0x1000,0x1000,0x1000,0x1000,0x1000,0x1002,0x1002,0x1004,0x1004,0x1008,0x1008,0x100c,0x100e,0x1813,0x1815,0x1819,0x181b,0x181f,0x0180,
0x181f,0x181b,0x1817,0x1815,0x1811,0x100e,0x100a,0x1008,0x1006,0x1004,0x1002,0x1002,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1002,0x1002,0x1004,0x1006,0x1008,0x100a,0x100e,0x1811,0x1815,0x1817,0x181b,0x181f,0x0100,
0x181f,0x181b,0x1819,0x1813,0x1811,0x100c,0x100c,0x1008,0x1006,0x1004,0x1004,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1004,0x1004,0x1006,0x1008,0x100c,0x100c,0x1811,0x1813,0x1819,0x181b,0x181f,0x0080,
0x181f,0x181b,0x1817,0x1815,0x1811,0x100e,0x100a,0x1008,0x1006,0x1004,0x1002,0x1002,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1000,0x1002,0x1002,0x1004,0x1006,0x1008,0x100a,0x100e,0x1811,0x1815,0x1817,0x181b,0x181f,0x0000,
0x181f,0x181b,0x1819,0x1815,0x1813,0x100e,0x100c,0x1008,0x1008,0x1004,0x1004,0x1002,0x1002,0x1000,0x1000,0x1000,0x1000,0x1000,0x1002,0x1002,0x1004,0x1004,0x1008,0x1008,0x100c,0x100e,0x1813,0x1815,0x1819,0x181b,0x181f,0x0080,
0x0100,0x181d,0x1819,0x1815,0x1811,0x100e,0x100a,0x100a,0x1006,0x1006,0x1002,0x1002,0x1000,0x1002,0x1000,0x1000,0x1000,0x1002,0x1000,0x1002,0x1002,0x1006,0x1006,0x100a,0x100a,0x100e,0x1811,0x1815,0x1819,0x181d,0x0100,0x0100,
0x0180,0x181d,0x181b,0x1817,0x1813,0x100e,0x100e,0x100a,0x1008,0x1006,0x1006,0x1004,0x1004,0x1002,0x1002,0x1000,0x1002,0x1002,0x1004,0x1004,0x1006,0x1006,0x1008,0x100a,0x100e,0x100e,0x1813,0x1817,0x181b,0x181d,0x0180,0x0180,
0x0220,0x181f,0x181b,0x1817,0x1813,0x1811,0x100e,0x100c,0x1008,0x1008,0x1006,0x1004,0x1002,0x1004,0x1002,0x1002,0x1002,0x1004,0x1002,0x1004,0x1006,0x1008,0x1008,0x100c,0x100e,0x1811,0x1813,0x1817,0x181b,0x181f,0x0220,0x0220,
0x02a0,0x02a0,0x181d,0x1819,0x1817,0x1813,0x1811,0x100c,0x100c,0x1008,0x1008,0x1006,0x1006,0x1004,0x1004,0x1004,0x1004,0x1004,0x1006,0x1006,0x1008,0x1008,0x100c,0x100c,0x1811,0x1813,0x1817,0x1819,0x181d,0x02a0,0x02a0,0x02a0,
0x0320,0x0320,0x181d,0x181b,0x1817,0x1815,0x1811,0x1811,0x100c,0x100c,0x1008,0x1008,0x1006,0x1006,0x1006,0x1006,0x1006,0x1006,0x1006,0x1008,0x1008,0x100c,0x100c,0x1811,0x1811,0x1815,0x1817,0x181b,0x181d,0x0320,0x0320,0x0320,
0x03a0,0x03a0,0x03a0,0x181d,0x181b,0x1817,0x1815,0x1811,0x1811,0x100c,0x100c,0x100a,0x100a,0x1008,0x1008,0x1008,0x1008,0x1008,0x100a,0x100a,0x100c,0x100c,0x1811,0x1811,0x1815,0x1817,0x181b,0x181d,0x03a0,0x03a0,0x03a0,0x03a0,
0x0c40,0x0c40,0x0c40,0x181f,0x181b,0x1819,0x1815,0x1815,0x1811,0x1811,0x100e,0x100c,0x100a,0x100c,0x100a,0x100a,0x100a,0x100c,0x100a,0x100c,0x100e,0x1811,0x1811,0x1815,0x1815,0x1819,0x181b,0x181f,0x0c40,0x0c40,0x0c40,0x0c40,
0x0cc0,0x0cc0,0x0cc0,0x0cc0,0x181f,0x181b,0x181b,0x1817,0x1815,0x1813,0x1813,0x100e,0x100e,0x100e,0x100e,0x100c,0x100e,0x100e,0x100e,0x100e,0x1813,0x1813,0x1815,0x1817,0x181b,0x181b,0x181f,0x0cc0,0x0cc0,0x0cc0,0x0cc0,0x0cc0,
0x0d40,0x0d40,0x0d40,0x0d40,0x0d40,0x181f,0x181b,0x181b,0x1817,0x1817,0x1813,0x1813,0x1811,0x1811,0x1811,0x1811,0x1811,0x1811,0x1811,0x1813,0x1813,0x1817,0x1817,0x181b,0x181b,0x181f,0x0d40,0x0d40,0x0d40,0x0d40,0x0d40,0x0d40,
0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x181f,0x181d,0x181b,0x1819,0x1819,0x1817,0x1817,0x1815,0x1815,0x1813,0x1815,0x1815,0x1817,0x1817,0x1819,0x1819,0x181b,0x181d,0x181f,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,0x0dc0,
0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x181d,0x181d,0x181b,0x181b,0x1819,0x1819,0x1817,0x1817,0x1817,0x1819,0x1819,0x181b,0x181b,0x181d,0x181d,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,0x0e60,
0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x181f,0x181d,0x181d,0x181b,0x181d,0x181b,0x181d,0x181b,0x181d,0x181d,0x181f,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,0x0ee0,
0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x181f,0x181f,0x181f,0x181f,0x181f,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,0x0f60,
0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0,0x0fe0
])
n2d.initBuffering()
n2d.clearBuffer(0xf000)
for(local i = 1; i < 200; i++)
{
n2d.drawSpriteScaled(sprite, 160, 120, i, i, 0, 0)
n2d.drawLine(i, i, i*2, 240, 0x0000)
n2d.updateScreen()
}
for(local i = 0; i < 480; i++)
n2d.updateScreen()
n2d.deinitBuffering()
[/spoiler]
Update time : Added N2DLib's fixed functions, fixed a few (useless) warnings and some functions. I included in the zip a script I did from scratch to show pretty things on the screen
Small edit : I found how to make libs from the script side:
Let's say you have a file a.nut, right? HEre's its content :
local function func()
{
return 42
}
# Explicit root table setting. I'm setting a global variable called a which contains the function func at the index f.
::a <- {"f" : f}So I can do from another script (or from the interpreter)
dofile("test.nut") // Loads file
print(a.f()) // a is now in the root table (::), so you can call its function f.
// And it'll print '42'
So yeah, I'm happily saying that Squirrel already allows user-scripted libraries :D So now, the biggest issue is organizing your libraries : Ndless doesn't allow relative paths IIRC (I need correction on this point but it was an issue on WRPG), like "subfolder/script.tns" but only absolutes path ("/documents/<path to your script>/subfolder/script.tns") which isn't really cool if you ever move your scripts not in the right place... I'll see what I can do to emulate this behaviour.
Nice progress Eiyeron. :)
That creature in the picture doesn't exactly look like a squirrel...?
I don't think it was meant to be a squirrel in particular?
Ndless does have relative paths : int enable_relative_paths(char **argv);.
Quite nice work :)
Quote from: Dudeman313 on April 03, 2016, 12:20:55 AM
That creature in the picture doesn't exactly look like a squirrel...?
(Look at the picture, I just used this one for fun.)
Quote from: matrefeytontias on April 03, 2016, 07:38:03 AM
Ndless does have relative paths : int enable_relative_paths(char **argv);.
This would have saved me quite a bit of time of work on WRPG (I recreated such thing with a custom path resolver). Thanks.
Quote from: Jim Bauwens on April 03, 2016, 11:43:22 AM
Quite nice work :)
Thanks Jim!
That's Psyduck from Pokémon 1st gen, right?
Yeah, it is.
Oh, I wouldn't know, being less than 20 years old and living sheltered from videogames. :P
Added a small poll to inquire people's opinion on how to call N2D's keys constants. Note that I can't let you do "RET" only because it's an enumeration constant and is processed compile time (so it'll be faster on the execution side).
Edit : using for now n2dk_ prefix, I finished implementing N2D's key detection functions. Have a try with the lastest script.
I don't know, but while the first option is longer in length, I find that it's easier to figure out what it's for, since key is in the name.
Added support of loadBMP which supports relative paths. No more heavy-arse source files.
Also made me discover an issue in Matref's loadBMP routine. I sent him a ticket about it : non-multiple of 16 (or 8, I dunno) bitmaps won't properly load and will be skewed. Let's wait until he works on it.
FInally gave in and published a new build. In the next days I'll build some kind of small documentation for the n2DLib binding. Note that as Squirrel's standard library is included, you could access files in read/write, you can have threads, coroutines and with N2DLib, acces the screen and the keyboard. I guess you have everything you would need to make some games, haven't you?
What should be included next? Some ndless syscalls?
Link to a screenshot : Here (webm) (http://i.imgur.com/UYG5VmZ.webm) GIF version (http://i.imgur.com/UYG5VmZ.gif)
Woah, that zoom effect is very smooth and fast O.O. Same for the balls moving around. I'm glad to see this language is running at very fast speed. At least advanced Nspire game programmers now have more choice :D
Well, according to the poll, I tried to set n2d as prefix for keys, but couldn't as it would override the function table, so the prefix will stay n2dk.
I'm making the doc for the v1.0. I'll also switch from hosting the source in the topic to ticalc (and eventually CW if you want so. Should I also move my small experiment to your download section instead of letting it in the topic? I already told it was a final version.)
Version 1.0.0 released.
"Allez, bisous." - Captain Nakou
Awesome! I'll append this topic to the downloads section as soon as we have a non-game section. :) You don't need to do anything other than making sure the first post has a link to v1.0.
Also does it mean that Squirrel for Nspire is 100% complete?
The first version is, indeed, complete. The interpreter works as expected on the example scripts and I could program something interactive with it. Next versions could embed more libraries and functions but that's only something for later. (My first thought came to lodepng which allows loading PNGs and have a cool open source licence. I'm already using it in WRPG)
Looks like this is really shaping up. Nice job :)
An example with lots of comments will come a little later, with a bugfix about some things that I overlooked (like a wrong argument usage on drawSpritePart and wrong key names setting).
Wow, this looks great! What is the performance like compared to micropython, duktape, and Nspire Lua?
Yeah it'd be nice to compare the same algorithms on those different languages/implementations
We had already done that here with simple things with timings&graphs: https://tiplanet.org/forum/viewtopic.php?f=43&t=16900 and the codes are very easy to port and try.
Well, it'll be probably slower than lua. From what I read, lua is probably better because the memory, GC based, uses cache better than a refcounting system. But the GC can hit more or less when it wants and I don't know if you can opt for refcounting on lua on nspire.
There is a lot of discussion and people (not really interested in benchmark because today we have highs performance CPU everywhere except in calculators) tends to say that in benchmarks, Squirrel is slower than Lua. The former also have a little bit more of features than the latter (citation needed) but heh, it's still another solution you get.
I wish I could have tried luajit on Nspires. Alas, the way Ndless is built made me give up as references to the built-in VM overrid each time the JIT's library/code...
So yeah, the main changes are in the memory stuff.
Found this (https://github.com/r-lyeh/scriptorium). Where I'm not too found of benchmarks (because you can easily fool a noob by screwing up a script on a language and stuff), I'd like to point at Tcl's position...
My last point is the difference of community size between Lua's and Squirrel's. The latter has a good performance against Lua where the community is radically smaller (lua is almost everywhere...)
Edit : oh, also, is Lua@Nspire event-based? I remember seeing that you couldn'take tight loops for games (like just an update-render). In my demos I'm just making a while loop and draw the frame after updating it. How does Lua on Nspire work in that way?
I should try this, gotta dust off my nspire :P
Quote from: aeTIos on April 08, 2016, 01:06:08 PM
I should try this, gotta dust off my nspire :P
I thought you Nspire's USB port was broken
Quote from: aeTIos on April 08, 2016, 01:06:08 PM
I should try this, gotta dust off my nspire :P
Wait until the 1.0.1. Just need to fool-proof my detailled example script and I'll release it.
Just poking that the 1.0.1 with the correct keys naming convention and a sokoban as game example is released : https://github.com/Eiyeron/squirrel/releases/tag/nsquirrel_1.0.1
That game looks cool. :D Also we really need a page on the forums that explains all language options available on each calculator. But I would probably need the help of
@Adriweb or
@critor for TI-Nspire languages, because I forgot which ones are available besides Squirrel, C, C++, Javascript, Micropython, ASM, Lua and TI-Basic.
Did you make those graphics, by the way?
Yeah I did them.
Cool, because I like them :3=
Another example is being programmed.
That looks cool. :) Shouldn't it be a bit bigger, though? (unless you plan to scale it up to 160x120)
Nice Duke! Maybe I will actually use my nSpire then :P
Quote from: alexgt on May 13, 2016, 02:17:58 AM
Nice Duke! Maybe I will actually use my nSpire then :P
This sentence sums up what I feared from the Nspire scene? "Oh? A new thing for them? Meh". Can we declare the official death of the Nspire scene and forget this calculator so we don't have to do it later?
Quote from: Ivoah on April 08, 2016, 01:12:33 PM
Quote from: aeTIos on April 08, 2016, 01:06:08 PM
I should try this, gotta dust off my nspire :P
I thought you Nspire's USB port was broken
That's my 84+ :/ A real shame. Eiyeron: I'll be sending this to my nspire sometime soon. (think: tomorrow or the day after)
Will report back.
Quote from: Duke "Tape" Eiyeron on May 13, 2016, 07:25:20 AM
Quote from: alexgt on May 13, 2016, 02:17:58 AM
Nice Duke! Maybe I will actually use my nSpire then :P
This sentence sums up what I feared from the Nspire scene? "Oh? A new thing for them? Meh". Can we declare the official death of the Nspire scene and forget this calculator so we don't have to do it later?
I wouldn't say it's dead, in fact it's more active than the fx-CG20 and HP Prime, but from 2011 to 2014 TI alienated most prominent Nspire coders by repeatedly locking down their calcs against Ndless development, so there are a lot fewer Nspire projects now.
I wouldn't recommend giving up, but for future projects it might be a good move to make them cross-compatible between the TI-Nspire and TI-83 Premium CE or at least between the Nspire and fx-CG20.
I think the main reason for Nspire activity declining is that it's just not special.
The Nspire is just way too close to smartphones and there is nothing special and hard about development.
No hard restrictions like a Z80, 1bit greyscale etc. just a "normal" embedded ARM system.
Also, there are not that many Nspire users as TI-[0-99] users and even there the developer/user ratio is quite small.
QuoteI wouldn't recommend giving up, but for future projects it might be a good move to make them cross-compatible between the TI-Nspire and TI-83 Premium CE or at least between the Nspire and fx-CG20.
Not really. The platforms are too different (just from a performance standpoint) for it to work out.
Ah yeah I forgot about the non-special factor. Most calc programmers started calc programming because they liked to push old-school platforms with 80's style technical specs to their limits and make them achieve things that no one thought that could ever be possible before.
The TI-Nspire caught on at first because smartphone games were not that popular when Ndless came out. But then smartphones got much more powerful and unlike the TI-84 Plus CE, the TI-Nspire CX lacked the charm from vintage platforms. It's a shame, though. Also I bet that if the Nspire CX had a BASIC-like language that could do decent games, but more old-school than Lua, then it might have gotten quite a following, just like PICO-8 on the PC.
But seriously, while the Nspire CX activity declined over the year, it was much more severe around when TI released hardware J and OS 3.2.4. Hardware J and OS 3.2.4 seemed like the final nail in the coffin at the time, so many developers left. Plus back then, Lua was much slower and less powerful, or at least if it got more powerful then it took too long before people finally realized it.
Also console emulators probably made some game programmers reluctant about making brand new games for the platform, since their smaller games would have to compete head-on against big franchises. But of course it depends of how people sees it. Some people might just want to make new games just for the sake of creativity.
Also, it's possible that some schools switched to the color TI-84+ models.
Also about cross-compatibility I wasn't necessarily refering to big projects, but rather smaller ones. For example, Axe Parser for both the Nspire CX and 84+CE would be nice, same for C versions of Reuben Quest, for example, both of which ran on 6 MHz calculators fine.
Quote from: DJ Omnimaga on May 14, 2016, 04:59:34 AM
Ah yeah I forgot about the non-special factor. Most calc programmers started calc programming because they liked to push old-school platforms with 80's style technical specs to their limits and make them achieve things that no one thought that could ever be possible before.
The TI-Nspire caught on at first because smartphone games were not that popular when Ndless came out. But then smartphones got much more powerful and unlike the TI-84 Plus CE, the TI-Nspire CX lacked the charm from vintage platforms. It's a shame, though. Also I bet that if the Nspire CX had a BASIC-like language that could do decent games, but more old-school than Lua, then it might have gotten quite a following, just like PICO-8 on the PC.
But seriously, while the Nspire CX activity declined over the year, it was much more severe around when TI released hardware J and OS 3.2.4. Hardware J and OS 3.2.4 seemed like the final nail in the coffin at the time, so many developers left. Plus back then, Lua was much slower and less powerful, or at least if it got more powerful then it took too long before people finally realized it.
Also console emulators probably made some game programmers reluctant about making brand new games for the platform, since their smaller games would have to compete head-on against big franchises. But of course it depends of how people sees it. Some people might just want to make new games just for the sake of creativity.
Also, it's possible that some schools switched to the color TI-84+ models.
Also about cross-compatibility I wasn't necessarily refering to big projects, but rather smaller ones. For example, Axe Parser for both the Nspire CX and 84+CE would be nice, same for C versions of Reuben Quest, for example, both of which ran on 6 MHz calculators fine.
I agree, I first started programming on my 84+ to make games but also it was super easy to make a good equation solver :P. Now I code on the Prime since it is so powerful but not too powerful that you can have crappy code and make a FPS :P
I faced some issues with the interpreter now, I'd like people to check them (specially the second one, as it'll impact the scriting language/functionality)
https://github.com/Eiyeron/squirrel/issues
(And now, I just had he idea of porting another version of the interpreter to the 3DS,
it's not happening yet >.>)
Also, still poking
@matrefeytontias to ask him to fix his loadBMP function as it blocks a programmer from using a non multiple of 8-sized bitmap. (Also I might ask help from Vogtinator to see what could fail with the first issue. Any ideas to set up DDD and firebird correctly? Or a better debugger coudl also match my needs, thanks in advance.)
Oh yeah. That. On it.
Alright, fixed and tested. I pushed it to Github.
Well! This seems to be turning out pretty well. I was too lazy to look but can you program with this on-calc? ;)
Quote from: SiphonicSugar on May 15, 2016, 09:19:34 PM
Well! This seems to be turning out pretty well. I was too lazy to look but can you program with this on-calc? ;)
Yep, as it's a scripting language you can use any editor you want.
Well, this is great, I'm looking forward to using something new on Nspire.
Quote from: matrefeytontias on May 15, 2016, 08:47:21 PM
Alright, fixed and tested. I pushed it to Github.
Thanks
Quote from: Ivoah on May 15, 2016, 09:30:25 PM
Quote from: SiphonicSugar on May 15, 2016, 09:19:34 PM
Well! This seems to be turning out pretty well. I was too lazy to look but can you program with this on-calc? ;)
Yep, as it's a scripting language you can use any editor you want.
Indeed, even though I have yet to find a good text editor for nspire (nTxt almost bricked my calc once), you can directly code on it. YOu'll have just to send yourself some pictures to the calc.
Edit : Weeell, the float issue is deeper in the code than expected, I have to discern where the system doesn't get the float. Also, the next version will get the updates of the original version, which includes a printf function to avoid print(format(meh))
Edit 2 : I have opened the gate to hell, Vog and me don't know the hell what's happening from my side. Vogtinator's builds works (and the float issue is fixed) where mine are more and more broken. 8|
Ouch, good luck fixing those issues. I hope it's not related to mysterious hardware differences or something.
Dang, I hope you can get this sorted out :/ I am really looking forward to more progress ;)
@Vogtinator, do you think the problem comes from the OS I'm using on my calc? I'm using a good old 3.1. Yeah, I'm still trying to corner that issue but dang, I still don't understand why it happens.
Edit : Doing a gcc -Q -v sq.c in sq/
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC)
COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-pie' '-fstack-check=specific' '-fstack-protector-strong' '-Q' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1 -v sq.c -dumpbase sq.c -mtune=generic -march=x86-64 -auxbase sq -version -fPIE -fstack-check=specific -fstack-protector-strong -o /tmp/cc2My5U3.s
GNU C11 (GCC) version 6.1.1 20160501 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160501, GMP version 6.1.0, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
/usr/include
End of search list.
GNU C11 (GCC) version 6.1.1 20160501 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160501, GMP version 6.1.0, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed: -v sq.c -mtune=generic -march=x86-64 -fPIE
-fstack-check=specific -fstack-protector-strong
options enabled: -fPIC -fPIE -faggressive-loop-optimizations
-fasynchronous-unwind-tables -fauto-inc-dec -fchkp-check-incomplete-type
-fchkp-check-read -fchkp-check-write -fchkp-instrument-calls
-fchkp-narrow-bounds -fchkp-optimize -fchkp-store-bounds
-fchkp-use-static-bounds -fchkp-use-static-const-bounds
-fchkp-use-wrappers -fcommon -fdelete-null-pointer-checks -fdwarf2-cfi-asm
-fearly-inlining -feliminate-unused-debug-types -ffunction-cse -fgcse-lm
-fgnu-runtime -fgnu-unique -fident -finline-atomics -fira-hoist-pressure
-fira-share-save-slots -fira-share-spill-slots -fivopts
-fkeep-static-consts -fleading-underscore -flifetime-dse
-flto-odr-type-merging -fmath-errno -fmerge-debug-strings -fpeephole -fplt
-fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic
-fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
-fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
-fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion
-fsemantic-interposition -fshow-column -fsigned-zeros
-fsplit-ivs-in-unroller -fssa-backprop -fstack-protector-strong
-fstdarg-opt -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math
-ftree-cselim -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im
-ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
-ftree-phiprop -ftree-reassoc -ftree-scev-cprop -funit-at-a-time
-funwind-tables -fvar-tracking -fvar-tracking-assignments
-fzero-initialized-in-bss -m128bit-long-double -m64 -m80387
-malign-stringops -mavx256-split-unaligned-load
-mavx256-split-unaligned-store -mfancy-math-387 -mfp-ret-in-387 -mfxsr
-mglibc -mieee-fp -mlong-double-80 -mmmx -mno-sse4 -mpush-args -mred-zone
-msse -msse2 -mstv -mtls-direct-seg-refs -mvzeroupper
Compiler executable checksum: 2b52ee45146df7b1f5b2606d8e51eb15
__bswap_32 __bswap_64 quit printfunc errorfunc PrintVersionInfos PrintUsage getargs Interactive main
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes> <free-inline-summary> <whole-program> <targetclone> <inline>Assembling functions:
<dispachercalls> <simdclone> quit printfunc errorfunc PrintVersionInfos PrintUsage getargs Interactive main
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 1070 kB (33%) ggc
phase parsing : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 1364 kB (42%) ggc
phase opt and generate : 0.01 (100%) usr 0.01 (100%) sys 0.02 (50%) wall 793 kB (25%) ggc
callgraph optimization : 0.00 ( 0%) usr 0.01 (100%) sys 0.00 ( 0%) wall 12 kB ( 0%) ggc
df scan insns : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 0 kB ( 0%) ggc
preprocessing : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 415 kB (13%) ggc
tree SSA other : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 1 kB ( 0%) ggc
rest of compilation : 0.01 (100%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 21 kB ( 1%) ggc
TOTAL : 0.01 0.01 0.04 3237 kB
COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-pie' '-fstack-check=specific' '-fstack-protector-strong' '-Q' '-v' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccCGH8yS.o /tmp/cc2My5U3.s
GNU assembler version 2.26.0 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.26.0.20160501
COMPILER_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/hardening-wrapper/bin/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' '/usr/lib/hardening-wrapper/bin' '-fPIE' '-pie' '-fstack-check=specific' '-fstack-protector-strong' '-Q' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/collect2 -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccs5XZdH.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/crtbeginS.o -L/usr/lib/hardening-wrapper/bin -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../.. /tmp/ccCGH8yS.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crtn.o
/tmp/ccCGH8yS.o: In function `quit':
sq.c:(.text+0x3f): undefined reference to `sq_getuserpointer'
/tmp/ccCGH8yS.o: In function `getargs':
sq.c:(.text+0x39c): undefined reference to `sq_enabledebuginfo'
sq.c:(.text+0x4d7): undefined reference to `sqstd_loadfile'
sq.c:(.text+0x50d): undefined reference to `sqstd_writeclosuretofile'
sq.c:(.text+0x538): undefined reference to `sqstd_loadfile'
sq.c:(.text+0x554): undefined reference to `sq_pushroottable'
sq.c:(.text+0x591): undefined reference to `sq_pushstring'
sq.c:(.text+0x5bd): undefined reference to `sq_call'
sq.c:(.text+0x5d5): undefined reference to `sq_gettype'
sq.c:(.text+0x602): undefined reference to `sq_getinteger'
sq.c:(.text+0x61c): undefined reference to `sq_getlasterror'
sq.c:(.text+0x633): undefined reference to `sq_getstring'
/tmp/ccCGH8yS.o: In function `Interactive':
sq.c:(.text+0x6f2): undefined reference to `sq_pushroottable'
sq.c:(.text+0x70f): undefined reference to `sq_pushstring'
sq.c:(.text+0x728): undefined reference to `sq_pushuserpointer'
sq.c:(.text+0x743): undefined reference to `sq_newclosure'
sq.c:(.text+0x75c): undefined reference to `sq_setparamscheck'
sq.c:(.text+0x777): undefined reference to `sq_newslot'
sq.c:(.text+0x78b): undefined reference to `sq_pop'
sq.c:(.text+0x983): undefined reference to `sq_getscratchpad'
sq.c:(.text+0x9c0): undefined reference to `sq_getscratchpad'
sq.c:(.text+0x9e2): undefined reference to `sq_getscratchpad'
sq.c:(.text+0xa38): undefined reference to `sq_gettop'
sq.c:(.text+0xa69): undefined reference to `sq_compilebuffer'
sq.c:(.text+0xa81): undefined reference to `sq_pushroottable'
sq.c:(.text+0xaa1): undefined reference to `sq_call'
sq.c:(.text+0xad1): undefined reference to `sq_pushroottable'
sq.c:(.text+0xaee): undefined reference to `sq_pushstring'
sq.c:(.text+0xb04): undefined reference to `sq_get'
sq.c:(.text+0xb13): undefined reference to `sq_pushroottable'
sq.c:(.text+0xb29): undefined reference to `sq_push'
sq.c:(.text+0xb47): undefined reference to `sq_call'
sq.c:(.text+0xb75): undefined reference to `sq_settop'
/tmp/ccCGH8yS.o: In function `main':
sq.c:(.text+0xbe7): undefined reference to `sq_open'
sq.c:(.text+0xc05): undefined reference to `sq_setprintfunc'
sq.c:(.text+0xc11): undefined reference to `sq_pushroottable'
sq.c:(.text+0xc1d): undefined reference to `sqstd_register_bloblib'
sq.c:(.text+0xc29): undefined reference to `sqstd_register_iolib'
sq.c:(.text+0xc35): undefined reference to `sqstd_register_systemlib'
sq.c:(.text+0xc41): undefined reference to `sqstd_register_mathlib'
sq.c:(.text+0xc4d): undefined reference to `sqstd_register_stringlib'
sq.c:(.text+0xc59): undefined reference to `sqstd_seterrorhandlers'
sq.c:(.text+0xc8f): undefined reference to `sq_close'
collect2: error: ld returned 1 exit status
It lacks the library functions because I didn't linked them, that's normal.
3.1 has some issues with stack and heap alignment, but the heap issue is worked around in libsyscalls and nothing uses the OS's printf.
You can still try a different version though, that's the way bugs get discovered ;-)
Quote
Doing a gcc -Q -v sq.c in sq/
I doubt that the host compiler is relevant here.
Quote from: Vogtinator on May 20, 2016, 06:18:34 PM
3.1 has some issues with stack and heap alignment, but the heap issue is worked around in libsyscalls and nothing uses the OS's printf.
You can still try a different version though, that's the way bugs get discovered ;-)
Quote
Doing a gcc -Q -v sq.c in sq/
I doubt that the host compiler is relevant here.
I have nothing right now to test other versions. What'd I need? Also dang, didn't thought of the command
Using built-in specs.
COLLECT_GCC=/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/libexec/gcc/arm-none-eabi/6.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-6.1.0/configure --target=arm-none-eabi --prefix=/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install --enable-interwork --enable-multilib --enable-languages=c,c++ --with-system-zlib --with-newlib --with-headers=../newlib-2.4.0/newlib/libc/include --disable-threads --disable-tls --disable-shared --with-gnu-as --with-gnu-ld --with-float=soft --disable-werror
Thread model: single
gcc version 6.1.0 (GCC)
COLLECT_GCC_OPTIONS='-mcpu=arm926ej-s' '-D' '_TINSPIRE' '-fuse-ld=gold' '-Q' '-v' '-I' '/home/eiyeron/.ndless/include' '-I' '/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include' '-I' '/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include/freetype2' '-mfloat-abi=soft'
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/libexec/gcc/arm-none-eabi/6.1.0/cc1 -v -I /home/eiyeron/.ndless/include -I /home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include -I /home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include/freetype2 -D__USES_INITFINI__ -D _TINSPIRE sq.c -dumpbase sq.c -mcpu=arm926ej-s -mfloat-abi=soft -auxbase sq -version -fuse-ld=gold -o /tmp/ccFutJv6.s
GNU C11 (GCC) version 6.1.0 (arm-none-eabi)
compiled by GNU C version 6.1.1 20160501, GMP version 6.1.0, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
#include "..." search starts here:
#include <...> search starts here:
/home/eiyeron/.ndless/include
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include/freetype2
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/6.1.0/include
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/6.1.0/include-fixed
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/6.1.0/../../../../arm-none-eabi/sys-include
/home/eiyeron/Git/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/6.1.0/../../../../arm-none-eabi/include
End of search list.
GNU C11 (GCC) version 6.1.0 (arm-none-eabi)
compiled by GNU C version 6.1.1 20160501, GMP version 6.1.0, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed: -v -I /home/eiyeron/.ndless/include
-I /home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include
-I /home/eiyeron/Git/Ndless/ndless-sdk/toolchain/../bin/../include/freetype2
-D__USES_INITFINI__ -D _TINSPIRE sq.c -mcpu=arm926ej-s -mfloat-abi=soft
-fuse-ld=gold
options enabled: -faggressive-loop-optimizations -fauto-inc-dec
-fchkp-check-incomplete-type -fchkp-check-read -fchkp-check-write
-fchkp-instrument-calls -fchkp-narrow-bounds -fchkp-optimize
-fchkp-store-bounds -fchkp-use-static-bounds
-fchkp-use-static-const-bounds -fchkp-use-wrappers -fcommon
-fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
-feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fgnu-runtime
-fgnu-unique -fident -finline-atomics -fira-hoist-pressure
-fira-share-save-slots -fira-share-spill-slots -fivopts
-fkeep-static-consts -fleading-underscore -flifetime-dse
-flto-odr-type-merging -fmath-errno -fmerge-debug-strings -fpeephole -fplt
-fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic
-fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
-fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
-fsched-spec-insn-heuristic -fsched-stalled-insns-dep
-fsemantic-interposition -fshow-column -fsigned-zeros
-fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt
-fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim
-ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
-ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop
-ftree-reassoc -ftree-scev-cprop -funit-at-a-time -fvar-tracking
-fvar-tracking-assignments -fzero-initialized-in-bss -marm -mlittle-endian
-mpic-data-is-text-relative -msched-prolog -mvectorize-with-neon-quad
Compiler executable checksum: 2b38d8d69bad79a1240417c94b13d221
__sputc_r bintime_addx bintime_add bintime_sub bintime_mul bintime_shift sbintime_getsec bttosbt sbttobt bintime2timespec timespec2bintime bintime2timeval timeval2bintime sbttots tstosbt sbttotv tvtosbt halt bkpt
sq.c:14:22: fatal error: squirrel.h: No such file or directory
#include <squirrel.h>
^
compilation terminated.
Found the origin of the issue : the 3.1 release of Ndless has a quirk that's cancelled out by nSquirrel (an unaligned sp register). Newer releases fixes this issue, making nSquirrel fail on the floating point part.
I don't know how to fix it for now but here's the next features for the 1.1 (breaking changes ahead):
- Keep squirrel's master source up to date
- Fixed an example
- New printf function for printf addicts (was in squirrel).
And here are the planned (yet not done) features:
- Fix and move LoadBMP to another namespace
- add lodePNG's load PNG routine to said namespace
- New example (a breakout)
No ideas of feature? I'd see something like a tilemap helper or something in the likes of but it'd limit the engine's flexibility. It's a language, not a game engine.
Yeah it should ve kept as language IMHO. But you could include tools that are separate but can help for map making or stuff like that.
Looks like the floating point bug is actually an issue with the combo "recent Ndless version" and Nspire OS 3.1. Vog just told me that 3.1 is just broken so I may have to switch for 3.4. :|
Edit : So yeah, some recent versions of Ndless breaks in some ways on 3.1, for instance on such issue, acocrding to what I understood. I'll just add a warning on the readme.
Edit 2 : Yu know what? F*** this. I'm just sick of waiting like 5 hours for a single line reply because there is a variable in the equation that hasn't been toyed with. I'm just sick of waiting for an issue that only happens to
me and when I can't nail it correctly. So screw it, if you meet this problem, update your calc or forget it. I'm sick of waiting.
@Vogtinator, if you're on any IM, I'll be
very happy to know how I can join it to be able to talk at the pace my mind goes because it's been very frustrating to wait for hours if not days for a single clue. I've nothing against you, don't take it personnal, it's just my patience that just ran short and I *want* to move forwards from this piece of WTF.
Quote from: Duke "Tape" Eiyeron on June 18, 2016, 02:23:05 PM
Looks like the floating point bug is actually an issue with the combo "recent Ndless version" and Nspire OS 3.1. Vog just told me that 3.1 is just broken so I may have to switch for 3.4. :|
It's not 100% sure that it is actually the OS, it's just most likely.
Quote
@Vogtinator, if you're on any IM, I'll be very happy to know how I can join it to be able to talk at the pace my mind goes because it's been very frustrating to wait for hours if not days for a single clue. I've nothing against you, don't take it personnal, it's just my patience that just ran short and I *want* to move forwards from this piece of WTF.
If I'm on, I'm most likely on #firebird-emu on efnet.
I would be ok if OS 3.1 isn't supported, since the only justification to stick to OS 3.1 anymore is smaller size IIRC (due to newer versions of Ndless and tools allowing reboot-proof Ndless on recent versions, for example), but it would kinda suck if there was absolutely zero way to get this to work properly on 3.1 due to some OS 3.1 or Ndless 3.1 limitations. On the other hand, if working around that limitation adds slowdowns or requires you to release two separate versions of nSquirrel, then perhaps it's better to give up on OS 3.1 support.