Cross-fading demo doesn't compile

[DaVince]

For some reason, the music cross-fading demo on http://opensludge.sourceforge.net/resources.html will not compile for me. It leaves me with the following mysterious compile error:

Code:

ERROR: Not a function, variable or object type!:  (in musicfade.slu)

That's right... It's tripping over no variable whatsoever. I have no idea where the problem comes from, as the code looks fine to me.

[Trumgottist]

I can confirm that I can reproduce it.

Will investigate later.

[DaVince]

Awesome. I was almost afraid my PC was being quirky again.

I haven't tried the sound effects cross-fade demo, but I bet it'd have the same error.

[Trumgottist]

(By "investigate later" I mean that I'll look into it - and fix it - tomorrow evening after work, or possibly Saturday, but no later than that.)

[Trumgottist]

I've identified and fixed the problem. It was a bug in the handling of constants, so a temporary workaround until the next version of SLUDGE is released is to avoid use of constants. (In this case, replace FADESPEED with 3 and it will compile.)

If you open the file consts.sld and add an empty line at the end, it should compile.

[Trumgottist]

To clarify my previous post (written late last night), and explain what was going on to anyone that's curious:

I initially posted a little too soon. I tracked the problem down to the FADESPEED constant, and figured that there was something wrong with the constants. Indeed, removing the constant from the code fixed the problem. But as I continued my investigation I found that the root of the problem was that the compiler expected every line of SLUDGE code to end with a newline character, so when consts.sld ended without one, it lost the 3 at the end, and set FADESPEED to nothing.

This bug (introduced by me when I added support for Unix-style line-endings as well as Windows-style) is now fixed for the next version of SLUDGE. In the mean time, just make sure that all script files end with an empty line, and everything will work fine.

[BigMc]

Is there something that can be done to improve the error message situation? Did you check that this error message can only appear when it's appropriate or is there nothing that can be done?

[Trumgottist]

You don't like the error message? It usually contains the offending text, but as that text string happened to be empty (the only way for that to happen is through an empty constant - otherwise it'd get caught at the syntax checking stage), it got more confusing.

[BigMc]

Is it possible to give some hint where he offending part is in that file?

[Trumgottist]

Is it possible to give some hint where he offending part is in that file?

As you probably know, I have added line numbers to many (most?) of the error messages, but by the time it gets to the linker (which is where this error comes from), that information is no longer available. It would of course be possible to store that information along with the compiled instructions, but as that would slow things down, I'm not convinced that's worth doing. After all, the most likely cause of this error is a misspelled variable, and it's easy to search for "dargon" if you get "ERROR: Not a function, variable or object type!: dargon (in dragon.slu)". (Note that the lack of identifier in the error as posted in the initial post in this thread was due to the bug.)

[BigMc]

Maybe there should be a different error message for the case that wrong name of the function, variable or object type is an empty string. I'm not sure how to call it. That should always be caused by a missing expression or not?

[Trumgottist]

That basically shouldn't happen. As I said earlier, a missing expression will be caught at an earlier stage. The only way to get an empty error message is by having an empty constant, since that will fool the earlier error checking. (SLUDGE constants are a bit like #defines in C, except that they're not expanded until after the compilation is done, rather than by a preprocessor.) I suppose an error could be flagged if someone creates an empty constant, since doing that would just be asking for trouble. Then it would be truly impossible to get an empty string in this error message.

Edit: I've now added that check.

[BigMc]

If I take the cross-fading demo and put an assignment with missing expression into consts.sld:

Code:

FADESPEED=
(empty line for now)

that's exactly what happens. So that could give "ERROR: Missing expression" rather than "ERROR: Not a function, variable or object type!: ".

[Trumgottist]

See my above edit. (We were apparently typing at the same time.)

"ERROR: Missing expression" would just be confusing to figure out what it meant. The error "ERROR: Not a function, variable or object type!: " (without further text) should now be impossible to get.

[BigMc]

Nice. BTW is speed still an issue? The largest games I have compiled are The Interview and the Vercoin example and they both need less than half a second including image compression.