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

Tue Dec 8 10:56:40 PST 2009

Gp, thanks for keeping on our toes ;)

- Matt

On Tue, Dec 8, 2009 at 8:06 AM, Giampiero De Ciantis
<gdeciantis at 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 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/0ff6c268/attachment.html>