Difference between revisions of "Suggested For Deletion/LlSLURL (NewAge)"

From Second Life Wiki
Jump to navigation Jump to search
(What happens to this page now?)
Line 35: Line 35:


BTW. What happens to this page now? -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 19:43, 4 September 2010 (UTC)
BTW. What happens to this page now? -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 19:43, 4 September 2010 (UTC)
Borrowing [http://en.wikipedia.org/wiki/Single_precision#Converting_from_single_precision_binary_to_decimal the example value from Wikipedia], here are two ways to represent twentyfive. Once as single precision float and once as 32bit integer in binary form:
::Ack... forget what I said about the parenthesis ^^ Actually, I notice that too many brackets tend to confuse me :P
::About the typecasting: In order to process one type and output another type, a function needs to internally typecast the value. [[llRound]] needs to somehow ([http://en.wikipedia.org/wiki/Single_precision#Converting_from_single_precision_binary_to_decimal borrowing an example value from Wikipedia]) get from 25.4 to 25 (rather than to 25.0). I don't know how llRound is implemented, though I'd guess that it goes to 25.0 first and then performs a typecast. And that typecast is actually more complicated than it might appear when seeing the decimals, since the system deals with binaries instead. And the representation of 25.0 as float is really different from 25 as integer:
0100 0001 1100 1000 0000 0000 0000 0000<sub><small>2</small></sub> == 25.0<sub><small>10</small></sub>
0000 0000 0000 0000 0000 0000 0001 1001<sub><small>2</small></sub> == 25<sub><small>10</small></sub>
::When the typecast is done directly (without rounding) then I'm not really sure what happens, but it's obviously more complicated than it would appear when seeing the decimal representation. So that discarding of decimals is actually real math implemented somewhere, rather than just sloppiness. And that real math might not be so much different from the math performed when rounding. Just that the rounding process needs to analyze if it should rather aim for 25 or 26 (in this example).
::Yeah, I'm hardly inword too... Not because of my PCs (they're both fine), though because of my Internet connection. I hoped so badly to be around more often after graduating from university, though the place I'm living at now got no decent broadband :(
::And yes, Wave isn't developed anymore as a standalone product... Though it's not closed down until the end of the year. And Google also said (besides releasing great parts as open source) they'd try to provide tools to liberate the users' content. [http://googleblog.blogspot.com/2010/08/update-on-google-wave.html] So Wave might live on in one form or another...
::As to the page: It'll stay for reference on why the move happened etc. Going to add a note to the articles talkpage.
::--[[File:Zai_signature.png|45px|link=User:Zai Lynch]] <sup><small>([[User talk:Zai Lynch|talk]]|[[Special:Contributions/Zai Lynch|contribs]])</small></sup> 13:10, 5 September 2010 (UTC)

Revision as of 06:10, 5 September 2010

Rename the page

Alternative to deletion but, is there a template for that? -- Fred Gandt (talk|contribs) 00:42, 3 September 2010 (UTC)

I think we can just go along and move it. Any suggestions for a new name? :) --Zai signature.png (talk|contribs) 06:01, 3 September 2010 (UTC)
Hi Zai :-) Not knowing what the "NewAge" part is for doesn't help. Calling it simply "SLURL" would be inappropriate I think since that would direct all searches for info on SLURLs. "BuildSlurl" is the sort of name I would give a function that performed this kind of task. But is this really worth its own page? Maybe it is better suited to being featured on the OPs user page? At least then anyone seeking a function for the production of SLURLs will know that this is a user contribution and not the way to do it.-- Fred Gandt (talk|contribs) 14:31, 3 September 2010 (UTC)
Heyas :)
Hm. "BuildSlurl" sounds good to me. The (NewAge) part seems to be something like a brand, since all code snippets posted by the OP got this suffix. So BuildSlurl (NewAge) might be a good spot. I'm not so happy with the code tho. It seems to be more complicated than necessary. Something like this would do the same job and be a bit shorter/simpler:

<lsl>string BuildSlurl(string region_name, vector pos){

   return "secondlife://" + llEscapeURL(region_name) 
           + "/"+ (string)((integer)pos.x) 
           + "/"+ (string)((integer)pos.y) 
           + "/"+ (string)((integer)pos.z);

}</lsl>

And yeah, that would then hardly be justifiable on having it's own page. Though in general, according to Category:LSL Library, it seems to be welcomed to be put in the main space. --Zai signature.png (talk|contribs) 02:58, 4 September 2010 (UTC)
Yeppers. That's basically the same code I suggested on the talk page but even though the OP did revisit the page after my suggestion no changes were made in favor of the better code. So since you're the wiki master you'll do the move? I can well imagine I would make a hash of it. Although if we agree that the code stinks and the name is inappropriate maybe simply deleting is better in this case? On a related note and while we're here... I used llRound instead of typecasting the vector floats. Which would you reckon is the BEST way<lsl>(string)llRound(pos.x)

// OR (string)((integer)pos.x)</lsl>? My thinking is that casting float to integer in order to crop the float is basically cheating. I can't help wonder what mess it makes behind the scenes (loads of decimals get cut lose instead of being properly disposed of). Like using integers in vectors (I hate that) E.g. <1, 1, 1> instead of <1.0, 1.0, 1.0>. I'm assuming that since you used tyrpecasting instead of llRound that you think that is the better way but it is possible you hadn't ever really thought about it (we all after all get into habits). So what do you think? llRound or typecast? Another matter of taste/best-practice.... I tend to use more brackets than many other scriptors (it seems). For example<lsl>return ("secondlife://" + llEscapeURL(region_name) +

       "/" + ((string)((integer)pos.x)) +
       "/" + ((string)((integer)pos.y)) +
       "/" + ((string)((integer)pos.z)));</lsl>Any thoughts? I won't change my ways unless they are inarguably bad but I would be interested in your views if you care to share them.-- Fred Gandt (talk|contribs) 04:09, 4 September 2010 (UTC)
Oh, didn't notice the talk page before ^^ Yeah, the code snippets look really similar!
OK, I'll do the move then :) Deleting is always so destructive and discouraging (and also requires rare admin attention to get it done).
About the coding questions:
First, I need to say that I'm not a programmer. So my way of coding is often based on what feels right for me, rather than what might actually be correct. (Tho I'm about to learn programming soon and might hopefully have some greater insight in a couple of years.)
For typecasting vs. rounding, I felt that typecasting might be less work for the server. Cause it doesn't have to bother about the value of the first decimal, but can just discard it altogether. And llRound is also doing a typecast after the rounding, so it felt like less work. Of course, my way results in the position being a little bit more inaccurate than your method, though I figured it wouldn't be too harmful to land up to 1 meter further eastwards (or south). While, thinking about it, for the Z position, llCeil might probably be best. I don't know how much it takes to fall through a thin primfloor (probably more than to TP a meter beneath?).
About the Parentheses: I guess that it is always better to use too many than too few. The best example for that is probably SVC-779. (While, in the snipped you posted above, your amount of closing brackets isn't matching the amount of opening brackets.) I'm just too lazy to add extra brackets, when I know that they aren't making a difference. I personally think that it looks cleaner / more professional then. But it's probably a matter of taste, rather than anything else. Just like I tend to like my code formatted with method one over here.
However, I'd also be interested to hear a programmers view on things like that. And while it just comes to my mind, I'm really sad not to see Strife around :( He also didn't answer to my waves anymore. I hope he's doing well...
--Zai signature.png (talk|contribs) 07:49, 4 September 2010 (UTC)

14 opening parentheses and 14 closing. Although since I haven't been inworld for a week or so and thus haven't got access to a compiler (yes I know there are compilers that can be used outside SL) there could quite easily have been an error. Trying to write code direct into these wiki pages is to me bloody frustrating. I like auto tabbing and the like. I think of parentheses as containers for what would otherwise be lose data. By gathering it all up the compiler sees each package as being 1 distinct "object". At least that's how I see it. Being in the habit of using them that way I simply find I have very few errors like type mismatches or bent maths anyway. One day it would be nice to really KNOW what is BEST. Every new script I try to outdo my last effort.

While style doesn't effect the runtime of code it does effect human interaction when it comes to editing. I find method one illogical, stylistically pretentious. It is however a matter of taste and at the minute I can't think how to describe best why I think method one sucks. Why this wiki hasn't got built in lsl tabbing etc is beyond me. Christ! that would make life simpler. As for that whole thing with casting v function: llRound, llCeil and llFloor may return a different type than they use but I wouldn't call what they do "typecasting". They process data and return a type designated result. Typecasting a float to an integer results in lost data. I can't help thinking that any program that loses data here and there isn't "well written". That's why I think of it as cheating. Like replacing fuse wire with a carbon-steel rod. Sure the fuse doesn't keep blowing but....well obviously that's a bad idea. The process of the rounding functions is (or should be) cleanly defined so that data isn't lost but is instead cleaned up. I may be talking out my ass tho. The idea that a function like llRound puts any greater strain on a server than typecasting also strikes me as illogical. Surely any process requires cpu time whether it is a function process or concatenation or casting or multiplication etc etc. But a process that magically discards data? Eeep! Anyway, I seem to be pissed off for some reason. Probably being reminded that my PC is bust and logging in is a truly repulsive experience right now.
Strife has been away a while now yup. Hopefully he is gainfully employed doing something cool or maybe just having a break. As for Google wave: I thought it had been discontinued. -- Fred Gandt (talk|contribs) 19:36, 4 September 2010 (UTC)

BTW. What happens to this page now? -- Fred Gandt (talk|contribs) 19:43, 4 September 2010 (UTC)

Borrowing the example value from Wikipedia, here are two ways to represent twentyfive. Once as single precision float and once as 32bit integer in binary form:

Ack... forget what I said about the parenthesis ^^ Actually, I notice that too many brackets tend to confuse me :P
About the typecasting: In order to process one type and output another type, a function needs to internally typecast the value. llRound needs to somehow (borrowing an example value from Wikipedia) get from 25.4 to 25 (rather than to 25.0). I don't know how llRound is implemented, though I'd guess that it goes to 25.0 first and then performs a typecast. And that typecast is actually more complicated than it might appear when seeing the decimals, since the system deals with binaries instead. And the representation of 25.0 as float is really different from 25 as integer:
0100 0001 1100 1000 0000 0000 0000 00002 == 25.010
0000 0000 0000 0000 0000 0000 0001 10012 == 2510
When the typecast is done directly (without rounding) then I'm not really sure what happens, but it's obviously more complicated than it would appear when seeing the decimal representation. So that discarding of decimals is actually real math implemented somewhere, rather than just sloppiness. And that real math might not be so much different from the math performed when rounding. Just that the rounding process needs to analyze if it should rather aim for 25 or 26 (in this example).
Yeah, I'm hardly inword too... Not because of my PCs (they're both fine), though because of my Internet connection. I hoped so badly to be around more often after graduating from university, though the place I'm living at now got no decent broadband :(
And yes, Wave isn't developed anymore as a standalone product... Though it's not closed down until the end of the year. And Google also said (besides releasing great parts as open source) they'd try to provide tools to liberate the users' content. [1] So Wave might live on in one form or another...
As to the page: It'll stay for reference on why the move happened etc. Going to add a note to the articles talkpage.
--Zai signature.png (talk|contribs) 13:10, 5 September 2010 (UTC)