Difference between revisions of "Talk:LSL Language Test"
(New section: Size) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 32: | Line 32: | ||
-- {{User|Scouse Linden}} 21:53, 5 February 2008 | -- {{User|Scouse Linden}} 21:53, 5 February 2008 | ||
It is definitely an error in LSO. It should return 1.0, it should NOT return 0.0. What it currently returns is not infact 0.0 but 0x1p-149 (use [[Float2Hex]] to show this). What is happening is that an integer is being pushed into a stack position that later gets read back out as a float. This is most definitely a compiler error, integer to float conversion has an implicit typecast but it seems that the compiler forgot to make it explicit. It would be nice to have some LSL function that does two way conversions from floats to integers and back based on how they are stored in memory. -- [[User:Strife Onizuka|Strife Onizuka]] 11:30, 5 February 2008 (PST) | It is definitely an error in the LSO compiler. It should return 1.0, it should NOT return 0.0. What it currently returns is not infact 0.0 but 0x1p-149 (use [[Float2Hex]] to show this). What is happening is that an integer is being pushed into a stack position that later gets read back out as a float. This is most definitely a compiler error, integer to float conversion has an implicit typecast but it seems that the compiler forgot to make it explicit. It would be nice to have some LSL function that does two way conversions from floats to integers and back based on how they are stored in memory. -- [[User:Strife Onizuka|Strife Onizuka]] 11:30, 5 February 2008 (PST) | ||
== Size == | |||
I've got a problem, I was about to release a new version of the script... but it's too big to compile in LSO. It's all the function calls, they eat up the memory and stack. -- [[User:Strife Onizuka|Strife Onizuka]] 14:37, 6 February 2008 (PST) | |||
Latest revision as of 14:37, 6 February 2008
<lsl> // post increment.
i = 1;
ensureIntegerEqual("i = 1; (i == 2) && (i++ == 1)", (i == 2) && (i++ == 1), TRUE);
// pre increment.
i = 1;
ensureIntegerEqual("i = 1; (i == 2) && (++i == 2)", (i == 2) && (++i == 2), TRUE);
// post decrement.
i = 2;
ensureIntegerEqual("i = 2; (i == 1) && (i-- == 2)", (i == 1) && (i-- == 2), TRUE);
// pre decrement.
i = 2;
ensureIntegerEqual("i = 2; (i == 1) && (--i == 1)", (i == 1) && (--i == 1), TRUE);</lsl>
These tests are good for LSO-LSL but do we want to propagate this order of execution to Mono-LSL? -- Strife Onizuka 19:16, 7 December 2007 (PST)
LSO failure
Is this expected under the existing system?
FAILED: testReturnFloat() (0.000000 expected 1.000000)
It only happens if you try returning an int as a float - returning a float as a float works as expected. I can't test behaviour under mono because there isn't a TG beta grid. - Katharine Berry 11:08, 4 February 2008 (PST)
Yes, look at the test. <lsl> float testReturnFloat() {
return 1;
} </lsl> Do you think it should be 0.0 or 1.0? We may fix this LSL2 bug once we have fewer Mono bugs to fix. -- Scouse Linden 21:53, 5 February 2008
It is definitely an error in the LSO compiler. It should return 1.0, it should NOT return 0.0. What it currently returns is not infact 0.0 but 0x1p-149 (use Float2Hex to show this). What is happening is that an integer is being pushed into a stack position that later gets read back out as a float. This is most definitely a compiler error, integer to float conversion has an implicit typecast but it seems that the compiler forgot to make it explicit. It would be nice to have some LSL function that does two way conversions from floats to integers and back based on how they are stored in memory. -- Strife Onizuka 11:30, 5 February 2008 (PST)
Size
I've got a problem, I was about to release a new version of the script... but it's too big to compile in LSO. It's all the function calls, they eat up the memory and stack. -- Strife Onizuka 14:37, 6 February 2008 (PST)