tcllib-devel — Discussion of development for tcllib

RE: [Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tc llib-devel] Release-planning ...)

[<dg...@ni...>]

Quoting Andreas Kupries <and...@Ac...>:
> The harness is copying tcltest 2.2.x into a location where it is accessible
> to all shells ... I should make sure that this is truly the case and that
> 8.2 does not get confused ...

Queston raised...

> > Is there supposed to be uniform support back to Tcl 8.2?
> 
> No. Each package can require everything from 8.2 to 8.5 according to its
> needs. However each package has to take care that its testsuite will not
> execute in an improper interpreter, like it has to make sure that it cannot
> be loaded into an improper interpreter.

.. and answered.

Just like all packages in tcllib ought to guard against loading
into a too-old version interp, so ought and does tcltest 2.  You
can place tcltest 2 where Tcl 8.2 can find it and do no harm;
tcltest 2 will refuse to be found by anything less than Tcl 8.3.

DGP

[Tcllib-devel] Re: SUGGESTION: Adding Tablelist to the tklib

[Csaba N. <csa...@t-...>]

Michael Schlenker schrieb:
> Hi Csaba,
> 
> as I (and many others) really like your marvelous tablelist widget. I
> suggest you submit it to the tklib, so it gets included in a wider range
> of distributions (notably ActiveTcl and the TclTkAquaBI distributions)
> and is more readily available.
> 
> What do you think about it?
> 
> Michael
> 
> 

Hi Michael,

I am glad to hear that you find the Tablelist package useful.  I think, 
it would make sense indeed to promote it into tklib, and I will consider 
this soon, after releasing the next version 4.1 (which will provide 
significantly extended tile support).

Many thanks for your suggestion!

Csaba

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

>
> Andreas Kupries wrote:
> >
>
> >
> > As promised. Attached is a gzipped tarball containing the
> detailed testsuite
> > logs for the shell/module combinations which had failures.
> >
>
> This has helped to identify the cause of the failures in the math
> module:
> Tcl8.4-specific operators and commands like eq and lset.
>
> But then the test suite seems to be too optimistic about Tcl 8.2 - maybe
> indeed the wrong tcltest version?

I still do not think so. I have committed some fixes already, like declaring
that bignum/bigfloat/linearalgebra require Tcl 8.4. This will take care of
the bulk of problems. 8.4isms in some tests for packages allowing Tcl 8.2
have been fixed too. Everything last night.



--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

[Tcllib-devel] SUGGESTION: Adding Tablelist to the tklib

[Michael S. <sc...@un...>]

Hi Csaba,

as I (and many others) really like your marvelous tablelist widget. I
suggest you submit it to the tklib, so it gets included in a wider range
of distributions (notably ActiveTcl and the TclTkAquaBI distributions)
and is more readily available.

What do you think about it?

Michael

Re: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Arjen M. <arj...@wl...>]

Andreas Kupries wrote:
> 

> 
> As promised. Attached is a gzipped tarball containing the detailed testsuite
> logs for the shell/module combinations which had failures.
> 

This has helped to identify the cause of the failures in the math
module:
Tcl8.4-specific operators and commands like eq and lset.

But then the test suite seems to be too optimistic about Tcl 8.2 - maybe
indeed the wrong tcltest version?

Regards,

Arjen

