On Tue, Jan 21, 2014 at 12:18 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 21 January 2014 00:58, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote:
> >> Hi Folks,
> >
> > Hi Jeff,
> >
> > Thanks for looking into this, I think it is important to maintain this
> > server and keep it producing meaningful tests.
> >
> >>
> >> I was taking a look at the build.squeak.org server and it seemed like
> there
> >> was a lot more red than green and I thought that I should at least start
> >> contributing to trying to fix that. I added a project a while back to
> show
> >> performance data from the image and it seemed to putting out some decent
> >> data, at least from a trendline perspective, for the last little while.
> >> Squeak was getting quite a bit faster from about the ~200 run of the
> >> project to #380 before it popped back up.  I'll investigate the change
> in
> >> speed and see if I can figure out the regression.
> >>
> >> In the meantime however, the console output is showing that the actual
> >> tests ran fine, but the "bundle install" command is failing because we
> >> apparently don't have the appropriate ruby gem installed to run this
> >> command.  Is this something I can fix via the Hudson web console or
> would I
> >> need access to the build server to do so? Does anyone with more ruby
> >> experience have a suggestion for this?
>
> It doesn't fail, it just warns about libyaml. And since we don't use
> any YAML stuff, I didn't bother "fixing" the problem. But I'm very
> happy that someone other than me actually reads the console output!
> Thanks!
>
> (The relevant warning is this:
>
> + bundle install
> /var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in
> `<top (required)>':
> It seems your ruby installation is missing psych (for YAML output).
> To eliminate this warning, please install libyaml and reinstall your ruby.
> )
>
> Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in
> the sea of red :( That was just because the build wasn't configured to
> use rvm. Fixed, and apologies for not fixing sooner.
>
> >> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing
> on
> >> the basis of being unable to use Git to checkout Frank's squeakci
> >> repository. I am not sure if that can be remedied by updating the
> installed
> >> software on the FreeBSD build slaves.
>
> See below.
>
> > The CogVM build job is maintained by me (independently of the actual Cog
> > VM development). Is intended to verify code generation only, and the
> errors
> > that you see there reflect an actual error in the code generation.
> Possibly
> > the current error condition reflects some method that needs to be
> checked in
> > to VMMaker for oscog. This is useful information, and the error messages
> in
> > the workspace are real, so this is a good thing.
> >
> > The FreeBSD Interpreter job has never worked. It is apparently owned by
> > nobody, and it seems to serve no useful purpose. I recall that it used to
> > be failing due to an improperly configured slave server (a FreeBSD
> machine
> > with duplicate and conflicting installations of UUID libraries I think)
> > but now it fails for no reason that I can understand. If anyone feels any
> > ownership for or interest in this job please speak up, otherwise I would
> > be happy to have the job disabled.
>
> All the FreeBSD jobs are owned by me :) They _do_ serve a useful
> purpose, which is to say "it doesn't work on FreeBSD". The machine on
> which those jobs run is being retired by its owner (I was but a
> guest), so until I find a new FreeBSD node (volunteers welcome! No,
> really!), I'll disable the jobs. I've already marked the sole node
> (havnor) as offline.
>
> >> Finally I wanted to ask about build machine coverage.  Do we still need
> a
> >> mac osx build machine to use remotely with Hudson and what about a
> windows
> >> machine?  I have recently come into some machines and I was wondering if
> >> donating time on those two operating systems would be worthwhile? They
> are
> >> respectively running the latest version of OSX and Windows 8.1. I am
> >> assuming that our linux coverage is good.
>
> I would love a Windows machine. LOVE.


I noticed a test failing on Windows.
I posted a possible fix for it:
Files-kfr.120 in the inbox.

Cheers,
Karl



> The current mac osx node (norst)
> runs, er, Snow Leopard, I think. It would be very useful to have a
> latest-and-greatest OSX because I don't plan on upgrading from Snow
> Leopard.
>
> > I would think that test coverage for the Squeak unit tests on Windows and
> > Mac OS X is very important indeed, and it would be great if you are able
> > to provide that.
>
> Test coverage is... _inadequate_, I think would be the polite way of
> putting it, both in the sense of our code having very low coverage,
> and in the sense of the tooling. TestCoverage tells you nothing more
> than that a method was run: there's no indication, for instance, that
> anything _inside_ that method ran. Also, you can't run coverage over
> anything in Kernel or a bunch of other places, because we always
> perform self-brain-surgery.
>
> frank
>
> > Thanks,
> > Dave
> >
> >
> >>
> >> Thanks for your help and time,
> >> Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140121/d82e4a76/attachment-0001.htm