Crashes with 1.10.0.32 - any tips?

Highlights all syntax errors in real time? That's pretty cool, I have to admit.

I've got emacs LSL syntax highlighting, but it doesn't notice when I misspell a variable, or leave off a semicolon (damn those!). I like being able to see those little bugs fast. Sure, I know whether the function I'm using is named right, but not whether I'm passing the right number and type of parameters.

If vi can highlight errors like that, I'm honestly impressed.

Ahh, you are correct, you would need to go toss in some time to make LSL understood by Eclipse for that sort of functionality directly in the editor.

Or I suppose you could use lslint to validate variables and stuff. Be one of those cute Makefiles in your code directory for stuff so you could ":make <file>" from within vim, Makefile just sets the CC and CFLAGS correctly for the %.lsl suffix, and lslint spits out the appopriate error, vim sees them and pulls the editor to that line of the code.

Corse, if one isn't happy with lslint it isn't a terribly big deal to write lexical parser for LSL in lex or something and have it do the same thing as lslint, which is basically tokenize everything, validate its consistency, and throw an appropriate error in a format that the editor understands well. Something the average editor supports would just be close to the same error output gcc gives. Then the editor would see the error and take you to the correct line.

Not to sound like a smartass or anything, but, I am failing to see why any of these options aren't viable and why it is I seem to be the only one pointing them out. I would like to think I am some sort of brilliant person for thinking these things up .. but unfortunately I am not, they where all on the LSL Wiki.

I know about makefiles, I've written code in Linux. And that's a good idea. I'll have to look at exactly what lslint does, maybe write a script to modify it's output.

Compiling in-editor works in emacs as well, of course. Like Turing machines, they are equivalent in power (For anyone curious, mini-tutorial: M-x compile, then specify the command to build. M-x recompile to repeat the same command, and C-x ` to jump to the next error, assuming the output is in a format similar to gcc)


You know, I feel dumber and dumber, reading your post. To think they gave me a degree in this crap. Bah!


Yeah, I just never noticed them. lslint slipped under my radar somehow. I was just voicing why I used the tools I did. I think I'm definitely preferring your method (well, with a nice s/vi/emacs/g thrown in, of course)

*sets up a SVN repository for LSL code, looks at lslint*

I am still pondering sitting down and replacing lslint (never found source for it). Not certain how up-to-date it is with the LSL constants and such. Would sort of be nice to be able to actually have those dragged into the tool as external files/headers so it was easy to keep up-to-date with builtin functions, their arguments, and various constants. That and it should be fairly easy to do as a one pass compile operation. After all, it isn't like we have the ability to do includes in LSL.

And if I get much more SL free time I might just do that. I can't remember the last time I had to write a compiler .. I suspect I will have to whip out the dragon book. Could be a hoot.