[MacRuby-devel] Has the team given up on continuous integration?

Giampiero De Ciantis gdeciantis at gmail.com
Tue Dec 8 08:06:14 PST 2009


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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091208/eb4fd74a/attachment.html>


More information about the MacRuby-devel mailing list