Mono script refuses to Save

[Phil Deakins]

I've posted this in the Server forum because it's a system problem, but I thought I might get some ideas here from anyone who has come across it before.

As I was doing work on a script, saving everything as I went along, all was well - until part way through today, when suddenly I could no longer save changes to it. I tried saving a different script and it was ok, but not the main script. The error message simply told me that it can't be saved and that I should try again later. That script always produces that error message, whereas other scripts don't have a problem.

Some time later I tried again, and had the same problem. I tried creating a new script and putting the main one's content into it, but that wouldn't save either. Then I accidentally discovered that it saves fine when it's not mono, so it's only saving in mono where there's a problem with that script.

It could be that this problem is very uncommon but, if anyone has any ideas, I'd love to hear them.

[Rolig Loon]

I suspect that whether it's mono or not is a symptom, not the cause, although I am surprised that it's the mono version that fails.  When I have had that error message, it's because I forgot to compile the script in Mono and it needs more than 16K of memory.  You might look for hidden characters, especially if you ever edited your script in a system that embeds control or formatting information, or if you have copy/pasted a routine from a web archive that does.  I have no idea why those characters would only affect a mono-compiled script, but it's the only shot I have at the moment.

[Darrius Gothly]

Do you know what changes caused the refusal to save? Meaning, can you narrow it down to a precise block of the Script? If so, try grabbing just that section and put it into a new Script and see if it has the same effect.

Near as I know the Save process causes the Script to be compiled to P-Code. If you've discovered a compiler-crasher of some sort, it would be helpful to identify exactly what sequence of code is doing it.

[Phil Deakins]

Thank you both.

@Rolig Loon It shouldn't be caused by embedded control characters because I'm using the Sublime Text external editor, which I've used successfully for probably a year now. It might have been you who suggested it some time ago. Somebody here did. Anyway, to be absolutely sure, I copied the script into TextPad, saved it and closed TextPad. Then I opened TextPad again and copied the 'text' from there into a new script in a new prim. It does exactly the same thing - saves in LSO but won't save in mono.

@Darrius Gothly. Yes I do remember exactly what I'd added immediately before saving and getting the error. It wasn't a block of code. I'm a habitual saver, even when there's nothing new to save, so the change had been very little. It was merely the addition of a new global variable, and using it in 2 already existing lines, which had already been written and saved. The silly thing is that the variable's name is 'password', and I did wonder if there was some sort of filter in play. Daft, I know, but nothing was making sense. I tried changing its name to no avail, and removing it completely but it didn't help. Later I tried creating a new script with the code in it, minus the password stuff, just in case the main script itself had been flagged in some way because of that variable name. You think of all sorts of stuff when nothing makes sense, but nothing worked.

My next step is to create a new script, in a new prim, and add the main script, chunk by chunk, to see where it fails to save in mono.

 

Edited August 20, 2017 by Phil Deakins

[Nova Convair]

That sounds like a small syntax error. Something that is handled a bit sloppy. The LSO compiler ignores it and the MONO compiler does not.

Alternatively you have found a compiler bug. But all that years nobody ever got one. I'm interested what it is.

[Phil Deakins]

I've narrowed it down to one little bit. Two lines, actually. It's not a syntax error, Nova. There are only 2 very short lines for there to be a syntax error in. Here's the little bit of code, and then I'll explain which lines make it not save in Mono, but save in LSO.

 

key id;
integer i;
for(i=0; i < numAgents; ++i){
	if(llList2Integer(lstAgentsStatus, i) > 0){
    	// Get the key.
	i=(i*2) + 1;
    	id = llList2Key(lstAgents, i);
    	jump out;
    }
}
@out;

Note: the reason for the i=(i*2) + 1 line is because lstAgents has 2 elements per agent.

If that block is written as a stand-alone script, with the necessary trimmings like 'default', lists, and such, it will save in Mono. But when it's in my script, it won't.

If I rem out the 'jump out;' and '@out;' lines, then it saves fine in mono. It's those 2 lines that cause the problem.

There are no other .... WAIT... goto "CRACKED IT"

I've looked at 'jump' in the the LSL wiki and I see no problem with way I've used it. It's used to jump out from within both the IF and FOR scopes, just like one of the examples in the wiki. Also, I tried it with the jump ouside the IF scope and inside the FOR scope, and it still won't save in Mono.

I'm completely baffled.

I can get round it by not using the jump, but I shouldn't have to.

 

CRACKED IT (I think)

I was starting write that there are no other jumps in the script, but I thought I'd better check, and there are. Not only that, but they both jump to @out.

Yep. That was the problem. It wasn't a syntax error as such but it certainly was an error on my part. Sorry to have troubled you

Edited August 20, 2017 by Phil Deakins

[Darrius Gothly]

RATS! I was hoping to convince you it was your entire computer set up so I could have you ship everything to me for testing. But now that you've fixed it .. bleh! 

FYI: I was going to suggest you change the assignment of the id variable so that it doesn't modify the loop iterator. So it would instead read:

40 minutes ago, Phil Deakins said:

// Get the key.
        id = llList2Key(lstAgents, (i*2) + 1);

 

