Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: JRuby 1.7.0.pre1
    • Fix Version/s: None
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Environment:
      MacOS X 10.6.8
    • Number of attachments :
      1

      Description

      Early versions of MRI 1.9.2 had a "scope" problem when Kernel.load was used with a "true" second parameter. I reported it as

      http://bugs.ruby-lang.org/issues/1982

      JRuby seem to fail in the same way (both in 1.8 and 1.9 mode). I attach a script showing the problem. JRuby reports:

      $ jruby -e 'load "helloworld.rb", true' 
      NameError: uninitialized constant #<Module:0x4a005364>::HelloWorld::Hello
        const_missing at org/jruby/RubyModule.java:2715
                  say at /Users/johan/proj/rcons-stuff/rcons-cpp/helloworld.rb:17
               (root) at /Users/johan/proj/rcons-stuff/rcons-cpp/helloworld.rb:21
                 load at org/jruby/RubyKernel.java:1017
               (root) at -e:1
      

      but if run with the second paramter set to "false" it works better:

      $ jruby -e 'load "helloworld.rb", false'
      Hello
      World
      

      I think it should have worked in the first case too.

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        I think this is a problem with how we set up the toplevel scope for a wrapped script. Currently, the parser creates its own scope at init time and then we have to go in and setModule the resulting RootNode to the wrapper module. But not having it there at parse time may be screwing up the lexical scope structure and causing this lookup issue.

        I did not see an easy way to fix the parser (ParseConfiguration, primarily) to set up the wrapper scope before parsing, so I'm punting this to Tom.

        Show
        Charles Oliver Nutter added a comment - I think this is a problem with how we set up the toplevel scope for a wrapped script. Currently, the parser creates its own scope at init time and then we have to go in and setModule the resulting RootNode to the wrapper module. But not having it there at parse time may be screwing up the lexical scope structure and causing this lookup issue. I did not see an easy way to fix the parser (ParseConfiguration, primarily) to set up the wrapper scope before parsing, so I'm punting this to Tom.

          People

          • Assignee:
            Thomas E Enebo
            Reporter:
            Johan Holmberg
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: