Difference between revisions of "Talk:SubStringLastIndex"
Jump to navigation
Jump to search
Void Singer (talk | contribs) m (@ Recursion) |
m (→@ Recursion) |
||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
Normally I would've just whacked such a dangerous code, but recursion is a (normally) valid handling method, and and I can imagine cases with long string that are known to generate few multiple that it might be workable with, so I just tagged it with the warning... of course this ignores the fact that LSL is pass-by-value, odds are it's gonna blow up in almost any scenario... perhaps I (or some bored person) should write the proper looping version? just a thought =)<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 04:11, 27 March 2012 (PDT) | Normally I would've just whacked such a dangerous code, but recursion is a (normally) valid handling method, and and I can imagine cases with long string that are known to generate few multiple that it might be workable with, so I just tagged it with the warning... of course this ignores the fact that LSL is pass-by-value, odds are it's gonna blow up in almost any scenario... perhaps I (or some bored person) should write the proper looping version? just a thought =)<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 04:11, 27 March 2012 (PDT) | ||
:I once had a situation in LSL where recursion was the best solution (optimized for bytecode to avoid stack-heap collision). I don't approve of this implementation either. I might be board enough this week end. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 22:03, 27 March 2012 (PDT) | |||
:Specifically I needed to take the first six characters off the start of a string and convert those six into a list, one character per list item. Recursion was cheaper in bytecode than looping. It was for TLMR, name of the function is token: [http://lslwiki.net/lslwiki/wakka.php?wakka=exchangeTLMLRenderer TLMLRenderer], that entire project was killed by LSO stack-heap collisions. It was too costly to keep adding on functionality. That code is an example of devious bytecode optimizations, later versions were even more devious. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 09:57, 28 March 2012 (PDT) |
Latest revision as of 09:57, 28 March 2012
@ Recursion
Normally I would've just whacked such a dangerous code, but recursion is a (normally) valid handling method, and and I can imagine cases with long string that are known to generate few multiple that it might be workable with, so I just tagged it with the warning... of course this ignores the fact that LSL is pass-by-value, odds are it's gonna blow up in almost any scenario... perhaps I (or some bored person) should write the proper looping version? just a thought =)
-- Void (talk|contribs) 04:11, 27 March 2012 (PDT)
- I once had a situation in LSL where recursion was the best solution (optimized for bytecode to avoid stack-heap collision). I don't approve of this implementation either. I might be board enough this week end. -- Strife (talk|contribs) 22:03, 27 March 2012 (PDT)
- Specifically I needed to take the first six characters off the start of a string and convert those six into a list, one character per list item. Recursion was cheaper in bytecode than looping. It was for TLMR, name of the function is token: TLMLRenderer, that entire project was killed by LSO stack-heap collisions. It was too costly to keep adding on functionality. That code is an example of devious bytecode optimizations, later versions were even more devious. -- Strife (talk|contribs) 09:57, 28 March 2012 (PDT)