Second Life Forums Archive - Proposed change to llSay

Moleculor Satyr

Fireflies!

Join date: 5 Jan 2004

Posts: 2,650

10-08-2004 11:56

From: Rickard Roentgen

wait a second, changing a return type is a problem... ADDING a return type shouldn't be. Since llSay, llShout, llWhisper currently return nothing, having them return an int won't break scripts. Look at llListen, it returns and int, and a lot of people ignore that return value

. You don't have to pay attention to the return value, therefore, won't break anything. Also llGetNotecardLine returns a key, which you can ignore...

llGetNotecardLine(...);

works as well as...

key query;
query = llGetNotecardLine(...);

Exactly.

But they shouldn't return an Int, they should return a string, even if that string IS a number. More flexibility in the future that way, if we ever want to change it.

_____________________

</sarcasm>

Huns Valen

Don't PM me here.

Join date: 3 May 2003

Posts: 2,749

10-08-2004 14:31

From: Rickard Roentgen

wait a second, changing a return type is a problem... ADDING a return type shouldn't be. Since llSay, llShout, llWhisper currently return nothing, having them return an int won't break scripts. Look at llListen, it returns and int, and a lot of people ignore that return value

.

From what Cory has said so far, I believe the problem is that when you call a function (that returns a value) without issuing a return variable, LSL has to know about it and provide for that condition at compile-time. I believe LSL passes arguments to (and from) functions entirely on the stack (i.e. no registers.) If you add a return type other than void, the function will push a return value onto the stack before returning. If the caller does not pop that return value off the stack (either into a variable you supply, or just discarding it) you'll get the stack out of order and the program will segfault during a subsequent function return (since it will think it is popping off an instruction pointer, but is actually popping off a pointer to a return value from a function.) It might segfault sooner than that, I dunno.

So, if the compiler was changed to allow for llSay() having a return type, newly compiled scripts would be fine... however, old scripts would have to be recompiled, and that is an inherently bad situation. If LL recompiles all scripts, then they all restart from scratch, regardless of what they were doing, and that could break stuff all over the world. If LL requires everyone to recompile their old scripts... well, that won't work either, since some scripts are by people who are no longer in-world or who don't want to be bothered with distributing product updates to hundreds or even thousands of customers.

_____________________

[ huns? || words || 1TBS KREW || VHI Aircraft || Whitepaper on Aircraft Physics ]

Make yourself and your objects immune to llPushObject().

wizzie Baldwin

Registered User

Join date: 23 May 2004

Posts: 52

Just truncate

10-08-2004 15:15

Leave the syntax for llSay, llWhisper, llShout the same. Yes truncate the excess to avoid errors.. Create new functions to handle the other requests for errors etc.

Morgaine Dinova

Active Carbon Unit

Join date: 25 Aug 2004

Posts: 968

10-09-2004 02:48

From: Strife Onizuka

In a normal system an error event would be an interrupt.
The problem with raising an event is that it would be added to the end of the event que. So it would be practically impossible to catch the error and make a custom handler for it.

Ah no, sorry, I wasn't at all clear about what I meant, my fault. And you're absolutely right.

I wasn't proposing real synchronous exception handling, ie. which would allow an excessively long llSay to trigger a handler which could deal with the issue directly BEFORE THE llSay COMPLETES --- that would of course be nice and extremely effective, but probably hard to graft on to LSL transparently, and totally unwarranted in this very simple little case.

Instead, I was suggesting an event-driven replacement for the need to check any llSay overflow return status if such a return value is added, so that the developer can fix her overflowing code. It should trigger an event as well. There are few things worse than code that is a great big long sequence of:

CODE

status = function_call(blah);
if (status == WHATEVER_ERROR_CODE)
{
    <error handling>
}

because the error handling is always longer than the main-path function calls, and hence you can't see the wood for all the leaves. It can be appropriate in some cases (and that's why a return code isn't a bad idea), but you certainly don't want to handle the situation in line all the time. Let me rephrase it: if an error exit is added, then also send us an event about it if we have the event handler for it in the script.

Synchrony doesn't matter here, because remember that we're comparing this against a simple overflow message being issued to chat. You can't trigger on that directly and synchronously either.

