Help with 'ERROR : Name not defined within scope

[rasterscan]

                if (total_noughts > total_ones)  { string winner = "0's Win !"  ; }
               else if (total_noughts < total_ones)  { string winner = "1's Win !" ; }
                else if (total_noughts = total_ones) { string winner = "Perfick 50/50" ; }

               llSay(0,winner);

Getting a 'ERROR : Name not defined within scope' on the llSay line any ideas why its not happy ?

 

 

 

Edited April 2, 2021 by rasterscan
b

[Profaitchikenz Haiku]

declare winner before any of the lines where it is being used. Currently it's being declared three separate times

[Rolig Loon]

And you are making an improper comparison in

31 minutes ago, rasterscan said:

else if (total_noughts = total_ones)

You should be asking else if (total_noughts == total_ones)

[Love Zhaoying]

5 hours ago, rasterscan said:

                if (total_noughts > total_ones)  { string winner = "0's Win !"  ; }
               else if (total_noughts < total_ones)  { string winner = "1's Win !" ; }
                else if (total_noughts = total_ones) { string winner = "Perfick 50/50" ; }

               llSay(0,winner);

Getting a 'ERROR : Name not defined within scope' on the llSay line any ideas why its not happy ?

 

 

 

That's weird, since you defined it 3 times in separate local scopes! 

[Madelaine McMasters]

1 minute ago, Love Zhaoying said:

5 hours ago, rasterscan said:

                if (total_noughts > total_ones)  { string winner = "0's Win !"  ; }
               else if (total_noughts < total_ones)  { string winner = "1's Win !" ; }
                else if (total_noughts = total_ones) { string winner = "Perfick 50/50" ; }

               llSay(0,winner);

Getting a 'ERROR : Name not defined within scope' on the llSay line any ideas why its not happy ?

 

 

 

Expand  

That's weird, since you defined it 3 times in separate local scopes! 

Because those scopes were... local!

Each instantiation of "winner" persists only until the closing brace of the scope created by the opening brace.

The llSay() is outside all the braced scopes, and so "winner" doesn't exist there.

[Love Zhaoying]

26 minutes ago, Madelaine McMasters said:

Because those scopes were... local!

Each instantiation of "winner" persists only until the closing brace of the scope created by the opening brace.

The llSay() is outside all the braced scopes, and so "winner" doesn't exist there.

I know, my sarcasm was lost ("those scopes were local"), also multiple definitions could be a hint 🙂

[Mollymews]

edit delete: confusing, not helpful
 

 

Edited April 2, 2021 by Mollymews

[Rachel1206]

@rasterscan Good follow up reading and explaining: LSL 101/Global vs Local Variables

"It is preferable to use local variables instead of global variables any time a value doesn't need to be retained once the event handler completes. (The reserving and un-reserving of local variables happens so efficiently that it is not a significant contribution to the work the sim server has to perform.) "

[Madelaine McMasters]

5 hours ago, Mollymews said:

edit delete: confusing, not helpful

Hey, that's my job!!!

[Profaitchikenz Haiku]

11 hours ago, Mollymews said:

edit delete: confusing, not helpful

You're being too hard on yourself and also underplaying the role that challenging phrases play in bringing upsight to the beholders.

To paraphrase Gurdjieff, "You should bury the dog deep so the bone has to work to find it".

(if you tell somebody the answer to a question they just file it away. If you lead them to working it out for themselves, they gain ability.)

Edited April 3, 2021 by Profaitchikenz Haiku

[Mollymews]

string winner = llList2String(["Perfick 50/50","0's Win !","1's Win !"],
  1 * (total_noughts > total_ones) + 2 * (total_noughts < total_ones)));

/*
  total_noughts = 0
  total_ones = 0
  1 * (FALSE) + 2 * (FALSE) = 0
          
  total_noughts = 1
  total_ones = 0
  1 * (TRUE) + 2 * (FALSE) = 1
          
  total_noughts = 0
  total_ones = 1
  1 * (FALSE) + 2 * (TRUE) = 2      
*/

ok then

i have to come understand that this style of coding can be confusing for some, and being confusing is not helpful

also and more importantly, the LSL compiler (like most compilers) can optimise IF ELSEIF ELSE constructs quite well, so overall LSL scripters are better off using IF ELSEIF ELSE even when the resulting source code is textually verbose    

[Rolig Loon]

10 minutes ago, Mollymews said:

i have to come understand that this style of coding can be confusing for some, and being confusing is not helpful

