Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^17: can't import using exporter

by Corion (Pope)
on Mar 19, 2012 at 16:07 UTC ( #960439=note: print w/replies, xml ) Need Help??

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

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.

Replies are listed 'Best First'.
Re^18: can't import using exporter
by perl-diddler (Hermit) on Mar 20, 2012 at 01:06 UTC
    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...

      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?

        You seem to be confused. There was no last time. This is all the same question. The error message you claim I should have seen was seen, or rather, NOT seen by you too -- spurring you to go on and write a rather long (required to work around the bugs in 5.14), example of how it worked. -- Except that you don't use any of perl's basic error parsing and library statements. Those are also part of perl. That's were the error is finally working out to be. Never starting in my code.

        Errors were created in me using a module I was unfamiliar with and used for the first time. But that was in trying to work around the original bug -- on top of that the workaround didn't work either. It suffers from he same bug. Perl doesn't see the vars being defined in the importing module space.

        Thank you very much for helping me clarify where the error was. I was fairly certain I had correct code. I did. It really is verifiably broken.

        My ways may be unconventional. It's too bad several people here think that is bad and wrong for me not to follow the crowd.

        I will have to thank chromatic, though, for getting me to think about it again after I'd stepped away from it for a bit and getting me curious enough to write a real reduction of my prog -- that fully duplicates the error.

        You have an odd view... I make a mistake, I correct it and move on, yet you brought up the same spelling thing that YOU overlooked, in an earlier post, that I did. Perhaps you are more irritated with yourself for missing it?

        I known I make mistakes -- but correct and move on, or the problems don't get solved. That's the only way I've gotten as far as I have, is by making alot of mistakes, and correcting them and moving on. But hey, I know other people, they say their stuff doesn't smell... Great. I'm not one of them. (would have been nice!)....

      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.
      { package DEBUG; our $var = 'foo'; } { package main; BEGIN { *var = \$DEBUG::var }; print "Var is $var\n"; } $ perl Variable "$var" is not imported at line 14. Global symbol "$var" requires explicit package name at +line 14. Execution of 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.)

        I disagree with your hints. But, more importantly, they miss an important point:

        #!/usr/bin/perl -w use strict; { package DEBUG; our $var = 'foo'; } { package main; BEGIN { package Other; *main::var = \$DEBUG::var }; # ^^^^^^^^^^^^^ ^^^^^^ print "Var is $var\n"; } __END__ Var is foo

        It doesn't actually have to be a third package, just not the destination package. So you could also use, for example:

        BEGIN { package DEBUG; no strict 'vars'; *main::var = \$var };

        - tye        

        I'm not sure I get your point.

        I'm not sure if you are trying to point at a solution or what?

        Does Exporter not work for variable names in 6.14? It's documented as supporting them in its pod/manpages, but putting the var in @EXPORT as '$var' and then importing it in another package, doesn't work either in 6.14.

        Does it work in your 5.8?

        package Debug; {use parent "Exporter"; our $var="foo"; our @EXPORT=qw($foo); } package main; {import Debug; print $var; }' Name "main::var" used only once: possible typo at -e line 10. Use of uninitialized value $var in print at -e line 10.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://960439]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2017-01-22 00:55 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (186 votes). Check out past polls.