RE: [Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcl lib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> > Should we really be worrying much about Tcl 8.5 at this point?
> > Or should we
> > be more concerned when we get to a beta 8.5 release?
>
> It is a less critical version for us, yes.
>
> Note however that running the tests even against 8.5 is IMHO a
> good thing. For example the failures of the ASN  testsuite for
> 8.5 are actually exposing a bug in the number processing of 8.5,
> and not a bug in ASN itself. Which is a good thing to know early.

And I expect that most of the 8.5 failures point to differences in the error
messages generated by Tcl not accounted for by the testsuite. Yes, 8.5 is
generating slightly different error messages when it comes to wrong#args of
procedures.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: [Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcl lib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> Should we really be worrying much about Tcl 8.5 at this point?
> Or should we
> be more concerned when we get to a beta 8.5 release?

It is a less critical version for us, yes.

Note however that running the tests even against 8.5 is IMHO a good thing.
For example the failures of the ASN  testsuite for 8.5 are actually exposing
a bug in the number processing of 8.5, and not a bug in ASN itself. Which is
a good thing to know early.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

[Tcllib-devel] test message

[Jeff H. <je...@Ac...>]

Just seeing if SF is accepting my mails again ...

RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> > In the general case of tests failing on a particular platform,
> one cannot
> > expect all developers to discover the nature of the bug by
> running the test
> > harness, since they're probably not able to run it on that
> platform anyway.
> >
>
> I happen to have a version of Tcl 8.3.5 on one of the Linux systems.
> I did not run the test harness Andreas mentions, but instead the
> "standard"
> Swiss army knife script, part of Tcllib:


> modules/math/bigfloat.test
> syntax error in expression "[string index $str 0] eq {-}"
>     ("if" test expression)
>     while compiling
> "if {[string index $str 0] eq {-}} {

>
> Tests ended at Mon Sep 19 11:17:35 CEST 2005
> all.tcl:        Total   219     Passed  216     Skipped 0       Failed
> 3
> Sourced 3 Test Files.
> Files with failing tests: math/combinatorics.test math/math.test
>
>
> So a bunch of tests failing and a lot of test files being skipped!
>
> Could the non-availability of tcltest 2.1 be the cause of the
> extraordinary
> number of tests failing in the math module?

No. If you look into the setup.sh script you will that after the compilation
I am moving the tcltest 2.2.x found in Tcl 8.4 into a location where it will
be found by all shells. The only shell not using this version will be 8.5
because its tcltest is a bit newer. However it is also a Tcl Module,
something the other shells do not understand anyway.

So, what I see in the test above is that the bigfloat testing is not
protecting itself properly against usage with a Tclsh below 8.4. It makes
use of 8.4isms (eq), which is certainly ok if bigfloat is a package
requiring 8.4, but it should then also take care that its tests are not run
for a a 8.2/8.3 shell. IIRC we have other modules which do take care of
this. An example of such a module is 'treeql'.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

>
> This first mail was more intended as a wake-up call to the various
> maintainers that we should run tests and look at the results while working
> towards the next release (mid Oct).
>
> > From the presentation it is clear that there is some
> > problem (1 failed test) that I'll have to fix, but how am I
> supposed to do
> > that when I don't know what the problem is? Yeah right, I'm supposed to
> > download, build, and run the test harness, aren't I? That's not
> an optimal
> > solution, however.
>
> Only if you look at this as a one-shot deal.
>
> The reason that I make test harness public is to have a common foundation
> for running tests which all maintainers can use on all their
> systems. While
> I primarily create/update the harness when a new release of
> Tcllib is coming
> near this harness is something which should be used any time a change is
> made, before committing that change. In other words, the time needed to
> download and setup the harness is amortized over a long period of time.
>
> Note that we had changes in the past which passed the testsuite for the
> changed module, but caused other packages in Tcllib depending on
> it to fail.
>
>
> Having said all that I should say that I will post the full test
> results ...

>
> > Thus: Could you please publish also the test results (*which* tests are
> > failing, and *how*?)?
>
> Will do.

As promised. Attached is a gzipped tarball containing the detailed testsuite
logs for the shell/module combinations which had failures.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> Andreas Kupries <aku...@sh...> writes:
>
> >tclsh8.2 sasl       5     0      0       5
> >tclsh8.3 sasl       5     0      0       5
>
> Oops. Fixed the 8.4isms here.
> I have tcl8.2, 8.3, 8.4 and 8.5 on windows so at some point I can run
> all the tests. I'll grab your harness and see how it operates and

Thanks.

> maybe it will convert sak test output into a table as above?

The script 'run' generates a number of report files. The summary information
is taken by grepping the regular tcltest output for the line containing
'all.tcl'. This line is mangled a a bit and then written into a csv file
with module name and tclsh used for the run. The 'summary', 'failures', etc.
scripts the read the file containing this information for all shells and
modules ("Totals"), sorts it a bit (shell or module name), puts it into a
struct::matrix, inserts the separator lines and then formats the matrix. The
latter generates the nice table.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: [Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tc llib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> Arjen Markus wrote:
> > Could the non-availability of tcltest 2.1 be the cause of the
> > extraordinary number of tests failing in the math module?
>
> Tcltest 2.1 requires Tcl 8.3.  You can just copy tcltest into a Tcl 8.3
> library, and it should work.

The harness is copying tcltest 2.2.x into a location where it is accessible
to all shells ... I should make sure that this is truly the case and that
8.2 does not get confused ...


> Is there supposed to be uniform support back to Tcl 8.2?

No. Each package can require everything from 8.2 to 8.5 according to its
needs. However each package has to take care that its testsuite will not
execute in an improper interpreter, like it has to make sure that it cannot
be loaded into an improper interpreter.

>  Grepping for
> "package require Tcl" shows me that module requirements range from 8.0 to
> 8.5.
>
> But it would seem to me that, for a specific module, if it supports Tcl
8.2,
> then the test suite should be runnable under Tcl 8.2,

Correct. Because otherwise we cannot test the package under a shell it is
supposed to work for.

> which excludes tcltest 2.x syntax.

Could be true.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <and...@Ac...>]

> At 08.20 +0200 2005-09-17, Andreas Kupries wrote:
> >Here are some first results of running the testsuite on a plain linux
> >system against several shells (8.2 ... 8.5, 8.5 is actually CVS head,
> >8.4 is branch head).
> >
> >The test environment I used can be found at
> >
> >	http://www.oche.de/~akupries/soft/clt-arch/testenv.tar.gz
> >	http://www.oche.de/~akupries/soft/clt-arch/testenv.README.txt
> >	http://www.oche.de/~akupries/soft/clt-arch/testenv.md5sum
> >	http://www.oche.de/~akupries/soft/clt-arch/testenv.session
>
> Hmm... ehummmm... hmmmm... Aha!
>
> :-(
>
> One thing the README says only in a rather convoluted way is that this
> archive is of the test _harness_, not the actual tests themselves.

Right. I thought I was clear about that, but apparently not.


> Downloading them will give you four different versions[*] of Tcl to bui=
ld
> and run tests on, but in order to do so you also has to separately
download
> the tests.

Well, a Tcllib CVS snapshot, which is code and tests.

> Not the funniest thing to discover when travelling.
> This need to be clarified.

Will do. We had a similar [x] test harness for the last release and I
apparently forgot that we got new people on board since then which have n=
o
experience with this type of thing.

> [*] As .tar.gz's inside a .tar.gz, no less! Compressing twice doesn't
> improve compression ratio AFAIK, and since compression and and archival
are
> two different steps it will not be the case that the outer gzip can go
> "This file I'll compress, that file is already compressed, etc." since
from
> its point of view it is all one large file.

This is a historical artefact from the last test harness. I can change th=
at,
sure. I should note that I actually run a quick test with the inner tarba=
lls
unpackaed and the resulting outer tarball was larger. OTOH, we are talkin=
g
about 15 M total, another few K do not mean a thing.


[x] The scripts in the old harness were pure bourne shell. The new harnes=
s
uses shell scripting only for the basic setup scripts (setup, testarea). =
The
other scripts (run, summary, etc.) use the Tcl 8.4 tclsh in the harness. =
It
is simply a much better scripting language than shell, better quoting,
easier handling of paths, etc.

> >Note that I tried it currently only on Linux. I believe that it will
> >not fully work on Windows as is. Well, most scripts should, being
> >written in Tcl, but the setup script is shell and could get confused
> >under cygwin.
> >
> >
> >Ok, to the results I have gotten ...
>
> Indeed, the results. Where are the *actual* test results (as opposed to
> just a summary)?

This first mail was more intended as a wake-up call to the various
maintainers that we should run tests and look at the results while workin=
g
towards the next release (mid Oct).

> From the presentation it is clear that there is some
> problem (1 failed test) that I'll have to fix, but how am I supposed to=
 do
> that when I don't know what the problem is? Yeah right, I'm supposed to
> download, build, and run the test harness, aren't I? That's not an opti=
mal
> solution, however.

Only if you look at this as a one-shot deal.

The reason that I make test harness public is to have a common foundation
for running tests which all maintainers can use on all their systems. Whi=
le
I primarily create/update the harness when a new release of Tcllib is com=
ing
near this harness is something which should be used any time a change is
made, before committing that change. In other words, the time needed to
download and setup the harness is amortized over a long period of time.

Note that we had changes in the past which passed the testsuite for the
changed module, but caused other packages in Tcllib depending on it to fa=
il.


Having said all that I should say that I will post the full test results =
...

> In the general case of tests failing on a particular platform, one cann=
ot
> expect all developers to discover the nature of the bug by running the
test
> harness, since they're probably not able to run it on that platform
anyway.

Or are able to run, but the bug does not appear for that platform. See Bo=
b's
mail regarding 'units'.


> In my case I suspect that the bug is in the test rather than the packag=
e,
> i.e., that the test code malfunctions under the particular configuratio=
n

That is possible. Especially as the harness truly goes over all shells fr=
om
8.2 onward.

> that your test harness employs. I'm sure the error is mine (after all, =
it
> is the first tcltest I ever wrote), but it seems a severe overkill to h=
ave
> to use the test harness to find out what it is that fails.


> Thus: Could you please publish also the test results (*which* tests are
> failing, and *how*?)?

Will do.

> For results that are different on different
> platforms, it would of course be necessary also to make available the
> differences, to aid developers not having access to the problematic
> environments.
>
> Lars Hellstr=F6m



--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

[Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcl lib-devel] Release-planning ...)

[Techentin, R. W. <tec...@ma...>]

> Here are some first results of running the testsuite on a 
> plain linux system against several shells (8.2 ... 8.5, 8.5 
> is actually CVS head, 8.4 is branch head).

I tried to reproduce the test failure for the units package, but I could
not.

I checked out Tcl CVS head, and compiled it on HP-UX 11.0 and Red Hat
Enterprise Linux 3.2.3 (gcc 3.2.3).  I ran the test suite with 'tclsh85
units.test' but I did not get a test failure.

On HP-UX the tests run successfully.  I noted that a new test (not checked
into CVS yet) fails because Tcl 8.5 seems to have tcl_precision=17.  Is that
an official "feature" of Tcl 8.5?

On Linux, the test suite hangs (cpu bound) on test 2.7, without generating a
test failure.  While I haven't delved deeply enough to identify the specific
line of code that is hanging, I did find out that the Tcl test suite also
hangs in 'binary.test' for this configuration.

Should we really be worrying much about Tcl 8.5 at this point?  Or should we
be more concerned when we get to a beta 8.5 release?

Bob
-- 
Bob Techentin                        tec...@ma... 
Mayo Foundation                                 (507) 538-5495 
200 First St. SW                            FAX (507) 284-9171
Rochester MN, 55901  USA            http://www.mayo.edu/sppdg/ 

[Tcllib-devel] RE: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tc llib-devel] Release-planning ...)

[Techentin, R. W. <tec...@ma...>]

Arjen Markus wrote:
> Could the non-availability of tcltest 2.1 be the cause of the 
> extraordinary number of tests failing in the math module?

Tcltest 2.1 requires Tcl 8.3.  You can just copy tcltest into a Tcl 8.3
library, and it should work.

Is there supposed to be uniform support back to Tcl 8.2?  Grepping for
"package require Tcl" shows me that module requirements range from 8.0 to
8.5.

But it would seem to me that, for a specific module, if it supports Tcl 8.2,
then the test suite should be runnable under Tcl 8.2, which excludes tcltest
2.x syntax.

Bob
-- 
Bob Techentin                        tec...@ma... 
Mayo Foundation                                 (507) 538-5495 
200 First St. SW                            FAX (507) 284-9171
Rochester MN, 55901  USA            http://www.mayo.edu/sppdg/ 

Re: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Pat T. <pa...@zs...>]

Andreas Kupries <aku...@sh...> writes:

>tclsh8.2 sasl       5     0      0       5
>tclsh8.3 sasl       5     0      0       5

Oops. Fixed the 8.4isms here.
I have tcl8.2, 8.3, 8.4 and 8.5 on windows so at some point I can run
all the tests. I'll grab your harness and see how it operates and
maybe it will convert sak test output into a table as above?
-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Arjen M. <arj...@wl...>]

