# ticket

tkt_uuid: 861622ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: mime
priority: 5 Medium
foundin: None
title: Documentation error(s)
cmimetype: text/plain
submitter: arjenmarkus
assignee: mrose
comment:
  The documentation for the mime package contains little
  or no information on the -parts option (it actually
  refers to -part). 

  One thing I found out trying:
  - if you combine several parts into one message, then
    you need to use "-canonical multipart/mixed" 

  It is not clear to me from the documentation how to 
  set a proper name for an attachment (default seems
  to be: Part 1.2)


tkt_uuid: 861721ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: nntp
priority: 5 Medium
foundin: None
title: NNTP is binary, yEnc is being corrupted
cmimetype: text/plain
submitter: orwellian
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-03-02T03:59:30
comment:
  Because of yEnc, binary must be downloadable.

  I have an 'expect' program to download a newsgroup,
  and I can make a lot of criteria choices based on the
  headers. The main purpose is to download pictures,
  then I use uudeview and xv next. I've used it forever,
  and wrote it before there was an nntp.tcl.

  95% of the yEncs were corrupted. I thought it was Usenet
  servers along the way doing the corruption. Recently I started
  downloading again, and now a high percentage of pictures are
  in yEnc format. Because I was getting almost nothing now, I
  investigated.

  I'm on a new dual-G5 running Unix. When I tried Netscape
  on this box, the yEncs were decoding. When I saved one of
  those to a file and compared it to my program's download,
  there was corruption alright. It apparently has to do with
  'expect' using Tcl's Unicode expectations. I tried adding
  'fconfigure's, but it didn't affect 'expect'.

  I decided to rewrite my program using the NNTP procs, and
  it was still corrupted. Then I added this line after the one
  'socket' command in nntp.tcl:

  fconfigure $sock -encoding binary

  Finally, yEncs were no longer being corrupted.

  tcllib 1.5 from TclTKAquaWithBatteries.


tkt_uuid: 861801ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: cmdline
priority: 5 Medium
foundin: None
title: Add a new option parser routine tailored for functions
cmimetype: text/plain
submitter: certgen
assignee: andreas_kupries
comment:
  Hey, I find the cmdline library particularly useful for
  script writing. I usually define a custom
  getFunctionsOpts routine that is a slight twist on the
  getKnownOptions routine (no support for -?/-h/-help)
  for new Tcl projects. The attached cmdline.tcl file
  contains the getFunctionOptions procedure -- I would
  like to submit this as a feature request for the next
  release of tcllib.

  Thanks for all the great utils!

  -Ian Chesal


tkt_uuid: 862491ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: fileutil
priority: 7 High
foundin: None
title: fileutil::find ... no catch around 'cd'
cmimetype: text/plain
submitter: carlls
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2005-02-02T06:49:55
comment:
  Cd sequences are not checked to see if the succeed. 
  I.e. failed due to permissions. 
  If failure occurs the code terminates. I would rather 
  it skip the problem children in a find. This problem has 
  been reproduced in both WIN32 & HP-UX


tkt_uuid: 862638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 5 Medium
foundin: None
title: can't read &quot;ftp(Wait)&quot;: no such variable - background error
cmimetype: text/plain
submitter: nobody
assignee: gwlester
comment:
  When an FTP session is close, all the variables has been 
  unset. However, the ::ftp::Timeout{} event is still be 
  triggered. This event will read the ftp(Wait) variable 
  that doesn't exist because it has already been unset 
  during ftp close session. Therefore, this background 
  error occur.  To fix this or to work around, we need 
  check whether if the ftp(Wait) variable is exist 
  in ::ftp::Timeout{} procedure, then we only procceed 
  on the event. 

  proc ::ftp::Timeout {s} {
      upvar ::ftp::ftp$s ftp
      if {[info exist ftp(Wait)]} {
          after cancel $ftp(Wait)
          set ftp(state.control) 1

          DisplayMsg "" "Timeout of control connection after 
  $ftp(Timeout) sec.!" error
          Command $ftp(Command) timeout
      }
      return
  }

  This only happen when we use ftp in asynchronous 
  mode.

  My Email:
  champdog_s1977@hotmail.com


tkt_uuid: 864530ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: md5
priority: 8
foundin: None
title: md5::md5 -- incompatible API change in 2.0
cmimetype: text/plain
submitter: jenglish
assignee: patthoyts
closer: patthoyts
closedate: 2004-02-08T01:09:37
comment:
  Previously, [md5::md5 $data] returned a result as a hex
  string; as of version 2.0, it returns it as binary.
  Although this is noted in the ChangeLog, it is easy to
  miss, and is sure to cause many hard-to-track-down
  errors when users upgrade to the next release of tcllib.

  This seems like a gratuitous incompatibility.  Please
  make '-hex' the default, for compatibility with tclllib
  1.4, and add a '-bin' or '-binary' option for those
  that want the new behaviour.


tkt_uuid: 867604ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: Problem with focus and spinbox
cmimetype: text/plain
submitter: nobody
assignee: damonc
closer: damonc
closedate: 2004-01-06T07:24:16
comment:
  If trying the following code:

  package require BWidget
  pack [spinbox .b1]
  pack [spinbox .b2]
  .b1 insert end hello
  .b2 insert end hello

  and using the <Tab> key, content in the spinbox is not
  selected.

  Solutions seems to add:

  bind Spinbox <<TraverseIn>> [bind Entry 
  <<TraverseIn>>]

  in file init.tcl


tkt_uuid: 868315ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: Dialog widget hangs in BWidget 1.7
cmimetype: text/plain
submitter: sgamon
assignee: damonc
closer: damonc
closedate: 2004-01-06T07:23:32
comment:
  When I issue the "draw" command to a Dialog widget in
  BWidget 1.7, the entire application hangs.  

  I am using ActiveTcl 8.4.5 on WinXP Pro.

  The code below illustrates the error.  Switching to
  BWidget 1.6 makes it work.
   

   # DialogTest.tcl
   #
   # A test of the BWidget Dialog widget.

   package require -exact BWidget 1.7

   button .b -text "Dialog" -command {ShowDialog}
   pack .b

   proc ShowDialog {args} {
  Dialog .prompt \
  -title {???} \
  -parent .b \
  -place above

  label .prompt.label -text "This is a dialog!\nDid it
  work?"

  pack .prompt.label

  .prompt add -text Okay -command {.prompt enddialog Okay}
  .prompt add -text Cancel -command {.prompt enddialog
  Cancel}

  set Prompt [.prompt draw]

  destroy .prompt
   }
   


tkt_uuid: 870429ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: html
priority: 5 Medium
foundin: None
title: ::html::textInput does not allow overriding of input.size
cmimetype: text/plain
submitter: mic42
assignee: welch
closer: mic42
closedate: 2006-07-02T20:02:28
comment:
  Basically a trivial problem:

  ::html::textInput foo bar size=\"20\"

  on would expect (in the generated html):

  <input ... size="20"> 

  but one gets:

  <input ... size="45" size="20">

  This is documented in the source code comments for
  ::html::textInput, but i think it is plain stupid:

  Possible fix:
  expand defaults/tagParam to handle lists of params and
  use that in ::html::textInput to check for overridden
  default values.

  Michael


tkt_uuid: 873666ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: scrollw.tcl does not support -relief
cmimetype: text/plain
submitter: nobody
assignee: hobbs
closer: hobbs
closedate: 2004-02-03T22:13:45
comment:
  BWidget's ScrolledWindow does not support options
  -relief and -bd at creation time

  May be the statement 
  set sw    [frame $path \
              -relief flat -borderwidth 0 -background $bg \
      -highlightthickness 0 -takefocus 0]
  is to change to
  set sw    [eval frame $path \
      -background $bg \
      -highlightthickness 0 -takefocus 0  \   
  [Widget::subcget $path :cmd]]


tkt_uuid: 879451ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: log
priority: 5 Medium
foundin: None
title: add better introspection to logger
cmimetype: text/plain
submitter: mic42
assignee: davidw
closer: davidw
closedate: 2004-03-10T11:17:22
comment:
  Hi,

  I would like to see more introspection for the logger
  command. 

  At the moment only logger::services and
  ${log}::services exist

  I would like to see this additions:

  ::logger::levels -- 
  Return the currently defined levels accepted by logger
  enable/disable.

  ${log}::enabled --
  Return 1 if the service is enabled 0 otherwise.

  ${log}::currentloglevel -- (bad name?)
  Return the current log level for this service .

  And maybe:

  ${log}::delproc --
  Return the current deleteproc if no argument was given.

  Similar behaviour for the procs for the log levels.
  (BTW. What is the rationale for not using a proc name
  as argument for logproc but creating a new proc? Speed?
  )

  Michael


tkt_uuid: 879812ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: log
priority: 5 Medium
foundin: None
title: Patch for FRE 879451
cmimetype: text/plain
submitter: mic42
assignee: davidw
closer: davidw
closedate: 2004-03-10T11:19:22
comment:
  An initial patch for better introspection and a new
  interface for logproc to optionally use an existing proc.


