require and include reference the same resource?

I'm puzzled by the ruby highlighting of module hierarchies.

When I 'require' a file correctly and then 'include' the module hierarchies in the file, the ruby ide poses an error in its ability to find the module hierarchy.

However the objects referenced in the code (in a unit test, for example) act properly without prepending the module hierarchy as a 'namespace'.

Is there a hidden issue here? Like maybe a 'setting' I haven't enabled?

require File.expand_path(File.dirname(File.dirname(File.dirname(File.dirname(__FILE__)))) + "/common/const/lumber.rb" )
require File.expand_path(File.dirname(File.dirname(File.dirname(File.dirname(__FILE__)))) + "/common/const/hardware.rb" )
require File.expand_path(File.dirname(File.dirname(File.dirname(__FILE__))) + "/controllers/trw_menus_controller.rb" )
require File.expand_path(File.dirname(File.dirname(File.dirname(__FILE__))) + "/const/menus_const.rb" )
include TRW::COMMON::CONST::LBR
include TRW::COMMON::CONST::HDW
include TRW::MENUS::CONST
include TRW::CONTROLLERS



THanks,

Kimball
7 comments
Comment actions Permalink

Hello Kimball,

RubyMine doesn't have a power of supercow, and in this particular case it didn't coped with such a complicated expression evaluation as

File.expand_path(File.dirname(File.dirname(File.dirname(File.dirname(__FILE__)))) + "/common/const/lumber.rb" )

Also please ensure that after evaluating this expresssion you really get existing file.


Regards,
Oleg

0
Comment actions Permalink

By the way, what are you trying to archive with such code? No matter how much time you call dirname it returns directory for directory:

foo.rb:
p File.expand_path File.dirname(File.dirname(File.dirname(__FILE__)))
p File.expand_path File.dirname(File.dirname(__FILE__))
p File.expand_path File.dirname(__FILE__)


Run result:
denofevil@Dennis-Ushakovs-Mac-Pro ~/temp $ ruby foo.rb
"/Users/denofevil/Temp"
"/Users/denofevil/Temp"
"/Users/denofevil/Temp"

If you want to get an upper level directory, you should use something like that:
File.dirname(File.dirname(File.dirname(__FILE__))) + "/../filename"
0
Comment actions Permalink

Oleg,

Thanks for your reply.

I'm not familiar with supercow and google says its a computer game.

Nonetheless, I appreciate your insight.

Based on your answer, I guess my question should have been stated this way:

All the expressions I included are considered valid by the Ruby interpreter.

And both the 'require' and the 'include' statements seem to be operating as normal, and the references are recognized by my code.

So why does the RubyMine IDE indicate that the 'include' reference to the nested modules fail?

I believe your answer is that the IDE cannot parse the complex 'require' statement, therefore it is unaware of the presence of the physical file containing the definition of the two modules.

Therefore it states that the 'include' statement cannot be verified.

'cannot be verified' seems to be a correct interpretation according to the IDE since it is unable to determine that the reference to the modules is either correct or incorrect.

I think perhaps simplifying the File.expand_path statements may be the answer.

Thanks again,

Kimball

0
Comment actions Permalink

Dennis,

This is a bit of a surprise to me that you say the nested File.dirname(File.dirname()) statements do not produce a ladder of folder references on your system as they do on mine.

If I use this construct, it works very well.

If I were to base my expectations on your example, my references would not work.

And finally, this test is green:



require "test/unit"

class RubyRequireTests < Test::Unit::TestCase

 def  test_nested_dir_names

 single = File.expand_path(File.dirname(__FILE__))

 assert_equal('C:/Program Files/Google/Google SketchUp 7/Plugins/trw/tests/ruby',single)

 multiple = File.expand_path(File.dirname(File.dirname(__FILE__)))

 assert_equal('C:/Program Files/Google/Google SketchUp 7/Plugins/trw/tests',multiple)

 end
 
end



Of course I'm using the world's most successful business OS, which might make a slight difference in how this statement works.

However, your suggestion of putting the train of double periods would hand the responsibility for climbing the folder tree back to the OS and perhaps relieve the ruby interpreter of that effort.

My preference would be to construct a class of 'constant' strings for the well known paths and use them.

Then I would not need to figure out the count of periods for each file.

Thanks for your suggestion,

Kimball

oops, almost forgot this:   --)

0
Comment actions Permalink

I've checked this on Windows 7 on both ruby 1.8.7 and 1.9.1:
test.rb:
p File.expand_path(File.dirname(File.dirname(__FILE__))) == File.expand_path(File.dirname(__FILE__))

1.8.7:
ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32]
true

1.9.1:

ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

true

So, I suggest you not rely on the method that works differently on different ruby version, but to stick with solution that is proved to be working and moreover has IDE support

> Then I would not need to figure out the count of periods for each file.
But you need to figure out the count of dirname calls, don't you?
0
Comment actions Permalink

Dennis,

Thank you for addressing issues that may have to do with my goal.

So I fired up my instance of RubyMine 2.02 and downloaded both ruby 1.9.1 and 1.8.7 for windows.

However, after selected either of those versions in the RubyMine settings, I can no longer load any gems.

What do you think about the following image?

This is the result of any installation of any gem using either ruby sdk 1.8.7 or 1.9.1.

Thanks,

Kimball Johnson

rubyminegemerror..png

0
Comment actions Permalink

This happens because rubygems changed output format for the list command and RubyMine 2.0.2 is unable to parse new version correctly. Please, consider using latest EAP build (see http://confluence.jetbrains.net/display/RUBYDEV/RubyMine+EAP), problem is already fixed couple of builds ago.

0

Please sign in to leave a comment.