Difference between revisions of "Talk:Combined Library"

From Second Life Wiki
Jump to navigation Jump to search
(→‎CombinedLibrary.zip: and it did it. I fixed 7 year old "unnoticed" bug in UnicodeIntegerToUTF8().)
Line 28: Line 28:


: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). -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:32, 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). -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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 --[[User:Ollj Oh|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...

Revision as of 12:46, 29 September 2014

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)
Good question, I'm not sure. I'll try to upload it. -- Strife (talk|contribs) 23:37, 22 December 2011 (PST)

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...