tcllib-devel — Discussion of development for tcllib

Re: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Relea se

[Aamer A. <aa...@gm...>]

Robert,

inline:


On 10/7/05, Techentin, Robert W. <tec...@ma...> wrote:
>
> > Please give them a whirl.
>
> =3D=3D=3D=3D createLogProc-1 create a proc and test it FAILED
> =3D=3D=3D=3D Contents of test case:
>
> set a [logger::utils::createLogProc -category catTest -priority
> critical -procName ::bobo -conversionPattern {\[%d\] \[%c\] \[%M\] \[%p\]
> %m}]
> eval $a
> ::bobo test
>
> ---- Output was:
> [G/10/07 07:40:13] [catTest] [namespace] [critical] test
>
> ---- Output should have been (regexp matching):
> \[[\d:\/ ]+\] \[catTest\] \[namespace\] \[critical\] test
> =3D=3D=3D=3D createLogProc-1 FAILED
>

This seems to be stemming from this line:

{[*clock* *format* [*clock* seconds] -*format* {%G/%m/%d %H:%M:%S}]}

For some reason %G is not being translated into four digit year. I check th=
e
8.4 manaul and it does seem to be there... if this is being caused by
running under 8.3, perhaps %Y instead of %G would be better.


--
Aamer Akhter / aa...@gm...

RE: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Relea se

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

> 11:46]	patthoyts	I see HPUX blowfish and aes 
> problems mentioned by Bob Techentin on tcllib-devel
> [11:49]	patthoyts	Hmm. I should try a sparc 64bit build.
> [11:51]	aku	Yep. Note that he used Tcl 8.3

No No No.  I got the aes/blowfish errors on HP-UX 11.0 with ActiveTcl 8.4.6.

(the Tcl 8.3 business was on Red Hat on X86_64)

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: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Release

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

And a second set of regenerated pre-release archives. Incorporates Pat's
smtp/sasl changes as well, and a bugfix for struct::tree/critcl. The CVS for
the module has been retagged as well. The new files are

  	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.tar.gz
  	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.tar.bz
  	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.zip
  	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.kit

The CVS is still frozen.

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

RE: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Release

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

>
> Thanks for the analysis, Andreas.
>
> > > I downloaded the preview, unpacked, configured, and ran "make
> > > test."  Everything passes on Fedora Core 3, ActiveTcl 8.4.6.  But
> > > I got failures doing the same thing on HP-UX, WinXP/MingW/Msys,
> > > and Red Hat Enterprise Linux (RHEL) 3.
> >
> > I wish that you had done that when I posted the 'testenv', it
> > is for easy testing of a Tcllib checkout using Tcl 8.2 to
> > 8.5. Ok, water under bridge ...
>
> My bad.  I was really concerned with the bugs that appeared with the units
> package and Tcl 8.5.  I spent a lot of time trying to build Tcl HEAD, and
> not much focusing on Tcllib.  :-(

Can happen.

> > > ActiveTcl 8.4.6 was
> > > installed everywhere.
> >
> > What is the situation if you are using ActiveTcl 8.4.11 ?
>
> I don't know.  Its getting about time to upgrade.  But the
> Sysadmins have to be fed. :-)
>
>
> > How about filing bugs against the modules and packages which
> > are in your opinion to chatty in the test output ?
>
> OK.  I will do so.  I see unnecessary log messages from calendar, comm,
> counter, docstrip, grammar_fa, htmlparse, log, math, ncgi, png,
> pop3, pop3d,
> struct, and tie.

Ok. And I see the notifications coming.

> > Do we have commands in tcltest for our own log
> > output, which can then be controlled through its -verbose option ?
>
> No, not really.  Tcltest's -verbose option controls when the test suite
> prints messages.  The default is to print the body when a test fails, and
> error information if there is an uncaught error.  You could also ask for a
> message when tests are passed or skipped.  But there isn't an associated
> general logging facility.

Yes, I had hoped that we had tcltest::log commands or some such we could use
instead of 'puts'.


> > > Modules with "Error: No test files remain ...
> >
> > This is the message generated by tcltest when there are
> > either no .test files or they are empty, i.e. when there is
> > no testsuite.
> >
> > > So I'm not testing these on unix, but they appeared to run tests
> > > on WinXP.
> >
> > How did you come to the conclusion that they have tests on WinXP ?
>
> I didn't get "Error: No test files remain..."  My misinterpretation.

Ah. Likely Windows redirected them (the std channels) into /dev/null or
something like that.


> > > Many aes and blowfish tests failed with "integer value too large
> > > to represent" on HP-UX and "integer value too large to represent
> > > as non-long integer" on RHEL with tclsh8.3.  For example, I
> > > include just one test, but there were 27 others.
> >
> > This could be a problem with Tcl 8.3. Do the same error occur
> > with Tcl 8.4 ? Is your machine 64 bit ?
>
> These fail on HP-UX with ActiveTcl 8.4.6, and also on RHEL with its stock
> tclsh8.3.  So it doesn't work on HP-UX.  Might be something to do
> with wide
> ints.  Perhaps we need to ugrade. :-)

Taked with Pat/Dgp on the chat about this:

