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

Eloy Duran eloy.de.enige at gmail.com
Tue Dec 8 11:04:34 PST 2009


No problem , like Matt said, thanks for keeping us on our toes :)

I think the best way to do so is to have a goal. So pick a lib you  
know you need:
* Run it in a sample or its test suite
* Wheep and moan in a corner ;)
* Grab coffee
* Pick a failure and lookup the specs of that functionality
* Start hacking and asking

Cheers,
Eloy

On 8 dec 2009, at 17:06, Giampiero De Ciantis 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 at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> 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/0309ea56/attachment-0001.html>


More information about the MacRuby-devel mailing list