<div dir="ltr">Hi Folks,<br><div><br>On Tue, Jan 21, 2014 at 4:18 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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></div></blockquote><div><br>Thank you for looking into this Frank. I will attempt to be more proactive about this job in the future and also get up to date on the latest configuration of the build server so that in the future I can take care of these issues myself. In the meantime your fix is greatly appreciated.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>> 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. 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></div></blockquote><div>The mac machine is a stand alone machine and as long as apple lets me keep it up to date I will. For the windows machine I was thinking I would get it setup inside of a VM because I remember you mentioning something about having to give Hudson the ability to run remote jobs and that really this could allow it to pwn the machine if it were ever malicious. I figured a vm I just keep up and running would help mitigate some of this risk. Does this ring any alarm bells for you?<br>
<br></div><div>If not, then I don't see any reason why I could not work to also get a FreeBSD vm up and running as well and then use that as the new machine. <br></div><div><br></div><div>If I don't hear any warnings of dire consequences I will go about sanitizing the mac machine and getting the windows VM set up this weekend. I'll get to the FreeBSD machine later but I think promising all 3 for the weekend would be overly optimistic.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 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="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><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 class="gmail_extra">Thanks again for all of your feedback and hard work,<br></div><div class="gmail_extra">Jeff<br></div></div></div>