Talk:Combined Library
CombinedLibrary.zip
Needs A New Download Link It Seems, As I Got This When Going To Download:
"Sorry, the page you were looking for could not be found.
Suggested Actions
- Check the URL that you have typed and retry."
Link Currently Goes To: http://mailerdaemon.home.comcast.net/CombinedLibrary.zip
Was Interested Since Unescape Says Its Not The One In The Combined Library, And The One In The File Is The One I Was Looking For Adi 23:42, 5 July 2009 (UTC)
- I've been meaning to re-upload it (and everything else) but I have to find the USB dongle that I have it stored on... and decide where I'm going to host it. ~_~ -- Strife (talk|contribs) 23:50, 5 July 2009 (UTC)
- Can It Be Hosted On The Wiki At All? Adi 01:47, 8 July 2009 (UTC)
Maybe Strife explains us (str = "") + str , whats the sense of the (str = ""), because the function works without it.
- In LSO memory fragmentation is a killer (not a problem in Mono). It frees the memory used by the variable. -- Strife (talk|contribs) 23:52, 22 December 2011 (PST)
Was just easier to upload it to megaupload. -- Strife (talk|contribs) 00:00, 23 December 2011 (PST)
And now that megaupload is dead, what now? I was hoping to use the combined library as a dependency on some of my own libs... :< --Michelle Resistance 19:19, 10 July 2012 (PDT)
- I'm on vacation at the moment, I'll find somewhere to upload it when I get back (I don't have it with me). -- Strife (talk|contribs) 21:32, 10 July 2012 (PDT)
A 7 year old bug died in 2014 in UnicodeIntegerToUTF8().
<lsl> string UnicodeIntegerToUTF8(integer input)//Mono Safe, LSLEditor Safe, LSO Incomplete {//LSO allows for the older UTF-8 range, this function only supports the new UTF-16 range.
if(input <= 0x7FF) input = input << 24; //< 2^7 , 7-bit code point is simple. // 7 U+0000..U+007F 1 0xxxxxxx else if(input <= 0x7F) input = 0xC0800000 | //correct mask! //11 bit code point appeared to be buggy after i tested AFF failing cases and noticed its exactly a range of 2^11 so i looked DEEPLY into it:
//((input << 18) & 0x1F000000) | //correct mask WRONG SHIFT
//waiiiiiiiiiit, why would you shift by 18, i think it should be shifted by 8, and the error is to assume its 16+2, while it should be 16/2 ??? lets test this !!! !!!!!
((input << 8) & 0x1F000000) | //correct mask, FIXED shift..// tested and shown to be a 7 year old bug that i finally fixed!
((input << 16) & 0x3F0000); //i am pretty sure there is an error here!
//11 U+0080..U+07FF 2 110xxxxx 10xxxxxx
else if(input <= 0xFFFF) input = 0xE0808000 | ((input << 12) & 0x0F000000) | ((input << 10) & 0x3F0000) | ((input << 8) & 0x3F00); //16 bit code-point range looked fine fine in all tests
//16 U+0800..U+FFFF 3 1110xxxx 10xxxxxx 10xxxxxx
else if(input <= 0x10FFFF) input = 0xF0808080 | ((input << 06) & 0x07000000) | ((input << 04) & 0x3F0000) | ((input << 2) & 0x3F00) | (input & 0x3F); //21 bit code-point range looked fine in all tests
//21 U+10000..U+1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
else if(input <= 0x10FFFF) {}//todo //yeah, actually the 21 code-point range is TOTALLY MISSING, and it seems no one ever counted high enough to notice that?
//26 U+200000 U+3FFFFFF 5 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
else if(input <= 0x10FFFF) {}//todo //yeah, actually the31 code-point range is TOTALLY MISSING also, and it seems no one ever counted high enough to notice that?
//31 U+4000000 U+7FFFFFFF 6 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
// return llBase64ToString(llIntegerToBase64(input));
return "";
} //the escaped lines represent utf8cpde point signatures as in http://en.wikipedia.org/wiki/UTF-8#Description , they also explain all the "|"ing and "&"ing... </lsl> //and it did it. I fixed 7 year old "unnoticed" bug. well i did notice something wrong back in 2008, but i think i failed to fix it and just didn't care enough and lived fine with a 15-bit limitation caused by a dumb typo.
// return llBase64ToString(llIntegerToBase64(0xC0800000 | ((input << 18) & 0x1F000000) | ((input << 16) & 0x3F0000))); //is WRONG and this went unnoticed since 2004..2007
// return llBase64ToString(llIntegerToBase64(0xC0800000 | ((input << 8) & 0x1F000000) | ((input << 16) & 0x3F0000))); //is FIXED --Ollj Oh 12:46, 29 September 2014 (PDT)
//also, seriously who uses goto function in 2014? stop using 40 year old programming style. we now use VMs and object orientated programming. "goto" must die! //i could easily add a binary else if() tree here, but this was taken apart by case just to make sure i get all the cases right before hanging them in a binary case tree...