Lars Hellstr=F6m wrote:
>=20
> At 08.20 +0200 2005-09-17, Andreas Kupries wrote:
> >Here are some first results of running the testsuite on a plain linux
> >system against several shells (8.2 ... 8.5, 8.5 is actually CVS head,
> >8.4 is branch head).
> >
> >The test environment I used can be found at
> >
> >       http://www.oche.de/~akupries/soft/clt-arch/testenv.tar.gz
> >       http://www.oche.de/~akupries/soft/clt-arch/testenv.README.txt
> >       http://www.oche.de/~akupries/soft/clt-arch/testenv.md5sum
> >       http://www.oche.de/~akupries/soft/clt-arch/testenv.session
>=20
> Hmm... ehummmm... hmmmm... Aha!
>=20
> :-(
>=20
> One thing the README says only in a rather convoluted way is that this
> archive is of the test _harness_, not the actual tests themselves.
> Downloading them will give you four different versions[*] of Tcl to bui=
ld
> and run tests on, but in order to do so you also has to separately down=
load
> the tests. Not the funniest thing to discover when travelling. This nee=
d to
> be clarified.
>=20

>=20
> Indeed, the results. Where are the *actual* test results (as opposed to
> just a summary)? From the presentation it is clear that there is some
> problem (1 failed test) that I'll have to fix, but how am I supposed to=
 do
> that when I don't know what the problem is? Yeah right, I'm supposed to
> download, build, and run the test harness, aren't I? That's not an opti=
mal
> solution, however.
>=20
> In the general case of tests failing on a particular platform, one cann=
ot
> expect all developers to discover the nature of the bug by running the =
test
> harness, since they're probably not able to run it on that platform any=
way.
>=20

I happen to have a version of Tcl 8.3.5 on one of the Linux systems.
I did not run the test harness Andreas mentions, but instead the
"standard"
Swiss army knife script, part of Tcllib:

/usr/bin/tclsh sak.tcl test math

This shows:=20

Shell is "/usr/bin/tclsh"
tcllib tests
Test platform: "Linux-2.4.21-27.0.2.ELsmp-i686" using Tcl 8.3.5
Tests running in working dir:  /p/delft3d/users/markus/tcllib/tcllib
Only sourcing test files that match:  *.test
Tests began at Mon Sep 19 11:17:31 CEST 2005
Module: math
modules/math/bessel.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2
modules/math/bigfloat.test
syntax error in expression "[string index $str 0] eq {-}"
    ("if" test expression)
    while compiling
"if {[string index $str 0] eq {-}} {
        set str [string range $str 1 end]
        set sign 1
    }"
    (compiling body of proc "::math::bignum::fromstr", line 5)
    invoked from within
