in reply to Re^17: global var
in thread global var
No it isnt, notice i didnt stop when i found it, like use/require does.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^19: global var
by Anonymous Monk on Apr 11, 2017 at 22:33 UTC | |
No it isnt, notice i didnt stop when i found it, like use/require does. Why is that important? use/require only load one file | [reply] |
by huck (Prior) on Apr 11, 2017 at 22:59 UTC | |
use/require only load one file yes of course What if there are two files named the same in the lib stack. why does it seem to work sometimes and not others, could it be one loads it from one place and the second loads it from another. If the faulty module existed higher in the lib stack in the failing code then that code would fail, but if in the working code the good module came before the faulty one in the lib stack it would get loaded instead and that code works. That is why i wanted to see where ALL of the manageusers.pm files were located. He may think he has the right lib added to the stack, but it is in the wrong position. But for the faulty code it looks like it only found one copy. | [reply] |
by Anonymous Monk on Apr 12, 2017 at 00:06 UTC | |
What if there are two files named the same in the lib stack. Perl tries to load the first file found
why does it seem to work sometimes and not others, could it be one loads it from one place and the second loads it from another. If the faulty module existed higher in the lib stack in the failing code then that code would fail, but if in the working code the good module came before the faulty one in the lib stack it would get loaded instead and that code works. That is why i wanted to see where ALL of the manageusers.pm files were located. He may think he has the right lib added to the stack, but it is in the wrong position. But for the faulty code it looks like it only found one copy. Without trying to be harsh, its simple, all the code resembles spaghetti, its full of red flags If you remember send windowmessage from cgi back to form that called the cgi, Cookie->fetch problem the story is familiar, OP tries to solve problem by showing fragments of a whole which is beyond understanding, instead of starting with a tiny self contained program that he can understand, debug, and apply what he learned to the big code For comparison a different guy a few years ago (perl pagination links) same problem (spaghetti but short) , but doesnt take the advice to unblender because its cgi101 Now the situation isn't hopeless, the entire code doesn't have to be thrown out or completely rewritten, the programmer simply has to improve a tiny little bit tultalk needs to step away from the spaghetti bathtub and begin working with simple plates/bowls, with one single solitary spoonfull of spaghetti, then switch to a second bowl with two spoon fulls of spaghetti, until he can learn his way around the bathtub, because thinking "but bathtub mostly works!" every time he encounters a bug is holding him back Solution is to start deleting stuff until you've got bare bones, because you can't fix spaghetti by digging in a bathtub of spaghetti, the spaghetti is blocking your view of the spaghetti you're working The goal is to gain/learn a clear mental picture of the overview/birds eye view of the code, how cgi operates, how every single component works and fits together, and the only way to do that is to start simple, a new file for every feature/addition/subroutine... The problem is the OP keeps pointing back at the huge bathtub and saying I made that it mostly works just help me fix it, but You skip understanding 1/10 parts that make up the bathtub, and then fix a problem caused by 5 different pieces of code in 5 different files, 4 of which shouldn't touch $global_variable, that shouldn't even be global ... But the guy is trying and thats good, just has to try something that has a chance of working If this was face to face meeting the current warning/error would have been sorted by Re^2 ... but the OP would still keep pointing at the bathtub unless there was someone to make him go through the motions to improve | [reply] [d/l] |
by huck (Prior) on Apr 12, 2017 at 00:39 UTC | |
by tultalk (Monk) on Apr 23, 2017 at 16:31 UTC | |
| |