# ticket

tkt_uuid: 01afa9345d4f1f09330edf57cf53971f3d92acf3
type: Bug
status: Open
resolution: Invalid
subsystem: textutil :: expander
priority: 5 Medium
severity: Minor
foundin: 1.3.1
private_contact: 24c76b4d51afd306f214a0794c097894cdc960df
title: textutil::expander expand - cget within an expand
cmimetype: text/plain
submitter: anonymous
assignee: akupries
closer: nobody
comment:
  This may be as intended but it appears that running cget inside of an expand call throws an error.

  testcase:

  ::textutil::expander exp
  exp cset BAR FOO
  exp expand {[exp cget BAR]} --> throws error

  but 
  ::textutil::expander exp2
  exp2 cset BAR2 FOO2
  exp expand {[exp2 cget BAR2]} --> yields FOO2

  This seems like a bug but perhaps I'm missing something.  

  Really like the expander package. Thank you.


tkt_uuid: 66d0effebc8d93a0c3d5c259c98a94563c16cf98
type: Bug
status: Closed
resolution: None
subsystem: tepam
priority: 5 Medium
severity: Minor
foundin: 0.1.0
title: tepam::doc_gen: POD format incorrectly formatted
cmimetype: text/plain
submitter: droll
assignee: afaupell
closer: droll
closedate: 2456583.7115514
comment:
  The argument list of generated POD files are incorrectly formatted:

  > =item [-mtype E<lt>mtypeE<gt>]
  > Message type

  There should be an empty line between =item and the following line:

  > =item [-mtype E<lt>mtypeE<gt>]
  >
  > Message type


tkt_uuid: a761133422392c8ad5780299831b22f8bdcc96ab
type: Patch
status: Closed
resolution: Fixed
subsystem: imap4
priority: 5 Medium
severity: Minor
private_contact: 5b861da73eb25bd34a919c8675a3381d9132b73b
title: imap4: fix minor bugs in imap4::cleanup, imap4::isableto
cmimetype: text/plain
submitter: anonymous
assignee: akupries
closer: aku
closedate: 2456594.77519846
comment:
  The attached patch will fix the two bugs:
  - imap4::cleanup was supposed to call ::close, but instead called imap4::close
  - imap4::isableto - when capa optional argument wasn't given,
      will result in error: can't read "result": no such variable


tkt_uuid: 1d2b62d10d250a0fa43e9b56adbdb967e10db057
type: Bug
status: Closed
resolution: Fixed
subsystem: jpeg
priority: 5 Medium
severity: Severe
foundin: jpeg 0.4.0
private_contact: af9c70d5700d5af288b87a3a9ed94e1300911d18
title: jpeg::getExif crash
cmimetype: text/plain
submitter: anonymous
assignee: akupries
closer: aku
closedate: 2456604.32923125
comment:
  jpeg 0.4.0 --  On Win XP,  TclTk 8.5.8

  Trying to get thumbnails from some jpegs, the following command
    jpeg::getExif c:/tmp/1000.jpg thumbnail
  raises the following error:
    jpeg::getExif  c:/tmp/1000.jpg thumbnail
    can not find channel named "fileebf2e0"

  Note that I have no problems when loading/displaying this file.

  Even the "jpeg::debug" command raises an error :
  marker: d8 length: 0
    SOI (Start Of Image)
  marker: e0 length: 14
    JFIF
      Header: 1.1 1 96 96 0 0
  marker: e1 length: 20
    EXIF data
      MAIN EXIF
      ExifOffset 30
      ExifByteOrder little
      THUMBNAIL EXIF
  can not find channel named "fileebcd58"


tkt_uuid: 4f9147ded45d6b5458236a4a7dd76c305e88c9c7
type: Bug
status: Open
resolution: None
subsystem: http :: autoproxy
priority: 5 Medium
severity: Minor
private_contact: 46b36ee666836233bb67043fcfaddd0f6ba390a1
title: autoproxy HTTPS support should handle authentication
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Although it is possible to use HTTPS with autoproxy:
  http::register https 443 ::autoproxy::tls_socket

  It does not handle any of the basic authentication configurations by ::autoproxy::configure.


tkt_uuid: 299cf8e367d0aed4a1ad9559d619cea5f85a4c95
type: Bug
status: Open
resolution: None
subsystem: yaml
priority: 4
severity: Important
private_contact: ab4830c92e4a1a599d941278263990e91b820f6d
title: yaml can't parse some files properly
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  1. Wrong output
  set d [yaml::yaml2dict .....]
  puts $d

  and you see how strange the output is...

  # the file: http://slexy.org/view/s21BwGvY4m


  2. Fails
  yaml fails to parse http://slexy.org/view/s21SOIImVi


tkt_uuid: b8f35b9883e825c23e00830ecd8f4aacbbd8ca4d
type: RFE
status: Closed
resolution: Accepted
subsystem: sasl
priority: 5 Medium
severity: Minor
private_contact: 5ae4f432be569f9793f7b9be140a192e890922dd
title: SCRAM mechanism for SASL
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456633.34489711
comment:
  I'd like to propose a basic implementation of SCRAM SASL mechanism for the SASL package (RFC-5802). It can be downloaded from http://sgolovan.nes.ru/tmp/scram-0.1.tar.gz and contains a separate package scram.tcl which implements the general algorithm and SCRAM-SHA-1 mechanism, and a very basic test suite (with only two tests).


tkt_uuid: 6b7aa0aecca6fdce12589884c3c9ea2b50c92ad4
type: Bug
status: Closed
resolution: Fixed
subsystem: tar
priority: 5 Medium
severity: Important
foundin: 1.15
private_contact: 3fedc5136b468329676f5199f7389ae0f7d92d8f
title: tar::skip silently trucates skip length to 65536
cmimetype: text/plain
submitter: pooryorick
assignee: aku
closer: aku
closedate: 2456619.51749075
comment:
  For some reason, there is  a line in tar::skip that silently truncates skip length to 65536.  This causes failures for tar files like, e.g., obst-3.4.3.tar.gz (find it at http://wiki.tcl.tk/7109).

  patch and the start of a test suite in pyk-tar branch


tkt_uuid: 864a0c83e3d03678765c49246bdac961dd337670
type: Bug
status: Closed
resolution: Fixed
subsystem: tcl :: chan :: *
priority: 5 Medium
severity: Important
foundin: 1.15
private_contact: 3fedc5136b468329676f5199f7389ae0f7d92d8f
title: memchan stops generating read events when cursor is at end of file
cmimetype: text/plain
submitter: pooryorick
assignee: aku
closer: aku
closedate: 2456619.26394929
comment:
  In the following script, [copied] never runs, and the script never completes.  The reason is the [::tcl::chan::memchan::implementation Events] disallows reads when the cursor is at the end of the file, so [fcopy] never gets the readable file event it is waiting for to get the empty string upon reading and check [eof].  Commenting out the line in Events that disallows "read" fixes the problem in this case. 

  ---- begin code ----
  #! /bin/env tclsh

  package require tcl::chan::events
  package require tcl::chan::memchan

  proc copied {args} {
          puts $args
          set ::done 1
  }

  set chan [tcl::chan::memchan]
  puts -nonewline $chan [string repeat a 50000]
  seek $chan 0 start
  set chanout [open zout w]
  fcopy $chan $chanout -command copied

  vwait ::done


tkt_uuid: cffddbb426c668b6ed0cca5ee209d131cd23e9f3
type: Bug
status: Open
resolution: None
subsystem: yaml
priority: 5 Medium
severity: Important
foundin: 0.3.6
private_contact: 1d771dfd9a257dad4825b410aead5bd1a7910fe7
title: Is this package being supported?
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  Hi guys,

  Is this package being supported?
  The developer has been awfully quiet on the open tickets, yet this package is in the latest TCLLIB.

  I have been trying to convince my team to rely on tcllib, but I am losing that battle.

  Can we rely on this package to be updated?

  Please advise,
  Thanks,
  -Arman.


tkt_uuid: 6efa4f571af05277b59c92989e9864cbc0a33326
type: Patch
status: Closed
resolution: Fixed
subsystem: json
priority: 7 High
severity: Important
private_contact: 3c910f5c2718ed76f02e67a48193f3cdea24c9ab
title: C-implementation for json2dict
cmimetype: text/html
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456665.51281406
comment:
  <p align="justify">The pure-Tcl implementation of json2dict &mdash; the sole procedure available in the json-package &mdash; is very slow. Although it may be sped up a little in pure Tcl, it may be better to implement the functionality in C.

  <p align="justify">Here is <A href="http://aldan.algebra.com/~mi/json.c">my sample implementation</A>, which uses the <A href="https://github.com/json-c/json-c/wiki">json-c package</A> for the actual parsing.

  <p align="justify">I needed to parse a total of 60-70Mb of JSON files. Using this C implementation, my program works 10-12 times faster, than with the pure-Tcl one. Perhaps, the Tcl code can check at loading time, whether the C-implementation is available on the system &mdash; and only fall back to the pure Tcl parser, if there is no alternative. I believe, this is already being done for the encryption/checksumming packages, which can use Trf, if available.

  <p align="justify">If the idea takes off, some more C-functions can be added to provide alternatives to the json_write stuff as well.


tkt_uuid: d8d201739eb840c8d55c91f8ba5cf72443340bdf
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: tklib :: ico
priority: 5 Medium
severity: Severe
foundin: 1.11
private_contact: be10c68edb35fa3f93c8cac6f2c0d27dc3933920
title: tklib::ico package ignores the transparency
cmimetype: text/plain
submitter: anonymous
assignee: afaupell
closer: aku
closedate: 2456633.26538315
comment:
  If an icon contains transparency information and the icon is loaded into a Tk image, than saving this image causes a loss of transparency information.

  Inspecting the transparency values in the data of the icon retrieved from the ico package is "empty".


tkt_uuid: f58015fbd0ffc074269b32006c6554a89dac0f1f
type: Bug
status: Closed
resolution: Fixed
subsystem: ftp
priority: 5 Medium
severity: Important
foundin: ftp 2.4.11
private_contact: bdcecae5a03289be0b09b3bc4d0689fcbdc2ddad
title: Incorrect error handling in ftp module
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456687.31335044
comment:
  The default output handling mechanism of the ftp package (::ftp::DisplayMsg) has a bug which varies in severity from incorrect output to throwing an error.

  The current implementation of ::ftp::DisplayMsg tries to use ::errorInfo whenever it is called with the internally defined state indicator "error", which is inconsistent with how the error state is used throughout the ftp module.  In many procs, error is a logical state of the ftp module, but not a Tcl error, so errorInfo does not contain any relevant information.  Most of the time, this just leads to DisplayMsg showing an out of date errorInfo stack trace, but sometimes ::errorInfo doesn't exist yet, which causes DisplayMsg to blow up.

  Example: (Actual error message will probably vary based on local configs)

  /e/Share/fm/dev $ tclsh
  % package require ftp
  2.4.11
  % ::ftp::Put 1 file.txt
  error     error | E: Not connected!:
  error     can't read "::tcl_pkgPath": no such variable
  error         while executing
  error     "foreach Dir $::tcl_pkgPath {
  error               if {$Dir ni $::auto_path} {
  error                   lappend ::auto_path $Dir
  error               }
  error           }"
  0
  %


tkt_uuid: 843c2257d2bd4c8c3b935c0269fa8be8901493e0
type: Bug
status: Closed
resolution: None
subsystem: math :: interpolate
priority: 5 Medium
severity: Important
foundin: 1.0.2
title: interp-spatial fails when interpolation point is in the given point set
cmimetype: text/x-fossil-wiki
submitter: anonymous
closer: arjenmarkus
closedate: 2456647.06010558
comment:
  interp-spatial fails when interpolation point $coord is in the given point set $xyvalues. Test case:

  <pre>
  interp-spatial {{1 1 1} {2 1 2} {1 2 5} {2 2 6} } {1 1}
  </pre>

  Should give 1, but yields an exception due to the calculation of the inverse of the distance.

  Proposed patch: 

  <pre>
   ...
       if { $max_radius2 == {} || $dist <= $max_radius2 } {
  	 if { $dist == 0.0 } {	         # PATCH
  	     return [lindex $point end]; # PATCH
  	 };				 # PATCH
           if { $inv_dist_pow == 1 } {
   ...
  </pre>


tkt_uuid: 31868eeaff873109c7a15fd94c942c81c857dc15
type: RFE
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 7 High
severity: Important
title: Consolidate (duplicated) utility packages
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2458593.21194078
comment:
  The modules 'doctools' and 'pt' have duplicated utility packages.

  - doctools::paths  / paths         --> Simple path mgmt --> fileutil
  - doctools::config / configuration --> array as object. Remove?
  - doctools::text   / text::write   --> text generation utils --> textutil

  The module 'doctools' and 'pt' contain utility packages which do not really belong to them, but other modules.

  - text::write    --> textutil
  - char           --> textutil
  - doctools::html --> textutil, see doctools::text (foundation)
  - doctools::text --> textutil

  Crosscheck with html package


tkt_uuid: 759713c5c469c847a1b5820db3d6fe8418a98ceb
type: Bug
status: Open
resolution: None
subsystem: mime
priority: 5 Medium
severity: Important
foundin: 8.5
private_contact: 0dfe2e6aa820af3598e203fec901fc46f1ba3c95
title: Tcllib mime package doesn't (document) support for header encoding
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  There is no publicly documented way to provide a header in any other encoding than US ASCII. However the following code seems to work for Latin_1:

      set token [mime::initialize -string $emailContent -canonical text/plain -encoding quoted-printable -param {charset iso-8859-1}]
      set subject [::mime::word_encode utf-8 quoted-printable [encoding convertto utf-8 "öö"]]   
      # ... ie. subject set to two umlaut-o characters

  This uses the undocumented ::mime::word command and setting other parameters accordingly. The desire here would likely be that sensible defaults would be given without the developer having to worry about matters, assuming strings are Tcl utf-8 strings.


tkt_uuid: 861f53ff24c0a5c23306db9f5118d790a4cd3ec0
type: Patch
status: Closed
resolution: Fixed
subsystem: sasl
priority: 5 Medium
severity: Important
private_contact: 07bcf89c4057d2d0e00473ab972eef3274af2d93
title: md5_bin is used from SASL::SCRAM
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456679.22882715
comment:
  Hi!

  SASL::SCRAM package uses [SASL::CreateNonce] to generate a random string, and it doesn't work well if /dev/urandom is not available, because it tries to call md5_bin and fails because md5_init wasn't called.

  I'd like to propose the following patch to SASL.tcl (I've made it for an AS distribution, so the line numbers and filename are a bit off):

  --- SASL-1.3.2.tm.orig	Mon Nov 26 15:27:07 2012
  +++ SASL-1.3.2.tm	Mon Jan 13 10:46:51 2014
  @@ -636,6 +636,7 @@
           }
       }
       if {[string length $bytes] < 1} {
  +        md5_init
           set bytes [md5_bin [clock seconds]:[pid]:[expr {rand()}]]
       }
       return [binary scan $bytes h* r; set r]


tkt_uuid: 7665c3532cbe1ef45f710ab998a6a21f630a0faf
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 7 High
severity: Important
foundin: 1.15
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: Can't match the empty string
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456681.2969008
comment:
  It is not straightforward to construct a grammar with a node accepting the empty string. For example:

  PEG test (start)
          start <- "a" / "";
  END;

  We want the parser to consume the either the "a" if there, or accept without consuming otherwise.

  Trying to generate a parser for this grammar results in the following stack trace:

  wrong # args: should be "pt::pe sequence pe ..."
      while executing
  "pt::pe sequence {*}$args"
      (procedure "Literal" line 5)
      invoked from within
  "Literal 40 41"
      (in namespace eval "::pt::peg::from::peg::GEN" script line 1)
      invoked from within
  "namespace eval GEN $ast"
      (procedure "pt::peg::from::peg::GEN" line 4)
      invoked from within
  "pt::peg::from::peg::GEN {Literal 40 41}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel $level [list {*}$cmdprefix $new]"
      (procedure "Bottomup" line 12)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup $clevel $cmdprefix $c"
      (procedure "Bottomup" line 9)
      invoked from within
  "Bottomup 2 $cmdprefix $ast"
      (procedure "::pt::ast::bottomup" line 2)
      invoked from within
  "pt::ast bottomup  pt::peg::from::peg::GEN  $ast"
      (procedure "Convert" line 28)
      invoked from within
  "Convert"
      (procedure "::pt::peg::from::peg::convert" line 7)
      invoked from within
  "pt::peg::from::peg convert $input"
      (procedure "::pt::pgen::peg" line 3)
      invoked from within
  "::pt::pgen \
  	  peg [fileutil::cat $filepath] \
  	  snit \
  	  -file $filepath \
  	  -name $name \
  	  -class $class"
      invoked from within
  "puts [::pt::pgen \
  	  peg [fileutil::cat $filepath] \
  	  snit \
  	  -file $filepath \
  	  -name $name \
  	  -class $class]"
      (file "./bin/generate-parser" line 32)

  As a workaround, we are using a void nonterminal:

          # We perform an optional match on an improbable terminal, so that we
          # accept without consuming any input.
  void:   EMPTY <- "␀␀␀"?;

  Then, the former grammar can be expressed as:


  PEG test (start)
          start <- "a" / EMPTY;
  END;

  Best regards,
  Adrián Medraño Calvo.


tkt_uuid: eb0b15d5981300c3c13b90ab4d3e7cd18c36095a
type: Bug
status: Closed
resolution: Fixed
subsystem: ftp
priority: 5 Medium
severity: Critical
foundin: ftp 2.4.11
private_contact: bdcecae5a03289be0b09b3bc4d0689fcbdc2ddad
title: Ftp module throws errors into the event loop
cmimetype: text/plain
submitter: anonymous
closer: aku
closedate: 2456710.38169527
comment:
  The module regularly throws errors into the event loop, which are very hard to recover from.  I have verified that the problem is reproducable on my desktop machine (Win7 using mingw) and an embedded Linux device.

  I have a test script which shows the problem.  In the following output, there is one successful NList command, and the second NList causes the error.

  ===
  [2014-01-24T14:26:34] [info] [stress] Count 19/100 NList = /Outbox/Store_11420/Done /Outbox/Store_11420/PCO-11420-140123-183131.xml
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> state="type"
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: info | ---> TYPE A
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> msgtext="200 Type set to A."
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> state="type_sent"
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: control | C: 200 Type set to A.
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:34] [debug] [DisplayMsg] -> state="nlist_active"
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: data | D: Port is 59758
  [2014-01-24T14:26:34] [debug] [DisplayMsg] ftp: info | ---> PORT 192,168,16,140,233,110
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="200 PORT command successful."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="nlist_open"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> NLST /Outbox/Store_11420
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 200 PORT command successful.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="150"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="150 Opening ASCII mode data connection."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="list_sent"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 150 Opening ASCII mode data connection.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: data | D: Connection from <ip addr>:20
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="226"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="226 Transfer complete."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="list_close"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: data | D: Port closed
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 226 Transfer complete.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="type"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> TYPE I
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="200 Type set to I."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="type_sent"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 200 Type set to I.
  [2014-01-24T14:26:35] [info] [stress] Count 20/100 NList = /Outbox/Store_11420/Done /Outbox/Store_11420/PCO-11420-140123-183131.xml
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="type"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> TYPE A
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="200 Type set to A."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="type_sent"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 200 Type set to A.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="nlist_active"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: data | D: Port is 59759
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> PORT 192,168,16,140,233,111
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="200 PORT command successful."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="nlist_open"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> NLST /Outbox/Store_11420
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 200 PORT command successful.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="150"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="150 Opening ASCII mode data connection."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="list_sent"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 150 Opening ASCII mode data connection.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="226"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext="226 Transfer complete."
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="list_close"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: control | C: 226 Transfer complete.
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | -> rc="   "
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> msgtext=""
  [2014-01-24T14:26:35] [debug] [DisplayMsg] -> state="type"
  [2014-01-24T14:26:35] [debug] [DisplayMsg] ftp: info | ---> TYPE I
  [2014-01-24T14:26:35] [error] [bgerror] bgerror: Unknown state "type_sent"
  [2014-01-24T14:26:35] [error] [bgerror] Unknown state "type_sent"
  [2014-01-24T14:26:35] [error] [bgerror]     while executing
  [2014-01-24T14:26:35] [error] [bgerror] "error "Unknown state \"$ftp(State)\"""
  [2014-01-24T14:26:35] [error] [bgerror]     (procedure "::ftp::InitDataConn" line 55)
  [2014-01-24T14:26:35] [error] [bgerror]     invoked from within
  [2014-01-24T14:26:35] [error] [bgerror] "::ftp::InitDataConn 0 sock560 <ip addr> 20"
  [2014-01-24T14:26:36] [debug] [DisplayMsg] ftp: info | -> rc="200"
  [2014-01-24T14:26:36] [debug] [DisplayMsg] -> msgtext="200 Type set to I."
  [2014-01-24T14:26:36] [debug] [DisplayMsg] -> state="type_sent"
  ===

  Here is the script:
  ======
  package require log
  package require ftp

  namespace import ::log::log*
  namespace import ::ftp::*

  # Set log package options
  ::log::lvSuppressLE warning 0
  ::log::lvSuppress debug 0
  ::log::lvCmdForall logCmd

  proc logCmd {lvl txt} {
      if {[info level] > 2} {
          set method [lindex [info level -2] 0]
      } else {
          set method "global"
      }
      set line "\[[clock format [clock seconds] -format {%Y-%m-%dT%H:%M:%S}]\] \[$lvl\] \[$method\] $txt"
      puts stdout $line
      flush stdout
  }

  # Set ftp package options
  namespace eval ftp {
      set VERBOSE 1
      set DEBUG 1

      # Override default output routine
      proc DisplayMsg {s msg {state "info"}} {
          ::log::log debug "ftp: $state | $msg"
          # if {$state eq "error" && [info exists ::errorInfo]} {
          #     ::log::log debug $::errorInfo
          # }
          return
      }
  }

  proc bgerror {msg} {
      log error "bgerror: $msg"
      if {[info exists ::errorInfo]} {
          log error "$::errorInfo"
      } else {
          log error "errorInfo does not exist"
      }
  }

  proc connect {addr} {
      log info "Opening anonymous FTP connection to $addr"
      set ftp [::ftp::Open $addr anonymous anonymous -port 21 -timeout 20]
  }

  proc disconnect {ftp} {
      ::ftp::Close $ftp
  }

  proc stress {ftp count} {
      for {set n 0} {$n < $count} {incr n} {
          set nlist [::ftp::NList $ftp /Outbox/Store_11420]
          log info "Count $n/$count NList = $nlist"
      }
  }
  ======


tkt_uuid: c1ca34ead35c9f8d6c3e02a46b085a566ad3deb9
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: geometry
priority: 5 Medium
severity: Minor
foundin: 1.1.2
private_contact: 983f37a90e3ed1e2cdda58c9eda3d4f3bd164c59
title: math::geometry::pointInsidePolygon issue
cmimetype: text/plain
submitter: anonymous
closer: arjenmarkus
closedate: 2456688.33873453
comment:
  ::math::geometry::pointInsidePolygon {3.0 -1.5} {2.0 2.0   -2.0 2.0   -2.0 -2.0   2.0 -2.0}

  returns 1

  the point {3.0 -1.5} is not in the polygon defined by {2.0 2.0   -2.0 2.0   -2.0 -2.0   2.0 -2.0} and should have return 0


tkt_uuid: bff902be357c9279d3a18b543f793da377945989
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: geometry
priority: 5 Medium
severity: Minor
foundin: 1.1.2
private_contact: 983f37a90e3ed1e2cdda58c9eda3d4f3bd164c59
title: ::math::geometry::calculateDistanceToPolyline issue
cmimetype: text/plain
submitter: anonymous
closer: arjenmarkus
closedate: 2456688.34027552
comment:
  ::math::geometry::calculateDistanceToPolyline {2.0 0.5} {2.0 2.0   -2.0 2.0   -2.0 -2.0   2.0 -2.0} returns 1.5

  The point {2.0 0.5} is on the above poly and should have returned 0.0


tkt_uuid: 2186ff86b7fcc0ba6e539edcbecf5276136a0fa7
type: Bug
status: Closed
resolution: Fixed
subsystem: ip
priority: 5 Medium
severity: Severe
foundin: 1.2
private_contact: 73876f6aa38a6950241a301fba0afa7f26493095
title: ::ip::toInteger returns an incorrect value for 255.255.255.255
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456693.38908227
comment:
  [user@localhost ~]$ tclsh
  % package req ip
  1.2
  % ::ip::toInteger 255.255.255.255
  -1 << value rolled over
  % 
  % 
  % info body ::ip::toInteger

      binary scan [ip::Normalize4 $ip] I out
      return $out

  % 
  This issue is present in any function that calls toInteger


  Fix resembles the following:
  proc ::ip::toInteger {ip} {
      binary scan [ip::Normalize4 $ip] H8 out
      return [format %u "0x$out"]
  }
  #with fix
  % ::ip::toInteger 255.255.255.255
  4294967295


tkt_uuid: 659631d1f44f2eaf6f6732e9b035efc3497c69d2
type: Bug
status: Closed
resolution: Fixed
subsystem: ip
priority: 5 Medium
severity: Severe
foundin: 1.2
private_contact: 73876f6aa38a6950241a301fba0afa7f26493095
title: nextNet --> nextNet's count argument does not function as expected
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456693.37318565
comment:
  #porting from Sourceforge, and originally posted by Mathew Jefferson

  http://sourceforge.net/p/tcllib/bugs/1167/

  Returns an unexpected result for any value of "count" other than 1.
  eg: 
  nextNet 1.1.1.1 24 3 
  ...returns "1.1.2.3", not "1.1.4.1", which is what I was expecting.
  The following proc contains my fix:
  proc ::ip::nextNet {prefix mask args} {
  set count 1
  while {[llength $args]} {
  switch -- [lindex $args 0] {
  -ipv4 {set args [lrange $args 1 end]}
  default {
  set count [lindex $args 0]
  set args [lrange $args 1 end]
  }
  }
  }
  if {![string is integer -strict $prefix]} {
  set prefix [toInteger $prefix]
  }
  if {![string is integer -strict $mask] || ($mask < 33 && $mask > 0)} {
  set mask [maskToInt $mask]
  }
  # This is the fix for the issue with "count".
  set prefix [expr $prefix + ((($mask ^ 0xFFffFFff) + 1) * $count) ]
  #set prefix [expr $prefix + ($mask ^ 0xFFffFFff) + $count ]
  return [format "0x%08x" $prefix]
  }

  This affects any operation that is looking to increment network N times in a single shot. It can be coded around.


tkt_uuid: 0fc3770ef50ec3c83460f6852cebb3074ee5e630
type: RFE
status: Open
resolution: None
subsystem: ip
priority: 5 Medium
severity: Minor
foundin: 1.2
private_contact: 73876f6aa38a6950241a301fba0afa7f26493095
title: Request for IPv6 support in the function ::ip::nextNet
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  Reference material
  http://www2.tcl.tk/13489

  Looking over the above functions listed on the webpage, it seems possible to do a unified nextNet function that will function for Ipv4 and IPv6. 

  The underlying string operations would require some additional functions not laid out on the referenced page, but are fairly trivial to code.


tkt_uuid: 600210572277778aac00ac3973ff156dc1655e51
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: list
priority: 5 Medium
severity: Severe
foundin: trunk
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: struct::list filter does not evaluate cmdprefix in caller's scope
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456693.42023737
comment:
  The documentation for `struct::list filter' (http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/struct/struct_list.html#13) states that "[...]The evaluation takes place in the context of the caller of the subcommand.", but that is not the case: the `cmdprefix' is evaluated in the scope of ::struct::list::Lfilter.

  The same issue is true of Lsplit, as it delegates to Lfold without collapsing levels. This one, on the other hand, does not state in its documentation in which scope its `cmdprefix' is to be evaluated. One may think that, intuitively, its `cmdprefix' should be evaluated at the caller's scope as well.

  The following patch adds tests and implements a possible fix for the above issue affecting `::struct::list filter' and `::struct::list split'.

  Index: modules/struct/list.tcl
  ==================================================================
  --- modules/struct/list.tcl
  +++ modules/struct/list.tcl
  @@ -756,11 +756,11 @@
   #       None of its own, but the command prefix can perform arbitrary actions.
   
   proc ::struct::list::Lfilter {sequence cmdprefix} {
       # Shortcut when nothing is to be done.
       if {[::llength $sequence] == 0} {return $sequence}
  -    return [Lfold $sequence {} [::list ::struct::list::FTest $cmdprefix]]
  +    return [uplevel 1 [::list ::struct::list::Lfold $sequence {} [::list ::struct::list::FTest $cmdprefix]]]
   }
   
   proc ::struct::list::FTest {cmdprefix result item} {
       set pass [uplevel 1 [::linsert $cmdprefix end $item]]
       if {$pass} {::lappend result $item}
  @@ -820,21 +820,21 @@
   proc ::struct::list::Lsplit {sequence cmdprefix args} {
       set largs [::llength $args]
       if {$largs == 0} {
   	# Shortcut when nothing is to be done.
   	if {[::llength $sequence] == 0} {return {{} {}}}
  -	return [Lfold $sequence {} [::list ::struct::list::PFTest $cmdprefix]]
  +	return [uplevel 1 [::list ::struct::list::Lfold $sequence {} [::list ::struct::list::PFTest $cmdprefix]]]
       } elseif {$largs == 2} {
   	# Shortcut when nothing is to be done.
   	foreach {pv fv} $args break
   	upvar 1 $pv pass $fv fail
   	if {[::llength $sequence] == 0} {
   	    set pass {}
   	    set fail {}
   	    return {0 0}
   	}
  -	foreach {pass fail} [Lfold $sequence {} [::list ::struct::list::PFTest $cmdprefix]] break
  +	foreach {pass fail} [uplevel 1 [::list ::struct::list::Lfold $sequence {} [::list ::struct::list::PFTest $cmdprefix]]] break
   	return [::list [llength $pass] [llength $fail]]
       } else {
   	return -code error \
   		"wrong#args: should be \"::struct::list::Lsplit sequence cmdprefix ?passVar failVar?"
       }

  Index: modules/struct/list.test
  ==================================================================
  --- modules/struct/list.test
  +++ modules/struct/list.test
  @@ -498,10 +498,30 @@
   
   test filter-4.4 {filter command} {
       filter {2 4 6} even
   } {2 4 6}
   
  +
  +# Alternate which elements are filtered by using a global variable flag. Used
  +# to test that the `cmdprefix' is evaluated in the caller's scope.
  +#
  +# The flag variable should be set on the -setup phase.
  +#
  +proc alternating {_} {
  +    upvar 1 flag flag;
  +    set flag [expr {!($flag)}];
  +    return $flag;
  +}
  +
  +test filter-4.5 {filter evaluates cmdprefix on outer scope} -body {
  +    filter {1 2 3 4 5 6} alternating;
  +} -result {2 4 6} -setup {
  +    set flag 1;
  +} -cleanup {
  +    unset flag;
  +}
  +
   #----------------------------------------------------------------------
   
   interp alias {} filterfor {} ::struct::list::list filterfor
   
   test filterfor-4.1 {filterfor command} {
  @@ -555,10 +575,19 @@
   } {{0 3} {} {3 5 7}}
   
   test split-4.8 {split command} {
       list [lsplit {2 4 6} even pass fail] $pass $fail
   } {{3 0} {2 4 6} {}}
  +
  +# See test filter-4.5.
  +test split-4.9 {split evaluates cmdprefix on outer scope} -body {
  +    list [lsplit {1 2 3 4 5 6 7 8} alternating pass fail] $pass $fail
  +} -result {{4 4} {2 4 6 8} {1 3 5 7}} -setup {
  +    set flag 1;
  +} -cleanup {
  +    unset flag;
  +}
   
   #----------------------------------------------------------------------
   
   interp alias {} shift {} ::struct::list::list shift
   

  Best regards,
  Adrián Medraño Calvo.


tkt_uuid: a6fd19d6cfdfa80bf8011f5fa8308b39d0aa85a5
type: Bug
status: Closed
resolution: Fixed
subsystem: widget
priority: 5 Medium
severity: Minor
foundin: 1.6
private_contact: 438e59f1f1c891b29d2528ed82d1e629cecc6336
title: websocket example doesn't work with 8.6
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: emmanuel
closedate: 2456790.00720363
comment:
  The websocket example in the documentation works fine with tcl 8.5 but fails with 8.6. Here are the two outputs:

  > tclsh8.5 ws.tcl
  [Tue Feb 04 09:31:52 CET 2014] [websocket] [debug] 'Removed socket sock5 from internal state of http library'
  [Tue Feb 04 09:31:52 CET 2014] [websocket] [debug] 'sock5 has been registered as a client WebSocket'
  Connected on sock5
  client from sn2000.medacta.locale to ec2-174-129-224-73.compute-1.amazonaws.com
  [Tue Feb 04 09:31:52 CET 2014] [websocket] [debug] 'Sent 19 bytes long text final fragment to server'
  [Tue Feb 04 09:31:52 CET 2014] [websocket] [debug] 'Received 19 long text final fragment from server'
  RECEIVED: Testing, testing...

  > tclsh8.6 ws.tcl
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [debug] 'Removed socket sock801ee6a90 from internal state of http library'
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [debug] 'sock801ee6a90 has been registered as a client WebSocket'
  Connected on sock801ee6a90
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [debug] 'Received 0 long close final fragment from server'
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [warn] 'Cannot send along WS sock801ee6a90, not connected'
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [info] 'Closing web socket: 1000 (Normal closure)'
  [Tue Feb 04 09:32:16 CET 2014] [websocket] [warn] 'sock801ee6a90 is not a WebSocket connection anymore'
  sock801ee6a90 is not a WebSocket
      while executing
  "::websocket::conninfo $sock type"
      (procedure "test" line 2)
      invoked from within
  "test sock801ee6a90"
      ("after" script)


tkt_uuid: fefcf3678801b2a5f56fbca6bc3ee3032d5a01d3
type: Bug
status: Open
resolution: None
subsystem: comm
priority: 6
severity: Important
foundin: 4.6.2
private_contact: 963550a1cc72196cbf54dbf695dae0e5c2a90c08
title: remoteid-to-socket ambiguity in comm
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Problems arise when two different clients connect to comm using the same port number in comm, and both pretend to be "localhost".  This happens e.g. if one client is really local and the other uses ssh tunnel to localhost. When the latter client connects, one gets a message about "incoming race condition". (I'm not sure if this should really be called a race condition, actually). When one then tries to use comm::comm send to the latter client using the (now common!!) remoteid, of course the commands goes to the first client.

  A specific example using three wish 8.6 executables on Mac OS. 

  Wish1 in computer1, wish2 in computer1, and wish3 in computer2. Wish1 playes the role of a server, the other are clients. Wish1 listens in OS-assigned port 55401. Wish2 in OS-assigned port 55404. Wish2 connects to wish1 by giving a command. Then, in computer2, an ssh tunnel is created to the wish1 in the computer1, using

  ssh -L 6000:localhost:55401 computer1

  and wish3 is started, and configured to use the same port number 55404 as wish2. Then wish3 connects via the tunnel, using

  % comm::comm send {6000 localhost} puts hello


  After this has been done, the ::comm::comm array in wish1 contains following stuff

  :comm::comm(::comm::comm,chan)                  = ::comm::comm
  ::comm::comm(::comm::comm,encoding)              = utf-8
  ::comm::comm(::comm::comm,events)                = 
  ::comm::comm(::comm::comm,fids,sock7fdf739fc190) = 55404
  ::comm::comm(::comm::comm,fids,sock7fdf740b5590) = 55404
  ::comm::comm(::comm::comm,interp)                = 
  ::comm::comm(::comm::comm,listen)                = 1
  ::comm::comm(::comm::comm,local)                 = 0
  ::comm::comm(::comm::comm,peers,55404)           = sock7fdf739fc190
  ::comm::comm(::comm::comm,pending,55404)         = 
  ::comm::comm(::comm::comm,port)                  = 55401
  ::comm::comm(::comm::comm,remoteid)              = 55404
  ::comm::comm(::comm::comm,serial)                = 0
  ::comm::comm(::comm::comm,silent)                = 0

  This appears a legal way of using the system, and in fact, both wish2 and wish3 can still send commands  to wish1, and they work normally. But now wish1 would like to send a command to wish3, using only the info it has (not knowing the actual IP address of computer2, or like that). It cannot do that, because the "peers" entry in the comm array gives only the socket that leads to wish2. Note that the reverse mapping (socket-to-id) contains both relevant sockets, but cannot be inverted, because the right-hand-sides are equal.

  What I have been doing for the time being, is actually grab the socket fids of the connections when they occur, and force the peer-to-socket map to point the correct fid when I give the command. But this is a rather desperate hack, I would think.

  I'm no really sure if this could be called a bug at all, except about possibly about the "race conditions" message, maybe. 

  ---

  If anyone is interested, the overall context where I hit this behaviour is described in the Appendix of the following report on my web page, 
  http://www.sgo.fi/~jussi/e3d/wp12_report_draft.pdf


tkt_uuid: d0bbe696b04c2c67433ceaccb34d707231a18f0d
type: Bug
status: Closed
resolution: Fixed
subsystem: json :: write
priority: 5 Medium
severity: Important
foundin: 1.0.2
private_contact: fe1907590219664bf7273418a757d0dd571234ee
title: json::write string doesn't escape all control characters
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: anonymous
closedate: 2456741.41949872
comment:
  json::write string simply uses string map to backslash escape characters. However, it only escapes ", \, and control characters: \b \f \n \r \t

  Json doesn't allow any control characters, they must be escaped as \uXXXX


tkt_uuid: f43d574b834ae36354621590f41a0538f870c394
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 7 High
severity: Critical
foundin: 1.15
private_contact: 2caf797de13248fb0c6ec498502ae2197d48be0f
title: Installer forgets subdir in pt
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456786.31213925
comment:
  The tcllib1.15 installer does not install the pt module correctly; it fails to copy a subdir "rde_criticl" with supporting files necessary to produce critcl parsers.

  Looking at how it is done for the doctools, textutils and dns modules, they have a special action _doc, _msg etc. I think this is a broken design - the installer should copy subfolders (or have an action which allows to specify a list of folders/files which should be copied)


tkt_uuid: a80e60deb11ab536f24d2f51fb4e39591224ca4a
type: Bug
status: Closed
resolution: Fixed
subsystem: crc
priority: 5 Medium
severity: Critical
foundin: SUM 1.1.0
private_contact: 2e7fb03fb66ed06254678661359741d8fe23ed8b
title: crc::sum returns incorrect checksum on 1K data
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456736.30215941
comment:
  Using a 1024 byte input string, the resulting checksum is incorrect.  I suspect the problem has to do with the sum exceeding 16 bits, and the return statement from ::crc::SumSysV is using a "%" operator rather than "&" to mask the output.

  Command being used:
    set ckSum [crc::sum -sysv -- $data]

    where data is a 1024 byte string.

  The correct checksum is returned if the data string is 128 bytes.


tkt_uuid: afe4366e2ea71590f59f2aeee9ee52a34b1f05d2
type: Bug
status: Closed
resolution: Fixed
subsystem: html
priority: 5 Medium
severity: Important
foundin: 1.4
private_contact: a59c367c86bd0021b564cddd65c56da974ebd28b
title: ::html::doctype fails to return valid data
cmimetype: text/plain
submitter: anonymous
assignee: andreas_kupries
closer: aku
closedate: 2456737.47048748
comment:
  The ::html::doctype was not updated to use the global namespace for the set command, and it enters an infinite loop.


tkt_uuid: ac8d016077268137980ddfef8f1ccf4d18adc3aa
type: Bug
status: Closed
resolution: Fixed
subsystem: coroutine
priority: 5 Medium
severity: Critical
foundin: 1.15
private_contact: 668a819fc68ae3df87285ba92d1fd8ef824e2d2b
title: coroutine package gets and read never worked
cmimetype: text/plain
submitter: twylite
closer: aku
closedate: 2456741.26806314
comment:
  In coroutine.tcl both ::coroutine::util::gets and ::coroutine::util::read dereference the variable 'result' on the success path after the try/on-error, but result is only defined on the error path.  As a result these procs do not work and - looking at the file history in Fossil - have never worked.

  coro_auto contains a similar bug.

  The diff below fixes the problem.  I can check this in on a branch or on trunk if that is more convenient.

  ----DIFF----
  Index: modules/coroutine/coroutine.tcl
  ==================================================================
  --- modules/coroutine/coroutine.tcl
  +++ modules/coroutine/coroutine.tcl
  @@ -179,11 +179,11 @@
       while {1} {
           set blocking [::chan configure $chan -blocking]
           ::chan configure $chan -blocking 0
   
   	try {
  -	    ::chan gets $chan line
  +	    set result [::chan gets $chan line]
   	} on error {result opts} {
               ::chan configure $chan -blocking $blocking
               return -code $result -options $opts
   	}
   
  @@ -246,26 +246,25 @@
   	while {1} {
   	    set blocking [::chan configure $chan -blocking]
   	    ::chan configure $chan -blocking 0
   
   	    try {
  -		::chan read $chan
  +		set result [::chan read $chan]
   	    } on error {result opts} {
   		::chan configure $chan -blocking $blocking
   		return -code $result -options $opts
   	    }
   
  -	    if {[fblocked $chan]} {
  +	    if {[::chan blocked $chan]} {
   		::chan event $chan readable [list [info coroutine]]
   		yield
   		::chan event $chan readable {}
   	    } else {
   		::chan configure $chan -blocking $blocking
   		append buf $result
   
   		if {[::chan eof $chan]} {
  -		    ::chan close $chan
   		    break
   		}
   	    }
   	}
       } else {
  @@ -276,11 +275,11 @@
   	while {1} {
   	    set blocking [::chan configure $chan -blocking]
   	    ::chan configure $chan -blocking 0
   
   	    try {
  -		::chan read $chan $left
  +		set result [::chan read $chan $left]
   	    } on error {result opts} {
   		::chan configure $chan -blocking $blocking
   		return -code $result -options $opts
   	    }
   
  @@ -292,11 +291,10 @@
   		::chan configure $chan -blocking $blocking
   		append buf $result
   		incr   left -[string length $result]
   
   		if {[::chan eof $chan]} {
  -		    ::chan close $chan
   		    break
   		} elseif {!$left} {
   		    break
   		}
   	    }

  ----END-DIFF----


tkt_uuid: 874dedb816a1fefbad56549ad77cf71dc382166f
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: matrix
priority: 5 Medium
severity: Minor
private_contact: 3c46e29387f7cd5d7492a3362d93bdfe60c0b978
title: Example documenation error
cmimetype: text/plain
submitter: anonymous
closer: aku
closedate: 2456741.25312314
comment:
  The examples section of the struct::matrix package has code that references [getrect] and [setrect] methods:

  % M getrect 0 0 4 4
  {{1 2 3 4 5} {5 1 2 3 4} {4 5 1 2 3} {3 4 5 1 2} {2 3 4 5 1}}

  % M setrect 1 1 {{0 0 0} {0 0 0} {0 0 0}}
  % M getrect 0 0 4 4
  {{1 2 3 4 5} {5 0 0 0 4} {4 0 0 0 3} {3 0 0 0 2} {2 3 4 5 1}}

  These methods don't exist and instead should be replaced with methods [get rect] and [set rect].


tkt_uuid: a4680273cf75b25df3741b33000e332e32c1bb35
type: Bug
status: Closed
resolution: Accepted
subsystem: html
priority: 5 Medium
severity: Minor
private_contact: a59c367c86bd0021b564cddd65c56da974ebd28b
title: ::html::meta cannot be used for normal attributes
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458660.29867096
comment:
  The existing implementation of the ::html::meta cannot be used to produce the required attributes, as specified in the HTML standard. The only attribute supported is the "name".

  Since a valid implementation must allow also the "http-equiv" and "charset" attributes, a design choice must be made to allow this to be used.


tkt_uuid: 06eef112da03bc1500b4732295ba37a3e4d0bf77
type: Patch
status: Closed
resolution: Fixed
subsystem: yaml
priority: 5 Medium
severity: Important
foundin: release version Tcllib-1.16
private_contact: e8fa720ad3d072f4d3e04516dce3ef6c61875899
title: regex missing char in _getToken proc
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456770.32126149
comment:
  Function:

  proc ::yaml::_getToken {} {
      variable data

      set reStr {^[^ \t\n,\]]+}
      set result [_getFoldedString $reStr]    
      return $result
  }

  diff:
  <     set reStr {^[^ \t\n,]+}
  ---
  >     set reStr {^[^ \t\n,\]]+}



  without the additional ']' in the regex, inline arrays with no whitespace doesn't tokenize correctly. 

  forexample:
  prefix: [*blah]

  the inline array got tokeized to 'blah]'


tkt_uuid: d4753af2ff9d904fa93d624d0b279df65ef58a09
type: Bug
status: Closed
resolution: Wont Fix
subsystem: struct :: graph
priority: 5 Medium
severity: Minor
foundin: 2.4
private_contact: ba302c5a744ad0a8e535de53c282a0121b4c2d00
title: struct::graph arcs order difference between C and Tcl
cmimetype: text/plain
submitter: anonymous
closer: aku
closedate: 2456759.37179513
comment:
  I have noticed the problem in the code generated by yeti: the code is different when tcllibc is installed, in the yytrans array.
  In yeti.tcl:
   ...
   append data "      array set yytrans {\n"
   foreach state [lsort -integer [$dfsm nodes]] {
     foreach arc [$dfsm arcs -out $state] {
       ...
     }
   }
   ...


tkt_uuid: d3b4501a6cf2dbb3d7af1cef0a94e57f2a63cdc9
type: Bug
status: Closed
resolution: Invalid
subsystem: json
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Two security flaws with json-c that may impact tcllib
cmimetype: text/plain
submitter: stwo
closer: aku
closedate: 2456759.36325098
comment:
  CVE-2013-6371 json-c: hash collision DoS
  CVE-2013-6370 json-c: buffer overflow if size_t is larger than int
  http://seclists.org/oss-sec/2014/q2/51

  These may impact tcllib?


tkt_uuid: ce17795a782c45fc1fe9d16a9f812b122c81453e
type: Bug
status: Closed
resolution: Fixed
subsystem: Installation
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Two extra, unneeded files are being installed
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: aku
closedate: 2456759.40304681
comment:
  The following two files are installed but not needed.
  json/test_support.tcl
  tar/test-support.tcl

  Consistent naming would be nice, too. :p


tkt_uuid: c21b57e4fc4db54f3b373a44749551bf21ff479c
type: Bug
status: Closed
resolution: Fixed
subsystem: coroutine
priority: 5 Medium
severity: Minor
foundin: 8.6.1
private_contact: 55805032f00760ddf84eb3f8acb077da7bef1411
title: Wrong package version in pkgIndex.tcl
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456759.35241705
comment:
  the pkgIndex.tcl file configures package number 1.1 whereas the file coroutine.tcl provides 1.1.1.
  This causes an error during package require.


tkt_uuid: c4b8162da59722c9329665e997a31780b012bb1f
type: RFE
status: Closed
resolution: Fixed
subsystem: inifile
priority: 5 Medium
severity: Important
foundin: 0.2.5
private_contact: 686cf80e6a8e5ccfa1b04fe4da7dd6d345e4d1a3
title: ::ini::open should have an option to set encoding
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456860.37408016
comment:
  As said in summary, having an option to set encoding when opening ini-file is a great deal for those who use it with non-unicode files.
  This RFE was already submitted at sourceforge, but I can't see if it is submitted here, so this is it.


tkt_uuid: ced0d60fc999b269a8809629d5954645b529999c
type: Patch
status: Closed
resolution: Fixed
subsystem: comm
priority: 5 Medium
severity: Important
foundin: unknown
private_contact: e6e0da3db38bd7f7aaef501760314ad0221f3e23
title: infinite readable events when closing the comm socket
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2456786.28392877
comment:
  [13:43]	schelte	A colleague showed me that the comm package doesn't handle a connection that is closed again without sending any data very well.
  [13:43]	schelte	There's no check for eof in the readable event handler.
  [13:45]		A limousine pulls up, and <webchain1> steps out into the crowd of waiting paparazzi.
  [13:47]	aku	schelte - I seem to remember a ticket about that recently added to the tracker. Or something similar. Was that you ?
  [13:48]	schelte	I asked my colleague to report it. He may have done.
  [13:49]	schelte	I don't see it in the tracker on core.tcl.tk though.
  [13:49]	aku	Just looked, and what I remember is https://core.tcl.tk/tcllib/tktview?name=fefcf36788
  [13:49]	aku	which comes from finland
  [13:50]	aku	schelkte - if you have demo code, can you add the ticket ?
  [13:51]		dgp doesn't want to talk anymore!
  [13:52]	schelte	That doesn't look like the same issue.
  [13:54]	schelte	The demo code is as simple as: close [socket localhost $commport]
  [13:55]	aku	And that goes into an infinite sending of readable events  from comm?!
  [13:55]	schelte	Yes.
  [13:55]	aku	Ok. Making the ticket now.


tkt_uuid: 7f082f86671e6a911a8022fcddf827e0684609d8
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: linearalgebra
priority: 8
severity: Critical
foundin: 1.1.4
private_contact: a7eb0a4e16c317ceb4aa8521757a17c4f4a651c9
title: wrong sign in some eigenvalue/eigenvector pairs from ::math::linearalgebra::eigenvectorsSVD
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457136.37165953
comment:
  The sign in some eigenvalue / eigenvector pairs seems wrong to me.
  Multiplying matrix A by a normalized eigenvector should yield the eigenvector scaled by the eigenvalue
  A * eigenvec = eigenval * eigenvec
  In some cases I got an inverted vector back
  A * eigenvec = -eigenval * eigenvec

  The following code shows the problem:

  #>---------------------------------------------
  #!/usr/local/bin/tclsh

  # add a possible local installation path
  lappend auto_path ~/.local/share/tcl
  package require math
  package require math::linearalgebra

  proc test_eigensolver {args} {
   set qdata {2.7563361585555084 0.02600440980933252 0.0 2.785766824118953 0.0 -5.542102982674461}
   puts "matrix elements qxx qxy qxz qyy qyz qzz: $qdata"

   set qtensor [::math::linearalgebra::mkMatrix 3 3 0]
   ::math::linearalgebra::setelem qtensor 0 0 [lindex $qdata 0]
   ::math::linearalgebra::setelem qtensor 0 1 [lindex $qdata 1]
   ::math::linearalgebra::setelem qtensor 0 2 [lindex $qdata 2]
   ::math::linearalgebra::setelem qtensor 1 0 [lindex $qdata 1]
   ::math::linearalgebra::setelem qtensor 1 1 [lindex $qdata 3]
   ::math::linearalgebra::setelem qtensor 1 2 [lindex $qdata 4]
   ::math::linearalgebra::setelem qtensor 2 0 [lindex $qdata 2]
   ::math::linearalgebra::setelem qtensor 2 1 [lindex $qdata 4]
   ::math::linearalgebra::setelem qtensor 2 2 [lindex $qdata 5]
   set svd_result [::math::linearalgebra::eigenvectorsSVD $qtensor]
   puts "matrix after diagonalization (eigenvectors and eigenvalues): $svd_result"
   set qvec1 [veczero]
   set qvec2 [veczero]
   set qvec3 [veczero]
   set qval  [veczero]
   set qvec1 [lreplace $qvec1 0 0 [lindex [lindex [lindex $svd_result 0] 0] 0]]
   set qvec1 [lreplace $qvec1 1 1 [lindex [lindex [lindex $svd_result 0] 1] 0]]
   set qvec1 [lreplace $qvec1 2 2 [lindex [lindex [lindex $svd_result 0] 2] 0]]
   set qvec2 [lreplace $qvec2 0 0 [lindex [lindex [lindex $svd_result 0] 0] 1]]
   set qvec2 [lreplace $qvec2 1 1 [lindex [lindex [lindex $svd_result 0] 1] 1]]
   set qvec2 [lreplace $qvec2 2 2 [lindex [lindex [lindex $svd_result 0] 2] 1]]
   set qvec3 [lreplace $qvec3 0 0 [lindex [lindex [lindex $svd_result 0] 0] 2]]
   set qvec3 [lreplace $qvec3 1 1 [lindex [lindex [lindex $svd_result 0] 1] 2]]
   set qvec3 [lreplace $qvec3 2 2 [lindex [lindex [lindex $svd_result 0] 2] 2]]
   set qval  [lindex $svd_result 1]
   puts "before checking:"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 0] [lindex $qvec2 0] [lindex $qvec3 0]]"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 1] [lindex $qvec2 1] [lindex $qvec3 1]]"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 2] [lindex $qvec2 2] [lindex $qvec3 2]]"
   puts "eigenvalues: [format "%9.3f %9.3f %9.3f" [lindex $qval  0] [lindex $qval  1] [lindex $qval  2]]"
   # workaround for the sign bug in ::math::linearalgebra::eigenvectorsSVD
   set checkval [expr {[::math::linearalgebra::dotproduct $qvec1 [::math::linearalgebra::matmul $qtensor $qvec1]] * [lindex $qval 0]}]
   if { $checkval < 0 } {
     puts stderr "sign is inverted for eigenvector/eigenvalue pair 1, will flip sign of eigenvalue"
     set qval [lreplace $qval 0 0 [expr { -[lindex $qval 0]}]]
   }
   set checkval [expr {[::math::linearalgebra::dotproduct $qvec2 [::math::linearalgebra::matmul $qtensor $qvec2]] * [lindex $qval 1]}]
   if { $checkval < 0 } {
     puts stderr "sign is inverted for eigenvector/eigenvalue pair 2, will flip sign of eigenvalue"
     set qval [lreplace $qval 1 1 [expr { -[lindex $qval 1]}]]
   }
   set checkval [expr {[::math::linearalgebra::dotproduct $qvec3 [::math::linearalgebra::matmul $qtensor $qvec3]] * [lindex $qval 2]}]
   if { $checkval < 0 } {
     puts stderr "sign is inverted for eigenvector/eigenvalue pair 3, will flip sign of eigenvalue"
     set qval [lreplace $qval 2 2 [expr { -[lindex $qval 2]}]]
   }
   puts "after checking:"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 0] [lindex $qvec2 0] [lindex $qvec3 0]]"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 1] [lindex $qvec2 1] [lindex $qvec3 1]]"
   puts "matrix     : [format "%9.3f %9.3f %9.3f" [lindex $qvec1 2] [lindex $qvec2 2] [lindex $qvec3 2]]"
   puts "eigenvalues: [format "%9.3f %9.3f %9.3f" [lindex $qval  0] [lindex $qval  1] [lindex $qval  2]]"

  }
  #---------------------------------------------------------<


tkt_uuid: c77cc35b1af898cf3b88e046c61861627017d2ff
type: Bug
status: Closed
resolution: Fixed
subsystem: crc
priority: 7 High
severity: Important
foundin: 1.1.3
private_contact: 0d5810a6d532ee60fe454fd2bdbe8e482821d713
title: ::crc::cksum severe performance issue
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456786.26885697
comment:
  The [::crc::cksum] command has severe perfomance issues with everything larger than a few KB. On my fairly perfomrant machine, calculating the checksum of a 16 KB file takes roughly one second, files larger than 128 KB take more than a minute !!

  I managed to find and fix the problem in source - I hope the diff below explains itself.


  --- cksum.tcl	2014-05-04 11:37:17.184247962 +0200
  +++ cksum_new.tcl	2014-05-04 11:30:28.472425955 +0200
  @@ -95,11 +95,15 @@
       set t $state(t)
       binary scan $data c* r
       foreach {n} $r {
  -        set t [expr {($t << 8)
  +        # Since the introduction of built-in bigInt support with Tcl 8.5, bit-
  +        # shifting $t to the left no longer overflows, keeping it 32 bits long. 
  +        # The value grows bigger and bigger instead - a severe hit on performance.
  +        # For this reason we do a bitwise AND against 0xFFFFFFFF at each step.
  +        set t [expr {0xFFFFFFFF & (($t << 8)
                        ^ [lindex $cksum_tbl [expr {
                                                    (($t >> 24) \
                                                         ^ ($n & 0xFF)) & 0xFF
  -                                             }]]}]
  +                                             }]])}]
           incr state(l)
       }
       set state(t) $t


tkt_uuid: da613292767ba06ac255bed9abbb774e8faa8e2f
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 7 High
severity: Critical
foundin: 1.15
private_contact: 2caf797de13248fb0c6ec498502ae2197d48be0f
title: Generated C code from pt interferes with C comment syntax
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456787.27414583
comment:
  If a grammer defines a symbol as alternatively being * or /, the resulting C code from the code generator contains an "*/" sequence in a comment, which terminates the comment and makes the C code invalid. For example

  leaf:    MulOp <- '*' / '/' / '.*' / './' / '\\' / '%';

  in my grammar leads to a function being generated

  static void sym_MulOp (RDE_PARAM p) {
     /*
      * /
      *     [*/]
      *     ".*"
      *     "./"
      *     [\%]
      */

      if (rde_param_i_symbol_start (p, 83)) return ;
      choice_270 (p);
      rde_param_i_symbol_done_leaf (p, 83, 82);
      return;
  }

  As a workaround, I could move the single-letter symbol % in between * and / in my specific case. (but doesn't work not for a symbol like m <- '*' / ' '/')


tkt_uuid: 466e34430366d6f03fda3bc283e5900b07183a52
type: Bug
status: Closed
resolution: Fixed
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: websocket 1.3.1
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: Default websocket loglevel too chatty, IMHO.
cmimetype: text/plain
submitter: aku
assignee: emmanuel
closer: emmanuel
closedate: 2456805.0281053
comment:
  The default loglevel of package "websocket" is "warn". This is IMHO too chatty for regular use. I would put the default level at "error" or higher.


tkt_uuid: c72748aaa1aed0eb40369697d115116b1de9e74b
type: Bug
status: Closed
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Minor
foundin: websocket 1.3.1
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: Misleading websocket protocol error message
cmimetype: text/plain
submitter: aku
assignee: emmanuel
closer: emmanuel
closedate: 2456882.08852609
comment:
  I am not sure how to classify this.
  I started working with the package as I will have talk to a websocket endpoint.
  In the test setup the endpoint is currently not available and the http package returns a 404 for it.

  This currently results in an error like

      Protocol error during WebSocket connection with ws://xxxx:5722

  To me this is misleading. There is no protocol error, as the endpoint is not there at all, and thus no handshake|protocol could be done at all.

  Note, the above is the error information I get through the handler set for the new websocket (type=error, (*)). This seems to be the proper way.

  I would like to request a different error message for this case, and possible even other http errors, to allow me as user to fully distinguish WS protocol issues from HTTP issues.

  (Ad *) Side note, this type 'error' is not documented.


tkt_uuid: 994ae08b5e2b1ceca6a762e9ca389a8d1282a2c2
type: Bug
status: Closed
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Severe
foundin: websocket 1.3.1
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: incomplete websocket error reporting
cmimetype: text/plain
submitter: aku
assignee: emmanuel
closer: emmanuel
closedate: 2456882.07966597
comment:
  While playing a bit more with websocket I cam across the error situation below (server was bad hostname, not resolvable).

  This was reported in the logger with:

  [Mon May 12 15:42:50 PDT 2014] [websocket] [error] 'Error while opening WebSocket connection to ws://XXXX: couldn't open socket: host is unreachable (Name or service not known)'

  It was NOT reported through the handler specified with 'open', nor was it reported by throwing an error.

  The only way to actually detect that there is some issue is the fact that 'websocket::open' returned an empty string. I do not know however what the issue is.

  This should truly be reported, through either handler, or thrown Tcl error.
  I will not enable debug logging in production just to know what problem to report.


tkt_uuid: 6c1c739c78301a9eccab379399d401c4b6af09af
type: Bug
status: Closed
resolution: Fixed
subsystem: dns
priority: 7 High
severity: Severe
foundin: trunk
private_contact: d22e258122ab571b058f11050b95da696e2b798f
title: dns package overwrites global variables
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456792.46965101
comment:
  Doing a "package require dns" will overwrite any existing global variables with the following names: escape host hostOrPort class type classOrType classOrTypeSpec query

  The uri::register in dns.tcl unsafely uses "set" instead of "variable" for these variable names, which is not safe to global variables even when being run inside a namespace eval.

  You can reproduce this bug with the following Tcl code:

     set ::class "test"
     puts "::class is $::class"
     package require dns
     puts "::class is $::class"

  Patch provided, will attach.


tkt_uuid: 97d451ab5cfbb208098635ba667949a90f7f769d
type: Bug
status: Closed
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: websocket 1.3.1
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: websocket client not providing the Origin header
cmimetype: text/plain
submitter: aku
assignee: emmanuel
closer: emmanuel
closedate: 2456882.09407064
comment:
  This package needs interoperability testing.

  While the websocket client code generates a number of Sec-Websocket-* keys|headers one header it does not generate is "Origin" (*).

  This header is apparently required by ws servers based on
  https://code.google.com/p/go/source/browse/websocket/?repo=net

  Without that header it returns status 403 (Forbidden).

  Servers of this type also do not set the Content-Length header in their response. This _may_ hang the http package, having it wait trying to read a body which does not come. Needs checking with the regular http package as this is something I can only truly claim for the modified http package found in stackato-cli (**)


  Side note: https://github.com/einaros/ws is a node.js websocket implementation.


  (*) Origin = Host, normally. It is a bit of a pity. This requires copying the URLmatcher part of http::geturl into websocket to get this information, i.e. replicate the parsing and validation done by the http package.



  (**) https://github.com/ActiveState/stackato-cli/tree/master/lib/http
       (Much extended debugging narrative, plus stackato-specific patches for the servers we working with, marker 'STACKATO')


tkt_uuid: ba3b0d913c430b5cb2182eedbea80eba8a6ac87a
type: Bug
status: Closed
resolution: Fixed
subsystem: general request
priority: 7 High
severity: Severe
foundin: 1.15
private_contact: df1d7fa59ae3f89054a03e83c668bbb2903d08ae
title: Allow specifying path to tclsh; pick better default tclsh
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456980.69478774
comment:
  Hello, I'm a developer with the MacPorts package management system.

  As of version 2.3.0, MacPorts incorporates a copy of tcllib. It has come to our attention that tcllib has code to find a suitable tclsh program, but that when multiple tclsh programs are found, the one that it tries to use is not necessarily one that works:

  http://core.tcl.tk/tcllib/artifact/b93d99315ce5f4758a13021bc708a54da766fd94

  For example it was reported to us that a user had installed a 3rd-party tcl package which contained a 64-bit version (tclsh8.6-64) in addition to a 32-bit version (tclsh8.6), and the user's computer was 32-bit, but tcllib chose to use the 64-bit version, which won't work.

  https://trac.macports.org/ticket/43809

  I'm hoping a better mechanism can be found to locate a suitable tclsh. Maybe check first if one called just "tclsh" is available (which would find the version included with every version of OS X, which should work), or skip executables that don't pass a simple check, such as printing their version number.


tkt_uuid: 659fec48260580797b74b9a5f05dec93856a3211
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil
priority: 6
severity: Minor
foundin: 66e07701c96b4b82486651b0920ab798ffb6d6e5
private_contact: 662c23482b0bf6a505f39e48fb7ad43af8dee4d3
title: Spurious [pid] in [fileutil::tempfile]
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456829.44409293
comment:
  [fileutil::tempfile] invokes [pid] but never uses the result.  This appears to be leftover from the old random number code from the wiki.  Suggest removing the call to [pid].


tkt_uuid: 52e14eb0b9e47f1b75b93951709d09c6a21a9c6d
type: Bug
status: Closed
resolution: Fixed
subsystem: logger
priority: 5 Medium
severity: Minor
foundin: 1.3
private_contact: d4456006aa793a9b5e98c8665afe28d8d71968fe
title: logger::utils applyAppender documentation incorrect
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456829.30162169
comment:
  Documentation at http://tcllib.sourceforge.net/doc/loggerUtils.html function ::logger::utils::applyAppender does not match the actual function as defined in loggerUtils.tcl file.

  The -conversionPattern is incorrect and should be replaced with description of the missing switch -appenderArgs.

  An example should be added that uses the -appenderArgs as its use is nonintutive.

  For example, here's a working example,

  logger::utils::applyAppender -serviceCmd $log -appender console -appenderArgs {-conversionPattern {\[%M\] \[%p\] - %m}}

  Note: Backslashes for the braces were required else function throws an error.

  But the key concept for the -appenderArgs switch is that its value must be a list.

  With that said, logger::utils is a great addition to the logger package. Thank you.

  best regards,

  Mark


tkt_uuid: f03637392d0d8abee2eb50b8b42fe3830b5a3095
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 7 High
severity: Minor
foundin: 1.4.18
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Unhelpful failure mode in doctools
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456832.3379995
comment:
  The ::doctools::LookupFormat command has a feature which allows for the developer to specify a custom format by having a file with the appropriate name in the folder the pwd of the Tcl interpreter.

  Unfortunately, if a directory happens to have the name, of say "html", the LookupFormat command returns the directory, which causes a nasty error, with a less than helpful message.

  1) I would be nice for ::doctools::LookupFormat to restrict it's search to files, and ignore directories.

  2) when ::doctools::_configure fails, in the -format branch of the switch (around line 367 in modules/doctools/doctools.tcl) it should include the errorInfo in the error it throws, as well as the rest of the tracing info.


tkt_uuid: 03f5d49c12913f3952b2b896005b0b0f744463bb
type: Patch
status: Closed
resolution: Fixed
subsystem: ncgi
priority: 6
severity: Important
foundin: 1.16
private_contact: eb5a509309d4ff62bdd05009993eace4edd25f7e
title: ncgi::redirect uri regexp fix
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456839.22486503
comment:
  The regsub that extracts request_uri from env(REQUEST_URI) fails to discard the query string if the query string contains a "/".

  e.g. if the current page is "http://foo.com/cgi-bin/view.tcl?path=/a/b/c"
  ... and we try to do "ncgi::redirect login.tcl"
  we end up at "http://foo.com/cgi-bin/view.tcl?path=/a/b/login.tcl"

  with the patch we get to "http://foo.com/cgi-bin/login.tcl"

  Why use custom regular expressions in ncgi when we have uri::split?

  --- ncgi.tcl.orig	2014-06-27 15:16:58.000000000 +1000
  +++ ncgi.tcl	2014-06-27 15:24:37.000000000 +1000
  @@ -28,6 +28,7 @@
   # We use newer string routines
   package require Tcl 8.4
   package require fileutil ; # Required by importFile.
  +package require uri

   package provide ncgi 1.4.2

  @@ -728,7 +729,7 @@

   	if {[info exists env(REQUEST_URI)]} {
   	    # Not all servers have the leading protocol spec
  -	    regsub -- {^https?://[^/]*/} $env(REQUEST_URI) / request_uri
  +        set request_uri /[dict get [uri::split $env(REQUEST_URI)] path]
   	} elseif {[info exists env(SCRIPT_NAME)]} {
   	    set request_uri $env(SCRIPT_NAME)
   	} else {


tkt_uuid: d679822510fac5859ab3cf093527cc1ad5b93210
type: Bug
status: Closed
resolution: Fixed
subsystem: uuid
priority: 7 High
severity: Important
foundin: 1.15
private_contact: ba69b1b3951296adee358cee3a51d0a1631f63cc
title: uuid (illegally) accesses an uplevel variable
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456839.26065552
comment:
  Repeat with:

  #!/usr/bin/tclsh
  array set e {any words to demonstrate the problem}
  package require uuid
  puts stdout "uuid = [::uuid::uuid generate]"


tkt_uuid: c6cb52589401fc887785e76fe6a0a5fbe273b224
type: Patch
status: Closed
resolution: Invalid
subsystem: pt (parsetools)
priority: 5 Medium
severity: Critical
private_contact: 438e59f1f1c891b29d2528ed82d1e629cecc6336
title: wrong variable used in strlen
cmimetype: text/plain
submitter: anonymous
closer: anonymous
closedate: 2456876.85009515
comment:
  Index: modules/pt/rde_critcl/tc.c
  ==================================================================
  --- modules/pt/rde_critcl/tc.c
  +++ modules/pt/rde_critcl/tc.c
  @@ -68,11 +68,11 @@
       char* ch;
       int clen;
       Tcl_UniChar uni;
   
       if (len < 0) {
  -	len = strlen (ch);
  +	len = strlen (string);
       }
   
       /*
        * Extend character buffer to hold the new string, and copy the string in.
        */


tkt_uuid: fb97352ad918fa08578a2c0cbbd2af38831cb32a
type: Patch
status: Open
resolution: None
subsystem: pt (parsetools)
priority: 6
severity: Minor
private_contact: 438e59f1f1c891b29d2528ed82d1e629cecc6336
title: chase compiler warnings
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Most of the chunks are related to casting variables to void* for use in rde_stack_push or Tcl_*Hash* function calls. There are a few removals of unused variables and (void)var; of unused parameters.


tkt_uuid: 577ed0d10b9d631678921416d55805d80c4c6bd2
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: 1.3
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: Variables not unset unless ::websocket::upgrade not invoked
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  ::websocket::test creates Client variable to communicate request values to ::websocket::upgrade. Only the latter unsets this temporary variable. Failing to invoke ::websocket::upgrade, creates a memory leak as requests come in.

  In my opinion if there is no reason to invoke ::websocket::test without later upgrading, both should be merged in a single procedure. Otherwise no temporary variables should be created.


tkt_uuid: bb5f70d7ddc9d07ae9000af2715f430b559c558c
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: 1.3
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: Client's sub-protocol preference not respected
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  RFC 6455 indicates that sub-protocols specified by clients (Sec-Websocket-Protocol) come ordered by preference.

  The WebSocket library currently does not respect the client's preference, nor allows servers to specify which subprotocol to choose when multiple can satisfy the request.

  In my opinion, the WebSocket library should default to respecting the client preference, and should allow servers to override that preference by specifying priorities for different handlers.

  [1]: http://tools.ietf.org/html/rfc6455#section-4.1, client handshake requirements, item 10.


tkt_uuid: b41b6f76b045c932e10f2504295cf98606835663
type: Bug
status: Open
resolution: None
subsystem: ftp
priority: 5 Medium
severity: Critical
foundin: 8.6
private_contact: bac48e30a486569439a2c7b74f154261e52e13f2
title: No IPv6 support for FTP
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Hello,

  There is no IPv6 support for FTP package available in TCL standard library.
  requesting you to add the support ASAP.

  Thank you.


tkt_uuid: a01e30ff4005d7cc44cf2cf5f018206339c0de36
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Minor
private_contact: dd929ddfa359b57543e6356645aa630cf243bb0e
title: websocket documentation still lacking in places
cmimetype: text/plain
submitter: emmanuel
assignee: emmanuel
closer: nobody
comment:
  The documentation of the websocket module still is incomplete. For example: 

  * the type 'error' is not documented.


tkt_uuid: 9a36e053beb105193241ccfce61091a3d6ffcc24
type: Bug
status: Closed
resolution: Fixed
subsystem: tcl :: chan :: *
priority: 5 Medium
severity: Minor
foundin: 1
private_contact: c355fe76647598e366b7455160fc6b2fe290cec1
title: error in "tcl::transform::zlib"
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456885.19667422
comment:
  Script that generate error:

  package require tcl::transform::zlib
  set f [open file r+]
  tcl::transform::zlib $f

  return:

  wrong # args: should be "zlib stream mode ?-option value...?"


tkt_uuid: ff8428ae1558b16ec5e717f143582aa8f4cd35f2
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil :: magic
priority: 5 Medium
severity: Minor
foundin: 1.0.2
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: fileutil::magic::mimetype does not recognize HTML5 files
cmimetype: text/plain
submitter: anonymous
assignee: pooryorick
closer: pooryorick
closedate: 2458352.77316216
comment:
  HTML5 doctype is not recognized by fileutil::magic::mimetype.

  Reproducible with following steps
  1. Create a file 'file.html' with the following content
  ~~~
  <!DOCTYPE html>
  <html>
  </html>
  ~~~

  2. Run the following script:

      $ tclsh <<EOF
      package require fileutil::magic::mimetype;
      puts [::fileutil::magic::mimetype file.html]
      EOF
      {exported SGML document text}

  The file is not recognized as 'text/html'.

  The cause could be excessive escaping in the generated
  recognizer, see the escaped space inside the quoted string
  in the rule that should have matched:
  ~~~
      if {[S 0 == {<!DOCTYPE\ html} ]} {emit text/html}
  ~~~


tkt_uuid: e3a6e3e02a9a787d3bac706513e7d06db50246ba
type: Bug
status: Open
resolution: None
subsystem: huddle
priority: 5 Medium
severity: Critical
private_contact: 9dffd9dca08d8cf29375b31fd4546e721bbedab8
title: Huddle: creating a list with quote as element fails
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  The following fails:

  package require huddle
  huddle list \"

  unmatched open quote in list
      while executing
  "lindex $arg 0"
      (procedure "isHuddle" line 2)
      invoked from within
  "isHuddle $src"
      (procedure "::huddle::to_node" line 3)
      invoked from within
  "::huddle::$command {*}$args"
      (procedure "huddle" line 6)
      invoked from within
  "huddle to_node $value"
      (procedure "::huddle::_list_setting" line 58)
      invoked from within
  "$huddle::methods($command) $command {*}$args"
      (procedure "huddle" line 4)
      invoked from within
  "huddle list \""


tkt_uuid: daa83d2edf59e451d87573bbc4a7442cce1c5c8d
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Important
private_contact: c1589a2fa4fc7951c4aba10439d3b95af55c3a63
title: uri::urn doesn't handle Unicode properly
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456903.36043541
comment:
  uri::urn::quote 你好                 ;# → %4F60%597D INCORRECT
  uri::urn::unquote %4F60%597D         ;# → O60Y7D CORRECT
  uri::urn::unquote %E4%BD%A0%E5%A5%BD ;# returns messy string, though what I provide is correct.


tkt_uuid: bb0137b0f2e004fcfb23a32f6e6659efe553ef34
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Some pt test failures
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: aku
closedate: 2456899.43955957
comment:
  pt-cparam-config-critcl-3.[0-11]
  pt-cparam-config-tea-3.[0-11]

  Result/wanted diff:

          rde_tc_get (RDE_TC tc, int at, char** ch, long int* len)
          {
  -           long int  oc, off, end;
  +           long int  oc, off, top, end;

          rde_tc_get_s (RDE_TC tc, int at, int last, char** ch, long int* len)
          {
  -           long int  oc, off, end;
  +           long int  oc, off, top, end;

          rde_param_i_value_reduce (RDE_PARAM p, long int s)
          {
              Tcl_Obj*  newsv;
  -           int       i, j;
  +           int       oc, i, j;


tkt_uuid: 6613fe7123f282fa3ff1c839315ab5220f954edf
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Lack of TclOO yields errors in the pt and tar tests
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: aku
closedate: 2456903.30125022
comment:
  Test constraints are needed?

  Snippets from test log:

  @@ Testsuite modules/pt/pt_pgen.test
  ...
  > pure Tcl
      Aborting the tests found in "pt_pgen.test"
      Error in pt_rdengine_oo.tcl: can't find package TclOO
  SETUP Error (Support): 
  SETUP Error (Support):     while executing
  SETUP Error (Support): "useLocal pt_rdengine_oo.tcl           pt::rde::oo"


  @@ Testsuite modules/tar/tar.test
  ...
  - tcllib::testutils 1.2
      Aborting the tests found in "tar.test"
      Error in memchan.tcl: can't find package TclOO
  SETUP Error (Support): 
  SETUP Error (Support):     while executing
  SETUP Error (Support): "use          virtchannel_base/memchan.tcl tcl::chan::memchan"


tkt_uuid: 1449d9f965dcca69b667ae9f4ef9e96e97ea9237
type: Bug
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Minor
foundin: 1.3.3
private_contact: c355fe76647598e366b7455160fc6b2fe290cec1
title: dict2json problem
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  command:

  dict2json [list fName Jarek lName John Age 18]

  creates incorrect json.

  Probably problem is with line:

  ...
  if {0 && ![string is double -strict $val]
  ...

  Should be:

  ...
  if {1 && ![string is double -strict $val]
  ...


tkt_uuid: c601e3dc6c1a43c7ce2fbacf5f92a323991a6f69
type: Patch
status: Open
resolution: None
subsystem: huddle
priority: 5 Medium
severity: Important
foundin: 0.1.5
private_contact: c355fe76647598e366b7455160fc6b2fe290cec1
title: String is double does not conform to JSON specification
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
   ::huddle::jsondump command has bad json export values like 00456.
  JSON specification says this is STRING but for huddle this is NUMBER.

  package require huddle
  set bb [huddle create a b c 00.34]
  huddle jsondump $bb

  returns bad json:

  {
    "a": "b",
    "c": 00.34
  }

  Patch solves the problem:

  {
    "a": "b",
    "c": "00.34"
  }


tkt_uuid: 358a88716e32b452115b8556208fd2ee42be8496
type: Patch
status: Closed
resolution: Accepted
subsystem: aes
priority: 5 Medium
severity: Minor
private_contact: 438e59f1f1c891b29d2528ed82d1e629cecc6336
title: slight performance improvement in CBC mode
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456923.51378765
comment:
  This patch modifies aes' state to keep the IV as a list of integers instead of their binary representation.

  This spares one [binary scan] per block (see ::aes::EncryptBlock and ::aes::DecryptBlock). The cost is an additional [binary scan] in ::aes::Init and ::aes::Reset, but since these functions are called much more rarely than [En|De]cryptBlock, it's worth doing: my tests have shown a gain of ~ 3% in speed.

  Also, the last chunk fixes the comment block for ::aes::Decrypt.

  [moved the inlined patch into a proper attachment]


tkt_uuid: fe7a0e0a3a1efe3613eddb6de175b155853f2abc
type: Bug
status: Closed
resolution: Fixed
subsystem: oo::util
priority: 5 Medium
severity: Minor
foundin: 1.2
private_contact: d3341d818ad311ff7ac50c5a3819416c817c825a
title: oo::class.Delegate create conflicts with megawidget.tcl
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457184.25850314
comment:
  % source ${tcllib}/modules/ooutil/ooutil.tcl
  % source ${tk}/library/megawidget.tcl
  wrong # args: should be "::tk::Megawidget create name ?script?"
      while executing
  "::tk::Megawidget create ::tk::SimpleWidget {} {
      variable w hull options
      method GetSpecs {} {
          return {
              {-cursor cursor Cursor {}}
              {-..."
      (file "megawidget.tcl" line 100)
      invoked from within
  "source megawidget.tcl"

  The offending definition seems to be [1] which conflicts with tk::Megawidget's constructor [2].

  This would appear an easy fix if not for the oo::define on line 100, which is decidedly shady.

  [1] http://core.tcl.tk/tcllib/artifact/f93e0d204919b02d9a57e268aedc966d41804b28?ln=93-111
  [2] http://core.tcl.tk/tk/artifact/fb4d68226f573c9a37badffb3b64f23221ef6031?ln=15-29


tkt_uuid: 5d23e45b0ec5a81e67aa1f492339a31e4c8b4ada
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 7 High
severity: Important
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: Websocket keys should not be wrapped
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  ::base64::encode defaults to line folding. Make sure WebSocket keys are not folded.

  -------- >8 --------

  commit 4ed0887b50c262df6b1477d92b950d0be16943d6
  Author: Adrián Medraño Calvo <amcalvo@prs.de>
  Date:   Mon Sep 22 17:35:00 2014 +0200

      [ws]: Make sure not to wrap the WebSocket key

  diff --git a/src/websocket.tcl b/src/websocket.tcl
  index 6d60537..a9e0624 100644
  --- a/src/websocket.tcl
  +++ b/src/websocket.tcl
  @@ -1434,7 +1434,7 @@ proc ::websocket::open { url handler args } {
       for { set i 0 } { $i < 4 } { incr i } {
           append OPEN(nonce) [binary format Iu [expr {int(rand()*4294967296)}]]
       }
  -    set OPEN(nonce) [::base64::encode $OPEN(nonce)]
  +    set OPEN(nonce) [::base64::encode -maxlen 0 $OPEN(nonce)]
       set HDR(Sec-WebSocket-Key) $OPEN(nonce)
       set HDR(Sec-WebSocket-Protocol) [join $protos ", "]
       set HDR(Sec-WebSocket-Version) $WS(ws_version)
  @@ -1652,7 +1652,7 @@ proc ::websocket::configure { sock args } {
   proc ::websocket::sec-websocket-accept { key } {
       variable WS
       set sec ${key}$WS(ws_magic)
  -    return [::base64::encode [sha1::sha1 -bin $sec]]
  +    return [::base64::encode -maxlen 0 [sha1::sha1 -bin $sec]]
   }
   
   # ::websocket::SplitCommaSeparated -- Extract elements from comma-separated headers


tkt_uuid: dec864a3b5e7f7092de085d0b090bb66998141b8
type: RFE
status: Open
resolution: None
subsystem: otp
priority: 5 Medium
severity: Cosmetic
foundin: 1.16
private_contact: 927e32c76f2d244b3d9148c34a6991f9c87fcfe7
title: Example ::tcl::transform::otp
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Please could you provide an example how to use ::tcl::transform::otp? It would be great to show a short tcl program how to encrypt a file. Thanks a lot.


tkt_uuid: 3553854a2b7f2112b87c97d8fa6e699bfbe52275
type: Patch
status: Open
resolution: None
subsystem: zip
priority: 5 Medium
severity: Minor
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: New version of zipfile::encode and zipfile::decode for 8.6
cmimetype: text/plain
submitter: hypnotoad
closer: nobody
comment:
  I have posted a new version of the zipfile::encode and zipfile::decode packages that exploit the native zlib capacities of the Tcl core.

  The new zipfile::encode uses an entirely new algorithm swiped from the Wiki, refined, and tested under OSX and Windows. 

  I am using the code now in production, but it could certainly use a review and a version pump.


tkt_uuid: 746d0abb21c653e52cbf971697c16869934b7d27
type: Patch
status: Closed
resolution: Accepted
subsystem: oauth
priority: 5 Medium
severity: Important
foundin: 1
private_contact: 7e2c788c5b6838d0219e72072fb388da945311ff
title: modified oauth.tcl for use tls
cmimetype: text/plain
submitter: hxm
assignee: aku
closer: aku
closedate: 2456953.49724297
comment:
  Due to POODLE (Padding Oracle On Downloaded Legacy Encryption) SSLv3 is being disabled in all servers. This update configures tls package to use tls instead.

  Adding at line #35 this:
  tls::init -tls1 1


tkt_uuid: 02205fcbd8d2b6ff50458dd29ec4f95ac65981a4
type: Bug
status: Closed
resolution: Works For Me
subsystem: mime
priority: 3 Low
severity: Severe
foundin: 1.16
private_contact: 186ea792fddcace8a38d57ce9e980f28dc5324eb
title: mime::initialize broken in newest tcllib version
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: pooryorick
closedate: 2458359.70636416
comment:
  "mime" should be able to not only build but also parse multipart messages. This simple test (taken from tclllibs mime.test) should work, but it does not in the latest version of mime (1.6)/tcllib (1.16). It throws an error. To verify this, I downgraded the mime package to 1.5.4, where this works like a charm.

  <<test script moved into a ticket attachment>>


tkt_uuid: cf5df74f40b8af12bde47e4415ca86b188a2c411
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Minor
foundin: 1.2.4
private_contact: 9546e9877f1a8899e25a89082561ee694e7fb402
title: uri package regexps for URI incorrect
cmimetype: text/plain
submitter: anonymous
closer: kjnash
closedate: 2457739.27220093
comment:
  The following regexp or equivalent is used in multiple places to match a URI

  {^([A-Za-z0-9+.-][A-Za-z0-9+.-]*):}

  However RFC 3986 seems to imply first letter must be alphabetic, not numeric or +,.,-

  Not sure whether this is a bug or intentional because of some non-conformant schemes.

  /Ashok


tkt_uuid: 0a3d5dfe5251ff916c39ef1a8b28282a8dcc6d7e
type: Bug
status: Closed
resolution: Fixed
subsystem: crc
priority: 5 Medium
severity: Minor
foundin: 1.1.1
private_contact: f2454e34878277d1c470b4a35f740f374a52b107
title: crc::sum -sysv does not return cannonical value
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456994.33234424
comment:
  crc::sum -sysv does not return the same values as SysV "sum"

  The actual algorithm for SysV "sum" isn't well documented, but the cannonical source code for the heirloom "sum.c":

  http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/sum/sum.c?view=markup

  Performs folding (lines 117 and 118) to reduce the 32-bit internal representation to a 16-bit return value rather than the truncation we do right now.

  http://stackoverflow.com/users/588079/gitaarlab  reported the issue

  Patch to code (not documentation) attached


tkt_uuid: fef66e4953d95b97c3dda0bbe35f746b511e76dd
type: RFE
status: Closed
resolution: Accepted
subsystem: cmdline
priority: 5 Medium
severity: Minor
foundin: cmdline 1.3.3
private_contact: bec9868c8915cd8cf17c0a2a251475c6f63efc38
title: cmdline - Add support for options format "[-]-opt[=val]"
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2456994.34977307
comment:
  Q: Why add --options[=value] support?
  A: I want to rewrite some tools completed by bash with tcl,
     but cmdline can not support orig "--option=val" format,
     so created this patch


tkt_uuid: 685345eb4d46207d089d2619616339a23298ddff
type: RFE
status: Open
resolution: None
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 1.16
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: Idea for documentation index: By command name, map to module/package(s)
cmimetype: text/plain
submitter: aku
closer: nobody
comment:
  Might be useful to extend doctools/dtp/dtplite to generate an index mapping from command names to the module/package defining it. In HTML it would link to the proper manpage.

  Note that index should possibly have a page based on just the last name of the command, without the parent namespaces.

  This might be a special form of keyword index.
  Actually I am quite sure that it is.

  This puts its implementation into the application layer, i.e. "dtplite" (and "sak localdoc").

  The really interesting point is when it comes to overarching documentation for multiple packages and merging them. Not a bundle like Tcllib where the packages are all present at generation time. But a larger help system where packages are added/removed incrementally, requiring updates to such indices.


tkt_uuid: 665fbc24eb7e2726ac0752a5dff02d90894fc6df
type: Bug
status: Open
resolution: None
subsystem: snit
priority: 5 Medium
severity: Minor
foundin: 2.3.2
private_contact: b86df94c4ad221bd6b7042dd14466c8e5949ff7e
title: error in destructor hides error in constructor
cmimetype: text/plain
submitter: anonymous
assignee: wduquette
closer: nobody
comment:
  Error that occurs in destructor overrides error from constructor, so I am unable to get stack trace or error message from original error.

  Example:

  package require Tcl 8.5
  package require snit

  snit::type Test {

      constructor {} {
          error "ctor error"
      }

      destructor {
          error "dtor error"
      }

  }

  catch {Test create %AUTO%} err opts
  puts err=$err
  puts opts=$opts

  Execution result:

  $ tclsh8.5 snit-bug.tcl
  err=dtor error
  opts=-code 1 -level 0 -errorcode NONE -errorinfo {dtor error
      while executing
  "error "dtor error""
      (procedure "::Test::Snit_destructor" line 4)
      invoked from within
  "${type}::Snit_destructor $type $selfns $win $instance"
      (procedure "::snit::RT.DestroyObject" line 16)
      invoked from within
  "::snit::RT.DestroyObject $type $selfns $name"
      (procedure "::snit::RT.type.typemethod.create" line 55)
      invoked from within
  "Test create %AUTO%"} -errorline 1

  There are no any information about "ctor error".

  I suggest to add constructor error and stack trace to destructor error to provide more useful information for error analysis.


tkt_uuid: 8c587f8f3380a3cf0ae7ad5578fc5c9ef88ff10a
type: RFE
status: Open
resolution: None
subsystem: Development Tools
priority: 5 Medium
severity: Cosmetic
foundin: 0.1
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Combine information from /support into /modules
cmimetype: text/plain
submitter: hypnotoad
closer: nobody
comment:
  Tcllib currently maintains two separate file structures: /modules (where the implementations for modules live) and /support (where sak maintains it's indices.)

  I am trying to adapt a similar structure for taolib (a collection of TclOO classes) and taotk (a megawidget framework built around tao.) I also have been working on adapting some of my tools in odie to be distributed in tcllib.

  Trying to find out all of the proper places to index a new package is somewhat frustrating. I also find that tcllib's SAK make quantum assumptions about the structure of a package. What I would like to see instead is more of a plugin architecture, where each module provides a ".sak" script which collects all of the index information in one shot. This would also be an excellent place to tweaks to documentation, generate C implementations for distribution in the teapot, etc.


tkt_uuid: 1cc32b469555cc025a4cae3d181d5c6270c90073
type: RFE
status: Closed
resolution: Out of Date
subsystem: sasl
priority: 5 Medium
severity: Minor
foundin: 1.3
title: Support SCRAM-SHA-1 and perhaps generic SCRAM
cmimetype: text/x-fossil-wiki
submitter: anonymous
closer: aku
closedate: 2457038.31352543
comment:
  Please implement SCRAM in the SASL module. It implements challenge-response authentication and improves upon the CRAM-MD5 and DIGEST-MD5 methods. It can use an arbitrary hash function, although currently only SHA-1 seems to be widely supported (but since SHA-1 is broken, it might be a good idea to implement SCRAM-SHA-256 at the same time, or perhaps add a parameter through which the hash function can be selected).

  It is defined in [http://tools.ietf.org/html/rfc5802|RFC 5802]. [http://tools.ietf.org/html/rfc5802#page-27|Appendices A and B] of the RFC explain in detail how it improves upon the previous methods.


tkt_uuid: 4565d1598d08bcabd1402922b05c804a107b3991
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 7 High
severity: Important
foundin: 1.4
title: Type change from "request" in 1.3.1 to "connect" in 1.4
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  Incompatibility *** When a new connection is established, version 1.3.1 of the WebSocket Library sent a message type of "request" via "Push $sock request [list $Client(path) $Client(query)]" line 494. In 1.4 it sends a message type of "connect".

  Scripts that rely on the message type of "request" break but modifying it to "connect" restores functionality.


tkt_uuid: 2df194042b2acd13c60b0dd92cdf55c1a0ef3bde
type: Bug
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Minor
foundin: 1.3.3
private_contact: 4d3bc24d727f6c89fb1509fef02f21887282efcc
title: json2dict does not always produce a dictionary
cmimetype: text/plain
submitter: nmadden
assignee: nobody
closer: nobody
comment:
  The json::json2dict procedure is named and documented as if it produces a dictionary output in all cases. This is incorrect, as per these examples where the output is a string/number/list:

  % package require json
  1.3.3
  % json::json2dict {true}
  true
  % json::json2dict {1234.45}
  1234.45
  % json::json2dict {"Hello, World!"}
  Hello, World!
  % json::json2dict {[1,2,3,4]}
  1 2 3 4

  The documentation (and ideally the name) should be updated to make clear that it only returns a dictionary if the input is a JSON object, and that the caller *must know* the type of JSON data being parsed in order to know how to interpret the result correctly. I have seen several questions on TkChat and c.l.t that suggest that this is confusing people.


tkt_uuid: 9853e83aee1da01f1868bedd23d58698c5946678
type: RFE
status: Open
resolution: None
subsystem: tcllib: request for new module
priority: 7 High
severity: Minor
private_contact: 194c9ef8edbd9a57ef36f4f18fde1d57ce26e1e5
title: Add the "browse" package from stackato-cli
cmimetype: text/plain
submitter: aku
assignee: aku
closer: nobody
comment:
  Please add the package
      https://github.com/ActiveState/stackato-cli/tree/master/lib/browse
  to Tcllib. Cross-platform portable opening of a browser from code.


tkt_uuid: 52b764e4dd9a4e9b939bc228379e47fbc758ca3a
type: Bug
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Important
foundin: json::write 1.0.3, json 1.3.3
private_contact: 5cb1225ab872b6d12e7ab3a1e9a1fd2e3fa22e82
title: json2dict incorrectly adds braces to strings starting with $
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  json2dict turns an array into a nested list when one item starts with $. $ should not have special meaning in JSON, so I am not sure what happens here. Steps to reproduce:

  30 % set var [json::write string \$::x ]
  "$::x"
  31 % set json [json::write array \"length\" $var]
  ["length","$::x"]
  32 % set dict [json::json2dict $json]
  length {$::x}


tkt_uuid: 09110adc430de8c91d26015f9697cdd099755e63
type: Bug
status: Closed
resolution: Fixed
subsystem: html
priority: 9 Immediate
severity: Critical
foundin: all
private_contact: 37918056d323dc69a2f76cecc85476189094f3b8
title: Cross-Site-Scripting (XSS) in html::textarea
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457080.31074939
comment:
  Overview:

     Applications using tcllib's ::html::textarea functions are vulnerable to
     Cross-Site-Scripting. This function is usually used to programmatically add
     an HTML <textarea> to the output stream of a CGI script.

     No publicly available software has been found to be vulnerable. However it is
     suspected that many non-public Tcl web applications using the
     ::html::textarea function are in operation.

  Details:

     User supplied input is directly inserted into the <textarea> as default
     value, e.g. a textarea named 'ta' with a parameter of ta=XXX results in
     `<textarea>XXX</textarea>`

     This can be used to break out of the <textarea>-context and insert arbitrary
     HTML content such as <script>-Tags.

     The attack is possible using HTTP GET requests as well as POST and multipart
     form encoded POST requests.

  Code:

     [http://core.tcl.tk/tcllib/artifact/9a43f5efda2b74a5e61b60f261afdaf9ce1f1221?ln=914-919]

  Proof of Concept:

     test.cgi

    #!/usr/bin/env tclsh
    package require ncgi
    package require html
    
    ::ncgi::parse
    ::ncgi::header
    puts [::html::textarea ta]

     http://example.com/test.cgi?ta=%3C/textarea%3E%3Cscript%3Ealert%281%29%3C%2fscript%3E

  Recommendation:

     The input value should be properly HTML-escaped.

     In the meantime, a quick application level bugfix would be to encode the
     input variable in question manually. Example with 'ta' as name:

    set ::ncgi::value(ta) [::html::quoteFormValue [::ncgi::value ta {}]]


tkt_uuid: 7446477f899a967a87ace5b487c595073f12df29
type: Bug
status: Open
resolution: None
subsystem: tar
priority: 5 Medium
severity: Minor
foundin: 0.10
private_contact: e772265a92eaed611b06a9680f167ab849f5e57f
title: tar package: issues with long file name
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  I am having some issues with the function ::tar::add

  My file name I want to add is really long and the ::tar::add is complaining “path name cannot be split into prefix and name”

  Can you please help?


  The file name I am using is

  fo_STT_D1_T25_VCMAX_VIOMAX_VOTNOM_F533_CFG0_LN4_5_6_7_M1v2_LNRVS0_DIFF1_DL036_DL136_NOISEquiet_DT201501261449_1_COUNT0.txt

  Thank You
  Amit


tkt_uuid: f08453f77da415e4436a05281f47e94e056f6225
type: Bug
status: Closed
resolution: Fixed
subsystem: textutil
priority: 5 Medium
severity: Minor
foundin: 1.16
private_contact: 4fc15a9fd36528d4bf38dcb7fcef28bbd405fde3
title: textutil::adjust in 1.16 contains an off-by-one bug
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457070.31018624
comment:
  TclLib v 1.16's textutil::adjust contains an off by one bug in the -strictlength true handling code.

  If a string of length X is "adjusted" with a -length of X-1 and -strictlength true, the word split routine returns two lines, the first with the full X length word, the second empty.  It should return the first line with X-1 characters and the second line with a single character.

  Demo code:

  % package require textutil
  0.8
  % set txt [string repeat A 25]
  AAAAAAAAAAAAAAAAAAAAAAAAA
  % textutil::adjust $txt -length 24 -strictlength true
  AAAAAAAAAAAAAAAAAAAAAAAAA

  % 


  This patch fixes the issue on my local copy:

  --- adjust.tcl.orig     2015-02-16 12:01:26.021847206 -0500
  +++ adjust.tcl  2015-02-16 12:13:57.743670685 -0500
  @@ -201,9 +201,9 @@
              # cut word into two pieces
              set w2 $w
   
  -           set over [expr {$pos+2+$wLen-$Length}]
  -           set w3   [string range $w2 0 $Length]
  -           set w4   [string range $w2 [expr {$Length+1}] end]
  +           set over [expr {$pos+2+$wLen-$Length-1}]
  +           set w3   [string range $w2 0 $Length-1]
  +           set w4   [string range $w2 [expr {$Length}] end]
   
              set x [lreplace $words $cnt $cnt $w4]
              set words [linsert $x $cnt $w3 ]

  Demo after patching:

  % package require textutil
  0.8
  % set txt [string repeat A 25]
  AAAAAAAAAAAAAAAAAAAAAAAAA
  % textutil::adjust $txt -length 24 -strictlength true
  AAAAAAAAAAAAAAAAAAAAAAAA
  A
  %


tkt_uuid: 8e643b5d6606d09f931605cec3c5770e6459d06e
type: Patch
status: Closed
resolution: Fixed
subsystem: coroutine
priority: 5 Medium
severity: Minor
foundin: 1.1
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: wrong error message for coroutine gets
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457078.47330986
comment:
  Wrong error message for [::coroutine::util::gets].

  Actual: can not find channel named ""
  Expected: wrong # args: should be "gets channelId ?varName?"

  Same for [::coroutine::auto::wrap_gets] (no patch provided).

  Patch:
  --- coroutine.tcl       2015-02-18 08:25:32.523968146 +0100
  +++ coroutine.tcl       2015-02-18 08:58:40.462966438 +0100
  @@ -158,16 +158,19 @@
       # Acceptable syntax:
       # * gets CHAN ?VARNAME?

  -    if {[llength $args] > 2} {
  -       # Calling the builtin gets command with the bogus arguments
  -       # gives us the necessary error with the proper message.
  -       tailcall ::chan gets {*}$args
  -    } elseif {[llength $args] == 2} {
  -       lassign $args chan varname
  -        upvar 1 $varname line
  -    } else {
  -       # llength args == 1
  -       lassign $args chan
  +    switch [llength $args] {
  +        1 {
  +            lassign $args chan
  +        }
  +        2 {
  +            lassign $args chan varname
  +            upvar 1 $varname line
  +        }
  +        default {
  +            # Calling the builtin gets command with the bogus arguments
  +            # gives us the necessary error with the proper message.
  +            tailcall [namespace current]::core_gets {*}$args
  +        }
       }

       # Loop until we have a complete line. Yield to the event loop


tkt_uuid: 26adce0902d55a292e49b71d05a6e68ea75cafb0
type: Patch
status: Closed
resolution: Duplicate
subsystem: coroutine
priority: 1 Zero
severity: Severe
foundin: 1.1
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: coroutine::auto breaks ::unknown
cmimetype: text/plain
submitter: anonymous
closer: anonymous
closedate: 2457072.17820433
comment:
  symptom: endless recursion when ::unknown is implicitly invoked after package require coroutine::auto.
  ::unknown -> global -> ::::core_global -> ::unknown

  Patch:
  Shouldn't _all_ [namespace current] inside proc be replaced by hard-coded ::coroutine::auto, e.g. in line 37? (13 of 17 instances to be replaced)

  reproduce with:
  #!/usr/bin/env tclsh
  package require Tcl 8.6
  package require coroutine::auto
  non_existing_proc


tkt_uuid: 510c9fce1bf5129195afea5e366cac315aa48e42
type: RFE
status: Closed
resolution: Accepted
subsystem: ip
priority: 7 High
severity: Minor
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: Additional commands for IP address manipulation
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2457128.37590103
comment:
  From a conversation on comp.lang.tcl about incrementing ipv6 addresses.
  Code attached

  https://groups.google.com/forum/#!topic/comp.lang.tcl/-ZPWC886KAQ


tkt_uuid: 7e0f5ae0f69146b1d73f450a7c1938210b429820
type: Bug
status: Closed
resolution: Fixed
subsystem: dns
priority: 8
severity: Severe
foundin: 1.3.4
private_contact: 87abe74d5afe184dfe3ea6b9cfac3f5683e69b5f
title: dns package
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457128.30557052
comment:
  hi , i just tried dns package 1.3.4 with these examples http://noel.feld.cvut.cz/vyu/ocs/ActiveTcl8.4.2.0-html/tcllib/dns.html
  but it looks like it doesn't work properly to me.

  % package require dns
  1.3.4
  % set tok [dns::resolve www.tcl.tk]
  ::dns::1
  % dns::status $tok
  connect
  % dns::address $tok
  can't read "state(reply)": no such element in array
  % dns::name $tok
  can't read "state(reply)": no such element in array
  % dns::cleanup $tok
  % info pa
  8.6.3


tkt_uuid: c315712173b359bcb61b3d3a8a8dbb91089f66ea
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Minor
foundin: 1.2.4
private_contact: ab5c04693d4ea3b3339a1e41947ceb8da8054625
title: uri::resolve doesn't handle scheme-relative urls
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457128.32624759
comment:
  A uri with an authority but no scheme should be resolved correctly. 

  Example:
  uri::resolve http://www.foo.com/ //www.bar.com/
  should be http://www.bar.com
  uri::resolve https://www.foo.com/ //www.bar.com/
  should be https://www.bar.com/

  Currently these will use the authority of the base url.

  http://tools.ietf.org/html/rfc3986#section-4.2


tkt_uuid: 071dbedcc8fcf432a790313030b807d2149d132f
type: Bug
status: Open
resolution: Accepted
subsystem: bibtex
priority: 3 Low
severity: Minor
foundin: 1.16
private_contact: 6c75ff8017bba20ae7d2bd8e65434b31f1b22d5e
title: Waiting on testcases for fix to mishandled token "string" and new feature "casesensitivestrings"
cmimetype: text/plain
submitter: aku
assignee: aku
closer: nobody
comment:
  Here is a patch against the bibtex module.  It fixes a minor issue where the token "string" could be found and treated as a string macro definition in the middle of a field.  It also adds a new "casesensitivestrings" feature to make bibtex string macros case sensitive (which is how bibtex works).


tkt_uuid: cf775f72eff52d73f87ba6fded32c4d41ad94dcc
type: RFE
status: Closed
resolution: Fixed
subsystem: logger
priority: 5 Medium
severity: Minor
foundin: 0.9.3
private_contact: 139b1eaf5ce8aad0f86e2ad385566019220aa1cf
title: logger::initNamespace does not inherit current level from parent service
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457134.35946854
comment:
  When no ?level? is specified for ::logger::initNamespace, it defaults to 'warn'.

  It seems to me that it would be more natural to inherit the current level from the parent service.

  Although current behaviour it is documented in the manual, it came as a surprise to me, as inheriting is a useful default behaviour, and it is the default for ::logger::init.  Restoring this behaviour is uncomplicated but somewhat wordy:

  ::logger::initNamespace \
          [namespace current] \
          [[namespace parent]::log::currentloglevel];


tkt_uuid: b55257b8d1865a9d4ac33b044c08a46e72737dbd
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil
priority: 5 Medium
severity: Important
foundin: 0.4.3
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: fileutil::traverse: filters do not see the absolute path
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457135.46292007
comment:
  While the documentation [http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/fileutil/traverse.html] emphasizes that "The callback is invoked with a single argument, the _absolute_ path of the directory [...]", the filter receives the _relative_ path instead.

  % info patchlevel
  8.6.3
  % package require fileutil::traverse
  0.4.3
  % proc prefilter path {puts stderr [info level 0]; return false}
  % proc filter path {puts stderr [info level 0]; return false}
  % [::fileutil::traverse %AUTO% . -prefilter prefilter -filter filter] foreach path {}
  filter .
  prefilter .

  Expected behavior:
  % [::fileutil::traverse %AUTO% . -prefilter prefilter -filter filter] foreach path {}
  filter /tmp
  prefilter /tmp
  OR fix the documentation (relative path for relative base dir)


tkt_uuid: 901466416386e65799b9eec0728bea1151cc5f35
type: Bug
status: Closed
resolution: Fixed
subsystem: control
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Possible extra [variable version] left over from 'provide' sweep.
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: aku
closedate: 2457127.46289446
comment:
  --- control.tcl.orig	Fri Apr 10 13:26:36 2015
  +++ control.tcl	Fri Apr 10 13:26:42 2015
  @@ -7,7 +7,6 @@
   package require Tcl 8.2
   
   namespace eval ::control {
  -    variable version
       namespace export assert control do no-op rswitch
   
       proc control {command args} {


tkt_uuid: 2d683b17a16ed3471317a95237b8be4897480cd8
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: calculus
priority: 8
severity: Severe
private_contact: 194c9ef8edbd9a57ef36f4f18fde1d57ce26e1e5
title: math::calculus - 8.4 or 8.5 as minimum requirement ?
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2457133.77971602
comment:
  Running the Tcllib testsuite against a Tcl 8.4.19 tclsh shows 3 test failures for math::calculus.

  Apparently while the package claims to be usable for Tcl 8.4, the command qk15_basic uses the ** operator, which exists only in Tcl 8.5+.

  Test output will be attached.

  Options for fixing the issue:
  - Keep 8.4 as min requirement and replace ** with use of the pow() function
  - Declare the package to require Tcl 8.5 (code, docs, testsuite).
  - ??? anything else


tkt_uuid: 624f2300ab3d5c458efe3c7d797cde2dd335d373
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: pool
priority: 8
severity: Severe
foundin: 1.2.2
private_contact: 194c9ef8edbd9a57ef36f4f18fde1d57ce26e1e5
title: struct:pool failures against Tcl 8.4.19
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2457127.45559626
comment:
  29 failures, all of the same variety, as inlined below.
  I suspect that struct::pool makes use of the {*} construct, especially as these failures do not happen against Tcl 8.5+.

  Confirmed. Stacktrace inlined below, after the test results.

  Options for fix:
  - Get rid of {*} - Should be trivial, centralized to "Error" procedure.
  - Declare package as Tcl 8.5+ (code, docs, tests).

  ==== modules/struct/pool.test pool-0.1 FAILED =========
  ==== Contents of test case:

      pool mypool
      catch {pool mypool} msg
      mypool destroy
      set msg

  ---- Result was:
  extra characters after close-brace
  ---- Result should have been:
  The pool `mypool' already exists.
  ==== modules/struct/pool.test pool-0.1 ====

  % source modules/struct/pool.tcl
  % package require struct::pool
  1.2.2
  % struct::pool mypool
  mypool
  %  struct::pool mypool
  extra characters after close-brace
  % set errorInfo
  extra characters after close-brace
      while compiling
  "return -code error -level 1  -errorcode [list STRUCT POOL $error {*}$args]  [format $Errors($error) {*}$args]
  "


tkt_uuid: 58eb8d4e84c56705e6cec11f89a79f995ec53680
type: Bug
status: Open
resolution: None
subsystem: huddle
priority: 5 Medium
severity: Minor
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: Boolean type and a bug
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  It would be interesting to add the boolean type to huddle. Specially for converting huddle objects to json.

  Also inside the procedure "::huddle::_dict_setting", I think that the subcommand "create" is wrong:

  "
          create { ; # $args: all arguments after "huddle create"
              if {[llength $args] % 2} {error {wrong # args: should be "huddle create ?key value ...?"}}
              set resultL {}
              foreach {key value} $args {
                  lappend resultL $key [huddle to_node $value]
              }
              return [huddle wrap D $resultL]
          }
  "

  I would replace lappend with "dict set":
  "            if {[llength $args] % 2} {error {wrong # args: should be "huddle create ?key value ...?"}}
              set resultL {}
              foreach {key value} $args {
                  dict set resultL $key [huddle to_node $value]
              }
              return [huddle wrap D $resultL]
          }
  "


tkt_uuid: 561c505d9760b278249fb814587c1b5b92395dc8
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Severe
foundin: 1.4
private_contact: 7e3820ed81064cf9306d34dd9be1633e66f1a08b
title: WebSocket headers not correctly checked
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  Requests were being (incorrectly) processed without checking
  whether they include the Upgrade and Connect headers.  The
  following patch solves the issue.

  commit 559a6dbc8a2bad39a3363d994237cc92
  Author: Adrián Medraño Calvo <amcalvo@prs.de>
  Date:   Thu Apr 16 10:10:35 2015 +0200

      [ws]: Ensure WebSocket headers are present

      Requests were (incorrectly) processed without checking whether
      they include the Upgrade and Connect headers.  The following
      patch solves the issue.

  diff --git a/src/websocket.tcl b/src/websocket.tcl
  index 6d60537..a9e0624 100644
  --- a/src/websocket.tcl
  +++ b/src/websocket.tcl
  @@ -431,8 +431,17 @@
   		}
   		dict lappend res protocols {*}$protocols;
   	    }
  +	    default {
  +		# Ignore other headers.
  +	    }
   	}
       }
  +    if {!$upgrading} {
  +	ThrowError "No 'Connect' header with 'upgrade' token found" HANDSHAKE CONNECTION
  +    }
  +    if {!$websocket} {
  +	ThrowError "No 'Upgrade' header with 'websocket' token found" HANDSHAKE UPGRADE
  +    }
       if {![dict exists $res version]} {
   	ThrowError "No WebSocket version specified" HANDSHAKE VERSION
       }


tkt_uuid: 1485d64881ca47bb69d65295e859d8f57f6713ae
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Minor
foundin: 1.4
private_contact: 7e3820ed81064cf9306d34dd9be1633e66f1a08b
title: Public procedures not exported
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  commit 4d7710c4eca7a1abff10385769cf512e
  Author: Adrián Medraño Calvo <amcalvo@prs.de>
  Date:   Thu Apr 16 10:15:15 2015 +0200

      [ws]: Export public procedures

  diff --git a/src/websocket.tcl b/src/websocket.tcl
  index 6d60537..a9e0624 100644
  --- a/src/websocket.tcl
  +++ b/src/websocket.tcl
  @@ -65,6 +65,8 @@
   	variable libdir [file dirname [file normalize [info script]]]
   	${log}::setlevel $WS(loglevel)
       }
  +    # Export all public procedures.
  +    namespace export {[a-z]*}
   }


tkt_uuid: 631a44ed66fbb33373f1d5342a0ae5d1ba6dd38b
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Critical
foundin: 1.4
private_contact: 3410fe6f8504d01909e548b02e0cec50a5f7fab3
title: WebSocket clients can block server
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  ::websocket server socket is set to *blocking* mode.  As a
  consequence, misbehaving clients can completely block the server if they
  refuse to read or write a complete message.

  The following recipe (*nix only) reproduces the issue.  Two shells are
  needed, one to run a ::websocket server, the other to create a
  misbehaving client.

  In the first shell run the Tcl script below.  The script creates a
  WebSocket server (handshake ommited) and prints a message at regular
  intervals; this message will stop being printed when the client blocks
  the server.

  ---------------->8----------------
  package require websocket;
  namespace eval ::s {};
  proc ::s::accept {sock args} {
      puts "server: new connection $args";
      ::websocket::takeover $sock [list ::s::handler] 1 {};
  }
  proc ::s::handler {sock type args} {
      puts "$sock: $type $args";
  }
  proc ::s::canary {interval} {
      puts "canary: Still alive...";
      ::after $interval [list ::s::canary $interval];
  }

  ::s::canary 1000;
  ::socket -server [list ::s::accept] 54321;
  ::vwait forever;
  ----------------8<----------------

  In the second shell run the following command:

  ---------------->8----------------
      { echo -n 1; sleep 5s; } | nc localhost 54321
  ----------------8<----------------

  The server is blocked for 5 seconds.


tkt_uuid: a753cade839f466391b1af0c1b334f5a601ddbcf
type: Bug
status: Open
resolution: None
subsystem: huddle
priority: 7 High
severity: Minor
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: New improved huddle version
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  I have a new improved version of huddle. It's more readable and it pass all the tests. I attach to this file.

  I want to continue doing improvements.


tkt_uuid: 87e374b7e4145fd33a91270392db6c342cb4c2f2
type: Bug
status: Closed
resolution: Fixed
subsystem: rest
priority: 6
severity: Minor
foundin: 1.0.1
private_contact: be7ac0e814cab3a6cfd46aad596a3ec91f56622a
title: rest module documentation formatting is incorrect making it hard to understand
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457172.50187535
comment:
  I've been using the rest package to accomplish some automated testing. However, it has been difficult to understand the options properly because "rest.man" is not formatted correctly in a browser. 

  Currently, the best way to understand the documentation is to read the "rest.man" file in an editor.


tkt_uuid: 34cf417ffd426833f4b3af697630ca936871c4d4
type: Bug
status: Open
resolution: None
subsystem: comm
priority: 5 Medium
severity: Minor
foundin: 4.6.3.1
title: comm-6.0 fails
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  ==== modules/comm/comm.test comm-6.0 FAILED =========
  ==== Contents of test case:

  SSL channel "sock6": error: sslv3 alert handshake failure
      # Setup secured channel in main process.
      tls::init  -keyfile  [tcllibPath devtools/receiver.key]  -certfile [tcllibPa
  th devtools/receiver.crt]  -cafile   [tcllibPath devtools/ca.crt]  -ssl2 1     -
  ssl3 1     -tls1 0     -require 1
      comm::comm new BAR -socketcmd tls::socket -listen 1
      # Setup secured channel in slave process
      ::comm::comm send [slave] {
          package require tls
          set fox dog
      }
      ::comm::comm send [slave]  [list  tls::init  -keyfile  [tcllibPath devtools/
  transmitter.key]  -certfile [tcllibPath devtools/transmitter.crt]  -cafile   [tc
  llibPath devtools/ca.crt]  -ssl2 1     -ssl3 1     -tls1 0     -require 1]
      set FOO [::comm::comm send [slave] {
          comm::comm new FOO -socketcmd tls::socket -listen 1
          FOO self
      }] ; # {}
      # Run command interaction over the secured channel
      set res [BAR send $FOO {set fox}]
      # Cleanup, remove secured endpoints
      comm::comm send [slave] {FOO destroy}
      BAR destroy
      # Return result of the secured command
      set res

  ---- Result was:
  ---- Return code should have been one of: 0 2
  ---- errorInfo: target application died or connection lost
      while executing
  "::comm::comm_cmd_send ::BAR 35868 {set fox}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [linsert $args 0 $method $chan]"
      (procedure "BAR" line 8)
      invoked from within
  "BAR send $FOO {set fox}"
      ("uplevel" body line 18)
      invoked from within
  "uplevel 1 $script"
  ---- Result should have been:

  ==== modules/comm/comm.test comm-6.0 ====


  Strong possibility this is really a failure in the
  locally installed tls package, but in that case the
  test ought to anticipate that possibility.


tkt_uuid: 9cbe339d784fc922cbeb3b029d886d1516753add
type: Bug
status: Open
resolution: None
subsystem: pop3
priority: 5 Medium
severity: Minor
foundin: 1.9
title: pop3-7.0 fails
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  ==== modules/pop3/pop3.test pop3-7.0 FAILED =========
  ==== Contents of test case:

      dialog::shutdown
      dialog::setup server {Pop3 Fake Server} 1
      tls::init  -keyfile  [tcllibPath devtools/receiver.key]  -certfile [tcllibPa
  th devtools/receiver.crt]  -cafile   [tcllibPath devtools/ca.crt]  -ssl2 1     -
  ssl3 1     -tls1 0     -require 1
      dialog::dialog_set loginStatusOk
      set psock [pop3::open -socketcmd tls::socket localhost ak smash [dialog::lis
  tener]]
      close $psock
      dialog::waitdone
      set msg [string match sock* $psock]
      # status data is retained if the connection is not closed through
      # the prescribed api command.
      lappend msg [peek $psock]
      set msg

  ---- Result was:
  ---- Return code should have been one of: 0 2
  ---- errorInfo: POP3 CONNECT ERROR: error reading "sock6": software caused conne
  ction abort
      while executing
  "pop3::open -socketcmd tls::socket localhost ak smash [dialog::listener]"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- Result should have been:

  ==== modules/pop3/pop3.test pop3-7.0 ====


  SSL channel "sock6": error: sslv3 alert handshake failure
  connection reset by peer
      while executing
  "close  $sock"
      (procedure "Exit" line 4)
      invoked from within
  "Exit $sock close"
      (procedure "Input" line 6)
      invoked from within
  "Input after#17 sock6"

  This may really be a failure in the locally installed tls
  package.


tkt_uuid: c61bc737717ede010494b59c3744b87d955af3a2
type: Bug
status: Closed
resolution: Fixed
subsystem: Build System & Testing
priority: 5 Medium
severity: Minor
foundin: gpx 1
title: gpx test stuite doesn't handle tdom absence gracefully
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457164.42560488
comment:
  [*   ]  [8.5.18] gpx                   Aborted!Required package tdom not found.
  [    ]  [8.5.18] gpx                   ~~ Skip  T     0 P     0 S     0 F     0


  should be easy enough to use constraints to cause 
  all tests skipped.


tkt_uuid: b5092d562380cb8518ad5875e87abe255ac57619
type: Bug
status: Closed
resolution: Fixed
subsystem: Build System & Testing
priority: 5 Medium
severity: Minor
foundin: 1.2.1
title: ooutil test suite doesn't handle TclOO absence gracefully
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457164.4312445
comment:
  [*   ]  [8.5.18] ooutil                Error in ooutil.tcl: can't find package T[    ]  [8.5.18] ooutil                ~~ ERR   T     0 P     0 S     0 F     0


tkt_uuid: 65eb10bf2f49cbd50d28716298b0c60c49d2f10c
type: Bug
status: Closed
resolution: None
subsystem: tepam
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Tepam demo assumes presence of csh
cmimetype: text/plain
submitter: stwo
assignee: droll
closer: droll
closedate: 2457165.7648689
comment:
  $OpenBSD: patch-examples_tepam_tepam_demo_tcl,v 1.3 2013/11/14 09:21:18 stu Exp $
  --- examples/tepam/tepam_demo.tcl.orig  Fri Apr 10 12:00:09 2015
  +++ examples/tepam/tepam_demo.tcl       Fri Apr 10 12:17:39 2015
  @@ -188,7 +188,7 @@ proc OpenConsole {} {
         }
         # Search inside the *n.x envirement for TkCon ...
         set TkConPath ""
  -      catch {set TkConPath [exec csh -f -c {which tkcon.tcl}]}
  +      catch {set TkConPath [exec which tkcon]}
         # Search inide the Windows envirement for TkCon ...
         catch {
            package require registry


tkt_uuid: 27ed7fc771b0036aba9c3b301819b92b362917db
type: Bug
status: Closed
resolution: Accepted
subsystem: huddle
priority: 5 Medium
severity: Minor
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: New huddle version
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457366.75759984
comment:
  I developed a new version of huddle. I improved more the readability of the source code. I refactored a little and I made other minor changes. I added 3 new types: boolean, number and null.

  For the reason that I added these new types, I have had to change the test 3-2, because the string type was used before for numbers, booleans and also the null type.

  I have to add more tests for these new types.

  Next week, I will add a json to huddle parser.

  I want to make some changes and I need an approval:
          - Tags are the name of the type in uppercase. For example STRING, BOOLEAN, NUMBER,... instead of s, b, d. I think that this is more readable. The drawback is that it's slower to compare two string of length greater than 1 , than two characters. But the purpose of huddle is not to proccess big json data structures, for this reason I think that this is not a serious penalty.
          - the gets subcommand is very confusing. I want to change this name to "get_stripped".


  Best regards,
  Miguel.


tkt_uuid: c3478ceae229ff99d36013497e9dfd389bdd7848
type: Bug
status: Open
resolution: None
subsystem: huddle
priority: 5 Medium
severity: Important
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: New json to huddle parser
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Hi, I created a json to huddle parser. I built 20 tests for this new code. I used an object oriented approach.

  I refactored huddle, I eliminated dead code and I improved the quality. Now it's more readable and easy to mantain.

  I added these new types to huddle:
  - number
  - boolean
  - null

  I added some tests for these new types.

  I changed accordingly yaml:
  - the behaviour and siganture of huddle::wrap was changed and for this reason made the appropriate changes in yaml
  - it's necessary a new parameter "isContainer" for new types. This parameter indicates whether a type can contains another types.
  - I added "combine_relaxed" in huddle because yaml needs to combines objects of different types

  The new source code pass al the tests:
  - the tests for huddle
  - the tests for yaml
  - the tests for json2huddle

  It's all added to the attachment.

  Best regards,
  Miguel.


tkt_uuid: 9b52204feaf9e1b0d5b081e849bc5136eccbd296
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil
priority: 7 High
severity: Important
foundin: 1.17
private_contact: adb452dc97d3b0673d7a54acfc0c8f63394f17c5
title: fileutil::find in tcllib 1.17 does not come back when used on /sys/devices
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457169.46364794
comment:
  Hi,

  I'm using the fileutil::find command to search for certain USB devices
  under /sys/devices. This still worked fine in tcllib 1.16. However, the
  functions hangs (endless loop?) in tcllib 1.17.
  Here is a small test program:

  --- snip ---

  package require fileutil


  proc IsIdVendorFile {fileName} {

      return [string equal idVendor $fileName]
  }


  foreach vendorIdFileName [fileutil::find /sys/devices IsIdVendorFile] {
      puts $vendorIdFileName
  }

  --- snip ---

  I did not check the find command for other trees.


tkt_uuid: 29aa482121acc35ee82ebab543cac56cff97af96
type: Bug
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Critical
foundin: 1.3.3
private_contact: 24e6652e36ce2e57ca3201030571772f1476335c
title: JSON module fails to parse data
cmimetype: text/plain
submitter: arjenmarkus
closer: nobody
comment:
  The following code produces a dict consisting only of the key "message":

  package require json
  set data { \
    "message": "success", \
    "number": 6, \
    "people": [ \
      {
        "craft": "ISS", \
        "name": "Anton Schkaplerov"\
      }, \
      { \
        "craft": "ISS", \
        "name": "Samantha Cristoforetti"\
      }, \
      { \
        "craft": "ISS", \
        "name": "Terry Virts"\
      }, \
      { \
        "craft": "ISS", \
        "name": "Gennady Padalka"\
      }, \
      { \
        "craft": "ISS", \
        "name": "Mikhail Kornienko"\
      }, \
      { \
        "craft": "ISS", \
        "name": "Scott Kelly"\
      } \
    ] \
  }

  set d [::json::json2dict $data]
  puts $d
  puts [dict keys $d]


tkt_uuid: 203aa0ea508c827ede4d37568620b2375478d3ff
type: RFE
status: Open
resolution: Wont Fix
subsystem: odie
priority: 5 Medium
severity: Minor
foundin: 1.17 .03
private_contact: d2f36a14d833bdfcec3af2595eb2dd824add0545
title: odie::processman should return exit codes of processes it manges
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  It would be very nice to see the return code of processes that odie:processman controls- As I need to get the return codes out of my processes I have had to copy the process_list and check for dead processes myself every x seconds instead of using the built in onExit callback.

  Thanks for writing such a cool package!


  Also, the odie Category that this page http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/processman/processman.html#5 points to does not exist!


tkt_uuid: b9a39c02c7855865fb48c32d1d4dcbf8ee22750b
type: Bug
status: Closed
resolution: Duplicate
subsystem: ldap
priority: 8
severity: Important
foundin: 1.16
title: ldap::search broken -- needs blocking socket
cmimetype: text/html
submitter: mi
assignee: aku
closer: aku
closedate: 2458143.33540744
comment:
  <p align="justify"><tt>ldap::connect</tt> explicitly sets blocking to "no" for the socket, which can then cause <tt>ReceiveBytes</tt> to return "partial".

  <p align="justify">Unfortunately, <tt>ldap::searchNext</tt> is not prepared to see "partial" in its request for 1 byte and throws a bogus error like:
  <blockquote>Error reading SEQUENCE response for handle ::ldap::ldapsock88654988 : partial :</blockquote>

  <p align="justify">As a work-around I switch the "blocking" attribute of the handle's sock back to blocking in my own script after binding. Searches now work for me. But, obviously, this should not be necessary...


tkt_uuid: 4a4e443ce9b08d1a579a97bb3bfa77d22d5be75d
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 5 Medium
severity: Severe
foundin: 1.0.3
private_contact: ab5c04693d4ea3b3339a1e41947ceb8da8054625
title: peg oo parser error
cmimetype: text/x-fossil-wiki
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457182.34827946
comment:
  A tcloo parser generated by pt::pgen throws an internal error or generates incorrect parse trees.  The same grammar works correctly with pt::peg::interp

  Grammar:
  <verbatim>
  PEG err (eos)
   eos <- ex (<space>+ ex)*;
   ex  <- (!X ('x'/'z'))+ X? ;
   X   <- "x" ;
  END;
  </verbatim>

  Input text: "zx z" results:
  <verbatim>
  insufficient items on stack to fill request
      while executing
  "$mystackloc peek"
      (class "::pt::rde::oo" method "complete" line 5)
      invoked from within
  "my complete"
      (class "::Lang" method "parset" line 5)
      invoked from within
  "L parset "zx z""
  </verbatim>

  Test script used:
  <verbatim>
  package require pt::pgen

  catch [pt::pgen peg {
   PEG err (eos)
    eos <- ex (<space>+ ex)*;
    ex  <- (!X ('x'/'z'))+ X? ;
    X   <- "x" ;
   END;
  } oo -class Lang]

  Lang create L
  L parset "zx"    ;# incorrect parse tree generated
  L parset "zx z"  ;# throws error
  </verbatim>

  Making the X production a void: eliminates the error (but changes the result of course).


tkt_uuid: ced089d5fec86a1b4722ffbd93810820ccc06845
type: Bug
status: Closed
resolution: Fixed
subsystem: multiplexer
priority: 5 Medium
severity: Important
foundin: 1.17
title: Multiplexer test continues to fail on FreeBSD
cmimetype: text/html
submitter: mi
assignee: aku
closer: aku
closedate: 2457182.3551772
comment:
  <p align="justify">The problem was originally reported as a <A href="https://sourceforge.net/p/tcllib/bugs/1212/">SourceForge Bug #1212</A>, and closed as unreproducible on Ubuntu. Well, it remains a problem on FreeBSD today, five years after the original report.

  <p>Please, do the needful.


tkt_uuid: 9a38890c98231ce1ee8ec21c28b0d5b99b42ca02
type: Bug
status: Open
resolution: None
subsystem: cron
priority: 5 Medium
severity: Minor
foundin: 1.17
title: cron's self-tests may fail sometimes
cmimetype: text/plain
submitter: mi
assignee: hypnotoad
closer: nobody
comment:
  Due to, I suppose, rounding errors the cron's wait may exit after 10 instead of 11 seconds, for example, leading to a spurious test-failure. These are hard to reproduce, but they do appear some times...

  Perhaps, the tests need to be rewritten to allow a range of expectations -- instead of the solid 11, for example, allow 10, 11, and 12 as acceptable values.


tkt_uuid: 785d2954d485669f6f9e0f24ffe3bb3e8deabcc0
type: Patch
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Minor
foundin: 1.17
title: Improve C-implementation of JSON-parsing
cmimetype: text/html
submitter: mi
assignee: aku
closer: nobody
comment:
  <p>The proposed improvement will:<ol>
  <li>Speed-up parsing by using dictionaries, if the underlying Tcl offers them (is above 8.4).
  <li>Use less memory by reusing string-objects for "null", "true", and "false -- the only string-literals in JSON.
  <li>Speed-up parsing and most usage by treating numeric values as such by creating Int, Long, or WideInt Tcl-objects instead of strings.
  </ol>
  <p>The additions to the JSON test-suite are included as well. The <A href="http://svnweb.freebsd.org/ports/head/devel/tcllib/files/patch-json?view=markup">complete patch</A> is now part of the FreeBSD ports-collection.


tkt_uuid: 14e3acd8d73ddf3a72b51611e5d4a7801827662a
type: Bug
status: Closed
resolution: Fixed
subsystem: Build System & Testing
priority: 5 Medium
severity: Important
foundin: 1.17
title: Build of tcllib creates files outside of build-directory
cmimetype: text/html
submitter: mi
assignee: aku
closer: aku
closedate: 2457177.79379983
comment:
  <p>When using critcl, build will leave stuff in <tt>~/.critcl/</tt>

  <p>This is not good &mdash; the build-process should invoke critcl with an explicit <tt>-cache</tt> argument pointing at a path under the build directory.


tkt_uuid: ad52568aab98ec49169884f4e4c1adac3a994430
type: Bug
status: Closed
resolution: Duplicate
subsystem: jpeg
priority: 5 Medium
severity: Important
title: github tcllib mirror bogosity (JPEG self-tests fail)
cmimetype: text/html
submitter: mi
assignee: aku
closer: aku
closedate: 2457175.5117142
comment:
  <p align="justify">Because <tt>getExifFromChannel</tt> may some times close the channel, an attempt to close it after calling the function some times fails. Two of the JPEG-tests (jpeg-11.0 and jpeg-32.0) currently fail with this error:
  <pre>---- errorInfo: can not find channel named "file5"
      while executing
  "close $fh"
      (procedure "getExif" line 4)
      invoked from within
  "getExif $file thumbnail"
      (procedure "::jpeg::getThumbnail" line 3)
      invoked from within
  "::jpeg::getThumbnail $f"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"</pre>


tkt_uuid: acd8c27943874c37dc6eaade0ab574950edcbc59
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil
priority: 5 Medium
severity: Minor
foundin: 1.17
private_contact: 3fedc5136b468329676f5199f7389ae0f7d92d8f
title: fileutil::fileType - detects some pdf files just as text
cmimetype: text/x-fossil-wiki
submitter: pooryorick
assignee: aku
closer: aku
closedate: 2457175.53962659
comment:
  Some pdf files fail the binary test, in which case they are also not reported
  as pdf files.  Here is a script to generate such a pdf file:

  <code><verbatim>
  #! /bin/env tclsh

  package require fileutil
  package require pdf4tcl

  set fname pdf4tcl_01.pdf
  ::pdf4tcl::new mypdf -file $fname 
  mypdf startPage
  mypdf setFont 12 Courier
  mypdf text Hello
  mypdf finish
  mypdf destroy

  puts [fileutil::fileType $fname]
  </verbatim></code>

  The following small change would cause <code>fileType</code> to return
  <code>text pdf</code> for such a file.

  <code><verbatim>
  --- modules/fileutil/fileutil.tcl
  +++ modules/fileutil/fileutil.tcl
  @@ -1654,14 +1654,15 @@
           }
       } elseif { $binary && [string match "MM\x00\**" $test] } {
           lappend type graphic tiff
       } elseif { $binary && [string match "BM*" $test] && [string range $test 6 9] == "\x00\x00\x00\x00" } {
           lappend type graphic bitmap
  -    } elseif { $binary && [string match "\%PDF\-*" $test] } {
  -        lappend type pdf
       } elseif { ! $binary && [string match -nocase "*\<html\>*" $test] } {
           lappend type html
  +    } elseif {[string match "\%PDF\-*" $test] } {
  +       puts [list whee $binary]
  +        lappend type pdf
       } elseif { [string match "\%\!PS\-*" $test] } {
          lappend type ps
          if { [string match "* EPSF\-*" $test] } {
              lappend type eps
          }
  </verbatim></code>


tkt_uuid: ea3f40b29fdc42ccc7d3429ec6746400643aaf4a
type: Bug
status: Closed
resolution: Invalid
subsystem: clock
priority: 5 Medium
severity: Important
foundin: 1.17
title: Test clock-iso8601-1.1 may fail on a "wrong" Tcl-version
cmimetype: text/html
submitter: mi
assignee: aku
closer: aku
closedate: 2457182.35800036
comment:
  <p>The negative test expects an error. However, the exact text of the error message varies between Tcl-versions.
  <p>Here is the fix:
  <pre>
  --- modules/clock/iso8601.test  2014-02-11 14:04:18
  +++ modules/clock/iso8601.test  2014-12-09 00:12:22
  @@ -27,5 +27,5 @@
   test clock-iso8601-1.1 {parse_date, bad option} -body {
       clock::iso8601 parse_date 1994-11-05 -foo x
  -} -returnCodes error -result {bad switch "-foo", must be -base, -format, -gmt, -locale or -timezone}
  +} -returnCodes error -match regexp -result {^bad (option|switch) "-foo"}

   # NOTE: While listed as legal, -format is NOT. This is because the
  </pre>


tkt_uuid: 5613c718c2a648f85bac730aacb7db52250d6101
type: Bug
status: Open
resolution: None
subsystem: Build System & Testing
priority: 5 Medium
severity: Minor
foundin: 1.17
title: Fixing compiler-warnings in C-code
cmimetype: text/html
submitter: mi
assignee: aku
closer: nobody
comment:
  <p align="justify">When using critcl, a number of warnings -- and bugs -- surface. Especially, when a "picky" compiler is in use -- such as clang, which is now the base "cc" on FreeBSD.
  <p>The fixes fall into several broad categories:<ol>
  <li>Casting pointer to int needs to be done via <tt>intptr_t</tt> or else a warning is generated on platforms, where pointer and int are of different width.
  <li><tt>size_t</tt> is a better type for counters, than <tt>long int</tt>. Note, that <em>no</em> type is safe, if the counter can grow perpetually (as  the enumerated objects are deleted and created) &mdash; sooner or later it will reset back to 0 (or MIN_LONG) causing mayhem. But, at least, with an unsigned type you will not have a - in the name. Generally speaking, this use of counters stinks and the actual pointers should be used instead, when a textual name for an object is desired <tt>sprintf(buf, "struct%p", pointer);</tt>
  <li>Use "%td" to print the above counters.
  <li>The function <tt>rde_param_query_lstop</tt> was outright broken &mdash; returning a junk instead of the value. Unlike Tcl, C does not implicitly return the result of the last invoked function :-)
  <li>Faster implementation of <tt>UniCharIsDecDigit</tt> and <tt>UniCharIsHexDigit</tt>
  <li>Include the right headers to make sure, every function used is declared in advance.
  <li>Fixes to the test-data to account for all of the above</ol>
  Some of the above changes assume C99 compiler. I believe that to be a reasonable assumption in 2015.


tkt_uuid: d36555bc472c8243afad767cfa7144fc37d0853d
type: Bug
status: Closed
resolution: Fixed
subsystem: Build System & Testing
priority: 9 Immediate
severity: Critical
foundin: 1.17
title: The "new" tcllib-1.17 at GitHub missing files
cmimetype: text/plain
submitter: mi
assignee: aku
closer: aku
closedate: 2457176.34371267
comment:
  The file now served by GH as tcllib_1_17:

  https://codeload.github.com/tcltk/tcllib/tar.gz/tcllib_1_17?dummy=/tcltk-tcllib-1.17-tcllib_1_17_GH0.tar.gz

  is much smaller than before (7686336 vs. 8284201) and lacks several files such as, for example:

  . modules/pt/pt_util.tcl
  . modules/string/token.tcl
  . modules/pt/pt_cparam_config_tea.tcl

  Please, advise.

  used by the testsuite.


tkt_uuid: 13506dd6a76fbc395954788dc4763f9a57494c58
type: RFE
status: Closed
resolution: Fixed
subsystem: math :: constants
priority: 5 Medium
severity: Minor
foundin: 1.17
private_contact: 69e6fa40fdd4770fd3a59354e647ca589c07115f
title: Document the constants defined by math::constants
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2457185.41758468
comment:
  It is proposed to extend the manpage of package math::constants with a section listing the defined constants. These constants should also be marked as keywords, for lookup via the index.

  Should make it easier to determine if the package will be of use before installation, instead of having to install it and then use 'print-constants' for introspection.


tkt_uuid: 91d3bd90fdaa17959ee341dc7546babeaa56d23d
type: Bug
status: Closed
resolution: Fixed
subsystem: odie
priority: 4
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: odie::processman is wrong?
cmimetype: text/plain
submitter: stwo
assignee: hypnotoad
closer: aku
closedate: 2457182.35734008
comment:
  There's no mention of the odie namespace in the documentation
  leading a user to think that [package require processman] will work
  whereas they really need [package require odie::processman].
  Shouldn't the usage be [package require processman]?


tkt_uuid: 3134eefad3a0b3db06980094915f1bdaf22bbfac
type: Bug
status: Closed
resolution: Works For Me
subsystem: zip
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Merge in the "zip for 8.6" branch
cmimetype: text/plain
submitter: hypnotoad
assignee: hypnotoad
closer: hypnotoad
closedate: 2457182.56185463
comment:
  The branch contains work which allows 8.6 interpreters to do zip decoding without the need of a binary extension. It also provides a new "mkzip" package which allows the creation of a zip archive or self extracting binary in one go.


tkt_uuid: 6caeac3d2ba1f8bcbf2ddd8b5153a3ab313a8704
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: special
priority: 5 Medium
severity: Minor
foundin: trunk
title: math::special::Gamma manual wrongly documents two arguments instead of one
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457184.26381672
comment:
  modules/math/special.man line 149:

  -[call [cmd ::math::special::Gamma] [arg x] [arg y]]
  +[call [cmd ::math::special::Gamma] [arg x]]


tkt_uuid: e23279c7d123395348b0660ec0016afcffcce1d3
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: 1.4
private_contact: 701769b102e1609c69fb82f60e02e52c65c76946
title: Websocket: empty protocol list throws error
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  Requesting a websocket with no protocols specified causes ::websocket::test to throw an error.
  For example, in Firefox v.38, the following javascript code is used to create the websocket:
  websock = new WebSocket("wss://example.com/websock")
  (There is an optional protocols argument following the first argument, but it is optional.)
  In my tclhttpd setup, the headers do not have a field for sec-websocket-protocol. This causes ::websocket::validate to return a dictionary that has no protocols field. In websocket::test, the line
  set protos [dict get $res protocols];
  then throws an error.
  My first workaround was to change the javascript code to specify the protocol. A better workaround is to change the line in websocket::test to catch the error and assign "*" to the variable protos in the event of an error. In other words, specifying no protocols implies all protocols are acceptable.


tkt_uuid: d879576438d4892909304013ed016ac195189ed6
type: Bug
status: Open
resolution: None
subsystem: nettool
priority: 5 Medium
severity: Minor
foundin: 0.5
private_contact: fe7e8ebe3a0e405d143524e072b65f94619a3565
title: nettool ifconfig 'couldn't execute "ifconfig": no such file or directory'
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  OS: Debian 8
  TCL: 8.6
  TCLLIB: 1.17

  On my debian systems I need to run '/sbin/ifconfig' since /sbin is not included in my path by default.  Using nettool::hwid_list or nettool::ip_list (probably others) will error saying it can't find 'ifconfig'.  I suspect that the command is being invoked without /sbin...


tkt_uuid: 3831d759223581dc8c63ecd741b80f47dc063da8
type: Patch
status: Closed
resolution: Accepted
subsystem: imap4
priority: 7 High
severity: Important
foundin: trunk
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: TLS for imap4 package
cmimetype: text/x-fossil-wiki
submitter: oehhar
assignee: aku
closer: aku
closedate: 2457316.45206481
comment:
  Message by Paul Marriott on clt: 2015-06-26 "Read ms exchange mailbox" [https://groups.google.com/forum/#!topic/comp.lang.tcl/tF8xX9Lw0aA]

  One more issue (resolved). If the server uses STARTTLS the standard IMAP4 package fails. The solution is to add the proc below to the IMAP4 package and call this function after connecting to the server but before login.

  This one took much hair pulling, googling and many cups of tea :-)

  See code below:

  <h1>Add this to IMAP4</h1>
  <verbatim>
                  # STARTTLS
                  # This is a new procc added to runs the STARTTLS command.
                  # Use this when tasked with connecting to an unsecure port which must be changed to a secure port prior to user login.
                  # This feature is known as STARTTLS.
      proc starttls {chan} {                                  
                                  puts "Starting TLS"                          
                                  request $chan "STARTTLS"
                                  if {[getresponse $chan]} {
                                                  puts "error sending STARTTLS"
                                                  return 1
                                                  }
                                 
                                  puts "TLS import"
                                  set chan [::tls::import $chan -tls1 1]
                                  puts "TLS handshake"
                                  set chan [::tls::handshake $chan]            
          return 0
      }
  </verbatim>
  <hr/>
  <h1>Use this code to connect to a maailbox using STARTTLS</h1>
  <verbatim>
  package require tls              ; # must be loaded for TLS/SSL
  package require imap4  
  set user domain/user
  set pass ********
  set server server.name
  set FOLDER INBOX

  # Debugging switch
  set ::imap4::debug 1

  # Connect to server
  set imap [::imap4::open $server]
  ::imap4::starttls $imap
  #set ::imap4::use_ssl 1           ; # request a secure connection
  ::imap4::login $imap $user $pass

  #switch to the folder defined
  ::imap4::select $imap $FOLDER

  # fetch 1 record inline
  set fields {from: to: subject: size bodystructure body header text uid}
  ::imap4::fetch $imap 1:1 {*}$fields
  ::imap4::msginfo $imap 1 text
  #show the unique id for the message
  ::imap4::msginfo $imap 1 uid

  # Copy the message to the archive directory (this is a backup just in case we need to re-read, it also functions as an audit trail)
  ::imap4::copy $imap 1:1 ARCHIVE
  #Delete the message
  ::imap4::store $imap 1:1 +FLAGS Deleted
  # Cleanup messages marked for delete
  ::imap4::expunge $imap

  # Cleanup
  ::imap4::cleanup $imap
  </verbatim>


tkt_uuid: 86c971506c37c6cb0d2faff13b9f86c8e131ff03
type: RFE
status: Closed
resolution: Fixed
subsystem: htmlparse
priority: 5 Medium
severity: Minor
foundin: 1.2.1
private_contact: 188c82e08dafda0b395d8b1182a0ab03060f986e
title: HTML 5.1 adds lots more named entities
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457336.66705244
comment:
  There are about 2000 new named entities.  I haven't tried this, yet.  But should be so darn close it shouldn't matter.

  It uses surrogates rather than the new \U literal.

  ex.  For the &Afr; entity, it uses \uD835\uDD04 instead of \U1D504


tkt_uuid: e84e8b481ed11d30948cd88d612f7514b1f41c0f
type: Bug
status: Closed
resolution: Fixed
subsystem: crc
priority: 5 Medium
severity: Severe
foundin: 1.1.2
private_contact: e377f0274c7d0799515857f13ca5ede5666031f8
title: CRC16 (CRC-CCITT): bad option -: ... AND list doesn't contains element 1
cmimetype: text/plain
submitter: anonymous
closer: patthoyts
closedate: 2458054.49906479
comment:
  The current CRC16 library reports an error when calculating the CRC of some special input data:

  In the version 1.1.2, when I execute the next code I receive the next error:

  set crc 0
  set data 11520
  set crc [::crc::crc-ccitt -seed $crc [binary format S1 [expr $data]]]

  # bad option -: must be one of -channel, -chunksize, -filename, -format, -impl, -seed

  The same error is reported when data is defined in the range of 11520 -> 11775. There are some values in this range that report other kind of error as 11625 and 11635:

  # list doesn't contain element 1

  With the rest of possible data in the range 0 --> 65535 no errors are reported and CRC is calculated correctly

  Is this a bug on the library or I am invoking the function in a wrong way?


tkt_uuid: a67295e52881c87b4142360cc235715a655e7519
type: Patch
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: cb02a4a25e8da92f2790bc307bf01ef24ce6053e
title: uri support for ipv6 hostnames
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457336.65199248
comment:
  uri::split doesn't know about IPv6 addresses as specified in rfc3986.
  The following patch adds support for IPv6 and IPvFuture addresses in
  schemes using the standard variables plus ldap, by the simple
  expedient of matching {[.*?]} (its non-greediness-sensitive equivalent)
  and including the [] with the hostname returned.

  This seems reasonable under the constraints of near-correct URIs.  A
  more precise regex would require scrutiny of ${unreserved} which doesn't
  exactly match the above RFC.  Some tests have been added.

  See attached uri.patch


tkt_uuid: a86b8b85e54d95d10ab97c05171d9d04c4644bd6
type: Bug
status: Closed
resolution: Fixed
subsystem: irc
priority: 5 Medium
severity: Minor
foundin: 8.6
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: Bug in example of irc library
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457315.14457902
comment:
  I detected a bug on the file:
      examples/irc/mainloop.tcl
  in line 47:
      $cn registerevent KICK {
          puts "[who] KICKed [target 1] from [target] : [msg]"
      }

  The "target" command doesn't accept an argument. So "[target 1]" is a bug. I
  suppose , but I am not sure, that this should be changed to this other code:
      $cn registerevent KICK {
          puts "[who] KICKed [target] : [msg]"
      }

  Best regards,
  Miguel.


tkt_uuid: feda6855978cd2fb4199ad37f324ed6f167e5b5f
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: 1.4
private_contact: 55805032f00760ddf84eb3f8acb077da7bef1411
title: Unsafe order of commands in websocket::Disconnect
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  The current implementation is:

  proc ::websocket::Disconnect { sock } {
  ...
      Push $sock disconnect "Disconnected from remote end"
      catch {::close $sock}
  ...
  }

  Where the order of these two commands is unsafe.
  Reason: In the [Push] there might be an [update] implemented which causes the websocket to re-enter the event loop --> ::Receiver --> ::Disconnect and crashing in an endless loop.

  The patch would simply be to move the [catch {::close $sock}] in front of the [Push]

  Note to myself:
  An application workaround is to implement the live callback as an event itself using [after 0].

  Regards
  Thomas


tkt_uuid: 06bf459d36c909846d3577d0cfd7fec261ab8c1e
type: Bug
status: Closed
resolution: Fixed
subsystem: csv
priority: 5 Medium
severity: Important
foundin: 1.17
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: [::csv::Split] sepRE is not a valid RE in general
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457316.42115782
comment:
  tcllib 1.17, csv 0.8:

  WHEN calling ::csv::Split with sepChar "x"
  THEN an error is thrown

  The bug is obvious after a look at the source code: [set sepRE \\$sepChar] is not a generic way to escape $sepChar in a RE. It results in an invalid escape sequence \x.


tkt_uuid: 0c3a46d24cf1412d153b9e2e5f3284b80e300ad2
type: RFE
status: Open
resolution: Accepted
subsystem: tcllib: request for new module
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: New FireTcl library
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  I don't know whether this library could be included in tcllib:
      https://sourceforge.net/projects/firetcl/

  It's framework that embeds Tcl into Firefox. It gives you the possibility to program desktop applications using web technology and Tcl.


tkt_uuid: 70d8274f904d7321c2e314a30f9f02101039e1ed
type: Bug
status: Open
resolution: None
subsystem: json
priority: 5 Medium
severity: Important
foundin: 1.3.3
private_contact: bd24e8f19d6884a980dbb98dbf01f84f44cbfe51
title: json2dict return value
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  It seems that json2dict returns a list for a JSON array, and returns a dictionary for a JSON object.  This seems okay, but is not how json2dict is documented and seems contrary to the name of the function.

  Also, if the list for a JSON array happens to have an even number of values, there is no way to tell if the original JSON is an array or an object.  I guess in general there is this schema issue.  It would be nice if the documentation spells this out.


tkt_uuid: 6e46b310f3fa93abf2ae4ff441fcf9b2e91f953f
type: Patch
status: Closed
resolution: Fixed
subsystem: irc
priority: 5 Medium
severity: Severe
foundin: 0.5.1
private_contact: a51e37d887da1eac76744a5dce5aac4423bc2404
title: picoirc: fix /msg command
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457315.13864203
comment:
  --- picoirc.tcl.orig	2015-09-06 21:15:36.082980736 +0200
  +++ picoirc.tcl	2015-09-06 21:15:47.182472503 +0200
  @@ -244,7 +244,7 @@
               version {send $context "PRIVMSG $first :\001VERSION\001"}
    	    msg {
    		if {[regexp {([^ ]+) +(.*)} $msg -> target querymsg]} {
  - 		    send $context "PRIVMSG $target :$msg"
  + 		    send $context "PRIVMSG $target :$querymsg"
    		    Callback $context chat $target $target $querymsg ""
    		}
    	    }


tkt_uuid: 817f51002f02b6b7edad6898e2c8b1e2167f465f
type: Bug
status: Closed
resolution: Fixed
subsystem: rest
priority: 5 Medium
severity: Severe
foundin: 1.0
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: ::rest::simple crashes
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457343.60115103
comment:
  ::rest::simple uses [info frame] to retrieve its callname - this is not reliable (also see https://groups.google.com/d/msg/comp.lang.tcl/xrtZw8CFcHI/I2A86UC-AAAJ).

  #!/usr/bin/env expect

  # Demonstrate the odd behaviour of [info frame].
  # This breaks ::rest::simple and aliases from tcllib's rest package.

  # ::rest::simple tries to get its call name with [namespace tail [lindex [dict get [info frame -1] cmd] 0]], ...
  proc simple {args} {
     puts stderr ">>>[dict get [info frame -1] cmd]<<<"
     lindex [dict get [info frame -1] cmd] 0
  }
  interp alias {} put {} simple

  # 1. the representation depends on control structures, compare these:
  put \
     A \
     B
  set do true
  while {$do} {
     put \
        A \
        B
     set do false
  }

  # 2. [info frame]'s cmd is not substituted --> simple's approach might not succeed:
  set m put
  $m A B ;# I cannot think of a workaround.

  # 3. [info frame]'s cmd is not a list in general --> simple's approach might crash the app:
  put [dict create headers {A B}]
  # WORKAROUND:
  put [dict create headers {A B} ] ;# take care of "meta-syntax"


tkt_uuid: 895baa109a5fedf7972313ced14b4585cf3ae953
type: Bug
status: Closed
resolution: Fixed
subsystem: rest
priority: 5 Medium
severity: Minor
foundin: 1.0
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: ::rest::simple ignores content-type
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457343.60107156
comment:
  "content-type" from the config directory of ::rest::simple is ignored. Workaround: use "headers" "Content-Type".


tkt_uuid: 2a45e56f92bf4467adb137984afd0f623934fab6
type: Bug
status: Closed
resolution: Fixed
subsystem: rest
priority: 5 Medium
severity: Cosmetic
foundin: 1.0
private_contact: 5ef84f1ed636fd4b80333e656cf7dfe1164a9802
title: incomplete documentation of rest+tls
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457315.3038994
comment:
  The section "TLS Security Considereations" suggests that the rest package seamlessly integrates with tls. It fails to mention that one needs to register the socket for the https protocol.

  Expected solution from the doc:
      package require tls
      tls::init -tls1 1 ;# forcibly activate support for the TLS1 protocol
      package require rest
  or
      package require rest
      package require tls
      tls::init -tls1 1 ;# forcibly activate support for the TLS1 protocol

  Actual solution (from http://wiki.tcl.tk/2627):
      package require rest
      package require tls
      http::register https 443 [list ::tls::socket -tls1 1] ;# "-tls1 1" is required since [POODLE]


tkt_uuid: a6eea15cdf4ae7fd20208a0d2caec3adfbbdf324
type: RFE
status: Closed
resolution: Fixed
subsystem: map
priority: 5 Medium
severity: Minor
foundin: 1.16
private_contact: 1d3c95db24e116878d6afed7cf890a89a0effe62
title: map::slippy::fetcher skip require img::png on tk 8.6
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457315.13002525
comment:
  map::slippy::fetcher can skip "package require img::png" when tk 8.6 is present since that supports PNG images out-of-the-box.

  While the IMG package itself is a great piece of work, it requires extra work to install (does not come with tklib), and sometimes it is not clear where to get it, which package is it on my distro etc.

  Patch:

  --- tcllib1.16/map/map_slippy_fetcher.tcl~	2014-02-11 20:04:18.000000000 +0100
  +++ tcllib1.16/map/map_slippy_fetcher.tcl	2015-09-10 23:43:45.361678526 +0200
  @@ -7,8 +7,11 @@
   ## Requisites
   
   package require Tcl     8.4 ; # No {*}-expansion :(, no ** either, nor lassign
  -package require Tk          ; # image photo
  -package require img::png    ; # Slippy tiles use the PNG image file format.
  +# "image photo" supports PNG on 8.6 but requires the IMG extension on earlier versions
  +if {[catch {package require Tk 8.6}]} {
  +    package require Tk; 
  +    package require img::png    ; # Slippy tiles use the PNG image file format.
  +}
   package require map::slippy ; # Slippy contants
   package require http        ; # Retrieval method
   package require snit

  Diff finished.  Thu Sep 10 23:45:58 2015


tkt_uuid: 0dd2a66f089e47c93b6f089e16e1fe6db41faf32
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Important
foundin: tcl 8.6
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: websocket server example and a bug found
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  I think that the websocket library requires an example of a websocket server.

  I attach to this message an example. It could be interesting for other users.

  I also found a bug. At the end of the  ::websocket::validate procedure it should be included this code:
     if {![dict exists $res protocols]} {
          dict set res protocols [list]
      }

  In my attachment, the websocket.tcl file has this change. Without this change the server example doesn't work.


tkt_uuid: dae6b527bc159a14c914c3d4eae46ac99a31b9be
type: Bug
status: Closed
resolution: Fixed
subsystem: cron
priority: 5 Medium
severity: Important
foundin: 1.17
private_contact: 310273a9a9308c961b73e79a87acdf09488aea25
title: Declaring a cron handler inside a cron command creates and infinte loop
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: hypnotoad
closedate: 2457367.19423567
comment:
  Okay! So when defining cron handlers, you cannot nest them:
  =========================================================
  #! /usr/bin/tclsh
  package require cron

  # Done timer
  ::cron::in done 20 {incr ::done}

  # Ten second timer
  ::cron::in ten_seconds 10 {
      puts "10 second timer triggered!"
      # Nested timer
      ::cron::in five_seconds 5 {
          puts "5 seconds triggered!"
      }
  }

  vwait ::done
  =========================================================
  Gives us this output:
  =========================================================
  second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  10 second timer triggered!
  5 seconds triggered!
  [hooga@samserv01 ~]$
  =========================================================

  If you instead turn the inner cron statement to an after Xms y, it works as expected:
  =========================================================
  #! /usr/bin/tclsh
  package require cron

  # Done timer
  ::cron::in done 20 {incr ::done}

  # Ten second timer
  ::cron::in ten_seconds 10 {
      puts "10 second timer triggered!"
      # Nested timer
      after 5000 {
          puts "After 5 seconds triggered!"
      }
  }

  vwait ::done
  =========================================================

  =========================================================
  [hooga@samserv01 ~]$ ./cron.tcl
  10 second timer triggered!
  After 5 seconds triggered!
  [hooga@samserv01 ~]$
  =========================================================


tkt_uuid: f084c0dc03bd57d142bce1703cc5bdd9beb88247
type: Bug
status: Open
resolution: None
subsystem: http :: autoproxy
priority: 8
severity: Critical
foundin: 1.17
private_contact: f0e2312a244c99b69b66ff52a743015292c5af63
title: memory leak in tcllib autoproxy
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  The autoproxy module appears to have a leak when a http request is made. Observe the RSS is increasing with each request. This has been observed on Tcl 8.5 and 8.6 running on FreeBSD 9.1 and 10.1, and with 1.16 and 1.17 versions of tcllib.

  Sample program will be attached in follow up.


  request 0
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  1.6  0.0 54200 8832  1  S+    3:48PM 0:00.19 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 1
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  1.2  0.0 54200 8968  1  S+    3:48PM 0:00.20 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 2
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  1.1  0.0 54200 8976  1  S+    3:48PM 0:00.21 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 3
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  1.1  0.0 54200 8976  1  S+    3:48PM 0:00.22 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 4
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.8  0.0 54200 8980  1  S+    3:48PM 0:00.23 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 5
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.7  0.0 54200 8984  1  S+    3:48PM 0:00.24 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 6
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.7  0.0 54200 8992  1  S+    3:48PM 0:00.26 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 7
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.6  0.0 54200 8992  1  S+    3:48PM 0:00.27 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 8
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.6  0.0 54200 8992  1  S+    3:48PM 0:00.28 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 9
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.5  0.0 54200 8996  1  S+    3:48PM 0:00.29 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 10
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.6  0.0 54200 9008  1  S+    3:48PM 0:00.30 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 11
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.6  0.0 54200 9012  1  S+    3:48PM 0:00.32 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 12
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.5  0.0 54200 9136  1  S+    3:48PM 0:00.33 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 13
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.5  0.0 54200 9140  1  S+    3:48PM 0:00.34 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 14
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.5  0.0 54200 9152  1  S+    3:48PM 0:00.35 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 15
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.4  0.0 54200 9152  1  S+    3:48PM 0:00.36 /usr/local/bin/tclsh8.6 ./leak.tcl
  request 16
  USER          PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
  jeff.lawson 11749  0.5  0.0 54200 9152  1  S+    3:48PM 0:00.37 /usr/local/bin/tclsh8.6 ./leak.tcl


tkt_uuid: d5435f31c23fd9d56c4a9c7fee8fc972589d4d51
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 9 Immediate
severity: Critical
foundin: 1.0.3
private_contact: 2caf797de13248fb0c6ec498502ae2197d48be0f
title: parsertools generator crash on metacharacters
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457359.60282816
comment:
  When the grammar contains the following definition:

  PEG DDL (Definition)
          Definition <- (!(<space> / '{') .)+;
  END;


  then pt::pgen crashes with the below error. It works as expected if { is used instead of }. As a workaround, this also seems to work:

      Definition <- (!(<space> / [{ ]) .)+;

  ============================================
  unmatched open brace in list
      while executing
  "llength $args"
      (procedure "FuseClass" line 30)
      invoked from within
  "FuseClass"
      (procedure "::pt::pe::op::FuseChars" line 36)
      invoked from within
  "::pt::pe::op::FuseChars {/ space {t \{}} / {space {t \{}}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel $level [list {*}$cmdprefix $pe $op $ar]"
      (procedure "Bottomup" line 19)
      invoked from within
  "Bottomup $clevel $cmdprefix $a"
      (procedure "Bottomup" line 11)
      invoked from within
  "Bottomup $clevel $cmdprefix $a"
      (procedure "Bottomup" line 11)
      invoked from within
  "Bottomup $clevel $cmdprefix $a"
      (procedure "Bottomup" line 11)
      invoked from within
  "Bottomup 2 $cmdprefix $pe"
      (procedure "::pt::pe::bottomup" line 2)
      invoked from within
  "pt::pe bottomup  [list [namespace current]::FuseChars]  $serial"
      (procedure "::pt::pe::op::fusechars" line 2)
      invoked from within
  "pt::pe::op fusechars  [pt::pe::op flatten  $is]"
      (procedure "::pt::peg::to::tclparam::convert" line 41)
      invoked from within
  "pt::peg::to::tclparam convert [lindex $args end]"
      (procedure "::pt::pgen::Write::snit" line 8)
      invoked from within
  "Write {*}$args [pt::peg::from::peg convert $input]"
      (procedure "::pt::pgen::peg" line 3)
      invoked from within
  "pt::pgen peg [fileutil::cat pterr.peg] snit -class DDLParser -name DDL"
      (file "ddlparser.tcl" line 49)
      invoked from within
  "source ddlparser.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 {source ddlparser.tcl}"
  ==================================================


tkt_uuid: bf65cfc1c77f3035973de0dda7653948202211a9
type: RFE
status: Closed
resolution: Accepted
subsystem: textutil
priority: 5 Medium
severity: Minor
private_contact: 2caf797de13248fb0c6ec498502ae2197d48be0f
title: Function to apply a patch in unified diff format
cmimetype: text/html
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458661.39010128
comment:
  The unified diff format (diff -ruN) has become the standard way to distribute source code patches. A function to apply patches to directory trees is very useful for software such as build tools. <a href="http://wiki.tcl.tk/12586">http://wiki.tcl.tk/12586</a> contains a proc at the bottom, which does can apply a patch to a directory tree. I'm submitting it for inclusion into tcllib.


tkt_uuid: 13d8e3ca0689b7cc5be555c9ee44c39862d0c7cc
type: Patch
status: Open
resolution: None
subsystem: websocket
priority: 7 High
severity: Important
foundin: tcl 8.6/lib 1.17
private_contact: 6aef60af72eb2ee55933613c8aa5bbd088f96843
title: websocket serve: clean close handshake
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  I've noticed Firefox always complain about "failed websocket connection" when using ::webslocket $socket close from the server side.

  Reason:

   set Connection(state) CLOSED
   if { $code == "" || ![string is integer $code] } {
     send $sock 8

  but of course send does refuse to send anything while in state CLOSED ...

  Furthermore, the server needs to wait for the client to complete the close handshake.

  Proposed fix:

  --- ../tmp/tcllib-tcllib_1_17/modules/websocket/websocket.tcl   2015-04-30 06:21:20.000000000 +0200
  +++ websocket-tcllib.tcl        2015-10-22 19:23:01.727986813 +0200
  @@ -113,6 +113,7 @@
   #       None.
   proc ::websocket::Disconnect { sock } {
       variable WS
  +    variable log
   
       set varname [namespace current]::Connection_$sock
       upvar \#0 $varname Connection
  @@ -120,6 +121,7 @@
       if { $Connection(liveness) ne "" } {
          after cancel $Connection(liveness)
       }
  +    ${log}::debug "disconnect $sock"
       Push $sock disconnect "Disconnected from remote end"
       catch {::close $sock}
       unset $varname
  @@ -155,13 +157,17 @@
   
       if { $Connection(state) eq "CLOSED" } {
          ${log}::notice "Connection already closed"
  +       if {$code != 1000} {
  +           # possibly an error while waiting for close handshake => force disconnect
  +           Disconnect $sock
  +       }
          return
       }
  -    set Connection(state) CLOSED
   
       if { $code == "" || ![string is integer $code] } {
          send $sock 8
          ${log}::info "Closing web socket"
  +       set Connection(state) CLOSED
          Push $sock close {}
       } else {
          if { $reason eq "" } {
  @@ -183,10 +189,10 @@
          set msg [string range $msg 0 124];  # Cut answer to make sure it fits!
          send $sock 8 $msg
          ${log}::info "Closing web socket: $code ($reason)"
  +       set Connection(state) CLOSED
          Push $sock close [list $code $reason]
       }
  -    
  -    Disconnect $sock
  +    # Keep Socket open to recieve close handshake!
   }
   
   
  @@ -869,11 +875,18 @@
       # continuation frame, fragmented or oversized control frame, or
       # the opcode is unrecognised.
       if { [catch {read $sock 2} dta] || [string length $dta] != 2 } {
  +       set closed false
          if {[chan eof $sock]} {
              set dta "Socket closed."
  +           set closed true
          }
          ${log}::error "Cannot read header from socket: $dta"
  -       close $sock 1001
  +       if {$closed} {
  +           # connection lost can't do close handshake
  +           Disconnect $sock
  +       } else {
  +           close $sock 1001
  +       }
          return
       }
       binary scan $dta Su header
  @@ -993,6 +1006,9 @@
                  } else {
                      close $sock 
                  }
  +               # recieved close and sent handshake, now we can close the
  +               # socket
  +               Disconnect $sock
                  return
              }
              9 {


tkt_uuid: 758754cbccc4b1ab41e05b827bfa236325c9e912
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 9 Immediate
severity: Severe
foundin: 1.17
title: Missing return statement in parsetools peg C implementation
cmimetype: text/plain
submitter: apnadkarni
assignee: aku
closer: aku
closedate: 2457336.72629098
comment:
  The function
                  SCOPE long int
                  rde_param_query_lstop (RDE_PARAM p)
                  {
                      (long int) rde_stack_top (p->LS);
                  }
  In pt_parse_peg_c.tcl is missing a return statement. Pointed out by the compiler and a genuine bug I think given how it is used.

  Changing that to "return (long int) ..." seems to be the fix though I"m not sure if some parse token would need to be popped off the stack.


tkt_uuid: 6bdf679832112c1adc71ad7ed55c38bd7618e8e3
type: Bug
status: Closed
resolution: Fixed
subsystem: debug
priority: 7 High
severity: Important
foundin: 1.0.5
private_contact: 1c57e67924247fd7926e89348f266c081ec57db2
title: debug::2array reports inactive tags as active
cmimetype: text/x-fossil-wiki
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457336.67293983
comment:
  There is a typo in debug::2async which causes it to report inactive tags as active. The line:

  <blockquote><code>
  if {[interp alias {} debug.$n] ne "::Debug::noop"}
  </code></blockquote>

  should be changed to:

  <blockquote><code>
  if {[interp alias {} debug.$n] ne "::debug::noop"} {
  </code></blockquote>

  This can be demonstrated with the following script:

  <blockquote><code>
  package require debug<br>
  debug define mytag<br>
  puts [debug 2array]
  </code></blockquote>

  which produces the output:

  <blockquote><code>
  mytag 1
  </blockquote></code>

  instead of the desired output:

  <blockquote><code>
  mytag -1
  </blockquote></code>

  Also, please consider changing the formatting of the man page entry for the command:

  <blockquote>
  debug.tag message ?level?
  </blockquote>

  to display "tag" in italics if possible. This would make it clear that "tag" is the name of a tag and not the literal word "tag".


tkt_uuid: 4811399edce1b2ef306b93141169d921ef833f8d
type: Bug
status: Open
resolution: None
subsystem: comm
priority: 5 Medium
severity: Minor
foundin: 4.6.3.1
private_contact: 1c57e67924247fd7926e89348f266c081ec57db2
title: comm disconnect after race condition
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  When 2 incoming connections are received simultaneously, comm displays a race condition warning. If the connections are from the same process, an error is displayed when the process disconnects.

  To replicate, run the following scripts in tclsh:

  Server:

      package require comm
      ::comm::comm configure -port 5000
      vwait forever

  Client:

      package require comm

      proc mysocket {host port} {
          set sock [socket -async $host $port]
          update
          return $sock
      }
      
      ::comm::comm config -socketcmd mysocket -listen 0
      
      after 0 [list ::comm::comm send {5000 localhost} pid]
      after 0 [list ::comm::comm send {5000 localhost} pid]
      
      after 1000 set forever 1
      vwait forever

  This produces the following output on the server:

      commIncoming race condition: 0
      peers=sock0000000002CC4FB0 port=5000
      can't read "comm(::comm::comm,pending,0)": no such element in array
          while executing
      "foreach s $comm($chan,pending,$id) {
              if {[string equal "callback" [lindex $s end]]} {
                  set ser [lindex $s 0]
                  if {[info exists comm($chan,ret..."
          (procedure "commLostConn" line 14)
          invoked from within
      "commLostConn $chan $fid "target application died or connection lost""
          (procedure "::comm::commCollect" line 12)
          invoked from within
      "::comm::commCollect ::comm::comm sock0000000002CC4E30"

  The warning message is distracting since the user can't prevent the condition, but the error message should definitely be removed.


tkt_uuid: 221180c14b199645a08f4e93aacaca424ada3f67
type: Patch
status: Closed
resolution: Accepted
subsystem: oo::util
priority: 5 Medium
severity: Minor
foundin: 0.1
private_contact: f6b536f9c1ed4b589e96e38fb613afc3d8991783
title: Making the dialect code less miserable
cmimetype: text/x-fossil-wiki
submitter: anonymous
assignee: hypnotoad
closer: hypnotoad
closedate: 2457342.13220594
comment:
  Here's a patch that I consider to make things rather less miserable than they were before. The new version of the code tries to avoid doing things with text substitutions, and instead makes much more use of aliases and shim procedures.

  I hope you have a test suite for the dialect code ready before applying this patch. ;-)


tkt_uuid: 187a6fa7ae129ab84ae4819df9790929c849f3b1
type: Patch
status: Open
resolution: None
subsystem: dns
priority: 5 Medium
severity: Minor
foundin: 1.17
private_contact: 2429c1df3ffdc4da232832d3a6823096d8081d4c
title: DNS client not handling partial TCP responses correctly
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  The proc ::dns::TcpEvent assumes that it has received at least 2 bytes for the response size when a readable event is triggered. In my particular case 1 byte arrived which triggered a read event. In this case the state(size) was not correctly populated and caused an exception. The patch below corrects this issue.


  --- /tmp/SBo/tcllib-1.17/modules/dns/dns.tcl	2015-04-15 17:13:52.000000000 -0400
  +++ dns.tcl	2015-11-16 12:31:57.000000000 -0500
  @@ -828,31 +828,37 @@
           ${log}::debug "Event error: $result"
           Finish $token "error reading data: $result"
       } elseif { [string length $result] >= 0 } {
  -        if {[catch {
  -            # Handle incomplete reads - check the size and keep reading.
  -            if {![info exists state(size)]} {
  -                binary scan $result S state(size)
  -                set result [string range $result 2 end]            
  -            }
  -            append state(reply) $result
  -            
  -            # check the length and flags and chop off the tcp length prefix.
  -            if {[string length $state(reply)] >= $state(size)} {
  -                binary scan $result S id
  -                set id [expr {$id & 0xFFFF}]
  -                if {$id != [expr {$state(id) & 0xFFFF}]} {
  -                    ${log}::error "received packed with incorrect id"
  -                }
  -                # bug #1158037 - doing this causes problems > 65535 requests!
  -                #Receive [namespace current]::$id
  -                Receive $token
  +
  +        upvar 0 state(reply) reply
  +        append reply $result
  +
  +        if {![info exists state(size)]} {
  +            if {[string length $reply] >= 2} {
  +                binary scan $reply S state(size)
  +                set reply [string range $reply 2 end]
               } else {
  -                ${log}::debug "Incomplete tcp read:\
  -                   [string length $state(reply)] should be $state(size)"
  +                # wait for more data
  +                return
               }
  -        } err]} {
  -            Finish $token "Event error: $err"
           }
  +        
  +        if {[string length $reply] < $state(size)} {
  +            # wait for more data
  +            return
  +        }
  +
  +        if {[binary scan $reply S id] != 1} {
  +            Finish $token "Event error: reply too short"
  +            return
  +        }
  +
  +        if {[expr {($id & 0xffff) != ($state(id) & 0xffff)}]} {
  +            Finish $token "Event error: mismatched reply id"
  +            return
  +        }
  +
  +        Receive $token
  +
       } elseif { [eof $state(sock)] } {
           Eof $token
       } elseif { [fblocked $state(sock)] } {


tkt_uuid: 5f4f30667b4bc066593e0aa37ddf88b62e1830b5
type: Bug
status: Closed
resolution: Duplicate
subsystem: ldap
priority: 8
severity: Critical
foundin: 1.8
private_contact: 764f212e7a55ae201b7fd3bd304f960311089db7
title: Error from LDAP package when requesting a larger base64 encoded JPEG image
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458143.33502575
comment:
  When requesting a larger base64 encoded JPEG image (2458481 Byte JPG / 3363119 Byte Base64) from LDAP server (OpenLDAP) you'll get this error message:
  ---8< ------------------------------------------------------------------------------------------ snip! ---
  Connected to LDAP: ldap-xyz.de:636
  Protocol error: Error reading LENGTH1 response for handle ::ldap::ldapsock6 : partial
      while executing
  "WaitForResponse $handle $conn(searchInProgress)"
      (procedure "searchNext" line 17)
      invoked from within
  "searchNext $handle"
      (procedure "::ldap::search" line 12)
      invoked from within
  "::ldap::search $handle $CONF(ldap,branch) (uid=test) {uniXYZNumber uniXYZCardNumber jpegPhoto}"
  ---8< ------------------------------------------------------------------------------------------ snap! ---

  When requesting this data with "ldapsearch" command, you'll get the complete document,  e.g.
  ---8< ------------------------------------------------------------------------------------------ snip! ---
  ldapsearch -Wx -H ldaps://ldap-xyz/ -b ou=campus,dc=xyz,dc=de -D uid=abc,ou=uni,ou=campus,dc=xyz,dc=de uid=test
  ---8< ------------------------------------------------------------------------------------------ snap! ---


tkt_uuid: 751707e0ae7811aaa48d11251b036f2fb11d9948
type: RFE
status: Open
resolution: None
subsystem: logger
priority: 5 Medium
severity: Minor
foundin: 0.9.3
private_contact: 3410fe6f8504d01909e548b02e0cec50a5f7fab3
title: logger::logproc should accept command prefixes
cmimetype: text/plain
submitter: anonymous
assignee: schlenk
closer: nobody
comment:
  As of current, the argument for ${log}::logproc must be a command name.  This makes overriding logprocs for all levels difficult if a dispatcher command is to be used.  Although a wrapper procedure can be built with ::apply, supporting command prefixes would make it easier to provide additional data to the logprocs.  See, for example:

      foreach level [::logger::levels] {
          log::logproc $level \
              [list ::apply [list {level} { msg $level; } [::namespace current]] $level];
      }

  If ${log}::logproc supported command prefixes, it could be rewritten as follows:

      foreach level [::logger::levels] {
          log::logproc $level \
               [list [::namespace current]::msg $level];
      }


  This change would also support the use case http://core.tcl.tk/tcllib/tktview?name=1113348fff, as the service name could be passed as a parameter.


tkt_uuid: e048d94427a1c479213ffa91bf36be7546a2b464
type: Bug
status: Open
resolution: None
subsystem: term
priority: 5 Medium
severity: Important
foundin: 1.17-dfsg-1 (debian)
private_contact: a8fafc46bb17fd6a80f858bd8d8f7637bc437820
title: ::term::ansi::ctrl::unix terminal dimensions functions work incorrectly
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  This seems to be utilizing tput, and assuming that tput uses stdin to get it's parameters, but that seems to not be the case. And things like:

  echo 'puts [exec tput lines]' | tclsh

  does not work (nor does it in script), same with:

  ::term::ansi::ctrl::unix::columns
  ::term::ansi::ctrl::unix::rows

  "tput lines", though, works on interactive tclsh. This was rather nasty thing, but #tcl user rkeene helped me to find workaround/fix to this:

  echo 'puts [exec tput lines 2>@ stderr]' | tclsh

  works, as does:

  echo 'puts [exec -ignorestderr tput lines]' | tclsh

  (of course works in script too) so it seems (as far as I understand) tput needs to be connected to tty's stderr to work correctly. Currently tcllib functions always return 80 for columns and 24 for rows. And current solution to this is rather obscure to say the least...


tkt_uuid: 284fd715e4fc6d5d3cb8a0409647b5f09058513a
type: RFE
status: Closed
resolution: Accepted
subsystem: rest
priority: 6
severity: Minor
foundin: 1.0.1
private_contact: 58f887df7a5535e3b8880f7c79a0749aa427e061
title: Return $result on HTTP Error
cmimetype: text/plain
submitter: scorriere
assignee: aku
closer: aku
closedate: 2457450.76783292
comment:
  I am looking into using the rest package for testing our REST API.  For testing purposes, we will want to create error situations.  When the rest calls hit a non 2xx HTTP response, an error is returned.  The error message only contains the HTTP response code in the form of "HTTP <code>".

  We would like to get the body($result) back with the response code.  Even though the return code specifies an error, there is useful data in the body of the response.


tkt_uuid: dbde846f53311094d46091e5a2ebfc6de606bfdc
type: Bug
status: Open
resolution: None
subsystem: imap4
priority: 7 High
severity: Important
foundin: 1.17
private_contact: 5f3d227cd2211939d78ccb0b18f723aa3e78547a
title: imap4 fails
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  There's an error when tring to import the imap4 package:
  package require imap4;

  Result was:
  can't read "argv0": no such variable


tkt_uuid: 6e778502b8990f3255ef4cbd83f18770fd967966
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: list
priority: 5 Medium
severity: Severe
foundin: 1.8.3
private_contact: d3087a52abea86234116c6d0fc932ab13864ef48
title: struct::list flatten, the "--" option breaks it
cmimetype: text/plain
submitter: glennj
assignee: andrewm
closer: aku
closedate: 2458540.7571602
comment:
  % package require struct::list
  1.8.3
  % set List1 {1 2 {3 4 5} 6 7 {8} 9 10 {{11 12} 13} 14 {15} 16 {{{{17} 18} 19} 20} 21 22 {23} 24 25}
  1 2 {3 4 5} 6 7 {8} 9 10 {{11 12} 13} 14 {15} 16 {{{{17} 18} 19} 20} 21 22 {23} 24 25
  % struct::list flatten $List1
  1 2 3 4 5 6 7 8 9 10 {11 12} 13 14 15 16 {{{17} 18} 19} 20 21 22 23 24 25
  % struct::list flatten -full $List1
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
  % # OK so far. But ...
  % struct::list flatten -full -- $List1
  wrong#args: should be "::struct::list::Lflatten ?-full? ?--? sequence"
  % struct::list flatten -- $List1
  wrong#args: should be "::struct::list::Lflatten ?-full? ?--? sequence"


tkt_uuid: 4adb7c36a35d0c475f8e9bba24ec04984bd8ce2f
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil :: magic
priority: 5 Medium
severity: Important
foundin: various
private_contact: ba41b53937d1b9ca694410bc8480be0835223608
title: TCL fileutil::magic::mimetype not recognising Microsoft documents or mp3
cmimetype: text/plain
submitter: anonymous
closer: pooryorick
closedate: 2458359.07650878
comment:
  I got directed here from a Stack Overflow question I raised https://stackoverflow.com/questions/34746759/tcl-fileutilmagicmimetype-not-recognising-microsoft-documents-or-mp3

  Take an ordinary Microsoft Word .doc file and pass it to fileutil::magic::mimetype e.g.

  package require fileutil
  package require fileutil::magic::mimetype
  set result [fileutil::magic::mimetype "/tmp/test.doc"]

  It returns empty string. 
  Same happens if you try mp3, wmv plus other Microsoft file formats (xls, ppt etc). In fact, the only file formats that seem to work well are images (png, gif, tiff etc)


tkt_uuid: deef12251a28b85978959a2a6ae03514f24395bc
type: Bug
status: Open
resolution: None
subsystem: zip
priority: 7 High
severity: Severe
foundin: trunk
private_contact: 4ca203a8e925aecdd9419645f936bccf18cd6ea7
title: Depending on input file, zipfile:mkzip::mkzip may raise error
cmimetype: text/plain
submitter: pointsman
assignee: hypnotoad
closer: nobody
comment:
  Due to the behaviour of the zlib core cmd documented by 
  http://core.tcl.tk/tcl/tktview/25842c161fd621d8d111430a3637688f55aeaa94 the tcllib cmd zipfile:mkzip::mkzip may raise error, depending on the data to process. (In fact, I got bitten by this in the wild.)

  Even if the zlib behaviour is changed to do nothing, gracefully in this case (which seems sensible for me) the mkzip cmd code should protect against this for tcllib compatibility with older 8.6 versions.

  The fix should be obviously: Check for zero length input to [$zlib put] in proc ::zipfile::mkzip::add_file_to_archive


tkt_uuid: 63a49163a84bb9e167a0e023a21a6f7ba5495a23
type: Bug
status: Closed
resolution: Accepted
subsystem: rest
priority: 5 Medium
severity: Minor
foundin: 1.0.1, 1.0.2
private_contact: 310273a9a9308c961b73e79a87acdf09488aea25
title: User defined callbacks with more than three args fail on error
cmimetype: text/plain
submitter: Wrenky
assignee: aku
closer: aku
closedate: 2457443.76489683
comment:
  When defining user callbacks in an interface, we often set callbacks with more than three args like so:
  ==================================================
  proc callbackHandler {extraArg method code response} {
  ...
  }

  set test(issue) [list\
      method get\
      url "https://url/that/ /"\
      auth basic\
      content-type "application-type"\
      callback [list callbackHandler "extra arg"]\
      result json]

  ::rest::create_interface test
  ==================================================

  which works great on data callbacks! On error callbacks it fails though due to how it is called in the ::rest::_callback method. The first argument isn't expanded so we get a generic sock error.. Expanding the argument with {*} rule (see attached 1.0.1 patch) fixes this.

  Patch attached only works for 1.0.1 as the line numbers are for that revision, but 1.0.2 as the same problem and the same solution will fix it.


tkt_uuid: 684329c01b10e85ace53e11419a710f10753c874
type: Bug
status: Closed
resolution: Fixed
subsystem: exif
priority: 5 Medium
severity: Minor
title: local exif documentation in tcllib missing
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457442.9214262
comment:
  exif documentation missing in tcllib

  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/exif/exif.html

  Document embedded/www/tcllib/files/modules/exif/exif.html not found in trunk


tkt_uuid: 4842c9ce0b2d86d2ddf0c8cdffd9e6ed009bbfb1
type: Bug
status: Open
resolution: None
subsystem: uuid
priority: 7 High
severity: Important
foundin: 1.18
private_contact: 2bd1b33f8d228f908ba3874a46b83792ec992764
title: ::uuid::uuid generate: couldn't execute "ifconfig": no such file or directory
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  'ifconfig' is located in /sbin (OpenSuSe) and not listed in PATH.

  couldn't execute "ifconfig": no such file or directory
      while executing
  "exec ifconfig"
      (procedure "dump" line 2)
      invoked from within
  "dump"
      (procedure "::nettool::mac_list" line 3)
      invoked from within
  "::nettool::mac_list"
      (procedure "::nettool::hwid_list" line 3)
      invoked from within
  "::nettool::hwid_list"
      (procedure "generate_tcl_machinfo" line 36)
      invoked from within
  "generate_tcl_machinfo"
      (procedure "generate_tcl" line 7)
      invoked from within
  "generate_tcl"
      (procedure "generate" line 6)
      invoked from within
  "generate"
      (procedure "::uuid::uuid" line 7)
      invoked from within
  "::uuid::uuid generate"


tkt_uuid: f990aa37bc6b6f0606026bb30788c9a4bd63a70f
type: Bug
status: Open
resolution: None
subsystem: oo::util
priority: 5 Medium
severity: Minor
foundin: 1.2.2
private_contact: 73806aaa17b0530df9957e457974f007e07b7602
title: oo::classmethod inherited only once
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Classmethod is inherited (visible) in a direct subclass, but not in the subclass of that subclass. 

  The following fragment demonstrates the problem:


  # **** TEST.tcl ****
  package require oo::util

  oo::class create MyClass {
  	classmethod clm {} {
  		puts "Hello"
  	}
  }

  oo::class create MySubclass {
  	superclass MyClass
  }

  oo::class create MySubSubclass {
  	superclass MySubclass
  }

  MySubclass clm ; # ok, will work as expected
  MySubSubclass clm ; # unknown method error!
   
  # *** END TEST.tcl ***

  Workaround: Redefine classmethods in every other subclass, which is not a nice solution.


tkt_uuid: 042d583738433af238f78c1bef820a06012b3be9
type: Bug
status: Open
resolution: None
subsystem: Documentation
priority: 5 Medium
severity: Important
foundin: 1.18
title: Documentation bugs - oometa, tool, cluster, ooutil, processman, try
cmimetype: text/plain
submitter: apnadkarni
assignee: hypnotoad
closer: nobody
comment:
  The Table of contents at http://core.tcl.tk/tcllib/doc/trunk/embedded/www/toc.html 

  - does not show any documentation pages for oometa and nns::cluster.

  - the summary for the tool package says "Dictionary tools" instead of the real description

  - there are two links to the oo::util package. One points to meta.html but the content is same as the oo::util page.

  - the ToC description of processman says "Tool for automating the period callback of commands" which is a cut'n'paste from the cron package

  - there are two pages labeled "try". One should actually be "throw"

  - there are two pages labeled tcldes. One should be "tclDESjr"


tkt_uuid: a0e091b25d27428a84e527006c87b87b89175596
type: Bug
status: Closed
resolution: Fixed
subsystem: tepam
priority: 5 Medium
severity: Minor
foundin: 0.5
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: misformatted description in auto-generated help text
cmimetype: text/plain
submitter: anonymous
assignee: droll
closer: droll
closedate: 2457452.83247595
comment:
  Below is a script that uses tepam to define a procedure with 5 sub-procedures.  When the -help flag is used to autogenerate a digest of the procedure, the sub-procedure names are not properly listed in the DESCRIPTION section of the help text. Note that "subproc5" is repeated as the name for each subproc.  The help digest text appears as:

  NAME
        bug::tproc
  SYNOPSIS
        bug::tproc subproc1
        bug::tproc subproc2
        bug::tproc subproc3
        bug::tproc subproc4
        bug::tproc subproc5
  DESCRIPTION
        bug::tproc subproc5
           desc1.
        bug::tproc subproc5
           desc2.
        bug::tproc subproc5
           desc 3.
        bug::tproc subproc5
           desc 4.
        bug::tproc subproc5
           desc 5.

  script:
  ##########

  package require tepam 0.5

  namespace eval ::bug {

  tepam::procedure {tproc subproc1} {
  	-description "desc1."
  } {}

  tepam::procedure {tproc subproc2} {
  	-description "desc2."
  } {}

  tepam::procedure {tproc subproc3} {
  	-description "desc 3."
  } {}

  tepam::procedure {tproc subproc4} {
  	-description "desc 4."
  } {}

  tepam::procedure {tproc subproc5} {
  	-description "desc 5."
  } {}

  }

  ##########


tkt_uuid: 6c33c2bcb3d27383396efe2abfa53f8c30bdd01e
type: Bug
status: Open
resolution: None
subsystem: zip
priority: 5 Medium
severity: Important
foundin: 0.3
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: zipfile::encode doesn't autogenerate command
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  According to the doc, when "zipfile::encode" is called without arguments, a command object is autogenerated.  However, when I try:

  % set myzip [zipfile::encode]
  wrong # args: should be "zipfile::encode subcommand ?arg ...?"


tkt_uuid: e7d1eeebb48912e5d4f2861630234f9a42d43e1b
type: RFE
status: Open
resolution: None
subsystem: rest
priority: 5 Medium
severity: Minor
foundin: 1.0.2
private_contact: 310273a9a9308c961b73e79a87acdf09488aea25
title: Dynamic callbacks without re-creating the interface
cmimetype: text/plain
submitter: Wrenky
assignee: nobody
closer: nobody
comment:
  With how ::rest works now, you can define a single callback for a route. The only ways to get a different callback then configured in the ::rest::create step is to recreate the entire interface! Example:
  =====================================================================
  proc callback {method code response} {
  ...
  }

  set test(issue) [list\
      method get\
      url "http://basicUrl.com/routes/"\
      auth basic\
      content-type "application-type"\
      callback callback\
      result json]

  ::rest::create_interface test

  after 5000 {set done 1}
  ::test::issue ;# Same callback
  ::test::issue ;# Same callback again
  ::test::issue ;# Same callback again
  vwait done

  =====================================================================
  All three ::test::issue calls above will call the same callback- It would be great if we could have some way to dynamically control that like we can with URL arguments! We've gotten around this lack of functionality like so:
  =====================================================================
  # Assoc. array to store callbacks
  array set callbackHandler [list]

  proc callbackDispatcher {method code {response ""}} {
      upvar token token
      set mySock $token(sock)
      puts "I should call: ::callbackHandler($mySock) == $::callbackHandler($mySock)"
     {*}$::callbackHandler($mySock) $method $code $response
      unset ::callbackHandler($mySock)
  }

  proc otherCallback {method code {response "-"}} {
      puts "othercallback"
      puts "\tArg Method: --$method--"
      puts "\tArg Code:   --$code--"
  }

  proc otherCallback_2 {name method code {response "-"}} {
      upvar token token
      puts "otherCallback_2"
      puts "\tArg Name:   --$name--"
      puts "\tArg Method: --$method--"
      puts "\tArg Code:   --$code--"
  }


  set test(issue) [list\
      method get\
      url "http://basicUrl.com/routes/"\
      auth basic\
      content-type "application-type"\
      callback callbackDispatcher\
      result json]

  ::rest::create_interface test

  after 5000 {set done 1}
  set myTok [::test::issue]
  upvar 0 $myTok httpToken
  set callbackHandler($httpToken(sock)) otherCallback


  set myTok2 [::test::issue]
  upvar 0 $myTok2 httpToken2
  set callbackHandler($httpToken2(sock)) [list otherCallback_2 "otherVar"]

  vwait done
  =====================================================================
  Which allows us dynamic callbacks! Its a little strange to rely on the http sock as our unique identifier but there is nothing else unique in the http token array.

  If we could instead do something like
  =====================================================================
  ::test::issue -callback otherCallback
  ::test::issue -callback [list otherCallback_2 "otherVar"]
  =====================================================================
  in addition to the URL arguments that would be awesome! If that's not possible, getting a unique identifier in the http token that isn't a socket handle would be nice as well :)


tkt_uuid: 682ca9b2e16bd86754a6117e2d314eae88ef9c81
type: RFE
status: Open
resolution: None
subsystem: rest
priority: 5 Medium
severity: Cosmetic
foundin: 1.0.2
private_contact: 310273a9a9308c961b73e79a87acdf09488aea25
title: Variables in the middle of a URL
cmimetype: text/plain
submitter: Wrenky
assignee: nobody
closer: nobody
comment:
  ::rest has the ability to handle URL arguments very well like so:
  =======================================================
  set google(search) [list\
      method get\
      url "https://ajax.googleapis.com/ajax/services/search/web"\
      req_args [list q:]\
      static_args [list v 1.0]\
      result json]

  ::rest::create_interface google
  set response [::google::search -q "tcllib"]
  =======================================================

  Turns out rest can also handle argument embedded INSIDE the URL, but its undocumented- if you add %varname% to the URL, the rest package will treat it as an argument to the point where the following works:
  =======================================================
  set jira(issue) [list\
      method get\
      url "https://jira.blank.com/rest/api/2/issue/%issueId%/otherPath/thing/"\
      auth basic\
      content-type "application-type"\
      callback myCallback\
      result json]

  ::rest::create_interface jira

  after 5000 {set ::done 1}
  ::jira::issue -issueId JIRA-1234
  ::jira::issue -issueId JIRA-1235
  vwait done
  =======================================================
  Which is awesome! What is not so awesome is that the ::rest::describe function does not recognize this argument, and its mostly undocumented. The only mention of this behavior in the docs is ::rest::substitute, but it only describes this exact substitution functionality. What isn't clear is that this is run on every URL. Its extremely useful (some of our internal routes of variables right in the middle:/) but it took us reading the rest.tcl code to understand this.


  You also cant replicate this behavior with the standard req/static args functionality, the only way to get arguments in the middle of a URL is this (awesome)hidden method. Could the documents reflect this functionality, and somehow let ::rest::describe know about it? Or if its unintended behavior, could we have a method to do this?


tkt_uuid: 83567329c96e234dce429b97c3c0828285d2f7f3
type: RFE
status: Open
resolution: None
subsystem: pki
priority: 3 Low
severity: Cosmetic
foundin: 0.6
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: suggest clarification of pki docs about proc input types
cmimetype: text/plain
submitter: anonymous
assignee: rkeene
closer: nobody
comment:
  Re: the man page for the pki module; coming from using openssl, I assumed that the input for procs such as ::pki::x509::parse_cert, when calling for "cert", referred to a certificate file name.  After getting errors and looking more closely at the code, I realized that "cert" was expected to be a variable containing the actual binary or base64-encoded data.

  This is not technically incorrect since the cert is the data and not the file created by (e.g.) openssl to contain it.  But I think it would be helpful to first-time users if the docs used phrases like "binary or base64-encoded contents of a certificate", rather than  simply "certificate".


tkt_uuid: 21c45cb4c4bff37adeac400189809c7f25cea1ea
type: Bug
status: Closed
resolution: Fixed
subsystem: tepam
priority: 5 Medium
severity: Minor
foundin: 0.5.1
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: TEPAM doesn't require Tk package before using Tk commands
cmimetype: text/plain
submitter: anonymous
assignee: droll
closer: droll
closedate: 2457614.81498181
comment:
  When I try to use the "-interactive" switch when calling a TEPAM procedure, I get the error copied below, because there is no "package require Tk" command before attempting to use Tk commands to create the interactive window.

  invalid command name "image"
      while executing
  "image names"
      (procedure "GuiEnvironmentInit" line 2)
      invoked from within
  "GuiEnvironmentInit"
      (procedure "argument_dialogbox" line 6)
      invoked from within
  "argument_dialogbox $DialogBoxArguments"
      (procedure "::tepam::ProcedureArgumentEvaluation" line 190)
      invoked from within
  "::tepam::ProcedureArgumentEvaluation"
      (procedure "::novasign::cli::generate_key" line 1)
      invoked from within
  "::novasign::cli::generate_key -alias test -interactive"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 {::novasign::cli::generate_key -alias test -interactive}"


tkt_uuid: e67cc435c53abfa25d62e2c5c9bc783979ad0f1b
type: Bug
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 5 Medium
severity: Cosmetic
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: Tcllib web site: "Tickets" menu item a dead link from home page
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457632.47010854
comment:
  The tcllib home URL redirects to "https://core.tcl.tk/tcllib/doc/trunk/embedded/index.html". If I click on the "Tickets" menu bar item from that URL, I get a "Not Found" error page with text: "Document embedded/reportlist not found in trunk"

  If however I go to another page from the menu item that's not a sub-location of "https://core.tcl.tk/tcllib/doc/trunk/embedded", such as the "Timeline" link, then from e.g. the timeline page the "Tickets" menu item link will work and take me to the tickets page.


tkt_uuid: dc49af96c220067543586c9c8a07b1838253a272
type: Bug
status: Closed
resolution: None
subsystem: math :: geometry
priority: 5 Medium
severity: Important
foundin: 1.1.3
private_contact: ed370a9a39466fe318de149a10eda29075002199
title: ::math::geometry::pointInsidePolygon sometimes gives wrong result
cmimetype: text/plain
submitter: peterlewerin
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2457490.8144449
comment:
  For the polygons

  set ::polygons {
      "-764 -677 -668 -1341 -124 -797 -508 -406"
      "764 -677 668 -1341 124 -797 508 -406"
      "-764 677 -668 1341 -124 797 -508 406"
      "764 677 668 1341 124 797 508 406"
  }

  and the point

  set point "838 456"

  lmap polygon $polygons {::math::geometry::pointInsidePolygon $point $polygon}

  returns

  1 0 0 0

  while it should be 0 0 0 0 since the point is outside all polygons. The error seems to be caused by a dubious calculation of the value of the variable pointFarAway inside the command. While the x coordinate is -640 for all the polygons, the y is -1300.4 for the first two polygons and 271.9 for the last two. This means that the pointFarAway is inside the polygon for the first polygon.

  See comp.lang.tcl thread https://groups.google.com/forum/#!topic/comp.lang.tcl/FYAhQ2iLRiE


tkt_uuid: 3bb067b6674eb84247a8f473eded22f4681a76ef
type: Bug
status: Open
resolution: None
subsystem: snit
priority: 5 Medium
severity: Important
foundin: 2.3.1
private_contact: 21780c4e03cc5884af69addd6efc1b71c50d9818
title: package load failure
cmimetype: text/plain
submitter: griffin
assignee: nobody
closer: nobody
comment:
  In snit2.tcl:

  namespace eval ::snit:: {
      set library [file dirname [info script]]
  }

  If the variable ::library exists before executing [package require snit], then the global library will be set, not a namespace variable.  The package will then fail to load:

  $ tclsh8.5
  % set library "of congress"
  of congress
  % package require snit
  can't read "::snit::library": no such variable
  % unset library
  % package require snit
  2.3.1
  % 

  The code should read:

  namespace eval ::snit {
      variable library [file dirname [info script]]
  }


tkt_uuid: 6bef0b5d0fc38991e97f9e45a514108c218573a0
type: Bug
status: Open
resolution: None
subsystem: bibtex
priority: 5 Medium
severity: Important
foundin: 0.5
private_contact: 885ae311f5fce05c2a8d9c31d2d2a1b5638ca9df
title: bibtex package doesn't parse entries correctly
cmimetype: text/plain
submitter: emiliano
assignee: nobody
closer: nobody
comment:
  If an entry contains the literal words "comment", "strings" or "preamble" they are incorrectly processed as one of these types of entries.

  The problem is in the regex that selects the type of entry; it is not contrained to look for these words only at the beginning of the record.


tkt_uuid: 76045b938d0a284352066a8d358a74a0250d3626
type: RFE
status: Open
resolution: None
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 0.1
private_contact: 1c4b6cdb98c9dfc4d1e74018f3f4efa00ad217e2
title: New selenium library
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  I would like to add to tcllib my selenium library for Tcl. I don't know whether this is possible. It's very complete and I am using in production. I have to improve the tutorial. There is a "Getting started" file now.

  https://sourceforge.net/projects/selenium-tcl/


tkt_uuid: 002b9e8e07777425a8ce4a36edec489e24d3818f
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: statistics
priority: 5 Medium
severity: Critical
private_contact: e9099fd1362553c412a7f18a132b64a12d4576ed
title: Wrong Arguments in lognormal distribution
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2457617.80458284
comment:
  ::math::statistics::pdf-lognormal and proc ::math::statistics::cdf-normal 
  needs as Argument {mean , varianz and x} and not {mean , stdev, x} !
  Because Stdev ist the sqard of Varianz.

  if they want to have the stdev as Argument for the lognomal deviation, they need to set sigma to : 

  set sigma [expr {sqrt(log(1.0 + $stdev*$stdev /double($mean*$mean)))}]

  Best Regards


tkt_uuid: e937acfe0c9d32ef96bdd303ccf33cf18f6b2825
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Severe
foundin: 1.2.6
private_contact: 7e3820ed81064cf9306d34dd9be1633e66f1a08b
title: uri::join ignores credentials for HTTP protocol
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: kjnash
closedate: 2457757.25137772
comment:
  uri::join ignores credentials when joining:

  % ::uri::join {*}[::uri::split "http://anonymous:passw0rd@core.tcl.tk"]
  http://core.tcl.tk/

  ::uri::join and ::uri::split should reverse each other.


tkt_uuid: caba923b30da38a3cac08aff3ecdbd96fbe47b21
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: linearalgebra
priority: 5 Medium
severity: Critical
foundin: 1.1.5 of linearalgebra
private_contact: 052ce3e43cffe6eea20ff1df11df92b0ed8446be
title: Solving Simultaneous Equations inconsistent
cmimetype: text/plain
submitter: sergio
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2457617.80721265
comment:
  Let "mt1" and "b" be the matrix and vector of a system of linear equations:

  mt1*x = b (System 1)

  where x = (x1,x2,x3,x4) are the unknows of the system

  and "mt2", "b", the matrix and vector of the same system but with the order of the unknows changed:

  mt2*y = b (System 2)

  where y = (x2,x4,x3,x1)

  for the values in the following example, the solutions of System 1 and System 2 differ for solveGauss but not for solvePGauss. Solutions of System 2 with solveGauss and solvePGauss are almost identical and coincide with the solution obtained with numpy





  (HM13) 7 % package require math::linearalgebra
  1.1.5
  (HM13) 7 % set mt1 {{-0.0012585709756272178 -235219735842.05304 117609867921.10306 117609867921.10408} {-0.0007706083587115171 -0.0026517381941796457 42416766269.665436 -42416766269.66554} {1010999714627.5773 974275470171.4105 24625609209.839363 24625609209.839558} {450880107.9198128 1219061933.8972623 38265151.50552135 38265151.50552134}}
  {-0.0012585709756272178 -235219735842.05304 117609867921.10306 117609867921.10408} {-0.0007706083587115171 -0.0026517381941796457 42416766269.665436 -42416766269.66554} {1010999714627.5773 974275470171.4105 24625609209.839363 24625609209.839558} {450880107.9198128 1219061933.8972623 38265151.50552135 38265151.50552134}
  (HM13) 8 % set mt2 {{-235219735842.05304 117609867921.10408 117609867921.10306 -0.0012585709756272178} {-0.0026517381941796457 -42416766269.66554 42416766269.665436 -0.0007706083587115171} {974275470171.4105 24625609209.839558 24625609209.839363 1010999714627.5773} {1219061933.8972623 38265151.50552134 38265151.50552135 450880107.9198128}}
  {-235219735842.05304 117609867921.10408 117609867921.10306 -0.0012585709756272178} {-0.0026517381941796457 -42416766269.66554 42416766269.665436 -0.0007706083587115171} {974275470171.4105 24625609209.839558 24625609209.839363 1010999714627.5773} {1219061933.8972623 38265151.50552134 38265151.50552135 450880107.9198128}
  (HM13) 9 % set b {3848.0 0.0 20449.0 13.0}
  3848.0 0.0 20449.0 13.0
  (HM13) 10 % math::linearalgebra::solveGauss $mt1 $b
  1.6982058148140882e-8 2.8514750715307717e-9 1.921064657651454e-8 1.921064657651401e-8
  (HM13) 11 % math::linearalgebra::solveGauss $mt2 $b
  3.5603980701693165e-9 1.9919569575152068e-8 1.991956957515263e-8 1.5825057309843255e-8
  (HM13) 12 % math::linearalgebra::solvePGauss $mt1 $b
  1.582505730984325e-8 3.560398070169323e-9 1.9919569575152637e-8 1.9919569575152074e-8
  (HM13) 13 % math::linearalgebra::solvePGauss $mt2 $b
  3.560398070169323e-9 1.9919569575152078e-8 1.9919569575152637e-8 1.582505730984325e-8


tkt_uuid: 387599b3d8b34e06e42c3811646925dff911159e
type: Bug
status: Open
resolution: None
subsystem: csv
priority: 5 Medium
severity: Minor
foundin: 0.8.1
private_contact: 4ca203a8e925aecdd9419645f936bccf18cd6ea7
title: csv::split -alternate doesn't work as expected
cmimetype: text/plain
submitter: pointsman
assignee: aku
closer: nobody
comment:
  package require csv
  puts [csv::split -alternate {a;b""b;c} \;]

  => a b {;c}

  That is with csv 0.8.1 / tcl 8.6.5.

  Expected result:

  a b\"b c

  (as [csv::split {a;b""b;c} \;] does)

  I'm aware, that csv formating (and in turn parsing) is a somewhat
  vague area. So the csv::split -alternate parser does, what it does.

  But it's not only, that the result for this input is rather strange
  (what did eat the second "b" of the sample input, only to start with)
  and that all other csv parser, I tried, did a better job. I also
  think, that the result doesn't match what the documentation say
  (http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/csv/csv.html#section3)


tkt_uuid: 24f7b1df580591a3af123602d5abe1e587858382
type: Patch
status: Closed
resolution: Fixed
subsystem: Documentation
priority: 5 Medium
severity: Minor
private_contact: ddcc6cc0268ca9bcf72d55271cd13eed5a2aed13
title: Clarification of bee(n) 0.1 tcllib "BitTorrent" documentation
cmimetype: text/plain
submitter: hanzer
assignee: aku
closer: aku
closedate: 2457632.62672613
comment:
  http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/bee/bee.html

  Description

  - the serialization format for data and messages used by the BitTorrent application.
  + the serialization format for data and messages used by the BitTorrent protocol.


tkt_uuid: 6362dbd12b94ec655f7b9639216c03cd81f375ef
type: Bug
status: Open
resolution: None
subsystem: uri
priority: 5 Medium
severity: Important
foundin: 1.2.6
private_contact: 3410fe6f8504d01909e548b02e0cec50a5f7fab3
title: uri::split does not support Windows drives
cmimetype: text/plain
submitter: adrianmedranocalvo
assignee: aku
closer: nobody
comment:
  Windows drive names are not supported by uri::split:

  % ::uri::split T:/dir1/file1.txt file
  unknown scheme 'T' in 'T:/dir1/file1.txt'

  % ::uri::split file:///T:/dir1/file1.txt
  path /T:/dir1/file1.txt scheme file
  # should be
  # path T:/dir1/file1.txt scheme file


tkt_uuid: 715944a1f71855ab32424a2229d09674adfd4f64
type: Bug
status: Closed
resolution: Fixed
subsystem: json
priority: 9 Immediate
severity: Critical
foundin: 1.3.3
private_contact: 3cb4dabca0e1e7b9d560b2ca060abb67f2a97f23
title: json::json2dict from tcllibc is not thread safe
cmimetype: text/plain
submitter: petasis
assignee: aku
closer: aku
closedate: 2457635.5219253
comment:
  If the tcllibc package is available, json::json2dict will cause problems if multiple threads use it, as the underline implementation is not thread safe.
  To my understanding, a bison generated parser is used, which is not a "pure" one: instead it uses global symbols.


tkt_uuid: 94f5b24ea6e4ff9dc2d1168c226e267e82a4d152
type: Bug
status: Closed
resolution: Fixed
subsystem: yaml
priority: 6
severity: Important
foundin: 0.3.9
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: global variable leak in init code
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457635.52918059
comment:
  The code executed in the ::yaml namespace on package load uses a variable named "result", which is defined as an array via upvar when the yaml code calls ::cmdline::getOptionDefaults.

  The variable "result" is not created using the "variable" command within the ::yaml namespace.  The code runs fine unless a variable called "result" exists in the global namespace.  If global "result" is not an array, trying to load the yaml package results in an error.

  % set result 1
  % package require yaml
  can't set "result(file)": variable isn't array
  % unset result
  % package require yaml
  0.3.9


tkt_uuid: 9f1eda1887442dc98643f430a8d61455db338b1a
type: Bug
status: Open
resolution: None
subsystem: snit
priority: 5 Medium
severity: Minor
foundin: 2.3.2
private_contact: 4b969f40c67eaaa92fe1a4b7b2d5f1793818b23b
title: snit -option -default won't recognize global or namespaced variables
cmimetype: text/plain
submitter: ron-fox
assignee: wduquette
closer: nobody
comment:
  Consider the following code snippet:

  package require snit
  set a 1234
  namespace eval b {
    variable c 5678
  }

  snit::type a {
    option -a -default $::a
  }

  snit::type b {
     option -b -default $::b::c
  }


  Snit will claim for both option definitions that the variable is not readable:
  e.g. for type a:

   can't read "::a": no such variable


  for type b:

  can't read "::b::c": no such variable


  The use case for this is to use a variable in Tcl in the same manner a #define is used in e.g. C

  Workaround:
    Options where this is desired can be initialized in the constructor for the type e.g.

  snit::type a {
    option -a 
    constructor args {
       set options(-a) $::a
       self configurelist $args
    }
  }


tkt_uuid: 733e45296319f8c92ae411efe009d59cad4dc8fa
type: Bug
status: Closed
resolution: Fixed
subsystem: http :: autoproxy
priority: 5 Medium
severity: Minor
foundin: 1.5.3
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: http::autoproxy has no interface to remove a set basic authentication
cmimetype: text/x-fossil-wiki
submitter: oehhar
closer: patthoyts
closedate: 2458055.0664078
comment:
  IMHO the autoproxy package lacks a possibility to remove a set -basic authentication.

  E.g.: if once, 'autoproxy::configure -basic -user a -password b' is set, there is no way to remove this.

  This is also the case, if autoproxy::init is called.
  A once found basic authentication can not be removed by a recall to autoproxy::init.

  This is important for the case, that -basic was set manually and should be removed by init.


tkt_uuid: 922880978d4890820a9bfd4a54cf55e876867207
type: Bug
status: Open
resolution: None
subsystem: http :: autoproxy
priority: 5 Medium
severity: Minor
foundin: 1.5.3
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: http::autoproxy::init does not discover https proxy on Windows
cmimetype: text/x-fossil-wiki
submitter: oehhar
closer: nobody
comment:
  The autoproxy::init function uses the http proxy on Windows.
  There might be different settings for https.

  Those are ignored so far.

  I have no idea if this is realistic. Anyway, only one host is supported so far.
  A use scenario is that an application only wants to support https and thus would eventually get the wrong proxy server or wrong port.


tkt_uuid: 85b2d9d46d3353123ad624f370cb413f46ff4a1a
type: RFE
status: Closed
resolution: Accepted
subsystem: pt (parsetools)
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: Add NX backend to PT [d062dc220b]
cmimetype: text/plain
submitter: ssoberni
assignee: andreask
closer: aku
closedate: 2457667.70203684
comment:
  Hi Andreas,

  I kindly ask for your review of my NX backend implementation. Basically, I retrofitted the TclOO infrastructure that I found (incl. the test suite).

  See [d062dc220b].

  Test suites run fine:

  1) ./sak.tcl test run modules/pt

  2) cd modules/pt && tclsh pt_tclparam_config_nx.test

  ... as do my examples that I have at hand (Calculator from the Tcl Wiki etc.)

  To-dos (from my end):

  - NX-specific command/method prefixes:

  As discussed in our email conversation back in May '16:
  >>>> ## a)  recursive method calls would turn out as [: /method/], rather
  >>>> ##     than [:/method/] (:-cmd vs. :-prefix)
  >>>> ## b)  are there object-variable accesses in the generated code?
  >>>> ##     variable + $objVar in TclOO vs. ${:objVar} in NX
  >>>  
  >>>> At least for the scope of the EXPRESSION examples, I could not spot
  >>>> occurrences of 2b). Are there any? As for 2a), I could live with "my"
  >>>> being replaced by ":" only (this will work in NX), but is not as optimal
  >>>> as the :-colon prefix (the prefix notation provides call-site caching
  >>>> after method resolution). Maybe providing sth. like -proc-command-prefix
  >>>> would be generally useful, assuming that some engine implementation
  >>>> prefixes its instruction procs/methods etc. somehow?
  >>>
  >>> I am currently not thinking very well, it being early morning right now.
  >>> Where would I have to accomodate NX ?
  >>>
  >>> The 'pt_tclparam_config_nx.tcl' ? That is something you can write,
  >>> with 90% its being the template to fill in with stuff ...
  >>
  >> I can definitely write/provide it, no problem. It is just about the
  >> ":"-prefix in NX: What "my foo" is in TclOO is ideally ":foo" in NX.
  > 
  > Well, changing the semantics of -runtime-command would require a major
  > version change. We can get away with a minor version change by
  > creating a new option (name to be determined) however. In its default
  > (inactive) state the existing semantics are active. When activated
  > however the prefix becomes a string-prefix, i.e. new semantics.
  > 
  > Your tclparam config file would then use this option to change the
  > semantics to suit, while all the existing code is unchanged and using
  > the old semantics.

  Once this is available, I would have to change the implementation and tests accordingly. Right now, they work with the existing infrastructure.

  - Am I missing tests?

  In the test helpers, I found routines to strip the package provide/return statements from the template-generated code (have not yet extended this for NX). Am I expected to do so? Which test cases make use of that?

  (If already required by the tests I implemented: Right now, I commented out the final return statement, because my current examples and smoke tests just eval the generated script).

  - Question: Multiple alternative templates?

  Is it possible to provide for more than 1 template. Why am I asking: In most case, it makes more sense to use the generated code in situ, rather than dump the package structure first and then source it again. I would like to provide a package-less template also.

  Thank you for your time and the great work with PT/PEG!


tkt_uuid: 405b23378dbabbf1efde5df48380d8bfb6348a70
type: RFE
status: Closed
resolution: Rejected
subsystem: textutil
priority: 5 Medium
severity: Minor
title: How about letting token::shell expand file names?
cmimetype: text/plain
submitter: arjenmarkus
assignee: aku
closer: aku
closedate: 2457900.26650789
comment:
  token::shell is meant to parse a string as it would be done by bash (basic stuff only). Would it be a good idea to allow for expanding file names as well? Like:

  ::string token shell -expand 1 *.tcl

  to get back a list of all files with extension .tcl.

  Just an idea, not sure if it would be really useful.


tkt_uuid: be22696352755c887c8dcd67749a4b385ee9dbcf
type: Bug
status: Open
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Important
title: string::token::shell -- Add/extend the set examples in the documentation
cmimetype: text/plain
submitter: aku
assignee: aku
closer: nobody
comment:
  Per discussion with Alexandru <alexandru.dadalau@meshparts.de> on comp.lang.tcl

  >> > Those are interesting packages too, though I find the
  >> > ::string::token::shell pretty difficult to understand.
  >> 
  >> Noted. Maybe more or better examples to add to the documentation ?
  >
  > Yes, more examples would be good. Also, I couldn't understand how
  > those tokens work and where and how I should input them...


tkt_uuid: 9d21e52e39c37d9521e8d34da3b301219b8f909c
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: bwidget
priority: 5 Medium
severity: Important
foundin: 1.9.10
private_contact: dac83924bb70a68f6807871ce80578576828377e
title: [BWidget] ScrollableFrame changes width upon unmap and map events
cmimetype: text/html
submitter: anonymous
closer: aku
closedate: 2457667.62374341
comment:
  As stated in the title, the ScrollableFrame changes width upon unmap and map events. 

  See: https://groups.google.com/forum/#!topic/comp.lang.tcl/Q5prg9lsOYc

  I have found the bug and solved it. Here are the original and modified procedures:

  proc ScrollableFrame::_frameConfigure {canvas {unmap 0}} {
      # This ensures that we don't get funny scrollability in the frame
      # when it is smaller than the canvas space
      # use [winfo] to get height & width of frame

      # [winfo] doesn't work for unmapped frame
      set frameh [expr {$unmap ? 0 : [winfo height $canvas.frame]}]
      set framew [expr {$unmap ? 0 : [winfo width  $canvas.frame]}]

      set height [_max $frameh [winfo height $canvas]]
      set width  [_max $framew [winfo width  $canvas]]

      $canvas:cmd configure -scrollregion [list 0 0 $width $height]
  }
  # This is the modified above procedure.
  # The modified procedure solves the problem described in https://groups.google.com/forum/#!topic/comp.lang.tcl/Q5prg9lsOYc
  proc ScrollableFrame::_frameConfigure {canvas {unmap 0}} {
      # This ensures that we don't get funny scrollability in the frame
      # when it is smaller than the canvas space
      # use [winfo] to get height & width of frame

      # [winfo] doesn't work for unmapped frame
      if {$unmap} {
          return
      }

      set frameh [winfo height $canvas.frame]
      set framew [winfo width  $canvas.frame]

      set height [_max $frameh [winfo height $canvas]]
      set width  [_max $framew [winfo width  $canvas]]

      $canvas:cmd configure -scrollregion [list 0 0 $width $height]
  }


tkt_uuid: faf551c778a357fe2e45899f23da6e014b73694e
type: Bug
status: Open
resolution: None
subsystem: snit
priority: 5 Medium
severity: Minor
foundin: tcllib 1.18
private_contact: 381064a27d4bf6b0e2864e4d7a71390f2cf4db47
title: snit doesn't work in Tcl 8.3
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  Running "package require snit" in Tcl 8.3 gives

  can't use non-numeric string as operand of "!"
      while executing
  "if {!$compile(-hastypemethods) && !$compile(-hasinstances)} {
          error "$which $type has neither typemethods nor instances"
      }"
      (procedure "Comp.Compile" line 77)
      invoked from within
  "Comp.Compile type $type $body"
      (procedure "snit::type" line 2)
      invoked from within
  ...

  That's because "yes", "no" etc are not recognized as boolean values in old Tcl versions. Please return back to 0/1 (as it was in first snit versions) to stay compatible.


tkt_uuid: 276fc23a33ff79e3084b9f61790622299ab63cf3
type: Bug
status: Closed
resolution: Out of Date
subsystem: math
priority: 8
severity: Important
title: math not passing tests
cmimetype: text/plain
submitter: aku
assignee: arjenmarkus
closer: aku
closedate: 2458143.34972471
comment:
   [8.4.20] math                  ~~ FAILS T  1067 P  1043 S     0 F    24
   [8.5.18] math                  ~~ FAILS T  1706 P  1702 S     0 F     4
   [8.6.4]  math                  ~~ FAILS T  1904 P  1904 S     0 F     0

  math::geometry apparently requires 8.5, the tests still allow 8.4.
  And other issues.


tkt_uuid: 2c492395710a33620ecee2fea5af78bd64c33ce4
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
severity: Important
private_contact: 9fa695d4fb65e5d5fd60604f1f9101b3d232166c
title: uri not passing tests
cmimetype: text/plain
submitter: aku
assignee: aku
closer: kjnash
closedate: 2457739.26595615
comment:
   [8.4.20] uri                   ~~ FAILS T   186 P   141 S    44 F     1
   [8.5.18] uri                   ~~ FAILS T   186 P   141 S    44 F     1
   [8.6.4]  uri                   ~~ FAILS T   186 P   141 S    44 F     1


tkt_uuid: ec4431c0ebd240aa3e1f6b302f66fba81a18adf2
type: Bug
status: Closed
resolution: Out of Date
subsystem: odie
priority: 5 Medium
severity: Important
title: markdown not passing tests
cmimetype: text/plain
submitter: aku
assignee: aku
closer: aku
closedate: 2458059.45872595
comment:
   [8.5.18] markdown              ~~ FAILS T    24 P     9 S     6 F     9
   [8.6.4]  markdown              ~~ FAILS T    24 P     9 S     6 F     9


tkt_uuid: 28e817872c863a183e5cde1d4b09d3d3288dde5c
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 0.1
private_contact: dac83924bb70a68f6807871ce80578576828377e
title: Improved history module of Tklib
cmimetype: text/plain
submitter: anonymous
closer: aku
closedate: 2457679.71393588
comment:
  I have made two improvements to the history module:
  1. Avoid multiple add of same text to the entry history
  2. Fixed weird behavior at the end of the history list: I had to press two times the up arrow in order to get the previous list value.

  Here is the modified code. I hope it will find it's way into the next release.

  # history.tcl --
  #
  #       Provides a history mechanism for entry widgets
  #
  # Copyright (c) 2005    Aaron Faupell <afaupell@users.sourceforge.net>
  #
  # See the file "license.terms" for information on usage and redistribution
  # of this file, and for a DISCLAIMER OF ALL WARRANTIES.
  #
  # RCS: @(#) $Id: history.tcl,v 1.4 2005/08/25 03:36:58 andreas_kupries Exp $

  package require Tk
  package provide history 0.1

  namespace eval history {
      bind History <Up>   {::history::up %W}
      bind History <Down> {::history::down %W}
  }

  proc ::history::init {w {len 30}} {
      variable history
      variable prefs
      set bt [bindtags $w]
      if {[lsearch $bt History] > -1} { error "$w already has a history" }
      if {[set i [lsearch $bt $w]] < 0} { error "cant find $w in bindtags" }
      bindtags $w [linsert $bt [expr {$i + 1}] History]
      array set history [list $w,list {} $w,cur 0]
      set prefs(maxlen,$w) $len
      return $w
  }

  proc ::history::remove {w} {
      variable history
      variable prefs
      set bt [bindtags $w]
      if {[set i [lsearch $bt History]] < 0} { error "$w has no history" }
      bindtags $w [lreplace $bt $i $i]
      unset prefs(maxlen,$w) history($w,list) history($w,cur)
  }

  proc ::history::add {w line} {
      variable history
      variable prefs
      if {$history($w,cur) > 0 && [lindex $history($w,list) $history($w,cur)] == $line} {
          set history($w,list) [lreplace $history($w,list) $history($w,cur) $history($w,cur)]
      }
      set idx [lsearch -dictionary $history($w,list) $line]
      if {$idx>=0} {
          set $history($w,list) [lreplace $history($w,list) $idx $idx]
      }
      set history($w,list) [linsert $history($w,list) 0 $line]
      set history($w,list) [lrange $history($w,list) 0 $prefs(maxlen,$w)]
      set history($w,cur) 0
  }

  proc ::history::up {w} {
      variable history
      if {[lindex $history($w,list) [expr {$history($w,cur) + 1}]] != ""} {
          if {$history($w,cur) == 0} {
              set history($w,tmp) [$w get]
          }
          $w delete 0 end
          incr history($w,cur)
          $w insert end [lindex $history($w,list) $history($w,cur)]
      } else {
          alert $w
      }
  }

  proc ::history::down {w} {
      variable history
      if {$history($w,cur) != 0} {
          $w delete 0 end
          if {$history($w,cur) == 0} {
              $w insert end $history($w,tmp)
              set history($w,cur) 0
          } else {
              incr history($w,cur) -1
              $w insert end [lindex $history($w,list) $history($w,cur)]
          }
      } else {
          alert $w
      }
  }

  proc ::history::get {w} {
      variable history
      return $history($w,list)
  }

  proc ::history::clear {w} {
      variable history
      set history($w,cur) 0
      set history($w,list) {}
      unset -nocomplain history($w,tmp)
  }

  proc ::history::configure {w option {value {}}} {
      variable history
      variable prefs
      switch -exact -- $option {
          length {
              if {$value == ""} { return $prefs(maxlen,$w) }
              if {![string is integer -strict $value]} { error "length must be an integer" }
              set prefs(maxlen,$w) $value
          }
          alert {
              if {$value == ""} { return [info body ::history::alert] }
              proc ::history::alert w $value
          }
          default {
              error "unknown option $option"
          }
      }
  }

  proc ::history::alert {w} {bell}


tkt_uuid: 0bd02c1bf804786a500d8a2abc1dceed826c26ca
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Severe
foundin: 1.18
private_contact: c6076ea3e6bc9e0e81402b689bfbed973110bf88
title: websocket: sec-websocket-protocol is optional but checked in websocket::test
cmimetype: text/plain
submitter: ecky-l
assignee: emmanuel
closer: nobody
comment:
  According to the websocket RFC, the sec-websocket-protocol header is optional for additional protocols on top of websocket. 

  The websocket::validate ($headers) proc does not set the "protocols" dict entry, if no sec-websocket-protocol header is present. But websocket::test assumes that the "protocols" entry is always present.

  Line 492: set protos [dict get $res protocols]

  It can be worked around if no sec-websocket-protocol is present, by changing that line 492 to:

  set protos [expr { ([dict exists $res protocols]) ? [dict get $res protocols] : [list *] }]

  to install a handler for all protocols. Is this a viable fix?


tkt_uuid: 77c26aad34b61371bf2f5e9c1f0507c03ee123fe
type: Patch
status: Closed
resolution: Fixed
subsystem: mime
priority: 5 Medium
severity: Minor
foundin: 1.15
private_contact: 88ae178bee4094e88a3adac9b6d0aa7e660e51bc
title: Fix ::mime::word_encode for Header-Fields
cmimetype: text/plain
submitter: anonymous
closer: pooryorick
closedate: 2458360.75946865
comment:
  A '?' and '_' in the input is not encoded 

  puts [::mime::word_encode "iso8859-1" "quoted-printable" "Error?"]
  => =?ISO-8859-1?Q?Error??=
  Should be
  => =?ISO-8859-1?Q?Error=3F?=
  See RFC 2047 4.2 (3)

  Proposed Patch:

  --- /usr/share/tcltk/tcllib1.15/mime/mime.tcl   2013-01-23 05:25:50.000000000 +0100
  +++ mime.tcl    2016-12-01 10:05:21.580373040 +0100
  @@ -2502,7 +2502,7 @@
              "\n\.\n" "\n=2E\n" "\nFrom " "\n=46rom "]
       if {$encoded_word} {
          # Special processing for encoded words (RFC 2047)
  -       lappend mapChars " " "_"
  +       lappend mapChars " " "_" "_" "=5F" "?" "=3F"
       }
       set string [string map $mapChars $string]


tkt_uuid: 5e8c21e9c23934a0121673f1339712befb2f009f
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 9 Immediate
severity: Important
foundin: trunk
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: Fix comment start delimiter [83742e01e4]
cmimetype: text/plain
submitter: ssoberni
assignee: akupries
closer: aku
closedate: 2457903.46466159
comment:
  I found that the html backend/format (fmt.html, ht_comment) produces invalid comment start delimiters (inflacted by one whitespace). This is not only invalid, but even throws up in some browser and parser quirk modes (e.g. tdom's html parsers) does not accept it.

  Fixed ht_comment and the corresponding test cases.


tkt_uuid: 7b5c6cb47792a7d8fc52a41ff8f6b73e96ec08e7
type: Patch
status: Closed
resolution: Accepted
subsystem: uri
priority: 5 Medium
severity: Important
foundin: Fossil current [34996bb8c0] and older versions
private_contact: a774b1f5653dc3360e29ea7d635a64e94c9f1dab
title: Bugfixes to URI parsing in module uri
cmimetype: text/plain
submitter: kjnash
closer: kjnash
closedate: 2457739.26929538
comment:
  A patch is provided with changes to files in modules/uri.

  This is a description of the changes, in the order they appear in the patch.


  FIRST CHANGE: to file uri.tcl, definition of ::uri::basic::toplabel

  This fixes two bugs.

  (1) Although the first and last characters of all current toplevel names begin and end in ${alpha}, the DNS system allows ${alphaDigit}.  Although it is unlikely that an ICANN toplevel name will be created that has a leading or trailing digit, such names are permitted, and they are likely to exist among the names defined by users of private networks.

  (2) Fully qualified domain names are terminated with ".".  Although it is not common to use such names in URIs, it is entirely valid.


  SECOND CHANGE: to file uri.tcl, proc ::uri::split

      This is not a bugfix, but it preserves consistency between the scheme-detecting regexps in procs ::uri::isrelative and ::uri::split.  Consistency is useful because an earlier bugfix was applied to one regexp but not the other.

      The change restricts the initial character of the scheme to [A-Za-z] (and also updates the comment that references an RFC).  The change has no effect on results, because uri::split rejects URIs with unknown schemes.


  THIRD CHANGE: to file uri.tcl, fragmentPattern in proc ::uri::SplitHttp

  This fixes a bug in the characters allowed in the URI fragment.  Consider these three alternatives:

  (a) Allow characters from ${segment} - i.e. keep the existing code.
  (b) ${segment} is insufficient for a fragment.
      Allow also the extra characters "/" and "?" which are permitted in the fragment (RFC 3986 Section 3.5).
  (c) Allow the fragment to include any character.

  In cases (a) or (b), uri::split interprets a fragment with an invalid character as part of the path or (if it exists) the query.

  However, the character '#' MUST be encoded if it appears in the path or query.  Therefore:
  - (b) and (c) perform differently only for invalid URIs.
  - If parsing the URI strictly, a fragment with an invalid character should cause a return with error status.
  - If instead the parser tries to make the best guess at the programmer's intentions, I suggest that (c) is a better choice than than (b).
  - (c) is implemented in the patch.

  FOURTH CHANGE: to file uri.tcl, proc ::uri::isrelative

  This fixes three bugs.

  (1) The first character of the scheme must be a letter (RFC 3986 Sec 3.1).
      (Fixes bug cf5df74f40)
  (2) The second bracket expression is reordered because [+-.] is interpreted as a range that includes the unwanted character ",".
      (A similar bug was fixed for uri::split in [28bfed4e43] at 2003-04-11 21:01:28)
  (3) Adding upper-case letters [A-Z] makes the scheme-detecting regexp conform to RFC 3986 Sec 3.1, which states:
     'Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.'


  FIFTH CHANGE: to file uri.test, test uri-8.0 {uri::split bug #676976, ill. char in scheme}

     * Independent of the changes above.
     * Without any changes, the current code for uri::split does the right thing: it detects the invalid URI, and throws an error.
     * The patch fixes the test so this is a "pass".
     * For some reason the test previously passed if uri::split misinterpreted the illegal URI.


tkt_uuid: 39ab616d8fc7474163a346726dfd817c779c3ef1
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: graph
priority: 8
severity: Critical
foundin: 2.4
private_contact: 86dbd7dc0404d59a10af70ab58914c5147194ace
title: struct::graph walk dfs preorder visits some nodes more than once
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457903.22239912
comment:
  Build a graph by the following statements:
  ::struct::graph g
  g node insert a
  g node insert b
  g node insert c
  g arc insert a b ab
  g arc insert b c bc
  g arc insert a c ac

  # Now walk through the graph type dfs and order pre:
  g walk a -command show -dir forward -order pre -type dfs

  The procedure "show" is defined as following:
  proc show {enter graph node} {
     puts "$graph: $enter $node"
  }


  Walking through the graph in the described manner results in:
  ::g: enter a
  ::g: enter b
  ::g: enter c
  ::g: enter c


  You see: node c has been visited twice. That is funny, I did not expect this.

  If you walk through the same graph in postorder mode all nodes are visited exactly once, what I expect:

  g walk a -command show -dir forward -order post -type dfs

  results in
  ::g: leave c
  ::g: leave b
  ::g: leave a

  What do you think?
  Have a great day and Merry Christmas!
  Matthias Hammelsbeck


tkt_uuid: aff22194d70682b503270354bab689df39f1091d
type: Bug
status: Open
resolution: None
subsystem: imap4
priority: 5 Medium
severity: Minor
foundin: 0.5.3
private_contact: 94b0e543dd4b22ca7c5efdfabe481fcd65792a89
title: imap4 - BODY.PEEK fails
cmimetype: text/plain
submitter: vonandraste
assignee: aku
closer: nobody
comment:
  When using BODY.PEEK[*] as a parameter, this seems to break imaptotcl_symbol due to the nested '[]' in the imap response. The match is incorrect (regex and nested patterns not a good mix) and the subsequent data var is incorrectly updated.

  When using just BODY, than all seems fine:The line "1 FETCH (BODY[HEADER.FIELDS (BODY FROM)] {46})" is processed and the element "BODY[HEADER.FIELDS (BODY FROM)]" is set, and appended to the list that is eventually returned to the proc prcoessfetchline, from 'imaptotcl'.

  Using BODY.PEEK[1], breaks that flow, setting the element to 'BODY', then 'HEADER.FIELDS', then 'S', then 'BODY.PEEK[1] FROM)]', which fails.

  Example usage:
  set fields {BODY from:}
  imap4::fetch $chan :1 -inline {*}$fields - Ok

  set fields {BODY.PEEK[1] from:}
  imap4::fetch $chan :1 0inline {*}$fields - fails


tkt_uuid: 8fd2561785f5dcc7f7c88182c89812a0a27a4498
type: Patch
status: Closed
resolution: Fixed
subsystem: oauth
priority: 7 High
severity: Severe
foundin: tcllib/1.18 oauth/1
private_contact: f49f9ff71016aa06bfa03b7052a7a98d2be1de91
title: Fix oauth::query defaulting POST requests to GET
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458143.3630748
comment:
  --- oauth_orig.tcl      2017-01-15 21:05:40.614045465 +0000
  +++ oauth.tcl   2017-01-15 23:39:27.259547226 +0000
  @@ -1,4 +1,4 @@
  -# !/bin/sh
  +# !/bin/sh
   # the next line will restart with tclsh wherever it is \
   exec tclsh "$0" "$@"
   
  @@ -156,22 +156,25 @@
       lappend paramList "oauth_token=$oauth(-accesstoken)"
       lappend paramList "oauth_version=$oauth(-oauthversion)"
       
  +    set header $paramList
  +    
       if {$postQuery eq {}} {
          set url [lindex [split $baseURL {?}] 0]
          set queryString [lindex [split $baseURL {?}] 1]
  -       foreach argument [split $queryString {&}] {
  -           lappend paramList $argument
  -       }
          set httpMethod {GET}
       } else {
          set url $baseURL
  +       set queryString $postQuery                                                                                                                                        
          set httpMethod {POST}                                                                                                                                             
       }                                                                                                                                                                    
  +    foreach argument [split $queryString {&}] {                                                                                                                          
  +        lappend paramList $argument                                                                                                                                      
  +    }                                                                                                                                                                    
                                                                                                                                                                            
  -    foreach parameter $paramList {                                                                                                                                       
  +    foreach parameter $header {                                                                                                                                          
          set key [lindex [split $parameter {=}] 0]                                                                                                                         
          set value [join [lrange [split $parameter {=}] 1 end] {=}]                                                                                                        
  -       lappend header "${key}=\"${value}\""                                                                                                                              
  +       lappend header2 "${key}=\"${value}\""                                                                                                                             
       }                                                                                                                                                                    
       set paramString [join [lsort -dictionary $paramList] {&}]                                                                                                            
                                                                                                                                                                            
  @@ -183,7 +186,7 @@                                                                                                                                                       
       set signKey "[PercentEncode $oauth(-consumersecret)]&[PercentEncode $oauth(-accesstokensecret)]"                                                                     
       set signature [base64::encode [sha1::hmac -bin -key $signKey $signString]]

  -    lappend header "oauth_signature=\"[PercentEncode $signature]\""
  +    lappend header2 "oauth_signature=\"[PercentEncode $signature]\""
       if {$oauth(-debug) == 1} {
          puts {oauth::header: Authorization Oauth}
          foreach line $header {
  @@ -191,7 +194,7 @@
          }
          puts "\nBaseString: $signString"
       }
  -    return "Authorization [list [concat OAuth [join [lsort -dictionary $header] {, }]]]"
  +    return "Authorization [list [concat OAuth [join [lsort -dictionary $header2] {, }]]]"
   }

   # query --
  @@ -200,7 +203,7 @@
   # Arguments:
   #       baseURL     api host URL with ?arguments if it's a GET request
   #       postQuery   POST query if it's a POST query
  -# Result:
  +# Result:
   #       The result will be list with 2 arguments.
   #       The first argument is an array with the http's header
   #       and the second one is JSON data received from the server. The header is
  @@ -235,6 +238,7 @@
       } else {
          set url $baseURL
          set httpMethod {POST}
  +       set queryString $postQuery
       }

       if {$httpMethod eq {GET}} {
  @@ -246,13 +250,11 @@
          set requestBody $queryString
       }
       if {$queryString ne {}} {
  -       set headerURL ${url}?${queryString}
  +       set header [header $url $queryString]
       } else {
  -       set headerURL $url
  +       set header [header $url]
       }

  -    set header [header $headerURL]
  -
       http::config \
          -proxyhost $oauth(-proxyhost) \
          -proxyport $oauth(-proxyport) \


tkt_uuid: 9f4c0e3e9555873be18495e272b12ed277c49b64
type: Bug
status: Closed
resolution: Fixed
subsystem: tar
priority: 7 High
severity: Severe
foundin: 1.3
private_contact: cb02a4a25e8da92f2790bc307bf01ef24ce6053e
title: incorrect use of == in tar
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457903.2788422
comment:
  tar::get is unable to distinguish between filenames that compare numerically equal, due to https://core.tcl.tk/tcllib/artifact/ccc1188a13c75865?ln=203

  This script illustrates:

  package require tar
  file mkdir temp.[pid]
  cd temp.[pid]
  proc writefile {name text} {
     set fd [open $name w]
     puts $fd $text
     close $fd
  }
  writefile 02 "number two"
  writefile 02 "zero-two"
  tar::create t.tar {2 02}
  puts [tar::get t.tar 02]           ;# "number two" - expected "zero-two"
  puts [tar::get t.tar 0b10]         ;# "number two" - expected error
  cd ..
  file delete -force temp.[pid]


tkt_uuid: 1be9ea99c9b76c8ffeff3edfb73671309bf657e8
type: Patch
status: Closed
resolution: Fixed
subsystem: math :: special
priority: 5 Medium
severity: Minor
foundin: 1.6
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: prime factors of integer
cmimetype: text/plain
submitter: de
assignee: arjenmarkus
closer: anonymous
closedate: 2457902.14113434
comment:
  request for the math::number.theory a command for prime factoring of a positive integer would be handy. could include an int if number was floating and return answer for int(n) . code from tcl wiki below ordered numbers from low to high, which is good.
  -tabasco7777@gmx.com, 3Feb2017

            proc factor_num {num} {
             # MS from Sample Math Programs
       for {set i 2} {$i <= $num} {} {
           if {![expr {$num % $i}]} {
               lappend factors $i
               set num [expr {$num / $i}]
           } elseif {[expr $i*$i > $num]} {
        lappend factors $num
        break
    } elseif {$i != 2} {     
               incr i 2
    } else {
        set i 3
           }
       }


tkt_uuid: 734dd2ae5c89319a3b8579e48d581f9d0a3da4f4
type: Patch
status: Closed
resolution: Fixed
subsystem: math :: special
priority: 5 Medium
severity: Minor
foundin: 1.6
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: Gauss / Legendre functions for number of primes
cmimetype: text/plain
submitter: de
assignee: arjenmarkus
closer: anonymous
closedate: 2457902.14025074
comment:
  request for math::number_theory.
  would be handy to have 3 prime number functions like approx_number_primes = N1 / ln (N1),
  legendre_primes2 = N1 / (ln (N1)-1),modified_legendre_primes3 = N1 / (ln (N1)-1.08366). 
  I have loaded ref page on tcl wiki.
  refs, http://wiki.tcl.tk/48334
  -tabasco7777@gmx.com, 3febrb2017


  Note: The Gauss approximation for number of primes is approx_number_primes = N1 / ln (N1), 15 percent average error. Gauss developed this formula at the age of 14! and formula was first published in 1863. If the exact solution is tabbed as one, the program is storing the exact solution in a list of limited size. The number one should not be counted as a prime and the number two is counted as prime, so some starting algorithm statements are tricky. 
  The Legendre approximation for number of primes was approx_legendre_primes2 = N1 / (ln (N1)-1), 2 percent average error beyond 1E4. A variant of the Legendre equation was approx_legendre_primes3 = N1 / (ln (N1)-1.08366).


tkt_uuid: 997c8b4e670c04bdf26d4c2489328e37eb152bd0
type: RFE
status: Closed
resolution: Accepted
subsystem: rest
priority: 8
severity: Cosmetic
private_contact: b925997882c794b5ee01f68425d08537ad6cf5fa
title: Add ::rest::patch for the HTTP PATCH method
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457903.43758339
comment:
  Although it can already be done with ::rest::simple, it would be nice to have a shortcut function for the HTTP PATCH method (as described by RFC5789) similar to ::rest::put. This should be very easy to implement.


tkt_uuid: baa334cfef21272276032498a62edf383e757d4f
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: record
priority: 8
severity: Critical
foundin: 1.18
private_contact: a62a085bcbd6abf6f3327d897889da41296695dc
title: struct:: record delete not clearing sub-structures - re-create fails
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458660.56343814
comment:
  When deleting an instance of a complex record parts of the sub-structure are left undeleted. Making re-creation fail. 
   This occurs in ver 1.2.1 of struct::record.
   I see the code is unchanged from my version in tcllib 1.18.


  # simple example to show error when deleting a non-simple record structure
  # *** for a more detailed example shouwing the more apparently ***
  # *** random effects see below                                 ***
  #
  #     note that deleting the sub-structure first works:
  #        record delete instance js.birth
  #        record delete instance js
  # 
  package require struct::record
  namespace import ::struct::record::*

  record define details  {date place}
  record define person {fullname {record details birth}}

   person js
   js.fullname "John Smith"
   js.birth.date "31 Jul 1935"
   js.birth.place London
   
   #  show everything
   js
   record show instances person
   record show instances details
   parray ::struct::record::person::values
   parray ::struct::record::details::values
   info commands js.*
   
   #=== All OK so far
   
   # delete this 
   record delete instance js
   
   #try showing again  
   record show instances person              ;# OK, nothing
   record show instances details             ;# ** error ** : js.birth still there
   parray ::struct::record::person::values   ;# OK, nothing
   parray ::struct::record::details::values  ;# ** error ** : js.birth values still there
   info commands js.*                        ;# as expected
   
   #== try recreating - as above
   person js              ;# error message : "Instances ::js.birth already exists"
   record show instances person    ;#== not created
   js.birth.place London  ;# error message : invalid command ...


  #=============================== 2 ===========================================

  # More detailed example to show error when deleting complex record structure
  # and shouwing the more apparently random effects 
  #     for simple case see record_delete_error1.tcl     
  # 
  package require struct::record
  namespace import ::struct::record::*

  record define details  {date place}
  record define nm    {full firstname lastname}
  record define person {{record nm name} {record details birth} {record details death}}

   person js
   js.name.full "John Smith"
   js.name.firstname John
   js.name.lastname Smith
   js.birth.date "31 Jul 1935"
   js.birth.place London
   js.death.date "1 Nov 2010"
   js.death.place Manchester
    
   person fj
   fj.name.full "Fred Jones"
   fj.name.firstname Fred
   fj.name.lastname Jones
   fj.birth.date "31 Jul 1930"
   fj.birth.place Liverpool
   fj.death.date "1 Nov 1990"
   fj.death.place Lancaster
   
   person ar
   ar.name.full "Ann Robinson"
   ar.name.firstname Ann
   ar.name.lastname Robinson
   ar.birth.date "31 Jul 1955"
   ar.birth.place Birmingham
    
   # correctly loads records - show data and instances - OK
   js
   fj
   ar
   record show instances person
   record show instances details
   record show instances nm
   
   # delete these 
   foreach id [record show instances person] { record delete instance $id }
   
   #try showing again
   record show instances person
   record show instances details
   record show instances nm
   
   #== OOps - some deleted, some not! : 
   #       ::ar.birth ::ar.death ::fj.birth ::js.birth
   #       ::ar.name
   
   #=== try recreating - as above
   person js
   # error message : "Instances ::js.birth already exists"
   person ar   
   # error message : 'bad level "3" '

   record show instances person
   #== not created
   js.birth.place London
   # error message : invalid command name "js.birth.place"


tkt_uuid: 7cf9323d38af6cf4e074ec10f6f15ad4c4e1fdf1
type: Bug
status: Closed
resolution: Fixed
subsystem: ldap
priority: 8
severity: Critical
foundin: 1.18
private_contact: ba69b1b3951296adee358cee3a51d0a1631f63cc
title: TLS options not in sync with tcltls
cmimetype: text/plain
submitter: pda
assignee: schlenk
closer: schlenk
closedate: 2457902.38531882
comment:
  Symptom: ldap module cannot connect to a tls-secured ldap service
  % package require ldap
  % set s [ldap::secure_connect ldap.example.com]
  protocol not supported

  Cause:
  Usage of tcltls in ldap.tcl is not up-to-date with tcltls and recent versions of OpenSSL (used by tcltls).

  Line 413 of modules/ldap/ldap.tcl is:
  tls::import $sock -cafile "" -certfile "" -keyfile "" \
     -request 1 -server 0 -require 0 -ssl2 no -ssl3 yes -tls1 yes

  Recent versions of tcltls:
  1- support TLS 1.1 and TLS 1.2 (not mentionned in ldap.tcl call to tls::import)
  2- enable use of SSL3 (-ssl3 yes) which is no longer supported (see line 565 of tls.c in tcltls source code

  This bug is critical since LDAP module cannot connect to a TLS-secured LDAP service.


tkt_uuid: c247ed5db42e373470bf8a6302717e76eb3c6106
type: Bug
status: Closed
resolution: Accepted
subsystem: ldap
priority: 8
severity: Critical
foundin: 1.18
private_contact: ba69b1b3951296adee358cee3a51d0a1631f63cc
title: LDAP protocol error
cmimetype: text/plain
submitter: pda
assignee: aku
closer: aku
closedate: 2458143.30330068
comment:
  Under some circumstances (large LDAP entries, e.g. with a large jpegPhoto), the LDAP module returns the following error:

  Protocol error: Error reading SEQUENCE response for handle ::ldap::ldapsock15a3700

  The ReceiveBytes proc seems to return 0 bytes (partial read) instead of the SEQUENCE byte. The partial read is treated as an error in MessageReceiver.


tkt_uuid: c974e352d2fdc34a8d267cd23c4a76a779770b4d
type: Bug
status: Closed
resolution: Fixed
subsystem: json
priority: 7 High
severity: Severe
foundin: 1.18
private_contact: ba69b1b3951296adee358cee3a51d0a1631f63cc
title: Invalid float parsing in json2dict
cmimetype: text/plain
submitter: pda
assignee: aku
closer: aku
closedate: 2457903.4348586
comment:
  json2dict accept an invalid floating point number:

  % package require json
  1.3.3
  % json::json2dict .1
  1

  According to json.org, a number cannot start with a decimal point (0.1 is valid, .1 is not).


tkt_uuid: 83a0b1b11bba28a29cf6be076c3c1943c8d958f5
type: Bug
status: Closed
resolution: By Design
subsystem: struct :: matrix
priority: 5 Medium
severity: Important
foundin: TclLib 1.15 and TCL 8.4
private_contact: 1cff2178a4b6322f8bd277f4bb1acdc652eb53c3
title: CSV lib and Struct Matrix packages
cmimetype: text/plain
submitter: nikhilesh.saggere
assignee: aku
closer: aku
closedate: 2458143.35263876
comment:
  The API to get the number of rows in a CSV file always returns the maximum number of elements in any given row as the size.

  Ex:
  Consider the following as the content of the CSV file.
  SYSTEM SIGNAL NUMBER VALUE 
  R1     X      60     13
  R2     Y      61     14     9   8   7

  When the get row API is used to gets the content of the row in the current index, the entire content is returned as a list.

  Considering the index is in the 2nd row, i.e, at X, the get row API returns list1 as
  R1 X 60 13 followed by 3 spaces ({} {} {})

  and when the index is at Y the get row api returns list2 as 
  R2     Y      61     14     9   8   7

  However the length of both the lists are now 7.
  The length of the first list (list1) should it not be 4?

  Please check.


tkt_uuid: 48ed494bc485f7967b4d4ef8fc614f1aac50feba
type: Bug
status: Open
resolution: None
subsystem: zip
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: cdcafd1bca6d120e64d32dc59249da53313c6728
title: zipfile::decode GetFile need check native_zip_functs flag
cmimetype: text/plain
submitter: danilochang
assignee: hypnotoad
closer: nobody
comment:
  ::zipfile::decode::GetFile method does not check the ::zipfile::decode::native_zip_functs flag, and use "zip" command directly.

  Reference is ::zipfile::decode::CopyFile method, if native_zip_functs flag is 1, use "zlib" command. And if native_zip_functs flag is not 1, use "zip" command.


tkt_uuid: 776a75f14f53b5c9a06fe3f3892485a6efe1dc20
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: linearalgebra
priority: 5 Medium
severity: Critical
foundin: 1.1.5
title: ::math::linearalgebra::conforming fails on 'matmul' when at least one object is a vector
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: anonymous
closedate: 2457902.77824725
comment:
  Example:
  set m1 {{11} {12}}
  set m2 {111 112}
  ::math::linearalgebra::conforming matmul $m1 $m2
   -> 0 # which is wrong
  ::math::linearalgebra::matmul $m1 $m2
   -> {1221 1232} {1332 1344} # which is correct

  The reason is that ::math::linearalgebra::shape returns only one dimension for vectors and this is not handled:
  ::math::linearalgebra::shape $m1
   -> 2 # no column information for m1


tkt_uuid: 7d93822003c82f702dd964b8a3204ea22638ded6
type: Bug
status: Closed
resolution: Fixed
subsystem: json :: write
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: e5d10350471142f963d2acde488a21cddedff493
title: json::write: Errors in json_write.pcx
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457904.16854003
comment:
  The checker for json::write in modules/json/json_write.pcx is missing a final closing brace '}' on line 38.

  Also, the tclchecker from TclDevKit v5.4.1 complains about checkSimpleArgsModNk in the same file:

  (pcxError) Bad PCX definition for "::json::write": "wrong # args: should be "checkSimpleArgsModNk min max n k argList tokens index""


tkt_uuid: 14e2c2cbba2a5bf8b78c9952426091601bdb4663
type: Bug
status: Open
resolution: None
subsystem: Documentation
priority: 5 Medium
severity: Minor
private_contact: 5369774a02bfd7af4e087486ce02de4dce243145
title: Update aycock parser example to include lexer
cmimetype: text/plain
submitter: bairui
assignee: kennykb
closer: nobody
comment:
  Please update the aycock parser example to include a lexer. Thanks!

  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/grammar_aycock/aycock.html

  A suggested replacement:

  proc lex {expression} {
    set tokens {}
    set values {}
    while {$expression ne {}} {
      if {[regexp {^([+*])(.*)} $expression -> token rest]} {
        # Single-character operators
        lappend tokens $token
        lappend values {}
      } elseif {[regexp {^([[:digit:]]+)(.*)} $expression -> token rest]} {
        # Numbers
        lappend tokens NUMBER
        lappend values $token
      } elseif {[regexp {^([()])(.*)} $expression -> token rest]} {
        # Brackets
        lappend tokens $token
        lappend values {}
      } elseif {[regexp {^[[:space:]]+(.*)} $expression -> rest]} {
        # Whitespace
      } else {
        # Anything else is an error
        return -code error -errorcode [list CALC \
        [string index $expression 0]] [list invalid character [string index $expression 0]]
      }
      set expression $rest
    }
    return [list $tokens $values]
  }

  set p [grammar::aycock::parser {
      start ::= E {}
      E ::= E + T {expr {[lindex $_ 0] + [lindex $_ 2]}}
      E ::= T {}
      T ::= T * F {expr {[lindex $_ 0] * [lindex $_ 2]}}
      T ::= F {}
      F ::= NUMBER {}
      F ::= ( E ) {lindex $_ 1}
  }]
  lassign [lex {( 2 + 3 ) * ( 7 + 1 )}] tokens values
  puts [$p parse $tokens $values]
  $p destroy


tkt_uuid: 0dd4b31bb8b3c1ce41e609a551564f73ae076b78
type: Bug
status: Closed
resolution: Accepted
subsystem: profiler
priority: 5 Medium
severity: Minor
foundin: 8.5.13
private_contact: e1e289e81f931be9eb396cfee59849a6b74fd383
title: profiler::leaveHandler doesn't return result
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458659.38716569
comment:
  The profiler::leaveHandler doesn't return the result, which means it's not available for subsequent leave handlers in the chain. 

  See https://core.tcl.tk/tcl/tktview/2811381fffffffffffff for more information.

  Here is a demo of the problem and a "proof of concept" fix. First, show the problem by creating a procedure while the profiler is active (so it gets the profiler trace handlers) then adding my own trace handler:

  (Desktop) 1 % package require profiler
  0.3
  (Desktop) 2 % profiler::init
  (Desktop) 3 % proc echo args {puts $args; return $args}
  (Desktop) 4 % proc tracer args {puts $args; return $args}
  (Desktop) 5 % trace add execution echo leave tracer
  (Desktop) 6 % echo hi
  hi
  {echo hi} 0 {} leave
  hi

  Note that the trace output shows result as {} when it should be hi. Now redefine the profiler leave handler to return the result:

  (Desktop) 11 % proc profiler::leaveHandler {name caller} {
  > 
  >     variable enabled
  > 
  >     if { !$enabled($name) } {
  >         return [uplevel 1 {lindex $args 1}] ;# RETURN RESULT!
  >     }
  > 
  >     set t [::profiler::tMark $name.$caller]
  >     lappend ::profiler::statTime($name) $t
  > 
  >     if { [incr ::profiler::callCount($name)] == 1 } {
  >         set ::profiler::compileTime($name) $t
  >     }
  >     incr ::profiler::totalRuntime($name) $t
  >     if { [catch {incr ::profiler::descendantTime($caller) $t}] } {
  >         set ::profiler::descendantTime($caller) $t
  >     }
  >     if { [catch {incr ::profiler::descendants($caller,$name)}] } {
  >         set ::profiler::descendants($caller,$name) 1
  >     }
  > 
  >     return [uplevel 1 {lindex $args 1}] ;# RETURN RESULT!
  > }

  Note that since the result isn't passed into leaveHandler, I use [uplevel 1 {lindex $args 1}] to get it in the caller's context. The problem is fixed:

  (Desktop) 13 % echo hi
  hi
  {echo hi} 0 hi leave
  hi


tkt_uuid: 71deadcf967a876520dad74d239abacdd22a1516
type: Patch
status: Closed
resolution: Accepted
subsystem: pt (parsetools)
priority: 8
severity: Severe
foundin: trunk
title: Improve import from TclOO engine: respect namespace scope [198a9c1da2]
cmimetype: text/plain
submitter: ssoberni
assignee: akupries
closer: aku
closedate: 2457910.38291617
comment:
  Hi Andreas!

  This is a patch [198a9c1da2] to align TclOO and NX default namespace scopes. Unpatched, one cannot instantiate the NX engine multiple times because the embedded stack objects are scoped for one namespace in NX, which is not intended and will throw up.

  Another cosmetic change is that originally, for convenience, I had uncommented the final return statement, to be able to generate/instantiate an engine class inline. I reverted that change, can be achieved more easily by providing a barebones template in my use cases: @code@.

  Thx,
  Stefan


tkt_uuid: d0dd236f1cfeb4a2c67e8dad398a670f9ab097b7
type: Bug
status: Open
resolution: None
subsystem: fileutil
priority: 5 Medium
severity: Important
foundin: 1.18
private_contact: 20fa134be7d51bcb5923d6ce5efd8c1eebd9a267
title: fileutil::maketempdir broken under Windows
cmimetype: text/plain
submitter: sbromle
assignee: nobody
closer: nobody
comment:
  The current implementation of fileutil::MakeTempDir (version 1.18) makes
  use of the "-permissions" option of [file attributes], which is not
  supported under MS Windows. This causes fileutils::maketempdir to break under
  Windows.
  A suggested fix is to first check whether the OS is UNIX, as in the modified (patch-like) version below:

  proc ::fileutil::MakeTempDir {config} {
      # Setup of default configuration.
      array set options {}
      set options(-suffix) ""
      set options(-prefix) "tmp"
      set options(-dir)    [tempdir]

      # TODO: Check for and reject options not in -suffix, -prefix, -dir
      # Merge user configuration, overwrite defaults.
      array set options $config

      # See also "tempfile" below. Could be shareable internal configuration.
      set chars abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
      set nrand_chars 10
      set maxtries    10

      for {set i 0} {$i < $maxtries} {incr i} {
  	# Build up the candidate name. See also "tempfile".
  	set directory_name $options(-prefix)
  	for {set j 0} {$j < $nrand_chars} {incr j} {
  	    append directory_name \
  		[string index $chars [expr {int(rand() * 62)}]]
  	}
  	append directory_name $options(-suffix)
  	set path [file join $options(-dir) $directory_name]

  	# Try to create. Try again if already exists, or trouble
  	# with creation and setting of perms.
  	#
  	# Note: The last looks as if it is able to leave partial
  	# directories behind (created, trouble with perms). But
  	# deleting ... Might pull the rug out from somebody else.

  	if {[file exists $path]} continue
  	if {[catch {
  	    file mkdir $path
  -           file attributes $path -permissions 0700
  +           if {$::tcl_platform(platform) eq "unix"} {
  +              file attributes $path -permissions 0700
  +           }
  	}]} continue

  	return $path
      }
      return -code error "Failed to find an unused temporary directory name"
  }


tkt_uuid: cfc5194fa29b4cdb20a6841068bea82d34accd7e
type: Bug
status: Open
resolution: None
subsystem: (unused)
priority: 5 Medium
severity: Minor
title: json::dict2json does not support list values
cmimetype: text/plain
submitter: tdiesler
assignee: nobody
closer: nobody
comment:
  Please note, that the value of 'snapdeps' is a list of dictionaries

  {
  "projId": "ProjENext",
  "vcsUrl": "https://github.com/FuseCID/cidpocE",
  "commit": "2a22b54",
  "number": "8",
  "snapdeps": [
     {
     "projId": "ProjB",
     "vcsUrl": "https://github.com/FuseCID/cidpocB",
     "commit": "162260d",
     "number": "16",
     "snapdeps": []
     },
     {
     "projId": "ProjDNext",
     "vcsUrl": "https://github.com/FuseCID/cidpocD",
     "commit": "2782d2a",
     "number": "14",
     "snapdeps": [
        {
        "projId": "ProjA",
        "vcsUrl": "https://github.com/FuseCID/cidpocA",
        "commit": "dcff2f9",
        "number": "12",
        "snapdeps": []
        },
        {
        "projId": "ProjB",
        "vcsUrl": "https://github.com/FuseCID/cidpocB",
        "commit": "162260d",
        "number": "16",
        "snapdeps": []
        }]
     }]
  }


tkt_uuid: 104f9c91a5d361ee6593bcc3206ff6b59d674a06
type: Patch
status: Closed
resolution: Accepted
subsystem: irc
priority: 5 Medium
severity: Minor
foundin: tcllib 1.18
private_contact: cd4f1973f31f720f1029be69fa16f46c8f4b7cd6
title: bug in file irc.tcl in the proc ::irc::config
cmimetype: text/plain
submitter: minduser00
assignee: aku
closer: aku
closedate: 2458143.33075931
comment:
  I found a bug in de file irc.tcl The bug occurs when calling the proc ::irc::config with a single parameter.
  After consulting the source code, the error is caused by a failure in the logic of the function. This is a possible solution, the proc has been tested and resolves that bug

  proc ::irc::config { args } {
      variable config
      switch [llength $args] {
          0   { return [array get config] }
          1 -
          2   {
              set key [lindex $args 0]
              if { [llength $args] == 1 } {
                  return $config($key)
              }
              set value [lindex $args 1]
              foreach ns [namespace children] {
                  if { [info exists config($key)] && [info exists ${ns}::config($key)] \
                          && [set ${ns}::config($key)] == $config($key)} {
                      ${ns}::cmd-config $key $value
                  }
              }
              set config($key) $value
          }
          default { error "wrong # args: should be \"config key ?val?\"" }
      }
  }


tkt_uuid: 85a0ec8f509fcbf9873caa9798e79ed95fbe9f15
type: Bug
status: Closed
resolution: Fixed
subsystem: textutil
priority: 9 Immediate
severity: Minor
foundin: 1.18
private_contact: f4b679459a3c52d67a51ecd06fa3fba663ebe607
title: [::textutil::splitx foo |] hangs
cmimetype: text/x-fossil-wiki
submitter: dbohdan
assignee: aku
closer: aku
closedate: 2457973.4970728
comment:
  Running <tt>::textutil::splitx</tt> with <tt>|</tt> as the regexp causes <tt>splitx</tt> to enter an infinite loop that eats up all available RAM.

  The obvious solution is to check whether at least one character is consumed per iteration. However, KBK proposed a more elegant alternative in the chatroom: checking if the given regexp matches an empty string.

  Sample implementation:
  <pre>
      proc ::textutil::split::splitx {str {regexp {[\t \r\n]+}}} {
          # Bugfix 476988
          if {[string length $str] == 0} {
              return {}
          }
          if {[string length $regexp] == 0} {
              return [::split $str ""]
          }
  +       if {[regexp $regexp {}]} {
  +           error "splitting on regexp \"$regexp\" would cause infinite loop"
  +       }
  </pre>


tkt_uuid: e2cc72f49661077c500d244294e7ae7a6fdfb04f
type: Patch
status: Closed
resolution: Accepted
subsystem: inifile
priority: 5 Medium
severity: Important
foundin: 0.3
private_contact: 2317bfc5aaa3e103a3f9efbd479fc51b4b22beea
title: The encoding option affect only the open of the inifile, not writing
cmimetype: text/plain
submitter: géballin
assignee: aku
closer: aku
closedate: 2458143.32313465
comment:
  When used, the encoding option affect the initial open of the inifile for reading but not the open for writing and not the third open for reading again.

  This is the diff in ini.tcl to solve that :
  62,67c62
  < 	if {[catch {
  < 	    fconfigure $tmp -encoding $enc
  < 	} msg]} {
  < 	    ::close $tmp
  < 	    return -code error $msg
  < 	}
  ---
  > 	_setfileenc $fh $enc
  77a73
  >     ::set ::ini::${fh}::enc     $enc
  85a82,90
  > proc ::ini::_setfileenc {fh enc} {
  > 	if {[catch {
  > 	    fconfigure $tmp -encoding $enc
  > 	} msg]} {
  > 	    ::close $tmp
  > 	    return -code error $msg
  > 	}
  > }
  > 
  107a113
  >     variable ::ini::${fh}::enc
  116a123,125
  >     if {[info exists enc]} {
  > 		_setfileenc $fh $enc
  >     }
  134a144,146
  >     if {[info exists enc]} {
  > 		_setfileenc $fh $enc
  >     }


tkt_uuid: 78f27a417fda43e90b97c9074989c317cb532b7c
type: Patch
status: Closed
resolution: Duplicate
subsystem: irc
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: cd4f1973f31f720f1029be69fa16f46c8f4b7cd6
title: Patch for a bug in de proc cmd-config in the file irc.tcl
cmimetype: text/plain
submitter: minduser00
assignee: aku
closer: aku
closedate: 2458143.33202146
comment:
  if proc cmd-config is called with one parameter, the program stops because de variable 'key' is not set yet
  this patch is a possible solution.

      proc cmd-config { args } {
          variable config
          variable logger
          if { [llength $args] == 0 } {
              return [array get config]
          } elseif { [llength $args] > 2 } {
              error "wrong # args: should be \"config key ?val?\""
          }
          set key [lindex $args 0]
          if { [llength $args] == 1 } {
              return $config($key)
          }
          set value [lindex $args 1]


tkt_uuid: b9cc3f892dc76b509793ce5b61bd1f0564aafba5
type: Bug
status: Closed
resolution: Fixed
subsystem: md5
priority: 9 Immediate
severity: Important
foundin: 78d7722e1e93b795aa305756c83da3b63f820e8d
title: md5 prints debugging info
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2457973.50133741
comment:
  Just a rogue puts.

  % source modules/md5/md5x.tcl
  % md5::md5 -hex abcd
  md5_______________________________________________
  ::::md5::1(A) = 1732584193
  ::::md5::1(B) = 4023233417
  ::::md5::1(C) = 2562383102
  ::::md5::1(D) = 271733878
  ::::md5::1(i) = 
  ::::md5::1(n) = 0
  IN=((abcd))
  md5-final_________________________________________
  ::::md5::1(A) = 1732584193
  ::::md5::1(B) = 4023233417
  ::::md5::1(C) = 2562383102
  ::::md5::1(D) = 271733878
  ::::md5::1(i) = abcd
  ::::md5::1(n) = 4
  P 52|bits=32
  DATA=61626364800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000(64)
  TR__=61626364800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000(64)
  BL
  md5-post__________________________________________
  ::::md5::1(A) = 121541623010
  ::::md5::1(B) = 127035909959
  ::::md5::1(C) = 123700835221
  ::::md5::1(D) = 120782552878
  ::::md5::1(i) = abcd 
  ::::md5::1(n) = 4
  HASH=E2FC714C4727EE9395F324CD2E7F331F
  E2FC714C4727EE9395F324CD2E7F331F
  %


tkt_uuid: 5465d70388dca48916ec50cdfd58959854bbdf3e
type: Bug
status: Closed
resolution: Fixed
subsystem: virtchannel base
priority: 8
severity: Important
foundin: 78d7722e1e93b795aa305756c83da3b63f820e8d
private_contact: 662c23482b0bf6a505f39e48fb7ad43af8dee4d3
title: Off-by-one end-relative seeking in memchan/string/variable refchans
cmimetype: text/plain
submitter: andy
assignee: aku
closer: aku
closedate: 2457973.55650924
comment:
  End-relative seeking in memchan, string, and variable refchans ends up at one byte before the requested position.  [seek $chan 0 end; tell $chan] should return the "file size", i.e. underlying string length, but for these types of channels, it gives one less than the file size.


tkt_uuid: 2fb3d28f6beddcb7b6673f36d5881fe7cdc94e51
type: Bug
status: Closed
resolution: Fixed
subsystem: ip
priority: 8
severity: Minor
foundin: 1.3
private_contact: a13bc415aba29b956a786d75407d6de5128332f7
title: ::ip::version documentation incorrect about return value for invalid IP address
cmimetype: text/plain
submitter: glennj
assignee: aku
closer: aku
closedate: 2457982.22363038
comment:
  The documentation for [::ip::version] states that the return value is "0 if the address is neither IPv4 or IPv6" (https://core.tcl.tk/tcllib/artifact/6aa6816e4a887b2b) but the proc actually returns -1 (https://core.tcl.tk/tcllib/artifact/4acc0edd932ed735)


tkt_uuid: cb043ecc70e0e90bff93535d1d371a78b94f5d44
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: geometry
priority: 5 Medium
severity: Important
foundin: trunk
private_contact: 2287a4a5f84eadc47fdc912609f4f98319372d33
title: areaPolygon miscalculates area
cmimetype: text/plain
submitter: avl42
assignee: aku
closer: aku
closedate: 2457973.48786089
comment:
  The original version returns 200.0 for the example in the comment, because it completely ignored the first point, and also didn't treat the polygon as closed.

  Here is the fixed version of the proc:
  mods: init of b1,b2   and  iterate the whole list
  minor extra mod: the extra parens should improve precision for small polygons far away from origin.

  proc ::math::geometry::areaPolygon {polygon} {

      # get last pair of the polygon for start:
      set b1 [lindex $polygon end-1]; set b2 [lindex $polygon end]

      set area 0.0
      foreach {c1 c2} $polygon {
          set area [expr {$area + ($b1*$c2 - $b2*$c1)}]
          set b1   $c1
          set b2   $c2
      }
      expr {0.5*abs($area)}
  }


tkt_uuid: 4cca6e630bfc67bcbbf07170879a8d53f0cc8f3e
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 6
severity: Important
foundin: latest
private_contact: fa09ce56b142615648245eacd3f561c3ad279373
title: Fix for ht_comment
cmimetype: text/plain
submitter: gjr.timmer
assignee: aku
closer: aku
closedate: 2457994.24933719
comment:
  I tried to use a mailto in the copyright, so the user could click my name.

  Command:
  [copyright "2017, [uri mailto:gjr.timmer@gmail.com {G.J.R. Timmer}]"]

  However this will cause a malformed body, because of the end result being unescaped html placed within the <head> as comment.

  This applies to all functions which are using the ht_comment.

  Origin of bug: doctools/mpformats/_html.tcl#183

  Current Code:
  proc ht_comment {text}   {
      return "[markup <]! -- [join [split $text \n] "   -- "]\n   --[markup >]"
  }


  Proposed solution: (Add HTML Escaping to comments)

  proc ht_comment {text}   {
      return "[markup <]! -- [htmlEscape [join [split $text \n] "   -- "]]\n   --[markup >]"
  }

  This will ensure that comments which may automatically contain html codes are placed correctly within the HTML output.


tkt_uuid: 82d77f6e1f80e1f5689864f7abdf89b0820cc9d9
type: Patch
status: Closed
resolution: Fixed
subsystem: doctools
priority: 6
severity: Important
foundin: 1.4.19
private_contact: fa09ce56b142615648245eacd3f561c3ad279373
title: Add <!DOCTYPE html> to doctools generated pages
cmimetype: text/plain
submitter: gjr.timmer
assignee: aku
closer: aku
closedate: 2457982.29325152
comment:
  When using additional style-sheets like bootstrap (http://getbootstrap.com/) to format the documentation pages, the entire bootstrap layout is malformed because the <!DOCTYPE html> tag is missing from the document.

  Attached the patches to correct this.
  This has been tested.


tkt_uuid: cd4fe2d0471a7be1524314421eea45243b0e1738
type: Bug
status: Open
resolution: None
subsystem: (unused)
priority: 7 High
severity: Severe
foundin: 1.1.3 of coroutine::auto
private_contact: 1ba83818ae951a8f52f8388b4c9201ce2b2eecd4
title: coroutine::auto causes auto_load to fail
cmimetype: text/plain
submitter: tom@wildturkeyranch.net
assignee: aku
closer: nobody
comment:
  coroutine::auto, among other things redefines "global". If, while in a coroutine an unknown command is encountered the auto_load mechanism is invoked to load the command. This fails because auto_load and friends depend on the globals auto_index and auto_path (at least). Here is a simple test routine that fails:

  !/bin/env tclsh
  #
  # try clock format from inside a corouting
  #
  #package require Tk
  package require coroutine::auto
  package require coroutine
   
  variable clockFormat "On %D at %H:%M:%S" 

  proc t1 {} {
    variable clockFormat
    set tm [clock format [clock seconds] -format $clockFormat]
    puts "$tm"
  }

  coroutine cor_foo t1
  t1

  # end of test routine
  Here is a workaround for this problem:

  if {[catch {info body global}] == 0} {
    # the real 'global' is not a procedure
    set ns ::coroutine::auto
    rename ::global ${ns}::wrap_global
    rename ${ns}::core_global ::global
  }

  A comment on what I think ought to be the real fix:

  First, I think "global" should not be renamed or replaced. What is wanted/needed is a coroutine local global which the current code puts at 'uplevel #1'  This seems fine except for the notion of calling such variables 'global's.  This is a new sort of global and, as such, ought to have a new name, for example corglobal" corglobal, should throw and error if it is called outside of a coroutine.

  An issue I don't see resolved is how to refer to a corglobal form outside of the coroutine, such as, for example, a textvariable, or a command script to be executed when a button is pressed.


tkt_uuid: 430c5bbc9fe02932a7c868f2d9e565f01aa5ce46
type: RFE
status: Open
resolution: None
subsystem: pt (parsetools)
priority: 5 Medium
severity: Minor
private_contact: ba302c5a744ad0a8e535de53c282a0121b4c2d00
title: Allow case insensitive matching of literals
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  It would be handy to be possible to specify case insensitive matching of literals string in PEG expression.


tkt_uuid: eb8c1e69ba76594f03b296d4dcf9ffc52b4f2521
type: RFE
status: Open
resolution: None
subsystem: pt (parsetools)
priority: 3 Low
severity: Minor
private_contact: ba302c5a744ad0a8e535de53c282a0121b4c2d00
title: Add "prune" mode
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  In addition to "value", "void" and "leaf", I'd like to have "prune": if a non terminal is empty or contains a single non terminal, then it is removed from the resulting AST, only the right side is kept (if non empty).


tkt_uuid: 45fe064cf2454dd3ae1b14f6d1e8a7eb605e4b5f
type: Bug
status: Closed
resolution: Fixed
subsystem: math
priority: 6
severity: Important
foundin: 1.0.3
private_contact: 15424da1de3696414eea007b0323e57db90a38b9
title: math::decimal documentation examples wrong
cmimetype: text/plain
submitter: ricardo-andre
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2457995.77113799
comment:
  The examples in the documentation for math::decimal examples are wrong.

  (see <http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/math/decimal.html#section2>)

  Where it reads:

  # Then we perform our operations. Here we multiply
  set c [::math::decimal::* $a $b]

  Instead of "multiply" it should be "add". That is consistent with the value of 8.4 expected as output later on. Plus, an example with multiplication would be a lesser one, because the multiplication will output 1.64 as expected also with [expr]. So it should be:

  # Then we perform our operations. Here we add
  set c [::math::decimal::+ $a $b]


  Also, on "Why bother using this instead of simply expr?", it is:

  puts 8.399999999999999 ; # => will output 8.399999999999999
  puts 7.999999999999999 ; # => will output 7.999999999999999

  Most likely the examples were meant to show the numerical error with [expr], e.g.:

  puts [expr 8.2+0.2] ; # => will output 8.399999999999999
  puts [expr 8.2-0.2] ; # => will output 7.999999999999999


  Finally, at the start of the example the [package require] line is:

  package require decimal

  when it should be:

  package require math::decimal


tkt_uuid: 7d12acd105601e1728e9312204a19c6a4cef82f3
type: Bug
status: Open
resolution: None
subsystem: uri
priority: 5 Medium
severity: Minor
title: uri::split does not parse file schemes correctly on Windows
cmimetype: text/plain
submitter: apnadkarni
assignee: nobody
closer: nobody
comment:
  I am not entirely sure of URI syntax but I believe the following is a bug. At least uri::join and uri::split should be complementary.

  % set p [uri::join scheme file path [pwd]]
  file:///C:/src/tdom/tests
  % uri::split $p
  path /C:/src/tdom/tests scheme file

  The path element should not conttain a leading /


tkt_uuid: 1f900bdf6bb6369987598e8c5f36a1e0f62b9798
type: Patch
status: Closed
resolution: Accepted
subsystem: ncgi
priority: 7 High
severity: Minor
foundin: 1.18
title: improve ncgi's decode procedure
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458659.26977723
comment:
  In practice www-url-encoded POST params can use encodings other than UTF-8 (think of legacy Tcl applications that use one of the ISO-8859-x charsets). In this case URL parameters can contain references to 8-bit code points (in the form of %[A-F8-9][A-F0-9]) that are not valid UTF-8 code points.

  For example, %DC can be used as a percent encoding for the german umlaut Ü (if a Tcl application is based on ISO-8859-1). Currently, the decode procedure does not decode %DC as all one byte UTF-8 code points must start with [0-7].

  This commit improves the handling of one byte percent encoded non-ASCII characters in the form of %[A-F8-9][A-F0-9]. It allows to use ncgi in application contexts that do not use UTF-8 as the base encoding.

  A pull request was created on Github. See https://github.com/tcltk/tcllib/pull/13 for more details. Thanks!


tkt_uuid: 6b29fddb21ceff35f0bee4c23aa4d057bbbedbe8
type: Bug
status: Closed
resolution: Invalid
subsystem: mime
priority: 5 Medium
severity: Severe
foundin: 1.6
private_contact: 2ccc20c12d68b9687ccb299dd85d4c164ff874ac
title: Mime package not handling multipart/form-data
cmimetype: text/plain
submitter: gwlester
closer: pooryorick
closedate: 2458360.75758323
comment:
  According to RFC7578 (https://www.rfc-editor.org/info/rfc7578) section 4.2 states: " Each part MUST contain a Content-Disposition header field [RFC2183] where the disposition type is "form-data".  The Content-Disposition header field MUST also contain an additional parameter of "name"; the value of the "name" parameter is the original field name from the form (possibly encoded; see Section 5.1)."

  Currently, the package neither generates this nor parses it.


tkt_uuid: bbe4b8eca4fc8152e4db4517940beafc2da3d33d
type: Bug
status: Open
resolution: None
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 1.0
private_contact: e5d10350471142f963d2acde488a21cddedff493
title: dicttool: errors in dict rmerge documentation
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  The documentation for dicttool lists the 'rmerge' command when it should instead be 'dict rmerge':

  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/dicttool/dicttool.html#6

  Furthermore, the example shown for 'dict rmerge' is confusing, since it only uses 'dict merge' and does not show example output for 'dict rmerge'.


tkt_uuid: 104809e450a5988162890bdbc654e0f6bf555a41
type: Bug
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 5 Medium
severity: Critical
private_contact: 6dd0e94ecdc3b26170a7664fd6e9557e5e4ccc48
title: [coroutine::util read] swallows data when the channel becomes blocked
cmimetype: text/x-fossil-wiki
submitter: pooryorick
closer: pooryorick
closedate: 2458017.07884561
comment:
  When a channel is in non-blocking mode <code>::chan read</code> may return some
  data but then also cause a subsequent <code>chan blocked</code> to return
  <code>1</code>.  <code>::coroutine::util read</code> currently fails to account
  for this scenario, and the data that was just read is swallowed.


tkt_uuid: d74e418e847ce61d81429abc24b539c181965176
type: Bug
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 5 Medium
severity: Minor
private_contact: 6dd0e94ecdc3b26170a7664fd6e9557e5e4ccc48
title: [::coroutine::util read] closes the channel
cmimetype: text/x-fossil-wiki
submitter: pooryorick
closer: pooryorick
closedate: 2458017.07848992
comment:
  <code>::coroutine::util read</code> currently closes the channel when
  <code>eof</code> is true, but that isn't the job of <code>read</code>, and
  can interfere with common usage.


tkt_uuid: d74e6561a29ca0dca4d6198a46aa9474e20e34ad
type: Bug
status: Open
resolution: None
subsystem: yaml
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 411315ec769379ea86b165441afa60d632da17e5
title: YAML->HUDDLE->YAML fails
cmimetype: text/plain
submitter: emmanuel
assignee: nobody
closer: nobody
comment:
  Converting a YAML file to huddle and back again to YAML will not work. This is because the implementation of huddle2yaml does not pay attention to the internal types that are introduced by the YAML parser to support dictionaries and lists. The following piece of code solves it:

      proc ::yaml::_imp_huddle2yaml {data {offset ""}} {
          set nextoff "$offset[string repeat { } $yaml::_dumpIndent]"
          switch -glob -- [huddle type $data] {
              "int*" -
              "str*" {
                  set data [huddle get_stripped $data]
                  return [_dumpScalar $data $offset]
              }
              "sequence" -
              "list" {
                  set inner {}
                  set len [huddle llength $data]
                  for {set i 0} {$i < $len} {incr i} {
                      set sub [huddle get $data $i]
                      set tsub [huddle type $sub]
                      set sep [expr {[string match "str*" $tsub] || [string match "int*" $tsub] ? " " : "\n"}]
                      lappend inner [join [list $offset - $sep [_imp_huddle2yaml $sub $nextoff]] ""]
                  }
                  return [join $inner "\n"]
              }
              "mapping" - 
              "dict" {
                  set inner {}
                  foreach {key} [huddle keys $data] {
                      set sub [huddle get $data $key]
                      set tsub [huddle type $sub]
                      set sep [expr {[string match "str*" $tsub] || [string match "int*" $tsub] ? " " : "\n"}]
                      lappend inner [join [list $offset $key: $sep [_imp_huddle2yaml $sub $nextoff]] ""]
                  }
                  return [join $inner "\n"]
              }
              default {
                  return $data
              }
          }
      }


tkt_uuid: 51c03aac1a45161ab6cc59afb69d1768175e054c
type: Bug
status: Closed
resolution: Fixed
subsystem: math :: statistics
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: edc79092ea3d48d084f7f8ca282b90c1120dedfe
title: Error raised in mv-ols for what should be valid input
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2458033.37499809
comment:
  ::math::statistics::mv-ols {{0 25125 128} {0 23224 64} {0 37903 512} {0 21263 32} {0 22053 64} {0 25745 256} {0 25745 256} {0 21557 32} {0 24935 128} {0 22904 64} {0 21422 32} {0 21947 32} {0 33244 512} {0 33244 512} {0 30060 512} {0 29691 256} {0 30439 256} {0 23724 128} {0 22541 64} {0 23640 128} {0 21422 32} {0 23640 128} {0 22249 64} {0 28247 512} {0 23333 32} {0 29841 256} {0 23959 128} {0 30819 512} {0 26333 256} {0 22145 32} {0 23863 128} {0 20772 32} {0 28511 512} {0 22425 64} {0 21598 32} {0 26335 256} {0 23816 128} {0 21157 32} {0 20973 32} {0 20973 32} {0 35125 512} {0 20679 32} {0 21241 64} {0 25297 256} {0 22301 32} {0 22007 32} {0 33351 512} {0 24115 128} {0 24115 128} {0 22301 32} {0 22797 64} {0 22593 64} {0 26439 256} {0 21255 32} {0 22645 32} {0 23447 128} {0 24205 64} {0 25051 128} {0 21007 32} {0 28237 256} {0 25546 128} {0 25669 256} {0 25669 256} {0 25669 256} {0 21977 64} {0 21977 64} {0 26187 128} {0 38360 512} {0 31846 256} {0 28349 256} {0 26450 128}}

  This dies with the following error message.  It seems to me that regression should work even if all y values are 0.  It's a pretty boring regression, but not worth failing over.  Maybe just needs a special case to handle this kind of input.

   domain error: argument not in valid range
      while executing
  "expr {double($ssreg)/$sstot}"
      (procedure "mv-wls" line 111)
      invoked from within
  "mv-wls $newdata"
      (procedure "::math::statistics::mv-ols" line 6)
      invoked from within
  "::math::statistics::mv-ols $data"


tkt_uuid: 819e42b05c7c30ab6225249be3f96d814997c0ac
type: Bug
status: Closed
resolution: Fixed
subsystem: md4
priority: 5 Medium
severity: Minor
private_contact: f0e2312a244c99b69b66ff52a743015292c5af63
title: md4 requires wrong package version
cmimetype: text/plain
submitter: bovine
assignee: aku
closer: aku
closedate: 2458058.3414635
comment:
  In the file modules/md4/md4.tcl, version 1.0 is required:
  https://core.tcl.tk/tcllib/artifact/a26bcde2a4fdea3b

      catch {package require md4c 1.0};       # tcllib critcl alternative


  But in modules/md4/md4c.tcl, version 1.1.0 is provided:
  https://core.tcl.tk/tcllib/artifact/f272eb0a02c81259

      package provide md4c 1.1.0

  This causes a spurious error to occur, which can be noticed if you have a global error handler in your parent program.


tkt_uuid: 3ed39a451f8ae9a48a221f90c7a74e2f99d8319d
type: RFE
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 8
severity: Important
foundin: trunk
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: Farthest failure path (FFP) tracking in PT/PEG [ssoberni-ffp-3ed39a451f]
cmimetype: text/plain
submitter: ssoberni
assignee: aku
closer: aku
closedate: 2458309.32371157
comment:
  Hi Andreas,

  As briefly discussed yesterday on IRC, I am interested in getting FFP tracking/reporting into the PARAM machinery. Right now, an FFP heuristic is applied in error handling, but it is confined within a given context (a choice). An overall (global) FFP is not maintained for a parse.

  For the NX backend (::pt::rde), I got an FFP extension (see script attached). I wonder, however, how this would be best become integrated into the base machinery, as all backends would benefit from this (practical error tracking in PEGs is much more convenient with an FFP hint). 

  The main idea of the extension is to intercept on "choice exits", intermittent exits (inter*) and actual exits (exit0/1), and update an FFP store (updateFFP). The update logic is basically the same operation as within choices: i_error_pop_merge (but without any popping). It works as expected (see the Tiny language example in the script).

  Qs:

  - How can this best be supported in the base machinery?
  - In my extension, the downside is that the intercepted SIs are not specific to  choices, but are also compiled into other parsing methods (sequences). So, the FFP update is triggered more often than necessary.
  - What are the consequences for error reporting: Should [complete] be made FFP aware, somehow?

  Let me know how I can help. That said, the extension works well for my needs. But I think PT users would benefit from this otherwise commonly available facility in its PARAM.

  For the records, the chat protocol from yesterday:

  m 2017-10-05T22:31:52Z ijchain {<mr_calvin> aku: around?}
  m 2017-10-05T22:32:28Z aku pong
  m 2017-10-05T22:32:48Z ijchain {<mr_calvin> regarding ffp for pt ...}
  m 2017-10-05T22:33:19Z ijchain {<mr_calvin> I got a minimal version (truly minimal) based on the nx backend, to show to you}
  m 2017-10-05T22:34:33Z aku {Oh, tcllib ticket ...}
  m 2017-10-05T22:34:46Z ijchain {<mr_calvin> not yet a ticket :)}
  m 2017-10-05T22:35:33Z aku {I believe I saw a ticket about `fail farthest p?` for pt::peg things ...}
  m 2017-10-05T22:35:49Z ijchain {<mr_calvin> was an email :)}
  m 2017-10-05T22:36:16Z aku {Ah. Ok, that is possible. I usually see ticket through mail notification, so might be scrambled there.}
  m 2017-10-05T22:36:33Z aku {somethng to me ... best shown in email as well, I believe ...}
  m 2017-10-05T22:39:55Z aku {I believe I will have to see how you did the instrumentation ....}
  m 2017-10-05T22:40:58Z ijchain {<mr_calvin> (obviously one can extend the basic si’s to just do what I do in a few line in the overloading methods, but you wrote in your email that you prefer sth. orthogonal)}
  m 2017-10-05T22:42:53Z aku {did I ... Suspect I have to reread ... I thought I said ... orthogonal first prefered, then integration ... If we need intregration we certainly can go there too ...}
  m 2017-10-05T22:43:12Z aku {well, I will see what is in your mail.}
  m 2017-10-05T22:44:13Z ijchain {<mr_calvin> downside of handling at this level of si’s that the ffp checks are done more often than necessary … triggering the ffp check “on error” is certainly more proportionate.}
  m 2017-10-05T22:50:12Z aku {mr_calvin - Is that even possible (doing the check only on error ?)}
  m 2017-10-05T22:54:12Z ijchain {<mr_calvin> well, “on error” in the sense of the i_error_pop_merge limbo …}
  m 2017-10-05T22:55:12Z ijchain {<mr_calvin> actually, right now, I try to capture what the inlined i_error_pop_merge logic does at the exit of a choice ...}
  m 2017-10-05T22:56:41Z ijchain {<mr_calvin> the thing is, that the si’s to do so are also fired when exiting sequences etc. it is not obvious to me how to limit it to “choice exits” …}
  m 2017-10-05T22:56:58Z ijchain {<mr_calvin> so I should have written “on choice exit” :)}
  m 2017-10-05T22:58:19Z aku {mr-calvin - ok, makes sense ... might new special si specific to choices then ...}
  m 2017-10-05T22:58:28Z aku {s/new/need new/}
  m 2017-10-05T22:58:37Z aku {put this all into the mail too, please}


tkt_uuid: 8659a16544549c77b75eb624d109985576af7cb3
type: Patch
status: Closed
resolution: Accepted
subsystem: yaml
priority: 7 High
severity: Minor
foundin: 0.3.10
private_contact: ed370a9a39466fe318de149a10eda29075002199
title: Support for !!float tag
cmimetype: text/plain
submitter: peterlewerin
assignee: aku
closer: aku
closedate: 2458058.35075126
comment:
  If YAML source contains the (standard) !!float tag, yaml fails with the message
   
  The "!!float" handle wasn't declared.
   
  In CHANGES, support for !!float is mentioned (0.2.2), but there is no composer for it. The above problem can easily be kludged away by stripping !!float tags, but it seems more correct to add support for them. Code and test diffs below.
   
  Possible problem with this patch: the decision how to handle values that can't be converted to float using expr {double($value)} is above me. For the purposes of this patch my decision is to let the Tcl exception remain unhandled, so for the value 123_0 the error message is
   
  expected floating-point number but got "123_0"
   
  While this side-steps the error handling in yaml, it is still a clear and useful message and keeps the patch simple. The alternative is of course to catch it and rethrow using the module's error handling, but that is a bigger rewrite.
   
  Code (yaml.tcl):
   
  50d49
  <             !!float ::yaml::_composeFloat
  249,252d247
  < }
  < 
  < proc ::yaml::_composeFloat {value} {
  <     return [list !!float [expr {double($value)}]]
   
  Test (yaml.test):
   
  769,785d768
  < test yaml-21.1 "explicit_tags float" -body {
  <     set y {!!float 123}
  <     yaml::yaml2dict $y
  < } -result {123.0}
  < 
  < 
  < test yaml-21.2 "explicit_tags float" -body {
  <     set y {!!float 123.0}
  <     yaml::yaml2dict $y
  < } -result {123.0}
  < 
  < 
  < test yaml-21.2 "explicit_tags float" -body {
  <     set y {!!float 123_0}
  <     yaml::yaml2dict $y
  < } -result {expected floating-point number but got "123_0"} -returnCodes error
  <


tkt_uuid: 644ec25013b52f37ed62856fb1660796e8683c99
type: Patch
status: Closed
resolution: Fixed
subsystem: dns
priority: 5 Medium
severity: Important
foundin: 1.3.5
private_contact: 7b121ba878eda31e382e197148dd730e2dc6b3a6
title: Review branch dns-rfc7858 adding DNS over TLS support.
cmimetype: text/plain
submitter: patthoyts
assignee: aku
closer: hypnotoad
closedate: 2458053.5183412
comment:
  Branch `dns-rfc7858` contains support for DNS over TLS queries. This is a privacy enhancement option being proposed and apparently included in Android so likely to become more prevalent in the future.


tkt_uuid: a12bff914de92abb0cc5a7e28bf0c80cffa40b94
type: Patch
status: Open
resolution: None
subsystem: smtp
priority: 5 Medium
severity: Important
foundin: 1.18
private_contact: 55ed3e0299ccb4fe6cc51ac1bfa759035ac8d705
title: add smtp.tcl support direct TLS connection with backward compatible
cmimetype: text/plain
submitter: raymin
closer: nobody
comment:
  Add smtp.tcl support direct TLS connection with backward compatible. 'direct TLS' should be used for situations where SSL is required from the beginning of the connection and using STARTTLS is not appropriate, such as on some SMTP server's 465 port.


tkt_uuid: da4520f0bc2a19b4855420ffda5a52ffe52884fb
type: Patch
status: Closed
resolution: Accepted
subsystem: http :: autoproxy
priority: 7 High
severity: Minor
foundin: 1.5.3
private_contact: fe43a83262eef1680511f524a1e74d43c633cffe
title: Review branch pt/avoid-old-ssl
cmimetype: text/plain
submitter: patthoyts
assignee: aku
closer: aku
closedate: 2458057.65478191
comment:
  Pull request for fixes to tests that try and use ssl2/ssl3 which is not supported in recent openssl. Switch to tls1.
  Also fixed issues in autoproxy and crc16 in other commits on this branch.


tkt_uuid: edbde89476054fa4d085ff06c75daeb718fd3abe
type: Patch
status: Closed
resolution: Accepted
subsystem: ldap
priority: 8
severity: Important
foundin: 1.18
private_contact: 483dded1f891b825ff245c8b35d091c1a59de7d3
title: ldap::starttls improperly uses tls::import
cmimetype: text/plain
submitter: gray
assignee: aku
closer: aku
closedate: 2458058.28215132
comment:
  ldap::starttls calls tls::import and then attempts to eval its result (i.e. a channel descriptor), which obviously fails. To reproduce, the following simple code can be used:

    package require ldap 1.9
    set handle [::ldap::connect "SERVER"]
    ldap::starttls $handle

  This produces the following error:

    invalid command name "sock6"
      while executing
    "sock6 -tls1 yes -tls1.1 yes -tls1.2 yes"
      ("eval" body line 1)
      invoked from within
    "eval $cmd"
      (procedure "::ldap::starttls" line 63)

  The following patch fixes this bug:

  --- tcllib1.18-orig/ldap/ldap.tcl       2017-10-27 03:25:32.000000000 +0300
  +++ tcllib1.18/ldap/ldap.tcl    2017-10-31 15:00:09.065262029 +0200
  @@ -534,11 +534,10 @@ proc ldap::starttls {handle {cafile ""}
               "Unexpected LDAP response"
       }

  -
       # Initiate the TLS socket setup
  -    set cmd [tls::import $conn(sock)
  +    set cmd [list tls::import $conn(sock) \
                            -cafile $cafile -certfile $certfile -keyfile $keyfile \
  -                         -request 1 -server 0 -require $verify -ssl2 no -ssl3 no ]
  +                         -request 1 -server 0 -require $verify_cert -ssl2 no -ssl3 no]

       if {$sni_servername ne ""} {
          lappend cmd -servername $sni_servername


tkt_uuid: a7fb3a643ce4b17cbb147eb37a5abe65f72db144
type: Bug
status: Open
resolution: None
subsystem: math
priority: 3 Low
severity: Minor
title: math::exact relies on bad Tcl resolution behaviour revoked by TIP 278 - Tcl 9
cmimetype: text/plain
submitter: dgp
assignee: aku
closer: nobody
comment:
  the math::exact package includes code like:

             next $math::exact::dneg
   
  where it relies on exactly the "try resolving
  in the global namespace" behavior that TIP 278
  gets rid of.

  Seems likely this package needs revision to work 
  in Tcl 9.


tkt_uuid: 4367201817b89224602de00b4b1cbad70180a77f
type: Bug
status: Open
resolution: None
subsystem: yaml
priority: 3 Low
severity: Minor
title: yaml relies on bad Tcl resolution behaviour revoked by TIP 278 - Tcl 9
cmimetype: text/plain
submitter: dgp
assignee: aku
closer: nobody
comment:
  Just one example:

  can't read "yaml::data(finished)": no such variable
      while executing
  "if {!$yaml::data(finished)} {
  ...

  yaml package is using the global namespace resolution
  rules for relative varnames that TIP 278 is revoking.


tkt_uuid: 95cf373829e2f60a047d8b3cedd039efc8a622f2
type: Bug
status: Open
resolution: None
subsystem: ldap
priority: 5 Medium
severity: Critical
title: ldap testsuite is fatally incomplete
cmimetype: text/plain
submitter: aku
assignee: schlenk
closer: nobody
comment:
  The tests for the ldap commands talking to an LDAP server test only the signature, i.e. `wrong#args` cases.

  Actual operation of these commands is *not* tested.

  Note that tcllib comes with test utilities to create mock servers. See the `pop3 `testsuite for a user. See `modules/devtools/{coserv,dialog}.tcl` for the helper implementation.

  Even if the existing helpers are not suitable as they are, we can always extend them with what is needed.

  IOW testing actual operation is feasible, without needing an external test server / endpoint.

  Not having such tests is big flaw of the testsuite.


tkt_uuid: bfbfc5c1273b4a45ec522d69ec6434a51a2aefea
type: RFE
status: Closed
resolution: Accepted
subsystem: Documentation
priority: 7 High
severity: Minor
private_contact: ed370a9a39466fe318de149a10eda29075002199
title: Add note about use of diff -u
cmimetype: text/plain
submitter: peterlewerin
assignee: aku
closer: aku
closedate: 2458059.32929335
comment:
  It can be hard to remember for occasional ticket writers, and some might not even know, that code diffs in unified format are preferred (among seasoned ticket writers this format is no doubt the most natural choice).

  I suggest adding a sentence to the text above the reporting box ("Enter a detailed ...") such as "For code changes, please use unified diffs, i.e `diff -u`."


tkt_uuid: e72cf5e815088248c923ed045372e4464f3e09a7
type: RFE
status: Closed
resolution: Accepted
subsystem: http :: autoproxy
priority: 8
severity: Minor
foundin: trunk
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: Extended autoproxy to works with twapi for https (configurable)
cmimetype: text/x-fossil-wiki
submitter: oehhar
assignee: aku
closer: oehhar
closedate: 2458226.17855346
comment:
  Twapi is helpful to be used for https on Windows instead the TLS package for update reasons (twapi gets updated with the operating system, with TLS (on windows), the program author must care to update openssl if required).

  For instance, it does not work with autoproxy.
  Wiki page for some details: [http://wiki.tcl.tk/https]

  It is examined in TWAPI and here, to find out:
     *   if this is possible
     *   what must be changed in twapi and autoproxy

  Here is the twapi ticket: [https://sourceforge.net/p/twapi/bugs/162/]


tkt_uuid: 21fef042b91ca252fc2a20ead5cd05c2b51b1776
type: Patch
status: Open
resolution: None
subsystem: math :: geometry
priority: 5 Medium
severity: Cosmetic
foundin: 8.5
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: add sind ,cosd, etc to geometry functions
cmimetype: text/plain
submitter: gold
assignee: arjenmarkus
closer: nobody
comment:
  ticket subject: proposal add sind, cosd, etc to geometry functions.
  The proposed 13 trig functions as scalar in degrees are listed below. Recognise these  trig functions (with radian measures) are convertible with your degToRad and radToDeg constants in the TCLLIB, but the usual trigonometric functions with input values as scalar or vector in degrees might be convenient to some TCLLIB users. Maybe these sind and cosd functions are already available in other TCL libraries, but not known to me (from some docs and later textbooks). As noted on the ticket entry, these proposed changes are cosmetic and do not interfere with existing user programs.

  math:geometry.
  ::math::geometry::degToRad angle 
  ::math::geometry::radToDeg angle

  math::geometry(n) 1.2.2 tcllib "Tcl Math Library"
  list of proposed 15 trig functions.
  sind(x)=Sine of argument in degrees,
   cosd(x)=Cosine of argument in degrees,
   tand(x)=Tangent of argument in degrees, 
  cotd(x)=Cotangent of argument in degrees, 
  asind(x)=returns the inverse sine (sin-1) of the elements of X in degrees,
   acosd(x)=returns the inverse cosine (cosin-1) of the elements of X in degrees,,
   atand(x)=Inverse tangent in degrees, 
  acotd(x)=Inverse cotangent in degrees, 
  secd(x)=Secant of argument in degrees,
  cscd(x)=Cosecant of argument in degrees,
  asecd(x)=Inverse secant in degrees, 
  acscd(x)=Inverse cosecant in degrees,
  atan2d(x1, x2)=Four-quadrant inverse tangent in degrees


tkt_uuid: df3676c9821ba917c5cfda68c2ea0ad7a6947ac9
type: Patch
status: Open
resolution: None
subsystem: math :: geometry
priority: 5 Medium
severity: Cosmetic
foundin: TCLLIB 1.5
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: trig angle reduction in degrees or radians
cmimetype: text/plain
submitter: gold
assignee: arjenmarkus
closer: nobody
comment:
  math::geometry(n) 1.2.2 tcllib "Tcl Math Library"
  subj: trig angle reduction in degrees or radians
  # Angle reduction in degrees or radians might be convenient to some TCLLIB users. Maybe these angle reduction functions are already available in other TCL libraries, but not known to me (from some docs and later textbooks). As noted on the ticket entry, these proposed changes are cosmetic and do not interfere with existing user programs. 

  # Code below was loaded on tcl wiki under page on Trig Procedures for degree measures as sind, cosd, tand,etc.
  I'll "fish" for some improvements.
      # start of file
      proc degree_reduction {aa} {
      if { $aa > 0. } {
      while {$aa > 360.} {
      set aa [- $aa 360.] }
      return $aa }
      if { $aa < -360. } {
      while {$aa < -360.} {
      set aa [+ $aa 360.] }
      return $aa }}
      proc pi {} {expr acos(-1)} from AMG
      proc radian_reduction {aa} {
      set pi [pi]
      if { $aa > 0. } {
      while {$aa > [* 2. $pi ] } {
      set aa [- $aa [* 2. $pi ] ] }
      return $aa }
      if { $aa < [* -1. 2. $pi ]  } {
      while {$aa < [* -1. 2. $pi ] } {
      set aa [+ $aa [* 2. $pi ] ] }
      return $aa }}
      # end of file


tkt_uuid: 77608718b586cedd16cf13715f1e26676dc18d6d
type: RFE
status: Open
resolution: None
subsystem: ncgi
priority: 5 Medium
severity: Minor
foundin: 8.6
private_contact: fa9df9d6567a36b77ae51df414d0a133fc0faf80
title: ncgi nvlist parsing with regards to content type and http method
cmimetype: text/plain
submitter: fuball63
closer: nobody
comment:
  I would like to update the way that ncgi parses requests in relationship to the content type and the HTTP method.

  Currently, ncgi treats the "query" as the url encoded parameters or multipart form parameters on stdin depending on if the method is GET or POST, respectively.  To populate nvlist, it switches on Content-Type to determine whether to parse query as url params or form data.

  This causes issues for anyone using other HTTP methods other than GET or POST, as well as other content types.  The current implementation errors out on "unknown content types", including text/plain.

  It also makes it difficult to POST data in different formats, like JSON, and impossible to parse both url encoded parameters and form data at the same time.

  I am willing to do the work, I just want to see what everyone things before investing time into this.

  I have two suggestions for how to improve ncgi:
  1) encapsulate the url parameter parsing code in ::ncgi::parse into its own function, allowing the developer to skip calling ::ncgi::parse and instead call ::ncgi::parseUrlParams and ::ncgi::multipart separately, as needed.
  2) reorganize ncgi so that query only refers to URL encoded parameters, make ncgi more flexible to other content types and HTTP methods, and split $values into $queryValues and $formValues, with nvlist being a merger or the two.

  The advantages to option 1 are that it is easy and backwards compatible.  The advantages to 2 are that it is, in my opinion at least, the more correct and complete way to approach the problem.


tkt_uuid: d94018f4763cde00c8e8976da8a4cf86d8509de4
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: Development Tools
priority: 3 Low
severity: Minor
foundin: Tcl 8.6.7
private_contact: a3cbfdb98acf5ab533a2e1324bab5c113eeb5754
title: Tcl_ObjPrintf() - 'Unable to format "%p" with supplied arguments: '
cmimetype: text/plain
submitter: zakhmak
closer: aku
closedate: 2458141.44894851
comment:
  Hello,
  I am working to wrap by myself some C functions to Tcl commands. I use for this purpose handles as command as suggested on wiki.tcl.tk/1089 
  - First part of the handle string is a short text telling the kind of struct tranfered as ClientData.
  - Second part consists in the pointer value concerning the ClientData struct so that I can also retrieve the pointer of other structs and not only the one of the current called command.

  I just discover the Tcl_ObjPrintf() function and I tried to used it for this prupose but the format specifier %p seems not to be supported. I get following message returned: 

  'Unable to format "%p" with supplied arguments: '

  I check my pointer before calling ObjPrintf("%p",ptr) and it's valid.
  Since the function name is related to printf() that supports "%p" format specifier, it looks like a bug for me. 
  Could anyone maybe explain me wether I am right or wrong and why concerning that point?

  Thanks in advance for any reply and regards


tkt_uuid: 9a21637273b81d3b245d8e3cc38759b1062ac738
type: Bug
status: Open
resolution: None
subsystem: nettool
priority: 5 Medium
severity: Severe
foundin: 1.18
private_contact: 07bcf89c4057d2d0e00473ab972eef3274af2d93
title: nettool cannot parse the ifconfig output
cmimetype: text/plain
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  Appears that the ifconfig output has been changed (a while ago) and nettool::dump cannot parse it anymore.

  An example of an old version:
  lo        Link encap:Local Loopback  
            inet addr:127.0.0.1  Mask:255.0.0.0
            inet6 addr: ::1/128 Scope:Host
            UP LOOPBACK RUNNING  MTU:65536  Metric:1
            RX packets:11582962 errors:0 dropped:0 overruns:0 frame:0
            TX packets:11582962 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000 
            RX bytes:208725263600 (194.3 GiB)  TX bytes:208725263600 (194.3 GiB)

  And a new one:
  lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
          inet 127.0.0.1  netmask 255.0.0.0
          inet6 ::1  prefixlen 128  scopeid 0x10<host>
          loop  txqueuelen 1000  (Local Loopback)
          RX packets 11577619  bytes 208724261162 (194.3 GiB)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 11577619  bytes 208724261162 (194.3 GiB)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  Also, it should be mentioned that (at least for Debian) there's an idea to drop
  net-tools (from which ifconfig and arp are) eventually.

  So I would suggest to replace ifconfig by 'ip address show' and arp by simply parsing /proc/net/arp. I don't know what happens on Macosx, so I came with a patch for Linux only.


tkt_uuid: 2adff5ca44c8fab64d736d279e76a13fdf0b6409
type: Bug
status: Closed
resolution: Fixed
subsystem: irc
priority: 5 Medium
severity: Minor
foundin: tcllib-1-19-rc
private_contact: cd4f1973f31f720f1029be69fa16f46c8f4b7cd6
title: bug in file irc.tcl
cmimetype: text/plain
submitter: minduser00
closer: aku
closedate: 2458158.74416059
comment:
  Bug still present in file irc.tcl
  Commit [41e67fa77f] solves the ticket [104f9c91a5] but the ticket [78f27a417f] is not a duplicate, is for another bug of the same tipe in the proc cmd-config line 166

     159          proc cmd-config { args } {
     160              variable config
     161  	    variable logger
     162  	    
     163  	    if { [llength $args] == 0 } {
     164  		return [array get config]
     165  	    } elseif { [llength $args] == 1 } {
     166  		return $config($key)
     167  	    } elseif { [llength $args] > 2 } {
     168  		error "wrong # args: should be \"config key ?val?\""
     169  	    }
     170  	    set key [lindex $args 0]
     171  	    set value [lindex $args 1]
     172              if { $key == "debug" } {
     173                  if {$value} {
     174                      if { !$config(logger) } { cmd-config logger 1 }
     175                      ${logger}::enable debug
     176                  } elseif { [info exists logger] } {
     177                      ${logger}::disable debug
     178  	        }
     179              }
     180              if { $key == "logger" } {
     181                  if { $value && !$config(logger)} {
     182                      package require logger
     183                      set logger [logger::init [namespace tail [namespace current]]]
     184                  } elseif { [info exists logger] } {
     185                      ${logger}::delete
     186                      unset logger
     187  	        }
     188              }
     189              set config($key) $value
     190          }

  Sorry I didn't upload both bugs in one ticket, but the second one I found after uploading the first one.


tkt_uuid: d6c9cfbaf9d9283dd181137c24a1ae1174f79015
type: Bug
status: Closed
resolution: Accepted
subsystem: ldap
priority: 5 Medium
severity: Minor
foundin: 8.4.14 or 8.6.7
private_contact: 9483839b88c374516aab6c85bc13ba5f4f360aa6
title: LDIF or LDAPx parser is not working properly: it removes the desired spaces of a ldif file format
cmimetype: text/plain
submitter: usmankhalid
assignee: aku
closer: aku
closedate: 2458160.45768407
comment:
  Hello
  I used tcl8.4.14 and ActiveTcl versions 8.4.14 and 8.6.7.0 cd as well.
  Where ldapx 0.2.4 version and with ActiveTcl ldapx 1.0 version available. 
   
  I face the issue that ldapx parser is removing the spaces which we ldif format provides it. The following is the
  ldif input file
  procedure
  output
  desired output


  ###################################################################################
  ## content of LDIF file

  dn: design data
  LOGICAL LIBRARIES: lib1
  PARAMETERS: 
  TOP ARCHITECTURE: structure
  TOP LIBRARY: lib
  TOP NAME: lib
  WORK LIBRARY: work

  dn: group #0
  FILES: aaaaaaa
   bbbbbbbbb
    ccccccccccc
     dddddddddddd
     
  ## Finish content of LDIF file
     
     
  ## start of tcl procedure

  package require ldapx 0.2.4      

  # create input channel
  ::ldapx::ldif create liin
  # link it to the input file
  liin channel [open "file_in.txt" r]

  ::ldapx::entry create input_file

  # each liin reads a "dn" from the input file
  # read the first one with the design data
  liin read input_file
  set output1 [input_file get {logical libraries}]
  puts stdout "this is the information contained in dn design data"
  puts stdout $output1

  #puts stdout "this is the information contained in the rest of dn"

  while {[liin read input_file] != 0} {
  set filelist [input_file get1 files]
  puts stdout [format {"%s"} $filelist]
  }

  return


  ## finished tcl procedure
  ###################################################################################   
     
  # output of provided tcl file
  aaaaaaabbbbbbbbbcccccccccccdddddddddddd


  ###################################################################################

  # expected output of provided tcl file
  aaaaaaabbbbbbbbb ccccccccccc  dddddddddddd

  ###################################################################################


tkt_uuid: c91ffaae34ae4874b4457ea190e8f4a3deb142bf
type: Bug
status: Closed
resolution: Accepted
subsystem: pt (parsetools)
priority: 8
severity: Important
foundin: 1.1.1.0
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: Improved and debug-ready NX PARAM engine [9877877dcd]
cmimetype: text/plain
submitter: ssoberni
assignee: aku
closer: aku
closedate: 2458158.73789543
comment:
  Hi Andreas!

  Pls. consider the improvements on branch pt-fixes2-ssoberni [9877877dcd] for inclusion into the mainline (maybe also the 1.19 rc?).

  Background: Working on the FFP patch, I realized that the debug mode was broken for the NX engine, because of the subtle differences between TclOO and NX when it comes to namespace contexts. I fixed this, one can now "debug on pt/rdengine" and "debug off pt/rdengine" as available for the other backends. Along the way, I also micro-improved the generated NX code so that the typical instruction methods (in non-debug mode) run ~25% faster on standard parsing loads (by managing variable imports à la TclOO in NX more selectively). 

  The pt test suite runs just fine. There are no API changes or backward compat issues, so a bump of version numbers should not be necessary.

  Thank you for your help.


tkt_uuid: 19607f927b68c8d98d385ccb2efa7bdb2f86669e
type: RFE
status: Closed
resolution: Accepted
subsystem: log
priority: 8
severity: Minor
foundin: trunk
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: add log::logsubst to optimize logging of expensive to build messages
cmimetype: text/x-fossil-wiki
submitter: oehhar
assignee: aku
closer: aku
closedate: 2458256.67848981
comment:
  It might be expensive to build a log message:

  <verbatim>
  log::log debug "XML of node $Node is '[$node asXml]'"
  </verbatim>

  An extensive xml representation is build for log purposes and thrown away if not logged.

  It is proposed to add a command logsubst, to do variable and command expansion only in the log case:

  <verbatim>
  log::logsubst debug {XML of node $Node is '[$node asXml]'}
  </verbatim>

  The substitution is done within the log command only if debug log level is set.

  Implementation starting with commit [ec9cf4bb6f] in branch [rfe-19607f927b-logeval].

  A practical usage is tclws (where the upper examples come from).
  The following commit introduces this optimisation and includes an emulator for older tcllib log packages:

  [https://core.tcl.tk/tclws/info/150950db68b9163a]


tkt_uuid: 48815669aa909c2d5ff755fd7ce66d6d381418ed
type: Bug
status: Closed
resolution: None
subsystem: snit
priority: 5 Medium
severity: Important
foundin: 2.3.2
private_contact: c006af9795e91328f4fd1d4e1c017a53a3e07a94
title: snit readonly option are not.
cmimetype: text/plain
submitter: anonymous
closer: anonymous
closedate: 2458174.24286476
comment:
  It appears that -readonly true is broken in snit.

  After construction a call to configure on a readonly option does in fact send the error message to stderr are documented "option -type can only be set at instance creation". However the option is in fact changed, more so any future calls to configure do not display the error message.


tkt_uuid: 877cddef7766f1303b932f86491208b3c790f18a
type: RFE
status: Closed
resolution: Invalid
subsystem: fileutil :: magic
priority: 5 Medium
severity: Important
foundin: 1.19
private_contact: 17ed0485017800b3787e6f9e46b58c8b86db8fcf
title: ::fileutil::magic::mimetype removed but no replacement suggested
cmimetype: text/plain
submitter: mxmanghi
assignee: pooryorick
closer: pooryorick
closedate: 2458345.09541065
comment:
  with the commit https://core.tcl.tk/tcllib/info/b0158a79513a8ffa the package ::fileutil::magic::mimetype was removed from tcllib but not explanation for the removal was given and apparently there is no recommendation for a replacement or compatibility layer


tkt_uuid: 7238d28e2550ae6f0301fe3d241ab08ac17ce0b0
type: Patch
status: Open
resolution: None
subsystem: (unused)
priority: 3 Low
severity: Minor
foundin: 1.18
private_contact: 3e93e59108acbd614d770dc9b13f93e2f11fd285
title: Handling of empty values in 'dict print' of module dicttool
cmimetype: text/html
submitter: anonymous
assignee: hypnotoad
closer: nobody
comment:
  <code>dict print</code>, of module <b>dicttool</b> inserts a <code>newline</code> and identation spaces to empty dict (key) values, when printing. Besides this being aesthetically strange, it becomes an error when the value is a string of only spaces, in which case the original value is destroyed. For example:
  <pre>
  % package req dicttool
  1.1
  % set d {a 55 b {} c "   "}
  a 55 b {} c "   "
  % dict print $d

  a 55
  b {
  }
  c {
  }

  # it should be:

  a 55
  b {}
  c {   }
  </pre>

  The following patch corrects both problems:<br>
  ------------------------
  <pre>
  --- dicttool.tcl        2018-02-02 05:38:38.000000000 +0200
  +++ dicttool1.tcl       2018-04-22 14:56:18.783045692 +0300
  @@ -71,7 +71,7 @@
         }
         ::incr indent -2
         ::append buffer \n [::string repeat " " $indent] "\}"
  -    } elseif {[string index $field end] eq ":" || ![is_dict $value]} {
  +    } elseif {[string index $field end] eq ":" || ![is_dict $value] || ![::llength $value]} {
         ::append buffer [::list $value]
       } else {
         ::incr indent 2
  </pre>
  ------------------------<br>
  dzach


tkt_uuid: d9be31a488f644839811f7addf0da80f047f1a27
type: Bug
status: Closed
resolution: Fixed
subsystem: smtp
priority: 9 Immediate
severity: Important
foundin: 1.18
private_contact: becf199537b904c008390f10887560767e96bebd
title: smtp::initialize fails with "<-- 421 4.3.2 Service not available"
cmimetype: text/plain
submitter: boegge
assignee: aku
closer: aku
closedate: 2458288.67722662
comment:
  smtp::initialize does not work correctly when using a server list and a port list in combination.

  In my opinion smtp::initialize should iterate over the server-list while using the port with the same index as server in list. (See code in line 626 in smtp.tcl)

  626 - set index 0 
  627 -  foreach server $options(-servers) { ....

  If connection init on the first port of ports fails, a connection with next server in list is tried to be opened but the index is not increased, so that connection establishment is only tried with the first port in list. 

  BUGFIX: Insert "incr index" before each continue in "iterate" loop or use two iterates combined. 

  foreach server  $options(-servers) { 
    foreach port $options(-ports) { ... } 
  }


tkt_uuid: 83d674b2dd2f15cdebb30a6e280e10ae91138f1d
type: RFE
status: Closed
resolution: Fixed
subsystem: smtp
priority: 9 Immediate
severity: Important
foundin: 1.19
private_contact: 6766e2ca0304c74c7698fe385680ee70cce7a6dd
title: Native tls outgoing mail servers (typically port 465)
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458288.67733333
comment:
  For smtp servers running native tls connection on port 465 (tipically) I had to patch smtp.tcl in this way for having smtp working fine. Follow the diff

  diff /opt/tclrad/lib/tcllib1.19/mime/smtp.tcl .
  103a104,105
  > #             -tlsimport   after a succesfull socket command, import tls on
  > #                          channel - used for native smtps negotiation
  156a159
  >             -tlsimport  {set tlsimport $value}
  424c427
  <                                 -tlspolicy $tlspolicy \
  ---
  >                                 -tlspolicy $tlspolicy -tlsimport $tlsimport \
  597a601,602
  > #             -tlsimport   after a succesfull socket command, import tls on
  > #                          channel - used for native smtps negotiation
  618a624
  >                             -tlsimport 0 \
  644a651
  >             if { $options(-tlsimport) } { tls::import $state(sd) }


tkt_uuid: 868b8ebe79b9ae93c395443a573f8813fc417806
type: RFE
status: Closed
resolution: Accepted
subsystem: json
priority: 6
severity: Cosmetic
foundin: 1.3.4
private_contact: c30cb52e03c9ca05e7acc2a409945abee8ab165a
title: documentation link json and json::write
cmimetype: text/plain
submitter: gwooledge
assignee: aku
closer: aku
closedate: 2458256.69715603
comment:
  The documentation for the json package should mention the json::write package, and the documentation for json::write should mention json.


tkt_uuid: 4ff12e3abdbad86b99ec59f604632952cd4b44ab
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil :: magic
priority: 6
severity: Critical
foundin: 2.0
private_contact: fd9290ae5f1a8509202a94b7afe132a13188e0cd
title: fileutil::magic fails to identify mimetype
cmimetype: text/plain
submitter: kevin_walzer
assignee: pooryorick
closer: pooryorick
closedate: 2458352.76976088
comment:
  package require fileutil::magic::filetype
  fileutil::magic::filetype /Users/kevin/Desktop/dndtest.rb

  Based on inspection of the source code of the module, I expected the output to be something like:

      mime text/x-ruby

  but there's no output at all.

  Checking to see if the module is correctly installed, I run this command:

      fileutil::magic::filetype /Users/kevin/Downloads/tcllib-1.19/devdoc/devguide.html

  And I get this output:

      {{HTML document text}} {text html} {}

  So, it seems to be working as designed, at least in some instances. But others, such as script and text files, return no output. This seems to be a bug to me.


tkt_uuid: 60160205fe965d617482fd65dee13031fc16a1b7
type: Bug
status: Closed
resolution: Accepted
subsystem: ldap
priority: 8
severity: Critical
foundin: 1.19
private_contact: ba69b1b3951296adee358cee3a51d0a1631f63cc
title: Broken support for LDAPS
cmimetype: text/x-fossil-wiki
submitter: pda
assignee: aku
closer: aku
closedate: 2458386.27707168
comment:
  Support for LDAPS is broken with ldap.tcl (and ldapx.tcl too).

  This ticket details a problem and suggest improvements to the ldap/ldapx modules.


  1) TLS handshake does not report an appropriate message

    I am trying to connect to our LDAPS server:

    <verbatim>Connection error: Protocol error: Error reading SEQUENCE response for handle ::ldap::ldapsock55682b6a9da0 : error : 562(long list of bytes)</verbatim>

    This message is not useful. While tracking the problem in ldap::secure_connect, I see that tls::handshake is called with async I/O enabled (fconfigure ... -blocking no). If I move this line after the while{1} loop, I get the more meaningful message:

    <verbatim>Connection error: handshake failed: certificate verify failed</verbatim>

    Conclusion 1 : TLS handshake should run on a blocking connection.


  2) ldap::secure_connect does not have appropriate parameters

    ldap::secure_connect accepts only the following TLS related parameters "verify_cert" and "sni_servername". It does not accept the "cafile", "certfile", not "keyfile" parameters (as with ldap::starttls).

    In my problem described in 1), it means that I cannot specify some TLS-related parameters.

    Conclusion 2 : ldap::secure_connect should accept "cafile", "certfile", and "keyfile" parameters.


  3) TLS parameters are not in sync with tcltls

    tls::import accepts the cadir/cipher/keyfile/password

    Conclusion 3 : ldap::secure_connect and ldap::starttls should accept these parameters too

  4) The "ldap connect" method in ldapx.tcl should accept TLS-related parameters

    Since the "connect" method of ldap objects (in ldapx) calls secure_connect, it should accept the same parameters as ldap::secure_connect.

    Conclusion 4 : add these TLS-related parameters to ldapx

  This ticket details some proposals as a basis for discussion, before trying to implement these points.


tkt_uuid: 2c0505fd9dec2192a5a420c3314d17f6a64102d3
type: Bug
status: Closed
resolution: By Design
subsystem: json :: write
priority: 5 Medium
severity: Important
foundin: Tcl 8.6.7 (json::write 1.0.3)
private_contact: 8610da473961a29788c71c582ee4af7e5955e619
title: json::write::string escaping unicode that shouldn't be escaped
cmimetype: text/plain
submitter: Jerry
assignee: aku
closer: Jerry
closedate: 2458261.84114038
comment:
  In json::write 1.0.3, we have this (comments omitted)
      
      namespace eval ::json::write {
          variable indented 1
          variable aligned  1
      
          variable quotes \
      	[list "\"" "\\\"" \\ \\\\ \b \\b \f \\f \n \\n \r \\r \t \\t \
      	     \x00 \\u0000 \x01 \\u0001 \x02 \\u0002 \x03 \\u0003 \
      	     \x04 \\u0004 \x05 \\u0005 \x06 \\u0006 \x07 \\u0007 \
      	     \x0b \\u000b \x0e \\u000e \x0f \\u000f \x10 \\u0010 \
      	     \x11 \\u0011 \x12 \\u0012 \x13 \\u0013 \x14 \\u0014 \
      	     \x15 \\u0015 \x16 \\u0016 \x17 \\u0017 \x18 \\u0018 \
      	     \x19 \\u0019 \x1a \\u001a \x1b \\u001b \x1c \\u001c \
      	     \x1d \\u001d \x1e \\u001e \x1f \\u001f \x7f \\u007f \
      	     \x80 \\u0080 \x81 \\u0081 \x82 \\u0082 \x83 \\u0083 \
      	     \x84 \\u0084 \x85 \\u0085 \x86 \\u0086 \x87 \\u0087 \
      	     \x88 \\u0088 \x89 \\u0089 \x8a \\u008a \x8b \\u008b \
      	     \x8c \\u008c \x8d \\u008d \x8e \\u008e \x8f \\u008f \
      	     \x90 \\u0090 \x91 \\u0091 \x92 \\u0092 \x93 \\u0093 \
      	     \x94 \\u0094 \x95 \\u0095 \x96 \\u0096 \x97 \\u0097 \
      	     \x98 \\u0098 \x99 \\u0099 \x9a \\u009a \x9b \\u009b \
      	     \x9c \\u009c \x9d \\u009d \x9e \\u009e \x9f \\u009f ]
      }

  I'm not 100% sure, but I believe the list should stop at \x1f, as per the specification here: https://www.rfc-editor.org/rfc/rfc7158.txt

  I stumbled on this while using ::json::write::string and getting escaped unicodes.

      % set s "\u30B8\u30A7\u30C3\u30EA"
      ジェッリ
      % set s [encoding convertto utf-8 $s]
      ã¸ã§ããª
      % ::json::write::string $s
      "ã\u0082¸ã\u0082§ã\u0083\u0083ã\u0083ª"
      # Should be "ã¸ã§ããª"

  Proposed fix: change quotes to the following:
      
      variable quotes \
        [list "\"" "\\\"" \\ \\\\ \b \\b \f \\f \n \\n \r \\r \t \\t \
         \x00 \\u0000 \x01 \\u0001 \x02 \\u0002 \x03 \\u0003 \
         \x04 \\u0004 \x05 \\u0005 \x06 \\u0006 \x07 \\u0007 \
         \x0b \\u000b \x0e \\u000e \x0f \\u000f \x10 \\u0010 \
         \x11 \\u0011 \x12 \\u0012 \x13 \\u0013 \x14 \\u0014 \
         \x15 \\u0015 \x16 \\u0016 \x17 \\u0017 \x18 \\u0018 \
         \x19 \\u0019 \x1a \\u001a \x1b \\u001b \x1c \\u001c \
         \x1d \\u001d \x1e \\u001e \x1f \\u001f ]


tkt_uuid: e4d5ef01e7a5db5e6d3c460ec4165edfacd1b1bb
type: Bug
status: Closed
resolution: Accepted
subsystem: logger
priority: 5 Medium
severity: Important
foundin: 8.6
private_contact: 5ab10c00dc00035bab3d73098ece8f9a46448408
title: TclOO: class logger mixin
cmimetype: text/plain
submitter: random-archer
assignee: aku
closer: aku
closedate: 2458659.3154886
comment:
  A bug confirmed by Donal Fellows:
  [https://stackoverflow.com/questions/50352363/tcloo-class-logger-mixin]

  -----
  Here is an extract of the upper communication:

  Andrej:

  Logger included with tcllib 1.19 breaks when used as class logger:

  #!/usr/bin/env tclsh
  package require logger
  package require logger::utils
  ::oo::class create Main {
      variable log
      constructor {} {
          set this_inst [namespace current]
          set this_klaz [info object class $this_inst]
          set log [::logger::init $this_klaz]
          ::logger::utils::applyAppender \
          -appender "console" \
          -appenderArgs {-conversionPattern {%d \[%p\] \[%M\] %m}} \
          -serviceCmd $log
      }
      method invoke {} {
          ${log}::info "hello"
      }
  }
  set main [Main new]
  $main invoke

  Producing object namespace:

  2018/05/15 08:54:43 [info] [::oo::Obj12] hello

  Instead of class/method namespace:

  2018/05/15 08:54:43 [info] [::Main::invoke] hello

  Donal:

  This is a bug in ::logger::utils::createLogProc in loggerUtils.tcl in that the %M substitution is not aware of TclOO. If it was, it wouldn't be using the name of the object that the method was invoked on, but rather the name of the method. (It appears that it was designed to work with [incr Tcl], which does name methods like you appear to want.)

  ...

  That's actually because it looks up the value for %M substitution like this:

      if {[info level] < 2} {
          set method "global"
      } else {
          set method [lindex [info level -1] 0]
      }

  whereas it probably ought to do something more like this:

      if {[info level] < 2} {
          set method "global"
      } elseif {[uplevel 1 {namespace which self}] == "::oo::Helpers::self"} {
          set method [uplevel 1 {string cat [self class] "::" [self method]}]
      } else {
          set method [lindex [info level -1] 0]
      }


tkt_uuid: c27da654f82e3fdf174dd0d3691eeeb21298b009
type: Bug
status: Open
resolution: None
subsystem: websocket
priority: 5 Medium
severity: Minor
foundin: websocket 1.4.1
title: websocket 1.4.1 closed sockets Ping
cmimetype: text/plain
submitter: anonymous
assignee: emmanuel
closer: nobody
comment:
  In websocket 1.4.1 closed sockets Ping

  ::websocket::find not list this socket before

  ::websocket::loglevel warn
  [Fri May 25 23:13:47 CEST 2018] [websocket] [warn] 'sock04D1C6D0 is not a WebSocket connection anymore'

  ::websocket::loglevel debug
  Exeption:
  sock0690E110 is not a WebSocket
      while executing
  "::websocket::Ping sock0690E110"
      ("after" script)


tkt_uuid: 21e22313d84775014fe304df5a436e02a8ae05d0
type: Patch
status: Open
resolution: None
subsystem: websocket
priority: 6
severity: Minor
foundin: 1.4.1
private_contact: 704d6f14369c3fc8af56665bbc2df55351e2caf0
title: Gracefully handle server side websocket close in TCL console
cmimetype: text/plain
submitter: aparvu
assignee: emmanuel
closer: nobody
comment:
  1. Connect to a websocket server using TCL console. 
  2. Close the server without closing the websocket.

  Results:
  can't read "Connection(liveness)": no such variable
  can't read "Connection(liveness)": no such variable
      while executing
  "if { $Connection(liveness) ne "" } {
                  after cancel $Connection(liveness)
      }"
      (procedure "Disconnect" line 7)
      invoked from within
  "Disconnect $sock"
      (procedure "close" line 34)
      invoked from within
  "close $sock 1001"
      (procedure "::websocket::Receiver" line 23)
      invoked from within
  "::websocket::Receiver sock896"

  There are many cases in which applications are being forcefully closed and TCL raises this. The fix handles this exception.


tkt_uuid: 5b8e3a9e9bb8a12fe4d0b2755086c1c241390bcf
type: Bug
status: Open
resolution: None
subsystem: markdown
priority: 5 Medium
severity: Minor
foundin: 1.19
private_contact: 3ba4de09451f1f5bca00b37535ac0785027835e3
cmimetype: text/plain
submitter: LawrenceWoodman
assignee: hypnotoad
closer: nobody
title:
  In package Markdown when a header markup is used (#, ##, ###, ####) it encloses the next line in the html header output unless their is a blank line below it.

comment:
  In package Markdown when a header markup is used (#, ##, ###, ####) it encloses the next line in the html header output unless their is a blank line below it.  The following code demonstrates this:

  package require Markdown

  set cases {
    {in {
  # This is a title
  this isn't
     }
  want {<h1>This is a title</h1>
  <p>this isn't</p>}
    }
    {in {
  ## This is a title
  this isn't
     }
  want {<h2>This is a title</h2>
  <p>this isn't</p>}
    }
    {in {
  ### This is a title
  this isn't
     }
  want {<h3>This is a title</h3>
  <p>this isn't</p>}
    }
    {in {
  #### This is a title
  this isn't
     }
  want {<h4>This is a title</h4>
  <p>this isn't</p>}
    }
    {in {
  # This is a title

  this definitely isn't
     }
  want {<h1>This is a title</h1>

  <p>this definitely isn't</p>}
    }
    {in {
  ## This is a title

  this definitely isn't
     }
  want {<h2>This is a title</h2>

  <p>this definitely isn't</p>}
    }
    {in {
  ### This is a title

  this definitely isn't
     }
  want {<h3>This is a title</h3>

  <p>this definitely isn't</p>}
    }
    {in {
  #### This is a title

  this definitely isn't
     }
  want {<h4>This is a title</h4>

  <p>this definitely isn't</p>}
    }
  }

  set caseNum 0
  foreach case $cases {
    set got [::Markdown::convert [dict get $case in]]
    if {$got ne [dict get $case want]} {
      puts stderr [format \
        "\n(%2d) Markdown::convert got: {$got}, want: {[dict get $case want]}" \
        $caseNum
      ]
    }
    incr caseNum
  }


tkt_uuid: 0d23817f75c666c912a812c6f1125b3406055f59
type: Bug
status: Open
resolution: None
subsystem: markdown
priority: 5 Medium
severity: Minor
foundin: 1.19
private_contact: 3ba4de09451f1f5bca00b37535ac0785027835e3
cmimetype: text/plain
submitter: LawrenceWoodman
assignee: hypnotoad
closer: nobody
title:
  In package Markdown when a boolean attribute is used in an embedded html element, the rest of the markdown text is ignored.

comment:
   	

  In package Markdown when a boolean attribute is used in an embedded html element, the rest of the markdown text is ignored.  The following code demonstrates:

  package require tcltest
  namespace import tcltest::*
  package require Markdown

  test booleanattribute {embedded html using a boolean attribute} -body {
    Markdown::convert {
  hello

  <div allowfullscreen></div>

  hello again
    }
  } -result {<p>hello</p>

  <div allowfullscreen></div>

  <p>hello again</p>}


tkt_uuid: 20b144d233864c03984a61262334ebd0fd988ffd
type: Bug
status: Closed
resolution: Fixed
subsystem: oauth
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Skip oauth tests if tls not available.
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458281.66555819
comment:
  Skip test if tls not available.

  Index: modules/oauth/oauth.test
  --- modules/oauth/oauth.test.orig
  +++ modules/oauth/oauth.test
  @@ -7,6 +7,7 @@ source [file join \
   
   testsNeedTcl     8.5
   testsNeedTcltest 2
  +testsNeed tls
   
   testing {
       useLocal oauth.tcl oauth


tkt_uuid: e334de21177152f5df419393dbde7d4aeb447885
type: Bug
status: Closed
resolution: Fixed
subsystem: Build System & Testing
priority: 9 Immediate
severity: Severe
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
comment: Summary says it all.
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458289.34829387
title:
  "sak  provided" needs to ignore all the build.tcl's or else they will create ridiculous files in strange places.


tkt_uuid: 351b8b2f55519f12d5c4f889b68ecee7db97118a
type: Bug
status: Closed
resolution: Fixed
subsystem: pt (parsetools)
priority: 5 Medium
severity: Severe
foundin: trunk
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: Bug fixes on PT/PEG transformation operations
cmimetype: text/plain
submitter: ssoberni
assignee: aku
closer: aku
closedate: 2458309.39581123
comment:
  Hi!

  As promised, I reworked a series of bug fixes on PEG transformations (realizability, dropping) into a fix branch: [https://core.tcl.tk/tcllib/timeline?r=pt-container-ssoberni].

  In short:

  1. minimize: the drop operations were in wrong order.

  2. realizability: kleene star and optionals should be set realizable by definition (is consistent with other PEG environments, incl. tcllib's page).

  3. Drop: 

  o wrong variable name in one, previously untested code branch.

  o drop was too permissive on expressions other than choice. In line with the realizability ruling, only choice should survive any removed children.

  Generally, offering the otherwise CFG-aware grammar transformations should maybe prominently be marked with a disclaimer in the docs? This is because treating a PEG as a CFG is not necessarily a good idea, although limited use of transformations is warranted. A disclaimer should state that realizability of an ordered choice cannot be decided statically and is conceptually itchy (non-disjointness). Also, realizability of predicates is certainly debatable (in the sense of a non-productive or a non-recognising expression). In any case, the message should be that the result of a minimisation will not yield a minimal PEG, rather a conservative approximation of a minimisation, at best.

  What do you think?

  Final observation, but also debatable: ::pt::peg::op::drop::unrealizable starts from the set of defined non-terminals (RHS of rules), and not all reachable ones. This is not an issue per se, but if one composes PEGs or the corresponding rules (e.g., with deferred non-terminals) then they will be just dropped, along with most of the rest of the rules set. A more permissive, conservative setting would switching from

     set all [$container nonterminals]

  to

     set all [::pt::peg::op reachable $container]

  Let me know what you think!

  Thx,
  Stefan


tkt_uuid: 3fe6b991f4633212e804932a79505528f6269996
type: Bug
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 9 Immediate
severity: Critical
foundin: tcllib-1.19
private_contact: 64decdc33135afd1d3b726d421049bde38a15c66
title: ::math::numtheory::primeFactor doesn't work properly
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458309.3050014
comment:
  I get the following error when trying to factor certain numbers:
  ::math::numtheory::primeFactors 964
  Error: can't use empty string as operand of "%"

  964 should be:
  2 2 241

  It appears that there is an issue when one of the primefactors is "large", like 241. 

  For example 960 works just fine:
  ::math::numtheory::primeFactors 960
  2 2 2 2 2 2 3 5

  but not 914
  ::math::numtheory::primeFactors 914
  Error: can't use empty string as operand of "%"

  thanks
  david


tkt_uuid: 4aeded587b48cd96183e14c97607c5ab3913364a
type: Bug
status: Pending
resolution: None
subsystem: asn
priority: 5 Medium
severity: Minor
private_contact: 87096969a040aee4fe31597ca329d71cdfaddb3d
title: https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/asn/asn.html
cmimetype: text/x-fossil-wiki
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458309.21347556
comment:
  The Example section references the Examples of the ldap package as an example.  However the current version of the ldap package has no use of the asn package within the Example set.

  See references:

  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/asn/asn.html
  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/ldap/ldap.html


tkt_uuid: 3c17835a2da341ad99c5e70007615f281f250534
type: Patch
status: Closed
resolution: Accepted
subsystem: math :: special
priority: 5 Medium
severity: Cosmetic
foundin: 8.6
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: find interval of Legendre and 2 other estimated primes from two entries
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2458598.29343348
comment:
  possibly, difference over interval using NumberPrimesLegendreModified (related previous ticket cd42b3ddf8,2017-05-28 )
  would be useful to some. two numbers entered, limit1 and limit2 and difference returned. both limits must be greater than one. find interval of est. primes from two entries on positive number line. Inclusive, interval differences for numberPrimesGauss, numberPrimesLegendre, NumberPrimesLegendreModified might be useful.
  ## 
  ### differenceNumberPrimesLegendreModified --
  #     Return the approximate difference number of primes 
  #     between a lower and higher limit as given values
  #     for approximate number of primes based on the
  #     modified formula by Legendre
  #
  # Arguments:
  #     limit1     The lower limit for the interval, largest prime to be included in the l.limit
  #     limit2     The upper limit for the interval, largest prime to be included in the u.mlimit
  #
  # Returns:
  #     Approximate difference number of primes
  #
  proc ::math::numtheory::differenceNumberPrimesLegendreModified {limit1 limit2} {
      if { $limit1 <= 1 } {
          return -code error "The lower limit must be larger than 1"
      }
      if { $limit2 <= 1 } {
          return -code error "The upper limit must be larger than 1"
      }

       set aa [::math::numtheory::numberPrimesLegendreModified [expr ($limit1)]]   
       set bb [::math::numtheory::numberPrimesLegendreModified [expr ($limit2)]] 
       expr ( $bb-$aa)
  }
  ####### 
  statements invoking difference
   puts " [ ::math::numtheory::differenceNumberPrimesLegendreModified 100  200  ] "
           #puts " [ ::math::numtheory::differenceNumberPrimesLegendreModified 100  0  ] " invokes error.


tkt_uuid: a16b1095974e071d294ccbc0cf4671148bddab76
type: Bug
status: Closed
resolution: Fixed
subsystem: mime
priority: 5 Medium
severity: Minor
foundin: 1.19
title: Error in mime.tcl
cmimetype: text/plain
submitter: plumsli
closer: pooryorick
closedate: 2458345.32033126
comment:
  There is an error on line 674 in mime.tcl:
  if {(!$blankP) && ([string last \r $line] == {$x - 1})} {

  should be

  if {(!$blankP) && ([string last \r $line] == [expr {$x - 1}])} {


tkt_uuid: 0a030f850d4e3fc05da98aa954a6ec1b16e655d9
type: Bug
status: Closed
resolution: Fixed
subsystem: math
priority: 5 Medium
severity: Severe
title: math::stat mean value round off
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2458592.28705954
comment:
  When using the math::stats function the mean value is calculated as integer instead of double. In the function the typecast to double is missing when calculating the mean value.


tkt_uuid: 30526e902772c23159e2fd166323bd2cc101b939
type: Bug
status: Closed
resolution: Fixed
subsystem: math
priority: 5 Medium
severity: Severe
foundin: trunk
private_contact: d4d1d8192a46acf2c7d58cddc1040ecdbc9c9d77
title: math::exact: ifneeded/provide version mismatch
cmimetype: text/plain
submitter: ssoberni
assignee: aku
closer: aku
closedate: 2458589.47246854
comment:
  There is a mismatch between the version number provided (1.0.1) and the one required (1.0) which yields a:

      attempt to provide package math::exact 1.0 failed: package math::exact 1.0.1 provided instead

  Fix is to patch the ifneeded script in modules/math/pkgIndex.tcl to show 

  package ifneeded math::exact             1.0.1   [list source [file join $dir exact.tcl]]

  instead of

  package ifneeded math::exact             1.0   [list source [file join $dir exact.tcl]]


tkt_uuid: e6b26853885c35d26243793e917107fa6f47206d
type: Patch
status: Open
resolution: None
subsystem: math :: statistics
priority: 5 Medium
severity: Cosmetic
foundin: 8.6
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: proportional weighted shares
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: nobody
comment:
  ::math::stats::proportional_weighted_shares --
          #
          # Return the proportional_weighted_shares from quantity by two or more given ratios
          #
          # Arguments:
          #    quantity   first value is quantity
          #    args       second, third,  and sucessive values
          #               are two or more given ratios (usually integers in high school)
          #               However, decimal fractions for both quantity and args seem
          #               to be reasonably accurate to TCL precison.     
          # Conditions and answer checks
          #       The quantity must be larger than 0
          #       The number of args must be larger than 2
          #       If sum of parts equals zero, formula is undefined
          #       Number of parts should be equal to [ llength $args ] 
          #       Total value of parts should be equal to quantity entry
          #       The solution may not be unique in that more than one
          #       set of shares may have or generate the same multiple ratios. 
          # Results: parts of quantity into proportional weighted shares


tkt_uuid: fdf6afed946042195041780a5b6d30b88de12315
type: Bug
status: Closed
resolution: Fixed
subsystem: A Category Is Missing
priority: 5 Medium
severity: Critical
foundin: 1.19
private_contact: af9c70d5700d5af288b87a3a9ed94e1300911d18
title: cache::async error when calling the clear method - Attached BugFix
cmimetype: text/plain
submitter: anonymous
assignee: akupries
closer: aku
closedate: 2458536.48142972
comment:
  cache::async 0.3 has a critical bug.
  By running the following code

  -----------------------------
  package require cache::async

  proc myDataFetcher args {  }

  cache::async myDataProvider myDataFetcher
  myDataProvider clear KEY
  --------------------------------------------

  .. an error is raised
    
  errorInfo: can't read "arg": no such variable
      while executing
  "llength $arg"
      (procedure "::cache::async::Snit_methodclear" line 18)
      invoked from within
  "myDataProvider clear KEY"


  Fixing the bug only requires to correct "arg" in "args".

  I included a zip with all the updated files
  - async.tcl     --  the main correction, and version changed to 0.3.1
  - pkgIndex.tcl  --  version changed from 0.3 to 0.3.1
  - async.test    --  added 2 testcases

  ABU


tkt_uuid: 67b7bafb20656b607f2d861e334c82567518a0bb
type: Patch
status: Open
resolution: None
subsystem: math :: statistics
priority: 5 Medium
severity: Cosmetic
foundin: 8.6
private_contact: 6a35629ae8c91b8189de05be9d12871d9ac9f8f9
title: ::math::combined_market_rate
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: nobody
comment:
          # adapted from tcl Stats 2011-05-22, arithmetic mean  [RLE]
          # gold on TCL/WIKI
          # ::math::combined_market_rate --
          #
          # Return the combined_market_rate by  one,two, or more given rates
          # market rate defined as quantity per price
          # or 1 over (price per quantity)
          # 
          # Arguments:
          #    
          #    args  values are one, two, or more given rates
          #
          # Results: combined_market_rate
          #  works for positive numbers, negative numbers,
          #  and mixed positive & negative numbers.
          #  arg of zero returns zero  
          #  arg of null returns zero  
          proc ::math::combined_market_rate { args} {
              set sum 0.
              set N [ expr { [ llength $args ] } ]
              if { $N == 0 } { return 0 }
              if { $N == 1 || [ lindex $args 0 ] == 0 } { return 0 }
              foreach val $args {
                set sum [ expr { $sum + 1./$val } ] 
              }
              set combined_market_rate1 [ expr { 1./($sum/$N) } ]
              return $combined_market_rate1
          }
          console
          # puts  " [ ::math::combined_market_rate  0.5524 0.4807 0.42918 0.47846 ] answer 0.40131"
          # various testcases and operator math formula below
          #puts  [::math::combined_market_rate  0.5524 0.4807 0.42918 0.47846 ] 
          #  answer 0.48131    "
          #puts   [ ::math::combined_market_rate .1 .2 .3 .4 ]     
          #  answer 0.192 
          #::math::combined_market_rate -.1 -.2 -.3 -.4  #answer -0.192
          # check [/ 1. [/ [+ [/ 1. -.1] [/ 1. -.2] [/ 1. -0.3 ] [/ 1. -0.4] ] 4. ] ]
          #returns  -0.192 
          #puts " [ ::math::combined_market_rate .1 ] "
          #:math::combined_market_rate -.1 -.2  .3 .4 #answer -0.4363636363636364
          #set check [/ 1. [/ [+ [/ 1. -.1] [/ 1. -.2] [/ 1.  0.3 ] [/ 1. 0.4] ] 4. ] ] 
          # check equals    -0.4363636363636364 
          #puts " for (::math::combined_market_rates .1) returns .1 "  
          # ::math::combined_market_rate      # null returns zero, correct.
          # ::math::combined_market_rate 0    # arg 0 returns zero, correct.


tkt_uuid: 59c60db96169e20200d920443be8663d40863bc5
type: Bug
status: Open
resolution: None
subsystem: cmdline
priority: 5 Medium
severity: Important
foundin: 1.19
private_contact: 5f7cb94f1e409473afb8467bfa844a9e9e1280eb
title: cmdline - not work correctly when options without dash prefix appear before options with dash
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  In GNU C library, the getopt() or getopt_long() function modifies the order of argv to move all operands(options without dash prefix) to the end of argv.

  So, for example,
  "cp fileA fileB -p"
  works well same as
  "cp -p fileA fileB".
  In cmdline package, this did not work.

  By the way, GNU getopt() did not modify the contents of argv except for the order of elements.
  It provides a variable "optind" as index pointing to the first operand in argv.


tkt_uuid: 3fff267fc4318b7a8bd2417f74f68d33a8788d89
type: Patch
status: Open
resolution: None
subsystem: ftp
priority: 5 Medium
severity: Minor
foundin: 1.19
private_contact: 6f3c446bb319826d555c0d5a0856665563ff8137
title: ftp with explicit tls
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  For connection on server ftp with explicit tls. I had to patch ftp.tcl in this way to allow the protocol to work fine.


tkt_uuid: 94e3466513bf9d9b1ea2a039c9d68ef035c2697b
type: Bug
status: Closed
resolution: Fixed
subsystem: struct
priority: 5 Medium
severity: Severe
foundin: 1.0
private_contact: dea4309228893694b36e1b3e9764a3c9178bbe7f
title: Bad performance of struct::disjointset
cmimetype: text/x-fossil-wiki
submitter: kbk
assignee: aku
closer: aku
closedate: 2458544.71259645
comment:
  struct::disjointset is coded in such a way that some of its operations appear to take quadratic time - leading to cubic time for N of them!

  If it's done right, with the Galler-Fischer algorithms, the quadratic-time operations in struct::disjointset diminish to amortized time of O(alpha(N)) where N is the inverse Ackermann function. (alpha(N) is less than 5 when N is the estimated number of fundamental particles in the physical universe, so this is effectively constant time.)

  Refactoring at [ccd844fad4]. Refactored code advances the Tcl requirement from 8.2 to 8.6. Three new methods are added, 'add-element', 'exemplars' and 'find-exemplar'.  Docs and test suite are updated accordingly. Version number advances from 1.0 to 1.1.

  This is pretty much a complete rewrite, but with API compatibility verified with the test suite. 

  There's no longer a Critcl dependency in this module, since it's not using
  struct::set internally any more.


tkt_uuid: 7dfe60d7f49d042943bd9ae7a675e64eb14c94b6
type: Bug
status: Closed
resolution: None
subsystem: Development Tools
priority: 7 High
severity: Severe
foundin: post commit 97e9f3adf5
private_contact: 194c9ef8edbd9a57ef36f4f18fde1d57ce26e1e5
title: testsuite improvement breaks testing against 8.4
cmimetype: text/x-fossil-wiki
submitter: aku
assignee: pooryorick
closer: pooryorick
closedate: 2458457.78020911
comment:
  Commit [97e9f3adf59badd1] has introduced the use of a Tcl 8.5 feature into
  the "testutilities.tcl" file used by __all__ .test files.

  Testing against any 8.4 will thus now break for all .test files which declare that they need a Tcl < 8.5.

  <pre>
  [    ]  [8.4.20] asn                   ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] base32                ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] base64                ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] bee                   ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] bench                 ~~ None  T     0 P     0 S     0 F     0
  [    ]  [8.4.20] bibtex                ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] blowfish              ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] cache                 ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] calendar              ~~ ERR   T     0 P     0 S     0 F     0
  [    ]  [8.4.20] chan                  ~~ Skip  T     0 P     0 S     0 F     0
  [    ]  [8.4.20] clay                  ~~ Skip  T     0 P     0 S     0 F     0
  </pre>

  I ask that you go through all .test files and fix those with "testsNeedTcl 8.4" (8.3, 8.2) to properly declare "testsNeedTcl 8.5". That way running the tests against a Tcl 8.4 will not error, but properly Skip.


tkt_uuid: 333ccac763a25b85c68b0a0ad6864fa51db74fc6
type: Bug
status: Open
resolution: None
subsystem: huddle
priority: 5 Medium
severity: Important
foundin: huddle 0.2+
private_contact: 3f94056072f59a63c4e6358904dba8bca34bf817
title: huddle wrap no longer accepts 2 arguments
cmimetype: text/plain
submitter: ethanp
closer: nobody
comment:
  Starting in huddle v0.2 the "huddle wrap" command was changed to only accept one argument instead of the two it required in v0.1.  Since huddle 0.2 was noted as a bug-fix this lack of backwards compatibility was not expected.

  The current docs still show the two argument form so either the docs need to be updated or the code should be updated to support two arguments.  

  Here is a fix that supports both forms: 
  proc ::huddle::wrap { args } {
      set num [llength $args]
      if { $num == 1 } {
        return [list HUDDLE [lindex $args 0]]
      } elseif { $num == 2 } { 
        return [list HUDDLE $args]
      } else {
        error "huddle wrap expects 1 or 2 arguments"
      }
  }


tkt_uuid: 7554bfed3026899ebb68bd400bc31548d6a4d5f2
type: Bug
status: Open
resolution: None
subsystem: dns
priority: 5 Medium
severity: Minor
title: IPv6 nameservers are not supported in UDP mode
cmimetype: text/plain
submitter: rkeene
assignee: akupries
closer: nobody
comment:
  When the UDP socket is created by "udp_open" it needs to have the "ipv6" flag
  specified if it is going to be used for talking to IPv6 addresses.

  Without that flag IPv6 nameservers in /etc/resolv.conf cannot be reached over
  UDP.


tkt_uuid: c08d4bbe4f9b56e21bfa270147cd31ceabef0034
type: RFE
status: Closed
resolution: By Design
subsystem: textutil
priority: 5 Medium
severity: Minor
foundin: 1.20
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Add a pure-tcl tool for diff
cmimetype: text/x-fossil-wiki
submitter: hypnotoad
closer: hypnotoad
closedate: 2458463.41341924
comment:
  I would like to adapt Kevin Kenny's existing diff algorithm from the wiki (<a href="https://wiki.tcl-lang.org/page/diff+in+Tcl">https://wiki.tcl-lang.org/page/diff+in+Tcl</a>) to operate as a module (or modules) in Tcllib. My thinking is to place the longestCommonSubsequence proc inside a new source file in textutil, and provide a wrapper inside of fileutil to perform that comparison in bulk on files or streams.

  Work will go into a branch called "kbk-diffutil"


tkt_uuid: 8c91e46800f569566ac60c7ded7c321b52f67a15
type: Bug
status: Open
resolution: Not Applicable Here
subsystem: (unused)
priority: 5 Medium
severity: Critical
foundin: 2.4.1
private_contact: cbcc432f27f5968bf9e719dec72bbe039eb1aa2d
title: Error when bindplot on createLogXYPlot
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: nobody
comment:
  When I bind to the plot created by createLogXYPlot using bindplot, I get an error.
  Same happens when I use bindlast instead.
  Same will happen for all other XY plot types except createXYPlot itself.

  I corrected the bug only for bindplot and only for createLogXYPlot but all other types should be corrected too.

  I modified the files:
  plotbind.tcl
  plotchart.tcl

  Here are the unified diffs:





   lib_x64/plotchart/plotbind.tcl | 4 ++++
   1 file changed, 4 insertions(+)

  diff --git a/lib_x64/plotchart/plotbind.tcl b/lib_x64/plotchart/plotbind.tcl
  index f06e71a..d6310f8 100644
  --- a/lib_x64/plotchart/plotbind.tcl
  +++ b/lib_x64/plotchart/plotbind.tcl
  @@ -20,6 +20,10 @@
   proc ::Plotchart::BindPlot {w event cmd} {
       variable scaling
   
  +    if {![info exists scaling($w,eventobj)]} {
  +        set scaling($w,eventobj) ""
  +    }
  +
       if { $scaling($w,eventobj) == "" } {
   
           set pxmin $scaling($w,pxmin)






   lib_x64/plotchart/plotchart.tcl | 3 +++
   1 file changed, 3 insertions(+)

  diff --git a/lib_x64/plotchart/plotchart.tcl b/lib_x64/plotchart/plotchart.tcl
  index c9d3c25..4e3cea9 100644
  --- a/lib_x64/plotchart/plotchart.tcl
  +++ b/lib_x64/plotchart/plotchart.tcl
  @@ -164,6 +164,9 @@ namespace eval ::Plotchart {
      set methodProc(logxyplot,plaintextconfig)   ConfigPlainText
      set methodProc(logxyplot,canvas)         GetCanvas
      set methodProc(logxyplot,deletedata)     DeleteData
  +
  +   set methodProc(logxyplot,bindplot)       BindPlot
  +
      set methodProc(logxlogyplot,title)          DrawTitle
      set methodProc(logxlogyplot,subtitle)       DrawSubtitle
      set methodProc(logxlogyplot,xtext)          DrawXtext


tkt_uuid: 57909d2e1c28546ff83a61f5bcbafd1215231445
type: Bug
status: Closed
resolution: Fixed
subsystem: mime
priority: 7 High
severity: Severe
foundin: 1.6
private_contact: 21e680c66afc6863cbbaf0aa5b26c9e8a4429339
title: Error opening MIMEs with CRLF line ends in Linux
cmimetype: text/plain
submitter: jal_frezie
assignee: aku
closer: aku
closedate: 2458586.4172725
comment:
  Error produced trying to initialize a MIME with CRLF (DOS style) line ends in Linux version. Windows version opens it OK.
  % package require mime 
  1.6
  % ::mime::initialize -file {Angela Budget Model v2.2.sml}
  improper line in header: 
  % set errorInfo
  improper line in header: 
      while executing
  "error "improper line in header: $vline""
      (procedure "mime::parsepart" line 63)
      invoked from within
  "mime::parsepart $token"
      invoked from within
  "{*}[list mime::initializeaux $token {*}$args]"
      (procedure "::mime::initialize" line 11)
      invoked from within
  "::mime::initialize -file {Angela Budget Model v2.2.sml}"


tkt_uuid: 48fe95c519ba9cbd3c443223c4311c1df7700f0e
type: RFE
status: Closed
resolution: Accepted
subsystem: png
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
title: Add function "getPixelDimension" to get physical pixel dimensions
cmimetype: text/x-fossil-wiki
submitter: oehhar
assignee: aku
closer: aku
closedate: 2458544.69904644
comment:
  A png file may contain the physical pixel size in a pHYs segment:

  [http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html]

  This info may be extracted by the new function "getPixelDimension" of the following branch: png-get-physical-dimension


tkt_uuid: 5edaf187fa3e13d9327cb0ff9c168be12174c2e0
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: graph
priority: 5 Medium
severity: Important
foundin: struct::graph 2.4
private_contact: 666fe0987de7db63f412a8510f29b7357c92320e
title: struct::graph is inconsistent about the support of nodes starting with a dash
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458586.65145049
comment:
  graph node insert -foo ;# works
  g walk -foo -command {apply {args {puts stderr [info level 0]}}} ;# results in

  apply {args {puts stderr [info level 0]}} enter ::g -foo
  bad restriction "-foo": must be -adj, -embedding, -filter, -in, -inner, -key, -out, or -value
  while evaluating {g walk -foo -command {apply {args {puts stderr [info level 0]}}}}

  Note how apply is invoked, i.e. [walk] is not directly affected, but one of the internals that it calls.

  I know that fixing this will be quite some work, but it is an actual restriction: e.g. the package does not work for negative numbers as node names


tkt_uuid: f61f2e83a30d152d123474d9529f83e06c2bda9e
type: Bug
status: Closed
resolution: Fixed
subsystem: Documentation
priority: 5 Medium
severity: Important
private_contact: f6b536f9c1ed4b589e96e38fb613afc3d8991783
title: no instructions for building tcllibc
cmimetype: text/html
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458611.45728606
comment:
  There isn't a page (so far as I can see or find with Google) that describes how to build and install the critcl accelerators for tcllib. This is <a href="https://stackoverflow.com/q/54320534/301832">causing significant problems for some users</a> (who apparently don't have the option of installing pre-built versions due to the way their package manager works).


tkt_uuid: 4c3e532500a7ed13862bbcd57de72c2f4c7411ff
type: Bug
status: Open
resolution: None
subsystem: tool
priority: 5 Medium
severity: Severe
foundin: trunk
private_contact: 4ca203a8e925aecdd9419645f936bccf18cd6ea7
title: tool::uuid_seed may raise error
cmimetype: text/plain
submitter: pointsman
assignee: hypnotoad
closer: nobody
comment:
  Look at:

  http://core.tcl.tk/tcllib/artifact?udc=1&ln=114-116&name=066c2163260e8391

  Line 115 uses $::env(user) without checking if that exists and will raise error if it doesn't.

  If this code is evaluated on a box without USERNAME nor USER nor user in env it will raise error.

  I run into this in a docker container.

  And even more: All this lines http://core.tcl.tk/tcllib/artifact?udc=1&ln=110-116&name=066c2163260e8391 are useless. They set the variable "user", but this variable isn't used at all.


tkt_uuid: 28919a4f4e87da223c77922ddc89a63216f264c2
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: amazon-s3
priority: 5 Medium
severity: Minor
foundin: 1.19
private_contact: f5e96bd3168d173a07f11b6f7040c085db1fb97d
title: Cannot find package xml?
cmimetype: text/plain
submitter: wrenashe
assignee: aku
closer: aku
closedate: 2458544.70723984
comment:
  I am using Tcl 8.6.8/Tcllib-1.19, while got xml package missed when trying S3 package.

  tcl>package require S3
  Error: can't find package xml


tkt_uuid: b9725d990bad71033ec286dc01ac0d110c505fc3
type: Patch
status: Closed
resolution: Accepted
subsystem: zip
priority: 7 High
severity: Important
foundin: 1.19
private_contact: 7037081d48397e409dbdf3f634c65c1c892e898b
title: ::zipfile::mkzip::walk fails with directory names preceded with '-'
cmimetype: text/html
submitter: hromojaro
assignee: aku
closer: aku
closedate: 2458589.46812009
comment:
  ::zipfile::mkzip::walk fails with sub-directories which names start with '-', due to missing '--' in glob expressions.<p>

  Can be reproduced like this: 
  <pre>
  $ mkdir -- -1
  $ ls
  -1/
  $ tclsh
  % package require Tcl 8.6
  8.6.7
  % package require zipfile::mkzip
  1.2
  % ::zipfile::mkzip::mkzip my.zip -directory .
  bad option "-1/*": must be -directory, -join, -nocomplain, -path, -tails, -types, or --
  </pre>

  Please consider applying the attached patch with a fix.<p>

  Regards,<br/>
  Héctor Romojaro


tkt_uuid: 1975182bddc84f6601f60b0acf2f326eae10316f
type: Bug
status: Closed
resolution: Accepted
subsystem: tcl :: chan :: *
priority: 5 Medium
severity: Critical
foundin: 1.19
private_contact: af9c70d5700d5af288b87a3a9ed94e1300911d18
title: tcl::chan::cat - syntax error and bad behavior with fileevents
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458589.30803292
comment:
  tcl::cache::cat 1.0.3 has a critical bug, if an event handler has been registered on the reflected channel. 

  By running the following code (interactively from wish)

  -----------------------------
  package tcl::chan::chan
  package tcl::chan::string

    # setup 2 simple data-channels.
    #  Here we use two simple string-channels but we could also [open] two simple files. 
  set fd1 [tcl::chan::string "ABCDE..XYZ"]
  set fd2 [tcl::chan::string "0123456789"]
   # setup a cat'enated channel
  set ch [tcl::chan::cat $fd1 $fd2]

   # register a file handler printing the contents of the cat'enated channel
   #  by reading 4 bytes at time -- NOTE: ch is a global variable
  # expected result is
  # <<ABCD>>
  # <<E..X>>
  # <<YZ01>>
  # <<2345>>
  # <<6789>>
  # <<>>
  chan event $ch readable {
      if { [eof $ch] } { close $ch } else { puts "<<[read $ch 4]>>" }
  }

  # ! NOTHING happens !!!!

   # trying to force a read ...
  read $ch 1 ;#  -->  error ... see below
  --------------------------------------------
  bad event name "rc7": must be readable or writable
  --------------------------------------------

  There's an error in the logic of the "watch" method.

  I included a zip with all the updated files; corrections and some code cleaning.
  - cat.tcl       --  the main correction, and version changed to 1.0.3
  - pkgIndex.tcl  --  version changed 
  - cat.man       --  version changed
  - changeLog     --  version changed

  ABU


tkt_uuid: e1b2ade14182c0c301d519bed0388caef997ffa9
type: Bug
status: Closed
resolution: Fixed
subsystem: imap4
priority: 5 Medium
severity: Cosmetic
foundin: trunk
private_contact: 20416f2875afa3f6736d6bd17d632bd165a1893e
title: imap4 - Add category Networking
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458584.63736888
comment:
  In the Table of Contents 
  (http://core.tcl.tk/tcllib/doc/trunk/embedded/md/toc.md) 
  the package imap4 is listed in the category "Unfiled".
  Add [category  Networking] in file modules/imap4/imap4.man after 
  [titledesc {imap client-side tcl implementation of imap protocol}]


tkt_uuid: b61793dbbc4ef4fdffba80cf2cfe998b61a7e475
type: Patch
status: Closed
resolution: Accepted
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 3ddb294ff05af1c5992db8a69dab0cc1e36a126e
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Merge Request: hypnotoad branch
cmimetype: text/plain
submitter: hypnotoad
assignee: aku
closer: aku
closedate: 2458659.22656227
comment:
  I have enhancements to the clay, httpd, and practcl modules in the hypnotoad branch that are passing their tests and I would like to see merged into trunk.


tkt_uuid: c17f7019ecde4d1a441ec36dede4af2fd7f89d74
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 7 High
severity: Severe
foundin: 0.5
private_contact: e1e289e81f931be9eb396cfee59849a6b74fd383
title: TEPAM Introduction Documentation - Markdown generation errors
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458590.45641601
comment:
  The TEPAM Introduction page at https://core.tcl.tk/tcllib/doc/trunk/embedded/md/tcllib/files/modules/tepam/tepam_introduction.md contains a couple of errors:

  1. The PROCEDURE DECLARATION section, 2nd paragraph after the example code, says "The procedure body on the other hand is identical between a command declared with proc and a command declared with procedure", but the example code contains asterisks in the body which aren't part of a normal "proc" declaration. If they're not formatting errors, the text doesn't explain them.

  2. In the FLEXIBLE ARGUMENT DIALOG BOX section, the big example code is missing a trailing square bracket "]".


tkt_uuid: 056a74a30fc8ca503a9d50e97a0f0d0df5b51518
type: Bug
status: Open
resolution: None
subsystem: math
priority: 5 Medium
severity: Minor
private_contact: b4dd46eb62d921721c0aeef91d8d6e06aaeb6646
title: The numtheory package is incomplete
cmimetype: text/plain
submitter: arjenmarkus
assignee: nobody
closer: nobody
comment:
  As I noticed when examining ticket 3c17835a2da341ad99c5e70007615f281f250534, the numtheory package as contained in the file "numtheory.tcl" is incomplete. The file was derived from the original numtheory.dtx file. We will need to update the package before the other ticket can be solved.


tkt_uuid: 52dfecac6908cc0399870b878896a7a6779cefb5
type: Patch
status: Open
resolution: None
subsystem: markdown
priority: 5 Medium
severity: Important
foundin: 1.19
private_contact: 6dcd7ca00fdbf25f6645f6a67a11668e7b5ef099
title: Wrongly add a carriage return on <pre><code>
cmimetype: text/plain
submitter: Géballin
assignee: nobody
closer: nobody
comment:
  When converting CODE BLOCKS (4 spaces) to <pre><code>, Markdown module add a carriage return (\n) before closing tags which shouldn't be the case and cause rendering problems.

  To correct this, just remove the "\n" on line 256.

  Patch :
  --- markdown.tcl	2019-05-18 17:55:28.177265543 +0200
  +++ markdown.new.tcl	2019-05-18 18:37:06.260674411 +0200
  @@ -253,7 +253,7 @@
                       }
                       set code_result [join $code_result \n]
   
  -                    append result <pre><code> $code_result \n </code></pre>
  +                    append result <pre><code> $code_result</code></pre>
                   }
                   {^(?:(?:`{3,})|(?:~{3,}))\{?(\S+)?\}?\s*$} {
                       # FENCED CODE BLOCKS


tkt_uuid: fb4384e4b4b3173f72f863ecfca9d0b6fb9647e4
type: Bug
status: Open
resolution: None
subsystem: uri
priority: 5 Medium
severity: Minor
foundin: 1.2.7
private_contact: 8dda71963bd5edcf76271381ede4f2d7ca6cd4b3
title: uri::resolve bug/feature causing loss of base address
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  A duplicate leading / will cause uri::resolve to loose its base address. I am not sure consider it is a feature or a bug

  % info patchlevel
  8.5.19
  % package require uri
  1.2.7

  # unexpected behaviour due to '//' in url argument 
  % uri::resolve https://127.0.0.1:8016 //index.html
  https://index.html

  # expexted
  % uri::resolve https://127.0.0.1:8016 /index.html
  https://127.0.0.1:8016/index.html

  # expected
  % uri::resolve https://127.0.0.1:8016 index.html
  https://127.0.0.1:8016/index.html


tkt_uuid: d56da1abcaa028bed473ff5ffbd814f41909c5f5
type: Bug
status: Open
resolution: None
subsystem: blowfish
priority: 5 Medium
severity: Minor
foundin: 1.0.4
private_contact: 87a8af3af6267b859f2893f3f1d57a347c5b095a
title: Incorrect padding of data when using input channel
cmimetype: text/plain
submitter: anonymous
closer: nobody
comment:
  Blowfish pads an incoming stream improperly. This was seen and reported by Jim in this thread on comp.lang.tcl:
  https://groups.google.com/forum/#!topic/comp.lang.tcl/XhDe5-yLzw0

  The improper padding happens in the procedure blowfish::Chunk which already contains a FIXME comment. The procedure needs to care about 2 things:

  1. Data must always be processed in multiples of 8 bytes. However, it's not guaranteed that a multiple of 8 bytes is read even in the middle of a stream. Reasons can be an odd user provided chunk size or a nonblocking channel. My patch introduces a new variable state(remainder) to hold the modulo data.

  2. Apply padding at the end of the stream, and only there. Don't pad an empty string. Unfortunately, blowfish::Pad is doing exactly this. I think an empty string should not be padded. Likewise an empty data set encrpyts to an empty data set. If this is not correct then extra care has to be taken with the remainig data at EOF. Also, blowfish::Chunk didn't call pad with the user provided pad character.

  The attached patch takes care of both points.

  Missing: A test for the input channel API.

  -- Stephan Effelsberg


tkt_uuid: 9e7df782194e87df7faa63a632139894df297b4a
type: Patch
status: Open
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Pull Changes from 2b1fd1d488 (hypnotoad) into Trunk
cmimetype: text/plain
submitter: hypnotoad
assignee: nobody
closer: nobody
comment:
  I discovered a cosmetic bug in Clay's uuid generator when running in the mode where it works off of Tcllib's md5 implementation. This merge fixes that bug, and includes a rebuild of the httpd and practcl modules which depend on clay.


tkt_uuid: 8168daf796e4cc2a843f4d1a4f2f38e348197945
type: RFE
status: Open
resolution: None
subsystem: dns
priority: 5 Medium
severity: Minor
foundin: 1.19
title: make reverse lookup of IPv6 addresses work
cmimetype: text/html
submitter: buzzdeee
assignee: nobody
closer: nobody
comment:
  using <pre>[dns::resolve AN_IPv6_ADDRESS]</pre> currently leads to an error.<br>

  this patch against modules/dns/dns.tcl below makes it work for me:

  <pre>
  --- dns.tcl.orig	Thu Jun 13 12:34:10 2019
  +++ dns.tcl	Thu Jun 13 12:38:02 2019
  @@ -286,10 +286,17 @@
           }
       }
   
  -    # Check for reverse lookups
  +    # Check for reverse lookups, IPv4 first, then IPv6
       if {[regexp {^(?:\d{0,3}\.){3}\d{0,3}$} $state(query)]} {
           set addr [lreverse [split $state(query) .]]
           lappend addr in-addr arpa
  +        set state(query) [join $addr .]
  +        set state(-type) PTR
  +    } elseif {[string match {*:*} $state(query)]} {
  +        set addr [ip::normalize $state(query)]
  +        set addr [split [string reverse $addr] :]
  +        set addr [join [split [join $addr ""] {}] .]
  +        lappend addr ip6 arpa
           set state(query) [join $addr .]
           set state(-type) PTR
       }

  </pre>

  similarily to checking if we got an IPv4 address, check if the query contains a colon. Checking if it contains a colon should be sufficient, since IPv4 addresses don't contain colons, as well as they are not allowed in hostnames.

  Once an IPv6 address is identified, normalize it, and format the query appropriately.


tkt_uuid: b1c2d07148abc1d84c97b44f0e3d1ef56cf04504
type: Bug
status: Open
resolution: None
subsystem: ip
priority: 5 Medium
severity: Minor
foundin: 1.19
title: ip::version and ip::mask accepts invalid netmask and other input after /
cmimetype: text/html
submitter: buzzdeee
closer: nobody
comment:
  IP version happily accepts and returns invalid netmasks:
  <pre>
  % ::ip::version 10.0.0.1/64
  4
  </pre>
  even worse, basically accepts all sorts of input:

  <pre>
  % ip::version 10.0.0.1/dsffds/44
  4
  </pre>

  The same is true for ip::mask

  I'm attaching a patch that makes things more strict in ip::version
  and then at the beginning of ip::mask, check ip::version.

  Then if ip::mask fails, also similariy to ip::version, return -1 on failure.


tkt_uuid: c030b5bc75717ae68d9ff524badca9370a3814fb
type: Bug
status: Closed
resolution: Accepted
subsystem: (unused)
priority: 7 High
severity: Important
foundin: 7fda9d9978
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Pull Request:
cmimetype: text/plain
submitter: hypnotoad
assignee: aku
closer: aku
closedate: 2458661.31358103
comment:
  I have fixed several bugs in Practcl and Httpd that should be brought over to Trunk.

  I have run the test suite on checkin  7fda9d9978, and no new bugs were found in the clay, httpd, or practcl modules. (Where the edits occurred.)


tkt_uuid: cc77e167bfaa779a203573f3a26da1a57fb9c8f6
type: Patch
status: Closed
resolution: Fixed
subsystem: simulation::random
priority: 5 Medium
severity: Minor
private_contact: 0da21f2649e2f7139a4113668982586168b3d24e
title: package simulation::random lacks triangular distribution
cmimetype: text/plain
submitter: emiliano
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2458660.79340618
comment:
  simulation::random lacks a prng with triangular distribution.
  This distribution is important as is one of the distributions
  used in calculation of the combined uncertainty in measurements.
  See for example https://www.bipm.org/utils/common/documents/jcgm/JCGM_101_2008_E.pdf


tkt_uuid: 7c8f294f7f4d88f8e25e08300f06f7e09ded9f73
type: Bug
status: Open
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: 1.18
private_contact: 194c9ef8edbd9a57ef36f4f18fde1d57ce26e1e5
title: clay: Duplicate tip479 tests ?
cmimetype: text/x-fossil-wiki
submitter: aku
assignee: hypnotoad
closer: nobody
comment:
  Sean, when fixing recent `clay.test` failures on trunk, see [4ccd49719e],
  I noticed that all the `tip479` tests look to be replicated 4 times.
  The test descriptions also do not really match what the tests do.
  Please have a look.

  andreask@ten:~/fast/aku/Tcllib/dev> grep tip479- modules/clay/clay.test 

  test tip479-001 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-002 {Test that a later ensemble definition trumps a more primitive one} -body {

  test tip479-003 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-004 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-001 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-002 {Test that a later ensemble definition trumps a more primitive one} -body {

  test tip479-003 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-004 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-001 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-002 {Test that a later ensemble definition trumps a more primitive one} -body {

  test tip479-003 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-004 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-001 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-002 {Test that a later ensemble definition trumps a more primitive one} -body {

  test tip479-003 {Test that a later ensemble definition trumps a more primitive one} {

  test tip479-004 {Test that a later ensemble definition trumps a more primitive one} {


tkt_uuid: f8e09da9dc22e29ca64e7862c19b573f1d522d4c
type: Bug
status: Closed
resolution: By Design
subsystem: pki
priority: 5 Medium
severity: Severe
foundin: 0.10
private_contact: 6b59b7b9d317a4338429e01b2628c3e0509cd1c9
title: pki::verify return always false if algo (hash algorithm) argument is provided
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458662.25585267
comment:
  e.g. the unit test of pki.test fail if $hash is provided to verify

  This original code of the test works ok
  set signed   [::pki::sign   $plain  $key   $hash]
  set verified [::pki::verify $signed $plain $key]

  but this fail (providing hash with the right hash algorithm used to sign)
  set signed   [::pki::sign $plain $key $hash]
  set verified [::pki::verify $signed $plain $key $hash]


tkt_uuid: 148eb6d849bb9d503fc19f475b0d99cfd0a4b00c
type: RFE
status: Open
resolution: None
subsystem: None
priority: 5 Medium
severity: Minor
private_contact: c8459d378d602de08a2ff023b35f1c3c62457d9f
title: Add a "package require tcllib" type "metapackage"
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Suggestion: Add a "package require tcllib" "metapackage", which would serve the following purposes (in no particular order):

  -- Simplify checking if there is an installed tcllib base package,
  -- Allow loading specific versions, or failing if the version is not available,
  -- Have the package require commend return the found version,
  -- Set up a few commands to query the installed base tcllib, such as the list of individual packages included; Possibly even how the hierarchy is structured (i.e., for "pkgfoo", with a child/sub package "pkgfoo::bar", indicate whether or not "pkgfoo" automatically loads the child or not).
  -- Possibly other uses..

  While I already wrote my code to scan the library paths and gather most of this information on my own, I really did not want to 1) reinvent the wheel, and 2) if the tcllib package structure or included packages changes, I would have to find and update my own code everywhere I use it. Even if I make my own package and just update that, I'd still have to keep it in sync with all other older code, older tcllib installations, etc. It would be better if the tcllib package provided it's own code for these things--after all, the package knows itself better than I do!

  As to my "why".. I'm playing with starkits, and trying to find out what packages are available/built-in to the various "tclkit" binaries I have found. But one of the most frustrating results of probing the package system is when I end up with long list of the individual packages in tcllib, when I'd rather just end up with "tcllib 1.18 is available". (Again, I've written code to do this, but it's "fragile" and will likely break if the internal structure of tcllib changes..)


tkt_uuid: 6db9fe84d197c8f9f979c719750ae6235ed3bf11
type: Bug
status: Closed
resolution: Fixed
subsystem: struct :: graph
priority: 9 Immediate
severity: Critical
foundin: 2.4.1
private_contact: f460f2d6e630fc785c7f814ddfc7f45371c8e62c
title: struct::graph node insert (C variant) with duplicate name crashes Tcl-shell
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2458711.27266344
comment:
  If you try to insert a node with a duplicate name, a message box pops up saying:
  "struct::graph(c) gn_new - tried to use duplicate name for new node".
  After closing the message box, the tcl-shell (Tkcon) exits or dies.
  The following code reproduces the observed behaviour:

  package require struct::graph
  set g [struct::graph]
  $g node insert n n

  I consider this a critical error because: 
  - The error message box is unexpected and not in line with normal tcl behaviour: expected is a normal stack trace
  - exiting the tcl shell is unexpected and unnecessary.
  Tcl 8.6.7 (ActiveState)
  tcl_platform(byteOrder)     = littleEndian
  tcl_platform(engine)        = Tcl
  tcl_platform(machine)       = amd64
  tcl_platform(os)            = Windows NT
  tcl_platform(osVersion)     = 10.0
  tcl_platform(pathSeparator) = ;
  tcl_platform(platform)      = windows
  tcl_platform(pointerSize)   = 8
  tcl_platform(threaded)      = 1
  tcl_platform(wordSize)      = 4

  Harm Olthof


tkt_uuid: e4d95d4ea0f97ab7e2be9e830b5f36a37b77e100
type: Bug
status: Open
resolution: None
subsystem: tepam
priority: 5 Medium
severity: Important
foundin: 0.5.2
private_contact: 22e3b7a55e291d179313f4c2e34877f09743ee31
title: TEPAM: using both -default and -multiple always includes default
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  If I define a procedure argument using both the -default and -multiple flags, then the default value is always included in the list of argument values in the body, even if one or more actual values are defined on the command line.

  I expected that the default would only be used if no actual values were specified on the command line.

  Ex:

  tepam::procedure mytest {
  	-args {
  		{-myarg -default mydefault -multiple
  		}
  	}
  }  {
  	puts $myarg
  }


  % mytest
  mydefault

  % mytest -myarg testval1 ; # expect "testval1"
  mydefault testval1

  % mytest -myarg testval1 -myarg testval2 ; # expect "testval1 testval2"
  mydefault testval1 testval2


