Note: This has already been posted on Ruby Forum some weeks ago. I'm crossposting it here, because I didn't get any response so far
Dir.glob provides an optional parameter, usually referred as 'flags'.
Where can I find a documentation about what flags are possible?
The Ruby 2.0 docs just say that the flags are "the same as used in
File.fnmatch".
Looking up the documentation of File.fnmatch, I only find the
explanation that these are the "FNM_xxx" flags, which can be or'ed
together. I could however find no documentation about what FNM_xxx flags
exist.
Where is this described?
It's actually defined inside File::Constants, and thereby documented under the same.
Look it up with ri :
ri File::Constants
Or read the html doc : Module: File::Constants (Ruby 2.2.2).
In the jquery-jasmine documentation (I've listed the exact revision of the docs in case they change).
It describes:
toContainHtml(string)
expect($('<div><ul></ul><h1>header</h1></div>')).toContainHtml('<ul></ul>')
toHaveHtml(string)
expect($('<div><span></span></div>')).toHaveHtml('<span></span>')
When should I use toContainHtml() and when should I use toHaveHtml()? From the examples I can't tell the difference.
Judging by this ticket on jasmine-jquery's github page
toHaveHtml() is more exacting using a == check
Whereas toContainHtml() uses an indexOf() check.
However the example in the documentation doesn't really demonstrate this, so I'm still not certain.
Similar to __callee__, is there something which returns the calling method? I realize there is the caller which I amble to strip the name of the caller method from but I am curious is there is a standard method for returning the name of the calling method without any other information along with it.
There is no such feature in MRI. But there are some alternatives.
In case you happen to use Rubinius, you can do this instead of parsing caller:
Rubinius::VM.backtrace(1, false).first.name
#=> :calling_method_name
You can also use a gem to parse the result of caller for you. It should work for any Ruby > 1.9.
The answer to this SO question describes how you can do some simple parsing yourself.
And finally, there appears to be work in progress on getting a feature like this into Ruby 2.0, although the relevant ticket has not been updated for a while.
I've seen plenty of posts providing the -W0 flag as an answer to this issue, but I don't want to suppress all warnings, just warnings of a particular value.
I'm running a non-rails app (which uses ActiveRecord, notwithstanding) on Ruby 1.8.7. I want to keep all warnings except for the following DEPRECATION WARNING:
Object#id will be deprecated; use Object#object_id
If that's not possible, I'd like to jettison all deprecation warnings. Java, at least, lets you do this. How about Ruby?
Update: I've upvoted both answers but checked the one that later searchers will expect to find here.
If there's a specific section of code that produces the warnings, you could try mixing in the Kernel module from ActiveSupport and wrap it with a silence_warnings block (example pulled straight from the RDoc):
silence_warnings do
value = do_something_that_causes_warning # no warning voiced
end
noisy_call # warning voiced
Is it absolutely necessary to suppress it? It's not like you're compiling something and have to sift through a ton of warnings all at once...
Edit: If you use read_attribute(:id), then you should avoid the waring. Thanks Jeremy!
I'm not a Rails developer, but isn't there a method that allows you to say "I want the database field id, not the id method of the object"?
Most of the code I write is in Ruby, and every once in a while, I make some typo which only gets caught after a while. This is irritating when I have my scripts running long tasks, and return to find I had a typo.
Is there an actively developed lint tool for Ruby that could help me overcome this? Would it be possible to use it across a system that works with a lot of source files, some of them loaded dynamically?
Take this snippet as an example:
a = 20
b = 30
puts c
To win bounty, show me a tool that will detect the c variable as not created/undefined.
ruby -c myfile.rb will check for correct Ruby syntax.
Reek checks Ruby code for common code smells.
Roodi checks Ruby code for common object-oriented design issues.
Flog can warn you about unusually complex code.
[Plug] If your project is in a public Github repository, Caliper can run the latter three tools and others on your code every time you commit. (Disclaimer: I work on Caliper)
You could give Diamondback Ruby a try. It does a static typecheck of Ruby code, and will thus blame you for using an undefined variable.
While DRuby is an ongoing research project, it already works quite well for small, self-contained Ruby scripts. Currently, it is unable to analyze much of the Ruby standard library “out-of-the-box”. Currently they are working toward typing Ruby on Rails (see their most recent papers).
RubyMine (http://www.jetbrains.com/ruby) does the trick:
alt text http://img707.imageshack.us/img707/5688/31911448.png
None of the below will do all the analysis that RubyMine does.
NetBeans Ruby pack
Aptana RadRails
gVIM (with syntastic plugin by scrooloose)
Each of these has the capacity to identify syntax errors such as wrong number of parentheses, too many defs, ends, braces, etc. But none will identify invalid method calls the way RubyMine does.
Here's why: it's difficult.
Since Ruby is extremely dynamic (and methods like 'c' could easily be generated on the fly), any editor that tries to identify non-existent variables/methods would need to have a large part of the entire evironment loaded and multiple program flow paths constantly tested in order to get accurate 'validity' results. This is much more difficult than in Java where almost all programming is static (at least it was when I dropped that hat).
This ability to easily generate methods on the fly is one of the reasons the community holds testing to such high esteem. I really do reccomend you try testing as well.
Have a look at RuboCop. It is a Ruby code style checker based on the Ruby Style Guide. It's maintained pretty actively and supports all major Ruby implementations. It works well with Ruby 1.9 and 2.0 and has great Emacs integration.
Yes. Test::Unit
Ok, I know you already know this and that in some sense this is a non-helpful answer, but you do bring up the negative consequence of duck typing, that there kind of is (at this time) no way around just writing more tests than something like Java might need.
So, for the record, see Test::Unit in the Ruby Standard Library or one of the other test frameworks.
Having unit tests that you can run and rerun is the best way to catch errors, and you do need more of them (tests, not errors :-) in dynamic languages like Ruby...
nitpick might be what you're lookng for.
With this code:
class MyString < String
def awesome
self.gsub("e", "3").gsub("l", "1").uppercase
end
end
puts MyString.new("leet").awesome
... it outputs:
$ nitpick misspelling.rb
*** Nitpick had trouble loading "misspelling.rb":
NoMethodError undefined method `uppercase' for "133t":MyString
Nothing to report boss! He's clean!
Have not used it yet, but sounds promising (will update when I've tested this).
https://github.com/michaeledgar/laser
Static analysis and style linter for Ruby code.
Pelusa is nice, but is working in rubinius only. This shouln't be a proplem for people familar with RVM though.
avdi#lazarus:~$ irb
>> a = 20
=> 20
>> b = 30
=> 30
>> puts c
NameError: undefined local variable or method `c' for main:Object
from (irb):3
>>
There ya go, the tool is called "IRB". Do I get the bounty?
I'm only half joking. I wrote this second answer to hopefully drive home the point that in Ruby, if you want to know that something is defined or not, you have to run the code.