Oh, I don't know.  It depends on your personality.  As a veteran puzzle addict, I find confusion quite helpful. It focuses my brain, making me search for deep patterns and principles that will make sense out of the chaos. I had the good luck to stumble into LSL scripting and fall under the influence of Void Singer, who would never write a long, verbose function when a terse in-line version would do the trick. I remember spending hours teasing some of her one-liners apart.   They were like the innards of a fine Swiss watch -- one of the classic gear and sprocket things, not a modern LED contraption with electrons humming around -- and they taught me a lot about basic script logic.  And they were wonderful puzzles.

[Mollymews]

31 minutes ago, Rolig Loon said:

Oh, I don't know.  It depends on your personality.  As a veteran puzzle addict, I find confusion quite helpful. It focuses my brain, making me search for deep patterns and principles that will make sense out of the chaos. I had the good luck to stumble into LSL scripting and fall under the influence of Void Singer, who would never write a long, verbose function when a terse in-line version would do the trick. I remember spending hours teasing some of her one-liners apart.   They were like the innards of a fine Swiss watch -- one of the classic gear and sprocket things, not a modern LED contraption with electrons humming around -- and they taught me a lot about basic script logic.  And they were wonderful puzzles.

definitely for sure. Working out puzzles is quite fun and pretty interesting

is just that in terms of this forum, I have come to think that is better to post my coded answers in the same style as OP. Basically talk to people in their language and not mine. Is more about their understanding in the moment

 

this said. About verbose. Sometimes verbose can be better as it can result in efficiencies. For example when speed is paramount then in LSL list lookups are faster than string lookups. The classic Int2Hex() function is often written using a string lookup, when in LSL a list lookup is faster. Example:

string Int2Hex(integer n)
{
  string result;
  do
  {
    result = llList2String(["0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"], n & 15) + result;
  } while (n = n >> 4);
  return "0x" + result;
}

typing in all the "," can be tedious, but when execution speed is our goal then is best we go this way

 

[Quistess Alpha]

Quote

string winner = llList2String(["Perfick 50/50","0's Win !","1's Win !"],
  1 * (total_noughts > total_ones) + 2 * (total_noughts < total_ones)));

Perhaps a useless question, but is there any reason to use addition ('+') in this sort of branchless programming structure rather than bitwise or ('|')? assuming the options are mutually exclusive bitwise, wouldn't | avoid having to deal with the possibility of carrys that won't happen?

[Profaitchikenz Haiku]

59 minutes ago, Mollymews said:

I have come to think that is better to post my coded answers in the same style as OP.

Certainly when trying to answer their questions that's a laudable aim. But after that, there's a good case for showing other ways of addressing the same problem. I liked your approach because it was succinct and didn't present me with a wall of long lines of text or a succession of gThisName or gThatName declarations that are frankly anathema to someone from my programming background. (6-letter identifiers

It's over-verboseness what sent me "running screaming naked down the middle of the road" from C# and other Visual Studio/.Net languages back into the arms of Python. Your eyes shouldn't have to make excessive movements when reading code, and your fingers shouldn't be aching from over-use when you hit the "build or execute" button 

Edited April 3, 2021 by Profaitchikenz Haiku

[Profaitchikenz Haiku]

1 hour ago, Mollymews said:

typing in all the "," can be tedious,

Me being lazy would have got a string hexDigits = "0123456789ABCDEF" and used string indexing to do my dirty work for me.

[Mollymews]

12 minutes ago, Quistessa said:

Perhaps a useless question, but is there any reason to use addition ('+') in this sort of branchless programming structure rather than bitwise or ('|')? assuming the options are mutually exclusive bitwise, wouldn't | avoid having to deal with the possibility of carrys that won't happen?

in this case there is no TRUE + TRUE combination, so the result can never be 3. So no carry can happen

another thing to consider is that with CIL bytecode (produced by Mono compilers), bitwise operations are done from with the CIL bytecode by calling low-level API library functions for each of the various CPU chips that CIL engines can run on. Low-endian, high-endian, etc. Whereas + is directly calculated on the stack by the CPU, so is a tiny bit more efficient 

[Rolig Loon]

6 minutes ago, Profaitchikenz Haiku said:

Certainly when trying to answer their questions that's a laudable aim. But after that, there's a good case for showing other ways of addressing the same problem

I think that's what I appreciated about Void's participation in this forum years ago. Her coding could be terse and certainly idiosyncratic, but it forced me to think carefully about alternative ways of framing a problem. I think we all have a tendency to use the same code snippets over and over again; a toolbox of trusted functions saves time and can reduce errors.  On the other hand, familiarity can close our minds to approaches that might save memory, result in faster scripts, or simply be more appropriate to a particular task. There's a lot to be said for thinking of many ways to skin a cat.

