Forum: IronRuby IronRuby internals - How can I get the full path to the current file?

I thought I'd be a good samaritan and implement require_relative in
IronRuby, but I'm having real trouble figuring out what the current 
file's
path actually is.

The closest I've got is something like this:

* Pull apart the the caller/backtrace to get the file name
* File.expand_path(file,  File.dirname(dir))
* require that file

This is equivalent to the existing ruby idiom of "require
File.join(File.dirname(__FILE__), 'lib/file1')", but this doesn't work
reliably because __FILE__ is already relative, so File.dirname(__FILE__)
often just returns "."
Without the full path to the current file however, this is as good as we
can get.

I've looked through various parts of the IronRuby source code...
- as far as I can tell the Parser/Syntax tree code (which has access to
the file path) doesn't keep the information around
- and even if it did, I'm not sure how regular ruby code could access 
the
parser/AST??

If anyone could help at all, even with a small bit of detail, it'd be 
much
appreciated.
Thanks, Orion

PS:

Here's my test program, which works correctly in MRI 1.92, but I cannot
get it to work in IronRuby

require_relative 'lib/file1'
Dir.chdir 'c:/windows/system32'
require_relative 'lib/file2'


Other things I tried

- eval("__FILE__") - is hard-coded to return "(eval)"

- I thought about poking around in RubyContext.Loader.LoadedFiles, but 
the
Loader doesn't know about the entry-point file (is this a bug??), which 
is
a big stumbling block

I'd recommend to start with some simpler features than this one. This 
seems to be quite non-trivial to implement efficiently and correctly.
Note that getting the current stack trace is very expensive, so you'd 
probably want to encode the path into Ruby call-sites (RubyCallAction) 
or something like that. But also adding more information to all 
call-sites consumes more memory so maybe we need a special call-site for 
methods called "require_relative" and fall back to the slow stack trace 
capture only when the method is called via an alias.

Tomas

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, January 03, 2012 2:02 PM
To: ironruby-core@rubyforge.org
Subject: [Ironruby-core] IronRuby internals - How can I get the full 
path to the current file?

I thought I'd be a good samaritan and implement require_relative in 
IronRuby, but I'm having real trouble figuring out what the current 
file's path actually is.

The closest I've got is something like this:

* Pull apart the the caller/backtrace to get the file name
* File.expand_path(file,  File.dirname(dir))
* require that file

This is equivalent to the existing ruby idiom of "require 
File.join(File.dirname(__FILE__), 'lib/file1')", but this doesn't work 
reliably because __FILE__ is already relative, so File.dirname(__FILE__) 
often just returns "."
Without the full path to the current file however, this is as good as we 
can get.

I've looked through various parts of the IronRuby source code...
- as far as I can tell the Parser/Syntax tree code (which has access to 
the file path) doesn't keep the information around
- and even if it did, I'm not sure how regular ruby code could access 
the parser/AST??

If anyone could help at all, even with a small bit of detail, it'd be 
much appreciated.
Thanks, Orion

PS:

Here's my test program, which works correctly in MRI 1.92, but I cannot 
get it to work in IronRuby

require_relative 'lib/file1'
Dir.chdir 'c:/windows/system32'
require_relative 'lib/file2'


Other things I tried

- eval("__FILE__") - is hard-coded to return "(eval)"

- I thought about poking around in RubyContext.Loader.LoadedFiles, but 
the Loader doesn't know about the entry-point file (is this a bug??), 
which is a big stumbling block