[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Automated testing project
From: |
Peeter Vois |
Subject: |
Re: [avr-libc-dev] Automated testing project |
Date: |
Wed, 19 Oct 2005 08:48:16 +0300 |
My Svannah username is PeeterVois
Best Regards ...
Peeter
Ühel ilusal kenal päeval Wed, 19 Oct 2005 08:43:44 +0300
Peeter Vois <address@hidden> kirjutas:
>
> As my proposed testsuite uses gdb serial protocol maybe it would be
> possible to set up hardware testplatforms for all / missing devices?
> This would need only minimal changes into testsuite.
>
> We could improve the simulavr too in this sence if we will have more
> resources.
>
> Having regression test running on some instances of devices from
> device classes would be step forward too.
>
> I would like to make the following steps in the near future ( in the
> order of importance ):
> 1. Import the MUL modifications into CVS
> 2. go on with the log() optimisations
> 3. improve the testsuite to have statistical module for results
> 4. Import the testsuite into CVS somewhere
> 5. I remember that I had some year ago porblem with constant + (nan) I
> would check this too
>
> Peeter
>
>
>
> Ühel ilusal kenal päeval Tue, 18 Oct 2005 23:36:39 +0200
> Joerg Wunsch <address@hidden> kirjutas:
>
> > As Peeter Vois wrote:
> >
> > > I'm thinking what would I do with the testing environment. We
> > > could merge it with avr-libc project or create a new project for
> > > libc automated testing.
> >
> > I'm quite busy right now, and wish I'd already made avr-libc-1.4.0
> > reality.
> >
> > Anyway, after that happened, it already became pretty clear to me
> > we need some sort of regression test. Currently, for any new
> > device, I'm running a small test program on it to see whether the
> > library adaptation for the new device actually works.
> >
> > After seeing how GCC uses dejagnu, I've already thought about using
> > that for regression tests, but I'm open for any option here.
> >
> > One major showstopper could be the limited device support in
> > simulavr/simulavrxx though. Basically, when extending the library
> > for new devices, it would require the simulation to also cover that
> > new device in order to make this a useful option.
> >
> > --
> > cheers, J"org .-.-. --... ...-- -.. . DL8DTL
> >
> > http://www.sax.de/~joerg/ NIC: JW11-RIPE
> > Never trust an operating system you don't have sources for. ;-)
> >
>
>
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
- [avr-libc-dev] Automated testing project, Peeter Vois, 2005/10/18
- Re: [avr-libc-dev] Automated testing project, Joerg Wunsch, 2005/10/18
- Re: [avr-libc-dev] Automated testing project, Peeter Vois, 2005/10/19
- Re: [avr-libc-dev] Automated testing project,
Peeter Vois <=
- Re: [avr-libc-dev] Automated testing project, Joerg Wunsch, 2005/10/19
- Re: [avr-libc-dev] Automated testing project, Paul Schlie, 2005/10/19
- Re: [avr-libc-dev] Automated testing project, Eric Weddington, 2005/10/19
- Re: [avr-libc-dev] Automated testing project, Paul Schlie, 2005/10/19
- Re: [avr-libc-dev] Automated testing project, Peeter Vois, 2005/10/20
- Re: [avr-libc-dev] Automated testing project, Joerg Wunsch, 2005/10/20
- Re: [avr-libc-dev] Automated testing project, Paul Schlie, 2005/10/20
- Re: [avr-libc-dev] Automated testing project, Joerg Wunsch, 2005/10/20
- Re: [avr-libc-dev] Automated testing project, Eric Weddington, 2005/10/20
- Re: [avr-libc-dev] Automated testing project, Russell Shaw, 2005/10/20