datamapper / dm-core

DataMapper - Core
http://datamapper.org/
MIT License
754 stars 153 forks source link

dm-core generates excessive warnings #172

Open lsiden opened 12 years ago

lsiden commented 12 years ago

I'm using dm-core 1.2.0 When I enable warnings with "ruby -w", dm-core generates several screen-fulls of warnings. I know that warnings are incredibly useful, but not if they are not dealt with and clutter up my output so badly that I have trouble noticing warnings that are generated by my own code that I need to deal with.

I have been able to suppress warnings generated in DataMapper#setup() by bracketing it with "$VERBOSE=nil" (turn them off) and "$VERBOSE=false" (set them back to default) - see http://www.justskins.com/forums/warnings-33468.html#post97927.

However, there are still at least a dozen warnings and I have not been able to figure out where to turn them off.

.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/query/conditions/comparison.rb:278: warning: private attribute?
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/resource/persistence_state.rb:40: warning: private attribute?
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/property/object.rb:19: warning: mismatched indentations at 'end' with 'case' at 14
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/model/hook.rb:56: warning: shadowing outer local variable - hooks
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/model/property.rb:68: warning: shadowing outer local variable - properties
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/model/property.rb:86: warning: shadowing outer local variable - context
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/associations/relationship.rb:656: warning: shadowing outer local variable - source
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/associations/relationship.rb:433: warning: private attribute?
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/associations/relationship.rb:436: warning: private attribute?
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/associations/one_to_one.rb:67: warning: private attribute?
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-core-1.2.0/lib/dm-core/support/logger.rb:71: warning: instance variable @log not initialized
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-constraints-1.2.0/lib/data_mapper/constraints/relationship/one_to_many.rb:20: warning: shadowing outer local variable - resource
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-migrations-1.2.0/lib/dm-migrations/sql/table_creator.rb:17: warning: `&' interpreted as argument prefix
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-migrations-1.2.0/lib/dm-migrations/sql/table_modifier.rb:14: warning: `&' interpreted as argument prefix
.../.rvm/gems/ruby-1.9.2-p290@accounts/gems/dm-validations-1.2.0/lib/dm-validations/formats/email.rb:59: warning: character class has duplicated range

I suppose I can hack the library to throw an exception on each of the warning lines so that I can figure out where in my code they are getting called from and bracket that code as Matz suggested with $VERBOSE=nil etc.

For future releases, could these be suppressed in the "production" version of the gem since there's little that I or anyone can do about them without opening up DataMapper and they make it much harder for me to see warnings generated by my own code?

lsiden commented 12 years ago

Out of exasperation I put "$VERBOSE=nil" at the top of my copy of resource.rb. That stopped most of it. I still see this line that someone may want to look at later:

.../dm-core-1.2.0/lib/dm-core/query/conditions/comparison.rb:278: warning: private attribute?

At least I can see warnings generated by my own code now.

lsiden commented 12 years ago

In order not to seem like such a whiner (what a great name for a Cucumber feature!), I cloned dm-core to my own hard drive to get a better look and possibly generate some patches or pull requests that might make it better for me and others. But first, I have to determine what branch to start working on. Looks like the currently release gem, v1.2.0, might be built from the branch release-1.2 or tag v1.2.0. Neither seems to be reachable from the other.

$ git rev-parse origin/release-1.2
03f14bca5350f289261348c3411fb4bc1f333eff
$ git rev-parse v1.2.0
b950a57e03e9c6e782f6578739d910c0a16227bc
$ git log --pretty=oneline origin/release-1.2 |grep b950a57
$ git log --pretty=oneline v1.2.0 |grep 03f14bc

Which of these is dm-core 1.2.0 base on?

Looking at commit history of lib/dm-core/version, it looks like it went directly from

VERSION = '1.2.0.rc1'

to

VERSION - '1.3.0.beta'

What happened to 1.2.0, the currently released version of the gem? Would the "real" commit please stand up?!

solnic commented 12 years ago

@lsiden re VERSION - I just forgot to bump it :( current 1.2.0 is maintained in release-1.2 branch. Master is now in 1.3.0.beta where jeweler has been removed and we use VERSION constant in the gemspec so it will be always up-to-date

lsiden commented 12 years ago

OK, now about all those warnings...

Is anyone going to clean them up or should I submit a pull request?

solnic commented 12 years ago

@lsiden pull requests are always welcome :)

lsiden commented 12 years ago

Well this is interesting. My strategy is to start checkout tag v1.2, run "rake rspec" and see where the warnings are, but but it just keeps going forever. I tried hacking tasks/spec.rake to do just the tests in one dir at a time, for example public/, semipublic/ then unit/, but I grdidn't see any warnings, just a lot of "Pending" messages.

Even weirder, I don't see the warnings when I run rspec on my own app now since I refactored my "requires".

All I know is, this is the first time I've created a gem on this scale, and as I refine it and refactor it's configuration, I get some surprises.

Re. my previous comment, you responded

I just forgot to bump it :( current 1.2.0 is maintained in release-1.2 branch.

Okay, then why isn't commit v1.2.0 reachable from commit (branch) release-1.2?

$ git co release-1.2
Previous HEAD position was a5ce6f2... Version bump to 1.2.0
$ git rev-parse v1.2.0
b950a57e03e9c6e782f6578739d910c0a16227bc
$ git log --pretty=oneline | grep b950a57
$ 

(Hope I'm not sounding argumentative - I'm just wondering out loud.)