Thanks Eloy. I'll take my panic pants off and get it at it again. I feel somewhat sheepish since I have been trolling through this code for months (I think a year now) and haven't been able to submit a single patch. But I will continue to try.
Cheers, -Gp On 2009-12-08, at 7:55 AM, Eloy Duran wrote: > Hi, > > See my replies inline. > >> Frustrated, not upset. I never trust a system where the CI has been red for >> this long. >> >> Here are the results I get, and they are fairly consistent. I don't know how >> you got the output you are showing, I am running "rake spec:ci" as described >> in the readme. >> >> Gps-iMac:MacRuby Gp$ rake spec:ci >> (in /Users/Gp/projects/MacRuby) >> ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full >> MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] >> ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x7fff7037cbe0) >> malloc: *** auto malloc[47790]: error for object 0x1036d46d0: >> auto_zone_set_associative_ref: object should point to a GC block or a global >> address, otherwise associations will leak. Break on >> auto_zone_association_error() to debug. >> ...............................................................................................................................................................................................................................................................................................................................................................................F........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x10bb81000) >> malloc: reference count underflow for 0x20210edc0, break on >> auto_refcount_underflow_error to debug. >> .....macruby(47790,0x10bb81000) malloc: reference count underflow for >> 0x2020d9320, break on auto_refcount_underflow_error to debug. >> ..macruby(47790,0x10bb81000) malloc: reference count underflow for >> 0x202135260, break on auto_refcount_underflow_error to debug. >> ...................................................................................................................................................................................................................................F................................................................................................................................................................................................................................................ >> >> 1) >> String#dump includes .force_encoding(name) if the encoding isn't ASCII >> compatiable FAILED >> Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" >> core:in `raise:' >> core:in `each' >> core:in `all?' >> core:in `each' >> >> 2) >> TCPServer.new raises a SocketError when the host is unknown FAILED >> Expected SocketError >> but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind(2)) >> core:in `raise:' >> >> Finished in 162.793482 seconds >> >> 2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors >> rake aborted! >> Command failed with status (1): [./mspec/bin/mspec ci -B >> ./spec/macruby.msp...] >> >> (See full trace by running task with --trace) >> >> >> In my case you can see 2 failures and a few exceptions being thrown which is >> troubling (is the Rake task supposed to abort at the end too?). And as you >> can see I am getting different failures than you are. > > The reason that one of the two failures is different has probably more to do > with the environment being different, ie the alternative formatter subtly > changes something. And as Matt said, the String#dump failure is one that > can't be helped right now, so you should consider this to be ‘green’. Or > better yet, you could fix these. > > And yes, Rake always ‘aborts’ if a system call did not exit status 0. So > don't worry about that. > >> I am trying to help, but my C skills are weaker than my ruby (or pretty much >> any other language) and the code is not easy to work with. However, after >> reading more and more I am starting to understand how the C code affects the >> Ruby runtime. > > Yes! Please don't stop :) > >> But every time I have pulled down a new version of the code to see if I can >> add or fix something, I hope that the CI suite will pass so that I can start >> from green and then tinker, but the suite hasn't passed in a while. When it >> was isolated failures, I felt Ok, but the the malloc exceptions and the like >> give me definite pause. > > Don't worry about those right now. Why? Just don't, the people that know why > will look into it when the time is right. > >> I am not confident enough to fiddle around with stuff when the whole system >> is showing this many failures. > > There are only _two_ failures in both your output, not that many imo. That's > nothing compared to how many we still have tagged. Also, did you know that > MRI surely has more than two failing examples in the RubySpec at any given > time? This so you can put it into perspective. > >> False positives make me more cautious. If I hand you a patch, I want to say >> "the CI is still passing", but I can never say that. > > I understand your worries, but you can in fact do this. Just make sure to run > them _before_ patching and then compare afterwards. This is how I've been > working on, for instance, Rails as well. > > HTH, > Eloy > _______________________________________________ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
