Recent changes to feature-requests

Update to use structured text editor

2010-09-20T10:17:07Z

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

2010-09-19T12:10:38Z

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

2010-09-19T12:09:39Z

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

2010-01-08T13:32:13Z

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.

2009-10-15T17:49:40Z

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

2009-09-20T21:05:20Z

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

2009-09-06T18:14:51Z

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

2009-07-16T12:05:14Z

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

2009-07-16T11:23:57Z

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

2009-07-05T16:35:27Z

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.