I could use:
File.open('/dev/null', 'w')
on Unix systems, but if there is a Ruby way to achieve this, I'd like to use it. I am just looking for an I/O stream, that immediately "trashes" all writes, kind of like a null-object.
If you want the full behavior of streams, the best is probably to use:
File.open(File::NULL, "w")
Note that File::NULL is new to Ruby 1.9.3; you can use my backports gem:
require 'backports/1.9.3/file/null' # => Won't do anything in 1.9.3+
File.open(File::NULL, "w") # => works even in Ruby 1.8.6
You could also copy the relevant code if you prefer.
There's stringIO, which I find useful when I want to introduce a dummy filestream:
require "stringio"
f = StringIO.new
f.gets # => nil
And here's some code from heckle that finds the bit bucket for both Unix and Windows, slightly modified:
# Is this platform MS Windows-like?
# Actually, I suspect the following line is not very reliable.
WINDOWS = RUBY_PLATFORM =~ /mswin/
# Path to the bit bucket.
NULL_PATH = WINDOWS ? 'NUL:' : '/dev/null'
No, I don't believe there is anything like a null stream in Ruby, at least in earlier versions. In that case, you must make one yourself. Depending on the methods that it will call, you will need to write
stub methods on the null stream class, like this:
class NullStream
def <<(o); self; end
end
The above example is by no means complete. For example, some streams may require calling the write, puts or other methods. Moreover, some methods should be implemented by returning self in their methods, like <<, others not.
Logger.new("/dev/null") does the trick
There's a gem called devnull
Ruby implementation of null file (like /dev/null on Un*x, NUL on
Windows)
It doesn't interact with the null file, but instead has dummy methods for all the methods that IO objects implement.
Related
I am writing a ruby DSL that will be used to code-generate a number of Objective-C++ functions. I would like the name of each function to be derived from the name of its ruby DSL source file.
For example, given this source file clusterOptions.rb:
require './vMATCodeMonkey'
VMATCodeMonkey.new(:print).options_processor <<EOS
-cutoff: flag: set('useCutoff', true), arg: vector('double')
-depth: flag: set('useInconsistent', true), arg: scalar('double', default: 2.0)
-maxclust: flag: set('useCutoff', false), arg: vector('index')
EOS
When the VMATCodeMonkey.new(:print) expression is evaluated I would ideally somehow like the new object to capture the clusterOptions.rb source filename. Is that possible?
And if (as I suspect) it is not, is there a good idiom for accomplishing this functionality [e.g. making the source file name effectively part of the specification captured by a DSL] in ruby?
[While I suspect it's not possible to do exactly as I've described, I ask anyway, because I've been surprised by ruby's obscure capabilities more than once.]
EDIT: I'm aware of __FILE__; what I'm looking for is some DSL-centric way of capturing the name of a DSL source file without explicitly mentioning __FILE__ in the DSL source. Hmm, and now that I'm trying to explain it, maybe crawling up a stack trace from the class initialize method?
Solution
With thanks to tadman, here is my VMATCodeMonkey#initialize method:
def initialize(out_opt = :print)
#caller_file = caller(1)[0].split(':')[0]
case out_opt
when :pbcopy
#out = IO.popen('pbcopy', 'w')
when :print
#out = $stdout
else
raise ArgumentError, "#{out_opt} is not an option!"
end
#out.puts "// vMATCodeMonkey's work; do not edit by hand!\n\n"
initialize_options_processor
end
And here's what it captures:
#caller_file = "/Users/Shared/Source/vMAT/ruby/clusterOptions.rb"
The full path to the source file being evaluated is stored in __FILE__. If you want just the filename, you'd use:
File.basename(__FILE__)
The __FILE__ constant is common to C, C++, Perl and Python, among others.
If you need to know what file made the call to the currently running routine, this could work:
caller(1)[0].split(':')[0]
This presumes your filenames do not have : in them, but in most cases that should be a fairly safe assumption. You'll also need to call this at the entry point into your library. If it's a method deeper in the stack, test caller(2) and so on.
Apologies for the poorly worded question title - no idea how to put it better!
In the following code, when I execute ruby bar.rb, how can I make it output bar.rb, rather than foo.rb?
In foo.rb:
module Foo
def filename
__FILE__
end
end
In bar.rb:
require_relative 'foo'
include Foo
puts filename # outputs 'foo.rb'
This is for a library function that, each time some code is executed, records the location (and git ref) of that code.
Your question stimulated me to crack open the Ruby interpreter source and see how __FILE__ actually works. The answer is pretty interesting: it's implemented right inside the parser. The lexer has a special token type for __FILE__. When the parser sees that token, it converts it to a string constant, which contains the name of the file the parser is working on.
From line 14948 of ext/ripper/ripper.c:
case keyword__FILE__:
return NEW_STR(rb_external_str_new_with_enc(ruby_sourcefile, strlen(ruby_sourcefile),
rb_filesystem_encoding()));
I think this should make it clear that trying to make __FILE__ return the name of the including file is completely impossible, unless you hack the Ruby interpreter source, or write your own preprocessor which transforms __FILE__ to something else before passing the Ruby source to the interpreter!
There is a trick you might be a able to use. If you pass a block to the method you could use the blocks closure to determine it's source. Something like:
def filename(&blk)
blk.eval "__FILE__"
end
But again, that means you have to pass a block.
Honestly I wonder what you are trying to accomplish, b/c outside of make some common core extension method, this is probably something you really don't want to do.
I'm wanting to use the &method(:method_name) idiom when there's more than one object required by method_name. Can I do this under Ruby 1.9?
For example, if I've got
def move_file(old_filename, new_filename)
STDERR.puts "Moving #{old_filename.inspect} to #{new_filename.inspect}"
# Implementation for careful moving goes here
end
old_filenames = ["foo.txt", "bar.txt", "hoge.ja.txt"]
new_filenames = ["foo_20110915.txt", "bar_20110915.txt", "hoge_20110915.ja.txt"]
the code
old_filenames.zip(new_filenames).each(&method(:move_file))
works under Ruby 1.8, but not under Ruby 1.9. Under Ruby 1.9, it's trying to do move_file(["foo.txt", "foo_20110915.txt"]) instead of move_file("foo.txt", "foo_20110915.txt").
How do I splattify it so it has the correct arity?
Workarounds I'm aware of:
Replace def move_file(old_filename, new_filename) with def move_file(*arguments)
Replace each(&method(:move_file)) with
each{|old_filename, new_filename| move_file(old_filename, new_filename)}
Instead
each{|old_filename, new_filename| move_file(old_filename, new_filename)}
you should be able to do
each{|pair| move_file(*pair)}
But I don't know how you'd pull off blockless variant (I needed it couple of times as well). I guess &-shorthand was made to make the syntax simpler, and is not meant to be clogged much (whether it will be passed an array as an array, or splatted, for example). :)
How do I splattify it so it has the correct arity?
I don't think there is a way to do this while being compatible to both Ruby versions. What you could do is wrap it into a lambda
move_from_to = Proc.new {|*both| move_files(*both) }
The thing is - block and proc arity is something that got addressed in Ruby 1.9 so there might be a difference in behavior there. Also see prc.lambda? here http://www.ruby-doc.org/core/classes/Proc.html for info on what it does to the arity.
This question is also related to what you want to do (the solution there is to resplat and unsplat manually): Inconsistency of arity between Hash.each and lambdas
Is there a nice, recommended way to get the name of the file that called a method? I don't want to pass __FILE__ every time. The closest thing I've found is taking the first element of Kernel.caller, which is okay but has the calling line number appended like "test.rb:7". It's easy enough to strip off, but using it seems like something that might be dependent on the interpreter or might change in the future.
In Ruby 2.0+ you can do this using Kernel#caller_locations. It's very similar to caller, with the added benefit that you don't need to parse out the file name manually, since it returns Thread::Backtrace::Location objects instead of Strings:
file1.rb:
def some_method
puts caller_locations.first.path
end
file2.rb:
require_relative './file1'
some_method
Shell:
$ ruby file2.rb
file2.rb
Perhaps it's safer than you think? I found this other post http://snippets.dzone.com/posts/show/2787 where someone did something similar to what you're suggesting...
I want to truncate #inspect output in irb (a large output must be cropped to MAX_LEN).
Currently, I override :inspect, :to_s methods for all specific objects.
Is there are other solution?
change $stdout ?
other?
For a clean solution, gem install hirb. hirb pages irb's returned values if they get too long.
If you want to monkeypatch irb:
module IRB
class Irb
def output_value
#context.last_value.to_s.slice(0, MAX_LEN)
end
end
end
I don't recommend this because it's a hack and breaks any time gems like ap and hirb are required.
Instead of monkeypatching irb, I'd recommend trying ripl, an irb alternative that is meant to extended.
The above as a ripl plugin would be:
require 'ripl'
module Ripl::SlicedInspect
def format_result(result)
result_prompt + result.inspect.slice(MAX_LEN)
end
end
Ripl::Shell.send :include, Ripl::SlicedInspect
With this plugin, you could require it as needed or add to your ~/.riplrc if you want to always use it.
Your solution is good.
It involves no dark magic, which might make the code less understandable and error-prone.
If you're just in IRB - you could define a monkeypatch in irb itself and or load a file that monkeypatches inspect via 'load'. This way you keep it out of your core codebase but you still get the functionality you need w/o having to override inspect in every class you wish to inspect....
If it's because you have a nested hash or something that's hard to decipher, try awesome_print. You can make it the default output formatter in irb by placing the following in your .irbrc:
require 'ap'
module IRB
class Irb
def output_value
ap #context.last_value
end
end
end
This makes objects with lots of data easy to decipher in IRB.
Even if you don't use awesome_print, you can truncate output using this same technique so you don't have to override to_s in your code.
For rails 3.1.1+, place the code below in helpers/irb_helper.rb
module IRB
class Irb
MAX_LEN = 10000
def output_value
if (#context.inspect_last_value.length > MAX_LEN)
printf #context.return_format, "#{#context.inspect_last_value[0..MAX_LEN]} <- Truncated"
else
printf #context.return_format, #context.inspect_last_value
end
end
end
end
If you'd like to customize your output more, check irb's source at https://github.com/Ruby/Ruby/blob/trunk/lib/irb.rb
I sometimes modify the objects themselves (via a module called BoringInspect which I include into the relevant classes) so that exception messages are also manageable.