public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Thomas Fitzsimmons <fitzsim@redhat.com>
To: "Steve McKay☄" <smckay@google.com>
Cc: David Herron <David.Herron@sun.com>, mauve-discuss@sources.redhat.com
Subject: Re: Tweaking default java.awt.Robot settings
Date: Tue, 25 Sep 2007 19:58:00 -0000	[thread overview]
Message-ID: <46F96854.6080706@redhat.com> (raw)
In-Reply-To: <4f2ee4520709251156yde57b65tbb97032939ac75e6@mail.gmail.com>

Steve McKay☄ wrote:
> Hi Thomas,
> 
>> If Robot can't be counted on to do something within some time
>> delay, is it also useless in non-test applications?
> 
> David's suggestion to use multi-threaded paradigms for dealing with
> the issue seems pretty good to me.

Yes, I shouldn't have said useless.. maybe "hard to use" :-)  In Mauve we traded 
timing-independent reproducibility for test case simplicity.  I did try writing 
synchronized Robot-using tests but it was a) difficult, and b) invasive, in that 
it required overriding and modifying the behaviour of methods that were being 
tested.

> For example, we can block until a
> window is ready to process events with code like this (only half baked
> at this time):

Even after you've ensured that the frame has responded, subsequent checks will 
still need to be synchronized, since Robot calls are not synchronous.  Or is 
this the specific problem that was causing test failures for you before -- that 
frames take a long time to be ready to receive events on other runtimes (e.g. 
Wine)?  If that's the main problem then maybe a hybrid approach of synchronizing 
frame readiness, then assuming small delays for Robot method calls, is a better 
approach.  Otherwise the proposal is to rewrite every Robot-using test to be 
perfectly synchronous (fine by me, but a big job).

Tom

  reply	other threads:[~2007-09-25 19:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-24 20:31 Steve McKay☄
2007-09-24 20:50 ` David Herron
2007-09-24 21:22   ` Steve McKay☄
2007-09-24 21:41     ` David Herron
2007-09-25 18:33       ` Lillian Angel
2007-09-25 19:13         ` Steve McKay☄
2007-09-25 19:27           ` Lillian Angel
2007-09-25 19:37             ` Steve McKay☄
2007-09-25 19:45               ` Lillian Angel
2007-09-25 19:27         ` David Herron
2007-09-25 18:33   ` Thomas Fitzsimmons
2007-09-25 18:57     ` Steve McKay☄
2007-09-25 19:58       ` Thomas Fitzsimmons [this message]
2007-09-25 20:28         ` Steve McKay☄
2007-10-04  0:43           ` Steve McKay☄
2007-10-04 13:04             ` Lillian Angel
2007-09-25 19:24     ` David Herron
2007-09-25 18:10 ` Thomas Fitzsimmons
2007-09-25 18:14   ` Steve McKay☄

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F96854.6080706@redhat.com \
    --to=fitzsim@redhat.com \
    --cc=David.Herron@sun.com \
    --cc=mauve-discuss@sources.redhat.com \
    --cc=smckay@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).