Ironruby core - Jan 2012 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20120104/f9e246a9/attachment.html>

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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, January 03, 2012 2:02 PM
To: ironruby-core at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20120104/c2d0f510/attachment.html>