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

D7aaf307f96bbdf5ff39be313fe581be?d=identicon&s=25 Orion Edwards (Guest)
on 2012-01-03 23:04
(Received via mailing list)
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
Cb51033949ffccd982ae32c9f890f25a?d=identicon&s=25 Tomas Matousek (Guest)
on 2012-01-04 05:12
(Received via mailing list)
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
This topic is locked and can not be replied to.