rebuilding expect with different timer
James Harper XX (AS/EAB)
I am testing a product that basically is a simulator of
hardware/software and the same expect tests are done on both real and
simulated. The problem is that a real time second can take minutes on
the simulated product so I wish to rebuild expect to use the virtual
time from the simulator which will have an API to return the time but
not sure in which format yet. Therefore we can use the same tests
without changes to run on both versions of the product.
Has anybody rebuilt expect to do this and if so any help on where to
start would be useful.
The two areas that will require the different timing information are the
sleep command and handling timeouts.
Thanks in advance
James
Donal K. Fellows
> Has anybody rebuilt expect to do this and if so any help on where to
> start would be useful.
> The two areas that will require the different timing information are the
> sleep command and handling timeouts.
There is a time virtualization API in Tcl 8.5's C interface. I don't
know how Expect handles time, but if it does it on top of Tcl's time
handling core, it should pick up the virtual times if you set them up.
But I'm not an expert on actually using the virtual time stuff, so I
can't offer detailed help.
Donal.
Jeff Hobbs
Indeed, this is exactly why those APIs were introduced - to allow for
Tcl and extensions built on Tcl that use Tcl_Time-based APIs to get a
skewed sense of time. The time virtualization API should be fully
sufficient for simulating both slower and faster time.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
James Harper XX (AS/EAB)
I have had a look at the expect source code and in particular expect.c,
I believe the timeout handling code use the system function
time(&time_t). However the sleep procedure uses Tcl_CreateTimerHandler,
is this a procedure that can use the API's you talk about? We have
Tcl8.4 installed and it might not be possible to upgrade to 8.5 for a while.
/James
Donal K. Fellows
There's no plan to backport the virtualization stuff to 8.4, and it
sounds like Expect will want to be adjusted to use Tcl_GetTime()
instead of time() in calls like that above so that it will
transparently pick up any virtualization installed. (The Tcl_GetTime()
function is new in 8.4, though it is really just an exposure of a
pre-existing internal function.)
Donal.
Jeff Hobbs
Which expect source base are you looking at? In conjunction with this
patch to Tcl, Expect and TclX received patches to ensure that they use
Tcl_Time-based handling everywhere.
James Harper XX (AS/EAB)
Our organisation uses Tcl 8.4 and expect 5.43 and as you can see from my
email address we are quite a big organisation and changing which
versions we use from the two mentioned will probably take a lot more
time than implementing some code to use simulated times ;)
Donal K. Fellows
Well, that's just not going to work.
But, knowing how large organizations operate, may I suggest that you put
together a package containing a recent 8.5 alpha and suitably new Expect
and use that with your application instead of the centrally rolled-out
version? As long as you don't spread stuff through all the standard
install locations, that'll work (and most people who use the app will
have trouble caring less about the fact that it's not using the central
installation). In this respect you'll be like many other apps that
require specific versions of libraries; I'd almost put money on your
central admins being *very* used to this sort of restriction in general
so you adding an extra requirement (and Tcl's unusually clean about
keeping to its own space) won't be a shock.
FWIW, I never use centrally installed tclsh instances. They're always
way behind where I want them to be. :-\
Donal.