Open lsiden opened 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.
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?!
@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
OK, now about all those warnings...
Is anyone going to clean them up or should I submit a pull request?
@lsiden pull requests are always welcome :)
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.)
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.
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?