From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11482 invoked by alias); 30 Jul 2007 15:38:47 -0000 Received: (qmail 11473 invoked by uid 22791); 30 Jul 2007 15:38:46 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jul 2007 15:38:37 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6UFcUuV028349; Mon, 30 Jul 2007 11:38:30 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6UFcTxO004285; Mon, 30 Jul 2007 11:38:30 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6UFcSKQ000818; Mon, 30 Jul 2007 11:38:29 -0400 Message-ID: <46AE05F6.8050203@redhat.com> Date: Mon, 30 Jul 2007 15:38:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Kris Van Hees , pearly.zhao@oracle.com CC: Frysk Mailing List Subject: Re: [patch] fix bug 4612 References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> <20070730150949.GB22305@oracle.com> In-Reply-To: <20070730150949.GB22305@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00221.txt.bz2 Kris, Yes, the dogtail testing. You'll see that there frysk-gui tree now also contains JUnit tests; and we're able to more directly test components using that. Pearly, you may want to talk to Sami about opportunities here. Andrew Kris Van Hees wrote: > Woops, my apologies for sending this off before responding to the first point > as well (I guess I do need more coffee): > > I do agree that testing is important (obviously), and hope that we will be able > to increase our GUI test coverage as time goes by. However, it clearly has > been a problem in the past as well (as witnessed by the very limited amount of > GUI tests that currently exist), and that is very understandable given the > framework needed to create those tests. Andrew even mentioned at OLS thatthe > GUI is essentially not tested. > > But we do need to get these bugs fixed, and make the GUI usable. Given the > complexity writing GUI tests (using dogtail), it seem more prudent to wait for > the affected windows to stabilize to write tests. Otherwise it's just going > to be a wasted effort. > > Cheers, > Kris > > On Mon, Jul 30, 2007 at 10:39:27AM -0400, Kris Van Hees wrote: > >> The code duplication between the Disassembler and Memory windows has been >> mentioned during the conf call where I pointed out the various problems >> found with those windows (and their implementation). It certainly could do >> with a refactoring, although it is too early for that right now. For one, >> I do not think it is wise to do it as part of a bug fix, and secondly, the >> planned changes to the Memory window will cause it to deviate more from the >> Disassembler window than it does now, so premature refactoring is likely to >> need a (partial) reversal later on. >> >> Cheers, >> Kris >> >> On Mon, Jul 30, 2007 at 09:02:19AM -0400, Andrew Cagney wrote: >> >>> Pearly, >>> >>> The below looks fine. Will you be around tuesday morning (your time?). >>> I'll send you off list some stuff to do with CVS so that you can check this >>> in. >>> >>> Two things to think about though: >>> >>> -> testing; >>> When making fixes we all endeavor to author the test-case up-front so that >>> we can directly demonstrate that the change has the intended effect. >>> >>> -> it looks like there is much code duplication between the Disassembler >>> and Memory windows; >>> an opportunity to refactor? >>>