Tk Library Source Code

SPARC Solaris 2.6, Tcl/Tk 8.4.2:

Using the tcllib CVS head downloaded from activestate
ftp site snapshots on march 25, 2003, I see these errors:


base64 2.2.1 (Trf based)
modules/base64/uuencode.test
Trf present

==== uuencode-1.6 encode dash-string FAILED
==== Contents of test case:

    catch {::uuencode::encode -BC} result
    set result

---- Result was:
::uuencode: wrong # args, all options require an argument
---- Result should have been (exact matching):
+4)#
==== uuencode-1.6 FAILED

==== uuencode-1.7 decode dash-string FAILED
==== Contents of test case:

    catch {::uuencode::decode "-4)#"} result
    set result

---- Result was:
::uuencode: wrong # args, all options require an argument
---- Result should have been (exact matching):
5BC
==== uuencode-1.7 FAILED


Module: crc
modules/crc/cksum.test
modules/crc/crc16.test
modules/crc/crc32.test

==== crc32-2.2 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
1136572392
---- Result should have been (exact matching):
3904355907
==== crc32-2.2 FAILED

==== crc32-2.3 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
3259049013
---- Result should have been (exact matching):
891568578
==== crc32-2.3 FAILED

==== crc32-2.4 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
2141000992
---- Result should have been (exact matching):
538287487
==== crc32-2.4 FAILED


==== crc32-2.5 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
3176146764
---- Result should have been (exact matching):
1277644989
==== crc32-2.5 FAILED

==== crc32-2.6 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
3538338335
---- Result should have been (exact matching):
532866770
==== crc32-2.6 FAILED

==== crc32-2.7 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
1917495676
---- Result should have been (exact matching):
2091469426
==== crc32-2.7 FAILED

==== crc32-2.8 crc32 and unsigned integer FAILED
==== Contents of test case:

        ::crc::crc32 $msg
    
---- Result was:
3857639600
---- Result should have been (exact matching):
2968055525
==== crc32-2.8 FAILED

==== crc32-3.2 crc32 as hexadecimal string FAILED
==== Contents of test case:

        ::crc::crc32 -format 0x%X $msg
    
---- Result was:
0x43BEB7E8
---- Result should have been (exact matching):
0xE8B7BE43
==== crc32-3.2 FAILED

==== crc32-3.3 crc32 as hexadecimal string FAILED
==== Contents of test case:

        ::crc::crc32 -format 0x%X $msg
    
---- Result was:
0xC2412435
---- Result should have been (exact matching):
0x352441C2
==== crc32-3.3 FAILED

==== crc32-3.4 crc32 as hexadecimal string FAILED
==== Contents of test case:

        ::crc::crc32 -format 0x%X $msg
    
---- Result was:
0x7F9D1520
---- Result should have been (exact matching):
0x20159D7F
==== crc32-3.4 FAILED

and so on for quite some time...

Module: struct
modules/struct/graph.test
modules/struct/matrix.test
modules/struct/queue.test
modules/struct/record.test

==== record-0.1 test error with circular records FAILED
==== Contents of test case:

    record define circular {
        one
        {record circular cir}
    } cir(1)

---- Result was:
Can not have circular records. Structure was not created.
---- Result should have been (exact matching):

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== record-0.1 FAILED

==== record-0.1 test error with circular records FAILED
==== Contents of test case:

        namespace eval myns {
    record define circular {
                one
            {record ::myns::circular cir}
        } cir(1)
        }

---- Result was:
Can not have circular records. Structure was not created.
---- Result should have been (exact matching):

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== record-0.1 FAILED


Module: fileutil
modules/fileutil/fileutil.test
fileutil 1.4

Module: ftp
Error:  No test files remain after applying your match
and skip patterns!

Module: ftpd
Error:  No test files remain after applying your match
and skip patterns!

Module: javascript
Error:  No test files remain after applying your match
and skip patterns!

Module: html
modules/html/html.test

Module: irc
Error:  No test files remain after applying your match
and skip patterns!


Module: log
modules/log/log.test
log 1.0.1
modules/log/logger.test
[Tue Mar 25 06:16:40 EST 2003] [global] [error] 'Danger
Will Robinson!'
[Tue Mar 25 06:16:40 EST 2003] [global] [warn] 'Danger
Will Robinson!'
modules/log/loggerperformance.test
Date is now Tue Mar 25 06:16:41 EST 2003
Date is now Tue Mar 25 06:16:41 EST 2003
Date is now Tue Mar 25 06:16:41 EST 2003
and hundreds of more Date outputs

