<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 12:18 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 21 January 2014 00:58, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote:<br>
>> Hi Folks,<br>
><br>
> Hi Jeff,<br>
><br>
> Thanks for looking into this, I think it is important to maintain this<br>
> server and keep it producing meaningful tests.<br>
><br>
>><br>
>> I was taking a look at the <a href="http://build.squeak.org" target="_blank">build.squeak.org</a> server and it seemed like there<br>
>> was a lot more red than green and I thought that I should at least start<br>
>> contributing to trying to fix that. I added a project a while back to show<br>
>> performance data from the image and it seemed to putting out some decent<br>
>> data, at least from a trendline perspective, for the last little while.<br>
>> Squeak was getting quite a bit faster from about the ~200 run of the<br>
>> project to #380 before it popped back up. I'll investigate the change in<br>
>> speed and see if I can figure out the regression.<br>
>><br>
>> In the meantime however, the console output is showing that the actual<br>
>> tests ran fine, but the "bundle install" command is failing because we<br>
>> apparently don't have the appropriate ruby gem installed to run this<br>
>> command. Is this something I can fix via the Hudson web console or would I<br>
>> need access to the build server to do so? Does anyone with more ruby<br>
>> experience have a suggestion for this?<br>
<br>
</div>It doesn't fail, it just warns about libyaml. And since we don't use<br>
any YAML stuff, I didn't bother "fixing" the problem. But I'm very<br>
happy that someone other than me actually reads the console output!<br>
Thanks!<br>
<br>
(The relevant warning is this:<br>
<br>
+ bundle install<br>
/var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in<br>
`<top (required)>':<br>
It seems your ruby installation is missing psych (for YAML output).<br>
To eliminate this warning, please install libyaml and reinstall your ruby.<br>
)<br>
<br>
Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in<br>
the sea of red :( That was just because the build wasn't configured to<br>
use rvm. Fixed, and apologies for not fixing sooner.<br>
<div class="im"><br>
>> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing on<br>
>> the basis of being unable to use Git to checkout Frank's squeakci<br>
>> repository. I am not sure if that can be remedied by updating the installed<br>
>> software on the FreeBSD build slaves.<br>
<br>
</div>See below.<br>
<div class="im"><br>
> The CogVM build job is maintained by me (independently of the actual Cog<br>
> VM development). Is intended to verify code generation only, and the errors<br>
> that you see there reflect an actual error in the code generation. Possibly<br>
> the current error condition reflects some method that needs to be checked in<br>
> to VMMaker for oscog. This is useful information, and the error messages in<br>
> the workspace are real, so this is a good thing.<br>
><br>
> The FreeBSD Interpreter job has never worked. It is apparently owned by<br>
> nobody, and it seems to serve no useful purpose. I recall that it used to<br>
> be failing due to an improperly configured slave server (a FreeBSD machine<br>
> with duplicate and conflicting installations of UUID libraries I think)<br>
> but now it fails for no reason that I can understand. If anyone feels any<br>
> ownership for or interest in this job please speak up, otherwise I would<br>
> be happy to have the job disabled.<br>
<br>
</div>All the FreeBSD jobs are owned by me :) They _do_ serve a useful<br>
purpose, which is to say "it doesn't work on FreeBSD". The machine on<br>
which those jobs run is being retired by its owner (I was but a<br>
guest), so until I find a new FreeBSD node (volunteers welcome! No,<br>
really!), I'll disable the jobs. I've already marked the sole node<br>
(havnor) as offline.<br>
<div class="im"><br>
>> Finally I wanted to ask about build machine coverage. Do we still need a<br>
>> mac osx build machine to use remotely with Hudson and what about a windows<br>
>> machine? I have recently come into some machines and I was wondering if<br>
>> donating time on those two operating systems would be worthwhile? They are<br>
>> respectively running the latest version of OSX and Windows 8.1. I am<br>
>> assuming that our linux coverage is good.<br>
<br>
</div>I would love a Windows machine. LOVE. </blockquote><div><br></div><div>I noticed a test failing on Windows.</div><div>I posted a possible fix for it:</div><div>Files-kfr.120 in the inbox.</div><div><br></div><div>Cheers,</div>
<div>Karl </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The current mac osx node (norst)<br>
runs, er, Snow Leopard, I think. It would be very useful to have a<br>
latest-and-greatest OSX because I don't plan on upgrading from Snow<br>
Leopard.<br>
<div class="im"><br>
> I would think that test coverage for the Squeak unit tests on Windows and<br>
> Mac OS X is very important indeed, and it would be great if you are able<br>
> to provide that.<br>
<br>
</div>Test coverage is... _inadequate_, I think would be the polite way of<br>
putting it, both in the sense of our code having very low coverage,<br>
and in the sense of the tooling. TestCoverage tells you nothing more<br>
than that a method was run: there's no indication, for instance, that<br>
anything _inside_ that method ran. Also, you can't run coverage over<br>
anything in Kernel or a bunch of other places, because we always<br>
perform self-brain-surgery.<br>
<span class=""><font color="#888888"><br>
frank<br>
</font></span><div class=""><div class="h5"><br>
> Thanks,<br>
> Dave<br>
><br>
><br>
>><br>
>> Thanks for your help and time,<br>
>> Jeff<br>
<br>
</div></div></blockquote></div><br></div></div>