Gp, thanks for keeping on our toes ;) - Matt
On Tue, Dec 8, 2009 at 8:06 AM, Giampiero De Ciantis <gdecian...@gmail.com>wrote: > 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 > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > >
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
