#167 allow skipping of constraint init code

Kenneth Cox

Some of the tcltest constraint initialization code is
nontrivial. A caller may want to avoid running the
initialization code. In my case, running the
constraint initialization code hangs my application.

This patch uses [info exists] to test a constraint
first, and runs the code to set the constraint if it
doesn't already exist.

This patch is incomplete; it only handles the (stdio)
constraint. If you agree with this style of test-
first constraint setting, I can patch the other
constraints and submit them.

My example: I have a client app which opens an
exclusive connection to a server. When this app tries
to spawn itself (while setting the stdio constraint),
it deadlocks waiting for the exclusive connection to
the server. Whether this is good app design is
outside the scope of this patch!

Most of this patch is whitespace-only change.


  • Kenneth Cox

    Kenneth Cox - 2002-02-02
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-03-23
    • assigned_to: melissachawla --> dgp
  • Don Porter

    Don Porter - 2002-03-25
    • priority: 5 --> 3
  • Don Porter

    Don Porter - 2002-03-25

    Logged In: YES

    I haven't examine this patch, but I agree with the

    I think the tcltest package still suffers from its legacy
    as something that grew by accretion, and is something
    mostly used exclusively in a single appliction. The
    package/application boundary is not clean.

    It would be better for the package to make functionality
    available, and leave it to applications to actually exercise
    it. In the case, the tcltest package should provide a means
    for defining constraints, and it could even offer code that
    queries the system and sets up some standard constraints.

    But that code should only run in response to a command
    executed by an application. It should not be part of
    package initialization.

    Tricky bit will be making this transition while supporting
    compatibility -- perhaps some form of "auto-loading" of
    the currently built-in constraints.

    Not gonna get to this soon, but did want to comment.

  • Don Porter

    Don Porter - 2002-05-31
    • priority: 3 --> 7
  • Don Porter

    Don Porter - 2002-06-06

    Logged In: YES

    Here's a patch that converts tcltest to do
    "lazy" initialization of test constraints.
    The value of a built-in constraint is not
    determined unless/until a [test] command
    that depends on that constraint is evaluated.
    This should address the problem.

    The patch also deprecates the [initConstraintsHook]
    because contraints are no longer initialized at
    package load time by default. For compatibility, if
    an [initConstraintsHook] has been defined, tcltest
    reverts to the old behavior of initialization of
    constraints at package load time. This should be
    discouraged. The hook is completely unnecessary;
    any tcltest user that wants to add a constraint can
    do so directly by calling the [testConstraint] command.
    No need for a hook at all.

    This patch also cleans up the mess that was the
    [limitConstraints] command. Some comments/documentation
    indicated this command took a boolean value; some that
    it took a list value. The existing code/tests did not
    appear to do anything sensible. I replaced the whole
    things with a consistent command that accepts a boolean
    value indicating whether or not to limit running of [test]s
    to those with constraints specified by the "-constraints"
    command line option.

    committing to tcltest 2.1 (Tcl 8.4a5)

  • Don Porter

    Don Porter - 2002-06-06
  • Don Porter

    Don Porter - 2002-06-06
    • status: open --> closed-accepted

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks