__FILE__ isn't reported correctly

[seanabraham]

I'm not sure whether to file this issue on this project or https://github.com/brandoncc/vscode-seeing-is-believing, but it looks like __FILE__ isn't supported and I wanted to add an issue for it.

Here's an example:

The evaluated value shows a path to a temp directory and program.rb instead of /actual/path/to/file/test.rb

[seanabraham]

It looks like the temp directory breaks require_relative as well:

For context I'm on macOS 10.12.6 and using Ruby 2.3.1

[JoshCheek]

Whoah, I didn't even realize that existed! Anyway, it'd be an issue with that project. If they don't tell SiB that the file is saved somewhere, it will save it in a temp dir.

This allows you to just open a file in your editor and start running it with SiB, it's actually the primary way that I use it.

But, if you want it to be located somewhere specific, you need to tell that to SiB. Either with the --as flag (eg), or by passing the filename to SiB (in that situation, you wouldn't need to send the editor's buffer, just the currently edited filename).

As an end-user, the way to deal with it without fixing the lib, depends what you're trying to do. Sounds like you're trying to require

• If it's one file, you can require '/full/path/to/file'
• If it's a gem or something, you can $LOAD_PATH.unshfit '/full/path/to/dir'; require 'adb_all'
• If you actually need to be in that dir for something, beyond requiring, you can Dir.chdir '/full/path/to/dir'

[JoshCheek]

Going to close this as it isn't a bug in SiB. You could open an issue on the vscode integration repo, if you want to consider it a bug.

It is worth noting that there is at least one good reason for it to do what it is doing, which is that SiB rewrites the file. It does this so that it actually evaluates the file (explicitly for the purpose of allowing use-cases like yours). But some editors see the file rewrite so quickly that they reread the file and display the rewritten version, and then when SiB puts the old file back into place, they see that and read it to display that version. In a normal-case scenario, this means that the file can flash around crazily, but in a worst-case scenario, I've seen editors freak out about it. If that is happening, then one way to deal with it is to not use the actual file on disk, and instead evaluate all files anonymously, which is what vscode seems to be doing. Ideally SiB wouldn't need to overwrite the file, but TBH, it's a pretty difficult problem. E.g. if we didn't, then we'd also have to replace __FILE__ and __dir__ macros and probably choreograph the $LOAD_PATH and $LOADED_FEATURES, we'd probably need to do something clever to get require_relative to work, and there are probably other edge cases, too. Again, IDK if that's what's going on here, but it's one possibility.