Re: Making juju work better with gccgo
I realise I left this bit hanging: On 16/05/14 14:41, Tim Penhey wrote: > A key issue that Dave and I have been poking with a stick is the test > suite for juju/errgo, as it had some failures with gccgo (all passed > with gc). In the end it had to do with the runtime.Caller method for stack analysis, and the synthetic methods that gccgo was creating. The solution was simply enough to convert the tests to use gocheck, that way the synthetic methods that were being created are higher in the stack that we ever look in the tests, and it is all good. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Making juju work better with gccgo
Thanks Tim, I think we're in the position that even if you don't use gccgo for your own development (understandable, it is slower), now that we have platforms we support in Trusty that must use gccgo, armv8 and ppc64el, for any new development, the code has to pass under both compilers. This is a bit of a bummer, but at least if you are running trusty on your development environment, you have all the bits you need[1][2]. Running tests, for a single package then becomes go test && go test -compiler=gccgo With respect to the whole Juju test suite, even after months of work there still remain a few tests which do not pass under trusty, these are tracked with bugs in lp, just look for the gccgo label if you find yourself at a loose end. Cheers Dave [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not of acceptable quality for use with Juju. [2] If for some reason you don't want to upgrade to trusty, we may be able to ask Doko for a backport of gccgo-4.9, but really, just upgrade to trusty. On Fri, May 16, 2014 at 12:44 PM, Tim Penhey wrote: > I realise I left this bit hanging: > > On 16/05/14 14:41, Tim Penhey wrote: >> A key issue that Dave and I have been poking with a stick is the test >> suite for juju/errgo, as it had some failures with gccgo (all passed >> with gc). > > In the end it had to do with the runtime.Caller method for stack > analysis, and the synthetic methods that gccgo was creating. The > solution was simply enough to convert the tests to use gocheck, that way > the synthetic methods that were being created are higher in the stack > that we ever look in the tests, and it is all good. > > Tim > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Making juju work better with gccgo
FWIW, I wrote this little bash function and put it in my ~/.bashrc
function gotest {
p="-gocheck.v"
f=""
if [ -n "$1" ]; then
if [ "$1" = "-r" ]; then
p="./..."
else
f="-gocheck.f=$f"
fi
fi
go test $p $f && go test -compiler=gccgo $p $f
}
That lets my write:
gotest
gotest -r
and
gotest justOneSuite
I'm sure something better could be done, but that makes things immediately
useful.
The compile time is noticeably slower at getting the tests running (so this
slows down iteration >2x), but until gccgo is ironed out it is probably
still worthwhile.
John
=:->
On Fri, May 16, 2014 at 6:53 AM, David Cheney wrote:
> Thanks Tim,
>
> I think we're in the position that even if you don't use gccgo for
> your own development (understandable, it is slower), now that we have
> platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
> for any new development, the code has to pass under both compilers.
>
> This is a bit of a bummer, but at least if you are running trusty on
> your development environment, you have all the bits you need[1][2].
>
> Running tests, for a single package then becomes
>
> go test && go test -compiler=gccgo
>
> With respect to the whole Juju test suite, even after months of work
> there still remain a few tests which do not pass under trusty, these
> are tracked with bugs in lp, just look for the gccgo label if you find
> yourself at a loose end.
>
> Cheers
>
> Dave
>
> [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
> of acceptable quality for use with Juju.
> [2] If for some reason you don't want to upgrade to trusty, we may be
> able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
> to trusty.
>
> On Fri, May 16, 2014 at 12:44 PM, Tim Penhey
> wrote:
> > I realise I left this bit hanging:
> >
> > On 16/05/14 14:41, Tim Penhey wrote:
> >> A key issue that Dave and I have been poking with a stick is the test
> >> suite for juju/errgo, as it had some failures with gccgo (all passed
> >> with gc).
> >
> > In the end it had to do with the runtime.Caller method for stack
> > analysis, and the synthetic methods that gccgo was creating. The
> > solution was simply enough to convert the tests to use gocheck, that way
> > the synthetic methods that were being created are higher in the stack
> > that we ever look in the tests, and it is all good.
> >
> > Tim
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
testing (was Re: Making juju work better with gccgo)
On 16/05/14 22:55, John Meinel wrote:
> FWIW, I wrote this little bash function and put it in my ~/.bashrc
> function gotest {
> p="-gocheck.v"
> f=""
> if [ -n "$1" ]; then
> if [ "$1" = "-r" ]; then
> p="./..."
> else
> f="-gocheck.f=$f"
> fi
> fi
> go test $p $f && go test -compiler=gccgo $p $f
> }
>
> That lets my write:
> gotest
> gotest -r
> and
> gotest justOneSuite
>
> I'm sure something better could be done, but that makes things
> immediately useful.
> The compile time is noticeably slower at getting the tests running (so
> this slows down iteration >2x), but until gccgo is ironed out it is
> probably still worthwhile.
I think it would be good if someone wrote a simple juju plug-in.
I toyed with this idea so it would give a similar feel.
We have hacks around hiding the log for failed tests so we can easily
see what failed, and dealing with other flags.
I thought we could have the plugin also emit the subunit output format
as an option for plugging into other tools like lifeless's test repository.
Main thing for me though was:
* a simple capture of the log output
* list the failing tests at the end so I don't need to go searching up
* elapsed time
* simpler way to execute one test so I don't need to type the gocheck
flags.
Tim
>
> John
> =:->
>
>
> On Fri, May 16, 2014 at 6:53 AM, David Cheney
> mailto:david.che...@canonical.com>> wrote:
>
> Thanks Tim,
>
> I think we're in the position that even if you don't use gccgo for
> your own development (understandable, it is slower), now that we have
> platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
> for any new development, the code has to pass under both compilers.
>
> This is a bit of a bummer, but at least if you are running trusty on
> your development environment, you have all the bits you need[1][2].
>
> Running tests, for a single package then becomes
>
> go test && go test -compiler=gccgo
>
> With respect to the whole Juju test suite, even after months of work
> there still remain a few tests which do not pass under trusty, these
> are tracked with bugs in lp, just look for the gccgo label if you find
> yourself at a loose end.
>
> Cheers
>
> Dave
>
> [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
> of acceptable quality for use with Juju.
> [2] If for some reason you don't want to upgrade to trusty, we may be
> able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
> to trusty.
>
> On Fri, May 16, 2014 at 12:44 PM, Tim Penhey
> mailto:tim.pen...@canonical.com>> wrote:
> > I realise I left this bit hanging:
> >
> > On 16/05/14 14:41, Tim Penhey wrote:
> >> A key issue that Dave and I have been poking with a stick is the test
> >> suite for juju/errgo, as it had some failures with gccgo (all passed
> >> with gc).
> >
> > In the end it had to do with the runtime.Caller method for stack
> > analysis, and the synthetic methods that gccgo was creating. The
> > solution was simply enough to convert the tests to use gocheck,
> that way
> > the synthetic methods that were being created are higher in the stack
> > that we ever look in the tests, and it is all good.
> >
> > Tim
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