Logged In: YES 
user_id=202636

Until I hear otherwise I think this is a general fix.
Basically we only have bigEndian or littleEndian and it's
now successful with both. Seems I didn't have to treat them
differently after all.

I've committed this change now, plus the additional tests
(in case we need them again).

Logged In: YES 
user_id=15949

Pat, after I make the change in my copy of crc32.tcl, I see
this from the test suite:
 
Module: crc
modules/crc/cksum.test
modules/crc/crc16.test
modules/crc/crc32.test
modules/crc/crc32bugs.test

==== crcbugs-0.0 get platform info - THIS IS SUPPOSED TO
FAIL FAILED
==== Contents of test case:

    array get tcl_platform

---- Result was:
osVersion 5.8 byteOrder bigEndian machine sun4u platform
unix os SunOS user lwv26 wordSize 4
---- Result should have been (exact matching):

==== crcbugs-0.0 FAILED

modules/crc/sum.test


Question - is the change you propose one for me personally,
for anyone using Trf, or for anyone using this module?

Logged In: YES 
user_id=202636

Cheers Larry,
Well it's clearly a byte order problem. I notice that you
are using the Trf based version of crc32 - crc16 doesn't
defer to Trf so it's using the tcl-only implementation.

So - at line 124 in crc32.tcl we have:
        if {$::tcl_platform(byteOrder) == "littleEndian"} {
            set conv i
        } else {
            set conv I
        }

It seems likely that we don't need this. So if you replace
these lines by
  set conv i
and redo the tests I think this will clear up the problem.

Perhaps Trf is already fixing the byte order?

Logged In: YES 
user_id=75003

Larry, your attachment is present.

Brett, I got your new testsuite and applied to the CVS head. 
The tests are now ok, no erors reported. I did some additional 
changes: (I) Cosmetics, i.e. it now has an -*- tcl -*- header to 
force emacs into the correct mode, and indentation is now 
nice. (II) All tests had id 0.1. I have now renumbered them so 
that all have unique id's. Thanks for your help.

As we now have only the crc stuff I am reassigning to pat 
(and will keep an eye on it, just in case Trf has something to 
do with that).

File Added - 46466: crcbugs.out

Logged In: YES 
user_id=15949

Pat, I have downloaded the new test file, and executed it
against the latest CVS head Tcllib and tcl 8.4.2 .  I am
attempting to attach the results with this msg.

Logged In: YES 
user_id=75003

Sure, no problem at all.

I just compared your permissions to those of Pat Thoyts who
most certainly has cvs write access. You have actually more
rights from what is reported. The only thing I can think of
right now is that you are somehow in  this cvs_acls script
they mention ... Checking. No, we don't have such a script.
... IMHO we should file a support request for this. ...
Question: Have you setup your SSH keys ? Can you log in to
the project server via ssh [*] ? If not then that is the
problem you have.

[*] I.e. ssh [email protected]

Logged In: YES 
user_id=159778

I have been trying for the past couple of days, and I still
do not get write access. Here is the exact error message:

cvs [server aborted]: "commit" requires write access to the
repository
cvs commit: saving log message in /tmp/cvsHy50Gw

Andreas, can I just send you the updated file until this
gets resolved?

Thanks

Logged In: YES 
user_id=75003

Brett, I updated yor permission record for tcllib, can you 
check if you now have write-access ?

File Added - 46372: crc32bugs.test

Logged In: YES 
user_id=202636

The crc bug is annoying. It doesn't occur for me on my intel
platforms and I don't have another architecture available
for testing on. I have attached another test file to this
bug - Larry, could you run this file and append the results
to this bug.

Logged In: YES 
user_id=159778

For some reason, I don't have write access. I remember now
that's what I had trouble with before (but then I forgot to
follow up). So, if someone can check on that, or do the
commit for me, that would be great.

     --brett

Logged In: YES 
user_id=75003

The uuencode errors should be gone in the latest CVS head 
of Tcllib (See tcllib bug #700327).

Bugs in struct::record to Brett Schwarz.
Crc might be influenced by Trf, or by changes
made by Pat to enforce 32bit math (Feb 11).

Refering bug to Brett first.