[Phil Deakins]

I scuppered your wicked plan

Yes, that change would be fine - it would usually be necessary. But I only want the first one to be found, so modifying the loop iterator doesn't matter. I could save a line by doing it they way you said though. I often write things a bit long-winded so that they are easier for me to understand what I've written when I see it again later, but this isn't one of those things.

Edited August 20, 2017 by Phil Deakins

[Darrius Gothly]

5 minutes ago, Phil Deakins said:

I scuppered your wicked plan

Yes, that change would be fine - it would usually be necessary. But I only want the first one to be found, so modifying the loop iterator doesn't matter. I could save a line by doing it they way you said though. I often write things a bit long-winded so that they are easier for me to understand what I've written when I see it again later, but this isn't one of those things.

*ebil grin*

Yup, I'm the same way. Long-way-round on first pass. Later when I'm squeezing out every byte of memory, I'll make code optimizations like that. I'm not always sure they help though. It would be nice if there was some way to get P-Code sizes so I can determine which code changes are useful and which ding me the other way.

So just to summarize (for clarity): The real cause of the issue was two labels named "out"?

[Phil Deakins]

Yep. It was my own doing - 2 labels with the same name in the script.

I'd never heard of p-code so I looked it up. It would be good if we could use something like that with LSL. With mono, though, I haven't found it necessary to squeeze stuff in. I'm not sure I would do it anyway. For instance, earlier today (before the problem raised its head), I was writing a bit of the script by using a truth table, and I wrote it the compact way, with longer lines that I would later need to work out what they were doing if I came back to them. So I expanded it a bit, so that it's much clearer to see what those lines are doing. I don't think I'd want to compress it. When you have a memory like mine, the long-winded way is always better   If I find myself running short of memory, I prefer to move some of it to another script.

Edited August 20, 2017 by Phil Deakins

[Rolig Loon]

Glad you found it.   Yeah, jump commands can be chancy.  I do everything I can to avoid them because I have run into exactly the same issue, although I have never tried compiling in LSO to see if that worked.

[ChinRey]

32 minutes ago, Rolig Loon said:

...

although I have never tried compiling in LSO to see if that worked.

In this paticular case, LSO wouldn't have solved the problem, it would just have caused the script to fail silently with no error message. More specifically, the second jump and the second @out; label would simply have been ignored.

Edited August 20, 2017 by ChinRey

[Phil Deakins]

@ChinRey Hmm. I hadn't thought of that. It appeared to work fine when compiled with LSO but maybe that was a misunderstanding on my part. All I needed was the key of one logged-in agent. Any would do, so what I assumed was working maybe wasn't, and instead I was getting the key of the last logged-in agent in the list. Interesting.

[Love Zhaoying]

23 hours ago, Phil Deakins said:

Yep. It was my own doing - 2 labels with the same name in the script.

I'd never heard of p-code so I looked it up. It would be good if we could use something like that with LSL. With mono, though, I haven't found it necessary to squeeze stuff in. I'm not sure I would do it anyway. For instance, earlier today (before the problem raised its head), I was writing a bit of the script by using a truth table, and I wrote it the compact way, with longer lines that I would later need to work out what they were doing if I came back to them. So I expanded it a bit, so that it's much clearer to see what those lines are doing. I don't think I'd want to compress it. When you have a memory like mine, the long-winded way is always better   If I find myself running short of memory, I prefer to move some of it to another script.

I wrote my own p-code interpreter for LSL very recently. Now I'm working on a parser/compiler.

Anyway, one of the few times I tried to get a "jump" command to work in a script, I just couldn't do it! Funny that a script error with a "jump" would not let your script save.

Anyway, turns out my problem was syntax - I kept trying to use "colon" before or after the jump label (like in most labels) instead of the uniquitious semicolon.  In the end, I saved myself using the evil, bad, no good, must-not-use jump.

[Love Zhaoying]

On 8/20/2017 at 0:59 PM, Darrius Gothly said:

Near as I know the Save process causes the Script to be compiled to P-Code. If you've discovered a compiler-crasher of some sort, it would be helpful to identify exactly what sequence of code is doing it.

It SHOULD always "save" even if there is a script error (in which case no code is generated and "running" should be disabled). SHOULD.  It appears Phil found a case where it does NOT save with a script error.

[Phil Deakins]

15 minutes ago, Love Zhaoying said:

It SHOULD always "save" even if there is a script error (in which case no code is generated and "running" should be disabled). SHOULD.  It appears Phil found a case where it does NOT save with a script error.

Saving scripts with errors does normally save. In those cases, the line number and character number are shown in the script box, together with what the error is - syntax, etc.

With this error it was different. The error message always opened in its own little box. It was as though the server was busy, so try again later (something that happened quite a lot many years ago). It's odd that it should behave differently in this case.

[Love Zhaoying]

17 hours ago, Phil Deakins said:

It's odd that it should behave differently in this case.

I learn weird new things about the scripting system a lot this year.  The biggest was that memory was slipping away (significantly less memory available after I compiled) for 1 script until I finally copied the text to a new script. Made no sense at all, but was repeatable.