Quite aside from the practical benefit, there's also a lot to be said for simply playing with code.  As hard as it might be for non-scripters to see, scripting is fun. I love coming up with an elegant, novel way to solve a challenge.

[Mollymews]

34 minutes ago, Profaitchikenz Haiku said:

Me being lazy would have got a string hexDigits = "0123456789ABCDEF" and used string indexing to do my dirty work for me.

the speed difference is because llGetSubString() has start and end parameters. After locating the start llGetSubString drops down into a loop secondary function to find the end of the substring.  Whereas llList2... only has to find the start value

 

Edited April 3, 2021 by Mollymews
---

[Mollymews]

5 hours ago, Profaitchikenz Haiku said:

It's over-verboseness what sent me "running screaming naked down the middle of the road" from C# and other Visual Studio/.Net languages back into the arms of Python. Your eyes shouldn't have to make excessive movements when reading code, and your fingers shouldn't be aching from over-use when you hit the "build or execute" button 

i have been looking at the NAP Framework which has been ported from OpenGL to Vulkan. Reading about how the devs went about it.  And this bit from Coen Klosters the lead dev:

"SDL & Vulkan: ... All things considered this was relatively straight-forward: Create a Vulkan window and Vulkan Instance using the required extensions and layers, select a GPU, create a surface to render to (based on window specifications) and make sure the GPU can present to it, create a swap chain and select a Queue. Your standard Vulkan initialization fare right? It just takes over 1000 lines of code."

only 1,000 lines of code to put the two together, and still yet to put stuff on the screen. I am like eep!! I think I need about 40 fingers!

Mr Klosters says also that having gone thru this porting project then he thinks that knowing what he knows now and able to share this knowledge then porting projects of this size would take a single experienced graphics developer about 3 months. He and his team of 3 (including himself) did it over 7 months while also working on other stuff. And seems that a lot of their time was working out the intricacies of Vulkan itself. Knowledge that can be now passed on to that single developer thru their code base

which in some ways is encouraging for Linden while contemplating porting SL from OpenGL to something else on at least MacOS. Other really knowledgeable industry people (similar to Mr Klosters) have been down this road already. And this might help inform Linden in their hiring choices

NAP Framework is open source MIT license. Is quite interesting. More here: https://blog.napframework.com/2020/porting-nap-opengl-to-vulkan/

[Mollymews]

On 4/4/2021 at 5:16 AM, Rolig Loon said:

I think that's what I appreciated about Void's participation in this forum years ago. Her coding could be terse and certainly idiosyncratic, but it forced me to think carefully about alternative ways of framing a problem. I think we all have a tendency to use the same code snippets over and over again; a toolbox of trusted functions saves time and can reduce errors.  On the other hand, familiarity can close our minds to approaches that might save memory, result in faster scripts, or simply be more appropriate to a particular task. There's a lot to be said for thinking of many ways to skin a cat.

Quite aside from the practical benefit, there's also a lot to be said for simply playing with code.  As hard as it might be for non-scripters to see, scripting is fun. I love coming up with an elegant, novel way to solve a challenge.

i was thinking about this a bit more today. As I am of this mind as well

a thing that I think about sometimes. Suppose someone asked how to find two factors of a positive integer closest to its square root. And I posted this as an answer:
 

integer getFactors(integer mag)
{
   integer factor = (integer)llSqrt(mag);
   for (
      factor -= ((!(factor & 1)) && (mag & 1));
      (factor > 2) && (mag % factor);
      factor -= (1 << (mag & 1))
   );
   return ((mag / factor) << 16) | factor;
}

default
{
   state_entry()
   {
       integer mag = 1234356;
       
       integer factors = getFactors(mag);
       integer high = factors >> 16;
       integer low = factors & 0xFFFF;
       integer check = high * low;
       
       llOwnerSay(llDumpList2String([mag, high, low, check], " "));
   }
}

unless we are experienced enough to decipher this then am not sure posting it would be useful

if tho I commented it and broke it out a bit then might be more helpful. Altho if I did that then am never sure how helpful that would be. Given that anyone who is wanting to apply this in their project would pretty much already know how to go about it. Example breakdown:
 