"::math::bignum::fromstr 0"
    (in namespace eval "::math::bigfloat" script line 10)
    invoked from within
"namespace eval ::math::bigfloat {
    # cached constants
....

modules/math/optimize.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2
modules/math/polynomials.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2
modules/math/qcomplex.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2
modules/math/special.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2
modules/math/statistics.test
Aborting tests for math::statistics.
Requiring tcltest 2.1, have 1.0.2


Tests ended at Mon Sep 19 11:17:35 CEST 2005
all.tcl:        Total   219     Passed  216     Skipped 0       Failed=20
3
Sourced 3 Test Files.
Files with failing tests: math/combinatorics.test math/math.test


So a bunch of tests failing and a lot of test files being skipped!

Could the non-availability of tcltest 2.1 be the cause of the
extraordinary=20
number of tests failing in the math module?

Regards,

Arjen

Re: Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Lars <lar...@re...>]

At 08.20 +0200 2005-09-17, Andreas Kupries wrote:
>Here are some first results of running the testsuite on a plain linux
>system against several shells (8.2 ... 8.5, 8.5 is actually CVS head,
>8.4 is branch head).
>
>The test environment I used can be found at
>
>	http://www.oche.de/~akupries/soft/clt-arch/testenv.tar.gz
>	http://www.oche.de/~akupries/soft/clt-arch/testenv.README.txt
>	http://www.oche.de/~akupries/soft/clt-arch/testenv.md5sum
>	http://www.oche.de/~akupries/soft/clt-arch/testenv.session

Hmm... ehummmm... hmmmm... Aha!

:-(

One thing the README says only in a rather convoluted way is that this
archive is of the test _harness_, not the actual tests themselves.
Downloading them will give you four different versions[*] of Tcl to build
and run tests on, but in order to do so you also has to separately download
the tests. Not the funniest thing to discover when travelling. This need to
be clarified.

[*] As .tar.gz's inside a .tar.gz, no less! Compressing twice doesn't
improve compression ratio AFAIK, and since compression and and archival are
two different steps it will not be the case that the outer gzip can go
"This file I'll compress, that file is already compressed, etc." since from
its point of view it is all one large file.

>Note that I tried it currently only on Linux. I believe that it will
>not fully work on Windows as is. Well, most scripts should, being
>written in Tcl, but the setup script is shell and could get confused
>under cygwin.
>
>
>Ok, to the results I have gotten ...

Indeed, the results. Where are the *actual* test results (as opposed to
just a summary)? From the presentation it is clear that there is some
problem (1 failed test) that I'll have to fix, but how am I supposed to do
that when I don't know what the problem is? Yeah right, I'm supposed to
download, build, and run the test harness, aren't I? That's not an optimal
solution, however.

In the general case of tests failing on a particular platform, one cannot
expect all developers to discover the nature of the bug by running the test
harness, since they're probably not able to run it on that platform anyway.

In my case I suspect that the bug is in the test rather than the package,
i.e., that the test code malfunctions under the particular configuration
that your test harness employs. I'm sure the error is mine (after all, it
is the first tcltest I ever wrote), but it seems a severe overkill to have
to use the test harness to find out what it is that fails.

Thus: Could you please publish also the test results (*which* tests are
failing, and *how*?)? For results that are different on different
platforms, it would of course be necessary also to make available the
differences, to aid developers not having access to the problematic
environments.

Lars Hellstr=F6m

Re: [Tcllib-devel] FW: [Tcllib-bugs] ::comm::comm send -command syntax??

[Don M. <don...@gm...>]

WOW, thanks for all the replies, and I am _sorry_ for the mispost. :(

I was able to figure out the problem...I was reading from an
un-official website that had incorrect documentation...I can't find it
again by googling...but the site said the syntax was:

comm send -callback callback

instead of=20

comm send -command callback

so I ended up defining the callback HOOK before fixing my syntax,
which did what I wanted (though this is of course horribly wrong) and
subsequently the command "callback" could not be found.....

MY APOLOGIES.

Would writing a short tutorial snippet on callbacks make up for this,
or would you be afraid to post it? ;)