tkt_uuid: 880692ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Not Applicable Here
subsystem: ncgi
priority: 5 Medium
foundin: None
title: ncgi - = in cgi value breaks parsing of variable/value pairs
cmimetype: text/plain
submitter: nobody
assignee: gwlester
comment:
  the regular expression in proc nvlist was changed from 
  (.*)=(.*) to {([^=]*)=(.*)}


  proc ::ncgi::nvlist {} {
      set query [query]
      set type  [type]
      switch -glob -- $type {
          "" -
          application/x-www-form-urlencoded -
          application/x-www-urlencoded {
              set result {}

              # Any whitespace at the beginning or end of 
  urlencoded data is not
              # considered to be part of that data, so we 
  trim it off.  One special
              # case in which post data is preceded by a \n 
  occurs when posting
              # with HTTPS in Netscape.

              foreach {x} [split [string trim $query] &] {
                  # Turns out you might not get an = sign,
                  # especially with <isindex> forms.
  #### start: RE in line below changed:
                  if {![regexp -- {([^=]*)=(.*)} $x dummy 
  varname val]} {
  #### end
                      set varname anonymous
                      set val $x
                  }
                  lappend result [decode $varname] [decode 
  $val]
              }
              return $result
          }
          multipart/* {
              return [multipart $type $query]
          }
          default {
              return -code error "Unknown Content-Type: 
  $type"
          }
      }
  }


tkt_uuid: 882154ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: dns
priority: 5 Medium
foundin: None
title: No support for reverse lookups in dns
cmimetype: text/plain
submitter: patthoyts
assignee: patthoyts
closer: patthoyts
closedate: 2004-01-31T23:32:13
comment:
  The dns package provides no assistance in doing reverse
  lookups.
  Try
  set tok [dns::resolve d.c.b.a.in-addr.arpa -type PTR]
  lindex [dns::Decode $tok] 3
  and get the rdata for the name.

  This can be auto detected by regexp {[\d.]+} $query


tkt_uuid: 882402ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: textutil
priority: 7 High
foundin: None
title: -full option ignored in ::textutil::adjust command
cmimetype: text/plain
submitter: andreas_kupries
assignee: vogeler
closer: andreas_kupries
closedate: 2004-09-29T19:10:07
comment:
  In the textutil package, which is a part of Tcllib, the -full 
  option (which should stop multiple consecutive space 
  characters being replaced with a single space) seems to 
  be ignored. This is in ActiveTcl 8.4.3.0, textutil version 
  0.6 . There are three [regsub] commands executed near 
  the beginning of ::textutil::adjust; it seems that they 
  should only be run if the -full option wasn't given.


  Original submitter:
  m_j_griffiths@talk21.com

  Original location of the bug:
  http://bugs.activestate.com/show_bug.cgi?id=28867


tkt_uuid: 883573ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 5 Medium
foundin: None
title: ftp change directory problems
cmimetype: text/plain
submitter: dejavo
assignee: gwlester
comment:
  There is a problem changing to directories with some
  special
  characters.

  I checked the ftp with gftp client and the directories
  are accessible.

  Roi


tkt_uuid: 886304ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: BWidgets1.7.0 bug in Notebook:bindtabs command
cmimetype: text/plain
submitter: donp1
assignee: hobbs
closer: hobbs
closedate: 2004-02-03T22:03:07
comment:
  I am using ActiveTcl8.4.4.0 with BWidgets1.7.0. The 
  Notebook widgets bindtabs command seems to be 
  stripping off the first two characters of the tabname. 
  Here is a small script to replicate the bug. 

  #!/bin/env wish

  proc print_tab_name {tab} {
  puts $tab
  }

  # Load BWidget package into the interpreter
  package require BWidget

  wm withdraw .

  # Create Notebook
  set notebook [NoteBook .nb]
  $notebook insert end TestTab -text "Test Tab"
  $notebook compute_size
  pack $notebook -fill both -expand yes -padx 4 -pady 4
  $notebook raise [$notebook page 0]
  $notebook bindtabs <Button-1> "print_tab_name"

  wm deiconify .


tkt_uuid: 886385ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Not Applicable Here
subsystem: control
priority: 5 Medium
foundin: None
title: Enhanced do...while|until [prefix] [suffix] Control Structur
cmimetype: text/plain
submitter: nobody
assignee: dgp
comment:
  This one came out of my customer demand! Pat Thoyts 
  and Donal K. Fellows suggested me to submit it here.

  The submission is in form of a TIP. Please search 
  for "sample implementation" to get to the code.

  Please also see at the end of it, untried version of tests. 
  Please search for "tests for do" to get to the code

  TIP 
  Title 
  Enhanced do...while|until [prefix] [suffix] Control 
  Structure 
  Version 
  $Revision: 1.4 
  Author 
  Bhushit Joshipura 
  State 
  Draft 
  Type 
  Project 
  Vote 
  Pending 
  Created 
  20-Jan-2004 
  Keywords 
  control structure, do, while, until, prefix, suffix 
  ~ Abstract 
  This TIP proposes the introduction of an enhancement 
  on do...while|until control structure already present in 
  TCLLib. It proposes to add prefix statement list and 
  suffix statement list to prepend and append to 
  statement body of do...while|until for the "while" part 
  (second loop onwards) of the loop. 
  ~ Rationale 
  Theoretically only two controls - if and goto - are 
  sufficient to implement all algorithms. However, 
  languages provide more control structures for better 
  representation of algorithms. 
  do...while|until is a useful structure in itself for parsing, 
  file reading etc. With little pain, a while loop does the 
  job too. However, when it comes to nesting, 
  do...while|until into another, equivalent while loop starts 
  becoming clumsier. 
  In situations where do...while|until is used in testing, if 
  the statement body of do...while|until changes state of 
  entity being tested, next iteration is bound to have side 
  effects. At that time, proposed prefix and suffix 
  statements come handy. 
  While it is still possible to handle all of these in a while 
  loop, nesting becomes a nightmare. 
  Proposed solution is more elegant, in spirit of 
  do...while|until's spirit of treating first pass specially. 
  ~ Implementation in Other Languages 
  C, C++, Java, Pascal have do...while. Perl has 
  do...while|until. Python does not have any equivalent. 
  ~ Grammar and Behavior 
  |do { 
  | 
  |} while|until { } [ prefix { }] [suffix { statements2>}] 
  1. are executed 
  2. while|until is evaluated 
  3. while associated are true ( or until are false ) 
  3.1 are executed 
  It is necessary to specify one and only one of "while" 
  or "until" with proper condition block following it. 
  ~Sample Invocations 
  set x 1 
  |do { 
  |    puts "Hello world!" 
  |    incr x 
  |} until { $x > 3 } prefix { 
  |    puts "prefix begin" 
  |    puts $x 
  |    puts "prefix end" 
  |} suffix { 
  |    puts "suffix begin" 
  |    puts $x 
  |    puts "suffix end" 
  |} 
  ~Contrast 
  Contrast above code with its while loop equivalent 
  |set x 1 
  |set firsttime "yes" 
  |while { $x <= 3 } { 
  |    if { $firsttime == "no" } { 
  | puts "prefix begin" 
  | puts $x 
  | puts "prefix end" 
  |    } 
  |    puts "Hello world!" 
  |    incr x 
  |   if { $firsttime == "no" } { 
  | puts "suffix begin" 
  | puts $x 
  | puts "suffix end" 
  |    } 
  |    set firsttime "no" 
  |} 
  ~Sample Implementation 
  |# do.tcl -- 
  |# 
  |#        Tcl implementation of a "do ... while|until" loop. 
  |#        Once first iteration gets over, body can be 
  augmented using prefix or suffix 
  |# 
  |# Originally written for the "Texas Tcl Shootout" 
  programming contest 
  |# at the 2000 Tcl Conference in Austin/Texas. 
  |# 
  |# Copyright for TCLLib implementation was 
  |# Copyright (c) 2001 by Reinhard Max 
  |# 
  |# Added prefix and suffix by Bhushit Joshipura, 
  December 15, 2003 
  |# Bhushit does not know what happens to copyrights 
  |# 
  |# See the file "license.terms" for information on usage 
  and redistribution 
  |# of this file, and for a DISCLAIMER OF ALL 
  WARRANTIES. 
  |# 
  |# 
  |namespace eval ::control { 
  | 
  |    proc do {body args} { 
  | 
  | # 
  | # Implements a "do body while|until test [ [prefix | 
  suffix] bodyparts ]" loop 
  | # 
  | # It is almost as fast as builtin "while" command for 
  loops with 
  | # more than just a few iterations. 
  | # 
  | 
  | set len [llength $args] 
  | if {$len != 6 && $len != 4 && $len !=2 && $len != 0} { 
  |     set proc [namespace current]::[lindex [info level 0] 
  0] 
  |     return -code error "wrong # args: should be \"$proc 
  body\" or \"$proc body \[until|while\] test\" or \"$proc 
  body \[until|while\] test \[ \[ prefix | suffix \] bodyparts 
  \]" 
  | } 
  | set test 0 
  | set bodyprefix "" 
  | set bodysuffix "" 
  | set whileOrUntil "" 
  | 
  | foreach { argument value } $args { 
  |     switch -exact -- $argument { 
  | "while" { 
  |     if { $whileOrUntil == "" } { 
  | set whileOrUntil $argument 
  | set test $value 
  |     } else { 
  | return -code error \ 
  |     "\"$argument\" found after \"$whileOrUntil\"" 
  |     } 
  | } 
  | "until" { 
  |     if { $whileOrUntil == "" } { 
  | set whileOrUntil $argument 
  | set test !($value) 
  |     } else { 
  | return -code error \ 
  |     "\"$argument\" found after \"$whileOrUntil\"" 
  |     } 
  | } 
  | "prefix" { 
  |     # last of prefix will be considered 
  |     set bodyprefix $value 
  | } 
  | "suffix" { 
  |     # last of suffix will be considered 
  |     set bodysuffix $value 
  | } 
  | default { 
  |     return -code error \ 
  | "bad option \"$whileOrUntil\": must be until, while, 
  prefix or suffix" 
  | } 
  |     } 
  | } 
  | 
  | # the first invocation of the body 
  | set code [catch { uplevel 1 $body } result] 
  | 
  | # decide what to do upon the return code: 
  | # 
  | #               0 - the body executed successfully 
  | #               1 - the body raised an error 
  | #               2 - the body invoked [return] 
  | #               3 - the body invoked [break] 
  | #               4 - the body invoked [continue] 
  | # everything else - return and pass on the results 
  | # 
  | switch -exact -- $code { 
  |     0 {} 
  |     1 { 
  | return -errorinfo [ErrorInfoAsCaller uplevel do]  \ 
  |     -errorcode $::errorCode -code error $result 
  |     } 
  |     3 { 
  | # FRINK: nocheck 
  | return 
  |     } 
  |     4 {} 
  |     default { 
  | return -code $code $result 
  |     } 
  | } 
  | 
  | set body [ format "%s\n%s\n%s" $bodyprefix $body 
  $bodysuffix ] 
  | 
  | # the rest of the loop 
  | set code [catch {uplevel 1 [list while $test $body]} 
  result] 
  | if {$code == 1} { 
  |     return -errorinfo [ErrorInfoAsCaller while do] \ 
  | -errorcode $::errorCode -code error $result 
  | } 
  | return -code $code $result 
  | 
  |    } 
  |} 
  ~Copyright 
  This document is placed in public domain. 


  Tests for do

  # do.test --
  #
  #         Tests for [control::do]
  # 
  # RCS: @(#) $Id: do.test,v 1.6 2003/05/01 22:40:13 
  patthoyts Exp $
  #

  package forget control
  catch {namespace delete control}

  # Direct loading of provide script -- support testing even
  # when not installed.  And be sure we test the local copy
  # and not some later version that may be installed.
  source [file join [file dirname [info script]] control.tcl]
  namespace import ::control::do

  package require tcltest
  namespace import -force 
  tcltest::test ::tcltest::cleanupTests

  # This constraint restricts certain tests to run on tcl 
  8.3+
  if {[package vsatisfies [package provide tcltest] 2.0]} {
      # tcltest2.0+ has an API to specify a test constraint
      ::tcltest::testConstraint tcl8.3plus \
          [expr {[package vsatisfies [package provide Tcl] 
  8.3]}]
  } else {
      # In tcltest1.0, a global variable needs to be set 
  directly.
      set ::tcltest::testConstraints(tcl8.3plus) \
          [expr {[package vsatisfies [package provide Tcl] 
  8.3]}]
  }

  # ----------------------------------------
  test {do-1.0} {do ... while} {
      set x 0
      do {incr x} while {$x < 10}
      set x
  } 10

  # ----------------------------------------
  test {do-1.1} {do ... until} {
      set x 0
      do {incr x} until {$x > 10}
      set x
  } 11

  # ----------------------------------------
  test {do-1.2} {break} {
      set x 0
      do {
  incr x
  if {$x == 5} {break}
      } until {$x == 10}
      set x
  } 5

  # ----------------------------------------
  test {do-1.3} {continue} {

      set x 0
      set xx [list]
      do {
  incr x
  if {$x == 5} {continue}
  lappend xx $x
      } until {$x == 10}
      set xx
  } {1 2 3 4 6 7 8 9 10}

  # ----------------------------------------
  test {do-1.4} {error} {
      catch {
  set x 0
  do {
      incr x
      if {$x == 5} {foo}
  } while {$x < 10}
      } result
      list $x $result
  } {5 {invalid command name "foo"}}

  # ----------------------------------------
  test {do-1.5} {return} {
      proc foo {} {
  set x 0
  do {
      incr x
      if {$x == 5} { return $x }
  } while {$x < 10}
      }
      set result [foo]
      rename foo ""
      set result
  } 5

  # ----------------------------------------
  test {do-1.6} {break in the first loop} {
      set x 0
      do {
  break
  incr x
      } while {$x < 10}
      set x
  } 0

  # ----------------------------------------
  test {do-1.7} {continue in the first loop} {
      set x 0
      set xx [list]
      do {
  incr x
  if {$x == 1} {continue}
  lappend xx $x
      } until {$x == 10}
      set xx
  } {2 3 4 5 6 7 8 9 10}

  # ----------------------------------------
  test {do-1.8} {error in the first loop} {
      set x 0
      catch {
  do {
      foo
      incr x
  } until {$x == 10}
      } result
      list $x $result
  } {0 {invalid command name "foo"}}

  # ----------------------------------------
  test {do-1.9} {[do ... while] with false condition} {
      set x 0
      do {
  incr x
      } while 0
      set x
  } 1

  # ----------------------------------------
  test do-1.10 {[do ... until] with true condition} {
      set x 0
      do {
  incr x
      } until 1
      set x
  } 1

  # ----------------------------------------
  test do-1.11 {third arg is neither while nor until} {
      set x 0
      catch {
  do {
      incr x
  } foo 1
  set x
      } result
      list $x $result
  } {0 {bad option "foo": must be until, or while}}

  # ----------------------------------------
  test do-1.12 {stack traces for errors in the first 
  iteration} {
      proc a {} b
      proc b {} {do c while 1}
      proc c {} d
      catch a
      set ::errorInfo
  } {invalid command name "d"
      while executing
  "d"
      (procedure "c" line 1)
      invoked from within
  "c"
      ("do" body line 1)
      invoked from within
  "do c while 1"
      (procedure "b" line 1)
      invoked from within
  "b"
      (procedure "a" line 1)
      invoked from within
  "a"}

  # ----------------------------------------
  test do-1.14 {stack traces for errors in subsequent 
  iterations} tcl8.3plus {
      proc a {} b
      proc b {} {
  set i 10
  do {
      incr i -1
      c $i
  } while {$i}
      }
      proc c {i} {if {$i==5} e}
      catch a
      set ::errorInfo
  } {invalid command name "e"
      while executing
  "e"
      (procedure "c" line 1)
      invoked from within
  "c $i"
      ("do" body line 3)
      invoked from within
  "do {
      incr i -1
      c $i
  } while {$i}"
      (procedure "b" line 3)
      invoked from within
  "b"
      (procedure "a" line 1)
      invoked from within
  "a"}

  # ----------------------------------------
  test do-2.0 {one-shot do} {
      set x 0
      do {incr x}
      set x
  } 1

  # ----------------------------------------
  test do-2.1 {one-shot do with break} {
      set x 0
      do {incr x; break; incr x}
      set x
  } 1

  # ----------------------------------------
  test do-2.2 {wrong no of arguments} {
      set x 0
      set res [catch {do {incr x} foo} ret]
      list $x $res $errorInfo
  } {0 1 {wrong # args: should be "::control::do body" 
  or "::control::do body [until|while] test"
      while executing
  "do {incr x} foo"}}

  # ----------------------------------------
  test do-2.3 {wrong no of arguments} {} {
      set res [catch do]
      if {[string match \
       {no value given for parameter "body" 
  to "do"*} \
       $::errorInfo]
      } then {
  set ::errorInfo {wrong # args: should be "do 
  body args"
      while executing
  "do"}
      }
      list $res $::errorInfo
  } {1 {wrong # args: should be "do body args"
      while executing
  "do"}}

  # ----------------------------------------
  test do-2.4 {one-shot do with error} {
      set x 0
      set res [catch {do {
  incr x
  foo
  incr x
      }}]
      list $x $res $::errorInfo
  } {1 1 {invalid command name "foo"
      while executing
  "foo"
      ("do" body line 3)
      invoked from within
  "do {
  incr x
  foo
  incr x
      }"}}

  cleanupTests

  if {[info exists ::argv0] && $::argv0 == [info script]} {
      # a proc that wastes some time
      proc something {n} {
  for {set i 0} {$i < $n} {incr i} {}
      }
      
      proc main {} {
  # run it for the first time to get it byte compiled
  something 1

  set payload {
      something 10
      incr x
  }
  puts "\nComparing performance of do-while, do-
  until and builtin while..."
  set format "%-8s : %20s for %4d iteration(s)."
  foreach c {1 10 5000} {
      puts ""
      foreach {descr script} {
  {do while} {do $payload while {$x < 
  $c}}
  {do until} {do $payload until {$x == 
  $c}}
  {while} {while {$x < $c} $payload}
      } {
  set x 0
  puts [format $format $descr [lrange 
  [time $script 1] 0 1] $x]
      }
  }
      }
      main
  }

  # Local variables:
  # mode: tcl
  # End:


tkt_uuid: 891024ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: tclapps :: tkchat
priority: 5 Medium
foundin: None
title: color handling problems for unrecognised users
cmimetype: text/plain
submitter: patthoyts
assignee: patthoyts
closer: patthoyts
closedate: 2004-02-05T15:22:47
comment:
   can't read "Options(Color,<[A]bomination>,Web)": no
  such element in array
      while executing
  "string compare $Options(Color,$nick,Web) $clr"
      (procedure "checkNick" line 23)
      invoked from within
  "checkNick $nick $clr"
      (procedure "addAction" line 3)
      invoked from within
  "addAction $clr "<$truenick>" $msg $mark"
      (procedure "addMessage" line 35)
      invoked from within
  "addMessage "" $nick $msg HISTORY"
      (procedure "::tkchat::LoadHistoryLines" line 15)
      invoked from within
  "::tkchat::LoadHistoryLines"
      ("after" script)


tkt_uuid: 891254ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: utils.tcl, place proc: does not place left or top
cmimetype: text/plain
submitter: rmaris
assignee: damonc
closer: rmaris
closedate: 2004-05-19T12:36:48
comment:
  BWidget V1.7 has very minor changes in the place proc 
  of utils.tcl (compared to V1.6).
  child windows will not display on top or to the left side of 
  the parent window. Probably coordinates run out of a 
  valid range.

  When I substitute the old place procedure within the 
  new utils.tcl, all works well.

  NOTE: the Activestate 8.4.5 distribution contails 
  BWidget V1.7, but the subdirectory under "lib" is still 
  named "bwidget1.6".


tkt_uuid: 893259ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: tcllib: request for new module
priority: 8
foundin: None
title: Add simple plotting and charting package
cmimetype: text/plain
submitter: arjenmarkus
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-04-23T20:18:12
comment:
  I have written a simple package for drawing plots and
  charts:
  - xy-plots
  - piecharts
  - barcharts
  - polar plots

  (I would like to add some simple 3D presentations too)

  It is still very much in its infancy, but I include
  the source nonetheless for early comments and
  suggestions.

  The basic design criterium was:

  Provide an easy-to-use package. It may not be as
  flexible as some others, but by offering lots of
  different chart types it should be worth looking
  into.


tkt_uuid: 893516ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: mime
priority: 5 Medium
foundin: None
title: flush error when large "quoted-printable"
cmimetype: text/plain
submitter: nobody
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-10T16:39:04
comment:
  I get a "400: error flushing "sock336": invalid argument" 
  when doing the following with a body larger than 4096 
  buffersize:

  set token [mime::initialize -canonical text/plain \
          -string $body]
  smtp::sendmessage $token -header [list Subject \
          $subject] -header [list From $sender] \
          -header [list To $recipient] -servers $email_server
  mime::finalize $token

  In the "string" arm of the ::mime::copymessageaux proc, 
  I noticed that the blocksize is computed but never 
  fconfigured. 

  The issue is resolved if I add "fconfigure $channel -
  buffersize $blocksize" after the blocksize computation 
  and before the "puts $channel [$converter -mode 
  encode -- $state(string)]" (approx. line 1687 of 
  mime.tcl).

  Thanks for including this fix in the next release,
  Todd Copeland
  todd.copeland@pervasive.com


tkt_uuid: 898067ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 5 Medium
foundin: None
title: ftp::NList error when directory empty
cmimetype: text/plain
submitter: cdclercq
assignee: gwlester
closer: andreas_kupries
closedate: 2004-02-26T01:13:43
comment:
  When executing ftp::NList on an empty directory
  follwing error message appears
  "error     error | E: Error getting directory listing!"

  The manual says:
  This command has the same behavior as the ::ftp::List 
  command, ...

  Ths ftp::List command does not show an error on emty
  dirs ...

  This a non-blocking message ...

  Regards,

  Christophe De Clercq


tkt_uuid: 898774ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: html
priority: 5 Medium
foundin: None
title: html - documentation for checkSet incomplete
cmimetype: text/plain
submitter: mic42
assignee: welch
closer: andreas_kupries
closedate: 2004-09-29T19:07:51
comment:
  The docs for ::html::checkSet do not document the
  arguments key and sep.

  Diff included.

  Index: html.man
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/modules/html/html.man,v
  retrieving revision 1.6
  diff -u -b -r1.6 html.man
  --- html.man    11 Apr 2003 18:27:10 -0000      1.6
  +++ html.man    17 Feb 2004 14:47:22 -0000
  @@ -50,8 +50,8 @@

   Generate a set of CHECKBOX form elements and
  associated labels.  The
   [arg list] should contain an alternating list of
  labels and values.
  -This uses [cmd ::html::checkbox].
  -
  +This uses [cmd ::html::checkbox]. All the CHECKBOX
  buttons share the same
  +[arg key] for their name. The [arg sep] is text used
  to separate the elements.

   [call [cmd ::html::checkValue] [arg name] [opt [arg
  value]]]


tkt_uuid: 899152ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: None
priority: 5 Medium
foundin: None
title: installer should [package require Tcl 8]
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-03-02T04:24:47
comment:
  By mistake I tried to install using
  Tcl 7.6.  Led to some surprising
  suggestions for install locations.

  Probably a good idea to
  [package require Tcl 8] early
  in installer.tcl.  The installer
  should not have to support Tcl 7,
  because none of the packages
  to be installed supports Tcl 7.


tkt_uuid: 899204ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: inifile
priority: 5 Medium
foundin: None
title: inifile test suite failures
cmimetype: text/plain
submitter: dgp
assignee: afaupell
closer: andreas_kupries
closedate: 2004-03-07T07:27:10
comment:
  The inifile.test depends on the
  file test.ini being writable. 
  However, in the official tcllib
  release, that file is read-only,
  causing the tests to fail.
  Is writability really needed?
  If not, the test should be modified
  to use mode r, instead of r+.

  Also, as written, tests
  inifile-1.2 through initfile-1.14
  depend on inifile-1.1 having
  run successfully.  This kind
  of inter-test dependency should
  be removed, since -skip options,
  etc. to tcltest mean there's no
  guarantee what tests will actually
  run.


tkt_uuid: 899207ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: snit
priority: 5 Medium
foundin: None
title: snit test failures
cmimetype: text/plain
submitter: dgp
assignee: duquette
closer: duquette
closedate: 2004-07-27T17:32:04
comment:
  In the tcllib 1.6 release,
  with Tcl/Tk 8.4.6 on Solaris 9:

  - snit 0.93

  ==== install-2.2 Delegate option * for a shadowed
  option.  Foreground is declared
      as a non-delegated option, hence it will pick up
  the option database
      default.  -foreground is not included in the
  "delegate option *", so
      the text widget's -foreground option will not be
  set from the
      option database. FAILED
  ==== Contents of test case:

      cleanup

      widget myframe {
          option -foreground white
          delegate option * to text

          typeconstructor {
              option add *Myframe.foreground red
          }

          constructor {args} {
              install text using text $win.text
          }

          method getit {} {
              $text cget -foreground
          }
      }

      myframe .frm
      set a [.frm cget -foreground]
      set b [.frm getit]
      destroy .frm
      tkbide

      list $a $b

  ---- Result was:
  red #000000000000
  ---- Result should have been (exact matching):
  red Black
  ==== install-2.2 FAILED


  ==== widgetclass-1.6 implicit widgetclass applied to
  hull FAILED
  ==== Contents of test case:

      cleanup

      widget dog { 
          typeconstructor {
              option add *Dog.background green widgetDefault
          }

          method background {} {
              $hull cget -background
          }
      }

      dog .dog
      
      set bg [.dog background]

      destroy .dog
      
      set bg

  ---- Result was:
  #FF00D6009000
  ---- Result should have been (exact matching):
  green
  ==== widgetclass-1.6 FAILED


  ==== widgetclass-1.7 explicit widgetclass applied to
  hull FAILED
  ==== Contents of test case:

      cleanup

      widget dog { 
          widgetclass DogWidget

          typeconstructor {
              option add *DogWidget.background green
  widgetDefault
          }

          method background {} {
              $hull cget -background
          }
      }

      dog .dog
      
      set bg [.dog background]

      destroy .dog
      
      set bg

  ---- Result was:
  #FF00D6009000
  ---- Result should have been (exact matching):
  green
  ==== widgetclass-1.7 FAILED


tkt_uuid: 899211ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: ntp
priority: 9 Immediate
foundin: None
title: time-1.3 fails on 64-bit
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2005-08-26T18:00:15
comment:
  ==== time-1.3 time::unixtime FAILED
  ==== Contents of test case:

      global token
      list [catch {
          set t [time::unixtime $token]
          expr {(0 <= $t) && ($t <= 2147483647)}
      } m] $m

  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  0 1
  ==== time-1.3 FAILED


  This appears to test that the result
  of [time::unixtime] is a positive 32-bit
  signed integer?

  Should it be so on a 64-bit system?
  Maybe this is just testing the wrong thing?


tkt_uuid: 899225ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: pop3
priority: 5 Medium
foundin: None
title: tests pop3-6.* hang
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2005-09-27T16:23:27
comment:
  The [setupServer] command hangs
  in tests pop3-6.0 and pop3-6.1 when
  running the pop3 tests.  The hangs
  trace to the [vwait] command within
  [::subserv::muservSpawn] .

  This is on Linux/Alpha, a 64-bit system.


tkt_uuid: 900041ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: htmlparse
priority: 5 Medium
foundin: None
title: htmlparse does not supprt empty elements
cmimetype: text/plain
submitter: nobody
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-09-29T18:19:18
comment:
  htmlparse 1.3 (as well as 2.0) does not support
  empty elements of the form:

  <e ... />

  I think this is supported in the HTML standard.

  e.g.
  <list name="List1" />
  <list name="List2" />
  results in
     list {} {name="List1"} {}
     list {} {name="List2"} {}
  rather than
     list {} {name="List1"} {}
     list {/} {} {}
     list {} {name="List2"} {}
     list {/} {} {}

  The first case results in havoc for 2Tree.

  A quick fix is to perform the cmd substitutions in
  2 passes (a necessary evil?)

  htmlparse 1.3 change (I think the Class code was
  removed in later versions):

  set w " \t\r\n";# white space
  set exp1 <(/?)([CClass ^$w>]+)[CClass $w]*([CClass 
  ^/>]*)>
  set exp2 <(/?)([CClass ^$w>]+)[CClass $w]*([CClass 
  ^/>]*)/>

  set sub1 "\}\n$cmd {\\2} {\\1} {\\3} \{"
  set sub2 [concat $sub1 "\}\n$cmd {\\2} \{/\} \{\} \{"]  

  regsub -all -- $exp1 $html $sub1 html
  regsub -all -- $exp2 $html $sub2 html

  Any comments?

  Tony Grimm
  grimmt@agilent.com


tkt_uuid: 900165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: BWidget progressbar problem
cmimetype: text/plain
submitter: decosterjos
assignee: damonc
closer: dev_null42a
closedate: 2006-02-10T23:07:11
comment:
  Hi, 
   
  The BWidget progressbar fails when using large values. This is 
  the code in version 1.7.0: 
   
  $path.bar coords rect -1 0 [expr {$val*$w/$max}] $h 
   
  Large integer values used for val and max will cause wrapping 
  problems for 32 bit integers. Making the new calculation using 
  doubles will fix the problem: 
   
  $path.bar coords rect -1 0 [expr {double($val)*$w/$max}] $h 
   
   
  Kind regards, 
   
  Jos. 


tkt_uuid: 900178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: ftpd
priority: 5 Medium
foundin: None
title: Incorrect or unclear Response to PASS
cmimetype: text/plain
submitter: nobody
assignee: gwlester
closer: gwlester
closedate: 2004-05-22T19:30:15
comment:
  In proc ::ftpd::command::PASS, the positive response is
  generated as puts $sock "200 OK" (line# 1050). The RFC
  (imo) states, that it should be "230 ...." instead.

  The ftpd-Version is:
  ftpd.tcl,v 1.17 2003/07/05 04:59:35 andreas_kupries

  This behaviour leads to the message
  Unexpected response: OK
  with the widely-used NCFTP-Clients.

  M.Hoffmann@hmk.info 


tkt_uuid: 905132ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Accepted
subsystem: None
priority: 5 Medium
foundin: None
title: time.tcl (version 1.8) fails to catch TCP connection timeout
cmimetype: text/plain
submitter: alathar
assignee: nobody
closer: patthoyts
closedate: 2004-02-26T22:11:12
comment:
  time.tcl fails to catch a timeout on the TCP socket
  connect, though it handles the UDP situation correctly.
   When used in TCP mode, either without the UDP package
  loaded or by specifying -protocol tcp, if there is
  nothing listening on the port of the specified server,
  the program ends with "connection refused".

  Also - this package is MISREPRESENTED. It does NOT
  implement the Network Time Protocol, RFC 1305, port
  123, nor does it claim to. It implements RFC 868, the
  system-independent time protocol, port 37, often
  implemented with other "simple server" protocols, like
  echo, chargen, and so forth (on Unix-derived systems,
  right in inetd). Whoever registered this within the tcl
  offering as NTP didn't do their homework.

  To make matters worse, if you really connect this thing
  to the REAL ntp on port 123, it doesn't recognize the
  fact, and it returns a WRONG VALUE. If I get time, I'll
  see if I can get it to return an error instead of a
  wrong value, but with the early, simple protocols,
  that's not always practical. I will also see how
  difficult it would be to get a value from the REAL NTP,
  though I'm not going to attempt to implement the
  convergence algorithms, just grab the time - though
  that isn't quite what it was intended for.


tkt_uuid: 905906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: des
priority: 5 Medium
foundin: None
title: des: problem wit variable options - variable not set
cmimetype: text/plain
submitter: arjenmarkus
assignee: patthoyts
closer: patthoyts
closedate: 2005-09-02T21:55:10
comment:
  I got an error report while using the DES module in the
  following way:

  DES::des -mode decode -key $passwd $string

  The loop to analyse the arguments ran into the default
  case and produced an error because the options variable
  was not set. 

  The remedy was simple (after inspecting the code):

  DES::des -mode decode -key $passwd -- $string

  The error message should at least:
  - show the list of valid keywords
  - show an indication that perhaps "--" was forgotten


tkt_uuid: 907904ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: None
priority: 8
foundin: None
title: Patches to adjust startup for modules and examples
cmimetype: text/plain
submitter: stwo
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-03T22:22:57
comment:
  These are the patches used in the OpenBSD port of
  Tcllib to adjust the 'exec tclsh' lines of scripts.


tkt_uuid: 909104ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: tclapps :: tkchat
priority: 5 Medium
foundin: None
title: tkchat - interface: can't send errors to /dev/null
cmimetype: text/plain
submitter: dgp
assignee: patthoyts
closer: patthoyts
closedate: 2006-09-15T07:41:59
comment:
  Debug->Error Logging->To File... has trouble setting
  destination to /dev/null

  complains about overwriting an existing file.


tkt_uuid: 911281ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: snit
priority: 5 Medium
foundin: None
title: snit - Optimize for space
cmimetype: text/plain
submitter: andreas_kupries
assignee: duquette
closer: duquette
closedate: 2004-08-08T04:16:30
comment:
  An empty snit::type comes with 37 K of runtime code.
  Optimize the generator ot include only the parts of the
  runtime support which are necessary (i.e. not widget
  stuff for snit:type's, no delegate handling if there
  are no delegates declared, etc.)


tkt_uuid: 911580ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Duplicate
subsystem: mime
priority: 5 Medium
foundin: None
title: clock scan error in ::mime::parsedatetime
cmimetype: text/plain
submitter: nobody
assignee: mrose
closer: andreas_kupries
closedate: 2005-10-04T18:12:52
comment:
  Due to a "clock scan" bug this mime function fails when use german 
  (and probably all other) locales.

  Error message:

  unable to convert date-time string "07 Mär 2004 19:04:52"
      while executing
  "clock scan $gmt"
      ("proper" arm line 3)
      invoked from within
  "switch -- $property {
          hour {
              set value [clock format $clock -format %H]
          }
          lmonth {
              return [clock form..."
      (procedure "::mime::parsedatetime" line ...)

  Simple work around in "proper" arm taht works for me:

          proper {
              set m [lindex {Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov 
  Dec} \
                    [clock format $clock -format "%m"]]
              set gmt [clock format $clock -format "%d $m %Y %H:%M:%S" \
                             -gmt true]
              if {[set diff [expr {($clock-[clock scan $gmt])/60}]] < 0} {
                  set s -
                  set diff [expr {-($diff)}]
              } else {
                  set s +
              }
              set zone [format %s%02d%02d $s [expr {$diff/60}] [expr 
  {$diff%60}]]

              return [clock format $clock \ 
                            -format "%a, %d %b %Y %H:%M:%S $zone"]
          }


  Best regards,
  Christoph


tkt_uuid: 913149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: log
priority: 7 High
foundin: None
title: log package should not start log by default
cmimetype: text/plain
submitter: hobbs
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-04-23T19:57:29
comment:
  merely requiring the log package and using the
  statements cause logging to occur.  I think there
  should be distinct individual commands between
  declaring the *use* of the log package and actually
  wanting logging to occur.

  At a minimum, logging levels debug to warning should
  not log by default.


tkt_uuid: 914279ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: crc
priority: 5 Medium
foundin: None
title: crc::crc32 and Trf
cmimetype: text/plain
submitter: miketm
assignee: patthoyts
closer: patthoyts
closedate: 2004-03-31T23:01:59
comment:
  When Trf is installed the data starting with the dash ('-') 
  lead to an error and end of otions option (--) doesn't work 
  either Examples: 
   
  set value "-hello world" 
   
  set x [ ::crc::crc32 $value ]  
   
  produces: 
   
  Error in startup script: bad option -hello world: must be 
  -filename, -format, -implementation or -seed 
      while executing 
  "::crc::crc32 $value " 
   
  set x [ ::crc::crc32 -- $value ]  
   
  produces: 
   
  Error in startup script: crc-zlib: wrong # args, all options 
  require an argument 
      while executing 
  "crc-zlib $s" 
      (procedure "crc::Crc32_trf" line 11) 
      invoked from within 
  "$impl [lindex $args 0] $seed" 
      (procedure "::crc::crc32" line 53) 
      invoked from within 
  "::crc::crc32 -- $value " 
   
  Changing line 167 in crc32.tcl (tcllib-1.6) from 
  binary scan [crc-zlib $s] i r 
  to 
  binary scan [crc-zlib -- $s] i r 
   
  solves the problem 
   
   


tkt_uuid: 914488ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: ftp
priority: 5 Medium
foundin: None
title: Transfer rate should be under VERBOSE or DEBUG control
cmimetype: text/plain
submitter: thorson
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-04-23T20:16:36
comment:
  This message:

    $ftp(Total) bytes sent in $elapsed seconds ($persec
  Bytes/s)

  in function ::ftp::ElapsedTime 

  is displayed as a debug message no matter what the
  value of ftp::DEBUG or ftp::VERBOSE.   I believe it
  should not be logged at all unless either of those
  flags are set to true.


tkt_uuid: 916160ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: struct :: tree
priority: 7 High
foundin: None
title: Add a prune operation to the tree walk command
cmimetype: text/plain
submitter: btheado
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-08-15T03:35:31
comment:
  In version 2.0, struct::tree added handling for walk
  scripts to execute [break], [continue], and [return]. 
  A call to [break] or [return] will halt the walk
  altogether.  A call to [continue] allows the remainder
  of the walk script to be bypassed for a given iteration
  and doesn't modify which nodes are visited.  

  It would be nice to also have a prune command available
  that would alter the walk such that for a dfs, for
  instance, the walk would go no deeper than the node for
  which the prune is invoked.

  One way to implement this is as follows:

  Add the following arm to the [switch -exact -- $code]
  call in the function ::struct::tree::WalkCall:

      5 {
          # Force the rest of the current while loop
  iteration in 
          # the caller to be skipped, resulting in a
  "prune" effect
          return -code continue
      }

  And add the following function:

  #
  # For use within a walk call.  Stops the descent on the 
  # current node but continues walking the rest of the 
  # nodes for a dfs search
  #
  proc ::struct::prune {} {
      return -code 5
  }

  Here is a test that illustrates the operation:

  test tree-4.4.18 {prune in dfs walk} {
      tree mytree
      set t [list ]
      mytree insert root end 0 1 2
      mytree insert 0 end a b c
      mytree insert b end I II III
      lappend t ==
      mytree walk root {a n} {
  if {[string equal $n "b"]} {
              lappend t .

              # Skip the I, II, and III nodes
              ::struct::prune
          }
  lappend t $a $n
      }
      lappend t ==
      mytree destroy
      set t
  } {== enter root enter 0 enter a . enter c enter 1
  enter 2 ==}


tkt_uuid: 916668ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: cmdline
priority: 5 Medium
foundin: None
title: getoptions: handling of booleans undocumented
cmimetype: text/plain
submitter: onde
assignee: andreas_kupries
closer: sf-robot
closedate: 2005-10-11T02:20:24
comment:
  Hi,

  from comp.lang.tcl:

  Why is it that the handling of boolean vars in
  cmdline::getoptions differs from that of other
  "datatypes" or rather that this is not mentioned in the
  docs?

  According to the manpage:
  "...optlist contains a list of lists where each element
  specifies an option in the form: flag default comment...."

  Consider the following example:


  package require cmdline
  set optlist [list {v 1 "be verbose"} \
     {f.arg "index.html" "some usage"}]
  if {[catch {array set params [cmdline::getoptions argv
  $optlist]} res]} {
      puts stderr "$res"
      exit
  }
  # ...process each options


  Invoked with -?:

   -v                   1
                       ^^^
   -f value             some usage <index.html>
   -help                Print this message
   -?                   Print this message


  The only way to avoid this incorrect usage string is
  _not_ to set a default value for booleans.
  I think this should be mentioned in the docs, shouldn't it?

  Regards,
  Andreas


tkt_uuid: 917798ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Invalid
subsystem: bwidget
priority: 5 Medium
foundin: None
title: No redraw during scrolling
cmimetype: text/plain
submitter: germinator2000
assignee: damonc
closer: damonc
closedate: 2004-03-22T17:41:46
comment:
  I'm on Mac OS 10.3.3 , TCL-TK 8.4.6 with BWdiget 1.70 and TKAqua

  package require BWidget
  proc test_scroll {} {
  toplevel .test
  ScrolledWindow .test.sc
  ScrollableFrame .test.sc.f
  .test.sc setwidget .test.sc.f
  set path [.test.sc.f getframe]

  for {set i 0} {$i < 20 } {incr i} {
  checkbutton $path.b$i -text "Probando probando" -variable 
  prueba
  checkbutton $path.c$i -text "HOLY HOLY" -variable prueba
  pack $path.b$i -side top
  pack $path.c$i -side top

  }
  pack .test.sc
  }

  With this script, when I scroll, the content into the frame is not 
  redraw. The content of the frame is not updated until I stop 
  scrolling.
  Do you know how can I fix that? 


tkt_uuid: 917877ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: bwidget
priority: 5 Medium
foundin: None
title: Add state readonly for Entry (and LabelEntry)
cmimetype: text/plain
submitter: mbroeken
assignee: damonc
comment:
  The Entry and LabelEntry widgets don't support the
  readonly-state like entry in pure Tk. This state is a
  perfect mix between normal and disabled because it can
  handle user events without changing its value.


tkt_uuid: 918099ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: smtp
priority: 7 High
foundin: None
title: SMTP AUTH support (RFC 2554)
cmimetype: text/plain
submitter: patthoyts
assignee: patthoyts
closer: patthoyts
closedate: 2004-03-18T11:08:27
comment:
  This patch adds support for the SMTP AUTH extension
  (RFC 2554). Currently this only deals with the LOGIN
  authentication mechanism but additional support for
  CRAM-MD5 and DIGEST-MD5 is planned.


tkt_uuid: 920974ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: nntp
priority: 5 Medium
foundin: None
title: Add support for async requests to nntp
cmimetype: text/plain
submitter: tallniel
assignee: nobody
comment:
  The NNTP package doesn't currently support asynchronous 
  requests. As NNTP commands may take a long time to run, it 
  would be useful to be able to do these asynchronously. The ability 
  to get a progress callback would also be useful (similar to the http 
  package).


tkt_uuid: 922877ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: bwidget PasswdDlg - honour labelwidth and fix return binding
cmimetype: text/plain
submitter: stevel
assignee: damonc
closer: dev_null42a
closedate: 2006-09-27T03:31:34
comment:
  Fixes the BWidget PasswdDlg widget so that it doesn't ignore the 
  -labelwidth option when calculating the label width.

  Also reinstalled the Return binding so that return now moves through 
  the widgets rather than always selecting OK (i.e. more like the 
  behaviour of various login managers on Windows, Unix)


tkt_uuid: 923055ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: ftpd
priority: 5 Medium
foundin: None
title: Generic arg processing is bogus, trips on spaces in paths
cmimetype: text/plain
submitter: nobody
assignee: gwlester
closer: andreas_kupries
closedate: 2007-08-20T20:42:34
comment:
  I've adapted the /tcl/demos/Tcllib/ftpd/ftpd.test -
  script to a full-functional ftp-daemon, especially
  using a modified proc like

  proc fakefs {cmd path args} {
      # Use the standard unix fs, i.e.
  "::ftpd::fsFile::fs", but rewrite the incoming path
      # to stay in the /tmp directory.

      set path [file join / tmp [file tail $path]]
      eval [linsert $args 0 ::ftpd::fsFile::fs $cmd $path]
  } 

  if transferring files with blanks in the filename, the
  $path-variable in fakefs() already holds an incorrect
  value: the cutted filename up until the first blank!

  I've been looking around the ftpd.tcl code, but someone
  with deeper knowledge of the program-logic there is
  required!

  I think this has something to do with the use of EVAL
  somewhere, because EVAL removes one level of grouping
  (so surrounding the destination-spec with "" doesn't
  solve the problem!).

  I haven't found a simple workaround yet.

  mailto:M.Hoffmann@hmk.info


tkt_uuid: 923942ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Rejected
subsystem: bwidget
priority: 5 Medium
foundin: None
title: BWidget dynamic help problem
cmimetype: text/plain
submitter: decosterjos
assignee: damonc
closer: oehhar
closedate: 2009-07-01T07:53:54
comment:
  Hi, 
   
  When using the BWidget DynamicHelp to add balloon tips to an 
  application, the balloons are only removed from the screen when 
  you move the mouse pointer out of the widget the balloon was 
  registered for. You can move the mouse inside the widget without 
  the balloon being removed. Use this test script to see the desired 
  effect: 
   
  package require BWidget 
   
  text .t 
  pack .t 
  DynamicHelp::register .t balloon "Testing dynamic help" 
   
   
  Hold the mouse pointer inside the text widget and the balloon help 
  will show. Now move the mouse pointer inside the text widget. The 
  balloon won't disappear. 
   
   
  The balloon help should also be removed when moving the mouse 
  cursor inside the widget the balloon was registered for. To obtain 
  this, replace the 
   
   DynamicHelp::_motion_balloon 
   
  function by the attached one. 
   
  Kind regards, 
   
  Jos. 
   


tkt_uuid: 928995ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Duplicate
subsystem: inifile
priority: 5 Medium
foundin: None
title: modules/inifile/test.ini ships read-only
cmimetype: text/plain
submitter: kot
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-04T19:13:02
comment:
  The file is extracted read-only, but the test script tries to open it 
  read-write (default). 
   
  I think, the default should change to read-only. chmod-ing the 
  file after extraction provides a workaround for the FreeBSD port. 
   


tkt_uuid: 929727ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Invalid
subsystem: bwidget
priority: 5 Medium
foundin: None
title: BWidget notebook page name bug
cmimetype: text/plain
submitter: nobody
assignee: damonc
closer: hobbs
closedate: 2004-09-14T21:34:42
comment:
  BWidget notebook page name retrieval uses wrong index.
  Here is the diff that I made:

  diff notebook.tcl BWidget-1.7.0/notebook.tcl 
  336c336
  <       append script " \[NoteBook::_get_page_name [list $path] current 1\]"
  ---
  >       append script " \[NoteBook::_get_page_name [list $path] current 2\]"


tkt_uuid: 930101ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: mime
priority: 5 Medium
foundin: None
title: Help with Tcllib MIME
cmimetype: text/plain
submitter: vijbulusu
assignee: mrose
closer: patthoyts
closedate: 2004-06-24T14:35:23
comment:
  Can anyone help me out with the following problem? I am 
  using Tcllib 1.0.

  THE CODE

  I am using the following code:
  [mime::initialize -canonical "text/html; charset=US-
  ASCII" -string $body]
  [mime::setheader $message Subject $subject]
  [smtp::sendmessage $message -originator $fromemail -
  recipients $toemail -servers $emailserver -ports 
  $emailport]
  [mime::finalize $message]

  THE ERROR

  When I use the variable "old" as described below, I have 
  no problems in sending the email. However, as soon as I 
  start defining attribute values in my HTML such as 
  width=100% (see the variable "new" defined below), I 
  get the following error:

  key message-id not in header

  THE MESSAGE

  [append old "<html><head> "
  append old "<title>eSampleMail</title> "
  append old "<style>"
  append old "</style>"
  append old "</head>"
  append old "<body>"
  append old "<table>"
  append old "<tr><td>We are pleased to 
  provide you with the most recent updates to 
  myserver.com</td></tr>"
  append old "</table>"
  append old "</body>"
  append old "</html>"
  NULL]

  [append new "<html><head> "
  append new "<title>eSampleMail</title> "
  append new "<style>"
  append new "</style>"
  append new "</head>"
  append new "<body>"
  append new "<table width=100%>"
  append new "<tr><td>We are pleased to 
  provide you with the most recent updates to 
  myserver.com</td></tr>"
  append new "</table>"
  append new "</body>"
  append new "</html>"
  NULL]


  Please help.


tkt_uuid: 932029ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: Cannot have space in pathname of combobox (FIX SUPPLIED)
cmimetype: text/plain
submitter: jaspert
assignee: damonc
closer: hobbs
closedate: 2004-04-21T21:44:17
comment:
  An error occurs if you try to create a combobox with a
  space in its pathname

  Here are the changes I made to get it working, please
  patch the next release, they look fairly harmless...

  $ diff BWidget-1.7.0/entry.tcl entry.tcl
  140c140
  <       "return \[Entry::_path_command $path \$cmd
  \$args\]"
  ---
  >       "return \[Entry::_path_command [list $path]
  \$cmd \$args\]"
  159c159
  <     foreach $vars [eval Widget::hasChangedX $path
  $opts] { break }
  ---
  >     foreach $vars [eval {Widget::hasChangedX $path}
  $opts] { break }
  $ diff BWidget-1.7.0/arrow.tcl arrow.tcl
  90c90
  <     eval canvas $path.c $submaps(.c)
  ---
  >     eval {canvas $path.c} $submaps(.c)

  Cheers


tkt_uuid: 932437ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: dns
priority: 5 Medium
foundin: None
title: dns::error not compatible with prodebug
cmimetype: text/plain
submitter: nobody
assignee: patthoyts
closer: patthoyts
closedate: 2004-04-13T10:46:00
comment:
  eventhough [error] is in the dns namespace, prodebug 
  doesn't like it.  Please rename it to something other than 
  a reserved name.


tkt_uuid: 932516ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: html
priority: 5 Medium
foundin: None
title: html - many procedures not compatible with prodebug
cmimetype: text/plain
submitter: nobody
assignee: welch
comment:
  prodebug complains about the following:

  html::foreach
  html::for
  html::while
  html::if
  html::set
  html::eval


tkt_uuid: 934134ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: smtpd
priority: 7 High
foundin: None
title: SMTPD GMT offset calculation incorrect
cmimetype: text/plain
submitter: patthoyts
assignee: patthoyts
closer: patthoyts
closedate: 2004-06-18T01:26:32
comment:
  Package smtpd, proc gmtoffset produces incorrect output
  (sign inverted) when calculating GMT offset. For
  example, it returns
    Sun, 11 Apr 2004 08:14:06 +0500
  for CDT. When it should return
    Sun, 11 Apr 2004 08:14:06 -0500

  The bug is at line 354 of $Id: smtpd.tcl,v 1.12
  2004/01/15 06:36:14 andreas_kupries Exp $

  Which is

          set off [expr {$zh - $lh}]

  but apparently should be

          set off [expr {$lh - $zh}]

  Raised by Bob Binder (rbinder aT rbsc dot com)


tkt_uuid: 934702ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: tcllib: request for new module
priority: 5 Medium
foundin: None
title: Add a XML parsing module to tcllib
cmimetype: text/plain
submitter: mic42
assignee: nobody
comment:
  As there is no XML parsing module in either the tcl
  core distro nor the Tcllib yet, there is a large class
  of modules not really nicely includeable into tcllib
  (nearly everything xml related). 

  A Tcllib XML parsing module would be really nice,
  especially if linked to a DOM module using the
  ::struct::tree (not super efficient but standard). 

  Candidates would be the TclXML package from the tclxml
  project or a new development. 

  A new development could unify the two most used C
  extensions in the area (TclXML and tDOM).


tkt_uuid: 936064ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: uri
priority: 5 Medium
foundin: None
title: password:user@host.com not parsed
cmimetype: text/plain
submitter: mic42
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-03T20:19:37
comment:
  URI does not handle RFC2396 mentioned http style with
  user:password included:

  % uri::split http://foo:bar@baz.com:80/bla/
  port {} path :bar@baz.tcl:80/ scheme http host foo query {}

  Regexps get it wrong...

  Michael


tkt_uuid: 939532ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: exif
priority: 5 Medium
foundin: None
title: exif read fails when subIFD has unknown tag
cmimetype: text/plain
submitter: pascalscheffers
assignee: andreas_kupries
closer: afaupell
closedate: 2009-02-19T05:39:40
comment:
  The if/elseif/else for tag recognition in 
  proc ::exif::exifSubIFD ends with 'error "unknown 
  tag ..."'.

  I highly doubt the author intended this, as this renders 
  the exif unusable whenever a camera manufacturer adds 
  a new exif tag. 

  My suggestion: change 'error' to 'debug'. 


tkt_uuid: 940375ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Duplicate
subsystem: None
priority: 5 Medium
foundin: None
title: tcllib 1.6 install error due to doc. generation bug
cmimetype: text/plain
submitter: rcalmbac
assignee: nobody
closer: andreas_kupries
closedate: 2004-04-22T22:09:28
comment:
  There is a problem generating the nroff documentation,
  which causes the installation of tcllib 1.6 to fail.

  In detail: When selecting the "Doc. Nroff" checkbox in
  the installer GUI, keeping "Simulate installation" off,
  and clicking on "Install", I get this output and error
  message:

  <47 triton->tcllib-1.6> wish installer.tcl 
  Installing Tcllib 1.6
  You have chosen the following configuration ...

  Packages:      install/lib/tcllib1.6
  Examples:      install/bin/tcllib_examples1.6
  Documentation:

          NROFF:  install/man/mann
          HTML:   install/lib/tcllib1.6/tcllib_doc

  Error in startup script: @--> invalid command name "option"
      while executing
  "::doctools::_format dt {[comment {-*- tcl -*- doctools
  manpage}]
  [comment { $Id: s.multiplexer.man 1.4 04/02/10
  23:36:58-08:00 tcl@bluepeak.home $ }]
  ..."
      ("eval" body line 1)
      invoked from within
  "eval [list ::doctools::_$cmd $name] $args"
      (procedure "::doctools::DoctoolsProc" line 15)
      invoked from within
  "dt format [get_input $f]"
      (procedure "_man" line 17)
      invoked from within
  "_man multiplexer nroff n install/man/mann"
      ("eval" body line 1)
      invoked from within
  "eval $guide($m,$type) $m $args"
      (procedure "xinstall" line 4)
      invoked from within
  "xinstall doc nroff n    $config(doc,nroff,path)"
      (procedure "doinstall" line 18)
      invoked from within
  "doinstall"
      (procedure "main" line 11)
      invoked from within
  "main"
      (file "installer.tcl" line 484)


  My wish shell is v8.4.5. This error happens whether I'm
  on Solaris or on Linux. The error seems to be caused by
  a problem encountered when processing the
  multiplexer.man documentation file. The same error also
  occurs for graph.man and struct_tree.man (both in
  module struct).

  These errors did not occur in tcllib 1.4.

  It would be good to fix this since it is somewhat
  frustrating for users to have the installation fail
  halfway through.

  I am not familiar with doctools or the doctools
  documentation format, but hopefully someone who is can
  identify the source of the problem from these symptoms.


tkt_uuid: 940651ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: csv
priority: 5 Medium
foundin: None
title: error in ::csv::read2matrix
cmimetype: text/plain
submitter: nobody
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-03T19:55:06
comment:
  in csv.tcl (line132)
  has to be a '5' instead a '4'.

  case '4' occures twice!


   switch -exact -- [llength $args] {

  .
  .
  .
  5 { 
      foreach {a b c d e} $args break
              if {![string equal $a "-alternate"]} {
                  return -code error "wrong#args: Should
  be ?-alternate? chan m ?separator? ?expand?"
              }
              set alternate 1

              set chan    $b
              set m       $c
              set sepChar $d
              set expand  $e
          }
  .
  .
  .
  }


tkt_uuid: 943145ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: doctools
priority: 7 High
foundin: None
title: doctools - [namespace] markup request
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-04T22:10:44
comment:
  Please add a [namespace] markup command
  to the doctools format for marking a namespace
  name in the documentation.


tkt_uuid: 943146ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 5 Medium
foundin: None
title: nroff formatting eats backslashes
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-04T18:52:01
comment:
  with [const {\u001A}] in a doctools formatted
  document, the literal backslash gets passed
  through fine, but since \ is an nroff-special
  character, it doesn't appear in the displayed
  documentation.

  Seems the nroff formatting needs to add
  some \-escaping.


tkt_uuid: 943994ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: doctools
priority: 9 Immediate
foundin: None
title: standard doctools target for TEA / Makefile authors
cmimetype: text/plain
submitter: dgp
assignee: andreas_kupries
closer: dgp
closedate: 2004-11-13T00:45:58
comment:
  The doctools package supports processing
  of a nice documentation markup language.

  Any Tcl package author who uses doctools
  markup to create documentation, will need
  a doc: target in his TEA Makefile to produce
  documentation in installable formats like
  nroff and html.  This suggests an application
  built around doctools.

  Candidates are mpexpand and dtp, but neither
  is routinely installed enough for simple use.

  Request that some such app get installed
  routinely when tcllib is installed, and that
  sample doc: target rules be made available,
  perhaps within the TEA sampleextension itself.


tkt_uuid: 944995ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: ncgi
priority: 5 Medium
foundin: None
title: xml content/type
cmimetype: text/plain
submitter: coldstore
assignee: welch
closer: welch
closedate: 2004-05-04T22:31:14
comment:
  Reported as tclhttpd bug '[ 698549 ] direct url getting
  xml content/type' at
  http://sourceforge.net/tracker/index.php?func=detail&aid=698549&group_id=12884&atid=112884

   when using in ie ActiveXObject("Microsoft.XMLHTTP");
  to get xml from a direct_url the is a server 500 error.
  the problem is the content-type:
  Unknown Content-Type: text/xml
  while executing
  "ncgi::nvlist"(procedure "ncgi::parse" line 8)


  this is because ncgi package does not reconize test/xml
  type.
  adding it to ncgi solves the problem:

  proc ncgi::nvlist {} {
  set query [ncgi::query]
  set type [ncgi::type]
  switch -glob -- $type {
  "" -
  application/x-www-form-urlencoded -
  application/x-www-urlencoded -
  text/xml
  {

  I'm handpassing this to you.


tkt_uuid: 946856ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: doctools
priority: 7 High
foundin: None
title: Enhance uri command
cmimetype: text/plain
submitter: apnadkarni
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-04T22:11:56
comment:
  I would like to generate a URL link in the output (html)
  where the displayed text is something other than the 
  link itself. The uri command doesn't seem to allow this. 
  In other words, I want to say

  [uri "http://foo.com" FOO] 

  and have it generate 

  "<a href='http://foo.com'>FOO</a>".


tkt_uuid: 947109ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: font selection dialog up/down bindings
cmimetype: text/plain
submitter: wilkason
assignee: damonc
closer: dev_null42a
closedate: 2006-09-27T03:31:23
comment:
  The listbox used to select the font should have the 
  following bindings added such that when the up/down 
  cursor keys are used in the listbox, the sample font is 
  shown in the sample area.

  In SelectFont::create procedure, add

          bind $lbf <Up>    $script
          bind $lbf <Down>   $script

  after existing bindings

          bind $lbf <ButtonRelease-1> $script
          bind $lbf <space>           $script
          bind $lbf <1>               [list focus %W]


tkt_uuid: 948063ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: MenuFrame: no 'getmenustate' method
cmimetype: text/plain
submitter: pointsman
assignee: damonc
closer: oehhar
closedate: 2009-07-01T07:43:32
comment:
  Apparently, there is not way, to query the state of a
  menu tag.

  The state of menu tags could be set with:

  $mainframe setmenustate tag state

  I would be very handy, to be able to query the state of
  a tag. Something like a getmenustate method with syntax
  like

  $mainframe getmenustate tag

  returning the state. Or enhanced setmenustate syntax

  $mainframe setmenustate tag ?state?

  If the optional new state is omitted, then the current
  state of the tag is returned. (And emtpy string for not
  knows tags? Or error? Curently,  setmenustate simply
  ignores unknown tags - which shuld be mentioned in the
  documentation.)

  The current setmenustate implementation in
  mainframe.tcl still includes the old tag state
  mechanism commented out. I agree, that the current
  state system is better. Shouldn't this code be removed?

  The documentation should mention at one place, that
  only state "disabled" disables the tag and that every
  other state enables it.


tkt_uuid: 948273ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: log
priority: 5 Medium
foundin: None
title: logger::services returns "services", not $services
cmimetype: text/plain
submitter: nobody
assignee: mic42
closer: mic42
closedate: 2004-05-25T17:45:13
comment:
  I believe the code in the logger::services

  proc ::logger::services {} {
      variable services
      return services
  }
                                                        
                                                        
                       
  should return $services, not "services"


  regards
  Jouni.Ryno@fmi.fi


tkt_uuid: 949049ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Invalid
subsystem: bwidget
priority: 5 Medium
foundin: None
title: Combobox error : unknown option "-label"
cmimetype: text/plain
submitter: nobody
assignee: damonc
closer: hobbs
closedate: 2004-05-06T16:22:36
comment:
  Error in startup script: unknown option "-label"
      while executing
  "error "unknown option \"$option\"""
      (procedure "Widget::parseArgs" line 7)
      invoked from within
  "Widget::parseArgs ComboBox $args"
      (procedure "ComboBox::create" line 3)
      invoked from within
  "ComboBox $parent.mscCombo -label "MSC"  -labelwidth 
  5 -labelanchor w  -textvariable save::mscNo  -values { 
  apollo athena mscE mscS }  -width 8  -helpt..."
      (procedure "_MscCell" line 7)
      invoked from within
  "_MscCell  [$mscCellFrame getframe]"
      (procedure "save::create" line 11)
      invoked from within
  "save::create $notebook"
      invoked from within
  "set f0  [save::create $notebook]"


tkt_uuid: 951568ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: smtp
priority: 9 Immediate
foundin: None
title: Problems sending long messages.
cmimetype: text/plain
submitter: patthoyts
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-13T07:02:21
comment:
  From Peter Campbell on comp.lang.tcl
  Message-ID: <DSSnc.1164$FN.128726@news02.tsnz.net>

  I have done some more debugging and found the problem
  to be with the "Trf"
  package, an incompatibility. The transform function of
  the "trf" package
  sends back a command "query/ratio" which the
  "smtp::wdata" function does not
  know - this returns the error.

  I included some debugging information in the mime
  package to delve deeper
  into the code and find the original error messages,
  rather than the message
  as reported by the application.

  By editing "smtp.tcl" and removing the usage of Trf the
  sending of the email
  works.
  ie: remove the trf line at the top, so create our own
  transform procedure.
  smtp.tcl; line 37:
  if {[catch {package require Trf  2.0}]} {
      # Trf is not available, but we can live without it
  as long as the
      # transform and unstack procs are defined.

      # Warning!
      # This is a fragile emulation of the more general
  calling sequence
      # that appears to work with this code here.

      proc transform {args} {
   upvar state mystate
   set mystate(size) 1
      }
      proc unstack {channel} {
          # do nothing
          return
      }
      set ::smtp::trf 0
  }

  The following is the output from my debugging:



  The following is the output from my debugging:

  (Desktop) 11 % smtp::sendmessage $multiT -servers [list
  {localhost}] -debug
  1 \
  >  -header [list From "<pc@acs.co.nz>"] \
  >  -header [list To pc@acs.co.nz] \
  >  -header [list Subject "Invoice TEST"]
  Trying localhost...
  <-- 220 hermes.acs.co.nz ESMTP Sendmail 8.11.6/8.11.6;
  Tue, 11 May 2004
  09:39:31 +1200
  --> EHLO localhost (wait upto 300 seconds)
  <-- 250-hermes.acs.co.nz Hello dhcp67.acs.co.nz
  [192.168.100.67], pleased to
  meet you
  <-- 250-ENHANCEDSTATUSCODES
  <-- 250-8BITMIME
  <-- 250-SIZE
  <-- 250-DSN
  <-- 250-ONEX
  <-- 250-ETRN
  <-- 250-XUSR
  <-- 250 HELP
  --> ONEX (wait upto 300 seconds)
  <-- 250 2.0.0 Only one transaction
  --> MAIL FROM:<pc@acs.co.nz> (wait upto 600 seconds)
  <-- 250 2.1.0 <pc@acs.co.nz>... Sender ok
  --> RCPT TO:<pc@acs.co.nz> (wait upto 3600 seconds)
  <-- 250 2.1.5 <pc@acs.co.nz>... Recipient ok
  --> DATA (wait upto 300 seconds)
  <-- 354 Enter mail, end with "." on a line by itself
  result =
  ecode = NONE
  einfo = Unknown command "query/ratio"
      while executing
  "error "Unknown command \"$command\"""
      ("default" arm line 2)
      invoked from within
  "switch -- $command {
   create/read
       -
          create/write
              -
          clear/write
              -
          delete/write {
              set s..."
      (procedure "::smtp::wdata" line 6)
      invoked from within
  "::smtp::wdata ::smtp::1 query/ratio {}"


  I am sure the correct way to solve this problem is to
  update the
  "smtp::wdata" procedure to handle the "query/ratio"
  command (and any others
  that the Trf package provides).

  Plus enhance the flow of error messages within the
  mime/smtp package so the
  original error information is not lost.


tkt_uuid: 952391ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: math
priority: 5 Medium
foundin: None
title: Add new optimisation and statistics procedures
cmimetype: text/plain
submitter: arjenmarkus
assignee: nobody
closer: arjenmarkus
closedate: 2005-10-04T06:54:05
comment:
  The work by myself and others as published on the Wiki
  should be added to the math module:
  - Optimisation procedures
  - Interpolation techniques
  - Cluster analysis
  - Discrete and Fast Fourier Transform
  - Linear regression (not on the Wiki yet)
  - Complex numbers 

  The work involved:
  - Clean up the code
  - Define clear test cases
  - Write up the documentation

  NOTE: This is just a reminder for myself, as I am 
  willing to prepare the addition.


tkt_uuid: 953075ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Invalid
subsystem: bwidget
priority: 5 Medium
foundin: None
title: ScrolleableFrame packs weird
cmimetype: text/plain
submitter: nobody
assignee: hobbs
closer: hobbs
closedate: 2004-09-14T20:50:04
comment:
  The BWidget demo displays so wrong behaviour.
  In the ScrolleableFrame it packs 20 entry fields
  and packs them with -fill both and -expand yes.

  However its seems like the expand tag is lost
  somewhere.


tkt_uuid: 953854ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: htmlparse
priority: 1 Zero
foundin: None
title: Errors when parsing HTML to a tree
cmimetype: text/plain
submitter: nobody
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2006-01-18T06:15:37
comment:
     Hello,

  In func

  proc ::htmlparse::mapEscapes

  line: return [subst $new]
  should change to:
     return [subst -nobackslashes -novariables $new]

  If not, if new has a backslash \, the subs breaks the 
  string (specially noted in paths on Windows)

  -------
  In func

  ::htmlparse::Reorder

  Lines:
      if {
         $sibling == {} ||
         (![string compare $tp [$tree get $sibling type]])
                   } {
                       break
                   }
  Should change to:
         if { $sibling == "" } { break }
         if { [lsearch "h1 h2 h3 h4 h5 h6 p li" [$tree get
                   $sibling type]] != -1 } {
      break
       }

    Second option is less agressive when reordering tags.

    Regards,

    Ramon Ribó
    ramsan@cimne.upc.es


tkt_uuid: 954328ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: mime
priority: 8
foundin: None
title: require md5 then mime, throws error
cmimetype: text/plain
submitter: coldstore
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-05-20T05:46:14
comment:
  From a clean CVS install of tcllib:

  tclsh 
  % package require md5 
  2.0.0 
  % package require mime 
  version conflict for package "md5": have 2.0.0, need 1.0 
  %  

  whereas the opposite order works:

  tclsh 
  % package require mime 
  1.4 
  % package require md5 
  1.4.3 
  %


tkt_uuid: 955187ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 5 Medium
foundin: None
title: Unknown state "<whatever>_sent"
cmimetype: text/plain
submitter: mc_8
assignee: gwlester
comment:
  Most of the time it's Unknown state "type_sent" ... but 
  this time it's pwd_sent .... -shrug-

  --[ Error as follows. ]--

  Unknown state "pwd_sent"
      while executing
  "error "Unknown state \"$ftp(State)\"""
      ("default" arm line 2)
      invoked from within
  "switch -regexp -- $ftp(State) {
          list {
              fileevent $sock readable [list [namespace 
  current]::HandleList $s $sock]
              set ft..."
      (procedure "::ftp::InitDataConn" line 27)
      invoked from within
  "::ftp::InitDataConn 0 sock6 <cut> 56721"


tkt_uuid: 955446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: ftpd
priority: 7 High
foundin: None
title: 227 reply non-recommended - causes failures
cmimetype: text/plain
submitter: royterry
assignee: gwlester
closer: gwlester
closedate: 2004-05-23T18:18:46
comment:
  ftpd.tcl (tcllib1.6) currently sends:
  227 Entering Passive Mode. 192,168,1,100,13,209

  The recommeded standard is
  227 Entering Passive Mode (192,168,1,100,13,209).

  Note the added parens. and the move of period to
  end of string.

  When I made this change my client, a Linux-based ROM-
  disk DVR (Digital Video Recorder) started working. So not
  much chance to change things on client.

  Seems in this case it's just a better idea to 
  exactly match the recommendation rather than
  vary slightly.


tkt_uuid: 955473ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: tclapps :: tkchat
priority: 5 Medium
foundin: None
title: Fatal error: tkchat requires winico
cmimetype: text/plain
submitter: dkf
assignee: patthoyts
closer: patthoyts
closedate: 2004-05-18T11:11:57
comment:
  Tkchat 1.160 requires the Winico extension, which is
  considerably less common than other extensions. This
  stops tkchat from loading (on Windows at least) if that
  extension isn't actually present.

  Please wrap the require of winico in a catch and only
  do the rest of the winico-related initialisation if the
  extension is loaded correctly.


tkt_uuid: 956930ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 7 High
foundin: None
title: Unknown state "pwd_sent"
cmimetype: text/plain
submitter: mc_8
assignee: andreas_kupries
comment:
  Unknown state "pwd_sent"
      while executing
  "error "Unknown state \"$ftp(State)\"""
      ("default" arm line 2)
      invoked from within
  "switch -regexp -- $ftp(State) {
          list {
              fileevent $sock readable [list [namespace 
  current]::HandleList $s $sock]
              set ft..."
      (procedure "::ftp::InitDataConn" line 27)
      invoked from within
  "::ftp::InitDataConn 0 sock6 <<cut>> 48836"


  uname -a
  Linux purehype.net 2.4.22-1.2115.nptl #1 Wed Oct 29 
  15:42:51 EST 2003 i686 i686 i386 GNU/Linux

  % info patchlevel
  8.4.6

  % package require ftp
  2.4.1


tkt_uuid: 957180ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: log
priority: 5 Medium
foundin: None
title: Various bug fixes and enhancements to the logger package
cmimetype: text/plain
submitter: mic42
assignee: mic42
closer: mic42
closedate: 2004-05-25T17:57:39
comment:
  Bugfixes and Enhancements to logger:

  * fixed broken logger::services and added tests
  * implemented ${log}::services and added tests and
  changed docs
  * fixed broken cleanup in ${log}::delete and the testsuite
  * fixed some bad uses of set in namespaces which could
  lead to overwrite of global vars.
    used 'variable' instead of 'set' where appropriate
  * added introspection commands with docs and tests
    ${log}::servicename and logger::servicecmd
  * added introspection to ${log}::logproc with docs and
  tests
  * bumped version No to 0.4
  * added introspection to ${log}::delproc with docs and test


tkt_uuid: 957919ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: uri
priority: 5 Medium
foundin: None
title: uri::split fails on "http://a.b.c/idx?path=/idx"
cmimetype: text/plain
submitter: svogel
assignee: andreas_kupries
comment:
  uri::split "http://a.b.c/idx?path=/idx"
  results in
  path: "idx?path=/idx"
  query: ""

  I think the "/" in the query confuses the regexp 
  in "SplitHttp"

  Fixing:
  variable charN {[a-zA-Z0-9$_.+!*'(,)?:@&=-]}
  to:
  variable charN {[a-zA-Z0-9$_.+!*'(,)?:@/&=-]}
  (Note the "/")
  results in the correct result.

  I'm not quite sure if this does affect other functions?

  I ran the "uri.test" but got 12 failures (before and after 
  my change!).

  I'm using uri 1.1.3 (with tcl 8.4.5 on WindowsXP).


tkt_uuid: 961452ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
foundin: None
title: Plotchart does not handle "missing values"
cmimetype: text/plain
submitter: arjenmarkus
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2006-04-25T12:31:11
comment:
  (Reminder)
  Plotchart currently does not handle missing values
  (empty strings). Adding such a feature is not too
  difficult though


tkt_uuid: 961454ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: tklib: plotchart
priority: 5 Medium
foundin: None
title: Add a date/time axis to the repertoire
cmimetype: text/plain
submitter: arjenmarkus
assignee: arjenmarkus
comment:
  (Reminder)
  Add the ability to show date/times along the x-axis -
  especially useful for timeseries of measurement data 


tkt_uuid: 966696ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: snit
priority: 5 Medium
foundin: None
title: Add introspection for methods
cmimetype: text/plain
submitter: andreas_kupries
assignee: duquette
closer: duquette
closedate: 2004-08-08T04:14:58
comment:
  Today I had a need to introspect a snit object, to find
  which methods it would understand. Found the 'info'
  method, but it had no way to ask for methods. Just
  variables, typevars, options, ...

  So I am asking for a 'info methods', 'info typemethods'.


tkt_uuid: 967906ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: bwidget - Font Chooser Cursor Usage
cmimetype: text/plain
submitter: wilkason
assignee: hobbs
closer: dev_null42a
closedate: 2006-09-28T15:55:32
comment:
  In the font chooser, the listbox cannot be navigated with the cursor key. Adding the bottom two lines to  SelectFont::create corrects this

  bind $lbf <space>           $script
  bind $lbf <1>               [list focus %W]
  +bind $lbf <Up>    $script
  +bind $lbf <Down>   $script


tkt_uuid: 970199ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: bwidget
priority: 5 Medium
foundin: None
title: MessageDlg::create Bug and Fix
cmimetype: text/plain
submitter: nobody
assignee: damonc
closer: dev_null42a
closedate: 2006-09-28T15:48:10
comment:
  BUG:

  The dialog type abortretryignore has no default button.

  In the demo this results in a tcl-error:

  bad -default value "": must be abort, retry, ignore, ok, 
  cancel, no, or yes
      while executing
  "tk_messageBox -icon info -default {} -message 
  {Message for MessageBox} -type abortretryignore -title 
  Information -parent ."
      ("eval" body line 1)
      invoked from within
  "eval [list tk_messageBox] [array get tkMBoxArgs]"
      (procedure "MessageDlg::create" line 81)
      invoked from within

  ... (further is uninteresting)


  FIX:

  add a default button even for type abortretryignore:
  (line 56 and 57 in messagedlg.tcl):

      switch -- $type {
          abortretryignore {set lbut {abort retry ignore}; 
  set defb 0 }

  regards
  Vera


tkt_uuid: 970878ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: html
priority: 5 Medium
foundin: None
title: Ability to add stylesheet
cmimetype: text/plain
submitter: coldstore
assignee: welch
closer: andreas_kupries
closedate: 2006-06-13T22:19:00
comment:
  Something like the following would enable people to add
  stylesheets, which would be a good thing.

  proc ::html::stylesheet {href} {
      variable page
      lappend page(meta) "<link rel='stylesheet'
  type='text/css' href='$href'>"
      return ""
  }


tkt_uuid: 971076ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: tklib: request for new module
priority: 5 Medium
foundin: None
title: snitbutton widget
cmimetype: text/plain
submitter: nobody
assignee: nobody
comment:
  A working snit-port of the itcl-gbuttons-widget. That
  way the wikit-tkGui can also be used on platforms where
  itcl is not available (like MacOS 9). 

  All feature to use it instead of gButton inside a wikit
  as a tkGUI are already supplied in the implementation on:

  http://mini.net/tcl/11794

  regards,
  Detlef Groth

  <dgroth (at) gmx.de>


tkt_uuid: 974034ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Rejected
subsystem: bwidget
priority: 5 Medium
foundin: None
title: ArrowButton attributes insensitive to [option add]
cmimetype: text/plain
submitter: eriklns
assignee: damonc
closer: oehhar
closedate: 2009-07-01T07:07:25
comment:
  The command [option add *ArrowButton.$property 20 100]
  has no effect for at least the properties "width" and
  "height". (While it does have effect for the options
  "background" and "foreground").

  I have been using BWidget 1.7 in combination with
  Tcl/Tk 8.4.6


  Sincerely,

  Erik Leunissen


tkt_uuid: 977354ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Accepted
subsystem: tclapps :: tkchat
priority: 5 Medium
foundin: None
title: cosmetic problem(s) in TkChat about box...
cmimetype: text/plain
submitter: mistachkin
assignee: patthoyts
closer: patthoyts
closedate: 2004-06-23T20:33:53
comment:
  I noticed this a while ago and finally got annoyed 
  enough to fix it.  Patch attached, please commit.


tkt_uuid: 978510ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: tclapps :: tkchat
priority: 5 Medium
foundin: None
title: tkchat should add "package require Tcl 8.4"
cmimetype: text/plain
submitter: willdye
assignee: patthoyts
closer: patthoyts
closedate: 2004-06-23T20:28:35
comment:
  I tried running tkchat.tcl under Tcl 8.3, but it blew
  up because several places in the code require 8.4
  (lsearch switches, etc.).  You might want to add a
  "package require Tcl 8.4".  

  If anyone decides to support 8.3, contact me for a list
  of bugs I encountered.  I managed to get it to at least
  come up and display a few messages with only a few
  changes, but there might be deeper problems I haven't
  encountered yet.

  --willdye ("BobaFudd" on tkchat)


tkt_uuid: 978962ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: tclapps :: tkchat
priority: 7 High
foundin: None
title: tkchat timestamp problems.
cmimetype: text/plain
submitter: patthoyts
assignee: wildcard_25
closer: wildcard_25
closedate: 2005-05-26T12:45:35
comment:
  dkfFor example, too often it gets the tabs wrong (puts
  a zero tab at the start of every line) and odd things
  happen when you have timestams visible but entry/exit
  messages off...
  patthoytsThe main issues I have are that it breaks the
  history download when turned off. If there are hidden
  users then we still get a timestamp. And as dkf has
  said, if you hide the timestamps it doesn't align the
  tab spacing properly.
  dkfIf you turn timestamps on then off again, the
  loaded history ends up correct.
  dkfAnd seems to stay that way thereafter.
  dkfThe other issues are less critical. You just get
  blank lines...


tkt_uuid: 979487ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: bwidget
priority: 5 Medium
foundin: None
title: SelectColor widget locks up on MacOS
cmimetype: text/plain
submitter: ssmedley
assignee: damonc
closer: oehhar
closedate: 2009-07-01T06:59:22
comment:
  Hi,

  The SelectColor widget locks up under Mac OS X. I'm
  using BWidget v1.7.

  If I remove the 3 "update" calls in SelectColor::menu, 
  everything works fine.

  I tried substituting with "update idletasks" but that
  didn't work.

  Email me at ssNO@SPAMaao.gov.au if you need more
  info or patches tested.

  SCoTT. :)


tkt_uuid: 979894ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: smtp
priority: 5 Medium
foundin: None
title: username and password options are missing
cmimetype: text/plain
submitter: orwellian
assignee: mrose
closer: patthoyts
closedate: 2004-07-08T22:58:22
comment:
  One of my web service providers recently started requiring all
  email use SMTP authorization - username/password. POP before
  SMTP was no longer good enough due to spammers.

  In the latest TCLLIB 1.6.1 there are username/password options
  in the smtp package for smtp::sendmessage invocations.

  Well, in the documentation. Not the code.

  I could really use to have these options available - TCLLIB can't
  send mail anymore without them, for me.

  ----

  I'm sourcing these TCLLIB 1.6.1 modules:

     base64.tcl,  md5.tcl, mime.tcl, smtp.tcl

  I uploaded those modules to source them because the hosting
  sit has an older TCLLIB installed.

  ----

  The MIME module gave me this error:

  can't read "::major": no such variable
      while executing
  "if {$::major < 2} {

  I altered the other two references to $::major from $major
  to get around this error.


tkt_uuid: 981545ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Accepted
subsystem: bwidget
priority: 5 Medium
foundin: None
title: better -exportselection behavior
cmimetype: text/plain
submitter: hobbs
assignee: damonc
closer: oehhar
closedate: 2009-06-11T09:18:43
comment:
  The following patch was sent to me as a recommendation
  for better behavior on unix.  It looks OK to me, but
  someone should double-check that it doesn't look too
  funky on unix (where is has more noticeable effect):

  I tried to turn off the -exportselection option for the
  ComboBox.  The result was the entry text was still
  selected, but now it did not deselect even if other
  places in the app grabbed the selection.  There appear
  to be now way to get rid of the selection after this.

  The following patch to ActiveTcl fixes this problem.

  --- lib/bwidget1.7/combobox.tcl.dist2004-05-26
  09:23:49.000000000 +0200
  +++ lib/bwidget1.7/combobox.tcl2004-05-26
  09:34:08.000000000 +0200
  @@ -599,7 +599,9 @@
           }
       }
       $path.e selection clear
  -    $path.e selection range 0 end
  +    if {[$path.e cget -exportselection]} {
  +        $path.e selection range 0 end
  +    }
   }


tkt_uuid: 981605ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
resolution: Not Applicable Here
subsystem: calendar
priority: 5 Medium
foundin: None
title: BWidget Calendar Dialog
cmimetype: text/plain
submitter: cmay
assignee: damonc
comment:
  This adds support for a calendar dialog, very similar
  to the iwidget version.  The dialog operates in one of
  two modes: dialog or popup.  The latter is just a
  special case of the former, but returns after one date
  is selected and offers no confirmation or cancellation
  buttons.  An embeddable method that fires virtual
  <<CalendarSelection>> events is on the TODO list.

  Also adds a manual page to the BWman directory, and
  files to the demo directory are modified to include the
  calendar as either a separate note book page or as a
  sub frame of the Dialogs page.  I couldn't decide where
  it would fit best.


tkt_uuid: 981764ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: bwidget
priority: 5 Medium
foundin: None
title: label problem in BWidget-1.2.1
cmimetype: text/plain
submitter: joshim
assignee: damonc
closer: hobbs
closedate: 2004-09-14T20:49:15
comment:
  Error in startup script: unknown option "-label"
      while executing
  "error "unknown option \"$option\"""
      (procedure "Widget::parseArgs" line 7)
      invoked from within
  "Widget::parseArgs ComboBox $args"
      (procedure "ComboBox::create" line 3)
      invoked from within
  "ComboBox $parent.mscCombo -label "MSC"  -labelwidth 
  5 -labelanchor w  -textvariable save::mscNo  -values { 
  apollo athena mscE mscS }  -width 8  -helpt..."
      (procedure "_MscCell" line 7)
      invoked from within
  "_MscCell  [$mscCellFrame getframe]"
      (procedure "save::create" line 11)
      invoked from within
  "save::create $notebook"
      invoked from within
  "set f0  [save::create $notebook]"


tkt_uuid: 981771ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: tklib: plotchart
priority: 5 Medium
foundin: None
title: Add radial diagram to the repertoire
cmimetype: text/plain
submitter: arjenmarkus
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2007-06-13T07:05:59
comment:
  Often semi-numerical data (scores on categories) are
  represented in a circular diagram. Each score is a
  point on a spoke of the circle and these scores are
  then connected by lines.

  Such a diagram could be a useful addition to Plotchart
  too.


tkt_uuid: 983197ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
resolution: None
subsystem: comm
priority: 5 Medium
foundin: None
title: bgerror not getting a chance
cmimetype: text/plain
submitter: puneet
assignee: andreas_kupries
closer: puneet
closedate: 2004-07-01T07:12:28
comment:
  I am sending a command form a tcl application (client)
  to another tcl application (server). If an error is
  caught on the server side, this is not getting handeled
  by the ::bgerror procedure on the server side. This
  used to be the behaviour in the tcllib1.4. Now the
  error is being thrown back to the client side.


tkt_uuid: 984407ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
resolution: None
subsystem: tklib :: ctext
priority: 5 Medium
foundin: None
title: Hang in ctext with regexp match
cmimetype: text/plain
submitter: tallniel
assignee: georgeps
comment:
  Just been playing with ctext and I ran into a bug which causes an 
  endless loop on my system. The problem came from trying to 
  highlight Tcl comments, using:

  ctext::addHighlightClassForRegexp $win comment navy 
  {#[^\n]*\n}

  Then if I add the following to the text widget:

  This is a test
  # This is a test
  foo


  Then position the cursor somewhere in the comment, and press 
  backspace - endless loop occurs in ctext::highlight - the third while 
  1 loop. Problem seems to be that the [$win search..] stuff is 
  passed indices like 4.0 3.15  (i.e. start is after end), and it return 
  3.0 bizarrely (this may be a bug in the text widget, or possibly in 
  the Mac OS X implementation - I haven't followed up yet). The fix 
  was to add these lines after the {"" == $res} check:

  # If result given is less than the start index (can happen), then
  # break out
  foreach {l1 c1} [split $res .] {l2 c2} [split $si .] { break }
  if {$l1 < $l2 || ($l1 == $l2 && $c1 < $c2)} { break }


  Everything seems to work again after adding that in. I would 
  upload a patch, but I'm very busy at present. Hassle me by email 
  if you really really want a patch!


tkt_uuid: 985568ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: doctools
priority: 7 High
foundin: None
title: doctools - better error messages
cmimetype: text/plain
submitter: andreas_kupries
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-07-23T03:49:39
comment:
  The error messages generated by doctools are bad with
  regard to reporting the location they happen at. They
  should report not only what is wrong, but exactly where.


tkt_uuid: 985601ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 6
foundin: None
title: doctools - engine parameters not documented
cmimetype: text/plain
submitter: andreas_kupries
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-07-10T07:20:17
comment:
  Neither the general methods to query and set engine
  parameters are documented, nor are the actual
  parameters defined by the predefined formatters.


tkt_uuid: 985839ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: smtp
priority: 5 Medium
foundin: None
title: Can't send mail to Yahoo
cmimetype: text/plain
submitter: phantomfive
assignee: mrose
closer: patthoyts
closedate: 2004-08-06T13:37:50
comment:
  Using the smtp and mime packages to send email, I am
  having trouble sending email to Yahoo using Windows XP.
   It works fine from a Linux machine, also sending mail
  from the windows machine to hotmail.com works.  I am
  using the following code:

  proc send_simple_message {recipient email_server
  subject body} {
      package require smtp
      package require mime
      
      set token [mime::initialize -canonical text/plain \
     -string $body]
      mime::setheader $token Subject $subject
      
      puts [smtp::sendmessage $token \
        -recipients $recipient -servers $email_server]
      mime::finalize $token
  }
  send_simple_message andrewthompson10@hotmail.com
  mx3.mail.yahoo.com \
      "This is the subject." "\n\n This is the message.\n"


  It gives me an error:

  key message-id not in header
     while executing 
  "error "key $mixed not in header""

  This appears to be on line 1282 of mime.tcl.

  I tried to add things to the header with the following
  code inside proc send_simple_message:

  mime::setheader $token Subject $subject
  mime::setheader $token Message-ID \
  "<3140374180748234979238742391784313234@localhost>"
  mime::setheader $token Date "July 4, 2004"
      


  And I ended up with the following error:

  can't unset "state(route)": no such element in array
  while executing 
  "unset state($prop)"

  This appears to be referring to line 2675 of mime.tcl
  (I would expect that the catch would take care of the
  error, but apparently not).


tkt_uuid: 987305ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: None
priority: 5 Medium
foundin: None
title: uuid::compare should be uuid::equal
cmimetype: text/plain
submitter: jenglish
assignee: patthoyts
closer: patthoyts
closedate: 2004-07-08T22:30:27
comment:
  From the uuid manpage:

  | ::uuid::uuid compare id1 id2
  |                                                     
                             
  | Compares two uuids. If equal the result is 0 
  | otherwise the result will be either +1 or -1.

  It's almost never necessary to check if one UUID is
  less than or greater than another; UUIDs don't really
  have a natural ordering relation.  

  It's far more common to check UUIDs for equality.  I'd
  suggest that:

  | ::uuid::uuid equal $id1 $id2
  |  Returns 1 if $id1 and $id2 are equal, 0 otherwise.

  would be a more useful API.


tkt_uuid: 988123ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: doctools
priority: 5 Medium
foundin: None
title: "./sak.tcl nroff" fails
cmimetype: text/plain
submitter: rmax
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-07-10T04:16:27
comment:
  The output is:

  Gen (nroff): ./modules/asn/asn.man
  Gen (nroff): ./modules/base64/yencode.man
  Gen (nroff): ./modules/base64/base64.man
  Gen (nroff): ./modules/base64/uuencode.man
  Gen (nroff): ./modules/bee/bee.man
  command "dt" already exists, unable to create doctools
  object
      while executing
  "::doctools::new dt  -format $fmt  -module $m"
      (procedure "gendoc" line 19)
      invoked from within
  "gendoc nroff n"
      ("eval" body line 1)
      invoked from within
  "eval gendoc nroff n    $argv"
      (procedure "__nroff" line 1)
      invoked from within
  "__$cmd"
      (file "./sak.tcl" line 1582)


tkt_uuid: 988628ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Fixed
subsystem: bwidget
priority: 5 Medium
foundin: None
title: BWidget 1.7 notebook: missing border
cmimetype: text/plain
submitter: jfontain
assignee: damonc
closer: hobbs
closedate: 2004-09-14T20:47:11
comment:
  Using the following code, with Tcl/Tk 8.4.6 and BWidget
  1.7:

  wm geometry . 200x100
  set book [NoteBook .book -side bottom]
  $book insert end 1; $book itemconfigure 1 -text 1
  $book insert end 2; $book itemconfigure 2 -text 2
  $book raise 1
  pack $book -fill both -expand 1

  I noticed that the 1 pixel bottom border of tab 1 is
  not visible, whereas it shows perfectly when using tabs
  on top side.
  Can you reproduce it? Any workaround at this time?


tkt_uuid: 990937ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Wont Fix
subsystem: uri
priority: 5 Medium
foundin: None
title: why is [eval] required for identity split->join?
cmimetype: text/plain
submitter: glennjnn
assignee: andreas_kupries
closer: sf-robot
closedate: 2005-10-15T02:20:13
comment:
  % package require uri
  1.1.1
  % set url http://some.site.invalid/some/path
  % set theUrl [uri::join [uri::split $url]]
  list must have an even number of elements
  % set theUrl [eval uri::join [uri::split $url]]
  http://some.site.invalid/some/path


  Surely uri::join should be written so that the eval is
  not required.  Merely stop using the "args" argument in
  the proc definition so that uri::join must be passed a
  list and not several parameters.

  proc uri::join parts {
      array set components $parts
      return [eval [list Join[string totitle
  $components(scheme)]] $parts]
  }


tkt_uuid: 991452ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Not Applicable Here
subsystem: ftp
priority: 5 Medium
foundin: None
title: ftp::Quote should join arguments
cmimetype: text/plain
submitter: nobody
assignee: gwlester
comment:
  in ::ftp::Quote arguments are simply reached to the server,
  but this is a tcl list. If list values contain spaces
  or special
  characters, tcl wraps list elements in braces and these get
  handed over to the ftp-server.

  I suggest the following mini-patch, which joins the
  args by spaces:

  --- ftp.tcl.orig        Thu Jul 15 10:42:53 2004
  +++ ftp.tcl     Thu Jul 15 10:38:18 2004
  @@ -2201,7 +2201,7 @@
           return 0
       }
   
  -    set ftp(Cmd) $args
  +    set ftp(Cmd) [join $args " "]
       set ftp(Quote) {}
   
       set ftp(State) quote


tkt_uuid: 991959ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: ncgi
priority: 5 Medium
foundin: None
title: command to send headers
cmimetype: text/plain
submitter: davidw
assignee: welch
comment:
  In CGI scripts with ncgi you send the headers via a
  regular old puts.  This works ok for the moment, but
  it's an obstacle to creating a compatibility layer for
  systems such as Rivet or tclhttpd.  It would be best if
  all 'special' goings-on were handled by ncgi commands
  that could be overridden to create a compatibility layer.

  Something along the lines of

  ncgi::headers text/html

  is what I'm thinking of.


tkt_uuid: 992481ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Duplicate
subsystem: log
priority: 5 Medium
foundin: None
title: typo in logger::services proc
cmimetype: text/plain
submitter: hemanglavana
assignee: andreas_kupries
closer: andreas_kupries
closedate: 2004-07-16T17:57:54
comment:
  The logger::services always returns "services", see below:

  godel:678> tclsh
  % package provide ActiveTcl
  8.4.6.0
  % package require logger
  0.3
  % logger::init foo
  ::logger::tree::foo
  % logger::init bar
  ::logger::tree::bar
  % logger::services
  services
  % exit
  godel:679> 

  This is because there is a typo in the services proc.
  The variable name is not accessed using $. See below:

  proc ::logger::services {} {
      variable services
      return services     <---- should be "return $services"
  }


tkt_uuid: 995545ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: Out of Date
subsystem: struct :: record
priority: 5 Medium
foundin: None
title: package require struct::record does not work
cmimetype: text/plain
submitter: nobody
assignee: schwarzkopf
closer: andreas_kupries
closedate: 2004-09-29T19:18:40
comment:
  as described above 

  package require struct::record
  can't find package struct::record


  however

  package require struct
  namespace import ::struct::record

  does work

  this does not match the documentation!!!

  tcllib1.6


  from garyt@bmb.leeds.ac.uk


tkt_uuid: 996326ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
resolution: Not Applicable Here
subsystem: textutil :: expander
priority: 5 Medium
foundin: None
title: Hook for errmode 'error'
cmimetype: text/plain
submitter: andreas_kupries
assignee: andreas_kupries
comment:
  When error mode "error" is used the expander places
  errors directly into the output. The format of that
  error message is hardwired. And really suitable only if
  the output is plain text.

  IMHO it makes sense to have a callback which can be set
  and creates a message which is properly formatted for
  the generated document. For example in HTML a box with
  highlighted background, bold text, large font, colors, ...


tkt_uuid: 996569ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
resolution: None
subsystem: bwidget
priority: 7 High
foundin: None
title: BWidget 1.7: ComboBox: autocomplete problem w/upper case
cmimetype: text/plain
submitter: wedgef5
assignee: dev_null42a
closer: dev_null42a
closedate: 2006-02-08T16:49:15
comment:
  The autocomplete function in the BWidgets 1.7.0
  ComboBox has problems matching when the list has values
  that are all upper case.  By doing either a string
  tolower or string totitle on the list entries, the
  autocomplete works very well.


tkt_uuid: 6812273b4db845b2374e9cb977cf352f96aa4863
type: Bug
status: Open
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
severity: Critical
foundin: 0.6
private_contact: 0e80a0514179e322e98b67c0f9b805f0a90e7efa
title: Plotchart "bindplot" not sensitive when cursor is over data/lines
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: nobody
comment:
  When using an xyplot in plotchart and trying to make use of 'bindplot' to get the coordinate X,Y values in a convenient callback, I notice that the callback does not execute if the cursor is over data (lines and dot symbols in my case) but it does work as expected in the empty parts of the plot.  A fix (or workaround) would be much appreciated.


tkt_uuid: 530c40d269eb3bc4523115e121c38e7a6c047632
type: Bug
status: Closed
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
severity: Minor
foundin: 2.2.2
private_contact: 662c23482b0bf6a505f39e48fb7ad43af8dee4d3
title: Incorrect plotchart version provided
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2456731.15586056
comment:
  $ tclsh
  % package require Plotchart
  attempt to provide package Plotchart 2.2.2 failed: package Plotchart 2.2.1 provided instead

  version 2.2.2 is referenced in pkgIndex.tcl, but plotchart.tcl provides 2.2.1.

  Check-in e3b4898b67bbde1cdd924044afa35f716bc9a751 changed the version number in pkgIndex.tcl and ChangeLog but missed plotchart.tcl.  I wonder if anything else was omitted from that check-in...


tkt_uuid: 2414880fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
resolution: Not Applicable Here
subsystem: Build System & Testing
priority: 5 Medium
severity: Minor
foundin: None
title: fix installer.tcl to look for and handle tcllibc
cmimetype: text/plain
submitter: karll
assignee: andreas_kupries
closer: aku
closedate: 2456596.28475439
comment:
  If one uses critcl to build the C accelerators for tcllib, make install / installer.tcl doesn't install the tcllibc module.

  aku requested in #tcl that I file a bug on this.


tkt_uuid: 3dee7d95ca4d14a112a2081858b26c2afce3b504
type: Bug
status: Closed
resolution: Fixed
subsystem: (unused)
priority: 5 Medium
severity: Important
foundin: 0.1
private_contact: 24e6652e36ce2e57ca3201030571772f1476335c
title: Gradient items should be lowered
cmimetype: text/plain
submitter: arjenmarkus
assignee: aku
closer: aku
closedate: 2456596.26664153
comment:
  The example below exhibits the problem:

  # grad.tcl --
  #     Show a gradient on the canvas
  #
  package require canvas::gradient
  canvas .c
  canvas::gradient .c -direction x -color1 yellow -color2 blue
  pack .c -fill both -expand 1
  set poly [.c create polygon 200 100 300 200 200 300 200 100 -fill blue]

  The polygon is not visible - the gradient is drawn on top of it.

  This can be remedied by lowering the gradient items:

  .c lower canvas::gradient


tkt_uuid: 19721eff15f5e90f2bd43f5a9205ad0184944669
type: Patch
status: Closed
resolution: Accepted
subsystem: Examples
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Better example usability
cmimetype: text/plain
submitter: stwo
assignee: andreas_kupries
closer: aku
closedate: 2456596.28381905
comment:
  Add shebangs, package requires, etc. to allow examples to be easily run.

  Also, tklib:canvas seems to be missing from the subsystem list.


tkt_uuid: 678c8ac255b77bd020f0130b43b0a55860f067fa
type: Bug
status: Closed
resolution: Fixed
subsystem: tklib
priority: 5 Medium
severity: Important
private_contact: 24e6652e36ce2e57ca3201030571772f1476335c
title: README file outdated - installed-modules.tcl no longer exists
cmimetype: text/plain
submitter: arjenmarkus
assignee: aku
closer: aku
closedate: 2456596.27098634
comment:
  The file README mentions that new modules have to be registered in installed_modules.tcl, but this file no longer exists. Instead the new module must be registered in installation/modules.tcl


tkt_uuid: 40ae42af80c61618720510ba6648bef183e6b894
type: Bug
status: Closed
resolution: None
subsystem: tklib: plotchart
priority: 5 Medium
severity: Important
foundin: 8.5.14
private_contact: 5996480398deae228ceb0cbed9e8bc8c457f2b88
title: Get canvas path name from plot id
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2456571.83811208
comment:
  Hi, in plotpriv.tcl, for instance ::Plotchart::WidthCanvas, it is used a piece of code to extract the canvas path name from the plot id, the expression used is:

  set w [string range $w 2 end]

  This expression assume that the first two character correspond to the index of the plot within the canvas and it may fails if for some reason the plot number has 3 digit, ie, 100. 

  The expression to build the plot id is [format "%02d%s" $scaling($c,plots) $c] if $scaling($c,plots) has 3 or more digits then it results in an invalid identifier.

  I have changed my copy of plotchart to use this expression:

  string range $w [string first . $w] end

  and it works as expected.

  Bellow is a code to help reproducing the error, you have to resize the window until the error appears, eventually after the resize number 100.

  package require Plotchart
  canvas .c
  pack .c -fill both -expand yes
  bind .c <Configure> redraw
  proc redraw { } {
    .c delete all
    ::Plotchart::createXYPlot .c {0 1 0.1} {0 1 0.1}
  }


tkt_uuid: bac1ff5030858564f1ca7ffdb044c4fdb8f4c72a
type: Patch
status: Closed
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Better example usability
cmimetype: text/plain
submitter: stwo
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2456571.85321225
comment:
  Add shebangs, package requires, etc. to allow examples to be easily run.

  Also, tklib:controlwidget seems to be missing from the subsystem list.


tkt_uuid: af953d9fbfafe05c0ae30ce27d18e11b68329ace
type: Bug
status: Closed
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: examples/controlwidget/demo-meters.tcl has msdos line-endings
cmimetype: text/plain
submitter: stwo
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2456571.8526035
comment:
  The file examples/controlwidget/demo-meters.tcl has msdos line-endings but should have unix line-endings, like all the other files.

  Also, tklib:controlwidget seems to be missing from the subsystem list.


tkt_uuid: 0cc0b936e89cd8068b4700ec42dce8e4613e4da3
type: Bug
status: Closed
resolution: None
subsystem: tklib: plotchart
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: examples/plotchart/testfunc.tcl has msdos line-endings
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: arjenmarkus
closedate: 2456564.9855489
comment:
  The file examples/plotchart/testfunc.tcl has msdos line-endings but should have unix line-endings, like all the other files.


tkt_uuid: 2db5ae23e2b41b513bf21db0b898cdc41c9c3256
type: Bug
status: Closed
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
severity: Important
foundin: 2.2.0
private_contact: f463162b66810fbbda2c193cc3476868adfe003a
title: ::Plotchart::createSpiralPie doesn't work
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: arjenmarkus
closedate: 2456564.98749637
comment:
  In routine ::Plotchart::createSpiralPie 

  --> scaling($w,coordSystem) , scaling($w,xfactor) , scaling($w,yfactor)
  are not defined

  Adding those lines allows the exemple "test-spiralpie.tcl" to work.
  (added just before the lines "viewPort $w $pxmin $pymin $pxmax $pymax" )

  set scaling($w,coordSystem) 0
  set scaling($w,xfactor)   1.0
  set scaling($w,yfactor)   1.0


tkt_uuid: 9c9ba3493099f0b877678645dfc5e1300efb458a
type: RFE
status: Open
resolution: None
subsystem: tklib
priority: 5 Medium
severity: Minor
foundin: 1.0
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
title: Add Taotk to tklib
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  I would like to add a package I am developing called "taotk" to the tklib. It is a TclOO megawidget toolkit based on Tao, which was presented at the 20th Annual Tcl conference in New Orleans.


tkt_uuid: 2733f5a9517e312e1f43d81f7bb546feaf375a99
type: Patch
status: Open
resolution: None
subsystem: Documentation
priority: 5 Medium
severity: Minor
foundin: 2.2.0
private_contact: f463162b66810fbbda2c193cc3476868adfe003a
title: error in Plotchart(n) documentation
cmimetype: text/plain
submitter: anonymous
assignee: arjenmarkus
closer: nobody
comment:
  The documentation for Plotchart describes the function : "$plot3d colours fill border" , but the method "colours" does not exist, it should be "$plot3d colour fill border", that works well according to the description.


tkt_uuid: 28d0c781447b74653333c2650519727de5659a5b
type: Bug
status: Open
resolution: None
subsystem: Examples
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Error when selecting Open from the File menu in bitmap editor
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: nobody
comment:
  Missing [global] or explicit ::.

  Also, the wiki has a newer version.

  I put this in Examples, maybe an App category is needed?


tkt_uuid: 1f4480cc97ef081b5d0ea92fb02097fe3797a02c
type: Bug
status: Closed
resolution: Fixed
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: dd46261fd519288c1396d5a58eb1be42b8706bef
private_contact: 662c23482b0bf6a505f39e48fb7ad43af8dee4d3
title: bitmap-editor not executable
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: aku
closedate: 2456969.47039354
comment:
  apps/bitmap-editor is not marked executable, so I have to manually chmod +x /usr/local/bin/bitmap-editor after running installer.tcl.


tkt_uuid: 14c1e0badf69d695c55e2c3bc20ecff1658ddcf9
type: Bug
status: Closed
resolution: Fixed
subsystem: A Category Is Missing
priority: 7 High
severity: Severe
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: apps/bitmap-editor can't open files
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: aku
closedate: 2456969.47071855
comment:
  Should there be an 'apps' category?

  Demonstrate:
  $ bitmap-editor z.bmp
  Error in startup script: can't read "fname": no such variable

  Fix: 
  -proc DisplayBMPFile {file} {
  +proc DisplayBMPFile {fname} {


# ticketchng

login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  This may have been a symptom of the problem reported in Bug
  970199, which I fixed.  Unfortunately I do not have a Win98
  box to test.


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1312539

  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirmed.

  This affects struct::graph as well. The code used for node
  and arc attributes is the same one as for struct::tree node
  attributes.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  We have different implementations for 8.[23] and 8.4+, and
  the implementation for 8.4+ seems to be buggy. It tries to
  use local vars for the set elements, to avoid an additional
  hash lookup, or such. Perf opt, goes through an 'eval'. It
  is not the eval. The '()' cause the code to think that the
  local is an array element. Bah. I will simply disable this
  special branch and use the 8.[23] implementation for all
  versions.


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=128673

  Proposed new ::ftpd::read solves problem:

  proc ::ftpd::read {sock} {
      upvar #0 ::ftpd::$sock data
      variable CurrentSocket 

      set CurrentSocket $sock
      if {[eof $sock]} {
  Finish $sock
  return
      }
      switch -exact -- $data(state) {
  command {
      gets $sock command
      set parts [split $command]
      set cmd [string toupper [lindex  $parts 0]]
      auto_load ::ftpd::command::$cmd
              if {($data(access) == 0) && ((![info exists
  data(user)]) || \
              ($data(user) == "")) && (![string equal $cmd
  "USER"])} {
                  if {[string equal $cmd "PASS"]} {
      puts $sock "503 Login with USER first."
                  } else {
                      puts $sock "530 Please login with USER
  and PASS."
  }
      } elseif {($data(access) == 0) && (![string equal $cmd
  "PASS"]) \
                      && (![string equal $cmd "USER"]) \
                      && (![string equal $cmd "QUIT"])} {
                  puts $sock "530 Please login with USER and
  PASS."
      } elseif {[info command ::ftpd::command::$cmd] != ""} {
  Log debug $command
  switch -- $cmd {
  APPE -
  CWD -
  DELE -
  LIST -
  MDTM -
  MKD -
  NLST -
  RETR -
  RMD -
  RNFR -
  RNTO -
  SIZE -
  STOR -
  STOU {
  set command [string trim $command]
  set cmdLength [string length $cmd]
  set path [string range $command $cmdLength end]
  set path [string trim $path]
  ::ftpd::command::$cmd $sock [list $path]
  }
  default {
  ::ftpd::command::$cmd $sock [lrange $parts 1 end]
  }
  }
  catch {flush $sock}
      } else {
  Log error "Unknown command: $cmd"
  puts $sock "500 Unknown command $cmd"
      }
  }
  default {
      error "Unknown state \"$data(state)\""
  }
      }
      return
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Duplicate of
  http://sourceforge.net/tracker/index.php?func=detail&aid=923055&group_id=12883&atid=112883


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=128673

  I double-submitted by mistake.  Please close this record and
  refer to previous.  Sorry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The problem are missing array initialization in the helper
  command 'CheckSerialization'. Adding them fixes the problem.

  Committed fix to both 1-6 branch and Head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Right. Worse, the stack object command is always in the
  global namespace. Graph for example on the other hand
  generates in the callers namespace first. Definitely in need
  of an update. Still the first/old style of command
  generation. I believe I will add serialization as well
  (trivial for stack). Maybe enough to go v2 for that package.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Checking I find that 'queue' had the same difference between
  docs and behaviour. This was fixed April 25, 2003, in favor
  of the behaviour/code. I.e. the behaviour/code was kept, and
  the documentation updated. Given that queue and stack are so
  similar I've decided to resolve this report in the same way,
  i.e. update the documentation, keep the code. That way we
  have similar structures with similar behaviour.

  The more tclish behaviour is something we can do later, for
  a major revision of both. If we want to.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  There is the LabelFrame which handles it.  I want to move
  away from making widgets that are too specialized.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Notes for future reports:

  Note I: Setting the 'category' information will in many
  cases auto-assign a maintainer for review and application.

  Note II: Changes sources, or patches are best not inlined
  into the bug report. Attaching them as separate files is
  better for two reasons:

  * The notification mails for the report are shorter, as SF
  doesn't have to send all this code, only the comments.

  * The changes are easier to get out of the report, via click
  on links. Right now I can either try copy/paste a mangled
  version out of the webbrowser, or I have to go to a
  notification mail to get an unmangled version I'd rather
  simply click on a link for the attachment.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825

  i agree with the submitter, the format should be constant
  across platforms. patch generated and attached.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted and added to SF CVS Head. However I still had to
  create the documentation for this.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The same is true for -value, -filter, -in, etc. I will add
  code and test cases to prevent multiple use of the various
  options. Method 'nodes' has the same problem as well. This
  is for graph v1 and v2.


login: georgeps
username: georgeps
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=585068

  The HEAD of tklib's ctext.tcl should have the -font, and
  -linemap work correctly in the instance and creation
  commands.  The -linemap should also now appear when -linemap
  1 is passed at all times, because it now uses grid and
  -minwidth.  Before I was using pack. 


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I forgot to add that it suffices (for me, and I imagine for
  most users) to have an option that turns off
  case-sensitivity globally.


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433

  Cause of the problem:  the TMML-to-HTML converter keeps an
  index of all defined symbols, and tries to make a
  cross-reference from any term to the definition of that
  term.  However, it doesn't handle the case where there are
  multiple definitions of the same term; this happens a lot in
  the TCLLIB documentation (e.g., struct::stack::destroy,
  struct::tree::destroy, etc.., etc.)

  Patched the conversion script to not generate
  cross-references if there are multiple definitions of the
  same term.  Should be better now, but there are still a few
  spurious incorrect xrefs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  How is having one call per line bad ? This means that each
  line is (correctly) prefixed with the level, for example (if
  using the standard proc).


login: eriklns
username: eriklns
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=113903

  Good or bad is of course a matter of taste.

  I expect a call to [log:log] log a _single event_ to the log
  file. If this expectation is wrong than please indicate what
  I should expect.

  If the event to be logged happens to be annotated with a
  text containing multiple lines, I end up with a log file
  whose (distorted) format implies multiple events.

  Of course, I may have been abusing [log::log] all the time ....

  Example:
  An app walks into a bgerror (a single event ! ), which is
  captured and logged as follows:

  proc bgerror {} {
      global errorInfo
      .....
      # note that $errorInfo has multiple lines ...
      log::log $level $errorInfo
      .....
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  We never specified in the beginning how much a call to
  log::log should write, and the interface to the log command
  itself was unspecified in this regard as well.

  I'll have to think more about this.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The line
      $x arcs -out $n1 -in $n2

  is wrong. You cannot combine operators in this way. You can
  say either
      $x arcs -out $n1
  or
      $x arcs -in $n2

  Please look at the documentation of arcs again, and you
  should see that only one of -in, -out, etc. is possible.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  See also Bug 1007396 , fixing it would prevent stumbling
  into this trap.


login: lio_lion
username: lio_lion
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=971615

  I just found the project "Tk Toolkit" and believe this is
  probably supposed to go there (and posted it there). However
  I will leave it here as well just in case this was the
  correct place.

  If it is the wrong place dont hesitate to delete this thread.

  Lio.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  "Tk Toolkit" is the correct place.

  Note that the resolution rejected means just that it is not
  valid here in tcllib. It does not mean that the report is
  invalid and such. I haven't actually read more than required
  to know that it doesn't belong here.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  IMHO putting this into a separate package would be better.
  Note that the code currently accesses counter internals.
  Separating the two will force usage of public API, and its
  possible extension to meet the generators needs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  After looking at the docs I have a question: The tcl core
  has the builtin command 'auto_execok' which also does
  searching for executables. How does your command compare to it ?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  I agree that [auto_execok] likely does a
  better job (especially when it comes to
  platform differences), but if one just has a liking
  for Unix-style shell commands, there's
  a history of placing them in the
  fileutils package, rather than having only
  one command per package.

  See for example, [fileutil::cat], [fileutil::find],
  [fileutil::grep], etc.


login: certgen
username: certgen
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=82268

  uhh...umm...well...i guess if i had read the docs for
  auto_execok...i...uhh...well, probably wouldn't have written
  this because they are the exact same thing. opps. don't i
  feel silly now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Don't feel to bad. Nobody knows all, not even I, and that is
  why things go through the review. Note that while
  auto_execok is meant to do the same things it is a bit
  different internally and the API, for more x-platform ability.

  Should I  close this then ?

  Oh, and don't let this stop you from proposing other modules
  and code of yours for tcllib.


login: certgen
username: certgen
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=82268

  Sure. Probably fine to close this. Unless you want to
  consider wrapping auto_execok in a fileutil::which command.
  I only never noticed auto_execok because, well, that command
  name completely sucks. Without clicking through the
  documentation on the tcl wiki page I would never have
  guessed what it did from the command name.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Wrapper as fileutil::which is an idea. Renaming and
  recategorizing the entry.

  I agree that the name 'auto_execok' is ... non-intuitive /
  non-explanatory. Historically grown, unfortunately. It came
  out of the 'auto'loader and is a helper command for it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed. pop3d used md5, but was not able to use both v1 and
  v2. Added switching at runtime, like for all other modules.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Larry, can you make Trf unavailable and check if the
  pure-Tcl version has the same problem ? It should not. The
  stacktrace shows the crash clearly in Trf's md5 implementation.

  This might be a bug in Trf. Except that Trf has not been
  changed in the last day, nor even week.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Outside communication by mail ... Apparently we have no
  crashes anymore.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the problems - they had to do with importing
  procedures from other namespaces and sourcing files from
  other locations. One needs to be careful with that :(


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I was unable to repro this. I used a Tcl 8.4.7 from Aug 31,
  and the most recent Tcllib, i.e Aug 31, again.

  The stacktraces as they are point to some problem with the
  "comm" package. I guess I should list its version in the
  output of the test suite as well.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  How can we figure out what might be causing the problem in
  my environment - maybe a firewall or something?
  I have executed the test suite from the aug 31, 2004 cvs
  snapshot available for ftp at activestate.com .  I
  configured it with 
  $ cd tcllib
  $ mkdir unix
  $ cd unix
  $ ../configure  --prefix=/usr/tcl84 --enable-shared
  --enable-symbols --enable-stubs
  Running the test suite against either Tcl 8.4.7 or 8.5a2, I
  see the identical
  errors.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A firewall should have no effect. The comm package is not
  used by pop3d itself, just the testsuite, to coordinate the
  pop3 client and server processes which are used to perform
  the various tests. I would have to look up the details tof
  the design again. Maybe that will give me clues.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The mgmt of sub processes and dialog facility were
  completely rewritten. They now use "comm". This does not
  happen anymore.


login: schwarzkopf
username: schwarzkopf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=159778

  sorry, I started looking at it last week, but got side
  tracked. I will look at it again tomorrow.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirmed that there is an error, but the error message I
  get is different

   ---- errorInfo: can't read "jmod": no such variable
       while executing
   "$fitXYInputData.macro $jmod"
       ("uplevel" body line 35)
       invoked from within
   "uplevel 1 $script"


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ah, this was a bug in the test case I was creating. I missed
  that the code here references jmod, but does not define it.
  Now I can confirm bug and error message.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This could be in the recursive creation via #auto. There is
  no direct writing to .input and maybe the data is not
  initialized.

  ... Yes, it is in the creation, of the nested structures.
  The fitXYdata.input.params aborts the creation, because
  there is no _recorddefn stuff (Guard against failed
  creation, lines 307-317). This however is not reported as
  error, and so the code returns the incompletely created
  record object.

  Digging deeper.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  And the true cause is bad management of _level.
  And it is not really the deep-nesting which screws up, but
  the that we have _two_ sub-records in fitInput. When
  creation of params is complete the _level is reset to zero.
  So .data believes it is toplevel. Bad.

  The level has to be incremented before each sub-record. This
  is done. It also has to be decremented afterward. That is
  missing. And the reset to zero has to be made conditional,
  check for level == 2.

  Yes, that fixes the problem. No new errors from the testsuite.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  -state was added in 8.3, so that would be the minimum
  requirement now for a TitleFrame.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted, and committed to head. A list of free ids may come
  later. However even with 32-bit ints we have around 4
  billion numbers before we get into trouble. Ignoring this
  issue for now.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  Instead of hiding the entire bottom frame, the solution I
  have keep the unmapping of the status bar, leaving the
  bottom frame there (but empty).  That way the main frame's
  size does not change upon mapping / unmapping the status bar.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Please attach your diffs to the report, instead of inlining
  them. Also, do you have one or more demo script we could add
  to the testsuite as new test cases ?

  Basically I see that there is a problem, but I have no idea
  how to reproduce it.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Fixed in revision 1.43 as part of some other work. All
  places that set the error array from the result now preload
  the array with a default error message.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks. Can you please also try the exif functionality in
  the jpeg module/package ? For this you will need the Tcllib
  CVS Head.

  Note: Is it possible for you to create a jpeg file without
  or minimal image data which has the same exif data which is
  giving you the trouble ? I would like to have something like
  that as test case.

  ... Belay the query about jpeg::exif ... I just see from the
  stacktrace that this happens in the MakerNote decoder of
  exif, and Makernote data is not yet handled by the
  jpeg::exif code. I would still like to have an image showing
  the error for a testcase.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Try this picture of yours truly (above, right) for example:

  http://virtual-estates.net/Izrail/Ira/img_4060.jpg

  BTW, I'm thrilled to learn, there is wider JPEG support in
  the works, than just Exif-handling.

  In particular, it appears, no software out there provides
  for lossless rotation of JPEG images (besides the jpegtran
  part of libjpeg). It would be great, if tcllib was the first
  to offer this valuable feature.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thank you. I got the image now, and will try to compress it
  a bit more. 600K is still a bit big to be lugged arund as a
  testcase in the distribution. I hope you don't mind getting
  more squeezed and blurry :)

  Alas, the jpeg code in tcllib is currently only able to work
  on a number of meta data chunks, like timestamps, comments,
  exif, etc. It has no operations for manipulating the pixels,
  like higher compression, rotation, and the like. However if
  someone writes such methods I would be willing to include them.

  See http://tcllib.sourceforge.net/doc/index.html#DIVnode290
  for the documentation.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Regarding JPEG manipulation. The way, jpegtran does(1)
  _lossless_ rotation is exactly through manipulating the data
  chunks. Decoding the image, rotating, and encoding it back
  is how everything else does it, which leads to loss in image
  quality. Rotation by 90, 180, and 270 degrees can be done
  without re-encoding, quickly, and losslessly.

  In general, I'd like to see TCL interface to ImageMagick's
  or GraphicsMagick's libMagick -- with and without the Tk
  support (photo(n)).


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Ooops, there is TclMagick already!

  http://www.graphicsmagick.org/TclMagick/


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  committed the fix to head. Place holder for the test image
  right now, have to cut it down a bit, 600K is not manageable.


login: pandur
username: pandur
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=59057

  This is a nice bug in ListBox::_mouse_select.

  it should read like:
  set ret [eval selection [list $path] ...]
  switch -- $cmd {
   ....
  }
  return $ret


  The return value is required in ListBox::_multiple_select


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Correct.
  Test script:
  pack [ListBox .l -selectmode multiple]
  .l insert end 2 -text a
  .l insert end 1 -text b
  .l insert end 0 -text c

  The code was there but there was an error->Fixed in cvs


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This change has one problem, IMHO. In the output of parse
  the empty tag, lets say <a/> looks like a closing tag,
  without a preceeding opening tag. This makes later checking
  of the nesting structure, for example by "2tree" effectively
  impossible as the code cannot tell anymore if the closing
  tag without the preceeding opening tag is truly bogus, or
  was generated by an empty tag, and thus ok.

  So IMHO it would be better to convert the empty tag into
  something which generates both opening and closing tag.

  Related question: Do you have test cases ?
  I am currently making some up, but if you have special tests
  which are important to you then please submit them.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok. I changed this to use 

  set sub "\}\n$cmd {\\1} {} {\\2} \{\}\n$cmd {\\1} {/} {} \{"

  This creates an opening tag carrying the attributes,
  followed by the closing tag. The opening tag does not carry
  any text data (which is correct, as the tag is empty).

  This will be committed.

  And while I haven't used your solution exactly as-is, thank
  you for making the effort to understand the parser and
  providing it in the first place. It gave me enough clues to
  go from there.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Also note the other report about this, at

      http://sourceforge.net/support/tracker.php?aid=900041

  This one was without code however.


login: petasis
username: petasis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=92283

  Thanks for the better fix!

  To say the truth, my initial thought was to use a different
  character (u) for such a case instead of providing '/' as
  the second argument to the callback proc, to indicate that
  this is a "unary" tag, i.e. a tag that starts/ends. But then
  I thought that this may break existing applications.
  (On the other hand, these applications already break on such
  tags, as the closing '/' was attached to the value of the
  last attribute).

  I thought a better compromise was to not alter the '/'
  character, and present it only as a closing tag. I was
  afraid to insert a 'vitual' tag, as this would alter the
  length in characters of the initial html code (at least as
  the callback sees it), which may potentially break my
  applications, where I use the htmlparse module to convert
  tags into other stand-off annotations and then strip all
  html tags. And as these annotations keep character
  references back to the original html text, I thought I would
  introduce new problems :-)

  However, I tested the final solution (which introduces this
  additional tag) and my apps seem to work fine. Of course
  this does not mean that other applications won't break, but
  we can't have anything :-)

  The only problem I think it still remains is that anyone who
  wishes to seperate these "unary" tags, cannot do so...

  George


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  This demonstrates the problem:

  % package require struct::tree
  2.0

  % struct::tree
  ::tree1

  % tree1 children root filter puts
  invalid command name "::struct::list"


  Whereas this works:

  % package require struct::tree
  2.0

  % package require struct::list
  1.4

  % struct::tree
  ::tree1

  % tree1 children root filter puts
  % 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Note: If you use the option to get _all_ children, i.e.
  -all, you will also need struct::list.

  Ditto for method "descendants".

  Another alternative is to simply make all of struct::tree
  dependent on struct::list ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  More: Graph has the same problem, for the methods "arcs",
  and "nodes".


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  Yes, sure, package require in global scope would work.

  It'd make the dependency clear at the top, too, which is good.

  Putting it close to the use point is probably an unwarranted
  micro-optimisation, wouldn't save much, and isn't very
  idiomatic from what I've seen of tcl common usage.

  So by all means, package require struct::list at the top.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the problem - a missing factor "$factor" when
  adjusting the raw ranges. 

  Could you confirm that the values returned by determineScale
  are now correct?


login: bwallner
username: bwallner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=318308

  The return values of determineScale seem to be correct.

  But the display of the scale in createBarchart seems to have
  a rounding problem. Instead of 0.0 I get ...1512313e-17.
  Example:
  package require Plotchart
  pack [canvas .c -background white]
  set dimScale [Plotchart::determineScale -1.07 -0.01]
  puts $dimScale
  set bc [Plotchart::createBarchart .c {f3d2 d3c2 h2h4}
  $dimScale 3]
  $bc plot 0 {-0.62 -0.67 -1.07} #000000
  $bc plot 1 {-0.64 -0.71 -1.01} #FFFFCC
  $bc plot 2 {-0.01 -0.01 -0.88} #00CCCC


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I will check this - it is simple to circumvent that problem
  and I thought I had done that ...


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Done, the code for drawing the numerical axes now treats
  labels near zero as a special case


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  This happens only on Windows, where [clock clicks] doesn't
  change very often.  So [clock clicks] % 64 only generates
  twelve uniuqe file names.  This should use rand() instead.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  Fixed by changing the random character selection expresison from
       append newname [string index $chars \
      [expr {([clock clicks] ^ $mypid) % 62}]]
  to
       append newname [string index $chars \
      [expr {int(rand()*62)}]]

  Also added a few tests to fileutil.test.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Just committed a fairly complete man page for the geometry 
  submodule


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825

  according to my repository they are. someone doublecheck
  that they are looking at HEAD

  exerpt:

  [call [arg net] [method log] [arg level] [arg message]]

  If logger is turned on by [method config] this will write a
  log [arg message]
  at [arg level].

  [call [arg net] [method logname]]

  Returns the name of the logger instance if logger is turned
  on.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yes, this is in the head. My fault. Somehow or other I
  missed this when looking at the irc manpage :(


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I was wondering where this came from, but then I saw the
  tkchat history. This can be used to feed a CVS server a fake
  PWD, and then strip it of locally, right ?

  Notice the "stripN" command. This allows you to strip N path
  elements from the beginning. This can be used for the same
  purpose, because you know how much segments your fake PWD
  had, no ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ping. I am not seeing any response to my question from the
  last comment.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Discussion on the chat.

  [16:27]akucolin - Question regarding 1040372 (Tcllib RFE)
  - Have you looked at stripN, if that is enough for you ?
  [16:29]Colinaku, looking now.  The idea is that [stripN
  $path [llength [file split $prefix]]] is equivalent to
  [::fileutil::strip $path $prefix].
  [16:30]ColinIsn't [::fileutil::stripN $path [llength [file
  split [pwd]]] equivalent to [::fileutil::stripPwd $path] too?
  [16:29]Out of a cloud of smoke, patthoyts appears!
  [16:31]akuActually no.
  [16:31]ColinAh.
  [16:32]akustripPwd does not touch the input if pwd is not
  prefix
  [16:32]akustripN always strips N elements
  [16:32]akuSo your generalized stripPath would make senbse,
  if it also does not touch input if prefix is not present
  [16:32]ColinThat would be useful.
  [16:32]akuOk.
  [16:33]akuI will add this as comment to the entry, so that
  I don't forget
  [16:33]ColinOk.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed implementation of, documentation and testsuite for
  'stripPath' to head.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Confirming here. The FreeBSD-i386 passes all tests properly. 
  FreeBSD-amd64 fails a whole lot of PNG-related tests, and 
  continues to fail the time-1.3 and hang on pop3, as tcllib-1.6 
  used to. 
   
  Why even bother making a new release without checking on 
  64-bit systems with different endiannes? 


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  It's a fair criticism, but it's also a
  fair question why neither you nor I
  tested the development sources
  in the last few weeks when we knew
  the 1.7 release was pending?  After all,
  we're the ones with the 64-bit boxes. :^)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, I guess I have to dig out the mail I sent to dgp ... a
  year ago or so ... with some debug proposals for crc. ...
  Wait, this time I have access to an amd64 machine ... Can
  test it locally.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Bah.

  For Tcl 8.4 on an amd64 machine I see no failures at all.
  Loaded packages are png, crc32, and Trf.

  Testing crc however gives me 13 failures, all in tests for
  crc32 using Trf.

  This is ActiveTcl 8.4.11.0.172579 btw.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Here's the first failure:

  $ /local/src/tcl8.4/unix/tclsh sak.tcl test png
  Shell is "/local/src/tcl8.4/unix/tclsh"
  tcllib tests
  Test platform: "Linux-2.2.23-alpha" using Tcl 8.4.11
  Tests running in working dir:  /local/src/tcllib
  Only running tests that match:  *
  Skipping test files that match:  l.*.test
  Only sourcing test files that match:  *.test
  Tests began at Thu Aug 25 02:21:44 PM EDT 2005
  Module: png
  modules/png/png.test
  - png   0.1
  - crc32 1.3

  ==== png-validate-basi0g01 full validation FAILED
  ==== Contents of test case:

          ::png::validate $f
      
  ---- Result was:
  CKSUM
  ---- Result should have been (exact matching):
  OK
  ==== png-validate-basi0g01 FAILED


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Oh, you have a plain Tcl crc32, without Trf accelerator. So
  I will have to force my system to not use Trf.

  And the moment I have figured this out a test will go into
  the crc module. I have no wish to test png in as many
  combinations as crc itself.

  Ok, confirmed. If I exclude Trf and use the pure Tcl crc32 I
  get errors.

  The stupid thing is, usage of Trf causes errors when testing
  the crc32 module by itself. But only on 64, not on 32. So
  there are errors lurking there as well.

  This will be a pain to untangle.

  I believe the first step would be to take checksums from the
  PNG stuff and convert them into crc32 testcases. If they
  fail we can work on a fix. And then we can ponder the effect
  of Trf.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The png failures have been fixed. We need truncation to
  32bit in two places where a [format %u] command made the
  unsigned result 64bit after sign-extending the incoming
  negative 32bit number.

  Now looking at the crc problem with Trf.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed a fix for crc/Trf as well. Code truncated to 32
  bit for pure Tcl and critcl paths, but not for Trf.

  This bug is now done.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Confirmed.
  I removed the condition about existing nodes in Tree_drop_cmd and it worked.
  So we call this a patch and commit it to cvs.


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=13222

  {^f([1-9]|([12][0-9]|3[0-5]))$} would be a better regexp.
  Doesn't match a single f anymore (and therefor fixing the
  bug), but all Fxy keys, accepted by tcl8.4 bind (F1 - F35), 

  (Though, this automatic spelling correction feature for
  MainFraim -menu definition is a bit obscure.)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I've fixed this to make the '--' optional as an end of args
  marker and arranged the code to cope with data that has a
  leading hyphen. 
  So now both examples will be OK. Also
   md5::md5 -hex -- --  will hash the last --  too.

  Also done for md4.

  I havn't added it to the documentation as the -- is rather
  redundant now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is more of a documentation bug: The cwd is passed in,
  just not as an explicit argument. Just use [pwd] to get the
  cwd and you will see that the CWD is the cwd.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Updated the documentation in the head, explaining how the
  cwd is passed in implicitly.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Well I _do_ have a console on windows - raised from a menu
  item. However these lines should either be tk_messageBox or
  log::log so will fix.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It would be interesting to know the server involved in this
  (although it is likely too late now to find out). In my
  hands against a Microsoft SMTP server if I make it fail one
  AUTH step (using NTLM or LOGIN) and try again and do it
  correctly then it works.
  I believe this server to have been configured to deny a
  connection following any failure and this is non-standard as
  far as I am aware. I believe we are correct to try for the
  most secure AUTH method on offer. If a server doesn't
  implement a particular mechanism it should not be offering
  it. For the server above if should only have offered LOGIN
  and maybe PLAIN from the description above.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  This is documented:
  ::base64::encode ?-maxlen maxlen? ?-wrapchar wrapchar? string 
  Base64 encodes the given binary string and returns the
  encoded result. Inserts the character wrapchar every maxlen
  characters of output. wrapchar defaults to newline. maxlen
  defaults to 60

  A "binary string" is in the essence a string with a
  Tcl_ByteArray representation, which is limited to the range
  you observed and is quite different from a typical tcl
  string. So if you non-binary data to base64 you get
  unexpected results.

  So if you want to encode utf-8 with base64 you should do:
  set string \u2019
  set bstring [encoding convertto utf-8 $string]
  set b64 [base64::encode $bstring]

  for decode:
  set bstring [base64::decode $b64]
  set string [encoding convertfrom utf-8 $string]

  So no real need for a new option, just take care that you
  feed "binary strings" to base64.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I guess this is possible, but requires support by the
  packages which look for accelerator packages. They basically
  need code looking for some magic signal which tells them not
  to look for accelerators, and then the testsuite can raise
  this magic signal.

  Otherwise the testsuite has to poke into the tested code,
  and modify it in some way. Dangerous. Difficult to Impossible.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  An idea in the same vein, actually more concrete than my
  last comment. And more general, hopefully. Have a small
  tcllib package containing runtime configuration options for
  all tcllib. The only configuration right now would be if
  'accelerator' packages are allowed or not, default is that
  they are allowed. The relevant packages using accelerators
  load the package and query this information before trying to
  an accelerator. The relevant testsuites load the package
  first, disallow accelerators and the packages under test
  then see this and don't load them.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  For packages which can use a compiled extension, the test
  suite should be testing all available implementations. The
  message digest packages (md4, md5, ripemd) all do this
  currently. So does uuencode and I need to check some others.
  So there is no option required I think.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I believe we can close this, as we are testing all impl. for
  at least 90% of the users of accel pkgsby now.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Thanks for bringing this to my attention: I was not aware of
  this lengthy initialisation. i suppose it could be done when
  actually using the procs that require it the first time.

  I will take action to improve this.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed this. Could you please check? (The tests are okay, but
  I would like a confirmation about the loading time)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Can you elaborate a bit more how you believe this will fit
  into Tcllib ? The main problem I have about this is: At the
  script level, and tcllib is at that level, we do not have
  data structures shared between threads. A data structure
  lives in one interpreter, which belongs to one thread.
  Access happens via 'thread::send', which are events
  underneath, automatically serialized.

  I had a quick glance at the noble site and it seem that they
  are talking about data structures at the C level. That could
  be of interest to the core, and/or extensions like 'Thread',
  or 'memchan' which have C level data structures living in
  several threads at once. But I cannot see how this applies
  to Tcllib, or can be applied to Tcllib.


login: elfring
username: elfring
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=572001

  The data can only be shared by the tsv interface of the thread package at the moment. Do you plan together with Zoran Vasiljevic to lower or change the boundaries in the future?

  Are you interested to use current non-blocking techniques at various places on the C level?
  http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I am not working on the Thread package, and I have no plans
  for anything regarding it. I.e. Zoran is the only one to ask
  about this.

  Sorry for not getting where you are trying to go. I still
  see no connection to Tcllib, so I maintain my belief that
  this RFE is misplaced.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  A LDAP search string has always consist of filter
  expressions in parenthesis.

  See http://www.faqs.org/rfcs/rfc1960.html :

       <filter> ::= '(' <filtercomp> ')'
       <filtercomp> ::= <and> | <or> | <not> | <item>
       <and> ::= '&' <filterlist>
       <or> ::= '|' <filterlist>
       <not> ::= '!' <filter>
       <filterlist> ::= <filter> | <filter> <filterlist> 
       ....

      4.  Examples

      This section gives a few examples of search filters
  written using
      this notation.

         (cn=Babs Jensen)
         (!(cn=Tim Howes))
         (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
         (o=univ*of*mich*)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Basically this is user error, the correct filter would be:
  (cn=General Management) and not "cn=General Management". The
  parsing code replaces () with {} which may not really be
  robust enough for corner cases, so i may revisit it, but
  this bug is invalid.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  OK - I've added this as a flag to ip::normalize as you
  cannot really auto-detect this. The default is as before, if
  set then you can get the IPv4 in IPv6 style address.

  % ip::normalize [ip::contract ::ffff:192.168.0.4]
  0000:0000:0000:0000:0000:ffff:c0a8:0004
  % ip::normalize [ip::contract ::ffff:192.168.0.4] 1
  0000:0000:0000:0000:0000:ffff:192.168.0.4


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I'm uncertain about this. WHat I do in the SPF module to
  check that the host is in the given domain is use the
  domain's mask and apply this to the host address too.
  ie:
    set domain fec0::/64
    set host    fec0::4
    set mask [ip::mask $domain]
    ip::equal $domain $host/$mask

  I think it may be useful to provide a utility function to
  make life simpler for everyone though. Maybe 
   ip::match domain host mask
  or just pick the mask off the domain part, giving
   ip::match fec0::/64 fec0::1 --> true
   ip::match fec0::/64 fec1::4 --> false

  The second version would be order dependent while
   ip::match fec0:: fec0::1 64
  the order would not matter.

  I think I'd like to keep the equality test the way it is -
  ie: very stringent.

  How would this work for you?


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  More than the syntax change is wrong in the latest tcllib
  cvs head though.  For instance:

  modules/math/linalg.test

  ==== svd-1.0 singular value decomposition - 2x2 FAILED
  ==== Contents of test case:

      set M {{1 2} {2 1}}
      determineSVD $M

  ---- Result was:
  {{0.70710678118654746 0.70710678118654768}
  {0.70710678118654757 -0.70710678118654735}} {3.0 1.0} {{0
  .70710678118654757 -0.70710678118654746}
  {0.70710678118654746 0.70710678118654757}}
  ---- Result should have been (exact matching):
  ?
  ==== svd-1.0 FAILED

  ==== svd-1.0 singular value decomposition - 10x10 FAILED
  ==== Contents of test case:

      set M [mkDingdong 10]
      lindex [determineSVD $M] 1

  ---- Result was:
  1.5707963267948406 1.57079632678333 1.5707963256965822
  1.5707962637493669 1.5707938907852776 1.57072
  96529311292 1.5694762403004545 1.5520538415681926
  1.3934577412020643 0.65048453501485148
  ---- Result should have been (exact matching):
  ?
  ==== svd-1.0 FAILED

  - comm 4.2.1
  Main       @ 37467
  Subshell is "/tmp/tcl/bin/tclsh8.4"
  Waiting for sub server to boot
  Sub server @ 37468      [server: Pop3 Fake Server]

  ==== pop3-0.0 bogus options FAILED
  ==== Contents of test case:

      catch {pop3::open -foo bar localhost ak smash 7664} msg
      set msg

  ---- Result was:
  ::pop3::open : Illegal option "-foo"
  ---- Result should have been (exact matching):
  ::pop3::open : Illegal option "foo"
  ==== pop3-0.0 FAILED

  ==== pop3-2.8 fast retrieval, .-stuff border break, #528928
  FAILED
  ==== Contents of test case:

      dialog::dialog_set {retrMessage 0 $__messageA 114}
      set psock [pop3::open -retr-mode retr localhost ak smash
  [dialog::listener]]
      set res   [pop3::retrieve $psock 1]
      pop3::close $psock
      dialog::waitdone
      set res

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: POP3 LOGIN ERROR: error writing "sock8":
  broken pipe
      while executing
  "error "POP3 LOGIN ERROR: $errorStr""
      (procedure "pop3::open" line 81)
      invoked from within
  "pop3::open -retr-mode retr localhost ak smash
  [dialog::listener]"
      invoked from within
  "set psock [pop3::open -retr-mode retr localhost ak smash
  [dialog::listener]]"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== pop3-2.8 FAILED

  ==== pop3-2.9 fast retrieval, .-stuff border break FAILED
  ==== Contents of test case:

      dialog::dialog_set {retrMessage 0 $__messageB 126}
      set psock [pop3::open -retr-mode retr localhost ak smash
  [dialog::listener]]
      set res   [pop3::retrieve $psock 1]
      pop3::close $psock
      dialog::waitdone
      set res

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: 
      while executing
  "error [string range $popRet 4 end]"
      (procedure "::pop3::send" line 13)
      invoked from within
  "::pop3::send $chan "RETR $index""
      ("retr" arm line 2)
      invoked from within
  "switch -exact -- $cstate(retr_mode) {
              retr {
                  set sizeStr [::pop3::send $chan "RETR $index"]

                  ::log::log debug "pop3 $chan retrieve
  ($sizeStr)..."
      (procedure "pop3::retrieve" line 46)
      invoked from within
  "pop3::retrieve $psock 1"
      invoked from within
  "set res   [pop3::retrieve $psock 1]"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== pop3-2.9 FAILED

  ==== pop3-5.0 get and delete all message, nano-client FAILED
  ==== Contents of test case:

      set res ""
      dialog::dialog_set deleDialog
      set psock [pop3::open -retr-mode slow localhost ak smash
  [dialog::listener]]
      set x [lindex [pop3::status $psock] 0]
      lappend res $x
      for {set i 0 } {$i < $x} {incr i} {
          set j [expr {$i + 1}]
          set msg [pop3::retrieve $psock $j]
          lappend res [string length $msg]
          pop3::delete $psock $j
      }
      pop3::close $psock

      set n 3
      foreach t [dialog::waitdone] {
          if {![string match "<<*" $t]} {continue}
          # Ignore commands from the login interaction.
          if {$n} {incr n -1 ; continue}
          lappend res [lindex $t 1]
      }
      set res
  ---- Result was:
  11 67 67 67 67 67 67 67 67 67 67 67 {TOP 1 1} QUIT
  ---- Result should have been (exact matching):
  11 67 67 67 67 67 67 67 67 67 67 67 STAT LAST {RETR 1} LAST
  {DELE 1} LAST {RETR 2} LAST {DELE 2} LAS
  T {RETR 3} LAST {DELE 3} LAST {RETR 4} LAST {DELE 4} LAST
  {RETR 5} LAST {DELE 5} LAST {RETR 6} LAST 
  {DELE 6} LAST {RETR 7} LAST {DELE 7} LAST {RETR 8} LAST
  {DELE 8} LAST {RETR 9} LAST {DELE 9} LAST {R
  ETR 10} LAST {DELE 10} LAST {RETR 11} LAST {DELE 11} QUIT
  ==== pop3-5.0 FAILED


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The changes to the error messages have been integrated into
  the Tcllib testsuite. Failurues due to changes in the way
  Tcl 8.5 is processing numbers are currently not tracked,
  i.e. ignored, until that area of 8.5 stabilizes again.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  You can see which version of pop3 you have by looking at the
  'package provide' statement in the file, either at the top,
  or the bottom. There should also be a line like 'RCS: @(#)
  ...' This line contains an internal revision number, just
  before the modification date.

  I cannot look at what you have done because you did not
  attach a file with your changes to this report.

  However if I understand your description correctly you are
  using 'vwait' to enter a new/nested event loop to both wait
  for the response from the server and to process events at
  the same time.

  Having a reference back to tcllib is ok (An url would be
  very good, not clear from description :)

  I have some ideas myself, so I don't know if I will use your
  stuff. It is definitely something which I want to do,
  however not right now. Maybe over X-mas.


login: lio_lion
username: lio_lion
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=971615

  You can see my code in the sf cvs at:
  http://cvs.sourceforge.net/viewcvs.py/amsn/amsn-extras/plugins/pop3/
  Lio.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Bryan, what is your response regarding our ability to use
  this code ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Reassigned to myself for work. Got mail that Bryan had
  already given permission.

  I am attaching a new patch which corrects a number of small
  problems I had with the original submission:

  * Using unified-diff format (option -u for diff).
    Much more readable regarding the changes
    which were made.

  * Fixed problems in the testsuite:
     - splitn => textutil::splitn
     - test 2.1 used tcltest 2 feature.
       Nothing else does in the textutil testsuite.
       Rewritten to regular v1 format.

  * proc splitn [list str [list len 1]] {...} rewritten to
     proc split {str {len 1}}

     The list construction was used by splitx only to
     get better quotation for the default regex, and
     only for older versions of Tcl. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Using the following test code I get no issue:

  pack [ListBox .l -selectmode multiple]
  .l insert end 2 -text a
  .l insert end 1 -text b
  .l insert end 0 -text c

  The proposed patch does not apply, the code changed in between.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Please do not confuse the SF project "Tcllib" with the
  package Tcllib  hosted in that project.

  The policy you mention has been formulated for the Tcllib
  package, yes, but this does not apply to the project as a
  whole. Similar policies for the other subprojects hosted
  here (tklib, bwidget, mclistbox, tclbench, tclapps, widget)
  have never been formulated.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  jlib _is_ a pure-Tcl package. It just isn't part of tcllib
  at the moment - something that we will rectify before too long.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted the patch, committed to CVS head.

  Side comment: The whole implementation of the ftp package,
  with its big StateHandler is annoying in general. 

  Side note 2: Next time when attaching not a patch please
  attach the whole file, and not only the changed command.
  That makes running the diff against the current revision
  much easier. With tkdiff I can relatively easy ignore the
  irrelevant chunks, but  when using a non-graphical diff it
  is inconvenient.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the bug (as it was indeed one). But noticed that the
  test cases are not yet in tcltest form.

  That remains to be done!


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  jlib is a jabber library depending on TclXML...

  its included in the tkchat starkit on sdarchive for example,
  its easiest to get it from there...


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  Where is the source for jlib?

  It is really peculiar that a working program would be
  modified to add a dependency on a tcl extension, without
  documentation on where to get the extension.

  There was nothing in the tkchat changelog about the addition
  of jlib, nothing in the source about where to find it.

  You point, in response to this bug report, to the starkit. 
  In there, I find source code without author identification
  and without an end user license agreement clarification.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  jlib is part of coccinella.

  cvs
  -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/coccinella
  co   -d jabberlib coccinella/jabberlib

  cvs
  -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/coccinella
  co   -d jabberlib-xml coccinella/TclXML

  Or you can get an archive from
  http://www.patthoyts.tk/programming/jabberlib.zip

  We are in the process of making jabberlib use tdom (optionally).

  License is BSD. Although the tclkit stuff should contain
  refences to coccinella.

  Re-assigning to pascal about that.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi, this depends if the selection is exported -> only one.
  Anyway, they are not.
  Test script:

  pack [ListBox .l -selectmode multiple]
  pack [ListBox .m -selectmode multiple -bg yellow]
  .l insert end a -text a
  .l insert end b -text b
  .m insert end a -text a
  .m insert end b -text b

  I am able to select all items at once.

  I close the bug


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The other options in ldap::search should also be exposed to
  the script level where appropriate: 
      set derefAliases 0
      set sizeLimit    0
      set timeLimit    0
      set attrsOnly    0
  Those are not settable by a script at the moment.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  kbk has got:
  <kbk> invalid command name "HttpServerError"
      while executing
  "HttpServerError $tok "History Fetch""
      (procedure "GetHistLogIdx" line 15)
      invoked from within
  "GetHistLogIdx logsize"
      (procedure "tkchat::LoadHistory" line 13)
      invoked from within
  "tkchat::LoadHistory"
      ("after" script)


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=99768

  Further issue in 1.253: There's missing error handling code?

  invalid command name "HttpServerError"
      while executing
  "HttpServerError $tok "History Fetch""
      (procedure "GetHistLogIdx" line 15)
      invoked from within
  "GetHistLogIdx logsize"
      (procedure "tkchat::LoadHistory" line 13)
      invoked from within
  "tkchat::LoadHistory"
      ("after" script)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This was due to the web server being down at the time.

  Should be fixed to give a better error message than a traceback.


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=13222

  Still got that error with v 1.263:

  couldn't open socket: connection refused
  couldn't open socket: connection refused
      while executing
  "::http::geturl $url  -headers [buildProxyHeaders]"
      (procedure "GetHistLogIdx" line 10)
      invoked from within
  "GetHistLogIdx logsize"
      (procedure "tkchat::LoadHistory" line 13)
      invoked from within
  "tkchat::LoadHistory"
      ("after" script)

  As for Miguel, otherwise tkchat works as normal.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I've changed the history fetch code to use asynchronous http
  gets. Now if it fails, it will put a system message into the
  chat window and give up.


login: aubinroy
username: aubinroy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1178514

  I am the one that filed this bug a LONG time ago.
  It requires only a simple fix: swap two lines in the 
  testbit routine.
  I am still relying on my workaround since the time that 
  bug was filed.

  From my point of view, this has still to be fixed.
  Best regards,
  ---/aubin/---


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Extended testsuite and fixed in CVS head now.
  Thank you for your patience.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirming. I noticed the very same thing during the xmas
  vacation when using htmlparse, and added it to my todo list.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  Actually the easiest would be to make use of Tcl's nice <<
  feature in exec.  Changed to use that.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  Fixed the -throwerrors, the -threads is not meant for public
  consumption at this time.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Aamer, some questions and notes on this code.

  Note: In the future please use 'diff -u'  to generate
  patches. The result is much more human readable, and also
  easier to apply.

  Questions:

  (1) How does your code behave when negative numbers are
  given to the commands ? The docs makes no mention of
  negatives being special, but when I look at the code it
  seems to me that the sign of the inputs is completely
  ignored, and the result is always positive. The question is
  if that is intentional, if you don't care about negative
  inputs, or something else ? In case negatives are not
  handled, intentionally, the docs should state this, to make
  the restriction clear. Otherwise we would get bug reports
  the first time someone tries to use negatives.

  (2) Do you have a testsuite for the operations ? That is
  really important IMHO.

  More musings:

  Due to a talk on the Tcler's chat with Kevin, who is working
  on a long-term thing about bignum ints in the Tcl core we
  also have some definitions which should allow the handling
  of negative numbers in the bitops. IOW instead of
  documenting the restriction we could try and extend the code
  to handle negative numbers as well. See below:

  Base definition: bitnot A == (-A)-1  [Two's complement].

  And then various laws, like DeMorgan to handle negatives:

  A & B ==
      ~(~A | ~B), for A, B < 0.
      The | is given positive numbers, and is thus trivial to do.
      A & B, for A, B >=0
      A & ~C, for A >=0, B < 0. where C = ~B, and
      bitwise expansion is possible.

  A | B, A ^ B have similar rules.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Integrated, with a minimal testsuite, and modified docs, the
  latter to make the limitation to positive numbers clear.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This has been fixed. A postprocessing step ensures that \fB.
  and \fBI. do not occur at the beginning of a line. By
  appending such offending lines to the end of the previous line.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed in the CVS head. List of glob patterns is defined
  platform dependent now.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I have asked Salvatore Sanfilippo, who wrote this package to
  look into these problems


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I ought to add the proposed tests (mind you: bit operations 
  are not my cup-of-tea - I will need some help on the 
  correct outcome or can I rely on the bit operations in Tcl 
  for ordinary integers?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Rely on the ordinary operations how ?
  They do work correctly assuming that the Tcl integers are
  limited-precision (32 or 64 bit). In 8.5 they are themselves
  extended for bignums. ... That may mean that you can use 8.5
  regular ops to determine what results the tests should
  expect. Kevin might be able to help you with that.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I made a correction to the rshift proc (not the rshiftBits 
  proc that it uses, as that is used in more than one place). 
  The idea for the test cases is to reproduce the results of 
  Tcl's expr for those integers that can be represented by 
  ordinary integers and by bignum.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  http://support.microsoft.com/?id=819961 suggests it will be
  of the form http://servername:port/
  Elsewhere MS documentation says "ProxyServer  This entry
  specifies the URL and port number for the proxy server."

  However, if you fill in different servers for each proxy
  type in the Internet explorer settings you indeed get the
  above string. This is with IE6. Probably the same for other
  versions.

  I think it is safe to split the string using ; and we will
  want the proxy for the protocol desired - that may be http
  or https for autoproxy purposes.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Added support for this to the autoproxy package. At this
  time we do not have sufficient information to differentiate
  between https and http at the point where we hook into the
  http package - therefore we always use the http proxy setting.

  The http package should be enhanced to support this -- but
  then the http package needs many enhancements and a general
  support for proxies is one part of that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed/added to CVS head. Lars will be added as developer
  to Tcllib as well, and bug reports etc. in the docstrip
  category will be (auto-)assigned to him.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Thanks for reporting this. 

  It is a bug, (now fixed with version 0.5.1), as the children
  only picked up level changes after their creation but did
  not inherit the current level configuration of the parent.

  Michael


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thank you. The fix has been accepted, but it was necessary
  to perform the changes manually. Please do not place patches
  like this into the report itself. Place them into a file,
  and attach that file.

  I have also added -no-apps options to the other install
  targets, to make explicit that they do not install the
  applications.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  I can confirm this and can offer two possible fixes:
  1. keep the current interface to logprocs and hack around it
  (quite a mess with alias introspection and other uglyness,
  but keeps the two parameters logprocs...)
  2. Change the interface of the logprocs and give the service
  as a parameter to the logging proc.

  The second version is much cleaner and better, but breaks
  compatibility.

  I have to think about, how to do it _right_, perhaps even
  introducing an args parameter for future extension (like
  format strings or similar things).

  Michael


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  There is now a fix in CVS for this. 
  Basically the info was not passed down the inheritance
  chain, which is now working. 

  It now works with all combinations of logger::import, even
  if -all is not given (which failed in the older fix).

  Michael


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  This fix has introduced a side-effect. The uplevel or [info
  level] cmd called from a custom logproc is 1 level deeper.
  see the following example:

  package require logger

  proc print args {
     set lvl [expr {[info level]-1}]
     set caller "global"
     if {$lvl > 0} {
         set caller [lindex [info level $lvl] 0]
     }
     puts "PRINT: level = $lvl, caller = $caller, args=$args"
  }

  namespace eval ::foo {

      set log [logger::init foo]
      logger::import -all -namespace log foo
      log::setlevel notice

      log::logproc warn  print
      log::logproc info  print
      log::logproc debug print
  }

  proc ::foo::x args {
      log::warn   "foo::x warn"
      log::debug  "foo::x debug"
  }

  ::foo::x

  When I execute the above, it used to print:

  hlavana-u5:143> tclsh foobar.tcl-v3
  PRINT: level = 1, caller = foo::x, args={foo::x warn}
  hlavana-u5:144>

  However, it now prints the following with logger.tcl in cvs
  head:

  hlavana-u5:143> tclsh foobar.tcl-v3
  PRINT: level = 2, caller = log::warn, args={foo::x warn}
  hlavana-u5:144>

  The caller proc name is no longer printed as foo::x.

  Hemang.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Yes, this is correct, as the internal are handled
  differently now (one extra layer of indirection, as always
  the solution).

  I added a uplevel 1 in the fix, and now the callstack looks
  nice again.  (fix is in cvs, logger 0.5.3)

  Is this callstack an important feature of logger for you? If
  yes, please file a RFE, so it either gets documented and
  gets part of the public API or an API is created to get the
  caller and callstack (excluding logger internals), so you
  can depend on it being stable between releases. (currently
  this is not tested).

  I hope i can keep the current clean callstack behaviour, but
  i thought of it as an internal detail, not a public thing. 

  Michael


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  Ok, here's one more error with the latest fix:

  hlavana-u5:158> tclsh foobar.tcl-v3 
  wrong # args: should be "print msg"
      while executing
  "::logger::tree::foo::warn foo::x warn"
      invoked from within
  "interp eval {} ::logger::tree::foo::warn {foo::x warn}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [linsert $args 0 interp eval {} [list
  ::logger::tree::foo::warn]]"
      (procedure "log::warn" line 1)
      invoked from within
  "log::warn   "foo::x warn""
      (procedure "::foo::x" line 2)
      invoked from within
  "::foo::x"
      (file "foobar.tcl-v3" line 33)
  hlavana-u5:159> cat foobar.tcl-v3 
  #!/bin/sh
  # \
  exec tclsh "$0" ${1+"$@"}


  package require logger

  proc print msg {
     set lvl [expr {[info level]-1}]
     set caller "global"
     if {$lvl > 0} {
         set caller [lindex [info level $lvl] 0]
     }
     puts "PRINT: level = $lvl, caller = $caller, msg=$msg"
  }
  namespace eval ::foo {

      set log [logger::init foo]
      logger::import -all -namespace log foo
      log::setlevel notice

      log::logproc warn  print
      log::logproc info  print
      log::logproc debug print
  }

  proc ::foo::x args {
      log::warn   "foo::x warn"
      log::debug  "foo::x debug"
  }

  ::foo::x
  hlavana-u5:160>  

  Note that I am not able to get latest version via anonymous
  cvs so e-mail me to verify further fixes.

  Hemang.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The last change had introduced an (uneccesary) double eval,
  removed one, now it works.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  It is the caller's job to call [update] within his loop if
  that is the intended behavior.  Man page modified to note this.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  You should never get an error about being unable to find
  tls.  Tls is an optional package. If it's present then it
  will enable the use of SSL but tkchat is happy to not have it.

  Can you try the current version (located at
  http://tclers.tk/~jabber/tkchat.kit) and update this bug
  with the result.

  It's possible that the error is related to the dodgy support
  for Solaris in the tls.kit rather than tkchat.kit itself.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  I downloaded the suggested tkchat.kit , along with the
  current tls.kit.
  I executed the new tkchat.kit, and it appears to start up
  without the error I was seeing before.

  So things appear to be working better.  Thanks!


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  This error appears to have returned:
   $ tkchat.kit
  couldn't load library
  "/volws/lwv28/ldatae/bin/tls.kit/lib/tls/SunOS-sparc/tls.so":
  no such file or directory
      while executing
  "load
  /volws/lwv28/ldatae/bin/tls.kit/lib/tls/SunOS-sparc/tls.so "
      ("package ifneeded" script)
      invoked from within
  "package require tls"
      ("foreach" body line 4)
      invoked from within
  "foreach tlsname {tls.kit tls-win.kit tls-lin.kit} {    
      if { [file exists [file join $kitdir $tlsname]] } {
          source [file join $kitdir $tls..."
      (file "/volws/lwv28/ldatae/bin/tkchat.kit/main.tcl" line 5)
      invoked from within
  "source /volws/lwv28/ldatae/bin/tkchat.kit/main.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel [list source [file join $self main.tcl]]"
  I did an sdx update tkchat.kit today:
  2005/04/14 07:07:40  30545-10419  /ldatae/bin/tkchat.kit


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Is this bug still relevant ? IIRC tkchat has evolved at lot,
  version somewhere at 1.320+


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  This error continues to occur. I downloaded the latest 
  tkchat.kit from mini.net, ran sdx update tls.kit, and when 
  I start tkchat.kit, I get:

  $ /volws/lwv27/ldatae/WWW/tkchat.kit
  invalid command 
  name "#####################################################
  ###########################################################
  ################################################LJÀÀ"
      while executing
  "source /volws/lwv27/ldatae/WWW/tkchat.kit/main.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel [list source [file join $self main.tcl]]"

  Note that when I rename tls.kit to tlsbad.kit, tkchat.kit 
  starts up without a problem.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This should be fine by now. At least on Solaris 10 sparc I
  can make use of the tls.kit at http://mini.net/sdarchive/tls.kit


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  One implementation of that is:

  proc fileutil::jail {jail filename} {
      set sjail [file split [file nativename $jail]]
      if  { ! [string equal [file pathtype [file join $sjail]]
  "absolute"] } {
  error "$jail must be an absolute path"
      }
      set sfilename [file split [file nativename $filename]]

      if {[string match ${sjail}* $sfilename]} {
  set path $sfilename
      } else {
  set path [concat $sjail $sfilename]
      }
      return [eval file join $path]
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, then. Why 'normalize' ?
  I believe to know, would like a confirmation.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Chat

  14:27]<davidw>aku: to take out all the ../../ stuff
  [14:27]akuOk.
  [14:28]akuWe should mention that explicitly in the docs,
  as security measure. You cannot escape using ..
  [14:28]akuIt will block symlinks trying to escape as well,
  right ?
  [14:28]<davidw>it should


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  It is fileutil::find which has the problem, not
  findByPattern. findByPattern is implemented in terms of 'find'.

  'find' calls itself recursively for all directories it finds
  in the base directory, making the subdirectory the new base
  directory.

  Looking at the code of 'find' it further seems to me that
  the 'glob' command is listing 'sys' deeply somewhere under
  c:\, 'file isfile' claims that it is not a file, but 'file
  isdirectory' claims that it is a directory. In complete
  contrast to the error message returned by 'cd'.

  The only time I have remotely similar behaviour, i.e.
  completely conflicting information from the various
  subcommands of the 'file' command, 'cd', 'glob', and the
  like was for a system file, in my case 'page.sys'.

  Given the name of the directory my guess is that this is a
  special directory of Windows which looks like a directory,
  behaves like directory, and yet is not a directory, not even
  there. To regular file/dir commands.

  My plan for fixing this is to add a catch around the 'cd
  $basedir' which errors out, and to ignore the
  pseudo-directory. In other words, neither sys, nor anything
  inside of it would show up in the out of 'find',
  'findByPattern', ever.

  One thing might wish to try in the interim is to locate this
  'sys' directory by conventional means, i.e. MS Explorer, and
  then to run various file related commands of Tcl on it, like
  'file exists', 'file isdir', 'file attributes', 'glob',
  'cd', etc.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The only other thing I can think of is that the permissions
  of the directory prevent you from entering it. The error
  message however is evidence against that. Still, I cannot
  exclude this, i.e. maybe the error message given by Windows
  is wrong.

  Well, I just tried this on Linux with a directory I made
  inaccessible (chmod -x). And an attempt to cd into that
  directory, in tclsh, returned the message "file or directory
  does not exist", but 'file isdir' and 'file isfile' returned
  the proper information. This is an indicator that
  permissions can be the problem as well. ... And 'find'
  errors out in the same manner as demonstrated.

  This would however not change the fix. The unix 'find'
  command ignores inaccessible directories, and we can do the
  same.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Small correction: The 'sys' directory itself will appear in
  the output of 'find', and of 'findByPatttern', if matching
  the pattern. Files and directories under 'sys' will not.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Looking over the other bugs I find that this one is actually
  a duplicate of
  http://sourceforge.net/support/tracker.php?aid=862491

  See there for more discussion which was had on the Tcler's chat.
  I have decided to fix this with a catch, ignoring any
  problematic directories. I will also file an RFE asking for
  an API change which allows us to set an error handler, to be
  called for the problematic directories.


login: jcw
username: jcw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1983

  Forgot to mention that the webdav package relies on a modified httpd 
  package (mods by Vinde Darley and Pat Thoyts AFAICT, included in the 
  starkit) to support DAV requests.  There is incomplete support for HTTP/
  1.1 in there, which would probably speed up the case of lots of back-to-
  back requests.


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  From the Tcl'ers Chat today (times UTC-0400):

  [13:18]<siyb>is jcw available by any chance?
  [13:19]kbkHe isn't often in the room, but he answers email. Can someone else help?
  ...
  [13:19]<siyb>kbk: it's about his davkit implementation. i was looking for a source version if one is available
  [13:21]<siyb>kbk: do you know if his email is still up to date (jcw@equi4.com)
  [13:22]   * kbk would have to check contact information at http://jeelabs.org/ - but hold on...
  [13:23]kbkdavkit is available as a starkit at http://tcl.tk/starkits/
  [13:23]kbkI just did an 'sdx unwrap'...
  [13:24]kbkand I found a bunch of Tcl code, and then...
  [13:24]kbk... native code in the Tclxml and Tclexpat packages...
  [13:24]kbk... both of which are readily available in source form.
  [13:24]kbkSo it looks as if downloading and unwrapping the starkit gives you all the pieces.
  [13:24]<siyb>thanks 
  ...
  [13:34]akuWe should possibly still ask jcw if he would be willing to put the sources up on github
  [13:36]kbkMaybe... didn't the 'webdav' package get added to Tcllib at some point? That's really all that the kit is: webdav + dependencies (base64, Tclexpat, Tclxml, and uri)
  [13:37]akuHm. Let me check ...
  [13:38]akuNo, no webdav in tcllib
  [13:58]kbkhttp://wiki.tcl.tk/13480 says, "The webdav and davvfs packages have been submitted to Tcllib for consideration, review, and possible inclusion."
  [13:58]kbkso it's obvious what Jean-Claude's intention was.
  [13:58]akuHm.
  [13:59]akuI don't remember that. I'll have a look through the bug database ...
  [13:59]kbkSuspicion: does the XML stuff (expat+tclxml) always require native code, and if so, did that cause a rejection?
  [14:00]akuIMHO should not. (Even if would prefer tDOM)
  [14:01]akufound it, assigned to Pat - 1115865
  [14:06]kbksiyb - Looks as if we dropped the ball about 6.5 years ago, but we're picking it up again. Better late than never.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This problem is fixed in the CVS.

  2004-11-22  Andreas Kupries <andreask@activestate.com>

  * rational_funcs.tcl: Removed bad source'ing of file
    polynomials.tcl. Depended on current working directory in the
    right place, and superfluous as well, as immediately after a
    'package require' of the package loaded it in the proper
    manner. Disabled the test code at the end as well.


login: skielty
username: skielty
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=355872

  if -drawcross option isn't used -- this doesn't happen -- if it 
  is allways it does -- I didn't check the auto or never options 


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  This was a tkCanvBmap.c issue and has been fixed in 8.4
  branch and HEAD.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  I added tests (14.x) for this feature and will add it to the
  documentation for the next release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Haven't we fixed that in the head ?
  Yes, in April 2005 according to the ChangeLog.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  I was looking for something more limited, but a subset of
  this. I find the width of the log's lines more than
  necessary.  I would like to be able to set the time format
  to be "%D %T" instead of the current default clock format.

  This can currently be done by using logproc to overwrite
  existing logprocs, or by cheating and replacing stdoutcmd
  and stderrcmd (which look to me like they should be
  refactored, since they do the same thing except for the
  channel).


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  One other element that I forgot; right now the log file is
  actually determined by the standard handles for stdout and
  stderr. It would nice if the file handles for different
  levels could be configured. Again, the logproc is sufficient
  to override this, but that's something that must be customized.

  The current definition of logproc does not say what
  namespace the command to execute must exist in.  While there
  is a sample replacement proc, there is no example  logproc
  command to use it. So, would it be ${log}::logproc notice
  ::logtoserver
  ?


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  ProgressBar now makes explicit check, disallowing having a
  -maximum 0.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Creating a server socket and giving port 0 should never be a
  privileged op. Passing port 0 means pick a random available
  port. So the issue is really about Windows XP's firewall
  implementation. 

  Maybe we might avoid this for that platform.

  hmmm


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Replaced on windows with a call to ipconfig which also
  returns information about the IP address on windows 98 and
  above.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  You should use the newer statistics submodule instead.
  (Though it does not - yet - compute the coefficient of 
  variation ...)

  The situation you sketch is one where the coefficient is not 
  defined. The procedure should return a more descriptive 
  message ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Has something happened here ?
  The reference to 'statistics' seems to indicate that we can
  close this entry, no ? Maybe as 'out-of-date' ?


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Looks like we just need to check that these elements are
  present in the array.  Fixed (for 1.266)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It seems jabberlib went and changed the interface for the
  send_iq command - which is a bit rude. Fixed


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This might also need a way to ask for the current serial
  number, no ? I do not believe that we have that already, so
  it needs to be added.


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  We're covered: [$chan config -serial] will give us the
  serial number.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The following script show this problem. It's not leaked
  arrays  or event handles. Watching the process shows no sign
  of leaked memory or windows kernel handles. Must be a tcludp
  limit in the recv queue?

  set file [file join [file dirname [info script]] dns.tcl]
  if {[file exists $file]} { source $file }

  package require dns
  dns::configure -nameserver [lindex [dns::nameservers] 0]

  proc LookupDone {ndx max name tok} {
      if {[dns::status $tok] eq "ok"} {
          #puts "$ndx [dns::address $tok]"
      } else {
          puts stderr "[dns::error $tok]"
      }
      dns::cleanup $tok

      incr ndx
      if {$ndx < $max} {
          dns::resolve $name -command [list LookupDone $ndx
  $max $name]
      } else {
          set ::forever 1
      }
  }

  proc Main {name {limit 10}} {
      set forever 0
      dns::resolve $name -command [list LookupDone 0 $limit $name]
      vwait ::forever
      puts done
  }

  if {!$tcl_interactive} {
      set r [catch [linsert $argv 0 Main] err]
      if {$r} { puts stderr $err }
      exit
  }


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Looks like it is something to do with the DNS activity and
  not just the UDP package. A similar script to the one below
  but using SNTP completed 70000 requests.

  set file [file join [file dirname [file dirname [info
  script]]] ntp time.tcl]
  if {[file exists $file]} { source $file }

  package require time

  proc LookupDone {ndx max name tok} {
      if {[time::status $tok] eq "ok"} {

      } else {
          puts stderr "[time::error $tok]"
      }
      time::cleanup $tok

      incr ndx
      if {$ndx < $max} {
          time::getsntp -command [list LookupDone $ndx $max
  $name] $name
      } else {
          set ::forever 1
      }
  }

  proc Main {name {limit 10}} {
      time::getsntp -command [list LookupDone 0 $limit $name]
  $name
      vwait ::forever
      puts done
  }

  if {!$tcl_interactive} {
      set r [catch [linsert $argv 0 Main] err]
      if {$r} { puts stderr $err }
      exit
  }


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  We were using the query id to locate the DNS state token but
  this restricts us to 65535 queries as the value is packed
  into a short. It isn't necessary and doesn't work.
  You can show this problem more easilly by setting the
  initial value of the uid variable to 65530 instead of 0.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed this - the test file was assuming it was started in th
  e same directory as the source files for plotchart. I took
  the opportunity to make it fit into the test framework just
  a bit nicer. Still requires some work, but at least it runs,
  the windows appear and disappear and it all counts as one
  successful test.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  For future reference, please create patches in unidiff
  format. They have infomration about which file they apply
  the regular plain patch you provided does not have. They
  also have context information which allows the patch to to
  find the location even if in the presen of slight changes in
  other parts of the file, shifting the locations around a bit.


  Also: Please specify exactly which images from the exif site
  you used. I.e. links to the pages containing the image(s),
  liks to the images themselves.

  If possible, can you please attach test images as well, if
  they are not too large ?

  All of the above is required by me so that I can extend the
  testsuite  to cover the new code. Test cases covering when
  encountering an unknown tag should be provided as well, but
  I am willing to drop this part.

  As you said "most 2.2 tags" I would like to know which of
  the tags  are _not_ handled by your code.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Reassigning to Michael Schlenker, AFAIK he was the last to
  touch this code as part of his ASN work.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  After some analysis, it appears that too many configure and
  resize events are being generated, causing Tk's event ring
  buffer to overflow.[1]  As an experiment, I ran the provided
  test program under differing window managers; the shaking
  behavior occurs when differing number of items are added to
  the ListBox.  I see no clean way of resolving this problem.

  [1] This error was first reported as Bug 795608, "tk binding
  problem in Gnome and Ximian".  My analysis to comp.lang.tcl
  may be found at http://tinyurl.com/l6dfd.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  It does not happen for me on current cvs on linux or windows for tk8.5.7.

  This might also be due to an improved locking in the widget.

  I close the bug, complain if it is still an issue.


login: kjnash
username: kjnash
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=991282

  I've run into the same bug:  if a tabbed page is deleted
  from the notebook, its records of pages and indices are
  corrupted.

  Operations like adding or removing further pages may fail,
  sometimes with bgerror.  Pages may be mapped to the same
  index in the notebook, and gaps appear in the tabs.

  Thanks for the fix.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Please try the current CVS head of tcllib, if it fixes this
  it could trivially be backported to the tcllib1.7 release
  version. The installer and confiigure now recognizes and
  respects ./configure --bindir ...

  dtplite is needed to create the nroff and html documentation
  for tcllib

  If it does not work, please report back with your configure
  / install values, so we can check whats wrong. If it works,
  report back so i can close the report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is AFAIK fixed in the CVS head. An 1.8 release is upcoming.
  Is the submitter willing to pre-test it ? so that we can be
  sure that a debian package can be created from it ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The submitter was mailed directly regarding the new release
  too, no response. The entry is now on auto-close row.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is wrong usage. Please try:

  set swg [ScrolledWindow .swg]
  set p [$swg getframe]
  set wg [NoteBook $p.nb]
  pack $wg -fill both -expand 1


login: georgeps
username: georgeps
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=585068

  This looks good.  Thank you :)  I will most likely add it to
  the cvs repository soon...


login: georgeps
username: georgeps
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=585068

  I committed this a while ago.  aku made some minor
  improvements.  Thank you Michael :)


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  This seems to be a simple bug caused by the fact that Tcl
  has two
  logically-equivalent-but-not-actually-string-equivalent
  names for commands:  one which includes the "::" prefix
  indicating the global namespace, and one which does not. 
  The profiler is saving descendent information using the
  unscoped name (no "::" prefix), but then trying to query it
  using the scoped name (with a "::" prefix).

  I added code to the profiler to try and account for this. 
  It should work in most scenarios, but I didn't test it
  exhaustively, so there may be corner cases not handled
  correctly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Three simple typos, refering to 'token' by 'tok'. Fixed,
  committed to head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done in CVS head.
  Keeping the report open, it might actually be a deeper
  conflict between tar and vfs::tar.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825

  fixed as recommended on 9/30/05 by akupries. Open a new 
  report for any new issues or conflicts.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  How does MSIE react to the use of the "title" attribute,
  instead of "alt" ?


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  no idea, but the W3 docs say that's how to set the data for
  such a thing. 'alt' is for display in text-only browsers and
  is not documented to carry the data a tooltip might want. 
  Whereas 'title' is documented to carry such info.


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  just search for 'alt=' and replace it with 'title='

  There's only one in modules/counter/counter.tcl


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  http://www.htmlhelp.org/reference/html40/special/img.html:
  "
  The required ALT attribute provides alternate text for those
  not loading images.
  "

  http://www.htmlhelp.org/reference/html40/attrs.html:
  "
  The TITLE attribute provides a title for an element and is
  commonly implemented as a "tooltip" on visual browsers
  "

  I had always thought alt was for a tooltip since the days of
  IE4, just cause I was used to it..  I had never known it was
  wrong until I started using firefox.

  Some recomendations have said to use both alt and title
  until M$ fixes IE to conform to the W3 standard of HTML
  4.01.  I read that on the firefox FAQ sometime ago.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed the fix to head. Had to move a namespace eval
  before the condition so that the namespace would exist
  before trying to put a variable into it.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Workaround:  
    
  ----------------------------------------------  
  puts [encoding convertfrom utf-8 $t(cn)]  
  ----------------------------------------------  
   
  Why UTF-8 strings resulting from a LDAP search are not 
  automagically converted into Unicode to be handled like 
  normal strings? 


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The ldap package probably just returns the ASN OctetString
  type and does not interpret it in any further, but the
  application is free to interpret it in the way it likes to.
  I need to check the LDAP RFC what is expected to happen with
  the search result encodingwise.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  According to RFC 2253 the string should probably be
  converted to the UTF-8 encoding.
  http://www.ietf.org/rfc/rfc2253.txt
  and
  http://www.ietf.org/rfc/rfc2251.txt
  (Section 4.1.2).
  So yes, this is a bug und output should be converted to
  utf-8 or the encoding given in RFC 2253. Direct access to
  the ASN.1 values should be optionally possible.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  This is not a bug in the LDAP module.  
     
  According to RFC 2251, paragraph 4.1.2, only "LDAPString" types are  
  encoded in UTF8. Decoding depends on the schema used. 
   
  This should be made clear in the documentation. 
   


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  The attached patch provides a correction:
  - addition of a new function ::ldap::api_version, which 
  defaults to 1 (compatibility with buggy API)
  - when set to 2, ::ldap::add expects multi-valuated values 
  for each attribute.

  The new function api_version is meant, in the future, to 
  be set automatically by new functions to manipulate LDAP 
  entries at a higher level.

  This patch also removes duplicated code between asn.tcl 
  and ldap.tcl (asn* functions are removed from ldap.tcl, 
  and some functions from asn.tcl are updated).


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Thanks for the patch.

  Some comments:
  1. prefixing all the calls with asn:: isn't necessary, this
  is a perfect usecase for 'namespace import', so just
  throwing out the duplicated code and adding a namespace
  import works fine

  2. I don't really like the 'api_version' command, such
  things should usually be done with a major version change of
  the package (see md5 for an example where this happend)

  Basically i would just go for fixing the error with multiple
  attributes, so that your $arrtval2 should work, but the docs
  talk about 'dictionary' which implicitly forbids duplicate
  keys in the typical tcl hashtable sense.  

  The main problem with using the list approach (like
  $arrval1) you choose is the fact that there is no way to
  find out if a list or a simple string is passed, so it would
  always require listification of all values.

  Repeating the name and value for multiple values and letting
  the code check for duplicates and create the appropriate
  response set would probably be better. This would change the
  documentation from the strict "dictionary" to the less
  strict "name value list" which would allow duplicate keys.
   
  This had the bonus, that it would not break but only extend
  the current api, and so the package could stay at api
  version 1.x.

  3. What kind of functions do you have in mind when you talk
  about 'higher level functions to manipulate entries'? Would
  be very interested in your ideas there.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  1- I don't like "namespace import". IMHO, it obfuscates 
  the code.

  2.a- Ok for removing api_version command and use a 
  different version number (2.0) for ldapx.tcl. May I 
  seriously change some APIs? Candidates 
  are: ::ldap::connect (take an URI and 
  remove ::ldap::secure_connect, ::ldap::bind 
  and ::ldap::unbind) and ::ldap::search (use a more 
  extensible way of specifying options).

  2.b- attr-vallist (attrval1) or duplicate keys (attrval2)?
  You seem to prefer attrval2, but this is not compatible 
  with ::ldap::search result which should be an objective 
  IMHO. The current spec is buggy, and we cannot cope with 
  it.

  3- I'm playing with some ideas at this time. Follow-up by 
  private mail.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  1. Ok, will consider 'namespace import' or the prefixed
  versions..., both would work...

  2a. In a major new version the api may change quite a bit,
  thats the reason for a major revision, so if you have a
  patch or good ideas, go on.

  2b. Yes, the spec is buggy, so if it is fixed in a 2.0 it
  should be done consistent in ldap search and other places.
  There are other things which should be done (use the SASL
  package and fix the SSL stuff).


login: pdav
username: pdav
mimetype: text/plain
icomment:
  File Added - 189010: ldap.diff2

  Logged In: YES 
  user_id=1268042

  Here is the final (I hope) patch to close this PR.

  - The "add" function allows multiple tuples with the same 
  attribute. This API change maintains compatibility with 
  the old one, while allowing multi-valuated attributes. 
  However, a additionnel loop makes this function slower.
  - A new "addMulti" function extends the API with a list 
  where each value in a pair is itself a list of all values 
  for this attribute.

  So, to summarize:

  1. I namespace-imported the asn module

  2a. There is no API change. Instead, thanks to Michel 
  Schlencker, a new module (ldapx.tcl) will provide a 
  higher-level interface based on Snit objects. The current 
  ldap.tcl will remains as the low-level interface upon 
  which ldapx.tcl is built

  2b. We get the two syntaxes at the same price ;-)

  3. Some progress is being made. But this is no longer 
  related to this PR.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  (msw) I just tried to reproduce it and I can't with 1.311.
  It may depend on the other side's setting of 1-1 chats
  though so not 100% sure it's really fixed.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  (msw) uh, which version... this happened with the up-to-date
  version (or maybe -1) of the time I submitted the bug; I've
  wiped it some time back when I was cleaning up thus can't
  tell exactly which version (i.e. 275 - 282 although the
  interesting question probably is was it 282 or pre-282 - I
  can't tell :( )


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  version had to be 282, introduction of the counter 
  variable was done then.

  The only way I can see this variable not being set would 
  be by using a pre-282 version and updating to v282, or 
  newer, via the "debug->retrieve script" menu.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Added a possible solution (the fix I use, since I really
  need the multi-line text):

  REPLACE in ftp.tcl
  while { [string equal $multi_line "-"] } {
      set number [gets $sock bufline]
      if { $number > 0 } {
  append buffer \n "$bufline"
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line
      }
  }
  WITH:
      if { [string equal $multi_line "-"] } {
          while { ![string equal $multi_line " "] } {        
                 
          set number [gets $sock bufline]
              if { $number > 0 } {
                  regexp -- "(^\[0-9\]+)?( |-)?(.*)$" $bufline
  all rc multi_line buffer
                  append msgtext \n "$buffer"
              }
          }
      }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Christophe, can you walk me through your changes ?

  Having looked at the wider context I think I now see where
  the 'msgtext' variable comes from, and why you said that
  'buffer' is thrown away. Because apparently the 'msgtext' is
  the final destination for the multi-line result, not the
  'buffer' itself.

  I do note that in the current setup the multi-line is
  accumulated in 'buffer'. I wonder why this is not simply
  appended to msgtext after the loop ? In your loop the buffer
  changes from accumulator to contain only part of a bufline,
  apparently. It is further unclear to me why an additional
  'if' was put around the loop, and why the loop-condition was
  changed, double-inverted in a way. I guess I have to see the
  low-level server responses and how they flow through the old
  and new loops. Part of the problem is likely that I do not
  know how a multi-line response looks like at the very lowest
  level, i.e. what exactly is coming in over the control
  connection.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Let me explain me changes:

  A multi-line should the following specs:
  Start with 999(rc) followed by a hyphen (-) and (optionally)
  msgtext
  Followed by line 1
  Line 2
  Line n
  End with 999(rc) followed by a space and (optionally) msgtxt

  Example:

  550-Start of Message
  Line1
  Line2
  550 End if Message

  Why not just append: because in the "original while" only
  the first line is red (condition is equals "-"),
  when reading. You should only start reading if we have a
  multi-line and the reading should stop when 
  the multi-line posistion equals " " (space).


  My approach (Added some comments, and some improvements to
  the previous code):


  # Only start reading the next (sub-line) if the current line
  has the multi-line indicator
  if { [string equal $multi_line "-"] } {
      # Keep on looping until the prefix equals the
  stop_prefix (original rc + space)
      set stop_prefix "$rc "
      while { $stop_prefix != $prefix } {        
          # Read a line
          set number [gets $sock bufline]
          if { $number > 0 } {
              # Improvements to RE:
              # Use curly braces, and remove back-slashes
              # (rc must be three digits and followed by a
  space or hyphen) this I call prefix, this entire prefix is
  optional                       
              regexp --  {^(([[:digit:]]{3})( |-))?(.*)$}
  $bufline all prefix rc multi_line buffer            
              # Add to msgtext, the real 'data'-variable
              append msgtext \n "$buffer"
          }
      }
  }


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  I forgot to copy paste one line of code in my previous post
  (--> set prefix "") :

  if { [string equal $multi_line "-"] } {
      # Keep on looping until the prefix equals the
  stop_prefix (original rc + space)
      set stop_prefix "$rc "
      set prefix ""
      while { $stop_prefix != $prefix } {
          # Read a line
          set number [gets $sock bufline]
          if { $number > 0 } {
              # Improvements to RE:
              # Use curly braces, and remove back-slashes
              # (rc must be three digits and followed by a
  space or hyphen) this I call prefix, this entire prefix is
  optional                      
              regexp --  {^(([[:digit:]]{3})( |-))?(.*)$}
  $bufline all prefix rc multi_line buffer            
              # Add to msgtext, the real 'data'-variable
              append msgtext \n "$buffer"
          }
      }
  }


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  I was thinking about your remark, why not just "Why not just
  append".
  Indeed, if you just add the line "set msgtext $buffer" just
  after the while loop it ALSO works fine.
  I was misled with the RE:
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line

  If we have a multi-line then the multi_line variable
  contains "-".
  For every next line the above RE will not be matched, thus
  the variables "rc and multi_line" will not be touched at all
  (I thought it would initialize it to empty, but NOT).

  The ending line will have a match and multi_line will
  contain a space, the loop will stop.
  So and easier, and less risk solution will be (the entire
  loop + "set msgtext $buffer")

  Code:
  # multi-line format detected ("-"), get all the lines
  # until the real return code

  while { [string equal $multi_line "-"] } {
      set number [gets $sock bufline]
      if { $number > 0 } {
  append buffer \n "$bufline"
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line
      }
  }
                  # This is the added line
  set msgtext $buffer


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks for going through this so thoroughly.
  So, under the assumption that lines between multi-line start
  and end will never have the form of three digits followed by
  blank, followed by whatever we can use a very simple fix. I
  will put this simple fix in first, and then we can think
  more about the assumption and if it truly holds.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Just to make sure "...assumption that lines between
  multi-line start
  and end will never have the form of three digits followed by
  blank..."

  I checked the RFC and this states:
  <<<The user-process then simply needs to search for the second
         occurrence of the same reply code, followed by <SP>
  (Space),
         at the beginning of a line, and ignore all
  intermediary lines.
         If an intermediary line begins with a 3-digit number, the
         Server must pad the front to avoid confusion.>>>

  So this means the problem should never occur if the server
  follows ths specs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Wonderful. In that case I believe that we can consider the
  problem truly and fully solved. And fixed. Closing the bug now.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  This should be an option - clearly some people will want to
  know if a function is not called at all.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  I think this is really a Tcl bug, but for the time being,
  it's probably a good idea to provide a workaround here.  The
  Tcl bug in question is this: 681877


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  I think you must be misunderstanding something.  The
  profiler makes no distinction between time spent "executing
  Tcl code" versus "executing C code".  In fact, practically
  speaking there is no way that it could do so.  I offer the
  following counter example as proof:

    package require profiler 1.6
    ::profiler::init

    proc testProf {} {
        after 3000
    }

    testProf
    testProf
    testProf

    puts [::profiler::print ::testProf]


  Here I have used the [after] command as a stand-in for your
  [C1] command.  Keep in mind that just like [C1], [after] is
  implemented in C code, and by definition, [after] takes some
  significant amount of time to execute.  When I run this in
  my interpreter, I get the following output:

  Profiling information for ::testProf
  ============================================================
              Total calls:  3
      Caller distribution:
    GLOBAL:  3
             Compile time:  3001000
            Total runtime:  9021000
          Average runtime:  3007000
            Runtime StDev:  5292
           Runtime cov(%):  0.2
    Total descendant time:  0
  Average descendant time:  0
  Descendants:
    none

  You can see that the time spent in the [after] command
  itself is clearly accounted for and billed to the testProf
  procedure.

  I happened to have my own Tcl extension here that implements
  several new commands, and I repeated this test calling those
  commands from testProf instead of [after], just to be sure
  that the profiler was not somehow treating built-in commands
  specially.  I obtained similar results with this experiment
  as well.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Thank you very much Eric for your careful handling. I will
  work more with the profiler and let you know if I meet some
  special behaviors sometime.


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=456242

  (I seem to be having trouble attaching the file; email me if
  you need it)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I bet that this was due to MD5 processing with the (new for
  8.5a2) arbitrary-length integers. The MD5 package was fixed
  to keep the calculation restricted to a 32 bit values size
  even when arbitrary length integers are available.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Applied. Parts of jabberlib require 8.4 so there is no going
  back to 8.3 support now.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  As Tile v0.5 is being package required, there's also no 
  need for a check on the ttk:: namespace, and as the 
  namespace is being imported there is no need for the use 
  of ::ttk::scrollbar anyway (that the first patch was 
  changing tscrollbar to).


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  updated patch to current head.
  This patch removes the ttk:: and tile:: namespace checks 
  as Tile v0.5 has changed over to ttk:: fully.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  File Deleted - 133259: 



  File Added - 133295: tkchat.NickListv2.diff

  Logged In: YES 
  user_id=596509

  Updated patch.
  Found a problem in addAction proc, where it was creating a 
  new nick in the nicklist for bridged messages. (ie. it was 
  leaving '<' and '>' on).


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  File Added - 133614: tkchat.NickListv3.diff

  Logged In: YES 
  user_id=596509

  updated for current head. v1.287


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In your example, are transmitter and receiver of the
  commands in the same process ? Have you tried this across
  different processes ?

  I am trying to understand the exact nature of the problem,
  and the examples given are a bit short.

  For example I do not see described where any of the errors
  is reported, in the client, or in the server process ? That
  does make a difference for the sync and async calls.

  Note also that 'after 1000 comm::send' is not async call. It
  is delayed invoked in the client, but the communication is sync.

  Async communication is 'comm::send -async {...}'.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirmed for the HTML tarball. However the Windows CHM is
  ok. This has to be a glitch in the ActiveTcl build system,
  not in tklib itself. Please report at the ActiveState site.
  The tktable problem has already been reported at the
  Activestate site.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Hi Andreas,
  I will if you can provide a link. Following advice I got at
  clt I already tried to find the correct place at
  activestate.com to submit it there, but didn't see anything
  obvious.
  Thanks
  Helmut Giese


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. I am quite sure that I would not use a report object to
  convert a matrix to csv. That can be done much more
  directly. Get all cells of the matrix, which is a list of
  lists, then iterate over the outer list and use csv::join to
  generate the csv lines, [join] them. ... I better pack that
  into a utility procedure.

  Are there any other use cases there a report with a
  right-ragged column makes sense ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  proc ::csv::joinmatrix {matrix} {
      set csv {}
      foreach line [$matrix get rect 0 0 end end] {
  lappend csv [joinlist $line]
      }
      return [join $csv \n]
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Oops. I was to quick, buggy. It is much simpler.

  proc ::csv::joinmatrix {matrix} {
      return [joinlist [$matrix get rect 0 0 end end]]
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirmed. Difficult to solve. We have to protect special
  characters in the string we try to flatten while stripping
  out a listlevel. The latter _requires_ eval, not using it is
  not an option.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A fix has been committed to the CVS head. The testsuite has
  been expanded to cover this, and similar cases.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Cross-reference. See patch
  http://sourceforge.net/tracker/index.php?func=detail&aid=1254934&group_id=12883&atid=312883
  for a possible solution.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The test case attached to the patch definitely shows the
  \r\n's added to a part, by part creation, and part composer
  repectively.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The original patch was incomplete, a new patch has been
  added to the cross-referenced entry. Please test.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed the patch, this should be fixed now. In the demo
  of the x-ref entry it is.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  mime::getheader $token  returns a list of header value pairs.
  getbody doesn't make sense for a multipart message.


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  > getbody doesn't make sense for a multipart message.

  ?? Then how do I combine the mime and http packages
  to implement HTTP form data?  The http package wants
  the body separately.  At least that was the case when
  I filed this RFE, I admit that haven't looked at the
  issue since.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Confirmed the problem. All other .msg files are ok. Note
  that the fr messages are incomplete as well. Compare to
  c.msg which also has the TOC and IDX related messages.

  Fixed, and committed to head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is a problem for Pat. He maintains the md5 critcl
  stuff, and has possibly integrated it into smtp. It might
  also be a problem in the md5 package itself.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Does this still happen with the current CVS head of Tcllib ?

  The only place I can think of where this can happend is the
  procedure "md5_init" in smtp.tcl. Can you check that this
  procedure is executed ? It does a regular "package require
  md5". Was md5 loaded before ? If yes, what version. If not,
  then we are likely getting v2, which is in md5/md5x.tcl, and
  it tries to load md5c in md5::LoadAccelerator. However this
  procedure catches any error from that, so you should never
  see the 'no package md5c' error.

  This part is however something which was rewritten some time
  ago, so maybe the old way of looking for md5c did fail.

  Hence my question at the beginning.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I'm going to junk this. I've never seen this occur and there
  have been no other similar reports
  Also, I'm just removing all the authentication code from
  smtp.tcl and replacing it with code that delegates to the
  SASL package for this purpose.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Actually this can be resolved by simply counting
  subsections, i.e. generating an anchor based on a unique id
  instead of the title. Of course, [sectref] section
  references still need disambiguation.

  A palliative might be to look for the section the subsection
  is in and use it in the construction of the anchor. ... Ah,
  not quite, still needs disambiguation of references ...

  Ok, it seems the best we can do without user intervention is
  warning. For reolsution of ambiguities we need a syntax
  change in the format. I.e. sectrefs, sections, and
  subsections need optional arguments for guide resolution.

  Added code generating warnings to the CVS head. Common
  layer, not the engines. ... In tcllib this code is tripped
  currently only by the snitfaq.

  Keeping open until a complete solution has been committed,
  albeit at lower priority for now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Will, what do you think would be a way for the author to resolve the ambiguity without changing the titles ?


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: YES

  Basing section cross-references on the section title strings was a mistake, I think.  It works for small documents, but
  breaks down for larger ones.

  What I've started doing in my personal code, when formatting larger documents, is give each section a tag which
  is a list of period-delimited tokens.  Toplevel sections get a tag that's a single token, i.e., "intro".  Subsections
  add a token, i.e., "intro.history" is a subsection of "intro" and "intro.history.ancient" is a subsection of "intro.history".
  Cross references use these tags instead of the section titles.  As a bonus, the structure of the tag indicates both
  the level of the section and its parentage; you can nest subsections arbitrarily deep, and generate section numbers
  automatically if you choose.

  Note that the command used to indicate a cross-reference can be smart about this: it can recognize both section titles
  (as it does now) and tags.

  This would mean updating all of the Tcllib documentation (ugh) but it's probably worth it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Mistake - Quite likely. So you have code like

      [subsection FOO intro.history.ancient]

  etc. in your documents ? Or do you use two commands ?

      [subsection FOO][label intro.history.ancient]

  ? (The second would be the LaTeX approach).

  Updating Tcllib. With a smart [sectref] and the tags themselves optional updating the sub/section info and references can be done incrementally.

  Hm.     [subsection FOO intro.history.ancient]
  or      [subsection intro.history.ancient FOO]

  Both can support optional tags. The second form is like [uri].

  Deep nesting of subsections ... If we do that, it seems that we would not need section and subsection commands anymore, just a section command ? (Right now doctools does not have arbitrarily deep nesting).

  In general I think that tagging makes sense. LaTeX uses tags as well, except that tags do not need to have structure. They are just labels for locations. Nesting is limited, and each level has its own command.

  Will do some more thinking.

  Thanks for the comment.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: YES

  I have a "section" command that looks like this:

    <<section intro.history.ancient "Ancient History">>

  Also, I've switched to using "<<" and ">>" as my expand brackets, in place of "[" and "]".  When
  documenting Tcl code, "<<" and ">>" is less like to cause confusion.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed in head. (sub)sections can be given logical names for use in (sub)section references. Anchors are generated internally, different from both (sub)section titles and logical names, always unique (counter). The system warns about ambiguous (sub)section names.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  I'm not sure how to fix the problem.  In the mean time, I
  added a note to the man page that %W does not work.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is by design. An access to the label window path is not prevued.
  Instead use the returned node id and the provided functions to manipulate the node.

  I removed the remarks in the docs about that.
  IMHO this should not work. We are on a higher level here.

  Technically, canvas items have no window paths and thus could not be returned.

  Please reply in case of other opinions.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  OK. RFC 2821 sec 3.7 agrees. Fix committed. The core server
  will accept such addresses and the programmer can then
  decide what to do in the validate_sender procedure.

  The example smtpd code will reject such mails.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Closed as duplicate, requested by Don.
  The original RFE is

  http://sourceforge.net/tracker/index.php?func=detail&aid=1225868&group_id=12883&atid=362883


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  This is a duplicate to:
  http://sourceforge.net/tracker/index.php?func=detail&aid=870429&group_id=12883&atid=112883
  Bug: 870429.

  Michael


login: nobody@164.129.1.42
username: nobody@164.129.1.42
mimetype: text/plain
icomment:
  Logged In: NO 

  to win :

  html::init {text.size ""}
  puts [::html::textInput "txt" "myValue" {size="23"}]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, very nice bug report.

  Specially, because some lines upwards, the non-existance case is handled in a similar way.

  Updated in cvs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is not a bug, but a request for enhancement. I am
  rejecting this request as featuritis we should avoid. It is
  easier and simpler, IMHO to simply negate the condition in
  the used filter command. I should also mention that I
  believe that the number of options lsearch has is already
  way to high, i.e. it makes a bad example to convince me.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  I have been able to trace this problem down to 
  the ::ftp::CopyNext routine and the StateHandler routine. 

  The CopyNext routine will always unset ftp(state.data) 
  once the transfer is complete or there is an error.  Then 
  the StateHandler routine in the put_sent switch arm, will 
  try to unset it again if the return code is not 1 or 2, 
  and it's passive mode.  

  All that's needed to fix this is either a catch, or a 
  cleaner way would be something like:

  if [info exists ftp(state.data)] {unset ftp(state.data)} 
  in the StateHandler routine.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thank you for tracking this down. I went the easy route of
  wrapping the offending command into a catch. The code had a
  lot more of them, in basically all of the xxx_sent states. I
  decided to wrap them into 'catch' as well for good measure.

  This has been committed.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I think you have interchanged the first two arguments: first
  the x values then the y values.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  OK. Simpler is to give -maxlen 0 to the base64::encode
  command to turn off the wrapping functionality.

  I'm not going to do this to DIGEST-MD5 unless there are
  reports of similar problems.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I checked it on Windows and Linux - works for me.

  Could you please check, if there is still an issue ?

  Thank you,
  Harald


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  allow_comments - 1

  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Fixed the message used for SNTP - as TIME servers don't care
  what message they get we will send the SNTP request to TIME
  servers too.

  The module is for network time protocols (hence the
  directory name) and the first one implemented was for the
  TIME (RFC 868) protocol. It turns out that there are
  insignificant differences between the implementation for
  TIME and for SNTP (RFC 2030) so I left the package as 'time'
  and just added a 'getsntp' api.

  I don't see any good reason to restrict the SNTP usage to
  UDP - but I have added comments into the man page to point
  out the likely requirement for UDP. In theory SNTP could be
  operated over TCP and I note that the services file reserves
  port 123/tcp and 123/udp for ntp.

  Added support for ceptcl in addition to tcludp for UDP support.
  I've checked the new implementation against ntp2a.mcc.ac.uk
  and ntp.blueyonder.co.uk for SNTP access along with a local
  server running OpenBSDs minimal NTP server.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Sorry forgot to include version number.

  tcllib-1.7

  I believe the solution should/would be to have the Makefile
  install target pass the ${prefix} and ${exec-prefix} to the
  install.tcl script

  Instead, it appears to be taking the name of the tclsh program.

  Thanks.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Arjen, this is likely not a problem in the installer, but in
  how you updated your tcllib workspace. My guess is that you
  used a plain  "cvs update", right ?

  You have to run "cvs update -d" to ensure that any _new_
  directories in the CVS are created in your workspace as
  well. -d for directory. A plain update ignores new
  directories, which is bad. And the fully proper way is to
  use "cvs update -dP". The -P option ensuring that
  directories which were emptied in the CVS are removed from
  your workspace (Prune).


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  You are (of course) completely right: I always do "cvs
  update" without any options. Hm, it looks like I should
  change that habit to "cvs update -dP"

  Arjen


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yes, definitely. To not have -dP as defaults is IMNSHO a
  misfeature of the cvs client.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It doesn't seem to me to make any difference to the output.
  I tried to create a test for this condition and plumped for
  test mime-9.0 {bug 1254934} {
    list [catch {
       set toka [mime::initialize -canonical text/plain
  -string testing]
       set tokb [mime::initialize -canonical
  application/octet-stream \
             -string [string repeat \0 160]]
       set tok [mime::initialize -canonical multipart/related \
            -parts [list $tok1 $tokb]]
       set r [mime::buildmessage $tok]
       mime::finalize $tok -subordinates -all
       set r
    } res] $res
  } {0 {}}

  Checking the output with and withouth these "\r\n" appended
  makes no difference to the buildmessage output.

  Can we get some sort of test case that shows the problem?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Erland, please provide a test case or example of the bug,
  and how it is fixed by you patch.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  The test case is a bit complicated - it involves setting up
  a web server script (I use PHP) to receive an uploaded file,
  and calculate a checksum which will differ from the sent file.

  The Tcl code is fairly cumbersome to handle HTTP headers and
  what not.

  I need some time to extract the relevant functions from my
  code and construct a nice, minimal test case, maybe with a
  PHP script as the client. I will be revisiting the upload
  part of my project soon, I'll get back to you with the test
  case. 

  Thank you for your attention.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Ok, here is a demonstration of the problem.

  This Tcl program (testMIME.tcl) uploads a file
  (transferFile.txt) to a web server (currently connects to
  one of my servers, I will also post the receiving PHP script
  so you can put it on the server of your choice).

  The program will print the size of the file, and then show
  the response from the web server. In my case I created a
  text file with the word 'Hello'; the Tcl script reported a
  file length of 5, and the HTTP server a file length of 7.

  You will have to create the transferFile.txt.

  I believe my patch fixes this discrepancy.

  FWIW, I wish Tcl's http class had a method for doing this.
  The code in testMIME is taken from examples on the Tcl Wiki.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Does anyone have the time to look at the testcase (if you
  have a PHP5 web server, then it shouldn't be too hard)?

  As I believe this is a bug in the Tcl MIME handling, that I
  believe I fixed in August, if would be nice if someone could
  take the time to hopefully approve it and get it checked in
  (or comment on any objections).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Running the tet script I see the webserver reporting an
  11-byte 'hello world' as 13 byte. Adding more logging of
  values to the script I find:

  The part generated in 'form-data-add_binary' seems to be ok.
  It has \r\n at the end, this however might be very necessary
  to put the separator line later closing the part on its own
  line.

  However the message then composed from all the parts, in
  'form-data-compose' has an additional \r\n before the
  separator line.

  There seems to be a disagreement between parts and their
  umbrella which of them has to add the \r\n for the separator
  line to the whole message. Now apparently both do it.

  It is unclear if this happens only for encoding binary.
  This has to be tested.

  I wonder if the problem is that the binary part is not
  generated with some 'size' information in the headers.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Cross-reference: See bug report
  http://sourceforge.net/tracker/index.php?func=detail&aid=1213527&group_id=12883&atid=112883


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Tried out the patch and have to report that the provided
  patch does NOT solve the problem. The path in question in
  question is actually not used at all by the demo ...

  Now trying to find the code paths actually used.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Note: Whatever we do to buildmessage and helpers we will
  likely have to replicate for copymessage and helpers as
  well. 'build...' is for getting a string, 'copy...
  ' writes directly to a channel. Structurally they should
  work identically.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The command is 'buildmessageaux'. It has a 3-way switch for
  file, strings, and parts. The patch modified the 'file'
  branch. Modifying the 'string' branch provides the desired
  result. Given the structural similarty the fix to the file
  branch is likely right as well, just not used in the example.

  An alternate fix might be to change only the 'parts' branch,
  as that is where the \r\n in fron of the separator line is
  added.

  This depends however on what a plain part would look like,
  outside of a composition. Gut feeling tells me that making
  the change in parts is wrong.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003


  Ah, slogging through the relevant RFC's showed the solution.
  According to RFC 2046 the \r\n before the boundary itself
  belongs to the boundary, not the body, so changing the
  'parts' branch is out. It has to be 'strings' and 'file'.

  I will make a new patch and upload it here.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Aamer,

  I have to delete this entry. The inlined manpage is
  unreadable (*) in both the HTML and in the notification
  mails generated by SF. And the latter has the additional
  problem of causing SF to mail _very large_ mails around, as
  it duplicates the whole comment thread, including your large
  initial manpage.

  Please refile this report, and attach not only
  ipExtension.tar.gz, but also the manpage.

  (*) I am not sure what format the manpage is in, but it is
  not a plain text format. Possibly *roff output ? If so,
  attaching the file is again the right thing to do.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Pat, pretty please give me an opinion if this can be added
  to Tcllib, or if additional work/polishing is needed to
  bring it to up to our standard.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Decided to accept the code and integrated it. Committed to
  CVS head.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  The two constants '0' and '1' have been defined in each
  high-level proc.
  The test suite was improved with new tests, including tests
  not devoted to this evolution. (division, modulo, remainder...)

  A hook (_treat) was created to handle the constants :
     _treat var ?var ...?

  Replace each variable named 'var' by the internal
  representation if it is equal to one of the constants : '0'
  or '1'. If the variable is already in internal repr, nothing
  is done.

  Please close this feature request, or tell the issues, if
  they are some.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  I was thinking about this myself for -validatemethod.  I
  wanted to be able to allow things like:

  option -place -default center -validatemethod [list ListOf
  $placeValues]
  option -modal -default none -validatemethod [list ListOf
  $modalValues]
  ....


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  The current behavior is as it is by design; there was considerable discussion
  on the Snit mailing list about at the time.  I forget the details; you can find
  them in the Snit mailing list archives (which you can find via the Snit
  home page, http://www.wjduquette.com/snit).

  As for the -validatemethod, it will soon be deprecated; it's being replaced
  by a "-type" option.  I've got the code written and will be starting on the
  documentation updates this week; the new version will be included in
  the Tcllib release for this year's Tcl/Tk conference in October.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  Note that "option -type" is now available in CVS.  As for updating -
  configuremethod and -cgetmethod as described here, I'll have to think about it 
  some more.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is for instance only used with the parameter -message of MessageDlg which is renamed to -text.

  Test script:
  MessageDlg .d
  Sets option:
  -> option add *MessageDlg.frame.msg.message  widgetDefault
  When applying the proposed patch, this is:
  -> option add *MessageDlg.frame.msg.text  widgetDefault
  Which sounds reasonable.

  OK, updated in CVS.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  My problem is that I currently have no good idea for the
  commands needed to define tables. Not sure if the HTML style
  is good enough, or if something more like TeX should be used
  ... How far do we wish to go with cells spanning multiple
  rows and/or columns ?


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  HTML, Latex, tbl (nroff) and docbook all support column
  headers, boxes around the table, framing each entry,
  multiple column spans, multiple row spans, highlighting
  entries (bold, italic), and some other features.

  I'd be happy starting out with defining a table in each
  format engine's default form.  Then it should be straight
  forward to add other features later.

  All of the engines define tables with commands for each row
  and cell entry.  We could have a syntax with commands for
  each row and element, but this would be pretty verbose.  I
  would vote for one command per row, or even one command per
  table, something like shown at the bottom of
  http://wiki.tcl.tk/3150 (Displaying tables).

  [begin_table]
  Quantity                Unit Name    Abbr.
  Length                  meter        m
  Mass                    kilogram     kg
  Time                    second       s
  [end_table]


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Is the column separator in your exmaple multiple spaces, or
  tabs, or one space, or a mixture ? ... Wait, one space
  cannot be a separator in your example, see 'Unit Name',
  which is in one column.

  Maybe several table commands, from the most primitive to one
  which supports lots of features ?


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  Oh, drat.  I meant to quote "Unit Name" as a single word. 
  And now that I look at it, I've got the begin/end backwards too.

  If I was going to make up a syntax, then I'd try to parallel
  manpage_begin/end and list_begin/end.  Both mark the start
  and end of blocks, and other doctool commands are valid
  within the block.  I like the simplicity of using Tcl's
  natural line and word boundaries to denote row and element
  breaks, but I can imagine optional row and element commands,
  [row] and [elem], and a special command for the header row,
  [header].

  Although a few doctool commands have optional arguments,
  none of them have Tk-style options.  But I think that would
  be the best way to implement table appearance features. 
  Options to [table_begin] would apply to the entire table. 
  Options to [row] would apply to the whole row, and options
  to [elem] would apply to just that element.  Just for fun,
  include a [columns] command, which takes a list of option
  lists, and applies them to each column in the table.  Common
  options would be

  -align {left center right}
  -colsep {true false}     draw a line to the right of the cell
  -rowsep {true false}     draw a line below the cell

  Options just for [table_begin] would be

  -title "table title text"
  -frame {all bottom none bottom sides top topbot}

  And I've grown fond of grid's relative placement syntax, so
  I'd use that to denote entries spanning more than one column
  or row.

  So without careful declaration of all the syntax, I present
  some examples of how you might use these commands.  For
  starters, apply some global formatting to the table with
  attributes supplied to [table_begin].

  [table_begin -align left -frame none]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  [table_end]

  Generate the same table, but center the rightmost column, so
  we need both [row] and [elem] commands.

  [table_begin -align left]
  [row Quantity      "Unit Name"  [elem -align center Abbr.]]
  [row Length        meter        [elem -align center m]]
  [row Mass          kilogram     [elem -align center kg]]
  [row Time          second       [elem -align center s]]
  [table_end]

  But if we have a [columns] command, then we can apply
  formatting to just the third column.

  [table_begin -align left]
  [columns {} {} {-align center}]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  [table_end]

  Same table, but use a special [header] command for the first
  row, which might give it special highlighting.

  [table_begin]
  [header Quantity   "Unit Name"  Abbr.]
  [row Length        meter        m]
  [row Mass          kilogram     kg]
  [row Time          second       s]
  [table_end]

  Create an entry in the second column which spans two rows,
  using the [grid] command's relative placement code.  This
  will render the "meter" entry in a box that is two rows
  high.  In the case of nroff format, it will probably leave a
  blank line.  This implies quoting single characters of ^, x,
  and - somehow, to avoid the special meaning.

  [table_begin]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass            ^          kg
  Time          second       s
  [table_end]


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Huh. I'll have to think about the various examples ... First
  "-quoting in regular text is not something the frontend
  recognizes. It is simply passed to the backend. This is
  important because all structural stuff should be in the
  frontend, and nothing in the backend. ... In your example I
  would have to handle the text between the table begin/end
  markers as a CSV, apparently. Except when the row/elem
  commands are used ... Definitely not easy to parse ...

  More thinking required.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  Almost Free Text (http://www.maplefish.com/todd/aft.html),
  txt2html
  (http://txt2html.sourceforge.net/txt2html.html#input_file_format),
  and txt2tags (http://txt2tags.sourceforge.net/rules.html)
  have methods of supporting table output based on character
  markup coming in.

  Just to show some examples of how other processors handle
  the task.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  Thanks for the examples, David.  I see that from these, and
  the others with which I am familiar, just about everything
  requires some sort of delimiter between column entries.  And
  I've also looked at how the formatting engines handle lists
  and examples.  

  It appears that for the "plain" formats I suggested, using
  line delimters for rows and word delimiters for columns, it
  would be necessary to have fmt_plain_text change modes of
  operation in a table environment.  This is presently only
  done for latex examples (as far as I looked).  So it would
  take a global (i.e., _in_table) and a switch inside of
  fmt_plain_text to make it work.

  It would also be possible to only support a single-command
  format for a  table, much like the short form of example. 
  So your table would be created with something like:

  [table -align left -title "Units Abbreviations" {
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  }

  This has the advantage of having all the table data in once
  piece, so you can compute column widths for text formats. 
  Your choice as to using Tcl words or a special delimiter
  character to deliniate column entries, but I think I still
  prefer words, just because it seems tclish.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This looks pretty good. First some performance comments
  - All [expr] expressions should be braced - [expr {....}]
  - Avoid excessive [expr] eg: if {[expr ...]} is better
  written if {(...)}
  - You can copy arrays quickly using [array set tempState
  [array get state]]
  - The inverse sbox function is twice as fast if we use a
  table lookup.

  by making the above changed changes can speed the encryption
  from about 26000ms per iteration to around 8000ms per iteration.

  Second I would think the programming API should be closer to
  that used for rc4 and blowfish in tcllib. I would rather see
  an aes::encrypt and aes::decrypt pair - but more importantly
  I think we should be able to do:
   set key [aes::Init $secret cbc]
   while {receiving data} {Output [aes::Encrypt $key $data]}
   aes::Finish $key
  in other words maintain all state in a opaque token that is
  created by Init and cleaned up by Finish and permit calling
  Encrypt or Decrypt multiple times. This fits well with use
  with network channels where we want to use the
  Encrypt/Decrypt call in the fileevent body on chunks of data
  read from the stream.

  It is also important that we can do ECB and CBC mode
  encryption - it's not specified anywhere what mode is being
  done here and I've not tried to work it out yet.

  Attaching my performance enhanced version.

  Nice job though. :)


login: fattobi
username: fattobi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1333726

  Thanks for the quick response and performance improvements.

  At the moment, there is no chaining of blocks implemented,
  just one block gets en-/decrypted.
  I will work on the API, but don't expect it done too soon.

  Thanks for your help,

  Thorsten


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Imported into CVS so that we can properly maintain the
  history of this code. I will try and fix the programming
  interface before we release the next version of tcllib.
  Fixing the API should also make supporting CBC mode simpler.
  New module: aes


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Integrated with CVS head. some shuffling, utilities are in
  their own namespace, not "::logger".


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The math tests are a likely source of changes to
  tcl_precision. We can check this by

      tclsh sak.tcl test math units

  Confirmed. The above is enough to cause the unit tests to fail.
  We should bring "sarnold75" and "arjenmarkus" into this.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Grepping ...

  bigfloat, calculus, lingalg, optimize are the math packages
  whose testsuites change tcl_precision.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  This can be fixed by setting tcl_precision back to the
  default in units.test.  This would work around the side
  effect from other unit tests.

  Perhaps a different solution would be to have the math
  libraries reset tcl_precision to the default after they are
  done with it.

  But the real root of the problem seems to come from tcllib's
  all.tcl, which goes to great length to run all the module
  tests in a slave interpreter.  Since all interpreters share
  tcl_precision, it leaks between modules.  It is also leaking
  ::env, and this scheme may also have trouble with tests
  checking -output and -errorOutput.  This might be causing
  the errors in docstrip.test.

  So why doesn't tcllib just execute tcltest::runAllTests,
  like everybody else?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Even with [runAllTests] these
  leakage issues ought to be
  addressed to support the
  -singleProc 1 configuration.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  runAllTests - Likely for historic reasons.

  Note however also the insertion of special test contraints,
  and helper commands. IIRC these are not done by runAllTests.
  I would say that this should be reported in a new entry, and
  investigated separately from these failures.

  I agree that the math tests should take care to restore the
  tcl_precision.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The tests check these branches. The if branches seem  to not
  trigger correctly and the value is formatted by the next
  larger range with the wrong extra padding.

      if {($number >= -8388608) && ($number < 8388608)} {
          set numberb [expr {$number & 0xFFFF}]
          set numbera [expr {($number >> 16) & 0xFF}]
          return [binary format H2H2cS $tag 03 $numbera $numberb]
      }
      if {($number >= -2147483648) && ($number < 2147483648)} {
          return [binary format H2H2I $tag 04 $number]
      }
      if {($number >= -549755813888) && ($number <
  549755813888)}     {
          set numberb [expr {$number & 0xFFFFFFFF}]
          set numbera [expr {($number >> 32) & 0xFF}]
          return [binary format H2H2cI $tag 05 $numbera $numberb]
      }

  This is entirely strange..., kann someone please check that
  if is sane on solaris..., basically this check fails:
   
      set number 8388608
      if {($number >= -2147483648) && ($number < 2147483648)} {
             puts "ok"
      } else {
            puts "bad"
      }

  I do not have a solaris box to test on...


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Thanks for looking into it.  The
  bug is in Tcl 8.5a4, now reported
  as 1274287.  You'll want to keep
  an eye on it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Still an 8.5 specific problem, different (default)
  precisions. Should we  use 'format' to round the value to a
  specific precision ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Went with my idea and used 'format' to get results with a
  deterministic precision across all versions. Committed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The difference is in the floating point values of
  FocalPlane(X,Y)Resolution. In Tcl 8.5 the value has several
  more digits.

  We are not tracking this until the Tcl 8.5 numerics have
  stabilized.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Went with my idea and used 'format' to get results of a
  deterministic precision across versions. Committed.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  I could not reproduce the bug : I ran the testsuite successfully
  My environment is ActiveTcl 8.5a3 and Tclkit85a2 on WinME.

  Please, could you grab the latest 'bigfloat.test' from CVS
  and make a more precise bug report.
  Could you also give a short description of your environment.
  But the best thing would be to isolate *one* command that
  failes in your environment.

  Regards,
  Stéphane Arnold


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Thanks for the renumbering.

  The failing tests are 2.6c and
  2.6e.

  This is with the latest HEAD
  of Tcl development sources, 8.5a4.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  I found the reason : it is a bit strange, but
  in Tcl 8.5a3 :
    expr round(0.5) gives 1 and
    expr round(-0.5) gives -1
  and in Tcl HEAD 8.5a4 both expressions return 0.

  Should we close this bug report and submit one in Tcl.sf.net?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  the change in Tcl 8.5a4 is likely
  an intentional change away from
  the (arguably buggy) biased
  rounding rule "0.5 rounds to the
  integer with greater magnitude"
  to the unbiased rule "0.5 rounds
  to the even integer".

  A bug report should still be opened
  on the topic, so it's clear that there
  are at least test scripts that do care
  about the change.  You should also
  review just what it is you are trying
  to test and whether it can be done
  in a manner not sensitive to this
  fine detail of Tcl's rounding rule.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  With Tcl 8.5 HEAD, these now fail
  in a different way:

  syntax error in expression " $msg == Infinity ": extra
  tokens at end of expression


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  This happens specifically with Tcl 8.5 (I tried on
  Sun/Solaris with Tcl 8.4.3 - that worked fine. It also
  worked on Windows XP with Tcl 8.4.1 and 8.4.5)

  Something is seriously wrong then! 


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  dgparjen, miguel: just a guess, but 1272910 is likely a
  tcl_precision sensitivity getting exposed.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530



  It appears that fixing Tcl
  Bug 1275043 has fixed this.
  Please confirm and close.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I can confirm this: tclkit 8.5a4 returns the same result as
  Tcl 8.4. So, indeed: closed


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Oh, oh, the profiler is using clock internally, and in 8.5
  they are procedures and thus show up in the trace. Hm. I am
  not sure if we can exclude them, as they may _also_ come in
  due to the profiled code.

  So maybe just using a version dependent test result to fix
  this ?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  simplest thing would be a more
  forgiving match like -match glob
  or -match regexp.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Duplicated the test. Original constrained to 8.4-, new
  variant for 8.5+ with changed result. Committed.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  This looks like Tcl bug #1220058.  It has to do with having a rename trace 
  on a namespace ensemble that gets renamed out of existence.  This 
  should be transferred over to the Tcl bug tracker rather than the Tcllib bug 
  tracker.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The non-Trf versions use ` as this is the 0 byte
  representation and this follows other uuencode
  implementations (notably perl's pack('u', ' ');) The tilde
  character is invalid which makes it helpful in recognising
  excess bytes but may cause interoperability problems for
  other decoders. In standard usage each line is prefixed by a
  byte the gives the length in bytes of the relevant data so
  the choice of padding should not be too important.

  Interestingly I looked for a standard and found IEEE Std
  1003.1-2001 gives a specification for uuencode which
  specifies = as the padding character! Solaris'
  implementation is using a space.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In other words, this area is even more of a mess than I thought.
  :(
  Ok,  I will consider this a low-prio thing then.
  Get to unconfuse the testsuite first/only.

  Hm. Might make sense to choose a padding character we can
  easily detect later and then convert into whatever is needed
  for compatibility when the result is used in specific tools,
  like uuencode.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, I committed a change which deconfuses the testsuite's
  belief about which accelerator is loaded and active. Keeping
  this open for dealing with the padding mess, retitled entry
  for that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted and committed the patch. I also added an "unset v"
  statement after the loop, as the variable is not really
  needed after the initialization.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  We now provide a jabber accessible pasting site at
  paste.tclers.tk so we should hook up to send messages to
  there. It replies with the new URL.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Added a dialog and menu items to send clipboard or pasted
  text to the paste.tclers.tk site.


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  I get the same problem here while just sending mail (I am not doing 
  anything with dates myself).  Smtp.tcl calls 
   
    parsedatetime -now proper 
   
  and that throws an error, just because I am on de_DE. There is no 
  valid reason for that to happen here, I think. 
   
  I don't know if the other parts of parsedatatime are a 
  problem or not, they are not used in mime.tcl or smtp.tcl. 
   
  I trivial fix for "parsedatetime proper" is to use an ISO-style time 
  spec instead: 
   
    set gmt [clock format $clock -format "%Y-%m-%d %H:%M:%S" \ 
                       -gmt true] 
   
  This works with 8.4.7 here. 


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  Ah, I see that the OP already mentioned this kind 
  of patch. 
   
  There are more problems though, because the 
  formatting part of "parsedatetime proper" is also 
  broken. 
   
  I have posted a patch on the patch tracker as 
  #1312869. 
   
  Note: I see that the same bug has been reported 
  as #911580 in 2004. 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Adding the patch file from the patch entry. It is not clear
  to me why asnother entry was opened. Files/patches can be
  attached everywhere.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Nuts. Fixed the fault. Should really ensure that both critcl
  and non-critcl paths are tested with windows.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  Hmmm.  I'm not sure what you mean by "an object inherits publically 
  from another".  Are you referring to the "component" statement's "-
  inherit" flag?  Also, if I implemented an "info self" method, then if 

     set a [$object info self]

  it should always be the case that "$a eq $object".  Unless $object isn't 
  fully qualified--but [namespace which] should help you there.

  There might, on the other hand, be some point to an "info selfns" 
  method that returns the object's private namespace.

  If I'm missing the point entirely, please enlighten me!


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  Consider:

  package require snit

  snit::type Y {
  }

  snit::type X {
      component Y -public y -inherit true

      constructor {
  install Y using Y %AUTO%
      }
  }

  X x;

  # I would like to know what object [x Y m] will be evaluated in.

  x Y ;# this could return the Y instance?
  x Y self ;# or this?
  x Y info self ;# or this?

  It came up when I wanted to return a handler object, and
  associate some information with the object, and then
  retrieve that information on handler completion by using
  [upvar self] as an implicit argument.

  I couldn't see a way to determine [x Y] easily.  I've coded
  around it, so it's not a dire need, but it occurred to me as
  a possibly useful facility.

  Colin.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  OK, I see what you're after.

  In your example, "x y" can't return the Y object's name; I'm using
  [namespace ensemble] for the dispatch now, and [namespace ensemble]
  requires a subcommand.

  Yes, "info self" would give you what you want; and it would certainly
  be easy to do.  I'll think about it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Using the CVS Head of Tcllib I am unable to reproduce this.
  I used Tcl 8.3.5.
  I also used tclsh together with vwait, instead of wish.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  I understand it doesn't happen under tclsh in 8.3.5
  but that's not the environment I have to support, which is
  wish 8.3.4.

  When I get a chance I can try upgrading to 8.3.5 but it won't
  be soon.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I understand, however from my perspective it is a quite
  likely a bug in the tcl core tripping comm, seeing that
  8.3.4 does not work, yet 8.3.5 does, with comm unchanged
  between the two. And that is something which is difficult to
  impossible to work around.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  OK, thanks for investigating and explaining. I will try to 
  schedule time to attempt an upgrade to 8.3.5. In the 
  meantime I will have to install comm4.0 in parallel with
  comm4.2 and load that version explicitly when running under 
  8.3.4.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I believe the problem is that the makefile target
  install-libraries does not define the option -app-path, and
  so takes a default directly from the executing tcl shell.
  This was fixed in the CVS Head at March 25.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Very bizar when I change the line to 

      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 1]
  OR !!!! (it does not matter???)
      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 0]

  Both work FAST ??? (Via Solaris tcl_patchLevel  8.4.5)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Added to CVS Head. Added documentation, which was missing,
  and a tiny testsuite for nl2br.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is actually already fixed in the CVS. The application
  manpages are installed in the same location as the package
  manpages.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is also fixed in the CVS Head of Tcllib. installer.tcl,
  line 167ff


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  However internal results can still be larger than int, right ?

  Should we care ?

  How much performance do we lose for pre-8.5 Tcl because of
  the additional conversions ?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  After TIP 237, you do not want
  to allow the computed numbers
  to grow without bound.

  Whether you limit them to 32-bits
  or 64-bits doesn't really matter, IMHO.
  (That's why I suggest int(.) as the 
  fix, without regard to what length that means)
  At either range you'll stick to computation
  that can be done with native types, either
  long or Tcl_WideInt.

  But without some limit, pretty soon
  you're chugging away on values literally
  thousands of digits long, just to keep the
  last 10 or so.  The small test suite literally
  runs for hours.

  Dunno about performace cost to 8.4 and
  earlier.  It's something that can be dealt
  with if needed though.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Adding some extra ops to truncate seems to make it a bit
  slower with both 8.4 and the current 8.5 head. Using int()
  or &0xffffffff seem to be equally slow. 

  I'm going to rig it to switch on the interpreter version and
  try and get the fastest implementation that will remain correct.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  So the Windows and Solaris ftp server generate different
  outputs in response to the request, right ?

  Please try to capture the commands sent by the package, and
  responses received, and attach the resulting log to this report.

  Note: We recently fixed a problem in NLIst regarding the
  handling of 'spaces' in filenames. Could this be a similar
  problem ?

  I.e. not a true difference between the windows/solaris
  servers, just filenames with spaces in them returneed by the
  windows server ? This can be tested by creating some files
  with spaces in their name on solaris and making sure that
  the solaris server sees them ... I think.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  I do not think it has anything todo with the 'spaces' problem.

  I noticed in the output that the return-code with the ftp
  list command was 
  226 on solaris - Closing data connection. Requested file
  action successful (file transfer, abort, etc.).

  550 on IIS - Requested action not taken. File unavailable
  (e.g., file not found, no access).

  Thanks for the effort!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Uh. In other words, the windows server sends a failure
  status code when you try to list non-existing files, whereas
  the solaris server is happy to report that it is happy, the
  list of matching files is simply empty.

  And the ftp package in turn is not happy with the failure
  status reported by windows. :(

  I had hoped it was something quickly fixed for the release.
  Now I am not sure. Ok, no fix for this release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ah, I missed that this was not only on the wiki, but also
  submitted here. This was fixed in the CVS head on Sep 26.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Closing this, moved the attachment to the bug entry, where
  it truly belongs IMHO.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  It can be the struct module. You are likely using
  struct::tree, and for that one we have a critcl based
  implementation. I believed to have found and fixed all my
  overflow bugs, but apparently not.

  I do test the critcl struct::tree and that testsuite passes
  (I test both critcl and tcl impl., whatever is available,
  using the same tests. You know how, I copied this
  (LoadAccel, SwitchTo, etc basically from your test). I
  wonder what hmlparse is doing different to cause this.

  Use TCLTEST_OPTIONS='verbose bpste' to get motre information
  from the test run, i.e. which tests where started, passed,
  etc. This should give you a better idea where the crash
  happen at the higher levels.

  There is a way to activate memory debugging for critcl based
  code too. I have to dig this out.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  File tree_c.tcl is the main entry to the struct::tree critcl
  code. At the top we have critcl::cheaders/debug commands, so
  memory debugging should be on. however for -g to be handled
  correctly the 'critcl' application has to be modified a bit
  as well.

  File "critcl.vfs/lib/critcl/critcl.tcl". Line 612. Disable
  this line. "append cmdline ... -O2 ...".


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A first attempt at reproducing the crash failed. I basically
  loaded tcllibc, all the tcllib modules and ran the series of
  tree commands as generated by the html test suite. I mean, I
  ran the htmlparse testsuite and used logging to determine
  the sequence of tree commands, and their arguments. This log
  was converted into a script.

  As said before, this failed. The crash happens only from
  within the htmlparse testsuite :( The interesting result is
  that the first tree test fails. Not a crash, but different
  results. I.e. there is also a regular bug in the critcl tree.

  The crash can happen after the first test alone, but
  sometimes a bit later, when the second test is initialized
  or started. Looks really like an overwrite bug.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The bug exposed by the first test may also point into the
  direction of the memory problem. The htmlparse does a
  Reorder. This is a walk which _also_ modifies the structure
  of the tree. This may invalidate data structures at the C
  level where I do not expect this, causing me to write where
  I should not. Note that the C code fails to do the reordering.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The basic bug is one of refcounting. The object holding the
  name of the loop variable has refcount 1, and after the
  first loop it hold a different value. My guess is that is
  was reused when the loop body was compiled, for a different
  literal. This caused me to write to a different variable and
  the Reorder proc was always called for the node from the
  first iteration. This does not explain the memory problem,
  not really. Having the walker holding a reference to the
  varnames fixes this.

  ... further checking shows that this is likely also the
  reason for the crash ... We do not get any anymore after
  this fix alone.

  Will also have to rewrite the iteration over children, the
  way I am doing it now it can go boom if the structure
  changes, as it does here. The array can not only be
  reallocated, but also shrink, expand, invalidating the index
  I have into it. I have to use my sibling pointer (next). ...
  No, does not work. Not the same behaviour as the Tcl impl.
  ... Ah, I essentially copy the children in Tcl before I walk
  them, so their move to a node already processed has no
  effect ... I have to emulate that at the C level ...

  Done, for all dfs walks. The bfs walks are quite different
  and should not suffer.

  Still, we do need test cases for the behaviour of the
  struct::tree walkers in all modes, when children and parent
  nodes are moved around, added, and deleted during the walk.

  In this area, walking a tree while changing it at the same
  time, we may still have (crashing) bugs lurking. And stupid
  behaviour in general, even for the Tcl implementation.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It's an endian-ness thing. Have to find a way to determine
  the byte order in the pre-processor.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Added code to set the byte order macro. Tested with gcc and
  msvc on Windows and gcc on SunOS-sparc, OpenBSD-x86 and
  Linux-x86. Should be ok everywhere as we use tcl's idea of
  the byte order.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The culprits for this are logger.test 3.0 and 3.1.

  Those basically should test if the default logprocs are
  called, which print to stdout, but do not really do it.
  Should probably be rewritten with the newer tcltest -output
  option, to check whats printed to stdout.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Done - I left in messages about aborting the package when
  not found, though.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

  What do you mean exactly? I get:
  $ tclsh stooop.test
  stooop.test: Total 103 Passed 103 Skipped 0 Failed 0


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  I got 

  Module:stooop
  modules/stooop/stooop.test
  env array elements created:STOOOPCHECKOBJECTS

  But now I see that this must be part of the tcllib test
  harness.  My mistake.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done. Disabled the commands only, no removal. May be needed
  in the future for debugging.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  A second look make it look like
  Tcl is at fault here, not aes.

  still looking...


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Yes. I'm seeing this too -- on FreeBSD-6.0/amd64. Please, 
  advise. 


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  I think, I found a fix. For some reason, attachments seem  
  disabled on this page, so here is the patch inline (be careful  
  of the white-space mangling):  
    
  --- modules/dns/ipMore.tcl      Fri Sep 30 14:03:58 2005  
  +++ modules/dns/ipMore.tcl      Tue Oct 18 01:15:38 2005  
  @@ -400,8 +400,9 @@  
   proc ::ip::maskToInt {mask} {  
       if {[string is integer -strict $mask]} {  
  -        set maskInt [expr {(0xFFFFFFFF << (32 - $mask)) &  
  0xFFFFFFFF}]  
  +        set maskInt [expr {(0xFFFFFFFF << (32 - $mask))}]  
       } else {  
           binary scan [Normalize4 $mask] I maskInt  
       }  
  +    set maskInt [expr $maskInt & 0xFFFFFFFF]  
       return [expr wide([format "0x%08x" $maskInt])]  
   }  
   
  This seems to work for me... 


login: aakhter
username: aakhter
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=736414

  The bug is currently assigned to me, but I don't have a 64 bit 
  system to work on this. Do I have write access to CVS to 
  commit this fix?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Aamer, I have a 64bit system (linux/amd64) and have verified
  the patch as well. I will commit it in a few minutes,
  currently doing the admin work for it.

  Beyond that, yes, you do have write access to the Tcllib CVS
  at SF. It enabled that at the time I added you as a developer.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed to CVS head. Only one change to the patch: The
  masking expression got braced.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  If only you did a PRE-release testing on a single 64-bit 
  platform :-( 


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Dude, I did plenty of pre-release
  testing, but you sneaked this module
  in just days before release, missing
  all the testing that was done.

  The closer to the deadline you make
  code changes, the less testing you
  can reasonably expect them to get.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The fault is that [encoding convertto unicode $str] produces
  different byte-order output on sparc and intel. NTLM
  requires little-endian unicode strings.
  Fixed by byte-swapping on big-endian systems.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The directory failures seem to be BSD specific. Solaris
  could have them too, as that allows to read a directory is
  if it were a file.

  Regarding /var/log/messages, what user were you ? IIRC this
  file is usually read-only root, i.e. unaccessible to anybody
  else. Right now I have now idea how fumagic will react if it
  doesn't have the permissions to read a file. You could try
  to make readable copies of messages and COPYRIGHT and try to
  get results for that.

  Have you also tried it on other text files, not only pictures ?


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  file(1), when applied to a directory responds with 
  "directory" -- try `file /' on any system. 
   
  /var/log/message is readable to all on my system and 
  yes, I did try other text file (/COPYRIGHT, for example). 
   
  file(1) works properly: 
   
  % file /COPYRIGHT  
  /COPYRIGHT: ASCII English text 
   
   


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  still fail in 
  - tcllib::testutils 1.1
  - fileutil::magic::rt 1.0
  * fileutil::magic::filetype 1.0.1
  (tcllib-1.9-rc1)

  on Solaris 9


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed the test failures. Committed to head.
  Nothing done yet regarding /var/log/messages, copyright, etc.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Does the Tcllib 1.9 RC2 have the same problems ?
  The foundations (programmed dialog) of the testsuite was
  changed completely.

  Urls to download the RC2 on the Tcllib-devel mailing list.
  Alternatively retrieve CVS Head. Identical modulo ChangeLog
  tags.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Would you like an account on my FreeBSD/amd64 system?

  Please, send me your ssh public key and your /etc/passwd 
  entry. Yours,

         -mi


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Why the /etc/passwd ? would you not need only a user name
  and passwd ? The latter even disposable, chsnged on first
  login ?

  Otherwise, yes, interested.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  /etc/passwd does not contain the actual password (which I 
  don't need and you will not use anyway). What I need is 
  your login-name, your numeric ID, your preferred shell, 
  etc. All of this is nicely specified in the single line 
  of /etc/passwd. You'll get it by running something like:

  fgrep andreas /etc/passwd

  (substitute "andreas" with your actual login-name).

  And the SSH-key, of course. If you use PuTTY, it has a way 
  to export the key in the "OpenSSH format".

  You can e-mail this to me directly at 
  mi+sourceforge@aldan.algebra.com

  Yours,

         -mi


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I got my account and ran the testsuite. The problems
  reported here are gone now. Closing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done. However only for the schemes which are actually known
  to the uri::split command.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Good catch: that file only documents the old procedures 
  cov, fibonacci, ...

  I am not sure yet how to proceed: I would like to retain 
  the old documentation and point to the new stuff too.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825

  bug 1 was fixed on 4/2/05 i suggest upgrading to the latest 
  version before submitting a bug report. I will look into #2


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I think, this is fixed, does not happen for me on windows.
  Report, if this is not the case.

  Thank you,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done. The new file is 'mime.bench'. The unstructured
  benchmarks have been removed now.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Dup
  http://sourceforge.net/tracker/index.php?func=detail&aid=1430694&group_id=12883&atid=112883


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ah. I believe I understand. cpush creates a context, but did
  not initialize the location information for the context. And
  somewhere later the location data was accessed, and not
  present. Ok. Accepted the patch.


login: wart
username: wart
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=244388

  Now that I take a closer look, this isn't entirely correct.

  aclocal.m4 contains a pointer to config/tcl.m4, which is not
  in the source tarball.  However, configure.in doesn't
  reference any macros that would be in tcl.m4, so aclocal.m4
  isn't even necessary and should be removed.

  configure.in does reference a 'config' subdirectory which
  does not exist.  This directory should either be added or
  configure.in should be modified so that it doesn't look for it.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  BWidget no longer uses autoconf, therefore there is no need
  for tcl.m4.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  CVS version of configure.in was updated a while ago.  No
  idea why this case hasn't been closed yet.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825

  thanks for pointing out my mistake. I fixed this problem in
  removeComments and also in removeExif


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Please increase the version number of the package after this
  change.

  If package would have version 0.3, scripts which need
  working removeComments/removeExif may

  package require jpeg 0.3

  and fail immediately if user have buggy version of package
  instead of destroying user images.

  It is that very kind of changes which should be reflected in
  the minor version number, because it is even more than new
  functionality added - functionality which was destructive
  for user data, became useful.


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Thanks that you haven't forget to raise package version when
  fixed this bug. Now I can package require asn 0.4.1 and be
  sure that my code would throw an error rather than silently
  produce incorrect data.

  Happy New Year


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  You are quite right. I have corrected the procedure angle 
  and I have added a procedure crossproduct.

  Thanks for reporting this.

  The new files are in CVS


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Confirmed, will fix.

  I really need to add more tests to the testsuite for this
  package...

  Please assign further bugs you find directly to mic42, so i
  get notified.

  Michael


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  What version of mime is this ?
  If it is not from Tcllib 1.8, can you try with Tcllib 1.8 too ?

  Also note: As you your are sourcing the files directly, in
  what namespace are your source commands ?

  Reason for my question: mime.tcl provides a package, and the
  package management _always_ sources such a file from within
  the global namespace. Because of this it is quite possible
  that mime.tcl contains tcl code which will only work for
  that environment, and not when the file is sourced within a
  different namespace.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  data_type - 362883

  Logged In: YES 
  user_id=302287

  This is more of a feature request than a bug.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  As for the errors in BWidget I was unable to recreate.  Is
  there an example script available?

  As for the BWidget demo I was able to recreate and then fix.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The current ldap TLS code just uses a different port and
  wraps the connection into TLS. A different solution would be
  to do the ldap starttls handshake to setup a TLS connection.
  Its not hard to do and i have it nearly done.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  I'll submit an updated ldap.tcl (version 1.6), which
  supports StartTLS. Not sure if that does a graceful fallback
  yet, but should improve things.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Added the new starttls code to the ldap module, which allows
  to upgrade a standard connection to TLS secured.

  As the LDAP RFC is more critical about validating TLS
  connections an automatic fallback to unencrypted is not a
  good idea. 

  Please have a look at the current code in CVS, I'll set the
  status to Pending, so it gets closed if there is no response.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in
    his patch for [SF Tcllib Bug 1276561], see 2005-10-04 entry.

    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0. 
    * (parsedatetime): For month index, use "%m" + scan
  instead of
      wrong "%e".


login: clmcavaney
username: clmcavaney
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1425189

  Apologies - should have checked the CVS version first.
  Thanks for the rapid response though.


login: aldobu
username: aldobu
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=979524

  Just to push for a quick bug-fixing,
  I suggest an alternative solution:

  # change line 1836  (tree.tcl  v.1.52)
  # from
   set data(dnd,afterid) [after 200 [list Tree::_scroll 
  $path $scroll]]
  # to
   set data(dnd,afterid) [after 200 Tree::_scroll $path 
  $scroll]

  ** Tested with Tcl 8.4.12 **


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=13222

  Bug still present in csv head (1.8 got rolled out, with it).
  The 'quick fix' by aldobu has the problem, that it will fail
  for widget pathes with spaces in it (though, widget names
  with spaces in it aren't best practice and will probably
  break BWidget at other places also). The fix in the original
  bug report looks OK. 


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Further investigation shows that 1.1 (from tcllib 1.6)
  doesn't work too.

  Offending function in both cases is log::loghex


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Followed your advice and removed the use of the log package
  completely. It simple enough to add useful debugging code
  when its really needed.


login: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=410366

  Here is the patch which seems to fix the bug:

  --- /usr/lib/tcllib1.8/sasl/sasl.tcl    2005-09-19
  16:12:39.000000000 +0400
  +++ /usr/local/lib/sasl1.0.0/sasl.tcl   2006-03-18
  21:24:10.736909032 +0300
  @@ -76,7 +76,7 @@
       set context [namespace current]::[uid]
       variable $context
       upvar #0 $context ctx
  -    array set ctx [list mech {} callback {} proc {} service
  {} server {} \
  +    array set ctx [list mech {} callback {} proc {} service
  smtp server {} \
                          step 0 response "" valid false type
  client]
       eval [linsert $args 0 [namespace origin configure]
  $context]
       return $context
  @@ -401,7 +401,7 @@
                   set realm [eval $ctx(callback) [list
  $context realm]]
               }

  -            set uri "smtp/$realm"
  +            set uri "$ctx(service)/$realm"

               set A1 [md5_bin "$username:$realm:$password"]
               set A2 "AUTHENTICATE:$uri"


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  You get the message about 'no benchmarks' when specifying
  "-verbose". I have chnaged the default level now to 'warn'
  (from 'critical', and elevated the message itself from
  'info' to 'warn' as well.

  Regarding the splitting it might be better to simply make
  all keys fully fledged lists. That way we get correct
  quoting all the way.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  However, using lists as keys requires a full-blown rewrite
  of the internals, as that requires changes everywhere.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, did the rewrite of the internals, all keys are lists now.
  With that all issues have been addressed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Is it sure that this is really done by snit, and not the
  package management code in general ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ah. Ok. I see and understand now. This is my bug, this is
  code I wrote :(


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  also:

  modules/tie/tie_rarray_comm.test
  - tcllib::testutils 1.0
  - comm 4.3
  - snit 1.1
  - cmdline 1.2.4
  - tie 1.0.1
  * tie::std::rarray 1.0
  WARNING: cleanupTests deleting /local/src/tcllib/spawn...


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Maybe this is naive, but why not just use the clock
  functions' '%b' format option, which outputs the abbreviated
  month name?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in his patch for [SF Tcllib Bug 1276561], see
  2005-10-04 entry.

  * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

  * (parsedatetime): For month index, use "%m" +
  scan instead of wrong "%e".


login: ricardoj
username: ricardoj
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=388133

  Ok, sorry not to double check on CVS. :(

  The problem using %b, is that command is locale specific, so
  if your system is in english then you get the correct answer
  for the month, otherwise not !


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  This is quite similar to the trace log feature in logger.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is a duplicate of
  http://sourceforge.net/tracker/index.php?func=detail&aid=1428544&group_id=12883&atid=112883


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Corrected this and extended the test suite. The problem was 
  that I used lists as either row vectors or column vectors, 
  thinking the difference would not be possible.

  It is, though. The [matmul] proc is adjusted for this.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Sorry, realized I could be a little more specific:
  In proc ::ftp::StateHandler on line 284 the following was added:
  if {$ftp(State) ne "quit_sent"}

  for this version. Should be changed to:

  if { ! [ string equal $ftp(State) "quit_sent" ] }

  to maintain compatability with tcl versions earlier the 8.4.

  Thanks,

  John Mercogliano III
  Contractor, TekSystems
  Systems Integration
  Sentara Health Care
  jxmercog@sentara.com


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I believe this is actually a problem on your server. The
  script provided works fine (although you should add the
  following lines to get the To and From headers added)
    set from "\"$fullname\" <$emailaddr>"
    mime::setheader   $token From $from
    mime::setheader   $token To $to

  I have tried this using the files you attached to the
  ActiveState bug on a Microsoft SMTP server and on Postfix
  (on Linux) and both worked ok. If you want to test this
  yourself locally I suggest you add -debug 1 to the options
  for smtp::sendmessage. This gets it to record the SMTP
  conversation to stderr. 
  You might also try the sample smtp server that is part of
  tcllib itself. If you start the example server (wish
  tcllib\examples\smptd\tk_smtpd) and set the port number to
  25 you can ue your script and send mail to localhost as the
  server. This way you can see both sides of the conversation.
  It's possible that your server is using the SIZE extension
  and limiting SIZE to something very small.

  I am going to close this as works for me - but reopen if you
  have more information to add. 


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  Ok, seems I left out something. I am sending the email 
  through an external email server owned by a reputable 
  hosting company. I believe this may effect the outcome. So 
  I am re-opening this report and adding some new info. I 
  have attached a file that contains the smtp dump after 
  turning on the -debug flag, a code snippet used to send 
  the message and the tcl result error. Also, the mail gets 
  sent but it's truncated to something less than 10KB.

  Also, the machine that is running my program is the same 
  machine that I use for my personal email client 
  (Thunderbird). It works just fine for sending large email 
  bodies.

  Please let me know what you think. You might also try 
  sending a message to an external server and see what you 
  get. Please make sure to use a large file and ensure that 
  received file is approximately the same size. My test file 
  was 52KB.

  Thanks Patt


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  Oh, one more thing, the path you gave to the example smtp 
  server does not exist on my install of ActiveTcl 8.4.11.2


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Using information contained in your attachment I have sent
  myself the mime.tcl file (108K) using your script on a
  Windows XP machine and sending via your server. In all cases
  I have got the full file. I'll separately mail you some
  extra bits.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  I get the same error when sending mail attatchments bigger 
  than 6-7 kb. The smtp package stops the base64 encoded 
  part, sends a newline and a dot, then RSET and QUIT. (no 
  ending boundry)

  The error message is "400: error writing "sock244": invalid 
  argument"

  Here, a ethereal dump of the end of the conversation with 
  mail server:
  <dump>
  dWJ0eXBlL1RydWVUeXBlPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvRW5j
  b2RpbmcvQmFzZUVu
  Y29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9qL
  .
  RSET
  QUIT
  250 198182198 mailfe02 Message accepted for delivery
  250 SMTP state reset
  221 mailfe02.swip.net SMTP closing connection
  </dump>
  Looks like smtp tries to send rest of the data, but 
  allready has closed the connection.
  Rgds.
  Jesper


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  In addition to my previously post.
  Just tested the setup thru sockspy, and the error didnt 
  occur. This could look like some socket issue in the smtp 
  package code.

  Rgds
  Jesper


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  This issue was resolved for me by Pat Thoyts. It turned 
  out to be an problem with the TCLs standard socket 
  implementation. Here's the solution:

  One last thing I thought of is there is an alternative 
  socket implementation for Tcl on windows - the iocpsock 
  extension provides a socket2 command. It was written as a 
  performance enhanced socket layer and uses the winsock 
  APIs rather than the BSD socket APIs. There is a slight 
  chance this might produce a different result for you. You 
  would use it by doing:

  package require Iocpsock
  interp alias {} socket {} socket2


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  This issue was not resolved. It appeared that it was 
  working because I move from the standard socket to the 
  iocpsock package which allowed a larger portion of the 
  email to be sent before something went wrong.

  I did some more testing and here's what I discovered:

  I went into the the smtp package and disabled the trf 
  package call. This allowed me to send large emails and 
  attachments but I was not happy with this solution so I 
  poked around some more and found that the tls package was 
  not installed on my system. I assumed everything needed 
  was there since I'm using ActiveTcl from ActiveState. 
  Those guys are usually pretty good about including 
  everything but I've since been informed that the package 
  was excluded from ActiveTcl due to export restrictions on 
  the crypt stuff.

  Second, if I send an email WITH "-usetls true" the mail 
  sends just fine (this is how Pat Thoyts was sending his 
  emails). However, when I send emails with "-usetls false" 
  it fails miserably and I get the dreaded iocpsock/sock 
  error!

  I'd like to see if you can send a large email soemthing in 
  the neighborhood of 1MB with the -usetls set to false. 
  There's obviously still something wrong with the way the 
  smtp package is handling the trf stuff.


login: dunkfan
username: dunkfan
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1183601

  FWIW, this bug has just appeared after an upgrade to tcllib-1.9
  tcllib-1.8 was/is working fine so I'll stick with it for the moment.
  System Win XP PRO SP2, iocpsock does not improve the situation. (tcl 8.4.13)
  Code is as follows:

  set token [mime::initialize -canonical text/plain -string $body]
  catch {smtp::sendmessage $token \
     -recipients $recipient\
     -header [list From $from]\
     -header [list To  $recipient]\
     -header [list Subject $subject]\
     -servers $email_server -usetls 0} error
  mime::finalize $token


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I did not really check your bug report because it is so time intensive to build up a test environment and try to find out what is happening.

  Instead, I want to ask you:
  - is the bug still an issue ?
  - does it still arise with the current cvs of bwidget ?
  - if yes, could you please simplify your code to just the usage of the ComboBox in question.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue is reproductible on windows and on linux.

  I think the following point might be the issue:
  - Dialog sets a global grab on its own
  - The Listbox of the ComboBox gets a global grab if it is posted.
  - There is normally a focusOut binding on the listbox, that when there is a click anywhere else, it is closed and the grab is released (and returned to dialog).
  The (highly risky) issue of grabs has troubble here.

  I do not want to go here any further.
  For me, it is ok at the moment, that it works in the normal case when the normal interface is used.
  Maybe, I will come later to the issue.
  Could you post the simplified version on the web site ?
  It shows the issue on linux and windows and does not have the installation system included.

  Thank you,
  Harald


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  I was able to recreate the problem and fixed it using your
  suggestion.  Thanks.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Proc NoteBook::delete might profit from a line like:
  unset data($page,width)
  although I am not sure this solves the trouble.


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411

  My mistake. I've still got a memory leak, but a more careful
  look shows me that it's not the BWidgets notebook widget.

  However, the notebook does seem to leave some info in data()
  after deleting, as you suggest. This seems to clean it up
  without side-effects:

      # Clear out page-related info
      foreach ndx [array names data -glob "*$page*"] {
          unset data($ndx)
      }

  Thanks, and sorry about the incorrect diagnosis.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I wish I could set multiple resolution. This is out of date,
  and fixed in the CVS head. See also the items 

  https://sourceforge.net/tracker/index.php?func=detail&aid=1403452&group_id=12883&atid=112883
  https://sourceforge.net/tracker/index.php?func=detail&aid=1425947&group_id=12883&atid=112883

  Changelog:

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in his patch for [SF Tcllib Bug 1276561], see
  2005-10-04 entry.
    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

    * (parsedatetime): For month index, use "%m" + scan
  instead of wrong "%e".


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=295103

  Forgot to mention - this bug report is for version 1.2 of
  widget::dialog. Tcl/Tk 8.4.12 on Windows XP


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  Error recreated using your test code.  Correction applied
  via your suggestion.  Thanks.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Themes will be included in BWidget 2.0. This is IMHO not a bug but a feature request.
  So I will close the bug report here.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  The ugliness seems to be due to the wish interpreter
  invoked.  Using wish from /usr/bin/wish8.4 (OS X 10.4.7) I
  get the black background as per your screenshot.  However
  when I invoked wish from fink, the notebook's
  -activebackground seems to be set correctly.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Investigated this further and it is rooted deep inside the
  implementation. Basically this is a user error that is uncaught.

  There is no easy fix to this, unless i completely rework the
  internal linkage structure.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875
  Originator: NO

  Although specifying multiple arguments may be a user error, I would like to see logger package support such multiple arguments. I need to pass multiple arguments so that my custom log proc can invoke argument specific actions. Consider the following example:

  ${f}::debug -subst {List of files = [glob -nocomplain *]}

  In above, the message is enclosed within curly braces so glob command is not invoked when debug level is disabled. However, if -subst flag is present and debug level is enabled, my custom proc can invoke [subst $msg] in the caller's context to get the list of files and print them in the log msg.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The attached changed implementation fails the testsuite.
  As the testsuite as is does not use the new functionality,
  the new code is breaking existing functionality.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted, with small change in join, fixing the testsuite
  breakage. Extended testsuite and docs to cover the new
  functionality.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  If you're going to rely
  on alpha releases, you'll
  have to pay some attention
  to ongoing development.

  Are you confident that you're
  working with the actual 8.5a2
  release?  Or could this be
  a snapshot of the development
  sources taken before release?
  The 'changes' file reports:

  ...
  2004-10-08 (new feature)[TIP 201] "in" and "ni" expr
  operators (fellows)
  ...
  --- Released 8.5a2, December 7, 2004 --- See ChangeLog for
  details ---
  ...

  so any install of the actual 8.5a2
  release (or better yet, 8.5a3, or
  an 8.5a4 release candidate, or the
  latest development snapshot you can
  stand), ought to resolve the issue.

  If there's a bug here, it might be
  that things would be a bit better
  if snit could indicate its need
  for 8.5a2 or better, so that a
  [package require] might fail instead
  of a random command.  There are
  two obstacles to that.

  First, the [package] command fails
  to support version numbers with
  alpha or beta designations.  This
  is Tcl Feature Request 219296.

  Second, during alpha development,
  it's fairly common to run into
  an interpreter that isn't based
  on any official release, but is some 
  development snapshot that may or
  may not have the same features as
  its [info patchlevel] would indicate.
  So even a working
  [package require Tcl 8.5a2] would
  not help since your interp claims
  to be 8.5a2 but lacks the features
  of the real 8.5a2 release.  One can
  imagine version number bumping
  schemes that could deal with that, but
  getting them followed reliably seems
  unlikely.

  Update your Tcl to one that supports
  the "in" operator.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Ok, thanks. Did not even know there's a new "in" keyword.
  I guess I was using the latest ActiveState Mac release.

  Dylan.


login: jepler
username: jepler
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2772

  I'm using bwidget with tcl/tk8.4.10.  There are still
  N-squared behaviors with "-selectfill 1".


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  The problem appears to be because the widget's path has
  parantheses.  Once they were removed I no longer get the
  error message reported.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  IMHO, this issue was fixed by [Bug 1842346], so I close it.
  Complain, if the current cvs does not solve the issue.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Looked a bit into this. When the remote interpreter receives
  an incoming connection it calls the commIncoming callback
  for the listening socket. The second argument is the ip
  address of the host the connection is coming from. That is
  the reason for the use of an ip address instead of a
  hostname. The remote interp has nothing else.

  Tcl is asymmtric in this regard. The side opening a
  connection can use ipaddr or hostname, and Tcl will use the
  OS to resolve hostnames to ip. The remote side however has
  only the ip address, not a hostname, and Tcl does not do
  reverse resolution. Note also that the revers lookup is also
  not unambigous. We may have several hostnames for an ipaddr.

  To get the hostname either the host opening the connection
  has to send its name as part of the first message, like it
  already does for offered protocol versions, or the remote
  host has to perform some sort of reverse dns lookup (ip ->
  hostname).

  The first is possible, means that the protocol goes a
  version higher. Disadvantage: The name as send may not be
  visible as is in the DNS of the remote host. Meaning that
  trying to connect back to that will fail. This will likely
  work best if both hosts use the same dns server. Not in
  general however.

  And reverse dns lookup, well, that is neither built into
  Tcl, not do I remember a package which could do it. Maybe
  tcllib::dns ? No idea. That has the disadvantage that the
  reverse lookup takes time, i.e. more time until the
  connection is open.

  The id value for the hooks is likely depending on whether
  this is a 'local' or a 'remote' hook. The remote hooks do
  not have host names, the 'local' hooks use whatever id the
  user specified when the connection was opened.


  There is definitely no quick, easy, and full solution for
  this (pick two).

  Well, the protocol extension maybe, with a quick check if
  the received name can be resolved. If not then fall back to
  the regular behaviour.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Be more careful what you type :)
  As I understand it, some lines get understood by the server.
  It's possible this is no longer the case with the Jabber MUC
  but I am not certain.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  This is because the type *is* a namespace.  In your example, the ::ns::myObj 
  constructor runs in the ::ns::myObj:: namespace, not the ::ns:: namespace.  
  This is extremely unlikely to change.

  I do agree, I would often find it convenient if ::ns::myObj's code could use any 
  command from ::ns:: without having to import it or qualify it.  I believe there's
  a TIP in progress which would allow me to tell Tcl that when it's in the 
  ::ns::myObj:: namespace it should look for unqualified command names in
  ::ns::myObj, and then in ::ns::, and then in ::, instead of just in ::ns::myObj::
  and ::.  If that pans out, it would be an obvious enhancement--and one that
  I'd welcome.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ah, you want a script, like used by 'foreach', instead of a
  command prefix. And the script has access to a variable
  containing the current element.

  Specialized foreach commands, both of them. Called them
  'mapfor' and 'filterfor'.

  Committed, with test cases, and documentation.

  Administriva: Please put tcl code into a files and attach
  them. Inlined code is unreadable.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have nothing to do with Bwidgets and its internals. DamonC
  and JeffH are the maintainers. Possibly Daniel South
  (wildcard_25) as well. As it was with Damon already it now
  goes to Jeff.


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=13222

  I didn't see that bug anymore, but I saw it in the past.
  IIRC, check in:

  Wed Jan 26 01:01:24 2005 UTC (16 months, 2 weeks ago) by hobbs
  Branch: MAIN
  Changes since 1.145: +5 -0 lines
  Diff to previous 1.145

  * notebook.tcl: reverted lester patch - too many bugs
  related to
  deleting and reinsertion of tabs.

  fixed the problem. 

  At least something like


  package require BWidget

  wm geometry . 200x200
  NoteBook .nb
  pack .nb -fill both -expand yes
  foreach page {zero one two three four five} {
      .nb insert end $page -text $page
  }
  after 2000
  foreach page {two three four five} {
      .nb delete $page
  }

  works for me as expected, with a almost recent BWidget cvs
  version.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Could only reproduce after a lot of clicking on the Buttons,
  not just the few clicks you reported.

  As you use Dialog -modal global this is probably a global
  grab which is not released.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi,
  thank you for reporting, it is reproductible on windows.
  Considering the following code on windows tk without BWidget:
  ---
  pack [button .b -text t -command "tk_messageBox"]
  focus .b
  raise .
  grab -global .b
  -EOF-
  we get a similar deadlock effect.
  As a workaround, I suggest to release the grab (or not use global grabs at all) before opening another window.

  This is filed as tk bug  2814003

  As a workaround, a tk_messageBox routine might be created like
  set grabcur [grab]
  if {"" ne $grabcur} {
      grab release $grabcur
  }
  tk_messageBox ...
  if {"" ne $grabcur} {
      grab $grabcur
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. There are a number of packages which can use tcllibc,
  and IIRC none of them look for and use an installed critcl
  to compile the acceleration codes dynamically.

  Yes, extending the installer should be possible, to have it
  look for critcl, and build tcllibc if it is present. That
  should alleviate most concerns I think. Otherwise we have go
  deeper into the code of all the packages loading their
  various accelerators and have it check for critcl alone as well.

  The other stuff are documentation issues I will address
  after we have consensus regarding tcllibc/critcl. I have
  notified Pat Thoyts directly, as he wrote most of the
  packages using critcl in general, and uuid in particular.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Oh dear, this is an unexpected side effect of that stuff.
  I have checked the other modules too - there may be a
  similar effect in stooop, but I have no experience with that.

  Other modules seem unlikely to cause trouble (cmdline and
  doctools)

  I have committed the changes to CVS 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Gregor,
  thank you for the report. It is now fixed with the assumption, that:
  - all screens have the same size
  - all screens are directly one beside the other
  Unfortunately, both are not true in general, but the current solution is a step forward.

  I have read that there is no way to find the screen geometries of the other screens with tk, so this seams the best possible solution.

  The fix in cvs also includes your solution.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I have implemented a first version - it can do only one 
  series of data per histogram, but that ought to be enough.

  I have ideas on how to extend it: stacking the bar on top of
  each other. Other options: cumulative plots in stead of each
  bar on its own... Just let me know.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  Closed the request - Plotchart has the possibility to dispaly histograms


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Stephen,
  this option is documented and implemented as readonly.

  Unfortunately, I first fixed it and then read the manual. So I fixed the manual too.
  Please check, if current cvs works for you.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  I have partial code that does this. I'll see if i can beat
  it into usable shape. 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I am not able to find a file 'tclunits.tcl' in the tcllib
  units module, nor anywhere elase in tcllib. There is also no
  file containing the string 'cto(capturing)' from the patch
  anywhere else in tcllib (in case the file was renamed).
  Based on that it seems that this patch/bug does not refer to
  tcllib, or to an old revision of tcllib (I checked the CVS
  head).

  Setting to pending, for auto-close in a about 2 weeks. This
  will automatically re-open the bug if new information comes
  in within this timeframe.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  Tclunit is in tclapps.  It is a real module, and has a real
  bug.  I just haven't had the mental energy or time to fix it.

  Changing status back to open.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, changed back to state none, and added clarification to
  subject line. We have no category for this one. Should we
  add it ?


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  I see 17 apps, and two of them with categories of their own.
   Perhaps a category for just "apps" which would at least
  give you a hint about where to find the module.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  did both. General category, and one for tclunits. You are
  the auto-assigned maintainer for the latter category.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494
  Originator: NO

  All fixed.  Thanks for the bug report and repair suggestion.


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1463011

  Adding the lines below (diff with 1.339) allows the proxy 
  password to be saved. 

  C:\Program Files\tkChat>diff -u tkchat-
  torsten.vfs\bin\tkchat.tcl tkchat-
  torsten.vfs.proxypw\bin\tkchat.tcl
  --- tkchat-torsten.vfs\bin\tkchat.tcl   Tue Jun 27 15:16:38 
  2006
  +++ tkchat-torsten.vfs.proxypw\bin\tkchat.tcl   Tue Jun 27 
  16:38:11 2006
  @@ -3437,6 +3437,10 @@
          ${NS}::label .logon.lpap -text "Proxy Auth 
  Password" -underline 13
          ${NS}::entry .logon.epan -textvariable 
  Options(ProxyUsername)
          ${NS}::entry .logon.epap -textvariable 
  Options(ProxyPassword) -show {*}
  +       ${NS}::checkbutton .logon.rprxpw \
  +               -text "Remember Proxy Password" \
  +               -variable Options(SaveProxyPW) \
  +               -underline 0
          ${NS}::label .logon.lnm -text "Chat Username" -
  underline 9
          ${NS}::label .logon.lpw -text "Chat Password" -
  underline 6
          ${NS}::entry .logon.enm -textvariable 
  Options(Username)
  @@ -3529,6 +3533,7 @@
          grid x          .logon.lph    .logon.fpx   -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpan   .logon.epan  -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpap   .logon.epap  -in $lf -
  sticky w  -pady 3
  +       grid x          .logon.rprxpw    -                 -
  in $lf -sticky w  -pady 3
          grid .logon.lnm .logon.enm    -            -in $lf -
  sticky ew -pady 5
          grid .logon.lpw .logon.epw    -            -in $lf -
  sticky ew
          grid x          .logon.rpw    -            -in $lf -
  sticky w  -pady 3
  @@ -4251,7 +4256,7 @@
          Emoticons EnableWhiteboard EntryMessageColor errLog 
  ExitMessageColor
          Font,* Fullname Geometry HistoryLines 
  JabberConference JabberPort
          JabberResource JabberServer LogFile LogLevel 
  LogStderr MyColor Nickname
  -       OneToOne Pane Password ProxyHost ProxyPort 
  ProxyUsername SavePW
  +       OneToOne Pane ProxyPassword Password ProxyHost 
  ProxyPort ProxyUsername SaveProxyPW SavePW
          ServerLogging Style Theme Transparency UseBabelfish 
  UseJabberSSL
          UseProxy Username Visibility,*
       }
  @@ -4298,6 +4303,9 @@
       if { !$Options(SavePW) } {
          unset -nocomplain tmp(Password)
       }
  +    if { !$Options(SaveProxyPW) } {
  +       unset -nocomplain tmp(ProxyPassword)
  +    }

       # Save original Nickname
       if { [info exists ::tkjabber::baseNick] } {
  @@ -5145,6 +5153,7 @@
          ProxyPort               ""
          ProxyUsername           ""
          SavePW                  0
  +       SaveProxyPW                     0
          ServerLogging           all
          Style                   any
          Theme                   ""


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  This is intentional - partly to avoid storing your network password in a plaintext file and partly to avoid having your account locked because of tkchat retrying too many times after a password change.


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  File Added - 184182: bwidget.diff.txt

  Logged In: YES 
  user_id=152318

  that diff has lost its indent.  Let me attach a file...


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=152318
  Originator: YES

  Here you go:

  package require Tk
  package require BWidget

  proc do_write {} { BWidget::write [file join $::env(HOME) bwidget.out] }

  Button .b1 -text "launch BWidget::write" -command do_write
  Button .b2 -text Exit -command exit
  pack .b1 .b2 -side top


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks. Yes, your correction is right. I have accepted it,
  and extended the testsuite as well.


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=128673

  The above suggested change excludes hidden files on Windows;
  the below line could be used in both the Windows and Unix
  implementations of find:

  replace 

   set filenames [glob -nocomplain * .*]

  with:

   set filenames [glob -nocomplain *] ; set filenames [concat
  $filenames [glob -nocomplain -types hidden *]]

  Note how much easier this whole problem would be if there
  were a "-types all" option provided by glob.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This should be fixed by the recent rewrite of fileutil::find which is now in the CVS head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 186333: valgrind.txt

  Logged In: YES 
  user_id=75003

  I can confirm the same crash with Tcl 8.4.CVS and
  struct::tree critcl. (Aborted with a "malformed bucket chain
  in Tcl_DeleteHashEntry").

  And I managed to get some more information where the
  problems by using valgrind.

  Hm. I wonder if I can manage to get more by compiling
  struct::tree with symbols.

  Ok, than you very much Helmut for investigating this so far,
  i.e. making the problem reproducible, and also reducing it
  to such a simple and small script. 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This can actually be seen as two problems.

  (1) The auto-generation of node-names is out of whack for a
  tree loaded from a serialization. It creates node-names
  which are already present.

  (2) The code for the destruction of tree is not able to
  handle a tree with duplicate node names.

  The latter is the crash. However (1) is the real problem.
  All parts of the tree implementation assume that node names
  are unique. all the methods for rename, etc. check that the
  result is not violating this assumption.

  Ok, the plan: Make the destruction more robust against dup
  names, if possible. By detecting an already deleted node.
  Panic with a proper message. Then fix the generation of dup
  names by the C impl. after a tree was loaded from file. Put
  this example into the testsuite.


login: hgiese
username: hgiese
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=522169

  Hi Andreas,
  I have been thinking a bit about this issue.
  You can use the same approach the Tcl version uses - that is
  on every node creation you keep incrementing the counter and
  compare the resulting name against all existing nodes. This
  is an O(n) operation for each newly created node.
  How about the following approach: On deserialisiation you
  check for the highest node index present and set your
  'unique number' from there. This is also an O(n) operation
  but it happens only once.

  Why aren't you on vacation at this time of the year?
  Greetings from a very hot place
  Helmut


login: hgiese
username: hgiese
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=522169

  Hi Andreas,
  just a last thought:
  On deserialising you are bound to look at each node. Why not
  note 'in passing' the highest "auto generated name" and when
  thru using it to initialise the 'unique number'?
  This should be negligible wrt changes in the code and
  run-time impact.
  Ok, I'll forget about it now and leave the rest to you.
  Greetings
  Helmut


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fix committed to head.
  t_newnodename extended to skip existing nodes while
  generating names.
  tn_new extended with check for duplicate name, panic. This
  latter ensures that, should we have other places which can
  cause generation of dup names, we panic early and with a
  good error message, and with damaged hashtable during
  destruction.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. Could actually have a huge impact on runtime in
  pathological cases. For the better. Consider a very large
  tree, several thousand nodes, all auto-generated.

  I start from the bottom (node1) to find and fill any gaps.
  If there are none I have to iterate over the thousands of
  names to to find the max. Takes a long time.

  The tcl version is most impacted by this. The C version is
  way faster, but even so this only means that the point where
  such the iteration takes a noticeable amount of time is
  pushed to higher numbers of nodes, not that the problem goes
  away.

  So, doing some precomputation when desrializaing makes sense.

  On the other hand, this precomputation has to 'string match'
  or 'regexp' each node name and see if it is of the form
  'nodeFOO', FOO an integer number. This is not cheap in
  runtime I believe.

  Well, in the end what we need is to benchmark this and see
  how the various cases behave and what the big-O constants are.


  --
  And thanks again for the concise test case. This made the
  debugging a snap.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Thanks for the patch. Applied it to the current CVS Head,
  its in logger version 0.7. I needed to fix some minor
  failures in the testsuite (to specific pathes to the
  logger.tcl file, wrongNumArgs which were not prepared for
  running with Tcl 8.5).


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  This has been fixed, and test "bug-3.1" has been added to the Snit test suite to 
  cover the error condition.


login: yahalom
username: yahalom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=130120

  I got very troubled from the response. the pervious bug 
  mentioned was fixed in the days of the tcllib1.3 we are now 
  in tcllib1.8 and the bug is still there!!!! this means that 
  the bug fix is not in the head version and therfore is 
  still open


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The bug was closed in July 2006, so the fix is only inside
  CVS currently, not in a released version. CVS HEAD is not
  equivalent to the latest released version...

  Take a look at ncgi.tcl in CVS and the nvlist proc, it does
  not contain a regexp anymore.... 

  So this is really closed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I checked as well and can confirm Michael's findings. The
  unreleased code we have in the CVS really is without RE's in
  nvlist.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Does this happen for the current CVS head as well ? I just checked and the installer code in the CVS head does not contain 'package require fileutil', so the problem might be gone.

  If not note that the Makefile calls on 'installer.tcl' as well, with a series of arguments for non-gui operation. So, when you call the installer directly, using them same arguments, does the error then happen ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Makes sense. Easy client side.
  Note: lcl_id aka local_id can be had automatically from the
  comm channel used to setup the "alias".

  Not really aliases, but forwarder, delegators ... I like the
  last name, matches with what snit does.

  More complex delegation would allow -async and -command.
  -async is actually easy, -command can have a variety of
  semantics, depending on when we wish to declare the callback
  (when delegator is created, or when it is used).

  Well, let us stay with the simple stuff first.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  "delegate" sounds good to me. And -async would be a nice
  addition too -- it can be very useful for logging messages
  to a central server where we know that the client doesn't
  have to wait for any responses. The -command stuff can wait.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Implemented in the CVS head, new module 'interp', doing
  interp creation, and additional packages for the creation of
  delegation procedures and methods (snit).


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Stupid typos. Wonder why this wasn't detected when the code
  was extracted from the ldap module.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  File Deleted - 189465: 



  File Added - 189517: ldap.patch

  Logged In: YES 
  user_id=1268042

  New patch (which supersedes the first one) with a small 
  bug corrected in the attrsOnly option handling.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  A workaround is in place in the ldap module, which looks for
  the namespace var storing the nonce count and resetting it,
  before a new attempt. Not perfect but works. If this gets
  fixed in the sasl module, it would be better, but its not a
  showstopper for ldap sasl support.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 242826: bug1545306.patch

  Logged In: YES 
  user_id=202636
  Originator: NO

  You might try the attached patch which moves the nonce count into the context structure. SASL::cleanup will remove it so a new context will begin again at 1.
  To reuse a SASL context as described in the RFC you should call SASL::reset. As the context remembers the original server challenge and now the noncecount it will compose a new auth request as before but with an incremented noncecount and should re-authenticate. This needs confirming -- I don't have an LDAP setup to try against and my SMTPd doesn't do re-authentication.
  File Added: bug1545306.patch


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Added this to the ldap module as ldapx.tcl based on the last
  version i received by email and some minor stylistic changes
  (unset -> array unset where appropriate, added some missing
  --, changed some string equals to eq, and so on)


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Added - 190935: tooltip.tcl.patch

  Logged In: YES 
  user_id=368971

  I've added a patch which fixes this bug. It withdraws the
  tooltip when the cursor is on the widget for which the
  tooltip is cleared.


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Deleted - 190935: 

  Logged In: YES 
  user_id=368971

  A tooltip isn't shown immediately when the cursor is already
  on the item. This bug isn't fixed in the patch.


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Added - 190937: tooltip.tcl.patch

  Logged In: YES 
  user_id=368971

  I've improved the previous patch to correctly clear and set
  tooltips on items with the cursor over them.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656
  Originator: NO

  in tooltip 1.4.  I didn't do the display if you just add the tooltip, just the clear if removed.

  BTW, diff -u is much easier to read.


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1463011
  Originator: YES

  asn::asnRetag allows precisely this scenario -> closed


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  oh damn, forgot to experiment a bit, found just add a .0 to
  the end to make it work with decimals.

  please delete this feature request, sorry to waste your
  time. feel free to slap me about with a trout :/


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  See also "[ 1563137 ] NList fails for files with spaces".
  This report contains a fix as well.
  The fix was applied and committed.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  IMHO...

  Nothing to repair; this is
  not a bug.

  [namespace import] the
  ::math::linearalgebra::scale
  command into your namespace,
  not the global one.

  If you insist that you must
  import both commands into
  the same namespace then
  [rename] one of them.  This
  is name conflict resolution 101.


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Ooops...

  ::html::tableFromArray 

  That also contains uppercase:

  append html "<TR><TH colspan=2>$arrname</TH></TR>\n"


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Fixed in CVS head. Also changed the SELECTED and CHECKED
  things to lowercase.


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193325: ntlm.patch

  Logged In: YES 
  user_id=1463011

  Attached patch allows me to successfully bypass our
  corperate proxy server. Via: 1.1 hostname (NetCache
  NetApp/6.0.2P2D2)


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193343: ntlm.test.patch

  Logged In: YES 
  user_id=1463011

  Test SASL-NTLM-1.1 now fails because of additional changes
  in the way of including the flags and session keys fields in
  the type-3 message.
  Attached a patch on the ntml.test file. 


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Applied patches plus a little reconfiguring. Tests ok on my
  unicode using systems.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Some of this is fixed in asn 0.8. I added a asn::peekTag, and some others to handle multi-byte tags and retag things. Not the best solution currently, but works. 

  PeekBytes is basically not needed, as the asn data is just a string. If you want a peek at the first x bytes, simply use string range for now, it works fine with binary data.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Please attach the result of package require ldap, so i know
  which ldap version your working with (must be a recent CVS
  checkout).


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Do other large searches work? The search interface and the
  underlying structures changed quite a bit, so there may be
  some more bugs lurking...


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  Ok, i can reproduce the error.

  The ldap code had a wrong calculation for missing length
  bytes and broke when it got a long response like the
  subschema query.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  This is fixed in CVS now, get package version 1.6.2 , along
  with some other bugs in the info subcommand.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Apart from a bug in this script ($b}] should be $b]), there
  was a genuine error in the leastSquaresSVD routine. This has
  been solved - see the CVS repository.

  Added this as a test case


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 194111: installer.tcl

  Logged In: YES 
  user_id=302287

  Diff adding an error dialog attached. Please review.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A quick look seems to be ok, only a nit: [catch {}] == 1 can
  be shortened to [catch {...}] I do not thank that we care
  about break, continue, etc. Will have a closer look when I
  ma home, i.e. patch and look at the whole context.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Accepted with very small changes yesterday, committed this
  morning. The nit, and slighty different formatting.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  You should add a -- to terminate the option list. Thus:
  ::blowfish::blowfish -mode ecb -dir decrypt -key -- $key
  Or use the programming api style as in the man page.

  I will note the -- option termination in the manual page and
  looking at the option code this can be made smart enough to
  tell that the final argument is data and avoid trying to
  handle it as an option.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have a tclsh 8.5 and can see what this is about. In the
  meantime use Tcl 8.4 to run sak and specify the shell to use
  for the testsuite itself using "test run -s SHELL ...".


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Uh. This seems to a something with the new 8.5 ensemble
  and/or namespace path stuff snit v2 uses.

  The constructor of tie::std::file has a call

       [file normalize $thepath]

  and this seems to be interpreted as call into the class or
  constructed instance now. In snit v1 this resolves to the
  global command.

  For now I will fix this using ::file, however I wonder if
  that is something which is a snit problem and not of the
  defined class.

  It is an incompat for sure.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed. Also fixed a syntax error in an example uncovered by
  emacs syntax highlighting. A closing double-apostroph was
  missing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, while I have no access to a Linux/Alpha box a Solaris
  box is at hand.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. I am on a solaris 2.6 box, and cannot repro these
  failures. The testsuite runs fine.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  The use of [file join . / *]
  in these tests is suspect.
  Perhaps it's combining with
  [glob] and [file] bugs here?

  What's intended by these tests?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The glob outout (.//foo) certainly looks broken. If this is
  the expected output and the intentation of thests. I don't
  know. They test the 'fileutil::install' command ... Written
  by David Welton in 2003. So he should be able to get us
  better answers. He is 'davidw' here, we could reassign this
  to him.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  ok, at least one relevant issue
  is a [glob] bug fix apparently
  not backported to 8.4.

  % info patch
  8.5a5
  % glob *
  foo
  % glob -dir . /foo
  ./foo


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Heh. I just ran into these test failures again, I think. Ok on Linux, failed on Windows.
  Will try to understand what is done and wanted.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks. I have to ask 'how quick' ? The testsuite is failure
  free for 8.4, the main release of the core, and the plan was
  to go final this evening (Monday Oct 2). I could move that
  one, at most two days, but no longer, as I want to have GA
  well before the conference.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

  I don't think I'll be done in 2 days, maybe, but not for
  sure... Sorry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I expected that answer ... Ok, if you manage we can put into
  the release, otherwise it has to wait for the next, and I
  hope that you will not min that. As it affects only the 8.5
  alpha it can be considered as relatively low-priority. On
  the other hand, several tcllib math failures uncovered bugs
  in the rewritten Tcl 8.5 number handling, so we should not
  leave it uninvestigated.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks Jean-Luc for the quick investigation and work. I saw
  your commit and tested it, the testcase is not failing
  anymore. I will now close the report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Used [format] to get a deterministic precision of the result
  across versions. Committed to head.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the test: the failure was due to the changed default
  for tcl_precision.
  By explicitly setting the value, the previous behaviour has
  been restored 
  and the test succeeds. 

  Note: the original value for tcl_precision is restored at
  the end to ensure
  consistent behaviour for other tests.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I made a fix to the dialog module and also to the pop3
  testsuite. This is in the head. Can you check if your
  problem still happens ?

  Note: The fixes I made were because the tests pop3-2.8 and
  pop3-5.0 were failing consistently on Solaris. Not on Linux.
  I never saw pop3-6.1 failing on solaris. And my failures
  were not dependent on running the whole tcllib testsuite,
  pop3 alone was sufficient. So, there are quite few
  differences. I am however not excluding that it is the same
  problem, just appearing in different places due to different
  system speed.

  In previous incarnations of the testsuite driver it was
  possible that a testsuite coming before pop3 forgot to kill
  a timer and it fired during the later test, smashing
  something. However in the current setup each module is
  tested using a new sub-process. So it should not be possible
  to leak stuff between modules. The only thing I can think
  off is timing differences between pop3 alone vs the whole
  testsuite.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  I can't repro the failure
  today, so either your changes
  fixed it, or it's not a real
  reproducible bug in the first
  place.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. Making it low-priority then. If a repro comes good,
  otherwise closing in a month or so.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  I am sorry, I have tested the package 2.0 with Tcl HEAD
  (updated and recompiled today) Windows XP (32-bit), and
  there is no problem - the test suite runs with no error.

  I guess the bug is somewhere in 64-bit integers handling,
  and/or even bignums.
  Maybe others areas of tcllib are impacted, this may be a
  problem related to the core, and which does not happen on
  32-bt systems.

  I feel sorry for you, but I'd only seek for a solution if I
  have a 64-bit system under my (dirty :^) hands...


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Selecting bigfloat-int2float-2.9.2.3
  for more analysis, on 32-bit system
  I see:

  % int2float [fromstr 5000000000] 5
  F 21474836480000000000 -32 42951

  On 64-bit I see:

  % int2float [fromstr 5000000000] 5
  F -125100849711610 -32 42951


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

   looked again and you need Trfcrypt, not Trf, I got confused
  by a switch-label. Trfcrypt does not come with ActiveTcl, so
  you are using the pure Tcl impl. of blowfish.
   
  I also note on further reading that the mode you are using
  is CBC aka Cipher Block Chaining. IIRC my crypto right this
  mode always operates on whole blocks, which are 64bit, aka 8
  byte
  for blowfish
  (http://en.wikipedia.org/wiki/Blowfish_%28cipher%29).
   
  This means that the padding done is correct. It likely
  actually is done to the input to make it a set of full blocks.
   
  Found some references:
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29
   
  And
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
  for methods padding which can be done before CBC is invoked
  and is exactly reversible. I do not know if the code in
  Tcllib uses any of these block padding schemes or is leaving
  that to the caller. I guess that it is the latter.
   
  Pat, I think we should add these wikipedia entries as
  references.
   
  I also grepped the manpage for information regarding padding
  and found none. IMHO this is a doc bug we should correct.
  This is one area where people can trip.
   


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Documented the padding a bit more explictly. Also added a
  -pad option to the blowfish command which can be used to
  turn off this padding feature (in which case you get an
  error if the data is not a multiple of the block size) + tests.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is DIGEST-MD5::client ... switch branch 1 ...
  CreateNonce not coming back ... Ah, reading from dev/random
  ... Checking ... /dev/random is readable, opened, reading 16
  bytes then hangs. My guess is that the machine has not
  enough randomness and is waiting for it accumulate.

  What now. In a way the report is invalid, as the testsuite
  hangs not on its own, but because of something in the
  environment. 

  Interesting, for machines without /dev/random, i.e. Win*,
  something based on clock, pid, and Tcl rand() is used.

  Oh, it is worse. The subprocesses not only hang, they cannot
  be killed anymore. Not even kill -KILL works :(


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It seems we should read from /dev/urandom to avoid blocking.
  Modified to use this source.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  I've fixed the alert mechanism to raise the alert for the window concerned now. This is fixed in 1.415.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed in CVS head on Friday Oct 7 after reported by Mikhail
  Teterin, a FreeBSD maintainer. He has the fix as patch as
  well, to be put into the ports build system.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494
  Originator: NO

  The units library already has most of this functionality.

  If, for example, you want to convert between inches and meters, or square feet and yards, you can do so like this:

    % package require units
    2.1
    % units::convert 4meters^2 yards^2
    4.7839601852
    % units::convert 22inches meters
    0.5588

  The referenced library also has some volume conversions between quarts, pints, and gallons, but the constants are for UK units.  I didn't put these units into the standard library because it might be misleading to have ambigious units.  But you can easily add them.

    #  Add UK gallons
    units::new impGallon 4.54liters


login: goodegod
username: goodegod
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1294134

  Even better would be to have tcl smart enough to not trip 
  an error if the variable unset is trying to unset doesn't 
  exist.  What is the harm in that?  It should be similar to 
  the tk destroy command.  

  That's just my two cents...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In newer Tcl's (since 8.4 IIRC) we have 'unset -nocomplain'
  for this. However 'ftp' is old and geared to run with Tcl
  8.2 as well. That needs either catch or the if-info-exists.

  In general you could, also, do

  rename unset unset_orig
  proc unset {args} {foreach v $args {upvar 1 $v var ; catch
  {unset_orig var}}}

  I.e. redefine 'unset' to do what you want, unset without
  tripping.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Reviewing the patch ...
  The move of the close/unset I understand. Takes the
  fileevent away.
  Unsetting ftp(state.data) I understand as well, after
  reading WaitComplete. It is necessary to prevent this
  command from doing a vwait without having an event source.
  However, why is there a 'read ftp(CtrlSock)' in the patch ?
  The Ctrlsock is already at eof, so this is a no-op.
  The close alone should be enough.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have now committed the patch without using the 'read
  CtrlSock'. If that causes the head (rev 1.44) to still fail
  with an infinite recursion please re-open this bug.

  Side note: Thank you providing a patch, and for attaching it
  to the report instead of inlining it. Despite this I have a
  small nit. Please use the command 'diff -u' the next time
  you create a patch for us. The '-u' switch causes 'diff' to
  generate a patch in the 'unified' format. This format
  generates larger patches, this however is offset by the fact
  that the result is much easier to understand when read by a
  human. In other words, it makes the reviewing of a patch
  easier for us maintainer. Thank you.


login: hofkensg
username: hofkensg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1625850

  You are right about the no-op.
  I have tested revision 1.44 and it works fine.
  I will use the diff -u in the future.
  Thanks,
  Guy


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Extra scenario:
  Installed apache ftp server from
  http://incubator.apache.org/ftpserver/ on win-xp (all default).

  And the output is (as you can see even other behaviour,
  nothing is prefixed now):
  % package require ftp
  2.4.4
  %
  % set h_ftp [ftp::Open 10.17.101.53 anonymous myPwd -port 21
  -mode active]
  0
  % # Case 1
  % ftp::NList $h_ftp  edidata/Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 2
  % ftp::NList $h_ftp  edidata/Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML
  % ftp::Cd $h_ftp edidata
  1
  % # Case 3
  % ftp::NList $h_ftp  Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 4
  % ftp::NList $h_ftp  Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The ftp packages NList command basically just passes through
  whatever it receives from the FTP server, without
  postprocessing, so you directly see the server differences
  (similar to what you would see if you used a typical command
  line ftp client).

  The RFC does not make any real assumptions how the returned
  filenames have to look like:

           NAME LIST (NLST)

              This command causes a directory listing to be
  sent from
              server to user site.  The pathname should specify a
              directory or other system-specific file group
  descriptor; a
              null argument implies the current directory. 
  The server
              will return a stream of names of files and no other
              information.  The data will be transferred in
  ASCII or
              EBCDIC type over the data connection as valid
  pathname
              strings separated by <CRLF> or <NL>.  (Again the
  user must
              ensure that the TYPE is correct.)  This command
  is intended
              to return information that can be used by a
  program to
              further process the files automatically.  For
  example, in
              the implementation of a "multiple get" function.

  It talks about 'valid pathname', if the results you see do
  not match the description in the RFC the server is buggy.
  The exact specification for 'pathname' is vague at best:

        pathname

           Pathname is defined to be the character string
  which must be
           input to a file system by a user in order to
  identify a file.
           Pathname normally contains device and/or directory
  names, and
           file name specification.  FTP does not yet specify
  a standard
           pathname convention.  Each user must follow the
  file naming
           conventions of the file systems involved in the
  transfer.

  The only 'safe' way i see is to CD to the working directory
  your interested in an invoke the NLIST command there, as
  that excludes all directory name prefix issues.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  I did some extra testing and I now convinced this is a
  ftp-server problem, not a tlclib problem. (thanks mic42 for
  the remark)
  * If you want to Use set directory listing to UNIX (to solve
  backslash problem)
  * Always add a slash to the end of a directory when using
  NList (solves directory prefixing)

  Is this something to add to the doc. as a remark ?


login: matzek
username: matzek
mimetype: text/plain
icomment:
  File Deleted - 200000: 



  File Added - 200122: new_conf_option.patch

  Logged In: YES 
  user_id=330806

  I am sorry. Had to replace the patch again, as the usage of
  AC_ARG_ENABLE was just wrong. Now triple checked...

  kind regards -- Matthias Kraft


login: bugant
username: bugant
mimetype: text/plain
icomment:
  File Deleted - 201918: 



  File Added - 202048: ftp.tcl.patch

  Logged In: YES 
  user_id=1391120

  Andreas Kupries suggested to change the -hylafax
  option to a more generic -temp. This is a good idea.
  The patch attached do this (I'm removing the previous one).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  The "Diagrams" package was obsoleted by "diagram" (lowercase, no trailing 's').


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=317958
  Originator: NO

  This problem is not Tablelist-specific.  Replace the tablelist with another widget, e.g., a Tk listbox or text widget, and you will see exactly the same behavior.

  I am no [incr Tk] expert, but apparently it is the

      itk_component add table {
          tablelist::tablelist $itk_component(sf).table
      } {}

  command in your script that causes the trouble (probably because $itk_component(sf) is a scrolledframe widget).  Replace it with

      set cs [$itk_component(sf) childsite]
      tablelist::tablelist $cs.table

  and update the pack command accordingly.  After these changes, the script will work as expected.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Not only with syslog, also with Andreas log package.

  I'll consider it. Its quite easy to do.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 214446: logger.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

  File Added: logger.diffs


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Wrong. The above is incorrect HTML. The JavaScript is incorrect, a < has always to be quoted as < unless it is inside a CDATA section.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I don't see anything in http://www.w3.org/TR/html4/interact/scripts.html that would indicate that. Can you provide a reference? None of the examples that I have seen on the web follow such a convention. (The CDATA section is deprecated, according the the W3 page above.)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Your right its valid, but there are some problems lurking in that area, see:
  http://www.w3.org/TR/html4/appendix/notes.html#notes-specifying-data

  It works because the DTD for HTML4 declares <script> as having a CDATA value, but may blow up in apps that don't fully respect the DTD. So its dangerous ground...


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I was able to work around the problem by adding spaces around the < in the files I had access to (which would not always be the case). Pragmatically, I don't know what the fix should be, but handling of SCRIPT might need to be more special than it is.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  Looking at your reference, it's pretty clear that the script tag cannot end until a </[a-zA-Z] is found. Looks like the recognizer needs to be a bit more discriminating.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  This problem is now more urgent than it had been before. I'm working with JavaScript that is writing the HTML as it runs, including adding new <SCRIPT>...</SCRIPT> code inside of JavaScript document.write statements. htmlparse is getting seriously confused inside the JavaScript, and the resulting nodes are truly mucking up my parse tree. Some nodes aren't even at the right level any more, which makes my post processing lose them, which is very bad news for my application.


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=99768
  Originator: NO

  Oops, didn't I close this when I committed the change?

  Thanks again for the patch!


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433
  Originator: NO

  It looks like after this patch, it's necessary to call [dns::wait] after [dns::resolve].

  (It's probably always been necessary, just that I never called [dns::wait] before and managed to get away with it.  Took a while to find out what was going wrong after upgrading to tcllib 1.10)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Basically the url is invalid according to:
  http://www.ietf.org/rfc/rfc1738.txt (Section 3.3), the ? is reserved inside the searchpart of an URL and would have to be escaped.
  http://www.ietf.org/rfc/rfc2396.txt (Section 3.4) agrees with this.

  This appears a lot in the real world (especially due to PHPs crappy and incorrect url and form handling), so perhaps the URI package should deal with such broken urls.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I agree that we should try to handle this, at least if it can be done in a simple manner. Like looking for the first ? instead of the last. as we are using regexes this may require higher versions of Tcl and Advanced RE stuff (non-greedy ops) ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed using 'string first' instead of RE's. Extended testsuite. Version now is 1.2.1.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  To what combobox do you refer? tcllib doesn't have one, and the only thing in tklib that I see with a combobox is tablelist.

  $ tclsh
  % package require tablelist
  4.6
  % ComboBox .cb -values {a b c a b c}
  invalid command "ComboBox"
  %

  Give us info on what version of tcl and tk and what combobox you are using.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  According to the category the bwidget one. bwidget is in this project.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  Sorry, thought, the category would be enough, but ... I missed the BWidget version I use.

  I tried this behaviour with the BWidget version 1.7 and the most current one I know 1.8.

  Hope this helps!

  Martin


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Martin,
  thank you for the report.
  The issue is fixed in current cvs by adding a variable holding the last set index.

  This also solves the issue:
  % .cb setvalue 5
  % .cb getvalue
  2


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  I fully agree that the doctools docs need improvements.
  Most Tcllib authors probably use sak.tcl to generate the docs from their doctools formatted man pages, where it simply is: sak.tcl doc html <packagename> IIRC, but that kind of magic should be exported into a general use package for non-tcllib packages.
  So i agree that point 3 should be easy to do and have a big bang for the buck ratio.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  For reference, the wiki pages, which should be included (at least partially) into the doctools docs:
  http://wiki.tcl.tk/doctools
  http://wiki.tcl.tk/dtp

  These document at least the basics. Would they be enough to satisfy your 3. point?


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: YES

  Actually, the Wiki seems to address a majority of the insufficiencies in the documentation. Removing the "incorrect" information from the manual page (like the EBNF that's wrong) and either incorporating the examples and specifics from the Wiki or including a prominent pointer to the Wiki in the man page would probably be sufficient to answer most questions. I guess I'm just old-fashioned and haven't gotten into the habit of checking the wiki before the man pages. :-)


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  One thing that needs to be carefully kept in mind as doc for this package is written is that at least two types of documentation is needed.

  One type of doc is for someone who is going to be working on the code itself. That code would focus on design decisions, what the plugin architecture is for and how to use it, etc.

  The other type of doc is for someone who wants to write code in doctools format. For that person, the emphasis needs to be on SEMANTICAL use of the format. One of the reasons for doctools is semantical markup of text. In a semantical view, one doesn't care whether the resulting text is bold faced, underlined, etc. What matters is that people CORRECTLY marks the various parts of text. If one marks the text correctly, then the doctools tools should be able to generate things in a format that is useful later.
  And viewing the doc from that perspective is invaluable.  

  I wonder if some sort of tool would be useful to have that would somehow display the documentation visually emphasizing the semantical markup, so that one could easily look at text and identify where something had a mistaken markup?  I'm not certain about a good way to do this - something to think about.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 216376: doc.tgz

  Logged In: YES 
  user_id=75003
  Originator: NO

  Now attached a first go at a set of new man pages for the doctools markup language. Please review and respond.

  Looking at this again, (4), ... The error messages do tell the location of the problem, line number and column.

  Of the 4 documents the command reference likely needs most of the expansion (i.e. more argument descriptions, add examples for each command).

  File Added: doc.tgz


