Nice to see this morning as I sit here sipping on my first cup of coffee for the day that Linden Lab® has been hard at work on Mono, and have announced a Mono Beta Refresh now available on the Beta Grid.
I’m hopeful that they’ve fixed some of the issues I was experiencing before, and that were blocking issues for me. Looking at the list of some of the Mono issues Linden Lab® has addressed, I’m encouraged:
- SVC-1325 Negation of vector or rotation no longer causes a runtime error.
- SVC-1342 Boolean && and || now correctly produce boolean results.
- SVC-1327 Added support for llHTTPRequest.
- SVC-1319 Added support for http_response.
- SVC-1325 int *= float now works correctly.
- SVC-1361 Corrected erroneous sleep values for some library calls.
- SVC-1324 Fixed problem with vector and quaternion being incorrectly handled by the UThread Injector.
- SVC-1344 Fixed problem with type casting of return statements.
- SVC-1353 Limited length of concatenated lists and strings.
- SVC-1326 Changed llGetFreeMemory() reporting for Mono scripts to return 0-64K and handle script reset correctly.
- SVC-1312 Fixed support for old scripts on the LSL2 VM.
I won’t have time to test this before work today, so I’ll be even more anxious to get into the Beta grid tonight and test this 
Popularity: 23% [?]
“Boolean && and || now correctly produce boolean results.”
At times it seems like their internal testing amounts to just a developer running it and saying “Yup, looks good.” I mean, it seems like if they were using any regression tests at all, they should have detected this bug which breaks a core functionality of any programming language.
Hey Colin, what do you base that on. If you look at this page http://wiki.secondlife.com/wiki/LSL_Language_Test you’ll see they did have a regression test, but it was only qualified with a truth table. After the current release they extended the tests.
Yes! That’s exactly what it seems like… Another commonly-heard phrase in this industry is “works on my machine….”
I remember writing version 2.0 (an upgrade from a strictly interpreted “tiny language” to an MSIL-bytecode-compiled version that also ran on Mono, btw) of a compiler a couple of years ago that appeared to work well enough at first, with cursory testing.
Then, when I went to run all of the existing test programs for V1, I noticed some subtle changes in behavior. Turns out that I had gotten the short-circuit boolean evaluation wrong. It’s easy to make (and fix) mistakes like that when creating a compiler and runtime virtual machine “from scratch”, and every developer knows that early versions look and work nothing like the final product anyways.
The big difference between what I did and what LL seems to have done is that I had a pretty good representative set of target-language source code to run through and test before distributing the new compiler, so I never had to be embarrassed by distributing broken fundamental language features like boolean comparisons that didn’t return correct results
Hmmmmm…. That boolean evaluation problem probably also explains a lot about why even the C:SI code that *did* compile on Mono didn’t run right.
I can’t think of any instance of a non-trivial program in any language that didn’t use boolean logic, lol.
Ahab, interesting link, I’ll have to find time to peruse that better.
But when you consider the fundamental role that boolean logic plays in any programming language, it’s easy to understand why someone might make comments about what appears to be extremely cursory testing.
In all seriousness, I believe that Linden Lab developers do conduct quite a bit of testing. That won’t stop me from poking at them about some of their decisions and obvious mess-ups, though
I have now reviewed the link that Ahab posted about 15 times, and I have to say that I now feel FULLY justified in every joke I’ve ever made about Linden Lab developer’s quality assurance process.
If the primary test they were using to validate LSL correctness didn’t previously even handle && and || operators correctly, that’s bad enough - a sure candidate for “The Daily WTF”, except it’s not funny.
But even forgiving that, I still have a problem with Ahab’s comment that the test script constitutes valid regression testing. Proper regression testing involves keeping a copy of scripts that have demonstrated a bug in the system at some point in the past, and running said scripts to validate each and every new build from that point on to ensure that those bugs are immediately identified if they re-appear in the future, hence the term “regression testing”.
That one script linked to above is not adequate testing, despite the fact that the page claims that it “Tests all LSL language features”. For instance, where is the money event handling? Or how about inventory? Permissions? Animations, sound, collision, sensor, states, timers, link messages? No, that is clearly not regression testing. Nor does it test all language features, though it does superficially test all of the data types.
Surely there is still much that I don’t know about the LL quality assurance process, and it’s extremely likely that they do more than I’ve seen thus far, but I still cannot get over my astonishment that a fundamental problem like this made it into a public beta.
It occurs to me that it would be in my own best interest to develop regression-testing scripts for LSL on my own, for my own use. If LL does not appear to do a sufficiently good job, at least I might be able to run the scripts on my own after a server upgrade and perhaps discover any problems early enough to assist LL in damage control.
The effort is probably much more than I have time for at the moment, but the possible payoff of discovering borked permissions or other serious problems right away is sufficiently motivating that I will spend some time doing this after my current project is completed.
Why not go to the office hour and ask them about this?
The developers are not some conspiratorial ‘they’, infact judging by the office hour there is probably fewer on Mono than there are on C:SI! Lol!
Ahab, excellent suggestion. I honestly intend to do exactly that, when I can find the time to do so. I like to poke fun at LL for obvious mistakes and other things I don’t understand, but I do recognize that they are probably fairly decent developers, and I have never really had a chance to discuss anything with them.
Not that I would get much chance to really discuss anything in detail from “office hour”, as I’ve seen chat transcripts that don’t really indicate that much of substance gets covered in the kind of depth I’d wish, but I should at least make the effort, huh?
Yeah, I’ll do that. Soon.