And it's much more flexible for developers than turning some UI flag on and off merely to control whether you see the messages. Assuming that the event were supplied with some useful parameters, you could have your script identify the source of the overflow very precisely and maybe even supply the chopped-off data itself. The UI switch is still useful to silence other people's overflowing code, but it gives developers very little compared to an event, and it lacks resolution anyway (eg. you want to turn off other people's messes but not your own, since you can fix your own overflows.) An event-based approached is a natural here.

_____________________

-- General Mousebutton API, proposal for interactive gaming
-- Mouselook camera continuity, basic UI camera improvements

Siro Mfume

XD

Join date: 5 Aug 2004

Posts: 747

10-09-2004 10:58

From: Siro Mfume

integer stringlength = llStringLength(message);
llSay(0, message);

Adding error catching code should be your imperetive when designing your code. llSay does not need error catching code when so simple a debug is readily available. I'm all for having it truncate silently.

heck even this snippet of code solves the problem without patching it:

CODE


integer stringlength = llStringLength(message);
if(stringlength>255)
{
    message = llDeleteSubString(message,255, (stringlength - 1));
    llSay(0, "message too long, truncated");  //or comment this line out to not say anything
}
llSay(0, message);

As I said before earlier in this thread, there's absolutely no need for a status flag or additional debuging functions. You can write them yourself. The major issue here is that you CANNOT currently get llSay to be SILENT if it truncates a message. Better functionality is allowing us to write debugging functions to make it nonsilent when needed and only when needed.

Proposed change to llSay
Moleculor Satyr Fireflies! Join date: 5 Jan 2004 Posts: 2,650	10-08-2004 11:56 From: Rickard Roentgen wait a second, changing a return type is a problem... ADDING a return type shouldn't be. Since llSay, llShout, llWhisper currently return nothing, having them return an int won't break scripts. Look at llListen, it returns and int, and a lot of people ignore that return value . You don't have to pay attention to the return value, therefore, won't break anything. Also llGetNotecardLine returns a key, which you can ignore... llGetNotecardLine(...); works as well as... key query; query = llGetNotecardLine(...); Exactly. But they shouldn't return an Int, they should return a string, even if that string IS a number. More flexibility in the future that way, if we ever want to change it. _____________________ </sarcasm>
Huns Valen Don't PM me here. Join date: 3 May 2003 Posts: 2,749	10-08-2004 14:31 From: Rickard Roentgen wait a second, changing a return type is a problem... ADDING a return type shouldn't be. Since llSay, llShout, llWhisper currently return nothing, having them return an int won't break scripts. Look at llListen, it returns and int, and a lot of people ignore that return value . From what Cory has said so far, I believe the problem is that when you call a function (that returns a value) without issuing a return variable, LSL has to know about it and provide for that condition at compile-time. I believe LSL passes arguments to (and from) functions entirely on the stack (i.e. no registers.) If you add a return type other than void, the function will push a return value onto the stack before returning. If the caller does not pop that return value off the stack (either into a variable you supply, or just discarding it) you'll get the stack out of order and the program will segfault during a subsequent function return (since it will think it is popping off an instruction pointer, but is actually popping off a pointer to a return value from a function.) It might segfault sooner than that, I dunno. So, if the compiler was changed to allow for llSay() having a return type, newly compiled scripts would be fine... however, old scripts would have to be recompiled, and that is an inherently bad situation. If LL recompiles all scripts, then they all restart from scratch, regardless of what they were doing, and that could break stuff all over the world. If LL requires everyone to recompile their old scripts... well, that won't work either, since some scripts are by people who are no longer in-world or who don't want to be bothered with distributing product updates to hundreds or even thousands of customers. _____________________ [ huns? \|\| words \|\| 1TBS KREW \|\| VHI Aircraft \|\| Whitepaper on Aircraft Physics ] Make yourself and your objects immune to llPushObject().
wizzie Baldwin Registered User Join date: 23 May 2004 Posts: 52	Just truncate 10-08-2004 15:15 Leave the syntax for llSay, llWhisper, llShout the same. Yes truncate the excess to avoid errors.. Create new functions to handle the other requests for errors etc.
Morgaine Dinova Active Carbon Unit Join date: 25 Aug 2004 Posts: 968	10-09-2004 02:48 From: Strife Onizuka In a normal system an error event would be an interrupt. The problem with raising an event is that it would be added to the end of the event que. So it would be practically impossible to catch the error and make a custom handler for it. Ah no, sorry, I wasn't at all clear about what I meant, my fault. And you're absolutely right. I wasn't proposing real synchronous exception handling, ie. which would allow an excessively long llSay to trigger a handler which could deal with the issue directly BEFORE THE llSay COMPLETES --- that would of course be nice and extremely effective, but probably hard to graft on to LSL transparently, and totally unwarranted in this very simple little case. Instead, I was suggesting an event-driven replacement for the need to check any llSay overflow return status if such a return value is added, so that the developer can fix her overflowing code. It should trigger an event as well. There are few things worse than code that is a great big long sequence of: CODE status = function_call(blah); if (status == WHATEVER_ERROR_CODE) { <error handling> } because the error handling is always longer than the main-path function calls, and hence you can't see the wood for all the leaves. It can be appropriate in some cases (and that's why a return code isn't a bad idea), but you certainly don't want to handle the situation in line all the time. Let me rephrase it: if an error exit is added, then also send us an event about it if we have the event handler for it in the script. Synchrony doesn't matter here, because remember that we're comparing this against a simple overflow message being issued to chat. You can't trigger on that directly and synchronously either. And it's much more flexible for developers than turning some UI flag on and off merely to control whether you see the messages. Assuming that the event were supplied with some useful parameters, you could have your script identify the source of the overflow very precisely and maybe even supply the chopped-off data itself. The UI switch is still useful to silence other people's overflowing code, but it gives developers very little compared to an event, and it lacks resolution anyway (eg. you want to turn off other people's messes but not your own, since you can fix your own overflows.) An event-based approached is a natural here. _____________________ -- General Mousebutton API, proposal for interactive gaming -- Mouselook camera continuity, basic UI camera improvements
Siro Mfume XD Join date: 5 Aug 2004 Posts: 747	10-09-2004 10:58 From: Siro Mfume integer stringlength = llStringLength(message); llSay(0, message); Adding error catching code should be your imperetive when designing your code. llSay does not need error catching code when so simple a debug is readily available. I'm all for having it truncate silently. heck even this snippet of code solves the problem without patching it: CODE integer stringlength = llStringLength(message); if(stringlength>255) { message = llDeleteSubString(message,255, (stringlength - 1)); llSay(0, "message too long, truncated"); //or comment this line out to not say anything } llSay(0, message); As I said before earlier in this thread, there's absolutely no need for a status flag or additional debuging functions. You can write them yourself. The major issue here is that you CANNOT currently get llSay to be SILENT if it truncates a message. Better functionality is allowing us to write debugging functions to make it nonsilent when needed and only when needed.

Welcome to the Second Life Forums Archive

Proposed change to llSay