Recent changes to feature-requests

Update to use structured text editor

Haravikk — Mon, 20 Sep 2010 10:17:07 -0000

In the new Eclipse Helios release there is a more formal structured text editor which seems to standardise a lot of features across different languages, including better handling of all types of brackets, formatting, text-encoding, and also access to the tasks feature.

If LSL Plus could be updated to use structured text editors then it should allow it to take advantage of a number of neat features without needing to do any of the grunt work.

Add support for packages

Haravikk — Sun, 19 Sep 2010 12:10:38 -0000

Fairly simple, but it'd be nice to be able to mimic packages and have the LSL view implement the same behaviours for displaying packages more neatly rather than as a stack of nested folders.

Native Java engine

Haravikk — Sun, 19 Sep 2010 12:09:39 -0000

Fairly simply this is a proposal to replace the Haskell engine with a native Java one for maximum compatibility across platforms and removing the need for the extra build stage. I realise that Haskell is quite concise, but it seems there are few advantages to using it when a native Java component could offer greater performance and take advantage of more of the compilation/processing features of Eclipse to avoid overly long delays etc.

break and continue

Anonymous — Fri, 08 Jan 2010 13:32:13 -0000

It would be cool if you could make the compiler translate break and continue statements into the appropriate jumps. It would clean up a lot of "jump break01;" and "jump continue01;" mess, lol.

Thanks!

Pass comments toggle for options.

Anonymous — Thu, 15 Oct 2009 17:49:40 -0000

While using LSLP, I am very much against is behaviour where it strips out large numbers of my comments - even when I'm not using the optimizer, it seems to strip out comments inside all imported functions and inside all states.

Please add a toggle to the options/preferences to switch off this behaviour, and pass all comments through to the generated code. Thank you.

Support for .lsl files without .lslp

Domagoj Klepac — Sun, 20 Sep 2009 21:05:20 -0000

Currently, lslplus thinks of .lsl files only as of .lslp counterparts. By opening .lsl files in the same editor as .lslp files (meaning coloring and code assist), it would be possible to have .lsl files without .lslp files and .lslp extensions, thus allowing to avoid code duplication when it's not needed.

I suppose this would also mean that "This file is derived. Do you really want to edit it?" would have to be tweaked to show only if edited .lsl file has .lslp counterpart.

String Constant Folding

IcyNeko — Sun, 06 Sep 2009 18:14:51 -0000

Would be nice if strings were also considered for folding.

Example:

string FOO = "bar";
default {
state_entry() {
llOwnerSay(FOO);
}
}

would then optimize to:

default {
state_entry() {
llOwnerSay("bar");
}
}

Joining constants

Haravikk — Thu, 16 Jul 2009 12:05:14 -0000

Fairly simple in theory, but possibly complex in practise. The idea here is that if several constants are concatenated (as can happen as a result of the optimisation process), then it may be worth joining these together.

For example:

string getLabel(integer v) { return llList2String(["Label1", "Label2", "Label3"], v);

default {
state_entry() {
llOwnerSay("[" + getLabel(2) + "] " + (string)llGetFreeMemory());
}
}

This will result in the state_entry() becoming:

llOwnerSay("[" + "Label3" + "] " + (string)llGetFreeMemory());

This isn't really ideal, as it should become:

llOwnerSay("[Label3] " + (string)llGetFreeMemory());

As this will be more efficient. However, it'll require a table of possible optimisations, as in some cases it is more efficient (on memory) to concatenate two common strings, rather than storing the concatenated form ready-made, which is where things get a bit complicated.

Fully eliminate redundant functions

Haravikk — Thu, 16 Jul 2009 11:23:57 -0000

Currently LSL plus won't full eliminate traces of a function whose contents are removed.

If you have the following function:

// pragma inline
function debug(string s, integer debug) {
if (debug) llOwnerSay(s);
}

Using it in the following simplified code:

integer DEBUG() { return TRUE; }

default {
state_entry() {
debug("Script started", DEBUG());
}
}

If you leave DEBUG() as TRUE, then you get the expected results whereby debug() is replaced by:

string s = "Script started";
llOwnerSay(s);

This could be further optimised (replace references to s) but that's another issue. However, if you set DEBUG() to FALSE, then the following code is produced:

string s = "Script started";

This isn't desirable, as it seems to actually make it through the compile process in Mono to take up memory, even though it's never used anywhere. In cases such as these LSL plus should be able to identify that a variable it created for inlining is never used, and eliminate it.

Report unused variables/functions

Haravikk — Sun, 05 Jul 2009 16:35:27 -0000

Quite simply; any variables or functions ignored by LSL plus due to never being used, should appear as warnings in Eclipse. It would be cool if this could also work correctly across modules to highlight functions that none of your scripts are using, but this could get complicated.