Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^16: can't import using exporter

by perl-diddler (Hermit)
on Mar 19, 2012 at 15:47 UTC ( #960436=note: print w/ replies, xml ) Need Help??


in reply to Re^15: can't import using exporter
in thread can't import using exporter

Can I assert that computer science is not your primary background as well?

Your instructions on narrowing down the source of a problem are true for simplistic programs in simplistic environments, but those are not the environments of today's computer systems. An update introduced either because I installed an update for an unrelated product like photoshop or such, or because of some permitted OS update, (manual or automatic), can easily change the behavior of installed programs.

In Windows7 programs are sensitive to what order they are loaded in memory and what else is loaded at the same time. It's very rare that they interact -- as we both 'know', they are not "supposed" to interact. But I have seen it happen due to random memory allocation by windows. Such things are rarely repeatable once the offending programs are terminated or even the machine is rebooted and the same programs loaded. Something left over in memory caused a different behavior.

In a perl program -- the larger the program, the more likely it will be that any memory corruption or leak in perl will later affect something else at random. Even the size of the file read in, could affect how it interprets things early on. There are tons of subtle bugs that might only. In real time testing, you don't just run a test once. You run it many times.. It may be the system only crashes after the 100, or 1000, or 10,000,000th execution.

In my later career, with my time spent in writing linux kernel security functions, crashes would occur after some random time of execution -- a timing bug that only happened ever so rarely. How do you debug it? By adding debug lines to the code, you are likely to make it go away. By removing functionality from the code, you may eliminate evidence of the problem, but not the cause. You may have just made it 10,000 times less like to occur -- which for an OS that is to be running 24/7, is still unacceptable. The way I attacked one such problem was by making the code less readable by optimizing the hell outof it. Because initially, it forced the crash to occur more often -- until I found what was likely the cause -- but no one was SURE it was the cause, because you couldn't remove it and still have the program work but changing it might simply hide it more thoroughly. Eventually I felt good about the code executing 20x faster at near the physical limits of the machine, for ... well I wanted 6 days, but my boss wasn't willing to wait for more than 3 days. He still felt I was needlessly optimizing the code -- and resented taking almost an extra 2 weeks to find a code that a more senior engineer gave up on finding but code that needed to be run for hours to a day at a time when he gave up.

Perl is no where near the complexity of a kernel, but it is easily approaching the level of a compiler where "at a distance" type bugs start being noticeable.

Coverity released a study on open source code quality and compared it to proprietary source code products. The defects/line of code were about the same between projects of the same overall size. Defects grew/line proportional to the size of the project. They did mention that open source projects tended to be smaller for the same types of functionality than their commercial counterparts, thus overall, had fewer bugs for products of the same type.

That means perl is not not immune to the same tendencies of having defects/line of code as any other project. And that as it grows, it will develop bugs similar to other projects of it's size. Programs do develop bugs where cause and effect don't happen together or due to only a few factors but sometime several and some random 'salt' thrown in on the random number generator for good measure.

That's my recent, largest code experience -- where simplifying something to just headers, would never display the bugs.

However, you are more like to end up with some seemingly innocuous change making huge, irrational changes in perl's error behavior (like in my response ^4, above). Indicating the problem is not one of 'simplicity', but one of complexity causing perl to misbehave. That doesn't mean complex is the problem -- if it is valid code, the parser should have handled OR if not, then should have given a more consistent and localized error message in both cases -- when clearly, it did not.

That is indirect evidence of a bug in the program handling the parsing and producing the output.

If you throw random garbage at the compiler -- it doesn't matter, that the program was wrong. The compiler shouldn't crash, and it should determine the point at which output was unacceptable, and if it couldn't make sense of it then gracefully retired, -- but at least point to the last place things made sense, and where things went wrong.

perl 5.16 doesn't do that, if anything it reliably does not do that. That is bad design -- to the point most wouldn't consider it to be a design flaw or bug, requiring more more evidence that what we've come up this thread. To the point -- my claims of finding bugs in the compiler (supported by many bug reports some of which causes were found, and some not in past versions) would show that someone who strongly claims that my finding a bug is 'extraordinary', requiring extraordinary proof, is rather naive. I've had bugs that would reliable reduce the the perl compiler to a core dump after a random amount of runtime. I've had others that only required reading a very specific way through 4TB data files. Not something that is the subject of your every day testing.

If I say I have multiple programs that have broke between versions, it's likely true and likely not entirely my fault if at all -- or so history has shown.


Comment on Re^16: can't import using exporter
Re^17: can't import using exporter
by Corion (Pope) on Mar 19, 2012 at 16:07 UTC

    Whatever the point of your missive is, besides telling me that life for you is complicated, it is all negated by the fact that for this concrete problem, you could not be bothered to read Perls error message, which would have pointed you to the problem immediately.

    Instead of believing this perceived complexity as being the untreatable nature of all your problems, I try to recommend to you the approach of reducing complexity. Especially when communicating problems to other people, I have experienced it as much more effective when I invest time in presenting the problem in a way that is as concise as possible but no simpler than possible. Hiding behind the claim that "it is all too complex" and blaming the tools is in my opinion the argument of a bad craftsman.

    Your ideas of how Perl should behave are, again, nice ideas. The thing is, your ideas are ideas of a fantasy language that are neither backed up by the documentation of Perl nor by its behaviour. This is what I mean by "extraordinary claims require extraordinary evidence". You claim weirdo generalities, but do not back them up with quotes from the documentation and self-contained programs that show the problem.

    Until you do that, I think you won't get any better replies than hints as to how the way you are going about things is an uncommon and unconventionally structured way. I recommend learning how to use the tools you employ instead of trying to use hammers as ladders.

    Can I assert that computer science is not your primary background as well?

    Yes - computer science was my minor, my primary study was in mathematics.

      Couldn''t be bothered to read perl's error message?

      You talking about the misspelling thing again? I fixed that -- it didn't change anything. I'm back to exactly where I was at in response "^4".

      I'm able to use 'use' instead of import, which supposedly does all the things you did in your example -- however, I get the same error message I originally got. The vars are still undefined, and Exporter isn't exporting it despite my having a 'use Debug' and Debug listing the var for export.

      What does that have to do with overlooking a alliteration problem? Did you miss the fact that I said it didn't work, earlier? and are just still stuck on me getting 1 error message wrong on a subname that is slightly misspelled were 2 letters are leftout , both letters of which are duplicated in the word?

      Haven't you studied reading or read the study about how words are processed? pfllple wer able to fixyure out comburtely sparred woods stll get the meaning. Only the start and beginning of the word were of prime importance as in readying the eye catches those first and scans for shapes. It doesn't decipher each letter except in rare situations where you spell out a word -- so words that are spelled similarly are often confused by many people -- let alone technical routine names were someone may have accidently gotten the notion to use that word to describe a routine that is to give you perl's module notation for a given filename. I can either file a bug on it or not. Either way, it didn't solve the base problem of importing the var names.

      I've imported them in 5.12 5.10...and before,

      Usually a simple alias BEGIN{ *var=\$DEBUG::var}; is what I remember working -- USED it TONS of times.

      Now it doesn't work. Ergo. bug in 5.14. You can claim it is a bug in my code somewhere. It may be... But perl ISN'T flagging the error.

      Instead, it's claiming that the var I imported into my name space needs a Packagename in front of it. Why? Dunno. Didn't do this before 5.14.

      p.s. Curious... was your math degree in the Liberal Arts School? It was at my college -- and they had 2 Computer Science majors -- one associate with Math tending more towards theory, and the other in engineering tending more toward practice (but 90% overlap in the main courses... it was the non-core stuff where things differed.)...Example, in engineering -- we had to take 'drafting' -- never have used that. But the L.A. degree had to take more calculus courses... something else I've never used since graduation...

        Do you ever read the stuff you write out loud?

        Usually a simple alias BEGIN{ *var=\$DEBUG::var}; is what I remember working -- USED it TONS of times.

        Now it doesn't work. Ergo. bug in 5.14. You can claim it is a bug in my code somewhere. It may be... But perl ISN'T flagging the error.

        Remember the last time when you had "irrefutable" proof of Perl 5.14 being buggy? It was a one four line program, and the bug was that you didn't read the error message. Why should it be different this time?

        Usually a simple alias BEGIN{ *var=\$DEBUG::var}; is what I remember working -- USED it TONS of times.
        { package DEBUG; our $var = 'foo'; } { package main; BEGIN { *var = \$DEBUG::var }; print "Var is $var\n"; } $ perl debug_begin.pl Variable "$var" is not imported at debug_begin.pl line 14. Global symbol "$var" requires explicit package name at debug_begin.pl +line 14. Execution of debug_begin.pl aborted due to compilation errors. $ perl -v This is perl, v5.8.9 built for x86_64-linux

        (Hint: our scope in this example and still the mess of compilation time versus run time in your longer example.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://960436]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2014-12-23 02:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (133 votes), past polls