On 9/17/05, Will Duquette <wi...@wj...> wrote:
> David,
>=20
> I think the current behavior (letting the error bubble up to
> bgerror) is the correct one.  Suppose I supply a command to a
> library module, and there's an error in my command's implementation.
> For debugging, I want access to the errorInfo.  If the library
> module catches the error, I lose that errorInfo--unless the library
> module stashes it somewhere, which isn't standard behavior.
>=20
> In an application that can log errors thoroughly it's reasonable
> to catch such errors and write them to the log; but in
> general-purpose library code, letting the error bubble-up to bgerror
> is the easiest way to get the debugging info to the developer.
> At most, the library might want to catch the error and rethrow it.
>=20
> Of course, the easiest way to log errors thoroughly in application
> code is to redefine bgerror to do that; I've had great success
> with that in the past.
>=20
> Will
>=20
> On Sep 17, 2005, at 1:11 PM, David N. Welton wrote:
>=20
> > Andreas Kupries wrote:
> >
> >
> >>>> ::comm::comm send -command callback $remoteID $remoteCMDs
> >>>>
> >
> >
> >> If not, then "comm" is quite rightly complaining about its
> >> non-existence, as you told it to call a command with that name when
> >> the result of the send comes back. It would also be right to use
> >> 'bgerror' as the result comes back asynchronously.
> >>
> >
> > This may not be all that related, but I'm not a big fan of library
> > code
> > triggering bgerrors.  One way to make the above not do that is to wrap
> > the -command in a catch, then provide a hook to deal with errors.  The
> > standard hook might be somewhat similar to bgerror in that it brings
> > everything to a screeching halt.  OTOH, perhaps in this case, it's
> > best
> > if the user does this themselves so as to avoid bloating the library
> > code...?
> >
> > Just a thought,
> > --
> > David N. Welton
> > - http://www.dedasys.com/davidw/
> >
> > Apache, Linux, Tcl Consulting
> > - http://www.dedasys.com/
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server.
> > Download it for free - -and be entered to win a 42" plasma tv or
> > your very
> > own Sony(tm)PSP.  Click here to play: http://sourceforge.net/
> > geronimo.php
> > _______________________________________________
> > Tcllib-devel mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcllib-devel
> >
>=20
> -------------------------------------------------------------
>        will -at- wjduquette.com | Catch our weblog,
> http://foothills.wjduquette.com | The View from the Foothills
>=20
>=20
>

Re: [Tcllib-devel] FW: [Tcllib-bugs] ::comm::comm send -command syntax??

[Will D. <wi...@wj...>]

David,

I think the current behavior (letting the error bubble up to
bgerror) is the correct one.  Suppose I supply a command to a
library module, and there's an error in my command's implementation.
For debugging, I want access to the errorInfo.  If the library
module catches the error, I lose that errorInfo--unless the library
module stashes it somewhere, which isn't standard behavior.

In an application that can log errors thoroughly it's reasonable
to catch such errors and write them to the log; but in
general-purpose library code, letting the error bubble-up to bgerror
is the easiest way to get the debugging info to the developer.
At most, the library might want to catch the error and rethrow it.

Of course, the easiest way to log errors thoroughly in application
code is to redefine bgerror to do that; I've had great success
with that in the past.

Will

On Sep 17, 2005, at 1:11 PM, David N. Welton wrote:

> Andreas Kupries wrote:
>
>
>>>> ::comm::comm send -command callback $remoteID $remoteCMDs
>>>>
>
>
>> If not, then "comm" is quite rightly complaining about its
>> non-existence, as you told it to call a command with that name when
>> the result of the send comes back. It would also be right to use
>> 'bgerror' as the result comes back asynchronously.
>>
>
> This may not be all that related, but I'm not a big fan of library  
> code
> triggering bgerrors.  One way to make the above not do that is to wrap
> the -command in a catch, then provide a hook to deal with errors.  The
> standard hook might be somewhat similar to bgerror in that it brings
> everything to a screeching halt.  OTOH, perhaps in this case, it's  
> best
> if the user does this themselves so as to avoid bloating the library
> code...?
>
> Just a thought,
> -- 
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Apache, Linux, Tcl Consulting
> - http://www.dedasys.com/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or  
> your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/ 
> geronimo.php
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
>

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

Re: [Tcllib-devel] FW: [Tcllib-bugs] ::comm::comm send -command syntax??

[David N. W. <da...@de...>]

Andreas Kupries wrote:

>>>::comm::comm send -command callback $remoteID $remoteCMDs

> If not, then "comm" is quite rightly complaining about its
> non-existence, as you told it to call a command with that name when
> the result of the send comes back. It would also be right to use
> 'bgerror' as the result comes back asynchronously.

This may not be all that related, but I'm not a big fan of library code
triggering bgerrors.  One way to make the above not do that is to wrap
the -command in a catch, then provide a hook to deal with errors.  The
standard hook might be somewhat similar to bgerror in that it brings
everything to a screeching halt.  OTOH, perhaps in this case, it's best
if the user does this themselves so as to avoid bloating the library
code...?

Just a thought,
-- 
David N. Welton
- http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
- http://www.dedasys.com/

Re: [Tcllib-devel] FW: [Tcllib-bugs] ::comm::comm send -command syntax??

[Andreas K. <aku...@sh...>]

Hi Don.

> > -----Original Message-----
> > From: tcl...@li...
> > [mailto:tcl...@li...]On Behalf Of 
> > Sent: Thursday, September 15, 2005 3:28 PM
> > To: tcl...@li...
> > Subject: [Tcllib-bugs] ::comm::comm send -command syntax??

Administrative side note:

	For the future please note that the tcllib-bugs mailing list
	is *not* for the reporting of bugs, but for the dissemination
	of the email notifications generated by SourceForge when a bug
	is entered into the Tcllib Bug Tracker.

	In the future please go either directly to

		http://sourceforge.net/tracker/?func=add&group_id=12883&atid=112883

	for reporting (possible) bugs, or go to 

		http://tcllib.sourceforge.net/

	and then follow the links (-> Bug Database - > Submit New).

On to your problem ...

> > I call
> > 
> > ::comm::comm send -command callback $remoteID $remoteCMDs
> > 
> > and everything works both on the remote side and in the callback when
> > the result returns from the remote, but when the callback exits,
> > bgerror gets called with the message:
> > 
> > invalid command name "callback"
> > 
> > I have read the docs several times and googled this, but I don't see
> > an example of good syntax anywhere.  What is the solution?

On the web you can find documentation at 

	http://tcllib.sourceforge.net/doc/comm.html
and	http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcllib/comm/comm.html
More specific
	http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcllib/comm/comm.html#1

Nevertheless, given the referenced documentation I believe that the
syntax you have used is correct.

So this could be a bug, except that you have not told us if a command
named "callback" does exist in your environment.

If not, then "comm" is quite rightly complaining about its
non-existence, as you told it to call a command with that name when
the result of the send comes back. It would also be right to use
'bgerror' as the result comes back asynchronously.



-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Some testsuite results - linux-ix86 - Tcl 8.2/3/4/5 (Re: [Tcllib-devel] Release-planning ...)

[Andreas K. <aku...@sh...>]

Here are some first results of running the testsuite on a plain linux
system against several shells (8.2 ... 8.5, 8.5 is actually CVS head,
8.4 is branch head).

The test environment I used can be found at

	http://www.oche.de/~akupries/soft/clt-arch/testenv.tar.gz
	http://www.oche.de/~akupries/soft/clt-arch/testenv.README.txt
	http://www.oche.de/~akupries/soft/clt-arch/testenv.md5sum
	http://www.oche.de/~akupries/soft/clt-arch/testenv.session

Note that I tried it currently only on Linux. I believe that it will
not fully work on Windows as is. Well, most scripts should, being
written in Tcl, but the setup script is shell and could get confused
under cygwin.


Ok, to the results I have gotten ...

Sorted by shell we find that 8.5 currently has the most problems,
counted by number of modules. We have however a spike for math under
8.3.

__________________________________________________
Setting up the Test Environment (/home/aku/Projects/Tcllib/testenv) ...
System Architecture : linux-ix86

Shell    Module     Total Passed Skipped Failed
-----    ------     ----- ------ ------- ------
tclsh8.2 fileutil   106   85     20      1
tclsh8.2 math       219   216    0       3
tclsh8.2 sasl       5     0      0       5
tclsh8.2 struct     1653  1645   5       3
-----    ------     ----- ------ ------- ------
tclsh8.3 fileutil   106   102    3       1
tclsh8.3 math       596   502    0       94
tclsh8.3 pop3d      152   148    0       4
tclsh8.3 sasl       5     0      0       5
tclsh8.3 struct     1917  1909   6       2
-----    ------     ----- ------ ------- ------
tclsh8.4 docstrip   7     6      0       1
tclsh8.4 fileutil   106   103    2       1
tclsh8.4 fumagic    42    36     4       2
-----    ------     ----- ------ ------- ------
tclsh8.5 asn        216   204    0       12
tclsh8.5 control    21    20     0       1
tclsh8.5 counter    16    13     1       2
tclsh8.5 docstrip   7     6      0       1
tclsh8.5 exif       1     0      0       1
tclsh8.5 fileutil   106   103    2       1
tclsh8.5 fumagic    42    36     4       2
tclsh8.5 grammar_fa 2410  2394   0       16
tclsh8.5 math       1236  1235   0       1
tclsh8.5 profiler   20    14     5       1
tclsh8.5 struct     1917  1909   6       2
tclsh8.5 tie        191   187    2       2
tclsh8.5 units      97    96     0       1
-----    ------     ----- ------ ------- ------
Shell    Module     Total Passed Skipped Failed


Taking the same results and sorting by module we find about three
modules which seem to have problems across all versions of Tcl we have
used, and a number of modules with problems for one or two shells.


__________________________________________________
Setting up the Test Environment (/home/aku/Projects/Tcllib/testenv) ...
System Architecture : linux-ix86

Shell    Module     Total Passed Skipped Failed
-----    ------     ----- ------ ------- ------
tclsh8.5 asn        216   204    0       12
-----    ------     ----- ------ ------- ------
tclsh8.5 control    21    20     0       1
-----    ------     ----- ------ ------- ------
tclsh8.5 counter    16    13     1       2
-----    ------     ----- ------ ------- ------
tclsh8.4 docstrip   7     6      0       1
tclsh8.5 docstrip   7     6      0       1
-----    ------     ----- ------ ------- ------
tclsh8.5 exif       1     0      0       1
-----    ------     ----- ------ ------- ------
tclsh8.2 fileutil   106   85     20      1
tclsh8.3 fileutil   106   102    3       1
tclsh8.4 fileutil   106   103    2       1
tclsh8.5 fileutil   106   103    2       1
-----    ------     ----- ------ ------- ------
tclsh8.4 fumagic    42    36     4       2
tclsh8.5 fumagic    42    36     4       2
-----    ------     ----- ------ ------- ------
tclsh8.5 grammar_fa 2410  2394   0       16
-----    ------     ----- ------ ------- ------
tclsh8.2 math       219   216    0       3
tclsh8.3 math       596   502    0       94
tclsh8.5 math       1236  1235   0       1
-----    ------     ----- ------ ------- ------
tclsh8.3 pop3d      152   148    0       4
-----    ------     ----- ------ ------- ------
tclsh8.5 profiler   20    14     5       1
-----    ------     ----- ------ ------- ------
tclsh8.2 sasl       5     0      0       5
tclsh8.3 sasl       5     0      0       5
-----    ------     ----- ------ ------- ------
tclsh8.2 struct     1653  1645   5       3
tclsh8.3 struct     1917  1909   6       2
tclsh8.5 struct     1917  1909   6       2
-----    ------     ----- ------ ------- ------
tclsh8.5 tie        191   187    2       2
-----    ------     ----- ------ ------- ------
tclsh8.5 units      97    96     0       1
-----    ------     ----- ------ ------- ------
Shell    Module     Total Passed Skipped Failed


The relevant maintainers are listed below, with me filling the holes
as well ...


Module     Maintainer	Module     Maintainer
------     ----------	------     ----------
asn        schlenk	counter    aku
control    dgp, aku	exif       aku
counter    aku		fileutil   aku
docstrip   lars		fumagic    aku
exif       aku		grammar_fa aku
fileutil   aku		pop3d      aku
fumagic    aku		profiler   aku
grammar_fa aku		struct     aku
math       arjen	tie        aku
pop3d      aku		------     ----------
profiler   aku		math       arjen
sasl       pat		------     ----------
struct     aku		units      bob
tie        aku		------     ----------
units      bob		control    dgp, aku
------     ----------	------     ----------
Module     Maintainer	docstrip   lars
			------     ----------
			sasl       pat
			------     ----------
			asn        schlenk
			------     ----------
			Module     Maintainer

--
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] FW: [Tcllib-bugs] ::comm::comm send -command syntax??

[Andreas K. <and...@Ac...>]

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Don
> Morrison <don...@gm...>
> Sent: Thursday, September 15, 2005 3:28 PM
> To: tcl...@li...
> Subject: [Tcllib-bugs] ::comm::comm send -command syntax??
> 
> 
> I call
> 
> ::comm::comm send -command callback $remoteID $remoteCMDs
> 
> and everything works both on the remote side and in the callback when
> the result returns from the remote, but when the callback exits,
> bgerror gets called with the message:
> 
> invalid command name "callback"
> 
> I have read the docs several times and googled this, but I don't see
> an example of good syntax anywhere.  What is the solution?
> 
> Don

-- 
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

RE: [Tcllib-devel] ActiveTcl-dev list available

[Jeff H. <je...@Ac...>]

> I have created an ActiveTcl-dev list for those interested in 
> package and release management discussion about the ActiveTcl 
> distribution.
> 
> The list is intended for authors of packages that are 
> included in the ActiveTcl distribution.  It would discuss 
> things like upcoming release timing (in case you want to 
> finalize package changes), notable distribution changes (like 
> threaded vs. non-threaded builds) and related issues.  If you 
> are an author of a package included in ActiveTcl, I would 
> encourage signing up for the list (core maintainers may also 
> be interested).

And the important part, here it is for sign-up:
	http://listserv.activestate.com/mailman/listinfo/activetcl-dev

Jeff