11:46]	patthoyts	I see HPUX blowfish and aes problems mentioned by Bob
Techentin on tcllib-devel
[11:49]	patthoyts	Hmm. I should try a sparc 64bit build.
[11:51]	aku	Yep. Note that he used Tcl 8.3
[11:52]	aku	I know that this is spotty on a 64bit system
[11:52]	aku	I believe Tcl 8.3 was only halfway there with regard to wide
integers.
[11:52]	dgp	wide integers arrived in 8.4
[11:53]	patthoyts	My 64bit sparc build handles the aes and blowfish tests
ok.
[11:53]	dgp	the 32- and 64-bit inconsistencies were probably different in
8.3 days though.
[11:53]	aku	dgp - something like that
[11:53]	dgp	Reasonable position to me:  anyone using a 64-bit platform needs
at least Tcl 8.4.
[11:54]	dgp	Tcl just wasn't tested well enough on such systems before that.
[11:54]	aku	That is why I usually ignore such failures for 8.3. 8.4 is
definitely better in that regard. And 8.5 should be really good



Notes: I accepted Pat's sasl/mime changes after chatting with him. I will
now do a bit of bug-hunting in struct::tree again. Independent of that I
will regenerate the archives and put a -2 pre-release out. After I have
concluded any bug-hunting.

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

RE: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Relea se

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

Thanks for the analysis, Andreas.

> > I downloaded the preview, unpacked, configured, and ran "make
> > test."  Everything passes on Fedora Core 3, ActiveTcl 8.4.6.  But
> > I got failures doing the same thing on HP-UX, WinXP/MingW/Msys,
> > and Red Hat Enterprise Linux (RHEL) 3.
> 
> I wish that you had done that when I posted the 'testenv', it 
> is for easy testing of a Tcllib checkout using Tcl 8.2 to 
> 8.5. Ok, water under bridge ...

My bad.  I was really concerned with the bugs that appeared with the units
package and Tcl 8.5.  I spent a lot of time trying to build Tcl HEAD, and
not much focusing on Tcllib.  :-(


> > ActiveTcl 8.4.6 was
> > installed everywhere.
> 
> What is the situation if you are using ActiveTcl 8.4.11 ?

I don't know.  Its getting about time to upgrade.  But the Sysadmins have to
be fed. :-)


> How about filing bugs against the modules and packages which 
> are in your opinion to chatty in the test output ?

OK.  I will do so.  I see unnecessary log messages from calendar, comm,
counter, docstrip, grammar_fa, htmlparse, log, math, ncgi, png, pop3, pop3d,
struct, and tie.

> Do we have commands in tcltest for our own log 
> output, which can then be controlled through its -verbose option ?

No, not really.  Tcltest's -verbose option controls when the test suite
prints messages.  The default is to print the body when a test fails, and
error information if there is an uncaught error.  You could also ask for a
message when tests are passed or skipped.  But there isn't an associated
general logging facility.



> > Modules with "Error: No test files remain ...
> 
> This is the message generated by tcltest when there are 
> either no .test files or they are empty, i.e. when there is 
> no testsuite.
> 
> > So I'm not testing these on unix, but they appeared to run tests
> > on WinXP.
> 
> How did you come to the conclusion that they have tests on WinXP ?

I didn't get "Error: No test files remain..."  My misinterpretation.


> > Many aes and blowfish tests failed with "integer value too large
> > to represent" on HP-UX and "integer value too large to represent
> > as non-long integer" on RHEL with tclsh8.3.  For example, I
> > include just one test, but there were 27 others.
> 
> This could be a problem with Tcl 8.3. Do the same error occur 
> with Tcl 8.4 ? Is your machine 64 bit ? 

These fail on HP-UX with ActiveTcl 8.4.6, and also on RHEL with its stock
tclsh8.3.  So it doesn't work on HP-UX.  Might be something to do with wide
ints.  Perhaps we need to ugrade. :-)



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: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Relea se

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

> Please give them a whirl.

I downloaded the preview, unpacked, configured, and ran "make test."
Everything passes on Fedora Core 3, ActiveTcl 8.4.6.  But I got failures
doing the same thing on HP-UX, WinXP/MingW/Msys, and Red Hat Enterprise
Linux (RHEL) 3.  I've gotten to the point of expecting something strange
from HP-UX, but several of the errors are common.  ActiveTcl 8.4.6 was
installed everywhere.

Just a nit, but wouldn't it be nice if a "clean" test results log file was
less than 500 lines long?  I personally like the "no news is good news"
style, where passing tests print nothing.  If the official Tcllib "style"
prints name and version for each module, then I guess that is OK.  But many
tests just print stuff.  Does that bother anybody other than me?

Many RHEL errors stemmed from the fact that 'configure' picked up
/usr/bin/tclsh8.3 in preference to /usr/bin/tclsh, which is linked to
ActiveTcl 8.4.6.  This same behavior occurs on Fedora, but it gets tclsh8.4
there.  Is the configure supposed to prefer a numbered tclsh, if available?

Modules with "Error:  No test files remain after applying your match and
skip patterns!" were ftp, ftpd, grammer_peg, http, irc, javascript, jpeg,
ldap, nntp, page, pluginmgr, smtpd, tar.  So I'm not testing these on unix,
but they appeared to run tests on WinXP.  Is anybody testing these on Unix? 


Many aes and blowfish tests failed with "integer value too large to
represent" on HP-UX and "integer value too large to represent as non-long
integer" on RHEL with tclsh8.3.  For example, I include just one test, but
there were 27 others.

The fileutil install errors occurred only on WinXP.

A couple of fumagic tests actually succeed on HP-UX where they are expected
to fail.  The same tests failed in a different way on WinXP.  I have always
had a couple of discrepancies with the Tcl test suite when it came to
directory/file tests.  Might be related to our network file server.  Perhaps
this isn't a serious problem.

And I'm not sure how to interpret the logger/appender failures on both
HP-UX, and WinXP.  Perhaps someone else could shed some light on those.
Same thing for ripemd on all of HP-UX, RHEL and WinXP.  I don't know what
that package is supposed to do.

I modified pop3-3.5 to capture the error string, and it returns "POP3 TOP
ERROR:" without additional information, but I don't know how to debug that.


Uri has a couple of canonicalization failures on WinXP that I didn't see
elsewhere.  They all fail the same way, with an extra ":", so I appended
only the first failure.

If anybody has any suggestions, I'd be happy to run tests on an HP box.


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/ 





==== aes-fips-C.1e Test vector for AES-128 from FIPS-197 Appendix C.1 FAILED
==== Contents of test case:

    list [catch {
        set txt [binary format H* 00112233445566778899aabbccddeeff]
        set key [binary format H* 000102030405060708090a0b0c0d0e0f]
        set enc [aes::aes -mode ecb -dir enc -key $key $txt]
        binary scan $enc H* r
        set r
    } msg] $msg

---- Result was:
1 {integer value too large to represent}
---- Result should have been (exact matching):
0 69c4e0d86a7b0430d8cdb78070b4c55a
==== aes-fips-C.1e FAILED



==== install-2.1 install a directory FAILED
==== Contents of test case:

    fileutil::install [file join installSrc subdir] installDst
    set result [lsort [glob -tails -directory [file join installDst subdir]
[file join . / *]]]
    file delete -force installDst
    set result

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: no files matched glob pattern "/*"
    while executing
"glob -tails -directory [file join installDst subdir] [file join . / *]"
    invoked from within
"lsort [glob -tails -directory [file join installDst subdir] [file join . /
*]]"
    invoked from within
"set result [lsort [glob -tails -directory [file join installDst subdir]
[file join . / *]]]"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== install-2.1 FAILED


==== install-2.2 install a directory FAILED
==== Contents of test case:

    fileutil::install [file join installSrc subdir] installDst
    set result [lsort [glob -directory [file join installDst subdir] [file
join . / *]]]
    file delete -force installDst
    set result

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error copying "installSrc/subdir" to "installDst/subdir":
file already exists
    while executing
"file copy -force $src $dst"
    (procedure "fileutil::install" line 13)
    invoked from within
"fileutil::install [file join installSrc subdir] installDst"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EEXIST {file already exists}
==== install-2.2 FAILED




==== fumagic.filetype-1.2 test file directory FAILED
==== Contents of test case:

    set f [file join $dir fileTypeTest]
    set res [catch {fileutil::magic::filetype $f} msg]
    regsub {file[0-9]+} $msg {fileXXX} msg
    list $res $msg

---- Result was:
0 {DBase 3 index file}
---- Result should have been (exact matching):
1 {error reading "fileXXX": illegal operation on a directory}
==== fumagic.filetype-1.2 FAILED

==== fumagic.mimetype-1.2 test file directory FAILED
==== Contents of test case:

    set f [file join $dir fileTypeTest]
    set res [catch {fileutil::magic::mimetype $f} msg]
    regsub {file[0-9]+} $msg {fileXXX} msg
    list $res $msg

---- Result was:
0 {}
---- Result should have been (exact matching):
1 {error reading "fileXXX": illegal operation on a directory}
==== fumagic.mimetype-1.2 FAILED


-- and on WinXP with MingW/Msys, we get a different failure --


==== fumagic.filetype-1.2 test file directory FAILED
==== Contents of test case:

    set f [file join $dir fileTypeTest]
    set res [catch {fileutil::magic::filetype $f} msg]
    regsub {file[0-9]+} $msg {fileXXX} msg
    list $res $msg

---- Result was:
1 {couldn't open "C:/Temp/tcllib-1.8/fileTypeTest": permission denied}
---- Result should have been (exact matching):
1 {error reading "fileXXX": illegal operation on a directory}
==== fumagic.filetype-1.2 FAILED

modules/fumagic/mimetypes.test
- tcltest 2.2.5
- fileutil::magic::mimetype 1.0
  - fileutil::magic::rt     1.0

==== fumagic.mimetype-1.2 test file directory FAILED
==== Contents of test case:

    set f [file join $dir fileTypeTest]
    set res [catch {fileutil::magic::mimetype $f} msg]
    regsub {file[0-9]+} $msg {fileXXX} msg
    list $res $msg

---- Result was:
1 {couldn't open "C:/Temp/tcllib-1.8/fileTypeTest": permission denied}
---- Result should have been (exact matching):
1 {error reading "fileXXX": illegal operation on a directory}
==== fumagic.mimetype-1.2 FAILED


==== fumagic.mimetype-1.13 test binary graphic gif FAILED
==== Contents of test case:

    set f [file join $dir fileTypeTest gifFile]
    set res [catch {fileutil::magic::mimetype $f} msg]
    list $res $msg

---- Result was:
1 {file not found: "C:/Temp/tcllib-1.8/fileTypeTest/gifFile"}
---- Result should have been (exact matching):
0 image/gif
==== fumagic.mimetype-1.13 FAILED










==== createFormatCmd-1 check for %d FAILED
==== Contents of test case:

	set a [logger::utils::createFormatCmd %d]
	set b [subst $a]
	regexp {\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d} $b
    
---- Result was:
0
---- Result should have been (exact matching):
1
==== createFormatCmd-1 FAILED


==== createLogProc-1 create a proc and test it FAILED
==== Contents of test case:

	set a [logger::utils::createLogProc  -category catTest  -priority
critical  -procName ::bobo  -conversionPattern {\[%d\] \[%c\] \[%M\] \[%p\]
%m}]
	eval $a
	::bobo test
    
---- Output was:
[G/10/07 07:40:13] [catTest] [namespace] [critical] test

---- Output should have been (regexp matching):
\[[\d:\/ ]+\] \[catTest\] \[namespace\] \[critical\] test
==== createLogProc-1 FAILED


==== applyAppender-1 apply an appender FAILED
==== Contents of test case:

	set log [logger::init testLog]
	logger::utils::applyAppender -appender console -serviceCmd $log
	${log}::error "this is error"
    
---- Output was:
[G/10/07 07:40:13] [testLog] [namespace] [error] this is error

---- Output should have been (regexp matching):
\[[\d:\/ ]+\] \[testLog\] \[namespace\] \[error\] this is error
==== applyAppender-1 FAILED


==== applyAppender-2 apply an appender, to 2 loggers FAILED
==== Contents of test case:

	set log1 [logger::init testLog1]
	set log2 [logger::init testLog2]
	logger::utils::applyAppender -appender console -serviceCmd [list
$log1 $log2]
	${log1}::error "this is error1"
	${log2}::error "this is error2"
    
---- Output was:
[G/10/07 07:40:13] [testLog1] [namespace] [error] this is error1
[G/10/07 07:40:13] [testLog2] [namespace] [error] this is error2

---- Output should have been (regexp matching):
\[[\d:\/ ]+\] \[testLog1\] \[namespace\] \[error\] this is error1\n\[[\d:\/
]+\] \[testLog2\] \[namespace\] \[error\] this is error2
==== applyAppender-2 FAILED


==== applyAppender-3 auto apply FAILED
==== Contents of test case:

	logger::utils::applyAppender -appender console
	set log [logger::init applyAppender-3]
	${log}::error "this is error"
    
---- Output was:
[G/10/07 07:40:13] [applyAppender-3] [namespace] [error] this is error

---- Output should have been (regexp matching):
\[[\d:\/ ]+\] \[applyAppender-3\] \[namespace\] \[error\] this is error
==== applyAppender-3 FAILED


==== applyAppender-4 auto apply FAILED
==== Contents of test case:

	logger::utils::applyAppender -appender colorConsole
	set log [logger::init applyAppender-4]
	${log}::error "this is error"
    
---- Output was:
[G/10/07 07:40:13] [applyAppender-4] [namespace] [error] this is
error

---- Output should have been (regexp matching):
\[[\d:\/ ]+\] \[applyAppender-4\] \[namespace\] \[error\] this is error
==== applyAppender-4 FAILED







==== pop3-3.5 top FAILED
==== Contents of test case:

    dialog::dialog_set {topMessage $__messageA}
    set psock [pop3::open localhost ak smash [dialog::listener]]
    set res [pop3::top $psock 1 1]
    pop3::close $psock
    dialog::waitdone
    set res

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: POP3 TOP ERROR: 
    while executing
"error "POP3 TOP ERROR: $errorStr""
    (procedure "pop3::top" line 5)
    invoked from within
"pop3::top $psock 1 1"
    invoked from within
"set res [pop3::top $psock 1 1]"
    ("uplevel" body line 4)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== pop3-3.5 FAILED




==== ripemd128-trf-1.20 RIPEMD-128 test strings (trf impl) FAILED
==== Contents of test case:

            ::ripemd::ripemd128 -hex -- $msg
        
---- Result was:
d12cd5e9e6222c9acfb7e6f55d237b5f
---- Result should have been (exact matching):
4eb9e2f034b961f464647021b99291ef
==== ripemd128-trf-1.20 FAILED


==== ripemd128-trf-2.1 HMAC RIPEMD-128 test vectors (trf impl) FAILED
==== Contents of test case:

            ::ripemd::hmac128 -hex -key $key -- $msg
        
---- Result was:
25359443edb0c092eb54a15ccb954146
---- Result should have been (exact matching):
ad9db2c1e22af9ab5ca9dbe5a86f67dc
==== ripemd128-trf-2.1 FAILED


==== ripemd128-trf-3.1 HMAC RIPEMD-128 test vectors (trf) FAILED
==== Contents of test case:

            ::ripemd::hmac128 -hex -key $key -- $msg
        
---- Result was:
948ec12cbc6ae1c35b972b690f084598
---- Result should have been (exact matching):
8931eeee56a6b257fd1ab5418183d826
==== ripemd128-trf-3.1 FAILED

modules/ripemd/ripemd160.test
- ripemd160 1.0.3 (Trf based)
- ripemd160 1.0.3 (pure Tcl)

==== ripemd160-trf-1.20 RIPEMD-160 test strings (trf impl) FAILED
==== Contents of test case:

            list [catch {::ripemd::ripemd160 -hex -- $msg} r] $r
        
---- Result was:
0 d50ec733b28b84b96a7a625140a1e1c83b6825a1
---- Result should have been (exact matching):
0 5cc1e0793bad0c5208f3903a8230a712887fcabd
==== ripemd160-trf-1.20 FAILED


==== ripemd160-trf-2.1 HMAC RIPEMD-160 test vectors (trf) FAILED
==== Contents of test case:

            ::ripemd::hmac160 -hex -key $key -- $msg
        
---- Result was:
ac0bf50168c60b84bb492d18c10edba08b46f152
---- Result should have been (exact matching):
cf387677bfda8483e63b57e06c3b5ecd8b7fc055
==== ripemd160-trf-2.1 FAILED


==== ripemd160-trf-3.1 HMAC RIPEMD-160 test vectors (trf) FAILED
==== Contents of test case:

            list [catch {::ripemd::hmac160 -hex -key $key $msg} r] $r
        
---- Result was:
0 a4eb34bf539c7f33ece5684febb214b2d126013f
---- Result should have been (exact matching):
0 fe69a66c7423eea9c8fa2eff8d9dafb4f17a62f5
==== ripemd160-trf-3.1 FAILED


Module:	sasl
modules/sasl/ntlm.test
- SASL::NTLM 1.0.0

==== SASL-NTLM-1.1 NTLM client response FAILED
==== Contents of test case:

    list [catch {
        set ctx [SASL::new -mechanism NTLM -callback NTLMCallback]
        SASL::step $ctx ""
        SASL::step $ctx [base64::decode $Chk(2)]
        set response [SASL::response $ctx]
        SASL::cleanup $ctx
        base64::encode -maxlen 0 $response
    } res] $res

---- Result was:
0
TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAJoAAAAB
AgAAAAAAAABEAE8ATQBBAEkATgB1AHMAZQByAFcATwBSAEsAUwBUAEEAVABJAE8ATsM3zVy9RPyX
gqZnr21CfG3mfCDC0+d8VoLTftHx9ZaM2NlnEeJBCjvPm4ryx3aR4A==
---- Result should have been (exact matching):
0
TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAJoAAAAB
AgAAAAAAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyX
gqZnr21CfG3mfCDC0+d8ViWpjBwx6BhHRmspst9GgPOZWPuMITqcxg==
==== SASL-NTLM-1.1 FAILED



==== uri-5.1-2 uri::canonicalize FAILED
==== Contents of test case:

    uri::canonicalize file://goo.test.net/path1/./remove/../path2/resource

---- Result was:
file://goo.test.net:/path1/path2/resource
---- Result should have been (exact matching):
file://goo.test.net/path1/path2/resource
==== uri-5.1-2 FAILED

RE: !! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Release

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

[Sent again from my home account as the mail from office has not
appeared yet].
  
> > then update the version number, tag the state, and generate a
> > pre-release distribution for testing Friday to Sunday. The only things
> > we will fix in that interval will be very major bugs and showstoppers.

The Tcllib CVS has been tagged and __ pre-release __ archives have been
created. They can be found at

	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.tar.gz
	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.tar.bz
	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.zip
	http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.kit

Please give them a whirl.

The CVS is still frozen.

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

!! Take note !! CVS frozen !! RE: [Tcllib-devel] Tcllib Release 1.8

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

[Sent again from my home account as the mail from office has not
appeared yet].

> We are now in the last week before the release will be made.
> 
> The major new stuff is in the repository and I have the trackers a
> bit. From now on please do not add any more major new code to the CVS
> anymore. Minor new code, and bug fixes are still welcome. Please
> remember to update the file "README-1.8.txt" whenever a checkin is
> made.
> 
> My current plan is to freeze the Tcllib CVS at
> 
> 	[clock format 1128625200]   (*)

Per this announcement the CVS should be considered frozen from now on.
what we have now in the CVS is the planned 1.8 release, except for version
information. Which I will fix in a moment.

Only major bugs and showstopper bugs should be fixed from now until Sunday.
 
> then update the version number, tag the state, and generate a
> pre-release distribution for testing Friday to Sunday. The only things
> we will fix in that interval will be very major bugs and showstoppers.

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

Re: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

Kevin Kenny wrote:
> 
> arj...@wl... said:
> > In general what should happen if a mathematical function is to be
> > evaluated for a set of argument for which it is not defined?
> 
> Hmm, in 8.5, you'll just be able to return NaN. :)
> 
> Returning a clearer message is probably better than a simple
> division by zero, which is likely to get reported as a bug.
> I've got a bunch of such checks in places like modules/math/combinatorics.tcl,
> where there are [return -code error] for most of the corner cases.
> 

Yes, this morning I realised that with Tcl 8.5 things could and would be
different. I still opt for the error message, rather than the NaN (or
Inf)
that the extended numerical features make possible, because it seems to 
me to give the least surprises.

Regards,

Arjen

Re: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

[<ke...@cr...>]

arj...@wl... said:
> In general what should happen if a mathematical function is to be
> evaluated for a set of argument for which it is not defined?

Hmm, in 8.5, you'll just be able to return NaN. :)

Returning a clearer message is probably better than a simple
division by zero, which is likely to get reported as a bug.
I've got a bunch of such checks in places like modules/math/combinatorics.tcl,
where there are [return -code error] for most of the corner cases.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

RE: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

> In general what should happen if a mathematical function is to be
> evaluated for a set of argument for which it is not defined?
>
> In this case, the bug is that there is a division by zero and
> this is reported as such, rather than as a clearer message
> that the coefficient of variation is not defined if the mean
> of the data is zero.
>
> My question:
> - Should the function return such a (clearer) message or
> - Should it return an empty string (not an error) thereby
>   leaving it to the caller to handle the _undefined_
>   situation
>
> I can argue either way, but we should probably try for a
> consistent practice.

My personal opinion is to return a clear error message, even if that entails
catching and rethrowing errors.


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

Re: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

> "Gerald W. Lester" wrote:
> 

> >
> IMHO, I would emulate what sqrt() does in expr, namely:
> 
>      % expr {sqrt(-1.0)}
>      domain error: argument not in valid range
>      % set errorCode
>      ARITH DOMAIN {domain error: argument not in valid range}
>      % set errorInfo
>      domain error: argument not in valid range
>          while executing
>      "expr {sqrt(-1.0)}"
> 
> In other words, raise an error -- but be sure to set error code to
> some appropriate list of informational elements.
> 
> Sincerly,
> Gerald W. Lester

Yes, that is what I had in mind. Thanks

Regards,

Arjen

RE: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

Arjen Markus wrote:
> 
> In general what should happen if a mathematical function is 
> to be evaluated for a set of argument for which it is not defined?
> 
> In this case, the bug is that there is a division by zero and 
> this is reported as such, rather than as a clearer message
> that the coefficient of variation is not defined if the mean
> of the data is zero.
> 
> My question:
> - Should the function return such a (clearer) message or
> - Should it return an empty string (not an error) thereby
>   leaving it to the caller to handle the _undefined_ 
>   situation

I would vote for the error, but a more descriptive error.  In this case,
mean!=0 is much like a precondition.  This function won't work unless the
assertion is true.  The caller can choose to pre-check this condition or
catch errors, or do nothing, and get the error.

If you don't generate an error, and silently return "", then the typical
application program will just have an error some time later in a numeric
comparison or expression.  And that will be -really- cryptic.

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: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

[Gerald W. L. <Ger...@co...>]

Arjen Markus wrote:

>Hello all,
>
>I was just checking the various bug reports that are assigned to me
>and I came across one (bug 1151935) that made me think:
>
>In general what should happen if a mathematical function is to be
>evaluated for a set of argument for which it is not defined?
>
>In this case, the bug is that there is a division by zero and 
>this is reported as such, rather than as a clearer message
>that the coefficient of variation is not defined if the mean
>of the data is zero.
>
>My question:
>- Should the function return such a (clearer) message or
>- Should it return an empty string (not an error) thereby
>  leaving it to the caller to handle the _undefined_ 
>  situation
>
>I can argue either way, but we should probably try for a
>consistent practice.
>  
>
IMHO, I would emulate what sqrt() does in expr, namely:

    % expr {sqrt(-1.0)}
    domain error: argument not in valid range
    % set errorCode
    ARITH DOMAIN {domain error: argument not in valid range}
    % set errorInfo
    domain error: argument not in valid range
        while executing
    "expr {sqrt(-1.0)}"

In other words, raise an error -- but be sure to set error code to some 
appropriate list of informational elements.

Sincerly,
Gerald W. Lester

Re: [Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

Hello all,

I was just checking the various bug reports that are assigned to me
and I came across one (bug 1151935) that made me think:

In general what should happen if a mathematical function is to be
evaluated for a set of argument for which it is not defined?

In this case, the bug is that there is a division by zero and 
this is reported as such, rather than as a clearer message
that the coefficient of variation is not defined if the mean
of the data is zero.

My question:
- Should the function return such a (clearer) message or
- Should it return an empty string (not an error) thereby
  leaving it to the caller to handle the _undefined_ 
  situation

I can argue either way, but we should probably try for a
consistent practice.

Regards,

Arjen

[Tcllib-devel] Tcllib Release 1.8 Status and Action Plan

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

We are now in the last week before the release will be made.

The major new stuff is in the repository and I have the trackers a
bit. From now on please do not add any more major new code to the CVS
anymore. Minor new code, and bug fixes are still welcome. Please
remember to update the file "README-1.8.txt" whenever a checkin is
made.

My current plan is to freeze the Tcllib CVS at

	[clock format 1128625200]   (*)

then update the version number, tag the state, and generate a
pre-release distribution for testing Friday to Sunday. The only things
we will fix in that interval will be very major bugs and showstoppers.

On Monday this pre-release will then go into an ActiveTcl Release
Candidate. After Monday (Oct 10 (x)) till the end of that week only
showstoppers can go into the CVS.

After that the pre-release, or whatever is head, becomes the actual
release with updated tag, is announced, put on websites, etc., and at
least the CVS is unfrozen.


(*) This is from my Point of view, i.e. Pacific Time,
    Noon Thursday Oct 6.

(x) This is Canadian Thanksgiving btw.

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

Re: [Tcllib-devel] Tablelist into tklib?

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

Andreas Kupries schrieb:
>>What is your opinion?  And what actions do I have to take to
>>"officially" request that Tablelist be included in tklib?
> 
> 
> I believe this mail is a got start.
> 
>>From a technical POV (in contrast to the discussion seen far about merits
> and release schedule and such):
> 
> *	As a minimum we need a tarball containing the current state
> 	of Tablelist. This would be imported into the Tklib CVS and
> 	we are set.
> 
> *	Better would be a tarball containing the CVS files (or RCS) for
> 	Tablelist, as they contain the full history of the package.  We
> 	would put this into a directory in the SF system and then send
> 	a support request to the SF managers where to put the unpackaged
> 	files. A bit more round-about, but giving us the full history
> 	of Tablelist in the tklib repository.
> 
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com, a division of Sophos
> 	Tel: +1 604 484 6491
> 
> 

Many thanks to all who have replied to my mail.

Andreas, I will send you a tarball containing the current state of 
Tablelist (based on the last official version 4.1, with a few 
improvements that I have made since its release a week ago).  I think I 
should increase the version number to 4.2, to reflect these changes 
(which are documented in the file CHANGES.txt and in the updated 
reference manual).

Unfortunately, I cannot send you any tarball containing the CVS/RCS 
files, because these files don't exist. :-(  To my shame I must admit 
that I am not using any version control system for my Tcl development 
work (which takes place exclusively in my rather limited spare time).

Best regards,
Csaba

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

Re: [Tcllib-devel] Tablelist into tklib?

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

Brett Schwarz wrote:
> 
> I would like to see this in tklib.
> 

I second that: the success of Tcllib shows that it 
is quite possible to have a library of pure-Tcl 
extensions. When Tablelist is included in Tklib,
it will get more exposure, it will be easier 
to find and it will be asset to Tklib.

Regards,

Arjen

Re: [Tcllib-devel] Tablelist into tklib?

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

Joe English wrote:
> Csaba Nemethi wrote:
> 
>>Michael Schlenker has recently suggested me to submit my Tablelist
>>package for inclusion in tklib. My answer was that I would consider
>>doing this after releasing Tablelist version 4.1. Since I received
>>similar suggestions from several Tablelist users in the past, I think,
>>it would make sense to ask the subscribers of this list whether they
>>share the opinion that Tablelist should be promoted into tklib.
>>[...]
>>What is your opinion?
> 
> 
> The tklib release schedule is rather unpredictable --
> indeed, to date, "nonexistant" is an appropriate adjective --
> so speaking as a Tablelist user, I can't think of any advantages
> that would be obtained by making Tablelist a part of tklib.
> It's just fine as an independent package as far as I'm concerned.
> 
> Bundling Tablelist with tklib would certainly benefit tklib,
> but I don't know if it would benefit Tablelist or its users any.
> 
One of the benefits of including tablelist in tklib, even though tklib
did not have an initial official release yet, would be the inclusion in
the ActiveTcl and AquaBI distros, which bundle a snapshot of tklib.

So i think a similar model to SNIT in tcllib is the way to go, putting a
version into tklib but keeping it as a separate package for those how
are happy with a separate package.

Michael

Re: [Tcllib-devel] Tablelist into tklib?

[Aaron F <ro...@fe...>]

It certainly wouldnt hurt tablelist users either. And after all tklib is
included in ActiveTcl so it may even increase the distribution of
tablelist. The way to a wider audience and more predictable release
schedule for tklib is certainly not to avoid adding functionality to it.

--Aaron

Joe English wrote:
>
> Csaba Nemethi wrote:
> 
> > Michael Schlenker has recently suggested me to submit my Tablelist
> > package for inclusion in tklib. My answer was that I would consider
> > doing this after releasing Tablelist version 4.1. Since I received
> > similar suggestions from several Tablelist users in the past, I think,
> > it would make sense to ask the subscribers of this list whether they
> > share the opinion that Tablelist should be promoted into tklib.
> > [...]
> > What is your opinion?
> 
> The tklib release schedule is rather unpredictable --
> indeed, to date, "nonexistant" is an appropriate adjective --
> so speaking as a Tablelist user, I can't think of any advantages
> that would be obtained by making Tablelist a part of tklib.
> It's just fine as an independent package as far as I'm concerned.
> 
> Bundling Tablelist with tklib would certainly benefit tklib,
> but I don't know if it would benefit Tablelist or its users any.
> 
> --Joe English
> 
>   jen...@fl...
>

Re: [Tcllib-devel] Tablelist into tklib?

[Joe E. <jen...@fl...>]

Csaba Nemethi wrote:

> Michael Schlenker has recently suggested me to submit my Tablelist
> package for inclusion in tklib. My answer was that I would consider
> doing this after releasing Tablelist version 4.1. Since I received
> similar suggestions from several Tablelist users in the past, I think,
> it would make sense to ask the subscribers of this list whether they
> share the opinion that Tablelist should be promoted into tklib.
> [...]
> What is your opinion?


The tklib release schedule is rather unpredictable --
indeed, to date, "nonexistant" is an appropriate adjective --
so speaking as a Tablelist user, I can't think of any advantages
that would be obtained by making Tablelist a part of tklib.
It's just fine as an independent package as far as I'm concerned.

Bundling Tablelist with tklib would certainly benefit tklib,
but I don't know if it would benefit Tablelist or its users any.


--Joe English

  jen...@fl...

Re: [Tcllib-devel] Tablelist into tklib?

[Brett S. <bre...@ya...>]

I would like to see this in tklib.
 

--- Csaba Nemethi <csa...@t-...> wrote:

> Hello,
> 
> Michael Schlenker has recently suggested me to
> submit my Tablelist 
> package for inclusion in tklib. My answer was that I
> would consider 
> doing this after releasing Tablelist version 4.1.
> Since I received 
> similar suggestions from several Tablelist users in
> the past, I think, 
> it would make sense to ask the subscribers of this
> list whether they 
> share the opinion that Tablelist should be promoted
> into tklib.
> 
> I released version 4.1 a few days ago, and since
> then I still performed 
> some further minor improvements on it. Should the
> package be accepted 
> for inclusion in tklib, then I would submit the
> newest version, 
> containing the most recent improvements.
> 
> What is your opinion?  And what actions do I have to
> take to 
> "officially" request that Tablelist be included in
> tklib?
> 
> The Tablelist package is available for free download
> from my web page 
> given below.
> 
> Best regards,
> Csaba
> 
> -- 
> Csaba Nemethi   http://www.nemethi.de  
> mailto:csa...@t-...
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content,
> downloads, discussions,
> and more.
> http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
>
https://lists.sourceforge.net/lists/listinfo/tcllib-devel
> 


--brett


	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

[Tcllib-devel] Tablelist into tklib?

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

Hello,

Michael Schlenker has recently suggested me to submit my Tablelist 
package for inclusion in tklib. My answer was that I would consider 
doing this after releasing Tablelist version 4.1. Since I received 
similar suggestions from several Tablelist users in the past, I think, 
it would make sense to ask the subscribers of this list whether they 
share the opinion that Tablelist should be promoted into tklib.

I released version 4.1 a few days ago, and since then I still performed 
some further minor improvements on it. Should the package be accepted 
for inclusion in tklib, then I would submit the newest version, 
containing the most recent improvements.

What is your opinion?  And what actions do I have to take to 
"officially" request that Tablelist be included in tklib?

The Tablelist package is available for free download from my web page 
given below.

Best regards,
Csaba

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

[Tcllib-devel] Update regarding testsuite results

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

After the updates done to the CVS in the last two days the summary results
look better.

They are actually very very good, but this becomes only clear when reading
the full reports about which tests failed and why. I have done this already
and have annotated the summary with my findings, for easy reading. No need
for anyone else to get and dig through the full reports.


System Architecture : linux-ix86

Shell    Module   Total Passed Skipped Failed
-----    ------   ----- ------ ------- ------
tclsh8.5 asn      216   204    0       12		[1]
-----    ------   ----- ------ ------- ------
tclsh8.5 counter  16    13     1       2		[2]
-----    ------   ----- ------ ------- ------
tclsh8.4 docstrip 7     6      0       1		[4]
tclsh8.5 docstrip 7     6      0       1		[4]
-----    ------   ----- ------ ------- ------
tclsh8.5 exif     1     0      0       1		[2]
-----    ------   ----- ------ ------- ------
tclsh8.5 math     1236  1235   0       1		[2]
-----    ------   ----- ------ ------- ------
tclsh8.5 profiler 20    14     5       1		[3]
-----    ------   ----- ------ ------- ------
tclsh8.5 units    97    96     0       1		[2]
-----    ------   ----- ------ ------- ------
Shell    Module   Total Passed Skipped Failed

[1] The asn testsuite actually exposes a bug in Tcl 8.5 and
    how it is processing numbers. An error has been raised
    for this at the Tcl tracke (IIRC).

	Nothing has to be done by Tcllib.

[2] The treatment of floats has been changed in Tcl 8.5
    (tcl_precision default IIRC). This causes some float
    results to change between 8.4 and 8.5. It will change
    further with Kevin's bignum/floats work.

	I see no reason to try and track these changes until
	that area of Tcl 8.5 has stabilized. I.e. nothing has
	to be done by Tcllib maintainers.

[3] In Tcl 8.5 some clock commands have been implemented as
    procedures, and are thus now reported by the profiler.
    The testsuite does not account for this. I am not sure
    if we should simply update the testsuite for this, if
    some type of exclusion in the profiler itself is warranted.

[4] This is a bug in the testsuite of docstrip and how it tries
    to access some files in the tested module.

    I am willing to let this one slide, although fixing this is
    trivial. It would IMHO be nicer to fix it, as a bit of polish.

So, while the summary is not looking like it, the testsuite is now basically
in order, save the docstrip nit.


Question is, will it look that good for other platforms as well ?

Please get the testenv and run it on your platforms as well. The more, the
merrier. And the better covered we are.

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

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

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

Will Duquette wrote:
> 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.

It should be standard behavior.  What if you have several library
modules that might generate background errors?  What if you're running
them in a GUI where you really don't want the end user to see them
'raw'? Then you have potential problems.

> 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.

It's easier, but providing an error handling hook is more correct
because of the robustness it gives your applications.  Of course, to
keep things 'easy', you could just make the default behavior call
bgerror so that nothing changes.

Ciao,
-- 
David N. Welton
- http://www.dedasys.com/davidw/

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