integer getFactors(integer mag)
{
  // use brute force to find the two integer factors closest to the middle
  // of some positive integer (mag)

   // get the closest integer less than or equal to square root of mag
   integer factor = (integer)llSqrt(mag);
 
   // when mag is odd then we step down by 2
   // else mag is even and we step down by 1
   integer step = 1 + (mag & 1);

   // decrement starting factor by 1 when factor is even and mag is odd (step == 2)
   factor -= ((!(factor & 1)) && (step == 2));
 
   // step down to find the nearest low factor which divides mag without remainder
   for (; (factor > 2) && (mag % factor); factor -= step);
 
   // return the high factor (mag div factor) in the high 16 bits
   // and the low factor (factor) in the low 16 bits
   // so that we don't have to store them in a global var
   return ((mag / factor) << 16) + factor;
}

 

 

 

 

 

[Rolig Loon]

It's not Newton-Raphson, but it's effective.  I like it. 

You're right.  There's always a balance between providing an answer to an immediate problem and diving deep to understand principles that will help make sense of future problems.  We have to do both.  Over the years, I think this forum has done a good job of helping newbie scripters figure out how LSL works, and it has teased a few of us to stretch and discover things that we never suspected were possible. I would not like to see us overbalance too far in either direction.  Personally, I resist the temptation to simply hand out freebie scripts to people who pretty clearly just need them to meet a short-term goal; they have no interest in learning how to do their own scripting. I'd rather direct them to the InWorld Employment forum, where they can hire someone who could use a commission.  When I write sample scripts or snippets, I try to include enough commentary to explain how they work; I want to pique curiosity about what else they might do, if you play with them.  That's what your example does.  That's what Void did for me and for Innula and a lot of other new scripters.

[Quistess Alpha]

13 hours ago, Mollymews said:

if tho I commented it and broke it out a bit then might be more helpful. Altho if I did that then am never sure how helpful that would be.

Speaking as someone who's decent at programming but not really a professional, reading the commented version really gave me motivation to understand the code, and while I probably could have come up with a similar algorithm had I thought about it enough, or parsed the non-commented code if I really put my mind to it, reading a verbal description (the comments) got me thinking about the problem enough to check that your code actually does what it says it does.

[Madelaine McMasters]

10 hours ago, Rolig Loon said:

There's always a balance between providing an answer to an immediate problem and diving deep to understand principles that will help make sense of future problems.  We have to do both.  Over the years, I think this forum has done a good job of helping newbie scripters figure out how LSL works, and it has teased a few of us to stretch and discover things that we never suspected were possible. I would not like to see us overbalance too far in either direction.  Personally, I resist the temptation to simply hand out freebie scripts to people who pretty clearly just need them to meet a short-term goal; they have no interest in learning how to do their own scripting. I'd rather direct them to the InWorld Employment forum, where they can hire someone who could use a commission.  When I write sample scripts or snippets, I try to include enough commentary to explain how they work; I want to pique curiosity about what else they might do, if you play with them.  That's what your example does.  That's what Void did for me and for Innula and a lot of other new scripters.

The VP of engineering at my company was weirdly proud of writing undocumented code. After he left, I was saddled with unraveling some of his work. The lack of comments made things unnecessarily difficult and I resolved never to do that to anyone else. The result was that my comments almost always outweighed my code and read like "Programming 101". I still bump into old friends who thank me for the documentation I left behind, not only because it explained the code and revealed insights that guided my decisions, but also because my love of design and sense of humor were apparent throughout.

I get great pleasure out of solving real problems, not those that others create for me out of their own laziness. I wanted those who followed in my footsteps to witness that pleasure, and experience it themselves.

 

[Wulfie Reanimator]

20 hours ago, Madelaine McMasters said:

The VP of engineering at my company was weirdly proud of writing undocumented code. After he left, I was saddled with unraveling some of his work. The lack of comments made things unnecessarily difficult and I resolved never to do that to anyone else. The result was that my comments almost always outweighed my code and read like "Programming 101". I still bump into old friends who thank me for the documentation I left behind, not only because it explained the code and revealed insights that guided my decisions, but also because my love of design and sense of humor were apparent throughout.

The "comments are bad" thing comes from a valid place, but that guy seems to have taken it to an extreme. You can find a lot of articles about it that explain it better than I have the energy for, but to put it simply:

• Comments need maintenance too.
  • When you write code, add a comment, and then change the code again, the original comment may become outdated and misleading.
• Code is documentation.
  • What is code anyway? A set of instructions. It tells you exactly what's being done, or at least that's the idea. When the code is so unclear that you need to write more to explain what it does or how it's done, you create two problems.

To restate the obvious, comments aren't bad. Bad comments are bad. Bad code produces bad comments.