# ticket

tkt_uuid: a697f07a38a7310a448cb52c15490b59a9eab4e6
type: Bug
status: Open
resolution: None
subsystem: tklib :: autoscroll
priority: 5 Medium
severity: Important
foundin: trunk
private_contact: b161dbf142556f12a9a6289ffc2a489dd98cabae
title: Infinite map/unmap of autoscroll widgets
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Using the autoscroll widgets in combination with a text widget can lead to an infinite mapping and unmapping of the scrollbars. 
  Tested with Tcl 8.6.3 on Windows, Linux and Mac.
  Example script attached.


tkt_uuid: ed8e0cf845cbd56dd32b0b5c60ff4d5a53e03b12
type: Bug
status: Closed
resolution: None
subsystem: tklib :: controlwidget
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Unprotected [console show].
cmimetype: text/plain
submitter: stwo
assignee: aku
closer: arjenmarkus
closedate: 2457126.02516132
comment:
  Old patch was ignored; resubmitting.


  $OpenBSD: patch-examples_controlwidget_demo-tachometer_tcl,v 1.1 2013/11/14 09:43:09 stu Exp $

  Windowsism.

  --- examples/controlwidget/demo-tachometer.tcl.orig	Thu Apr  9 00:08:32 2015
  +++ examples/controlwidget/demo-tachometer.tcl	Thu Apr  9 23:46:53 2015
  @@ -35,7 +35,7 @@ proc main { argc argv } \
       grid .t1 .s1 .t2 .s2 .b -padx 2 -pady 2
       wm deiconify .
   
  -    console show
  +    catch { console show }
   
   
       vwait forever


tkt_uuid: f0edc6c7bebd5abc59309d22fc36c94636fa0ed4
type: Bug
status: Closed
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
title: Unprotected [console show]s.
cmimetype: text/plain
submitter: stwo
assignee: arjenmarkus
closer: arjenmarkus
closedate: 2457125.78265877
comment:
  The older patch was ignored and now there's more!


  $OpenBSD: patch-examples_plotchart_testtable_tcl,v 1.1 2013/11/14 09:43:09 stu Exp $

  Windowsism.

  --- examples/plotchart/testtable.tcl.orig	Thu Apr  9 00:08:32 2015
  +++ examples/plotchart/testtable.tcl	Thu Apr  9 23:46:53 2015
  @@ -31,7 +31,7 @@ proc setColor {table widget row col value} {
   # Command must already exist ...
   $t formatcommand setColor
   
  -console show
  +catch { console show }
   $t title "Demonstration of table charts"
   $t separator
   

  $OpenBSD$
  --- modules/plotchart/plotaxis.tcl.orig	Fri Apr 10 00:10:46 2015
  +++ modules/plotchart/plotaxis.tcl	Fri Apr 10 00:10:59 2015
  @@ -1447,7 +1447,7 @@ proc ::Plotchart::AxisConfig { plottype w orient drawm
   
       worldCoordinates $w $xmin $ymin $xmax $ymax
   
  -    console show
  +    catch { console show }
       puts "$orient: $xmin $xmax $scaling($w,xdelt)"
   
       if { $orient == "x" } {


tkt_uuid: 34783217f723eb452634e7af7a1855d3e09b7fac
type: Bug
status: Open
resolution: None
subsystem: tklib :: plotchart
priority: 5 Medium
severity: Important
foundin: 2.3.4
private_contact: 9b076687903aba8f5254d84cbc9577f25d0fbe8c
title: createBarchart (vertical) doesn't work when gradients are used
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Bug in plotannot.tcl
  Example code pctestv.tcl attached. 
  No bars are displayed.

  Patch for plotannot.tcl provided.
  Remark: createHorizontalBarchart works correctly (see pctest.tcl).


tkt_uuid: ff4630901499e0e7d01c5d63c462929643f4080e
type: Bug
status: Open
resolution: None
subsystem: tklib :: tooltip
priority: 5 Medium
severity: Severe
foundin: latest
private_contact: 8cd4094d9cc19081fb2af3bcb7eeb83a6b69e6e4
title: Check for window existence AFTER update idletasks in tooltip
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  The procedure ::tooltip::show performs a call to update idletasks early on in its initialisation. This is to be able to properly detect the size of the window on top of which the tooltip should be shown.

  HOWEVER, since update idletasks releases control to everything else, there should be line like the following one immediately after:

      if {![winfo exists $w]} { return }

  I use an automated talkback reporter so that my clients can report problems and bugs. I've had a few reports that I can trace back to this "misbehaviour". This happens because ::tooltip::show itself is delayed and called from an "after xx" command.


tkt_uuid: 42622db1989d34f6a8df17e19854d0e5a57a1b7f
type: Patch
status: Open
resolution: None
subsystem: tklib :: swaplist
priority: 5 Medium
severity: Minor
foundin: 0.2
private_contact: 739ee75779220cf80faa6227c8075ca6e4243280
title: Patch to the swaplist default <Double-Button-1> binding that causes an error with -embed option
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  ## Example code
  package require swaplist

  toplevel .t
  swaplist::swaplist .t.swl sels {a b c} {d e} -embed
  pack .t.swl

  ## If you double click the left listbox, the error dialog is displayed.

  # invalid command name ".t.lr.left"
  #     while executing
  # "$top.lr.left invoke"
  #     (procedure "::swaplist::Double" line 6)
  #     invoked from within
  # "::swaplist::Double .t.swl.list2.list"
  #     (command bound to event)

  ## Patch to this issue

  172,173c172,173
  <     bind $w.list1.list <Double-Button-1> [list ::swaplist::Double %W]
  <     bind $w.list2.list <Double-Button-1> [list ::swaplist::Double %W]
  ---
  >     bind $w.list1.list <Double-Button-1> [list ::swaplist::Double $w 1]
  >     bind $w.list2.list <Double-Button-1> [list ::swaplist::Double $w 2]
  350,356c350,355
  < proc ::swaplist::Double {w} {
  <     set top [winfo toplevel $w]
  <     if {[string match *.list1.* $w]} {
  <         $top.lr.right invoke
  <     } elseif {[string match *.list2.* $w]} {
  <         $top.lr.left invoke
  <     }
  ---
  > proc ::swaplist::Double {w side} {
  > 	if {$side == 1} {
  >         $w.lr.right invoke
  > 	} elseif {$side == 2} {
  >         $w.lr.left invoke
  > 	}


tkt_uuid: 4e6715533c15534e6a9ed31321f18123ed12fc9b
type: Bug
status: Open
resolution: None
subsystem: tklib :: diagrams
priority: 5 Medium
severity: Minor
foundin: 1
private_contact: b4dd46eb62d921721c0aeef91d8d6e06aaeb6646
title: Arrow not drawn correctly in diagrams
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  The following code produces a simple diagram with two boxes and two arrows. While superficially the arrows are created with a very similar command, the second one is drawn incorrectly:

  package require diagram

  pack [canvas .c -width 750 -height 800]

  ::diagram d .c {
     move to [350 20]

     set HYDRO [box "Hydrodynamic\nmodel"  width 200  justify center]

     set WQ    [box "Water quality\nmodel"  width 200  justify center  with north  at [[$HYDRO south] - [0 -100]]  ]
     arrow from [$HYDRO south] to [$WQ north]  text "Flow field"  textfont "Helvetica 12 italic"  rjust south

     set NEWPOS [[$WQ south] + [0 70]]
     arrow from [$WQ south] to $NEWPOS  text "Results"  textfont "Helvetica 12 italic"  rjust south
  }


tkt_uuid: c023fe86313025a492b5bff5c377160143f01728
type: Bug
status: Open
resolution: None
subsystem: tklib :: widget :: dateentry
priority: 5 Medium
severity: Important
foundin: 8.6.4
private_contact: 8ecba79ffacc294d2b83ccb8f954310d127bf42d
title: text selection bindings
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  extending the text selection using keyboard (Shift + Left|Right)
  works as expected only if the selection extends
  to the right of the initial insertion point

  Shift + Right extends the selection to the right
  and subsequent Shift + Left reduces the rightmost boundary

  Shift + Left extends the selection to the left
  but subsequent Shift + Right extends the selection to the right
  instead of reducing the leftmost boundary

  I have only tested this in ttk::entry


tkt_uuid: 82a76c74110c1705359d9173cddfacc7ef3157f8
type: Bug
status: Open
resolution: None
subsystem: widget
priority: 5 Medium
severity: Important
foundin: 3.1/0.96
private_contact: be10c68edb35fa3f93c8cac6f2c0d27dc3933920
cmimetype: text/plain
submitter: Martin0815
assignee: nobody
closer: nobody
comment:
  Using wdiget::dateentry on a system with black based high-contrast-mode or high-contrast-themes (e.g. #1) is impossible, due to unreadable text (white on white).
  The calendar part of the dateentry widget does not render in the mandatory high-contrast-colors (in my case black background, white "frames", yellow text).


tkt_uuid: 0f618793c98871463a09a8f96eb76cce37f22729
type: Bug
status: Open
resolution: None
subsystem: tklib :: widget :: dateentry
priority: 5 Medium
severity: Severe
foundin: 1.0.3
title: widget::dateentry option -textvariable not functioning
cmimetype: text/x-fossil-wiki
submitter: holgerjakobs
assignee: nobody
closer: nobody
comment:
  When using the option -textvariable with widget::dateentry, the widget does update the variable when a date is selected, but changing the variable doesn't change the widget, although the documentation says so.

  There seems to be no way of setting the date for the dateentry widget to any other day but the default (which is today).

  see also [https://plus.google.com/+HolgerJakobs/posts/81U9MmTxjdi]


tkt_uuid: 6da48f457975aaef5c2b15b50dd87789e886f13a
type: Bug
status: Open
resolution: None
subsystem: tklib :: autoscroll
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: cb02a4a25e8da92f2790bc307bf01ef24ce6053e
title: autoscroll assumes packed widget managed by parent
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Line 122 of autoscroll.tcl [1] should be changed:

  -                     foreach x [pack slaves [winfo parent $w]] {
  +                     foreach x [pack slaves [lindex [pack info $w] 1]] {

  For backward-compatibility this uses [lindex _ 1] instead of [dict get _ -in].
  pack(n) says this is safe [2].

  [1]: http://core.tcl.tk/tklib/artifact/abfb57342332ea62?ln=122

  [2]: http://tcl.tk/man/tcl/TkCmd/pack.htm#M23


tkt_uuid: bb18815c6c59398d283bcc79dfc500aa4242307c
type: Bug
status: Open
resolution: None
subsystem: tklib :: diagrams
priority: 5 Medium
severity: Important
foundin: Tk 8.6
private_contact: ff3ca9071cd8ba88d18a72335e8ee406f56b10f1
title: Where is the "Diagram Language Tutorial"
cmimetype: text/plain
submitter: anonymous
assignee: aku
closer: nobody
comment:
  Hello,
  on the page <diagram(n) 0.3 tklib "Documentation toolbox"> it says 
  "Its intended audience are users of the package wishing to refresh their memory. Newcomers should read the Diagram Language Tutorial first."

  I am a newcomer and would very much like to read this tutorial, but I cannot find it.

  Thanks in advance
  Helmut


tkt_uuid: 8656e62ca75c3bb54fd72fc83247a02271dd15e8
type: Bug
status: Closed
resolution: Fixed
subsystem: Installation
priority: 5 Medium
severity: Minor
foundin: 0,6
private_contact: 55805032f00760ddf84eb3f8acb077da7bef1411
title: bad cursor .../pencil.cur
cmimetype: text/plain
submitter: tombert
assignee: nemethi
closer: nemethi
closedate: 2458403.20854503
comment:
  During installation the pencil.cur file is not copied:

  bad cursor spec "@D:/CM.git/tcltk85/release/lib/tklib0.6/tablelist/scripts/pencil.cur"
  bad cursor spec "@D:/CM.git/tcltk85/release/lib/tklib0.6/tablelist/scripts/pencil.cur"
      (processing "-cursor" option)
      invoked from within
  "$data(body) configure -cursor $cursor"
      (procedure "updateCursor" line 48)
      invoked from within
  "updateCursor $win $row $col"
      (procedure "tablelist::handleMotion" line 36)
      invoked from within
  "tablelist::handleMotion .gEntryWindow3.shellchildsite.childFrame.tableFrame.workFrame"
      ("after" script)


tkt_uuid: 5e324065bfb46f73dcbaa6ef1c7cc24890968602
type: Patch
status: Open
resolution: None
subsystem: A Category Is Missing
priority: 5 Medium
severity: Minor
foundin: 0.1
private_contact: dac83924bb70a68f6807871ce80578576828377e
title: Improved history module of Tklib
cmimetype: text/plain
submitter: aku
assignee: nobody
closer: nobody
comment:
  I have made two improvements to the history module:
  1. Avoid multiple add of same text to the entry history
  2. Fixed weird behaviour at the end of the history list: I had to press two times the up arrow in order to get the previous list value.

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

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

  package require Tk
  package provide history 0.1

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

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

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

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

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

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

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

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

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

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


tkt_uuid: d5e3a8eddd1ccdfc2f53c9a6a53de983e20fd1b7
type: Bug
status: Open
resolution: None
subsystem: tklib :: canvas
priority: 5 Medium
severity: Important
foundin: 1.0.1
title: partial canvas::snap output, osx
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  canvas::snap output is incorrect under osx;
  this is potentially due to the canvas being
  drawn on an hidpi (retina) display.

  to reproduce:

  --8<-----------------------------------
  pack [canvas .c -width 200 -height 100]
  .c create rectangle 10 10 60 60

  package require canvas::snap
  file temp filename snap.png
  [canvas::snap .c] write $filename
  puts $filename
  exit
  --8<-----------------------------------

  output:

  - https://imgur.com/a/ceYtb (osx)
  - https://imgur.com/a/aakol (linux)


tkt_uuid: 3295abf0786394dc8bb96ecadc30ce4a57e6af0e
type: Bug
status: Open
resolution: None
subsystem: tklib :: ico
priority: 8
severity: Important
foundin: trunk
private_contact: a013af67114eccc19ad12b04f14923acea9e96b7
title: ico: incorrect use of $img put
cmimetype: text/x-fossil-wiki
submitter: anonymous
assignee: aku
closer: nobody
comment:
  In the ico module there are the following four lines:

  <verbatim>
  /tklib-0.6/modules/ico/ico.tcl(557):	$img put -to 0 0 $colors
  /tklib-0.6/modules/ico/ico.tcl(563):    $img put -to $x $y $clr
  /tklib-0.6/modules/ico/ico0.tcl(400):	$img put -to 0 0 $colors
  /tklib-0.6/modules/ico/ico0.tcl(406):	$img put -to $x $y $clr
  </verbatim>

  This is an incorrect use of the put command. Documentation says:

  <b>imageName put data ?option value(s) ...? </b>

  However the code in the ico module uses:

  <b>imageName put ?option value(s) ...? data </b>

  The latter used to be accepted, although undocumented, but will soon no longer be. See:

  http://core.tcl.tk/tk/tktview?name=d4fb4e80d2

  Fix is easy and consists in swapping the order of the data and the options arguments.


tkt_uuid: 2a98e111894484e036edad72e73ab18999575343
type: Patch
status: Open
resolution: None
subsystem: widget
priority: 5 Medium
severity: Cosmetic
foundin: trunk
private_contact: 9a062c9a258075a3d7b26b9e6a58ac0bb71a4469
title: Russian abbreviated names of days of the week in the calendar widget
cmimetype: text/plain
submitter: anonymous
assignee: nobody
closer: nobody
comment:
  Do not correct the abbreviated names of the days of the week in Russian in a calendar widget

  ---------------------------------------------------------------------------
  --- calendar-old.tcl	2016-11-25 14:31:51.000000000 +0500
  +++ calendar.tcl	2017-01-20 14:02:56.328281800 +0500
  @@ -650,8 +650,8 @@
   	    \u0414\u0435\u043A\u0430\u0431\u0440\u044C
   	}
   	weekdays,ru {
  -	    \u432\u43e\u441 \u43f\u43e\u43d \u432\u442\u43e \u441\u440\u435
  -	    \u447\u435\u442 \u43f\u44f\u442 \u441\u443\u431
  +	    \u412\u441 \u41f\u43d \u412\u442 \u421\u440
  +	    \u427\u442 \u41f\u442 \u421\u431
   	}
   	today,ru {}
  ---------------------------------------------------------------------------


tkt_uuid: cd399b24dbb91b47b0d080cbe8d9a74948c7cba3
type: Bug
status: Open
resolution: None
subsystem: widget
priority: 5 Medium
severity: Important
foundin: Tcl/Tk 8.6.4
private_contact: d1daeb4ba521a25e9d5fdf05611fb6ee4777c118
title: ttk::spinbox command is invoked without stop
cmimetype: text/x-fossil-wiki
submitter: badchicken
assignee: nobody
closer: nobody
comment:
  I have an strange behavior that it invokes the command without stop. I write the next code in the wish8.6 console:
  <pre class='verbatim'>
   ttk::spinbox .sb -from 0 -to 10000 -command [list ::danitest]
   grid .sb
   proc ::danitest {} {
      puts "inside"
      tkwait variable ::danivar
      puts "outside"
   }
  </pre>
  Then, I do a single click on any arrow. The command is invoked and I can read the message "inside". Now, the process is waiting to the change of my variable danivar. In this momment, I write in the console the next code:

  <pre class='verbatim'>
   set ::danivar 1
  </pre>

  and when I press return I see that the message "outside" is shown, and some milliseconds later, the event is recalled (and I can read again the message "inside"). This behaviour doesn't stops.

  I don't know if it is my fault or there is an error. I have the same behaviour if I use the command error instead of tkwait.


tkt_uuid: fa7e4857020c0688d2e8477c45841a8eac851871
type: Patch
status: Open
resolution: None
subsystem: tklib :: datefield
priority: 5 Medium
severity: Minor
foundin: 0.2
private_contact: 6803cf5599f709a403c17167c01f3341d5539faf
cmimetype: text/plain
submitter: AdE@BfzPL
assignee: aku
closer: nobody
title:
  datefield with additional "-format" option to support Dates for German and ISO including MouseWheel-binding

comment:
  Based on "datefield.tcl" by KPV from Feb 07, 2002 - initial revision
  I give my propose for revision 0.3 (with no warranty etc.)
  - support more keys and the mouse wheel
  - add option -format to support 3 date-styles:
  	"%d.%m.%Y" (for German)
  	"%m/%d/%Y" (for English, standard/default)
  	"%Y-%m-%d" (for ISO)
  - each widget may have another format (stored on creation)
  See the already coded file attached
  It was successful tested under RedHat and Windows 7 & 10
  with ActiveTCL 8.4.20.0, 8.5.18.0 and 8.6.4.1.


# ticketchng

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

  Grrrr...  My Mozilla apparently does bad things with TABs...

  Anyway... tried to install using the

     ./configure
     make
     make install

  but ran into:

  $ make
  make[1]: Entering directory `/usr/local/src/tcllib'
  Gen (nroff): ./modules/base64/base64.man
  can't find package textutil::expander
      while executing
  "package require textutil::expander"
      (file "./modules/doctools/mpexpand" line 5)

  Apparently I must have the latest tcllib installed in
  order to install the latest tcllib.  Oops!


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

  Very. ...

  Given that there is no environment
  variable I can use to add paths to
  the library search path I believe
  the only solution to this problem
  is to patch the mpexpand application
  so that it looks for packages
  relative to its own location too.

      Right ?


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

  Look when I made the comment. It seems my memory subsystem 
  was down at that time. I will try TCLLIBPATH.


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

  Using TCLLIBPATH fixes the problem. Instead of 
      $(DOC_EXP) ...
  use
      TCLLIBPATH=$(srcdir)/modules $(DOC_EXP) ...

  Patch coming.


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

  Fixed in cvs head. Not sure if I got everything. One of the other bugs you reported seems to suggesst (implicitly) that we should add classes to list start/item/end as well. That I have not touched. Not yet done either is documentation for the class names in use in the output.


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  This seems to cover at least the markup I've used so far. Great, thanks.

  I did notice that the [opt ...] macro doesn't output any HTML tags, just surrounds
  it's argument with ?...? pairs. Can this also have an HTML tag?

  So, this code:

    [opt [option "-maxrun [arg n]"]]


  Which results in this HTML:

    ?<b class='option'>-maxrun <i class='arg'>n</i></b>?


  Should instead produce this:

    <span class="opt">?<b class='option'>-maxrun <i class='arg'>n</i></b>?</span>


  i.e. wrap the whole thing in a span with CSS class opt.


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

  Re [opt]. Yeah, could be done. Question. Rockshox asked to add <div>'s around things. Now here you are saying <span>. What is the difference between both ? Or, in the concrete case of [opt], could a <div> be used instead of <span> ? how interchangeable are they ?


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  A <div> is a block-level element. Like a <p> or <ul>, it begins a new line, and
  the content following it begins on a new line. A <span> is an inline element, like
  <b> and <i>.

  So in this case you need a span, because it needs to appear inline with the rest of
  the arguments and options.


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

  The cvs head of tcllib doctools should have class names for all the semantic markup now, and span where classes where not possible, so I am closing this one. If there are classes/ids/spans/divs missing please open a new bug for them specifically, or put the notice into http://sourceforge.net/tracker/index.php?func=detail&aid=1798427&group_id=12883&atid=112883, the general bug about HTML output and its styling (while it is open).


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

  Committed the attached code head, after fixes in the .man
  and .test files. The .html and .n files are generated,
  therefore left out.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A pattern match on the attribute keys of a particular node is 
  now in the CVS head. Note: Due to other changes to the 
  attribute interfaces the version of struct jumped to the next 
  major version, i.e. "2.0".


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

  Per the ChangeLog this was fixed in CVS on March 9, 2008 by Michael Schlenker.
  Package version (since Mar 22, 2008) is 0.2, containing this fix.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report and the test script.
  Could you please post your tcl version (and source).
  Does it only happen for the menu item with purple background or for all of them ?

  Thank you,
  Harald


login: wordtech
username: wordtech
mimetype: text/plain
icomment:
  It appears that mainframe.tcl in the BWidget source tree sets the background of Tk menus by checking for $tcl_platform(platform), and assigning traits if the platform returns "unix."  It really should use [tk windowingsystem], because while tcl_platform(platform) returns unix on MacOSX, the UI framework is not X11. 

  The diff below appears to fix the problem:


  --- mainframe-orig.tcl2010-11-09 09:36:05.000000000 -0500
  +++ mainframe.tcl2010-11-09 09:36:49.000000000 -0500
  @@ -518,7 +518,7 @@
   }
       }
   
  -    if {![Widget::theme] && $tcl_platform(platform) == "unix"} {
  +    if {![Widget::theme] && $tcl_platform(platform) == "unix" && [tk windowingsystem] !="aqua"} {
   set menuopts [list -background [Widget::getoption $path -background] \
     -borderwidth 1]
       } else {


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

  Note that for HTML the CVS head contains a revamp of the backend which marks all the pieces in the output with lots of class/id tags keeping the semantic information. Making it possible to change the visual style of the lot via CSS. Output contain an embedded default CSS style I mainly lifted from the TMML/HTML output. The embedded style is suppressed if you define your own via engine parameters (-style option of dtplite, or -meta option of dtp).

  For LaTeX it might more sense to allow the specification of a latex-style through an engine parameter and have it define the formatting of examples. With default formatting embedded as definitions at the top if no style is specified.

  Would that serve?


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  No, I don't see how that would serve. I'm not after changing the formatting of existing markup commands, but want an additional markup command, for expressing a variation not covered by the existing ones.

  The concrete example which made me file this RFE is that I wanted to document the default for an option as being the regular expression [[:graph:] ]. No markup for the RE at all looks wrong (at least in HTML, and probably also in LaTeX), but this is not an [arg], [class], [cmd], [file], [fun], [method], [namespace], [option], [package], [syscmd], [type], [uri], [var], or [widget]. It /might/ be considered a [const], but I don't think it fits well under that heading either. It's simply a string, which happens to have very technical interpretation.

  Making an [example] out of it would be to overemphasize it.

  If you insist on all markup being semantic, then some kind of generic markup command might be the way to go, e.g.

    [string regexp {[[:graph:] ]}]

  so that [cmd whatever] is equivalent to [string command whatever], [option whatever] is equivalent to [string option whatever], [arg whatever] is equivalent to [string variable whatever], etc. Then there wouldn't be an immediate need to request another markup command as soon as someone encounters an object that doesn't match the standard set.


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

  > I [...] want an additional markup command,
  > for expressing a variation not covered by
  > the existing ones.

  Ok. Now I understand the request.
  It is orthogonal to the 'macro' request. The macro request is extending the markup language by composing existing stuff into larger pieces and naming these, and this request is for extending the language by adding a new semantic category specifically, or allowing the writer to extend the language by defining new categories (generic markup command). Where the problem with the latter is that it is not at all clear how backends can treat such a generic markup.

  Thank you for the clarification, and I will mediate more about this and your other requests in the next days.


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

  Ah. There is no need to generate a new bug report by the 
  way. It is possible to attach files to existing reports, 
  after their creation.


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

  See 528433 for the actual description. Here we have the 
  sources to look at.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 19367: calculus-ak.tar.gz

  Logged In: YES 
  user_id=75003

  Enclosed the sources for the calculus modules
  as changed by me to fit them into tcllib.
  Changes I made:

  * namespace Calculus => math::calculus
  * Braced some expressions, prevented frink
    from complaining for unbraceable expr's
  * According to docs solveTri... is public,
    but was not exported. Is now exported.
  * Styleguide says that exported commands
    begin with a lowercase letter. Changed
    all exported commands to follow this.

  Arjen, please check that my changes are ok
  with you. If they are I will commit and expect
  that the committed variant is the master from
  then on. I say this because I hade to make some
  changes I did during the first integration
  again this time and would like to avoid this
  in the future.


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

  Yes, I will do that. I will make sure that my own copy is
  replaced by yours 
  (of course, if I am convinced you did the right thing :-).
  I was not aware of the styleguide's recommendation
  concerning exported 
  commands. But I will adhere to it.
  Where can I find the styleguide?


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

  This can be done with the logger package with a custom logproc that uplevels, look at the examples at the end of the manpage:
  http://tcllib.sourceforge.net/doc/logger.html


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

  Committed a fix. Cleaned up the selection code a bit beyond 
  this. Added proper argument checking and extraction, 
  documented some undocumented subcommands and 
  options, added toggling of selection per Control-Button-1.


login: nicolascastagne
username: nicolascastagne
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1258423
  Originator: YES

  Note : I did not put any "category", since though I found the pb with the math package, I guess it is perhaps more general in tcllib.


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

  Safe base means that a number of commands are not allowed, and not provided. pwd and file are among them.
  math uses pwd and file to set up old-style lazy auto-loading of procedures.

  To use math in the safe base you have to reconfigure it, i.e. make pwd and file available, maybe in restricted form.
  Or the package has to be rewritten to not use auto-loading of its pieces.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I have tried a SafeBase interpreter - it works for a package like math::statistics, but it fails for math itself. The error message is uninformative: script error.

  This needs some further investigation


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Note the following in the original description
  > LOG: {ERROR for slave interp0 : invalid command name "pwd"} 
  pwd is a forbidden command in a safe interp.

  The problem is likely

  math.tcl:36:    variable home [file join [pwd] [file dirname [info script]]]

  and later

      if {[lsearch -exact $::auto_path $home] == -1} {
          lappend ::auto_path $home

  I am not sure why this extension of the auto-load path is required.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I tried to solve this by avoiding auto_path and auto_load for safe interpreters and simply
  sourcing the files. This does not work either. My suspicion is that [info script] does not
  return a valid file name, but I still have to check that - puts is not very helpful in safe
  interpreters, I probably have to alias it.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I got this one solved - sn error in my test case, rather than something very weird in the package management. As the repository is read-only at the moment, I include the changes 
  and the test case here:

  -- math.test --
  test math-12.1 {Safe Interpreter} {
      #interp create -safe safeInterp
      ::safe::interpCreate safeInterp
      interp alias safeInterp puts {} puts
      set result [interp eval safeInterp {
          package require math
          set result [math::cov 100 100 100 -100]
      }]
  } 200.0
  ----

  -- math.tcl --
      # Set up for auto-loading

      if { ![interp issafe {}]} {
          variable home [file join [pwd] [file dirname [info script]]]
          if {[lsearch -exact $::auto_path $home] == -1} {
     lappend ::auto_path $home
          }
      } else {
          source [join [lreplace [split [info script] /] end end misc.tcl] /]
          source [join [lreplace [split [info script] /] end end combinatorics.tcl] /]
      }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  I am accepting this with some modifications. Replaced the join/lreplace/split with file join/dirname. The only command which made trouble was [pwd], not the path manipulation commands. I.e. no reason to drop them as well. The use of / as path separator is also not robust, i.e. portable. On windows it might quite well be \.

  Tweak to the testcase: Destruction of the interpreter after we are done with it.

  Another tweak to math.tcl, when I am done with the release: Make the whole thing unconditional. No need to distinguish plain and safe interps, just have plain source their files as the safe will do, i.e. directly, not lazy.

  Committed to head, version 1.2.5.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  FWIW, I see troubles with test math-12.1.
  Several messages about inability to read
  paths ending in pkgIndex.tcl.  One of the
  testing interps is the release of 8.5.8, so I
  suspect this is really a problem in the math
  package (code or test).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. Per talk with dgp on the chat based on his continued investigastions this seems to be a problem in Tcl's package.tcl file. See

  https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2910867&group_id=10894


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 0

  Reopening. Now its called 'Blocke' in the code.
  Note the trailing 'e'.

  Side note: This and the chi-squared fix warrant a bumping of the package's patchlevel.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Wojciech, dear George,
  thank you for the bug report, patch, and succesful test (all on c.l.t).
  Unfortunately, here are no test cases (I would like to have easy demo scripts).

  I have sent two questions about the patch to Wojciech by private mail.
  He replayed, that he is not at home at the moment and it will take one week.
  It is the same for me, I will be on holiday the next week.

  Here are the questions and the preliminary answers:

  -- Q1 --
  > Sorry, question about your patch for BWidget Entry themed:
  >
  > Patch line 82:
  >
  > -    if { $chstate || $chfg || $chdfg || $chbg || $chdbg } {
  > +    if { [Widget::theme] && ($chstate || $chfg || $chdfg || $chbg ||
  > $chdbg) } {
  >
  > Isn't an inverted logic more appropriate ?
  > Thus:
  > +    if { ![Widget::theme] && ($chstate || $chfg || $chdfg || $chbg ||
  > $chdbg) } {
  >
  > Otherwise, "Widget::cget $path -disabledforeground" is executed two rows
  > below which should IMHO fail...

  -- A1 --
  It is a good point.

  I think I converted all the code without testing all possible paths -
  I originally did this for a product I am working on and I guess we
  never came across this issue.

  ---Q2---
  > Sorry, another question about your patch for BWidget Entry themed:
  >
  > Patch line 90:
  >
  > -            return [eval [linsert $larg 0 $path:cmd $cmd]]
  > +            return [uplevel 2 [linsert $larg 0 $path:cmd $cmd]]
  >
  > This should be a general optimisation, to evaluate the command in the
  > caller space. May you make any comments on this ?
  > Is this for error message purposes or what ?

  --A2--
  The issue was ttk specific I think - from what I remember ttk bindings call:

  $widget instate {...} {some script}

  which fails since instate is not invoked in proper level - i.e. you can do
  set bg [$widget cget -something]
  $widget instate {!background} {$widget configure -background $bg}
  (this is just a quick sample, but ttk events used instate, which crashed)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Answer from Wojciech by E-Mail:

  I found some time to doublecheck it today - you were right - it should
  be ![Widget::theme]. In my case it crashes if theme is set and state
  is set to disabled.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you addressing this always annoying issue.
  For me, I required another window size to show the effect, but I know it. I never liked, if the scrollbar jumped back to 75% after having pulled it to 100%.

  There was a patch by private E-Mail


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Summary of private Mails about the attached patches:

  -Ideas by WC-
  Date: Fri, 17 Jun 2011 11:05:29 +0200
  From: Wojciech Kocjan
  I just filed a bug so I don't loose the example. I investigated the
  issue and have been wondering - would it make sense to just allow
  configuring smooth scrolling?

  It would make sense since with 8.5, smooth scrolling is also the case
  for other widgets.

  Do you think it makes sense? Do you think it makes sense for both tree
  and list? Do you think it can pose any problem?

  Do you know of any other solution that would resolve the Windows issue
  without such a rework?

  -About the first patch-
  Date: Fri, 17 Jun 2011 17:04:48 +0200
  From: Wojciech Kocjan <wojciech@kocjan.org>
  It expands region by number of pixels needed below list - i.e. if size
  is 163px (without borders), deltay is 25, then I am adding 13px
  because this is how much is needed below the list and will be shown if
  you move all the way down.

  -Modified patch by Koen Danckaert-
  -------- Original-Nachricht --------
  Date: Tue, 21 Jun 2011 17:57:15 +0200
  From: Koen Danckaert
  I basically agree with the patch, but I think it can be simplified.

  The original version already contained code to increase the scrollregion, but this code can be considered wrong since it did not work. So I would leave out that part and replace it by the new code.

  Also, the int() conversions are not needed because they already operate on integer arguments?

  With a bit more code refactoring I arrived at the attached patch, which works for me. Note, line numbers are different because I still work with BWidget 1.9.0, and I only did the Listbox part (not Tree).

  -Modified patch by WC-
  -------- Original-Nachricht --------
  Date: Wed, 22 Jun 2011 16:51:18 +0200
  From: Wojciech Kocjan
  Yes, that fix worked jut fine. Attached is patch against 1.9.4.

  -HaO-
  I specially like, how exact the scrollbar "jumps" now, if the scrolling region is at the end and the window is resized. Good work !
  Fix committed, thank you all !


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Oh, I have made an error and applied the wrong patch.

  For me, the patch has the following issues:

  1) the space below the last entry is far to much for me. (see attached foto)
  2) scrolling down to the end and resizing the window to get smaller:
    did keep the last row in view before.
    This is not the case any more.

  Could you reinvestigate the patch, please ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Koen and Wojciech reevaluated:
  - extra space (felt by me) is ok
  - resizing and keep last row was not related to the patch.

  Bug closed, thank you all,
  Harald


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260283: simpletest.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: simpletest.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260287: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  Hello,

  I'm adding to this an implementation of the inverse cumulative chi-squared distribution, since that's needed for statistical inference. It's a straightforward implementation of root solving. It turned out to be a little "touchy", but I think I've covered enough extreme cases that I can be pretty sure it will behave robustly.

  This has "source chisqr.tcl" at the top of the file and runs the tests at the bottom of the file, but it could really be put directly into the "chisqr.tcl" file.

  Eric

  File Added: invchisqr.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260314: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is an improved inverse chi-square. More robust than the original. Also tested to tolerance of 1.0e-9 against R output.
  File Added: invchisqr.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260323: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  OK, last fix to inverse chi-squared -- now catches when p = 1.0 (so return value should be infinity).
  File Added: invchisqr.tcl


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

  I note that this incompatibility has not been noted in the
  documentation. It should have been.

  Over to Pat as he wrote the new code and made the change.


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

  Another incompatibility: the old version returned hex digits
  in lowercase, the new version returns them in uppercase.


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

  The quick answer is that full compatability is available if
  people
  do [package require md5 1]. This loads the original script.

  The longer answer is that I believe that the current interface 
  for md5 is wrong. md5 defers to compiled implementations if
  it can 
  find one. Trf returns a binary value, as does the critcl
  md5c version
  and if you were to use openssl's version that will do so too.
  Even in the md5 code itself, it has to convert the hex back
  into binary
  to perform the hmac algorithm. 

  md4 returns a binary value and the checksums (crc{16,32},
  cksum and sum) 
  return decimal values. All these have a -hex option to get
  hex output.
  sha1 returns hex bu default, but I would like to redo this
  as per the new
  md5 too. md5 and sha1 are pretty much enhanced versions of
  md4. All these
  can use the ability to read data in chunks which is the
  point of the new 
  verison of md5, and I'd like to add this to sha1 eventually.

  So I do not plan to change the new interface as I deem the
  old one wrong.
  The new manual page already has a note about this. I shall
  try and make 
  sure its more clear in the documentation.


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

  A bit code diving showed, that there is in fact code, which
  is intented to provide the behaviour, i wand (combobox takes
  focus while tabbing, even if -editable false). The problem
  is the following:

  If the combobox is -state disabled, the widget doesn't take
  the focus. 

  For a [$combobox configure -editable false] call, there is
  code in ComboBox::configure which ensures, that the entry
  takes the focus, even if the new -editable value is false.

  But if one create a combobox with -state disabled -editable
  false and later change -state to normal with configure,
  there isn't special care, that the -takefocus of the entry
  is set to 1. 

  Something like this code added to ComboBox::configure seems
  to do the trick:

      if { [Widget::hasChangedX $path -state] } {
          if { ![Widget::cget $path -editable]  && 
               ![string equal [Widget::cget $path -state]
  "disabled"] } {
              Entry::configure $path.e -takefocus 1
          }
      }


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

  To make my report even clearer, here a short script, which
  demostrates the problem:

  package require BWidget

  entry .w1
  ComboBox .w2 -editable false -values {one two} -state disabled
  entry .w3
  ComboBox .w4 -editable false -values {one two}

  pack .w1 .w2 .w3 .w4
  focus .w1

  .w2 configure -state normal


  Try tabbing throu the widgets: the first one does not take
  the focus    although both ComboBoxes have (after the .w3
  configure -state normal) exactly the same settings. 


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

  It looks like the code in combobox.tcl conflicts with the
  focus code in widget.tcl that checks the -editable state.


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

  With current BWidget head, I still see the problem. The
  point is, that a Combobox, with -editable false which was
  -state disabled and later got configured to -state normal
  didn't take the focus, while tabbing.

  Please try the test script from an early comment by me:
  package require BWidget

  entry .w1
  ComboBox .w2 -editable false -values {one two} -state disabled
  entry .w3
  ComboBox .w4 -editable false -values {one two}

  pack .w1 .w2 .w3 .w4
  focus .w1

  .w2 configure -state normal

  Try tabbing throu the widgets: the first one does not take
  the focus    although both ComboBoxes have (after the .w2
  configure -state normal) exactly the same settings. 


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

  I'm not the right person to fix this; the BWidget code is beyond me.  Damon?


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: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 35487: latest3.diff

  Logged In: YES 
  user_id=240

  This patch fixes the problem, and, IMO, makes the code
  cleaner and more compact.  It passes all the tests,
  including those added by this patch.


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

  Just send the patch to 
  <andreas_kupries@users.sourceforge.net> and I will attach 
  the patch.


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

  I believe this is out-of-date.  Please reverify with the CVS 
  head of bwidgets.  IOW, it works for me.


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

  This is a bug in the ftpd package: it's generating an
  incorrectly formatted multi-line reply.

  I've update ftpd.tcl (r1.11 -> r1.12) as above to generate a
  single-line reply.
  (This may not be entirely correct, as '$f' may itself
  contain newlines, but it fixes the immediate problem.)

  According to RFC959 section 4.2 "FTP Replies", multi-line
  replies must be indicated with a hyphen after the status
  code, and the last line of the reply must begin with the
  status code followed by a space, e.g.:

  puts $sock "500-Copy failed:\n$path\n$f\n500 blah."


login: juliannoble
username: juliannoble
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=598324
  Originator: YES

  Further testing indicates it's the result of a difference in the length of output from md5::md5

  -------------------------
  C:\Users\Administrator>tclsh
  % package require tcllibc
  can't find package tcllibc
  % package require md5
  2.0.5
  % md5::md5 {a$apr1$a}
  ☻♀=?▼~?ì?▼NLS
  -------------------------
  c:\home\Administrator>tclsh
  % package require tcllibc
  0.3.2
  % package require md5
  2.0.5
  % md5::md5 {a$apr1$a}
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  --------------------------


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

  I cannot reproduce this fault using 8.5.15 or 8.5.2. The md5 module has a fairly extensive set of test vectors and I've added the "a\$apr1\$a" string to the test suite but I find that it passes with all the available accelerated and pure-Tcl implementations.

  C:\opt\tcl\src\tcllib\modules\md5>tclsh
  % package require md5crypt
  1.0.0
  % md5crypt::aprcrypt a c
  $apr1$c$wkeW9CQT8XlL.qu2CHHbm/
  % set md5::accel(critcl) 0
  0
  % array get md5::accel
  trf 0 critcl 0 cryptkit 0
  % md5crypt::aprcrypt a c
  $apr1$c$wkeW9CQT8XlL.qu2CHHbm/
  %
  % md5::md5 {a$apr1$a}   ;# pure-Tcl
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  % md5::md5c {a$apr1$a} ;# critcl implementation
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  %


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  There was an error in random-gamma. Here is the corrected version:

  # Generate a list of gamma-distributed random deviates
  # Use Cheng's envelope rejection method, as documented
  #   in Dagpunar, J.S. 2007. "Simulation and Monte Carlo:
  #   With Applications in Finance and MCMC"
  proc random-gamma {alpha beta number} {
      if {$alpha <= 1} {
          set lambda $alpha
      } else {
          set lambda [expr {sqrt(2.0 * $alpha - 1.0)}]
      }
      set retval {}
      for {set i 0} {$i < $number} {incr i} {
          while {1} {
              # Two rands: one for deviate, one for acceptance/rejection
              set r1 [expr {rand()}]
              set r2 [expr {rand()}]
              # Calculate deviate from enveloping proposal distribution (a Lorenz distribution)
              set lnxovera [expr {(1.0/$lambda) * (log(1.0 - $r1) - log($r1))}]
              if {![catch {expr {$alpha * exp($lnxovera)}} x]} {
                  # Apply acceptance criterion
                  if {log(4.0*$r1*$r1*$r2) < ($alpha - $lambda) * $lnxovera + $alpha - $x} {
                      break
                  }
              }
          }
          lappend retval [expr {1.0 * $x/$beta}]
      }
      
      return $retval
  }


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Also, adding a better way to test the random deviates. Now for the testing routine, add the pdf to the histogram of values. Here's the revised testing code:

  ##########################################################################################
  ##
  ## TESTING
  ##
  ## Can test pdf & cdf by running in a console. For random numbers, generate histograms:
  ##
  ##########################################################################################
  canvas .c
  pack .c -side top
  frame .f
  pack .f -side bottom
  label .f.alphal -text "alpha"
  entry .f.alphae -textvariable alpha
  pack .f.alphal -side left
  pack .f.alphae -side left
  label .f.betal -text "beta"
  entry .f.betae -textvariable beta
  pack .f.betal -side left
  pack .f.betae -side left
  button .f.run -text "Run" -command runtest
  pack .f.run -side left

  proc runtest {} {
      set vals [random-gamma $::alpha $::beta 5000]
      set remainder 5000
      for {set x 0.0} {$x < 20.0} {set x [expr {$x + 0.25}]} {
          lappend bins $x
          set distvallow [pdf-gamma $::alpha $::beta $x]
          set distvalhigh [pdf-gamma $::alpha $::beta [expr {$x + 0.25}]]
          # Total trials (5000) * step (0.25) * average value
          set distval [expr {int(5000 * 0.25 * 0.5 * ($distvallow + $distvalhigh))}]
          lappend distcounts $distval
      }
      # Assume none are left
      lappend distcounts 0.0
      set bincounts [::math::statistics::histogram $bins $vals]
      .c delete hist
      .c delete dist
      math::statistics::plot-scale .c 0 20 0 [math::statistics::max $bincounts]
      math::statistics::plot-histogram .c $bincounts $bins hist
      math::statistics::plot-histogram .c $distcounts $bins dist
      .c itemconfigure dist -fill {} -outline green
  }

  set alpha 1
  set beta 0.5
  runtest


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260324: gamma.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is not a change to the basic code. Instead, it's just rearranging the testing code a bit. I'm attaching a zip file with all of the needed files to run the tests. The code itself is (almost) stand-alone: just a few calls to "simple test" (also included).

  File Added: gamma.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Note that the zip file contains all of the fixes mentioned in previous posts. Also, it includes the incomplete gamma function. Finally, it puts everything in a "gamma" namespace (which I expect you'll move over to the math::statistics namespace).


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: NO

  The handling of hierarchical methods changed slightly between Snit 1.x and Snit 2.x, which explains why the error messages differ.  In each case, though, to delegate hierarchical methods you need to do something like this:

      delegate method {is *} to foo


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

  Proposed additional semantic markup (See
  tcllib-devel mailing list, subject
  "doctools tagging").

  * sectref  - section x-ref
  * syscmd   - Shell commands ('cat', 'ls')
  * method   - Subcommands or methods
  * option   - Options (-exact, -nocase, -textvariable)
  * widget   - Widget classes (Entry, Text)
  * fun      - C functions (Tcl_CreateInterp)
  * type     - C typedef names (Tcl_DString)
  * package  - package names
  * class    - class names (a la [incr tcl], stooop, etc)
  * var      - Tcl variables (errorInfo)
  * file     - file names
  * uri      - URIs


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok, I have to look into this. I am using safe slave interpreters to contain the plugins for the formatting backends, and maybe the setup of their package paths (*) is going haywire.

  (*) I am using the SafeBase for that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Note to self: Bisect using
  TCLTEST_OPTIONS='-match doctools-idx-50.0.1' ./sak.tcl test run -s /path/to/shell -l Y modules/doctools2idx

  Reason: Confirmed that 8.6b1.2 fails. Also found that 8.6b1.1 is ok. Some change in the core has caused this. Some change to the SafeBase most likely.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This is fixed in the Tcl 8.5 and 8.6 CVS head. An issue with the emulation of the [glob] command by the safe base. I.e. not a tcllib bug, just exposed by it.


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

  Regarding section titles. They are passed through as is from the input, currently by all backends. If you do not write all-caps they will not be all-caps in the output ... Could the real request be that you wish to write your titles normally, and the nroff backend convert it to all-caps, with the html backend passing them unchanged, as it does now ?

  Regarding the Table of contents. Do you have a concrete proposal or ideas for how the formatting of the TOC should be done instead ? Regarding the Synopsis the same question applies. Ditto regarding the formatting of examples.

  Paragraphs. As far as I know that is legal HTML, although possibly not legal XHTML. I agree, closing them would be nicer. The same for definition lists. I have added these to my TODO lists.

  dtplite has possibly quite rigid expectations. That is part of the reason it has the 'lite' moniker, as it made the implementation less complex. Is it possible for you to write up how your directory structure looked like, how dtplite behaved on it, and how your symlink forest helped in that regard ? Is it also possible to clarify the question on "how to add C library docs" a bit ? I have trouble understanding the problem with that ? From dtplite's perspective this would simply be another module in another directory. I think, if I interpret your question correctly.


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

  The closing of list elements (dt, dd, li) is now done. The closing of paragraphs is mainly done. Paragraphs in list elements do not get closed yet.


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

  I think I am will use this bug report as the one where we can discuss HTML styling in general.
  From the tcler's chat ...

  [15:43]<RockShox>aku continuing from yesterday re doctools
  [15:43]<RockShox>the class names dont matter as long as its documented
  [15:45]akuI guess. I added lots of lcass names today, no docs however yet for them.
  [15:52]<RockShox>its nice to have some divs too
  [15:52]<RockShox>like around the toc
  [15:52]<RockShox>or examples
  [15:53]akuI have no idea what you can do with CSS, please file bug/enhancement reports with examples of how you wish to change the HTML
  [15:55]<RockShox>you dont need to know what i can do with css
  [15:55]<RockShox>you just need to give me a way to address the distinct parts of a doc
  [15:55]<RockShox>if that makes sense
  [15:56]<RockShox>it probably means most doctools commands should generate something within a div or an individual tag with a class name
  [15:58]akuI may have phrased  my words badly too ... I have no idea what exactly you want me to put into the HTML which would support CSS. What is a div ? what attributes does it  have? things like that. I can work better when I see a concrete example of the change wanted, for this
  [16:00]<RockShox>a div is just a division
  [16:00]<RockShox>it doesnt really do much
  [16:00]<RockShox>but if you give it a class then the css can distinguish anything within that div
  [16:01]<RockShox>like i could make a link inside an example div different than a normal link
  [16:01]<RockShox>by addressing that class
  [16:05]akuso you are talking just about adding <div class=XXX>...</div> around certain things, or most things ?

  What is your opinion about this ?

  I am amenable to redo the generator to make it more accessible to CSS based styling.
  This pertains to the items in the report here too. Will adding divs and classes make the nested table superfluous, to be added back if wanted by css, or overridable by CSS, or ... ?


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES


  Re formatting block level elements...


  The auto-generated table of contents at the top of each page currently looks like this:


  <h2><a name="table_of_contents">TABLE OF CONTENTS</a></h2>

  <p>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#table_of_contents">TABLE OF CONTENTS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#synopsis">SYNOPSIS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#description">DESCRIPTION</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#commands">COMMANDS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#examples">EXAMPLES</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#see_also">SEE ALSO</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#keywords">KEYWORDS</a><br>


  (bug: note that "TABLE OF CONTENTS" appears twice; as a header and within the table of contents.. :-)


  It probably should look something more like this:



  <div id="table-of-contents" class="section">

    <h2>Table of Contents</h2>

    <ul>
      <li><a href="#synopsis">Synopsis</a></li>
      <li><a href="#description">Description</a></li>
      <li><a href="#commands">Commands</a></li>
      <li><a href="#examples">Examples</a></li>
      <li><a href="#see-also">See Also</a></li>
      <li><a href="#keywords">Keywords</a></li>
    </ul>

  </div>



  The synopsis should probably look something more like this:


  <div id="synopsis" class="section">

    <h2>Synopsis</h2>

    <ul>
      <li><a href="#ns_sls-get"><strong class="cmd">ns_sls get</strong> <i class="arg">key</i> <span class="opt">?<i class="arg">value</i>?</span></a></li>
      ...
    </ul>

  </div>



  The commands sections currently looks like this:



  <h2><a name="commands">COMMANDS</a></h2>
  <p></p>

  <dl>

  <dt><a name="1"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> ?<i class='arg'>args</i>?</a></dt>
  <dd>Pre-startup procs are called...
  <br><br>
  </dd>

  <dt>...



  It should look something more like this:



  <div id="commands" class="section">

    <h2>Commands</h2>

    <dl class="definitions">
      <dt id="ns_atprestartup" class="call"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> <span class="opt">?<i class='arg'>args</i>?</span></dt>
      <dd>Pre-startup procs are called...</dd>

    </dl>
  </div>



  The pattern is:

  - All sections have their own <div>, and the div wraps everything including the title

  - They all have a class of 'section', and an id. An id is like a class, you can use it for styling. However, it must be unique within a page, and is the recommended way of linking within a document. So, this works: cmd.html#synopsis. 

  - The id is the section name

  - Definition lists seem to be reused within doctools, i.e. [call ...] is another way to say [def ...], so we add a class of 'call' to the <dt>, even though it already appears within a <dl> classed with 'definitions'.



  The styling that used to be applied directly to the HTML elements can be moved to an embedded style sheet at the top of the page. If, the user passes a -style option to dtplite, the embedded styles are omitted and the link inserted.

  For example, to some vertical space between each section, and indent the Table of Contents, the styles will look like this:

  <head>
    <style type="text/css">
    <!--
      .section {margin-bottom: 2em;}
      #table-of-contents {padding-left: 4em;}
    -->
    </style>
  </head>


  The Table of Contents is a section, so it has both styles applied.



  Also, the whole content section should be enclosed in a div, like so:


    <body>
      <div id="doctools"
        ...
      </div>
    </body>


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

  Some clarifications ...

  Wrapping sections into div's ... A bit more complicated than you might think, as I know when a section starts, but not immediately where it ends. May need state flags ... At least I have to number more than one place ...

  id = section name ... you seem to actually use 'lower case section name'. what about spaces in the section name, is that allowed to be in the id too ? Or should we replace with underscore ?

  'call' = 'def'. Not quite. 'call' wraps an anchor around the defined item, and puts the information into the synopsis. 'def' doesn't do these things. Beyond that they are identical, yes.


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  Yes, I canonicalised ID's by bashing to lower case and replacing spaces with dashes.

  I'm pretty sure you can't have spaces in ID names. If it were a class it would be considered two class names, but for ID's I'm pretty sure you can only have one anyway. Still, ID names are also used in fragments (the bit after the #hash in a URL) and in general it's a pain to have spaces there.

  I used dashes instead of underscores again because of the URL fragment. URLs are often shown underlined and it's sometimes difficult to distinguish an underscore from a space when the word is underlined.

  I forced to lowercase because of the requirement that nroff and html output titles in deferent cases. Probably best here to accept any input from the source, and force to uppercase for nroff, title case for html, and lower case for ID names. It's predictable for people generating URLs.


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

  I found later that I am generating the id's by going to lower case, and replacing
  spaces with underscores. Point taken regarding underscore/space vs. dash.


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

  Started to work on this again in the last few days (*) - cvs head now contains:
  - sections, subsections are now closed. they are put in div's.
  - examples are in divs (still have to drop the wrapping in table), sectref in spans.
  - whole body in a div
  - still to do: redoing toc and synopsis, embedded style, and lots of other small things.

  (*) Now that I have a big set of formatting examples used by the testsuite to check the output.
      (see doctools/tests/man/* for the testcases, doctools/tests/html/* for the current results).

  Regarding id's I have seen another way of generating them, in the tcler's wiki.
  It uses the crc16 or crc32 of the section title, formatted as hex.
  I believe an md5 would be better, more collision resistant. for subsections merge in the section title
  predictable generation, no issues with any type of casing, no spaces, no dashes, no underlines.


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

  It seems section titling is the only thing I have left to do with this, and the generation of nice (sub)section ids.

  Examples are now properly classed, without lots of tables and such. TOC and synopsis are now styled through the CSS as well, and a standard CSS is placed in the output. At least if the 'meta' engine parameter is not set. If it is it is assumed that its contents will specify their own style, be it internal, or external. Paragraph handling is now done into, through and in lists / list elements as well, so that should look nice too, now.


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

  Anchors for (sub)sections are now nicely generated (sectionNNN, subsectionNNN), nroff does automatic upper-casing of (sub)section titles, HTML doesn't do that any longer. The automatic sections (like keywords, see also, etc.) are now camel-cased instead of full uppercase. This completes the handling of this report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  The proposed fix is certainly the easy fix. So I will do it that way.
  Committed revision [b3b52828b9].


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

  Fixed. Extended textutil::expander to keep track of location
  and report it as part of errors. Fixed doctools to not snip
  the new location information. Changes have been committed to
  head.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  I have tried to connect manually thru a telnet client. The
  server responds ok but as soon as I try to type something on
  the keyboard the errormessage is sent to me. I have
  contacted customer support for my email-service provider and
  (not very likely) maybe I will get a serious response in a
  couple of days. In the meantime if anyone has any ideas
  about what the cause of this might be I'd be thankful?


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Problem solved, it appears that the problem was that the
  emailserver only accepts connections over SSH. Perhaps a
  reason for considering an openSSH implementation in an
  encryption package ;-).

  In the meantime I will incorporate the use of a commandline
  SSH-client in the UIE communicator. Since most SSH-users
  have SSH installed, and if not can install it this should
  not be a major setback in peoples possible willingness in
  trying out UIE communicator.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Perhaps one might supply an enhanced error message. When
  this error occurs, try to connect through SSH instead?
  I think this would be very helpful as it most probably is a
  situation that will occur with many mailservers.


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

  Can this situation be detected in general ? If possible try to 
  create a trail of comminucation between the pop3 module and 
  the server without SSH in place:

  1. package require pop3
  2. package require log
  3. Enable logging or all levels.
  4. Divert logging into a file (optional)
  5. Run the pop3::open
  6. If 1-5 are in a script you can redirect the log output from 
  stdin and stderr into a file.

  A good error message will be possibly if and only if the 
  information from the contact with the mail server is good 
  enough to know that SSH is expected. I'd rather just 
  say "Problems with talking to server" than assuming that 
  SSH is asked for if the returns from the server do not state 
  this explicitly. Because that would be a bit of misdirection 
  and confusion for the user.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  What actually happens is that after the initial connect,
  i.e. replying with the server adress, anything sent to the
  server returns -ERR authorization first. When telneting I
  got this for every character typed on the keyboard. When
  using pop3::open, I did get a reply of +OK after user, this
  occured when password was sent.
  I'll have a look at this next week when I get home. The
  problem as I see it is that if one isn't aware of this, then
  it is going to confuse users. So some sort of information is
  needed. Perhaps a suggestion in the docs or somewhere to try
  Telnet if pop3::open fails, when telnet'ing this is much
  clearer as nothing at all can be sent to the server apart
  from the initial hello.

  But as I said, I'll have a look at this next week, and will
  see if I can get some definitive answers and such. It would
  be best of course if the servers had to reply with some
  meaningful error message, but alas that is most probably not
  going to happen. I'll post back here next week when I have
  investigated this further.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  I have done some additional checking running a socket by
  hand thru tcl. The situation is as follows:
  After USER-command is sent the mailserver responds
  +OK
  -ERR authorization....

  however

  The connection is in fact correct and if I continue by
  sending command PASS I am logged into the mailserver.

  pop3-module will tell me that there is an error (since my
  mailserver sends two replies to the first command) and I am
  disconnected. It seems that if it first sends +OK then the
  rest could be disregarded?

  - Veronica


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Workaround for now, removed the errorchecking catch around
  ::pop3::send $chan "user $user"
  ::pop3::send $chan "pass $password"

  Certainly not good in the long run but it works, just have
  to make sure to supply valid username and password.


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

  +OK immediately followed by -ERR without intervening 
  command ? That is seriously broken. A pop3 server is simply 
  not allowed to send more than one response to a single 
  command.

  That is not something we can handle automatically. We 
  cannot automatically detect if there is a second response 
  after the first. Well, we can, by waiting for some additional 
  response with a timeout, and assuming that nothing is wrong 
  if the timeout expires. This however slows the client down 
  considerably. I am not willing to support such in the default 
  setup. If anything this should be explicitly activated by an 
  option (i.e. expect two responses after USER and ignore the 
  second, or something like that). The workaround is fragile, 
  actually, IMHO, because it could also cause the client and 
  server to lose synchronization as there is one more response 
  in the pipe than expected. Or does the server does not send 
  a response after PASS ?

  In general I believe it is good to extend the documentation 
  with some general tips how to handle problems, like activation 
  of logging, using telnet, etc.


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

  Nothing has happened with this for a long time, no new info
  etc. Setting to pending, will auto-close in a few days.


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: dejavo
username: dejavo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=57232

  If you want a temp work arround
  I use ::List and get lindex 7 which is the time thingy just
  before
  the filename/dirname starts then i do split to the whole line
  and use lsearch to find its new place then i do lrange from
  its place+1
  to the end of the line and use the join command.
  Now I have the filename / dirname only without the other params.
  I also do string range to the first char if its "d" then its
  a directory.


login: oliversix
username: oliversix
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1091745

  Hi,

  the reason for this behaviour is the line
  return [ lsort $ftp(List) ]
  near the end of ::ftp::NList. I changed this to
  return [ lsort [ split $ftp(List) \n ] ]
  an it works perfectly.

  Bye Oliver


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

  Urgh. 3yrs old, and a solution for a year as well.
  See also 1553919, and 1563137. The latter has
  basically the same solution.
  Accepted, and committed.


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: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  This is user error, not a bug.  Stop packing - bwidgets 
  controls that.


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

  I am sorry, but I don't understand your comments. This 
  problem is not occurring with the BWidgets pacakage version 
  1.4.1, so I don't uinderstand what you mean by user error. I 
  would expect backwards compatibility to be maintained. 


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

  what you wrote wasn't correct for 1.4.1 either, it just didn't 
  conflict with the gm, which is now grid in 1.6.


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

  I am sorry for bothering you, but I need a clear answer to this 
  issue I am having. So, are you saying that I shouldn't pack a 
  tk widget inside a bwidget control? Or are you saying that I 
  should use grid instead of pack? If so, why?


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

  The use of pack on the widget for setwidget is redundant, and 
  arguably incorrect.  In 1.6 the scrolledwindow now uses grid 
  (better gm), so it really is now incorrect.


login: ferrieux
username: ferrieux
mimetype: text/plain
icomment:
  The attached patch does two things:
  (1) completely remove the -peername since it is redundant with the given remote host and port. The behavior is now to always return an IP address instead of a name, but that also happens when rDNS fails, so it's not breaking compat.
  (2) move the -sockname on control connection, which is needed to get the IP of the proper network interface, inside the part specific to active mode. Thus, passive mode is now DNS-free.


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: rkeene
username: rkeene
mimetype: text/plain
icomment:
  This functionality is a part of pki 0.4 (not yet in tcllib).  The only part that is not there yet is encrypting the output.


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  pki 0.5 ( http://www.rkeene.org/devel/pki/pki-0.5.tar.gz ) now supports emitting password-protected private keys -- feature request complete.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Does this mean that the change/code has been committed to the Tcllib Fossil Repository ?
  If not, then this is not truly done, and should not be closed.
  I am willing to do this, if necessary.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you !
  Theming support in BWidget is only for migration purposes anyway.
  I have not tested this as I suppose, that ttk::combobox will be used instead.
  But anyway it is a bug to fix.
  I will come into this on monday.
  - Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed in csv by removing many options from Entry.
  In addition, disabled state is now visible in themed Entry

  Please update files entry.tcl and combobox.tcl

  I fear, the removal of so many options from Entry will cause many other things to break in themed mode. I did not check this to deeply.


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

  Making # lines comments is difficult, as the underlying 
  processor (textutil::expander) recognizes only macros (in 
  []), and text.

  Would a comment command/macro, like

          [rem foo bar]
  or      [rem {foo bar}]
  or      [comment ...]

  be sufficient for your purposes ?


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

  That would be fine. Especially if it's short! [c foo bar] ?

  [comment ...] would seem to be in keeping.


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

  Ok, I will add a comment macro, together with a bunch of 
  other semantic markup.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have started the integration into the uri module.

  Currently I miss examples I could use to extend the
  testsuite.


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

  I have integrated the new code into the uri module.
  I would like to extend the testsuite as well, but
  lack examples I could use to so.

  Are the qoute, unqote commands URN specific or
  could they be used to un/quote ftp/http/file urls
  as well ?

  If not, what about a generic un/quote command
  which dispatches to to schema-specific routines
  (like we already do for split/join) ?


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

  I made small change to your code to make it work correctly. 
  I moved the uri code to compute schemePattern and various 
  maps into a procedure and have your code call that 
  procedure so that this information in the overall package 
  stays uptodate.

  Future: Introduce an official command to register new 
  schemas and have that command recompute this information. 
  This would also allow us to move the various predefined 
  schemas into their own files and thus make the central 
  package lighter.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 11986: urn.test

  Logged In: YES 
  user_id=202636

  OK Here is a test suite as per the RFC (I hope). I noticed
  that some of the tests fail my original code so I'm
  uploading a new version of the urn extension so that you can
  examine the differences.

  The quote/unquote code just implements the quoting rules
  described in the RFC. How relevant this might be to other
  URL schemes I am not sure but I imagine the only differences
  are in the characters that are required to be quoted or not
  quoted.


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

  New code added to head. Also base module rewritten to make
  addition of future sub-packages easier. See new exported
  command "uri::register". New code rewritten to use
  "uri::register".


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

  Have you checked that patterns are not allowed by the 
  documentation?


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

  > Have you checked that patterns are not allowed by the
  documentation?

  Yes.  The only user-level commands where it _might_ make
  sense are [$w exists ...] and possibly [$w index ...], and
  the documentation doesn't mention glob patterns here.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  This is actually a little bit more complicated than adding a
  foreach - what needs to be decided is how tclish this
  command should be, as opposed to behaving exactly like cat.
   For instance, the real cat, even if it is fed a
  non-existant file, cats all the preceding files, and then
  errors out.  Since tcl can only return once... you can't
  really distinguish like that.

  I think the best thing is probably the simple, foreach
  implementation, but it's worth thinking about for a minute
  or two.


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

  David committed changes to head on 2003-11-15 after a short
  conversation on the chat.


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

  This is IMHO now done with the fumagic aka fileutil::magic
  package and its commands.


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: eee
username: eee
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=661010

  This is a duplicate of patch number 654976, was mistakenly created as a new patch instead of simply updating that one. This has been corrected, so I'm closing it.


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

  Because Tk already uses native scrollbars on Windows since 8.0.


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

  WinXP-style controls are used iif there is a manifest file. Wish has a manifest included on the executable (See http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/win/wish.exe.manifest.in?view=markup). If an application that embeds Tk wants xp-style controls when executed on XP, either it distributes a manifest along with the executable, or injects the manifest into the executable. Both ways have can cause problems (one more file to distribute and to depend on, modify the makefiles, etc).

  IMHO, it's simpler to avoid the issue once and for all using Tile's scrollbars.

  Besides, is there a reason for not using Tile's scrollbar and use tk's one, on a widget set that explicitly requires Tile?


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

  Another point supporting the use of Tile's scrollbar (and Tile widgets in general) was made by Georgios Petasis on comp.lang.tcl:

  Tk's scrollbar does not support themes. widget::scrolledwindow is ok as far as you want to always use xpnative theme on Windows XP, but becomes broken as soon as you change the theme.


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

  OK Fixed this and I'll check for other similar problems when
  using Trf commands.


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  I have corrected the source code and the documentation
  w.r.t. the remarks by Andreas and Larry


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

  Arjen, as tcllib developer you should have write access to the 
  CVS of tcllib. In other words, you should be able to commit 
  this.


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

  I have not tried this yet - out of "coldwater fear" :) Let
  me try though ...


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

  Raising the priority of the item because its inclusion in the 
  upcoming release was proposed in the Tcllib-devel mailing list.

  Supporting or contrarian statements should be made on the 
  referenced mailing list for public discussion.


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

  This has been committed by Arjen. some minor formatting 
  work by me now too.


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

  I've applied a fix for this and checked it for 'make
  install' on OpenBSD and by sourcing the test script into a
  wish session. Should be OK now.


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

  This was fixed by Aaron Faupell on July 28, 2003. I guess
  you have Tcllib 1.4 or earlier. Tcllib 1.6 does not have
  this problem anymore.


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

  The method is "format". Use "2string" without a report 
  reference to see simple output. Same for "2chan", but 
  because of argument ordering use {} for the rpeort to 
  achieve the effect.

  As for tabular reports see the "report" module of tcllib. 
  The manpage has examples to define reports, and the 
  testsuite of report actually formats a matrix and thus can 
  serve as example.


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

  Added examples to the doctools manpages for matrix and 
  report. Committed changes.


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

  I later realised that the report object that was mentioned
  in the matrix documentation is indeed part of the report
  module. Perhaps the text in the matrix documentation should
  be slightly adjusted (add a reference to that module?) to
  make the link clearer.


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

  As you already did that - forget my suggestions. (It came
  later in a long list of e-mails; probably I should not just
  scan them from old to new but use a more intelligent
  browsing method :-)


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

  Can you please submit a small standalone code fragment that
  reproduces this fault. For instance,

   % package require BWidget
   1.6
   % LabelEntry .le0 -label Label -labelwidth 20 -labelanchor
  w -textvariable  ::_le0
   .le0
   pack .le0 -side top -fill x

  works fine for me. This is with the current CVS head for
  BWidgets.


login: aspenlogic
username: aspenlogic
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=494080

  Any word on this bug? Is it pilot error or is there a real
  problem with the widget?


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

  We would need to be able to reproduce this to call it not pilot 
  error.  You are sourcing a site-specific file, so anything might 
  have gone wrong before Bwidgets was used.


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

  This message is a followup on the investigation
  to determine the cause of

      "[528392] Missing commands in nroff format".


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

  Reopening. The current solution for the problem has the 
  drawback that the context stack is used both by the 
  expander itself to store internal information regarding the 
  nesting of 'expand', and by the macros in the input language. 
  This means that no language with an macro which uses 
  expand (like an 'include file') is able to open a context in one 
  file and close in a different one. Closing the expand level kills 
  all user context it generated.

  Better solution: decouple internal usage form macro context. 
  Store data in a separate stack. Have the outermost expand 
  check that the context nesting is done right.


  stack used by macro


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

  Having looked deeper I see no way to decouple things without
  introducing a major headache in how to actually handle file
  crossing context. The reason being that method [expand]
  opens its own context not only to save state (brackets), but
  also to capture the output so that it can return it as its
  own result. Any way of getting rid of that context implies
  complexification of the rules who determine which output
  goes where when and why.

  Closing for good. Thinking about different methods of
  implementing file inclusion than using [expand].


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

  As it is already implemented a patch instead of a feature
  request. TIP's are only for the tcl core. tcllib is not big
  enough yet to warrant them.


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:
  Thank you. Is this the
  http://en.wikipedia.org/wiki/International_Bank_Account_Number
  ? (As you gave no reference I googled for IBAN and found the above).

  Do you have test cases as well, per chance, i.e. examples of correct and incorrect IBANs ?


login: maxjarek
username: maxjarek
mimetype: text/plain
icomment:
  Yes, this is International_Bank_Account_Number. I attach new version function when i include references. I attach also test script for test correct iban numbers for some countries. I have only examples of correct IBANs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you. I have integrated this new version with the previous one, extending the range of checks a bit. I also moved some of the fixed values into type variables and simplified an expression, the check itself (nested expr is superfluous).

  One of the ibans in your tests is actually not correct, it seems:

                     PL78102030170000270200618694
  becomes  102030170000270200618694 PL78
  becomes  102030170000270200618694 2521 78
      % 97 == 46 != 1
  (Confirmed using 'bc'). Spaces in the numbers just for clarity.

  I will take that as a test case of an incorrect number.


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

  Patch committed, with slight changes to the error messages.
  Also committed the associated patches for the graph
  structure.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 21278: bug544453.patch

  Logged In: YES 
  user_id=202636

  There were two problems here. One is that the uudecode from
  a file was failing to handle DOS line endings properly. The
  other is to permit the decoder to handle unpadded lines more
  gracefully. The attached patch handles both problems. The
  decode procedure will now pad the input string to a multiple
  of four if necessary. This should work ok for Trf as well -
  although I havn't had a change to  check that yet.

  I'll update the CVS repository when I get the chance
  (tonight sometime (GMT)) and close the bug once the CVS has
  been updated.


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  File Added - 37972: tkchat.patch

  Logged In: YES 
  user_id=241231

  Updated comment for the second patch


   This code provides to highlight interesting text in the
  tkchat message window.

  The user interface can be invoked in two ways:
  1.) Through the Find entry on the FIle menu.
  2.) By entering /find in the message post window.
  (command line) The /find command may have an optional
  argument, which will then be used as the search string.

  To highlight an exact string or regexp pattern, enter
  it in "Find text" field. All matches in the chat
  window will be highlighted. Should the search be a
  time consuming one, it will pause when the Find dialog
  is closed and resume when it is re-opened.

  To remove all highlighting, clear the "Find text" field
  in the Find dialog.

  Known caveats:

  Sub-strings are not highlighted separately from the
  rest of the matching text when using regexp
  sub-matching. The whole match will be highlighted the
  same. This is a limitation of of the [text] -search
  command.


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  EE, Thanks for all your help as I tried to get up to speed
  on these development tools.

  -- Luke Myers


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  Looks like there were two identical .tar.gz archives added.
  I will try to delete one duplicate...


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  Hmm, it says:

  File Delete: ArtifactFile: Permission Denied

  well, that's okay since they are identical AFAIK


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  File Added - 38579: patch.diff

  Logged In: YES 
  user_id=241231

  Yet another revision. This patch includes support for
  navigating between results in the chat window and obsoletes
  all previous patches.


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

  We have applied another patch for a find function that uses
  /?regex typed into the entry widget. However, we might want
  to add a Find menu item like this too.


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: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  Oh, my error - analogous changes would need to be made for
  each setting of visited($node) in that function.


login: svenn
username: svenn
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=918049

  There is a complete example on  http://mini.net/tcl/8787 with 
  data and a picture of the wanted result. 


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

  testing with the latest tcl and tcllib show this problem no
  longer is occuring.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Had the same problem on UNIX.
  --> LC_TIME=nl_BE.ISO8859-1 
  unable to convert date-time string "03 okt 2005 09:28:47"
  In Dutch october with a "k" io "c"
  unset LC_TIME
  problem solved, altough the procedure should be
  able to handle other LC settings.


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

  Closing this old one as duplicate, nobody will be notified
  anyway of its demise.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10811: 439016.diff

  Logged In: YES 
  user_id=75003

  Enclosed an updated patch. I added nroff documentation for 
  the two functions,  reformatted the tcl code to adhere to 
  the general style of tcl (indentation) and braced several 
  expressions for speed.

  Test question: What happens if I feed a string already 
  containing tabs in some positions to tabify ? Are these
  taken into account when replacing spaces ? I believe not.

  Algorithm question: Why does it work backward through a 
  line ?


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

  Two more testcases showing that tabifyLine does not handle 
  existing tabs properly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10891: 439016.diff.1

  Logged In: YES 
  user_id=75003

  New patch containing a corrected version of tabify.


login: pkienzle
username: pkienzle
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=40262

  The following will cause an infinite loop:

    package require BWidget
    namespace import BWidget::*

    ScrolledWindow .textbox
    text .textbox.text -wrap no -height 2 -width 6
    .textbox setwidget .textbox.text
    pack .textbox -fill both -expand yes

    .textbox.text insert 0.0 "Line 1\nLine 2\nLong line 3"

  In this case, would it be possible to keep the horizontal
  scroll bar if it will be needed by any line of text rather
  than just the lines shown in the window?


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

  Unfortunately any test is sensitive to the actual fonts 
  used and geometry given.  If a very precise sample with all 
  the OS / fonts / exact geometry can be given, a solution 
  may be found.  Otherwise I can't repeat it in the current 
  code.


login: pkienzle
username: pkienzle
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=40262

  Given a text box with some short lines followed by one long
  line as in my example,

    (1) make the box tall enough and wide enough to show the
  long line plus a vertical scrollbar

    (2) shorten the box until just the top of the longest line
  is shown

    (3) narrow the box until a horizontal scrollbar will be
  required

  The horizontal scrollbar will shorten the box so that the
  longest line will no longer be visible, and so the
  horizontal scroll bar will not be required, and so the
  horizontal scroll bar will not be displayed, and so the
  longest line will again be visible, and so a horizontal
  scrollbar will be required which will shorten the box, etc.

  It fails with:
    BWidgets 1.3.1
    Tcl/Tk 8.3.1
    Redhat 7.1
    Linux 2.4.2
    XFree86 4.0.3
  And also with:
    BWidgets 1.3.1
    Tcl/Tk 8.3.4
    IRIX64 6.2
    XFree86 4.0.3


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

  The following code:

  package require BWidget
  namespace import BWidget::*
  ScrolledWindow .textbox
  text .textbox.text -wrap no -height 2 -width 6   
  .textbox setwidget .textbox.text   
  pack .textbox -fill both -expand yes    
  .textbox.text insert 0.0 "Line 1\nLine 2 \
  \nVery,very,veryllllllllllllllllllllllllllllllllllllllong 
  line 3"

  which differs from the example offered here earlier just 
  by the length of the line 3 (it is just enough to have the 
  line out of the text widget) crashes immediately after 
  starting. There is no need to do any resizing.

  Tested positive on "quality assured" AS Tcl/Tk 8.3.4.1, BW 
  1.3.1, Win 2000/XP, also on freeBSD 4.4 , BW 1.3.1, Tcl/Tk 
  8.3.4

  It don't seems to be specific only to exotic OSes.

  Actually, almost any window which uses ScrolledWindow can 
  be crashed just by resizing the widget around the point 
  where both scrollbars should appear at the same time. It 
  makes ScrolledWindow widget unfortunately unusable.


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

  The following procs avoid infinite loop but they have the 
  limitations to hide 1/10 of the contained widget before 
  displaying scrollbars. The loop borns with these calls:

  _set_vscroll  { 0 0.934343 }
  _set_hscroll  { 0 0.961538 }
  _set_vscroll  { 0 1 }
  _set_hscroll  { 0 1 }

  # -----------------------------------------------------------------------------
  #  Command ScrolledWindow::_set_hscroll
  # -----------------------------------------------------------------------------
  proc ScrolledWindow::_set_hscroll { path vmin vmax } {
      upvar \#0 ScrolledWindow::$path data

      if {$data(realized) && $data(hsb,present)} {
          set grid $path._grid
          if {$data(hsb,auto)} {
              if {$data(hsb,packed) && $vmin == 0 && $vmax == 
  1} {
                  set data(hsb,packed) 0
                  grid configure $grid.f $grid.vframe -row 0 -rowspan 2
              
              # G. Bloisi 29/May/2002, IONTrading
              } elseif {!$data(hsb,packed) && ($vmin != 0 || $vmax < 
  0.9)} {
                  set data(hsb,packed) 1
                  grid configure $grid.f $grid.vframe -row $data
  (hsb,north) -rowspan 1
              }
          }
  # G. Bloisi 19/Oct/2001, IONTrading
  #update idletasks
          $grid.hscroll set $vmin $vmax
      }
  }


  # -----------------------------------------------------------------------------
  #  Command ScrolledWindow::_set_vscroll
  # -----------------------------------------------------------------------------
  proc ScrolledWindow::_set_vscroll { path vmin vmax } {
      upvar \#0 ScrolledWindow::$path data

      if {$data(realized) && $data(vsb,present)} {
          set grid $path._grid
          if {$data(vsb,auto)} {
              if {$data(vsb,packed) && $vmin == 0 && $vmax == 1} 
  {
                  set data(vsb,packed) 0
                  grid configure $grid.f $grid.hframe -column 0 -
  columnspan 2
                  
  # G. Bloisi 29/May/2002, 
  IONTrading            
              } elseif {!$data(vsb,packed) && ($vmin != 0 || $vmax < 
  0.9) } {
                  set data(vsb,packed) 1
                  grid configure $grid.f $grid.hframe -column $data
  (vsb,west) -columnspan 1
              }
          }
  # G. Bloisi 19/Oct/2001, IONTrading
  #update idletasks
          $grid.vscroll set $vmin $vmax
      }
  }

  proc ScrolledWindow::_setSBSize {sb size args} {
  # G. Bloisi 29/May/2002, IONTrading
  bind $sb <Configure> {}

      $sb configure -width $size
      eval place $sb $args
  }


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Added - 43397: scrollw.tcl

  Logged In: YES 
  user_id=72656

  A complete rewrite of ScrolledWindow is attached that 
  corrects the problems.  It may have slight behavior 
  irregularities as I rewrote it from scratch and there are several 
  undoc'ed features of ScrolledWindow, but it does 
  behave "correctly", and doesn't suffer from the infinite loop 
  problem.


login: pkienzle
username: pkienzle
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=40262

  My example still fails (BWidget from CVS 2003-02-25 9:00am,
  configure.in says 1.6, pkgIndex says 1.5, wish 8.3.1 or
  8.4.0, RH linux). I haven't checked windows yet.

  ScrolledWindow .textbox
  text .textbox.text -wrap no -height 2 -width 6
  .textbox setwidget .textbox.text
  pack .textbox -fill both -expand yes
  .textbox.text insert 0.0 "Line 1\nLine 2\nLong line 3"


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

  Applied paul's patch - it corrects the small window infinite 
  loop problem.  Patch attached.  All seems happy!


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

  tcllib 1.4 was released 2003-05-06 and inifile was not added
  until 2003-06-01. it will be in the next version. until then
  it is available from the cvs repository.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 24607: 564670.diff

  Logged In: YES 
  user_id=75003

  Reason for the problem: Usage of [dns::configure] during 
  variable initialization, before the command is actually defined.
  Moving code to the end. Patch enclosed.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I printed the values of ln_Gamma(a+1), ln_Gamma(a), ln_Gamma(b) and the constituent terms term1 and term2 (on Windows XP). The problem is very likely caused in the case:

  a, b = 1000, 1

  a very uncommon distribution, however the test case should be dealt with properly.

  The terms term1 and term2 turn out to be 6.216 and -803.11. So the script is trying
  to take the exponent of -797 (approximately). We should change the expression
  to:

  set t [expr {$term1+$term2}]
  if { abs($t) < 200 } {
     return [expr {exp($t)}]
  } else {
    return 0.0
  }

  (This is a rather safe limit: exp(-200) is roughly 1.0e-87 - and the smallest number that
  can be represented is exp(-744) = 5.0e-324)

  I will fix this


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks. Please do not forget to bump the version number of the package as well. Bugfix => patchlevel.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The md5 package in Tcllib can use the binary package 'Trf' to accelerate its operations. For correct diagnosis of the problem it is necessary to know if the accelerator is used or not. To determine this please report the output of the each of the following commands:

     info loaded
     package ifneeded Trf [package present Trf]


login: mstrhh
username: mstrhh
mimetype: text/plain
icomment:
  % info loaded
  {/usr/share/tcl/lib/teapot/package/linux-glibc2.3-x86_64/lib/tcllibc0.3.4/Linux-x86_64/tcllibc.so Tcllibc}
  % package ifneeded Trf [package present Trf]
  package Trf is not present
  %


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Max, thank you for your help.

  The loaded tcllibc indicates that md5 is using the critcl-based md5c accelerator to perform all calculations. Which is also in Tcllib.

  The accelerator is written by Jean-Claude Wippler (JCW) per the notes in the comments. However overall author (integrating all pieces) is Pat Thoyts.

  I am re-assigning to Pat now for comments from him, and will also send a mail to JCW as well, to see how far his involvement went.


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: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Yes, we see this too on FreeBSD-amd64 with tcl-8.4.6 and 
  tcllib-1.6. 


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

  The whole dialog system used by this testsuite was
  rewritten. The CVS Head has no trouble on Linux, regular
  intel, and x86_64. Was this tested on Alpha again too ? I
  have no Alpha.


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

  Is that true? I will look into this - the $expression
  arguments turned out to be a problem in another module too,
  calculus. I will adopt the same solution.


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

  I have fixed this problem. The tests now all work. Still
  need to commit the new version.


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: kennykb
username: kennykb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=99768
  Originator: NO

  What's going on here is that the 8.5 [clock] command is implemented in
  Tcl, A number of procedures, including ::tcl::clock::format (the guts
  of [clock format] are created at run time. The fact that the $compiler
  interpreter in Comp.Init overlaods ::proc and ::variable means that
  the Tcl code inside [clock] cannot function normally.

  A workaround - perhaps a fix, but I don't claim to understand what
  the compiler is actually doing - is to add the line:

  $compiler alias clock ::clock

  to the set of compilation aliases.  This will cause all [clock]
  commands to be evaluated in the master interp, obviating the need
  to run [clock]'s Tcl code in the slave. This at least got the original
  poster over the fault in initialization.

  I would anticipate the same sort of trouble if commands such
  as [msgcat::*], [package], [auto_load] or [parray] were to be 
  evaluated in the $compiler interp, since they, too, are implemented
  in Tcl and use [proc] and [variable].

  Any thoughts?


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: NO

  This strikes me as being *not* a Snit bug, but a bug in the new implementation of "clock", etc.  Standard Tcl commands, it seems to me, should function normally in any interp, unless excluded for reasons of safety.  At the very least, they should be fully defined in a new interp *before* the interp's user starts changing things, rather than being defined lazily.

  I'm certainly willing to add a fix for this in Snit if it's determined that that's the right thing to do...but I'm not at all sure that it is.


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

  I don't think I can do what you're asking.

  [clock scan] and [clock format] both work by compiling new 
  Tcl code (defining a proc) every time a new format string is 
  encountered.  They rather depend on ::proc being there to do
  so. (And they suffer dreadfully in performance if they can't
  compile code.)

  Also, Snit overloads ::variable, and nearly every procedure
  in the [clock] implementation begins with one or more
  [variable] commands.  I don't really see how to avoid that
  one without using fully qualified variable names everywhere
  and eschewing [variable] entirely. Are you looking to inflict
  that level of unreadability on core code so that you can
  overload ::variable?

  I suspect that what you're really saying here is that you find it
  unacceptable that every Core command doesn't stand entirely
  alone -- that some of the Core is written in Tcl, so depends
  on other pieces of Tcl being there.  If you consider it a bug
  that not all Core commands are written in C, please bring that
  up on tcl-core, because we're moving more and more to
  using Tcl for at least some non-critical things.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Added - 265076: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  While not necessarily a short-term solution for this, turning the snit compiler into a fully namespace-encapsulated solution for 8.5 seems possible.

  It would really depend on what level of importance independent namespacing has for snit.  Most of the code I see doesn't rely on that.

  I just created the following patch that is a first pass at this.  It runs our TclApp, VFSE and Inspector from TDK locally with only one change (where we had ::typevariable used in the snit body).  I of course don't have full tests for this, so it would need further vetting.

  It is built so you can switch the modes (from namespace to interp) at 1 point.

  File Added: namespace-snit.diff


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Added - 265077: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  Updated my patch to correct one.
  File Added: namespace-snit.diff


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Deleted - 265077: 



  File Added - 265078: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  Update to one that still works with interp method
  File Added: namespace-snit.diff


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: NO

  Sorry, Kevin, I don't mean to be difficult.  It wasn't clear how you were using proc--I assumed it was just how the code was loaded, rather than being part of a scheme to compile code dynamically.  To the extent the core commands place serious restrictions on what you can do with an interpreter without breaking them, those constraints need to be clearly documented.  Are they?

  Jeff, I don't understand what you mean by "turning the snit compiler into a fully namespace-encapsulated solution for 8.5" and "independent namespacing".  Are you using a namespace *instead* of an interpreter?  Or putting the Snit compilation commands into a namespace *within* the current slave interpreter?  I'd like some better notion of what you're doing before I dive into your code.


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

  The patch should be rather self-explanatory.  It does all the snit stuff in the same interp in ::snit::compiler instead of in a separate interp.  This has benefits and disadvantages, but I think that the benefits may outweigh in the long run.


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

  By the way, the way that [clock] command is evaluated in the 
  slave strikes me as a trifle strange.

  I see:

  snit::widgetadaptor sframe {
      option -foo [clock format [clock seconds] -format %Y]
      constructor args {installhull using frame}
  }

  How does that differ in principle from

  proc foo {} {return bar}
  snit::widgetadaptor sframe {
      option -foo [foo]
      constructor args {installhull using frame}
  }

  The second case fails with

  invalid command name "foo"

  because, of course, [foo] exists in the master interp and not the
  compiler interp.

  In short, it's arguably the widgetadaptor definition that's making 
  the mistake (evaluating arbitrary Tcl code inside the compiler interp) 
  rather than Snit. Is it actually reasonable to expect arbitrary Tcl
  code to work there?


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

  For what it's worth, the list of core commands on which [clock] 
  depends is fairly long (unsurprising for a large module coded in
  Tcl).  I don't want to guarantee that the list will never expand,
  but I attach the current known dependencies. (On Windows systems,
  there is also a dependency on 'registry', not shown here.)
  File Added: commandlist


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

  Thanks, Jeff.  That does make sense, as it means global scope commands can also be available.  I'll take a look at it.

  Kevin, you're right, it's an odd place to call "clock".  I imagine it was intended to set a default option value to a timestamp, which (on the other hand) is a reasonable thing to do.  So it really ought to work.


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

  The line in question is an artifact of the udp support. It
  should have been removed. For tcp/37 connections we are not
  supposed to send anything but just await an answer. For
  udp/37 we have to send an empty packet first. Evidently
  FreeBSD's service is a bit on the strict side.

  I'll fix this so an empty packet is only sent if UDP is in use.


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

  With some testing it seems that the webpub server only
  responds to tcp connections. If you do a 
  set tok [time::gettime -protocol udp ntp.webpub.net]
  time::status $tok
  it returns 'error' and ::time::error $tok tells you it timed
  out.
  If you set the protocol to tcp then it's happy.

  UDP is used if you have tcludp installed. You can opt for
  tcp by using the -protocol switch.


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

  I'm currently looking into coding a c version to reduce
  memory consumption and speed (i like the tcllib interface,
  but it is a bit slow using 150 000 + Nodes...), perhaps
  there are some ideas how this could be done. Any help
  appreciated.


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

  Whow, there do you use 150 000+ nodes ?

  Seriously. We have a command per graph. The implementation 
  (= C function) of this command should be shared, and be 
  given a reference to the actual graph structure during 
  registration as true tcl command (ClientData of tcl 
  commands!). In the shared implementation cast the incoming 
  clientdata into the correct pointer to the graph structure 
  and then just use it.

  nodes, arcs. Use hashtables to map from node and arc names 
  to the structures hold information about them. Interlink 
  these structure. For example an arc structure should 
  contain references to the two nodes the arc is connected 
  too. Same for node structures, should have references to 
  all incoming and outgoing arcs. Possibilities here are 
  dynamically allocated arrays, linked lists, hash tables, 
  Tcl_Obj => list functionality.

  A C implementation would be great.


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

  I have finished a c coded version of the tcllib 1.3 version.
  It can be found at:

  http://purl.oclc.org/NET/schlenk/tcl/cgraph

  Michael


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

  The url of the archive containing the multiplexer sources 
  is http://people.debian.org/~davidw/files/multiplexer.tgz


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

  If I understand this correct this is some sort of multi-
  cast socket where each message is automatically posted to 
  all applications connected to the "socket", right ?


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

  In principle I want to add this. It makes for a nice core we can 
  use in a future Tcl'ers Chat.

  Changes I would like to do before adding:
  - Support of more than one multiplexer server by the package
  - Usage of either logger or log for debugging output.


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Added storage for memo messages to an mbox format file
  ~/.tkchat_msgs. Need to add a diaplay dialog to list and
  show them.


login: keithv
username: keithv
mimetype: text/plain
icomment:
  the crash is caused by a missing line:
      upvar #0 ::ftpd::$sock data

  But a bigger problem is that permission logic in authFileCmd is wrong for renaming. It returns not ok if the file doesn't exist and okay if the file does exists.


login: martinao
username: martinao
mimetype: text/plain
icomment:
  I noticed incorrect return values of Rename also. I did not mention this, as I did not want to "overload" the above bug report.
  Also, I did not see any easy correction possibility like above- this needs a deeper insight into ftpd.tcl. Therefore I currently use the workaround (client side):
  1) Check, if a file with the target name already exists. If yes, delete that file.
  2) Call Rename.
  3) Check on the target file.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed the missing upvar in CVS head. Thanks.

  Regarding the authentication ... The high-level rename is apparently implemented in ftp via 2 commands, RNFR, and RNTO, to specify source and destination path ... Currently both these commands auth-check their path for "write" ... Seems that we need new modes, for "rename-src" and "rename-dst" ?

  Reading "fileAuth" I am unable to understand it any longer. Should rewrite it to separate the handling of the modes, instead of having the mode and file checks mixed with each other.


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: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  I see the same notice on my 32-bit Solaris machine.
  Perhaps this is an intended feature of the test?
  Is this message seen on other platforms as well?


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

  Checking ... I see them on my linux 32bit machine too.
  Source dive ... uuencode.tcl, line 62, proc uuencode::pad
  Uses the log package to generate the warning.


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

  I should delete this message. It is just an alert to notify
  us that a provided uuencoded string is technically invalid.
  That is the generating program didn't pad the string out to
  a multiple of four characters. We therefore pad it with some
  nulls which may end up in your decoded result.

  If it's a uuencoded file then the line carries the number of
  chars so it's not a problem but if you are decoded a simple
  string you'll get some spare nulls - hence the notice.

  In short - this isn't a problem, it's just noise.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the feed-back.
  The version with the wrong version number was around one hour online, sorry for that. I suppose, it is already fixed so no action needed here.
  Andreas wrote, that the correct version is on teapot.

  Sorry,
  Harald


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

  These tests are actually meant to fail (see the
  description). They fail because in the version of tcltest
  that was used during development of the package, it was not
  possible to set up custom comparison routines.

  (It led to TIP #85 and the corresponding new version of
  tcltest. Perhaps it is time to update the test file.)


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

  No. Tests never fail(in the absence of bugs).
  If a test drives the functionality intentionally into an error state 
  then the test has to check that the error state has occured, 
  and report that as a sucess. And if the intended error state 
  did not occur, then that is a failure of the functionality, and 
  that is a failure of the test.

  Example (taken from struct, graph)

  test graph-0.1 {graph errors} {
      graph mygraph
      catch {graph mygraph} msg
      mygraph destroy
      set msg
  } "command \"mygraph\" already exists, unable to create 
  graph"

  We intentionally call commands in an illegal way, catch the 
  error message produced by the graph commands and check 
  that this message is the correct one. If it is the test is 
  sucessful. If the message is not right, then the test failed, as 
  something in the functionality is not as we expected it.


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

  Okay, that is a very reasonable (and probably the only good)
  solution. I will repair this and submit a new test suite


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

  Thank you. With a weeping eye. Did you run a cvs update 
  before your changes ? Or did you get a message about 
  conflicts when you tried to commit, and then copied the new 
  version of the one provided by the CVS ?

  Because the improved version is based on the code you 
  originally submitted, and thus overwrites the bugfixes and 
  cleanups I did. Especially the bugfix to make the file operable 
  overall as part of the tcllib testsuite.

  Ok, water under the bridge. I will now re-apply my changes to 
  your improved version to get these fixes back. However I do 
  ask you to make sure that your development is either based 
  on the code we have in the tcllib CVS, or to make sure that 
  your updates are correctly merged instead of simply 
  overwriting anything which was done with what is essentially 
  an old version with different changes.


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

  Committed re-applied fixes. Verified that the changes fix this 
  bug too. Done.


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

  I have been too hasty - I apologize. I did not do a cvs
  update. Curiously enough I also did not get any conflicts
  ... 

  I have not had the luxury to work with CVS these past few
  years (we switched to another product that I still can not
  feel at ease with), so I have to relearn the proper
  etiquette. 


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  fileutil::findByPattern is based on fileutil::find and this command likely exhibits the same behavior. IIRC the basedir is 'normalized' and you get that back in the results. I.e. [file normalize /net/<machine>/export/disk1/...] is '/export/disk1/...'. IIRC (again) this is cross-platform behavior.

  There are efforts underway to redo fileutil::find to be more maintainable (currently we have about 3 or 4 variant implementations for win vs unix, Tcl 8.4+ vs Tcl 8.3- etc.). This report could be addressed as part of that work.


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

  Ok. Fixed with the recent rewrite of fileutil::find, and committed to CVS head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 14680: latex.tgz

  Logged In: YES 
  user_id=75003

  Additional archive containing the changes for LaTeX output.


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

  Frank, please attach the tests you have to this report. 
  Having updated documentation (See profiler.man) would be 
  nice too. I assume that the change in tZero was done to 
  make the counting a bit more accurate by doing the [pstirng 
  map] mgmt before the timebase is set.

  start/stop:
      start => watchForNewProcs
      stop =>  stopWatching
  ?


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 65538: profiler_devel.tar.gz

  Logged In: YES 
  user_id=118601

  Hallo Andreas,
  > Frank, please attach the tests you have to this report.
  I have added my development 'package' with the tests. It
  contains the improved 'profiler.tcl' and the tests
  'profiler.test' as well as the 'all.tcl' to invoke them
  and some devel procedures (which are NOT needed, but
  sometimes they are quite nice) in 'profile_devel.tcl'.
  BTW, tracking 'puts' in tcltest is quite 'tricky', because
  it is redefined, when the option -output is set.
  > Having updated documentation (See profiler.man) would be 
  > nice too.
  Hummpf, is this done manually ??
  (That means not generated from the source ?)
  > I assume that the change in tZero was done to 
  ...
  Exactly, I forgot to mention, sorry. Other things I forgot
  is that I have done the work only for Tcl 8.4 and later.
  And still the empty info level problem with my application
  which I cannot track down to a simple example.
  > start/stop:
  >     start => watchForNewProcs
  >     stop =>  stopWatching
  Sounds good. BTW, init should use and should have an
  option to disable it.
  And finally, thank you for being interested.
  <frank/>


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

  Thanks Frank.

  Yes, the documentation is written manually, and not 
  extracted from the sources.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  I have few comments below:

  1. It would have been nice if the entire post to c.l.t was
  attached here because I couldn't understand the need for
  these changes just by reading this summary:). Anyway thanks
  to Andreas for adding the url here.

  2. agree about using 'canonical' names for function names

  3. Most of the profiler APIs such as reset, pause, resume
  and dump accept ?pattern? as an argument. I think it would
  make sense to do the same for addCmd and removeCmd APIs
  (instead of the proposed ?name? argument).

  4. Again, most profiler APIs work on commands. So the Cmd
  suffix looks redundant to me -- perhaps we should just have
  ::profiler::add and ::profiler::remove rather addCmd and
  removeCmd.

  5. At first, start/stop looked very similar in functionality
  with pause/resume -- I understood its purpose only after
  reading the full post on c.l.t. How about merging it with
  pause/resume itself so when pause is called, it will stop
  for arranging of procs and calling resume will restart
  arranging of procs. However, there is one caveat here -- new
  procs defined between pause and rename will not be profiled
  unless explicity added using addCmd after resume or
  implicitly added by resume itself. Another alternative is to
  add -nonewprocs option to pause (for stop) and -addallprocs
  option to resume (for start).

  6. The problem with set cmd mentioned here can also occur
  with any other core tcl commands used in the profiler. A
  better alternative would be to modify the TraceHandler proc
  to look at the caller's namespace scope and ignore profiling
  if it is called from the ::profiler namespace. Would the
  following work for you (untested code):

  proc :: profiler::TraceHandler {name cmd args} {

       if {[uplevel 1 namespace current] eq "::profiler"} {
           # Do not profile cmds in profiler namespace
           return
       }
       if { [info level] ...

  Of course this means that the profiler itself cannot be
  profiled but do we really need to do that? Also, use of
  above method will keep the profiler data to scripts only and
  not skew it with data on its internal commands (I don't know
  whether this is good or bad).

  7. I didn't quite understand the code related to 2nd try
  when info level returns empty. Can you elaborate on the
  problem with some examples.

  8. the profProc command should be modified to call addCmd
  API internally instead of replicating the code.

  9. agree about changing tZero for more accurate timings.

  It's good to see your patch on these improvements, because
  being a user myself, such enhancements can be very useful.
  We should definitely discuss the other open issues that you
  mentioned and look upon enhancing the profiler package further.

  Hemang.


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 66079: profiler.ema.txt

  Logged In: YES 
  user_id=118601

  Hallo Andreas and Hemang,

  > 1. It would have been nice if the entire post to c.l.t ...
  Done. Now I understand the cryptic comment. Thanks Andreas

  > 3. Most of the profiler APIs ...accept ?pattern? as an 
  argument.
  Well, the ?name? was a fast hack and I agree ?pattern? 
  would be better, I think this should be easy to add using
  [info commands ?pattern?] and call an internal add function?!
  This means the ?pattern? will have info commands semantics.

  > 4. Again, most profiler APIs work on commands ...
  Agree

  > 5. At first, start/stop looked very similar in functionality...
  I would not merge them together, because pause/resume 
  having to do with measuring time and start/stop (okay, 
  misleading names) are for setting up functions for profiling. So 
  these functions have different concerns and I would not make 
  one out of them.

  > 6. The problem with set cmd mentioned here can also 
  occur ...
  Hmmm, my experiments it occurred only with set, because the 
  profiler state is changed during tracing set. Well how
  wants to profile the profiler?
  Generally I think it is better to put such restrictions into
  the add command and move this item there. Put it here will 
  end up in more inaccurate time measurements.
  > Also, use of above method will keep the profiler data to 
  > scripts only and not skew it with data on its internal 
  > commands (I don't know whether this is good or bad).
  Sorry, I do not understand why the profiler is restricted
  to scripts this way. But I definitely want to measure how much
  time a procedure spends in 'puts' 'append', etc. and what is
  even more interesting how many calls where made to this
  functions.

  > 7. I didn't quite understand the code related to 2nd try ...
  The problem is simple, I do have empty but VALID results
  with [info level -1]. Believe me, I wrote tons of simple
  examples but up to now I cannot track down this effect. But
  unfortunately it is present in our application. So take it as 
  a workaround for our application. As soon as I get a simple 
  example I'll post on c.l.t and good ideas are welcome.

  > 8. the profProc command should be modified to call addCmd 
  API
  I definitely agree, but that's not so easy regarding Tcl 8.3 
  parts. BTW, init should use start.

  > 9. agree about changing tZero for more accurate timings.
  Looking into again, while being in leave trace the time should
  taken when entering the TraceHandler. But then time 
  measurement must be moved out of tMark, and that is 
  somehow ugly, isn't it.


  > It's good to see your patch on these improvements, 
  because ...

  First, thank you for getting involved. When I posted on c.l.t I
  was a little bit disappointed that was practically no response 
  to it.
  So let me say thanks to Jeff here.

  Second allow me to add and elaborate some items.
  - time in descendants. That's the points that leads me to the 
  need of canonical names. But imagine you add '::append' 
  or '::puts' to profiling and go through a procedure having 
  appends and puts in it.
  This will be measured as time in descendant. Well, normally 
  that's not what you expect and I guess not what you want? 
  So I thought about a concept of node and leaf functions 
  where node functions add to time in descendants and leafs 
  not. But which functions are leaf functions and how to detect 
  them automatically?
  Somehow leaf functions are atomic, is it possible to detect 
  them using info body?

  - To ease the pain of recursive procedure calls, I think
  one should store the level and the time. Having this would 
  allow more accurate 'level' statistics.

  - Coverage. I am thinking of the following workflow:
    - use trace execution with enterstep and/or leavestep.
    - restrict this trace to the current level.
    - 'back match' each 'step' with body and count.
    What do you think about that?

  - profiler.man I am working on it.

  <frank/>


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=118601

  I have added a reworked version as tar.gz, which contains an
  alpha of profiler.man and some of the improvements we
  discussed here:
  - ::profiler::add pattern
  - ::profiler::remove pattern
  - ::profiler::watchForNewProcs <enable|disable>

  Please have a close look on it.
  Todo: 
  - set time in descendants according to info procs

  >> 6. ...my experiments it occurred only with set...
  >What does one mean by "profiling the profiler"? Note that
  [snipped]
  >that the profiling of the profiler itself should not affect
  >the stats of my application which is being profiled.
  I agree
  <philosophy>
  Well, it depends on the point of view. Both results are correct
  in some sense. For a user of the profiler the second result is
  definitely the expected and correct one. For the developper
  of the profiler the first one is correct. But I think, and I
  guess
  you agree, this is only a minor issue and we should keep in mind
  what the user needs and provided correct results for him.
  </philosophy>
  So I disable 'profiling the profiler' in the tracehandler.

  >> 7. ...I do have empty but VALID results with [info level -1].
  [snipped]
  >like to take a look.
  Sorry, it is in my company application 
  and I still got no example for this.

  >You are defining caller as EMPTY and the profiler is
  >defining it as GLOBAL in some places. What is the difference
  >between the two?
  GLOBAL means the call was at toplevel
  EMPTY means the caller is deleted (tkInit) or was empty (see
  above)

  >> - time in descendants. That's the points that leads me ...
  [snipped]
  >... The [info proc $name] can be used for this purpose.
  I agree.


  >> - To ease the pain of recursive procedure calls...
  [snipped]
  >with it. Can you elaborate on this issue.
  Yes, IMHO except the 'atomic' time measurements for each
  call, all 
  other 'aggregate' measurements do not make much sense.
  For example you have a tree walker proc, which is typically
  implemented
  by a recursive descending proc. Therefore the time for the root
  node (time to process the whole tree) is quite different from
  the time to process a leaf node. Both results are typically
  quite
  different. And that's where the level come into play. This would
  allow the user to make his own statistics depending on his
  needs,
  whether he wants to profile the whole tree walking or the time
  needed to process a node.

  >> - Coverage. ...
  >I need to give some more thought to coverage.
  okay

  <frank/>


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  I have made several (minor) changes to your code and have
  attached
  a new tarfile for the same (hmm, I don't see any attach
  button at SF, 
  so I will mail you the tarfile directly). The tarfile also
  contains diffs for profiler.tcl with cvs called
  profiler_cvs.diff and one with your last 
  patch version called profiler_2.diff.

  The major changes are as outlined below:

  * Fixed code to ensure that it works with tcl8.3 as well:
      -- replaced use of eq conditions with [string equal ...]
      -- add and remove cmds can be called in tcl8.3
  * used switch stmt for watchForNewProcs and returns
    an error if the argument is not enable or disable
  * watchForNewProcs api should not change "paused" variable,
    to cover the following scenario
          suspend                                   ;# paused = 1
          watchForNewProcs disable
          watchForNewProcs enable     ;# should still be
  paused = 1
          resume                                     ;# paused = 0
  * Moved disabling of profiler cmds in TraceHandler proc
    to top of the proc so that it does not waste cylces in
    getting the $caller value
  * deleted special handling of set command in resume proc
     because it is no longer needed
  * created a new removeCmd proc similar to addCmd proc

  For EMPTY caller, does it happen only during "leave" traces
  since the caller has been deleted? Or does it happen when
  the caller's namespace has been deleted? Anyway, I will let
  Andreas decide on this issue.

  Okay, I now understand the issue of timings for recursive
  calls, so levels make sense. For coverage, you may want to
  file a RFE and we can take its
  discussion there. Also, have you looked at TIP86 (still in
  draft state) ... I beleive it can make the coverage feature
  very easy to implement.

  Hemang.


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 70081: profiler3.tar.gz

  Logged In: YES 
  user_id=118601

  Upload of Hemang's improvements of 
  my patch.
  Thanks
  <frank/>


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 72541: profiler4.tar.gz

  Logged In: YES 
  user_id=118601

  Hallo Andreas and Hemang,

  Now we getting to an end, hopefully.
  But let me add some correction and further improvements.

  - the uplevel in ::profiler::add:
  set addList [uplevel 1 [list ::info commands $pattern]]
  is needed, otherwise the test profile-1.4.1 will fail.

  - I add a list for gathering the call level. But right now
  there is no
  evaluation function for this.

  - And finally I make the time measurement more correct by
  gathering the time date at the beginning of the trace
  handler. ;-)

  - To test the Tcl8.3 part I rearranged the code a little
  bit, to be able to use and test the 8.3 parts with 8.4+.
  (init has an optional parameter to forbid the use of
  'trace'). Then I adapt the Handler of 
  8.3 to conform with the TraceHandler and correct some issues
  to get my tests pass for 8.3.

  - while working with our application I found out that in the
  8.3 mode info procs <profiledProc> does not work as
  expected. AFAIK, the interp alias does not make an entry to
  'info procs' see profile-1.4.3. Therefore programs using
  info proc will not work as expected in profiling mode. 
  I suggest the following change for addCmd:

  # uplevel 1 [list interp alias {} $name {}
  ::profiler::Handler $name]
  set body "\n  return \[uplevel 1 \[list ::profiler::Handler
  $name\] \$args\]\n"
  uplevel 1 [list ::_oldProc $name {args} $body]

  I guess using the above removeCmd must be changed, too?!
  Note, that this change is not in the currently uploaded sources
  'profiler4.tar.gz'.

  - Again it would be nice if someone looks through the code
  and the changes, because last time Hemangs changes made the
  source a lot clearer and better, thanks and a happy new year.

  <frank/>


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: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The command .pg is created, but does not work as expected.

  % .pg configure
  unknown option -geometry

  % .pg configure -bg red
  unknown widget .pg:cmd  


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

  Since this seems to never have worked ... you can set all the 
  options to start, but not change them.  BWidgets is fairly 
  obtuse with the arg handling here.


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

  Maybe its an error in the call of cmd, is there a ":" missing? 
  Would .pb::cmd work?


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  An addendum:  The windows and linux machines are behind a
  firewall and are being masquaraded to a different ip
  address.  I don't know if that matters.
  Also, yahoo has a strange mail server.


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

  Their mail server isn't that wierd. It appears to be RFC2821
  compliant at least.

  Here is what I'm using to test this:
   proc send {from to msg {server localhost} {port 25}} {
      set tok [mime::initialize -canonical text/plain -string
  $msg]
      smtp::sendmessage $tok -debug 1 \
          -servers [list $server] \
          -ports [list $port] \
          -header [list From "$from"] \
          -header [list To "$to"] \
          -header [list Subject "RFC 2821 test"] \
          -header [list Date "[clock format [clock seconds]]"]

      mime::finalize $tok
   }

  Note the -debug 1 -- this lets you check the SMTP
  conversation. For which I get
  Trying mx3.mail.yahoo.com...
  <-- 220 YSmtp mta260.mail.scd.yahoo.com ESMTP service ready
  --> EHLO zen (wait upto 300 seconds)
  <-- 250-mta260.mail.scd.yahoo.com
  <-- 250-8BITMIME
  <-- 250-SIZE 15990784
  <-- 250 PIPELINING
  --> MAIL FROM:<patthoyts@users.sourceforge.net> SIZE=265
  (wait upto 600 seconds)
  <-- 250 sender <patthoyts@users.sourceforge.net> ok
  --> RCPT TO:<XXXXXXXXX@yahoo.com> (wait upto 3600 seconds)
  <-- 250 recipient <XXXXXXXXX@yahoo.com> ok
  --> DATA (wait upto 300 seconds)
  <-- 354 go ahead
  --> . (wait upto 120 seconds)
  <-- 250 ok dirdel
  --> QUIT (wait upto 120 seconds)
  <-- 221 mta260.mail.scd.yahoo.com

  So it's not the yahoo server - it's something in the mime
  package -- perhaps you have an old version? I'm testing with
  mime 1.4 and smtp 1.4 here.


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  The problem is fixed if I add the "From" field to the
  header.  When I send mail to hotmail the "From" field is
  added automatically, but sending mail to yahoo throws the
  error if there is no "From" field.

  I downloaded the latest versions of mime.tcl and smtp.tcl
  off the CVS last saturday (July 3rd).  Previously I had been
  using mime.tcl 1.4 and smtp 1.3.5 that came with the active
  tcl distribution.


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

  I nearly forgot - I'm looking for comments and complaints
  before I go and commit this as a new 'dns' module.


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

  I've tested this with 1.88 and it seems to be working fine.
  I'll check it in later today.

  Nice work. :)


login: pascalscheffers
username: pascalscheffers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=582857

  Added a highlight [while] loop to mark all occurences in one
  go and then start jumping through the results.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Jasper,

  I have tried the following on a windows computer with two screens on tcl 8.4.18 and 8.5.7:

  pack [ComboBox .c -values {1 2}]

  Move the window (with the mouse) on screen one or two and open the drop-down box.

  It worked as it should.

  I will set the state to pending. I have no Mac and I suppose it is a Mac issue of Tcl (and not BWidget).
  I would appreciate if someone could check further.

  Thank you,
  Harald


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

  Applied to the cvs head, and committed. Updated the
  documentation for getbody as well.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  allow_comments - 1

  Fixed this issue - scalars were treated separately so that [dim] could report the correct dimension, but that special casing was used for row vecotrs as well.


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


  Note that the control module is now created.
  Addition of this command and others will be
  taken up later.


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

  It would be nice to have a semaphore package, such that
  one could direct all callbacks to trigger semaphores.
  This way, even if a pacakge does not support a "wait any"
  mechanism, the semephore package could trap all callbacks
  and provide a wait any mechanism.

  this technique could be used for
  - file events
  - http::geturl
  - email::send
  - timers
  ... the list goes on.
  Anyone could thus create a package with callback, and not
  have to reveal internal variables for use with a waitany
  command. The semaphore package could then provide a waitany
  on its internal variables and there would not have to be any
  breaching of encapuslation.


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

  Do you have a reference for precisely what you mean
  by a "semaphore" ?  Would that be an alternative to
  wait-for-any, or something to have in addition to
  wait-for-any?


login: erempel
username: erempel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=304001

  Yes, FR 454718 is what I was talking about.
  To explain a little further...
  If a wait-any concept is added to TCL, it would be very useful, but only to implimentations
  within a given package. If a user of many packages wished to wait for one of many package
  call to complete, and only had the wait-any method available to them, they would be required
  to know the variables in each package that they should wait on. In my opinion, any requirement
  for unpublished vairable names within a package is a violation of the intent of the package construct.

  I think that a better approach would be to have a consolidated wait-any *package* that can be
  invoked (signalled) by a call-back from an underlying package. This way, the developer would not
  be required to know about internal variables, they could use a wait-any concept, and they could wait
  for one of any event accross a number of packages.

  Furthermore, developers of new packages need only impliment a call-back, and this would fully support
  a multi-package wait-any method. No other special consideration need be done by the package developer.

  Just my thoughts on this.

  Evan,


login: kenstir
username: kenstir
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=246646

  I would agree that a general wait-for-any package would be more useful, and would make it easier for a 
  client to avoid breaking encapsulation.  However, I propose moving forward with this implementation 
  anyway, because:

  * the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage semaphores, 
  in the meaning of Solaris sem_wait(3R) and sem_post(3R).  The API just does not seem finished and working 
  and tested.

  * the proposed Semaphore package does not solve the wait-for-any problem, which this package has 
  solved.  Thus, this work is necessary anyhow, and we merely disagree over the eventual package layout.  
  Future package could use this wait-for-any implementation.

  * a general purpose callback mechanism would be difficult at best to get widely deployed.  The http and 
  fileevent applications mentioned are already well established in the core Tcl distribution.  To retrofit them to 
  use a general purpose mechanism would require volunteers and wide buy-in.  It would require design and a 
  detailed audit to ensure no existing code would break as a result.  Such an effort does not seem 
  cost-effective to me.

  * a client could avoid breaking encapsulation using the existing APIs together with this API.  That is, a 
  client could register a callback with the http package, set a client-specific variable, and wait for that 
  variable, avoiding the use of the undocumented $token(status) variable.


login: erempel
username: erempel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=304001

  Kenstir stated:
  * the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage 
  semaphores, in the meaning of Solaris sem_wait(3R) and sem_post(3R).  The API just 
  does not seem finished and working and tested.
  -------------------
  I'm not sure what documentation regarding Solaris that you were reading, but the proposed
  semephore package does adhere to the functional description of sem_wait(R3) and sem_post(R3)
  of the Solaris man pages.

  There may be some difficulty in a threaded TCL environment, but that was highlighted in the
  FR 454718.

  ------------
  Kenstir stated:
  * a client could avoid breaking encapsulation using the existing APIs together with this API.
  That is, a client could register a callback with the http package, set a client-specific
  variable, and wait for that variable, avoiding the use of the undocumented $token(status)
  variable.
  -----------------
  I think that you were using this as an example of how the wait-for-any would work, and it is
  also an excelent example of how the semephores would work. Your description of how
  you could make a callback routine that modifies its own variables and then use wait-for-any to
  wait for these variables, is basically the way that a semephore package would work.
  The wait-for-any command is merely a more convenient way of implimenting a semephore
  package. The package would be better off standard, rather than requiring that everyone
  impliment thier own. Since http, fileevents, timers and many other tcl packages use callbacks,
  there would not need to be *any* change to any code, just the way that we use the code.
  See below how the already existing http package could be used and waited for via the
  semephore package.

  --- example TCL ---
  set afterName [after 10000 Semephore::Signal timoutName]
  set URLToken [http::geturl $someURL -command Semephore::Signal]

  if {[Semephore::Wait *] == timeoutName} then {
    http::reset $URLToken timout
  } else {
    after cancel afterName
    processHTTP $URLToken
  }

  The bottom line here is that I was trying to stimulate a waiting package for the
  TCL Standard Library. I did not wish to make any changes to the core TCL code, since this is the feature
  request for tcllib.

  I was hoping that since the semephore package was so small and straight forward that it would be
  easy for TCLers to extend to handle threaded tcl and include it in tcllib. I think that we agree that
  in TCLs current state, waiting for one of many call-backs or events is difficult.


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

  This is still true today for question mark (mime version 1.5.2). Since question mark is part of the delimiter used in the subject content (=? and ?=) of a mime message, it causes error at decode time on client side.


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  The console show/puts commands are already gone - they were indeed way out of place, 
  except for debugging purposes ;).

  The -scale option is more serious: I will look into this. Thanks for reporting it.


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

  I have been looking into this:
  - The fix you suggest solves the immediate syntactical problem
  - The scale values for the axis remain unchanged though - you get the same axis back.
  - When I fixed that bit, I got strange results (the wrong range, only a part of the labels I 
    expected drawn).
  - The code as it is is too naive: I need to change a few private variables in the scaling array 
    as well (they hold the transformation from world coordinates to pixels)


login: arjenmarkus
mimetype: text/plain
icomment:
  Fixed in version 2.3.3: 

  A call to worldCoordinates was needed to reset the scaling, so that the values are mapped to the appropriate screen coordinates.


login: cwjolly
username: cwjolly
mimetype: text/plain
icomment:
  Sorry I should have included the prior Bug # searching for it was not as obvious as I had thought. 
  Here it is : 3147481


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Thank you. I am closing this one as a duplicate then, and handle the changes under the original report.


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  What I propose to do is to bring TclDES' des.tcl file into
  tcllib's des module and rename it tcldes.tcl. I have written
  a wrapper to replace the current des code and re-implements
  the current interface in terms of the TclDES interface. This
  also permits me to give the des module the same style of
  programming api we have for the other crypto packages (ie:
  set Key [DES::Init ...]; DES::Encrypt $Key $data; DES::Final
  $Key)

  I have raised a patch request on the tcldes project because
  I found some significant performance improvements for tcldes.

  I would prefer to imort the 3des/des version and not deal
  with DESjr but if Mac Cody wants to close the TclDES project
  and maintain the code in the context of tcllib there is no
  problem with having both.

  To summarize, [package import tclDES] would load up TclDES'
  API as currently released by Mac Cody. [package require des]
  will load TclDES and provide a tcllib standard API that
  includes backward compatability with the previous tcllib
  version.

  If someone wants to review the code before I check it in -
  contact me.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hello Koen,
  thank you for the demonstration script and the patch.
  For me, it works very well and solves issues I have open since years.

  I have slightly modified the patch to keep as much lines unmodified as possible.
  In addition, the formatting is adapted to the environment.

  Could you please verify, if the current cvs works for you ?
  Does the entry in the changelog hit the point ?

  Regards,
  Harald


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Hi Harald,
  I think the new CVS version is not completely right. But it's partly my fault: I wasn't aware that some of my earlier changes were already in CVS (submitted by Jos Decoster), so my patch was w.r.t. the 1.8 release instead of CVS head.
  Could you do the following:
  - Remove the <Configure> binding on $canvas. For this event, _frameConfigure is called from _resize. (Since $canvas is a user visible widget, you should not impose bindings on it.)
  - Remove the <Expose> binding. Its usage is discouraged in the Tk bind manual. I have replaced it with the bindings on <Map> and <Unmap>.

  Another note: I noticed that you use Windows-style linebreaks in the code (^M^L). Maybe it's better not to do that?

  Regards,
  Koen


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Koen,
  thank you, corrected (after light tests).
  Please stay as critic as possible - also formatting, documentation etc.

  Thank you,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Per the Changelog and commit messages this was fixed Aug 13, 2008 by Michael Schlenker.
  The relevant version of nameserv is 0.4.1.
  This version is available in the recently released Tcllib 1.11, through ActiveState's TEApot repository (You need the teacup application from ActiveState's ActiveYTcl distribution to access the repository), or by checking out the CVS head of Tcllib.


login: vonbane
username: vonbane
mimetype: text/plain
icomment:
  I was using 0.4.1 from the Activestate teapot.  I just looked in CVS and the "0" condition of the switch statement does not set oneshot.  I'm not good with cvs to see what was changed between 1.7 and 1.8 of nns.tcl but this problem was not fixed.

  Can you please look at this again?


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: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433


  Possible fix: add the pair "\01" "-->" to the
  $::htmlparse::escapes string map, so [htmlparse::mapEscapes]
  will change it back.

  Don't know what to do about parsing "<!-- ....-- >", this
  part is beyond me.


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

  The relevant part of the spec is

    http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5

  BOC is always '<!--'. '<--' is not legal. Tidy converts this
  into an entities, and essentially converts the whole string
  into a PCDATA section, plain text. Htmlparse is now doing
  the same.

  EOC is indeed allowed to have whitespace between '--' and
  the closing '>'. This has been fixed, by replacing the
  relevant [string map] with a [regsub].

  All changes have been made to the command "PrepareHtml".

  The changes have been committed to the Tcllib Head.


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

  The value reported by GNU C is in agreement with Abramowitz and Stegun, so
  it seems reasonable to take that as a benchmark. The actual computation in Tcllib 
  is done via the TOMS-322 algorithm. I am not sure what the accuracy is of that 
  algorithm, but I will check this.


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

  Solved this: replaced the original algorithm by one due to George Marsaglia.
  It is more accurate and simpler (but less general, as the TOMS algorithm
  covers several statistical functions). Version for the package: 0.2.2


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

  Further comments: install.bvat does not copy "doctools",
  "fileinput" and "irc" (note that "fileinput" is an empty
  module right now)


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

  Hrm. doctools, irc I don't know ... They are listed in 
  MODULES of Makefile.in and in install.bat themselves.
  fileinput is a still-born module. Use option -P for cvs 
  update/checkout to ensure that it is not in your CVs 
  snapshot. It is also not part of the source distribution, and 
  thus its non-installation is quite understandable.

  The other points about the env variable are taken. ... I will 
  write up something about tcllib installation this weekend. If 
  not, remind me.

  (I want to try a starpack based installer for windows, tarball 
  and starkit for unix).


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

  Ok, I consider this fixed: The .sh/.bat files and the old all-tcl 
  installer are discontinued and removed, and the new all-tcl 
  installer handles all these things.


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: 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: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1312539
  Originator: NO

  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

  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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 16294: mdist.diff

  Logged In: YES 
  user_id=75003

  The problem is that the release process as documented in 
  the DOC section of this project is currently not in sync 
  with what is done by 'make dist' as misses some important 
  parts. But the script "mkInstallScripts.tcl" generates 
  installation scripts for use with an archive generated 
  by 'make dist' and not the release process.

  Unfortunately 'make dist' is not without problems either 
  (it does not take the examples into account).

  Enlosed is now a patch which reworks the target 'make dist' 
  so that it generates archives which contains both modules 
  and examples (= where the directory structure is 
  essentially a reduced variant of the raw directory 
  structure instead of something completely different as 
  currently, i.e. before this patch), wehere the generated 
  install scripts are updated to deal with the new directory 
  structure.

  After application of this patch the release process is much 
  simpler:

  * Get tcllib from the tcllib CVS
  * Get config from the tclpro CVS
  * configure tcllib
  * make dist
  * Upload the generated archives.

  Asssigned for Bob Techentin for review.

  Bob, if this patch is ok IMHO we should regenerate the 1.1 
  archives too to fix the problem they currently have. Maybe 
  even only the installation scripts in them.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Extended the pop3 testsuite (CVS head after Sep 3, 2002, 
  12:30pm Westcoast TZ). The supplied script was used as 
  template for the test. This uncovered a bug in the pop3 server 
  of tcllib, introduced while fixing other bugs during the 
  weekend. Fixed this bug.

  I was unable to reproduce the bug. Maybe I am not using 
  enough messages in the maildrop ? The server (srv.tcl) is 
  currently hardwired to provide 3 messages per user, fvor two 
  users.

  The RFC regarding pop3 states that the server must not 
  renumber messages after the deletion of a message until 
  after the connection was properly closed (QUIT command). 
  During the transaction message ids stay the same, and 
  trying to retrieve or delete a deleted message cause a 
  negative response (-ERR something).

  Can you supply me with more data ? Now that we have a 
  testsuite this should become easier.


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425

  It's been a while, but if I remember properly, it skips alternate messages. (Against the "real" pop3 servers I've tried, 
  not the pop3 server in TclLib.) I just sent myself eight messages, "TEST ONE" thru "TEST EIGHT", in that order. I 
  then ran this program (modified to print out the message itself as well) and the output was

  x=8
  msg len=940
  msg= ... TEST ONE ...
  msg len=980
  msg= ... TEST TWO ...
  msg len=950
  msg= ... TEST THREE ...
  msg len=960
  msg= ... TEST FOUR ...
  msg len=0
  msg len=0
  msg len=0
  msg len=0

  Then when I went to fetch my mail, TEST FIVE, TEST SIX, TEST SEVEN, and TEST EIGHT were still in my inbox.

  Perhaps the ::pop3::delete is implicitly incrementing the message number even if given a specific message 
  number?


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

  I know, the delay is completely my responsibility. Got to work 
  on the pop3 testsuite last weekend.

  ... Checking.
  ... The pop3::delete maps msgid 0 to msgid 1, but does no 
  increment on the id.

  What happens if you do close the connection after each 
  retrieve/delete and always retrieve the first message, until 
  status returns 0 messages ?

  I will add log statements to the client in the evening so that 
  we can trace commands, their arguments, and server 
  responses.


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425

  Closing and reopening the connection was the work-around I used, yes. That renumbers the messages (except on 
  an Exchange server, if you don't delay long enough. Strange one, that, letting multiple users modify the mailbox at 
  once.)


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

  Allowing more than one connection to the same maildrop is 
  not allowed according to the RFC (1939, see pop3d module).


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

  Ok, the CVS head now uses the 'log' module of tcllib to trace 
  the activity of the pop3 client. Places where logging was 
  adding:

  pop3::send
  pop3::RetrFast
  pop3::RetrSlow

  Everything send to and retrieved from the server goes through 
  these three commands.

  Can you use that to create a trace of the problem when 
  talking with your pop3 server ?


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

  Extended to 10 messages, tried testsuite. It hangs itself 
  when trying to retrieve message number 7. The first 6 are ok. 
  Now I can look deeper into what is happening.


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

  More info. When I tried to log the server side the testsuite did 
  not hang. ... I used a custom log procedure to divert the 
  output of package 'log' into the server log file. ... Removing 
  this hangs on ... Supressing log messages. No hang again.

  Tentative conclusion: The output of log messages by the 
  server to stdout/err hangs the system somehow, when a pipe 
  or whatever fills up and then blocks, causing the server to 
  hang in the log output routine.

  However that does not match your experience, as you talked 
  to an external server. Hm.

  Despite this I will update the testsuite to more than 10 
  messages and supressed log output, for you to use in testing 
  the other server.


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

  We cannot repro this, and the testsuite doesn't find any 
  inconsistencies either. Closing.


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

  Is adding a [catch] around the failing unset statement 
  sufficient to make the problem go away ?

  (The ftp code we have inherited here is very convoluted and I 
  am trying to get away with a change as minimal as possible).


login: msofer
username: msofer
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=148712

  To illustrate the effect *only* on catch, it may be better
  to avoid measuring the time spent in the funny loops; after
  building them, do just

  set body "
      catch {set b}
      return  
      $nestedRanges
  "


login: msofer
username: msofer
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=148712

  Oops ... forgot to close this: new test was committed on
  15-03-2002


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

  What platform and version of Tcl was this? 

  I tested it on Windows XP with ActiveTcl 8.5.0 - and the math module passed all tests.

  matchNumbers actually tests up to seven decimals (0.1e-6), but it still does not fail.

  The difference between the numbers is:
  0.707107 - 0.70710678118654757 = 0.22e-6 

  So the failure seems justified - hm, why doesn't it fail on Windows XP then?

  I will need to investigate further, but I am still interested in your platform


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

  Ok, the original system it failed in this manner was a plain Linux/Intel (32bit) box.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Actually no. On the boxes where I have tested tcllib I haven't seen any errors in math except for the beta-distribution thing which I reported a few days ago and you have already corrected. I guess that we can close this as 'out of date' or 'invalid'.


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

  Added patch containing manpages for base64, cmdline and 
  fileutil. ftp is not done yet.


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

  Just saw that ftp has documentation, HTML based.
  See "modules/ftp/docs" ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10710: ftp.n

  Logged In: YES 
  user_id=75003

  Here is manpage for ftp. I used the HTML documentation as 
  template for the first sketch and then reworded it to make 
  it sound better, less stilted and more clear.


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: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 32747: diffs.txt

  Logged In: YES 
  user_id=24077

  what's going on here, i think, is that in one case Trf's
  base64 is being called and on the other system, Tcllib's
  base64 is being called.

  it appears to be that the routines aren't identical in the
  sense that one has a "\n" at the end.  since the copymessage
  routine chunks at 32766 octets, this explains why a "\n"
  shows up in the file.

  try the attached patch and see if it works


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=456242

  I tried this patch and the behaviour is still the same.
      --Jasper


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

  Ok, I tried my hand now. I can confirm that the new
  character comes in after 2^15-1 characters, and at the very
  end. Trf has no influence on this either. The problem
  happens with and without.

  New finding: Base64 is no problem either. Looking at the
  intermediate file model.mm1 I see that quoted-printable was
  chosen.

  Another new finding: When looking at the equivalent position
  in model.mm1 (line 488, .cnv = line 152) I do _not_ see
  additional newlines. In other words, the characters are
  _not_ added during writing. This exonerates copymessage.
  They have to come in during _reading_ and we have to look at
  'getbody' instead.

  Urrk. That looks like a complex state machine ... value,
  canonicalP, encoding ... Ok, we know the latter one. ...
  canonicalP as welll ... This seems to be in this while loop
  going through the input in some chunks ... With and without
  Trf, so mime::qp_decode is most likely not the culprit. I
  will have to look deeper at this loop.


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

  Arg. Got thrown off, the same data is a bit earlier than the
  line in question. It is a 492, and in the output, i.e.
  model.mm1. Ok, it is still copymessage to look at. Stopping
  now, evening, obviously my mental capacity is going down.


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

  I believe I found it. In command 'copymessageaux', near the
  end (lines 1637, and 1639), we have two puts commands. These
  should use 'puts -nonewline'. The reason: We are reading the
  input with read and convert it, so the output of the
  conversion has to be written without newlines. The converter
  is itself responsible for the insertion of newlines where it
  sees fit.

  This asymmetry of reading/writing caused the problem.


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

  Fix committed to cvs head. Added a testcase to the testsuite
  as well. Thanks Jasper, for the report, and your patience.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  After a bit more play, I figured out it should be
  [list_begin enum]

  and with that additional change, it appears the doc then builds.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Uurps. These were all my bugs, and easily fixed. Would have been better had I validated the syntax before committing :( Fixes are now in the head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes, that is intentional. The code doing this is in the last 6 lines of the file "log.tcl".
  This was done because (we believe that) in most situations debugging output is not wanted.
  Most wish to have such output only when actually debugging an application.


login: jxmercog
username: jxmercog
mimetype: text/plain
icomment:
  Ah, I see it now.  Should add the default settings to the man pages.  It was not obvious in the code as the initialization of the array had everything set to '0'.  Plus, should not have to look in the code to figure out the default settings. Probably in the Levels section where you list all the log levels.  
  Let me know if you want me to open up a new tracker item for the doc change.

  Thanks,


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  No need too. I have now updated the docs in the CVS, and also made a comment in the code to cross-reference the two relevant places. Changing state to 'fixed'.


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

  What module are we talking about ? 'counter' ? or 'html 
  display' ? Or is html display a command in 'counter' ?


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

  The ncgi functions are used in "counter" in the following proc:

  counter::histHtmlDisplayRow

  The package ncgi isn't required.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902

  It seems mystifying to me; have you checked that it is not
  an [encoding] problem? If the problem really is a 64-bit
  nasty, it might be fixable with a quick [expr {...&0xff}] in
  the right spots to trim all the offending bits...


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

  More data:  I see these test failures in a Tcl 8.3.3
  and in a Tcl 8.4a2 interp.  I do not see them in a
  Tcl 8.4a3 interp.

  More magical corrections from the Unicode update?

  Anyhow, a [package require Tcl 8.4] might eventually
  take care of this.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  I don't see this bug anymore with tcl8.4.  It does seem to
  produce different results for the first failed test on x86 

  Test de caract=FFres accentu=FFs : =FF =FF =FF =FF et
  quelques contr=FFle=s =22=5B=7C=5D()=22

  and my linux ppc (unsigned char) machine:

  Test de caract=C3res accentu=C3s : =C3 =C3 =C3 =C3 et
  quelques contr=C3le=s =22=5B=7C=5D()=22


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


  If this package needs Tcl 8.4 to work
  correctly. lets just add [package require Tcl 8.4]
  and declare victory.


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

  Better solution, IMHO: Add known bugs section to mime 
  manpages and add info about this problem.

  Forcing the large set of 32-bitters to switch to 8.4 for a bug 
  hitting only the small 64-bit crowd is not so good IMHO.


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

  Man page is extended now with section about known bugs, 
  and this item was filed.

  Modding down, no other change for the 1.4 release.


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

  Apparently. No test failures for me on a x86_64 platform as
  well. Across Tcl 8.[2345].


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed in CVS head. doctools::paths was a plain version mismatch. doctools::nroff::man.macros required a rename of the package. The '.' (dot) is not allowed for Tcl Module names. man.macros became man_macros. The packages in doctools2{base,idx,toc} using it were updated too, with proper version bumps.


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: jaspert
username: jaspert
mimetype: text/plain
icomment:
  File Added - 42845: buginfo.tgz

  Logged In: YES 
  user_id=456242

  Oops, seems my files didn't get uploaded, I'll try again 


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

  The attached patch is not a self-contained example.  Could 
  you narrow it to a smaller code snippet?


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=456242

  You should be able to reproduce the problem with these files. I 
  didn't develop this code I am just trying to port the tool to Linux. If I 
  have time I'll try and find a simpler procedure that causes the 
  segfault. 


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

  When trying with those files and your example, it complains 
  about a missing image and nothing works ... perhaps rework 
  without the images?


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  File Added - 43020: mre.tcl

  Logged In: YES 
  user_id=456242

  OK I've edited mre.tcl and removed the references to other things 
  that were lying around my system (I hope...) Also I found that after 
  the frame is drawn by the RunEnv::Create dummy command, you 
  can get the segfault directly with the command 
   
  .mre.mainframe.frame.mainpw.mainDisplayPane.notebook.fpage/1.panedwindow 
  sash place 0 2 5 
   
  (but change that last 5 into an 8 and it accepts the command) 
  Hopefully that makes it easier to trace 


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

  It's much easier on developers when problems like this are 
  distilled down.  This can be repeated in 3 lines of code:

      panedwindow .p
      .p add [frame .f -width 20 -height 20 -bg pink]
      .p sash place 0 2 5

  It's also a core bug, not a bwidgets bug.  Please reissue in 
  the Tk tracker (unfortunately SF doesn't allow moving bugs 
  between projects).


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

  I went ahead and fixed this for 8.4.  The code is actually an 
  error - the first sash only exists when 2 panes exit.  This is in 
  8.4.2.  You will get an error now from your original code 
  sequence.


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

  Committed to head, and version number bumped to 4.0 as 
  requested by John LoVerso (original author).


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

  Please do not inline such large files in the comment 
  section. Attaching them as files is much better.

  Anyway

  The uuencode errors seem to be a duplicate of #553732
  "uuencode.test warnings: 64 bit"

  The yenc warnings seem to be a duplicate of #548354
  "yenc testsuite trouble".

  For the stooop messages I have no duplicate report.
  I am passing this to jfountain as author of stooop.


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

  I would very much like to fix that.

  Unfortunately, I do not have a fast enough cvs access from home, and from work the firewall prevents 
  cvs.

  Is there somewhere a 8.4a5 snapshot tarball that I could download via http or ftp?

  Thanks.

  Jean-Luc


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 23186: pat.yencode.test

  Logged In: YES 
  user_id=15949

  I am attaching a patch to yencode.test that fixes its test
  suite error.  There were two problems.  First was that
  tcllib test runs from the top level directory, but
  yencode.test expects it is being run from the modules/base64
  directory where its datafile is located.

  The second problem was a wrong variable, which I have fixed
  as well.

  Can someone fix this in the cvs?


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

  Note: We do not seem to have test cases for asnTag/asnPeekTag regarding PRIVAT, nor CONTEXT either. Only UNIVERSAL and APPLICATION.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  Have corrected these. The problem is due to TAG priority. 
  Still have a couple of minor issues, not mentioned here, 
  to correct before applying a patch.


login: edsuom
username: edsuom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302938

  Forgot to log in...but this was from me (Ed Suominen). Also,
  if I can figure out how, I'll submit a diff for easy reference.


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

  Note that this is just one specific instance of
  a general problem with the packages in tcllib:
  they fail to declare and manage their package
  dependencies.  This report is about a failure
  to declare dependence on "Tcl 8.2", but all
  dependencies need to be declared and checked.


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  RFC868, while being quite vague in parts, specifies a 32bit
  signed integer as the datum returned to clients. We then
  subtract 2208988800 to convert to unix time. As this is
  supposed to be current time (we are not dealing with history
  here) this should give us something between about 0xc3e8fc4c
  and 0xffffffff which means some time during 7 Feb 2036 we
  have a bit of a problem with this protocol.

  However, I don't know that testing this way is especially
  relevant under 64 it platforms (not having such a machine).
  Do you actually get correct times out of this?


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


  Just ran this test again on
  64-bit Linux/Alpha with the
  ntp that came as part of
  tcllib 1.6.  The test still fails.
  The value of $t during failure
  is -3217070557

  Hope that helps.


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

  We are seeing this too on FreeBSD-amd64. With tcl-8.4.6. Must 
  be a 64-bit vs. signedness thing. The time as returned by 
  time::unixtime in the time-1.3 test is something like 
  -3197788553. 
   
  This is with tcllib-1.6. 


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

  Was the 'still failing' for Tcl 8.4 or 8.5 ?
  For 8.4 I now get

  modules/ntp/time.test
  - time    1.2

  ==== 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:
  1 {error: data format not recognised}
  ---- Result should have been (exact matching):
  0 1
  ==== time-1.3 FAILED

  A bit different.


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

  $ /local/src/tcl8.4/unix/tclsh sak.tcl test ntp
  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:16:49 PM EDT 2005
  Module: ntp
  modules/ntp/time.test
  - time    1.2

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


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

  On the machine I am on State(data) aka <token>(data)
  contains 7 bytes, and expected were either 4, or 48+. That
  is the cause for my error message

  Oh, the ClientReadEvent is bad IMHO. The moment it has
  received 4 or more characters it stops receiving. This is
  bad if the 48+ byte is received in chunks, as the receiver
  will stop before it has gotten all data.

  But is that the root cause for my test failure. I have to
  determine how much data is actually sent. For 32 and 64 bit
  systems.


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

  For RFC868 (time::gettime) the data that we send as a client
  is irrelevant as it is only used to get the server to
  respond to us. For TCP connections we don't send anything.
  For SNTP we should always send 48 bytes.

  Added code to the ClientReadEvent to stop reading when we
  have received the amount expected for the protocol in use
  (ie: 4 bytes for RFC868 and 48 for RFC2030). We should not
  really get data in chunks as RFC2030 really only operates
  over UDP and the server response is handled as a single UDP
  packet.

  I wonder why I don't see 64-bit related failures on my sparc64.


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

  I have no idea so far regarding the 64bit failures. I will
  test your changes to see if that got rid of my 'data format
  error'. Maybe I will have a failure, maybe not. I will
  report back when I have done this.


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

  Ok, I found the reason for my data format errors. Yes, I
  still had them despite the change in ClientReadEvent. But I
  knew that I should have gotten 4 characters, instead of the
  actual 7.

  In the fake server the _listening_ socket is fconfigured to
  binary. The actual socket however is not. After I fixed that
  the data format error goes away. So the translation got some
  EOL characters and expanded on them.

  With this gone I have to report that I now see the same test
  failure Don was reporting originally. This I still have to
  look into. However with that change maybe even your sparc64
  is able to repro the failure ;)


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

  Ok, it was a simple masking problem as we had before with
  png and crc. Just restrict the results to 32 bit to get the
  correct information. Committed a fix.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Does  a good usecase exist for an empty servicename?

  If not, i would simply document that servicename may not be empty and add a check for that. Otherwise some more work is needed to enable empty names.


login: heinrichmartin
username: heinrichmartin
mimetype: text/plain
icomment:
  I would have considered the root service the default for all other ones. This seems easier than many non-empty roots...
  A message usecase might be during cmdline param checks.
  Any workaround like "logger::init _" does not provide inheritance.

  But I see, that it might be much more work.
  Preventing the infinite loop should be the primary goal :-)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  allow_comments - 1

  Added some new tests and a new error code for this.

  Empty names or names that are just : or ::: etc. now raise an error on init.

  The idea of a global logger to ease the setup is surely a good thing, but using the empty logger for that would be a little difficult with the current style.


mimetype: text/plain
icomment:
  something i realized after a few tests.  The key set is not always generated with the equal amount of bits specified, and that is what causes the problem at the time of the signing.

  Something that may patch the problem (not the actual fix) would be to recalculate the bitlenth using the way parse_key proc does and set retkey(l) to that value before returning the set of values at the end of the generate proc.


mimetype: text/plain
icomment:
  I uploaded a different algorithm that works for me, still slow on the prime search on bigger keys (2048)

  hope it helps


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Converted and committed (See bottom of tests/faop_regex.test). Note: T'was a bit difficult to copy the code out the report, well, and then fixing the broken lines to get back usable Tcl. Please _attach_ examples and such as a file next time.


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: 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: 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: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 291284: cursor.tcl

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: cursor.tcl


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

  1. Fixed
  2. Fixed
  3. The problem is the . starting the '.btn'. Having this as first character on the line causes the roff formatter to interpret it as a command. A command it does not understand. It apparently simply drops the whole line. Fixed by indenting the example, i.e. working around the problem. Better would be to fix the doctools nroff formatter to somehow quote a leading '.' in plain text to prevent interpretation as a roff-command.
  4. Fixed.
  5. See explanation for 3. Same fix.
  6. Actually the two examples are different. The first one demonstrates instance destruction (spot destroy), the second type-destruction (dog destroy). It might be beneficial to put both examples together into at the end of the block.

  I am leaving the decision regarding item 6 to Will. The others the pure typos and such and have been fixed in the CVS head now.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  The problem is not that the extra points introduced for an already closed polygon get in the way, but the specific choice of the "point far away". The round coordinates I chose for my
  test case make the point intersect two sides at the vertices. 

  This is a corner case that needs to be solved!


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  A more standard way would be, I believe, to use [subst] internally, not [format]. That way we just have to change "..."-quoting to {...}-quoting  (and, of course, change the name of the log command).
  Alternatively, keep the name, i.e. "log", then this is a major API  change, forcing a major version change, i.e. 1.3 -> 2.

  The subst is certainly what wub's Debug package does. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Indeed, subst gives more power than format.

  format would be similar how the msgcat package handles things.


login: hartweg
username: hartweg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=338658

  Version 1.52 of tkchat fixes this problem & also properly 
  handles multi-line messages correctly


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

  Note that the patch as provided here is malformed. Manual 
  application is performed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Renamed 'LexNormalize ' to 'lexnormalize' and documented it.
  Version bump to fileutil 1.14.
  Committed to CVS head.


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

  Yes, see revision 1.8 of the code. But this is already in 
  tcllib 0.8. Whatever, using LIST is a viable workaround.
  We should be lenient with the server and what is returned 
  by it.


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

  Agreed. filterfor already runs 'expr' internally. Fixed in CVS head.


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

  Synopsis lists commands in the order they are listed in the manpage body. Actually doctools hasn't specified any type of order for the sysnopis ... I.e. this is an undocumented implementation detail ... Fixed order in the body.

  Capitalization ... Apparently most explanations use uppercase tag names. See html::bodyTag, checkbox, checkSet, etc. I guess it is simply a kind of markup. ... Changing to lowercase now, and using 'term' as markup for tags, i.e. relatively general semantics. ... Done.

  openTag ... Worse, the param argument is even optional and not documented as such. It is actually not documented at all. Fixed.

  row ... done.

  Examples ... I haven't written this module and don't really know how to use it, therefore I am not really suited to writing examples.

  I am leaving this report open, with modified summary, unassigned, for whoever is able to provide examples.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I also noticed this.  The explanation for title says: ::html::title title 
  Side effect only. Call this before ::html::head to define the TITLE for a page.

  This is incorrect.  ::html::title is called by ::html::head; calling ::html::title before calling ::html::head would have no effect. Calling ::html::title after callilng ::html::title would change the result of calling ::html::getTitle, but it does not affect the title of the page.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  A couple more clarifications.

  tableFromArray creates a two-column table with a heading that matches the array name, and each row containing a name, value pair. The array names are sorted by lsort before use.

  tableFromList creates a two-column table from a nonempty, with each row containing a label, value pair. 


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  The following procedures exist in html.tcl but are not documented: css, doctype, js, tagParam, urlParent.

  The following procedures are not listed in alphabetical order: init, minorList, paramRow, set.
  This makes their documentation harder to find.


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

  Going through the accumulated comments

  html::title - Are you saying the documentation is wrong, that the behaviour of the package is wrong, or both ? From the description you give it seems to me that the documentation may be right, and actual behaviour wrong. However, not being the author, I am not really sure. Should the behaviour be wrong then this should be submitted as a separate bug.

  TableFromArray/List - I am guessing that you are asking me to extend the documentation for them, based on the described behaviour ?

  Undocumented procedures - I do not know what they do either. Can you draw up some documentation for them for me, and attach to this bug ?

  Sorting minorList, paramRow, etc. - I sorted these yesterday, see my first comment 'Fixed order in the body.'


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  html::title documentation is wrong. It's used inside the package, but having the user call it makes no sense since it's called by html::head where the title is required anyway.

  Yes, I think the real behavior of tableFromArray/List should be documented.

  I can try to infer documentation to the undocumented procedures.

  I wasn't sure if you fixed all the sorting problems.

  I've been thinking of making a different version of this that would allow creation of more than one stack.  I might if I can find the time.


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

  tableFrom{Array,List} documentation extended. html::title documentation disabled (effectively removed from output, still in the .man, as comment). Committed. When documentation for the undocumented commands comes in this bug can be re-opened, or a new bug made.


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

  Yes, I found and fixed that when I wrote the testsuites for 
  pop3 and pop3d and testing them against each other.


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

  Yes, it is. This was a problem in the main Makefile of
  tcllib and has actually been fixed for quite some time in
  the CVS.

  Here's the entry in the changelog

  2002-08-15  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * Makefile.in (DOC_EXP): Use the tclsh found during configuration
    to run mpexpand. This ensures that mpexpand does not pick
    something from the path on its own, possibly something too old
    to understand TCLLIBPATH. Problem noted by Elchonon Edelson
    <edelson@pobox.com>.


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

  Looking at the code for the head, the '1' appears to be the
  correct value, as that will extract, eg, "p:2" and give us
  "2" as the page identifier.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  to see yaml-1.1
  http://yaml.org/spec/1.1/#id928558
  in the Literal Block Scalar, 
  # comment
  lins are ignored.


login: mpr8
username: mpr8
mimetype: text/plain
icomment:
  #-lines that are otherwise treated as comments (i.e. ignored) should not be treated as comments but literal. In your implementation, those lines completely go missing, but shouldn't. That's my point.
  To cite: "The literal style is the simplest, most restricted and most readable scalar style. It is especially suitable for source code or other text containing significant use of indicators, escape sequences and line breaks. In particular, literal content lines may begin with a tab or a “#” character."


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  hmm...

  I find a mistake that should'nt ignore "# comment" just next of "|",
  for example,

  |
    # comment
    literals
    literals
   # ignored as comment

  but other problems has been left there?

  Please show me the complete examples for the specification.


login: mpr8
username: mpr8
mimetype: text/plain
icomment:
  If I understand you right: You think, that lines beginning with # (regardless of indentation level) should be ignored. But that's plain wrong (according to the specification). In your example (that's only readable by e-mail; for other readers: first three content lines are indented by 2 spaces, fourth line is indented by 1 space), the first line prefixed with # is part of the content, the second is of course treated as comment (because it falls out of indentation level). This applies in general to all literal scalar #-lines, regardless where (first line or not) they show up. In my posted real-life complex example (http://yaml.org/ypaste/674/; compare with parse tree to the left) all #-lines are on the same indentation level as all other scalar lines, so they may not be treated as comments, they're part of the scalar content. It would help a lot if you would admit that those lines aren't comments (and start fixing the implementation). ;)

  What do you mean with "Please show me the complete examples for the specification."?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed.
  Listbox deltes the item widget as bwidget (bwidget::delete) but postphones the delete in the canvas to a after idletasks routine.
  An eventual pending resize event may be executed between the two tasks.
  The error may arise due to the half deleted item widget.

  A patch is attached. It consists of a check if the widget (to update) is on the "to-delete" list.
  Alternate solutions:
  - a simple catch -> drawback -> errorInfo pollution
  - a check if the widget was removed (widget::exists path.item

  Patch for listbox.tcl:
  1069,1070c1069,1072
  <         $path.c itemconfigure "n:$item" \
  <             -fill [_getoption $path $item -foreground]
  ---
  >         if {-1 == [lsearch -exact $data(upd,delete) $item]} {
  >             $path.c itemconfigure "n:$item" \
  >                 -fill [_getoption $path $item -foreground]
  >         }


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: 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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Duh - there is a catch but it got disabled during testing
  and left disabled.


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

  OK. It is modified as suggested.

  I will enter it in cvs in a few days I hope.

  Jean-Luc


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227
  Originator: NO

  The math::bigfloat::todouble procedure made use of tcl_precision to compute the number of significant digits.
  It used to be 12 or more in Tcl 8.4, but Tcl 8.5 made it invalid and defaults to 0, which I knew.
  I simply added a test to make use of 16 when tcl_precision is 0, and it will work fine.


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

  Since I can't find a description of what [formatCode]
  is supposed to do or any implementation, I've removed
  it from the docs.

  (html.n: r1.15 -> r1.16)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Fully agreed on both bug and fix.
  The fix is now in the CVS head.
  Package version bumped to 1.3.3.
  Testsuite extended.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  I found a "fix" of sorts. Not a real fix because
  I'm not prepared to explain how/why it works.

  The change is to switch the channel to -buffering line
  and to change -translation {binary crlf} to -translation binary


  Based on
  # RCS: @(#) $Id: pop3.tcl,v 1.25 2003/04/11 20:07:24 
  andreas_kupries Exp $

  Here is the diff
  -------------------------------------------------

  738 C:/p/t/spam> diff pop3-works-under-windows2000-tk.tcl 
  pop3.tcl
  274c274
  <     fconfigure $chan -buffering line  -translation binary
  ---
  >     fconfigure $chan -buffering none
  282c282
  <       # fconfigure $chan -translation {binary crlf}
  ---
  >       fconfigure $chan -translation {binary crlf}

  Makes my issue go away at least for now.


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

  log::log is usually inactive, i.e. not producing output. Setting 
  it a null proc will accomplish nothing with respect to output. 
  It may make the code a bit faster as there won't be any 
  checks for possible logging anymore.

  Please remove your null log::log and then activate logging 
  (Via [log::lvSupressLE critical 0]). That way we can see what 
  is going inside the library and on the wire to the pop server.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  I tried this again with logging as requested by Andreas. The 
  observed behavior was different this time but still always a 
  failure. My stop-gap fix continues to work without any known 
  errors. 
  The failure is an unknown (no error string) error out of 
  pop3::send, which is reported by pop3::top. This results in 
  only the first message top being retrieved by the code.

  In roytest2.tcl see line 586 for the call to top. Again this all 
  works fine (and I use it continously) for days and weeks on 
  end with the patched version.  Seems pretty clear that fiile 
  events are being mismanaged somehow in the standard code 
  such that running in Windows Tk fails.
  Please see attached log/console: roytest2.output.txt
  and roytest2.tcl

  PS: Regarding log enable/enable I have learned through 
  painful experience to be suspicious of performing "console" 
  (and sometimes even file output) during tk event processing.  
  In the past this has lead to some lockups and crashes. That 
  is why I disabled logging. Unfortunately logging in this case 
  really doesn't seem to reveal much but here you have it 
  anyway in the .txt file.

  Thanks,
  Roy Terry

  - more -

  I tried "standard" versions of pop3.tcl 
  < # RCS: @(#) $Id: pop3.tcl,v 1.25 2003/04/11 20:07:24 
  andreas_kupries Exp $
  ---
  > # RCS: @(#) $Id: pop3.tcl,v 1.21 2002/10/14 19:17:23 
  andreas_kupries Exp $
  and they failed identically. 
  The saved output from tkcon is attached. and I 've added a 
  note at the bottom of it.  I've also attached the program files 
  I used to execute the test with my personal server 
  information deleted.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 242204: tsrsplit.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  Attaching a quick hack I made quite some time ago for regular tcltest logfiles, 'tsrsplit.tcl'. That one was for getting expected/is output for use with tkdiff.
  File Added: tsrsplit.tcl


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

  Are there log files generated when I do a normal make test? If so, where? All I was aware of was the "fancy" output that was displayed.

  Would the attached script be appropriate to add in the tcllib distribution?


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

  Attached script in tcllib - not yet. It was a quick hack, not very polished, and only useful in combination with other commands, like tkdiff or eskil, i.e. lots of manual work still. It is semi-related, as it also processes test output.

  log files via 'make test'. The CVS head got some changes to 'make test': 'make test_interactive' -> fancy output, 'make test_batch' -> detailed output. 'make test' now chooses automatically. Fancy normally, and when redirected to a file it does the detailed log.


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: tomk
username: tomk
mimetype: text/plain
icomment:
  That is a really nasty case. Your proposal makes sense in terms of continuing the parse but I'm a little confused by the "Erroring out is undesirable...". It seems to me that you should error out. If the using proc needs to test the html then it can capture the error with a catch and decide what to do.
  tomk


login: dvrsn
username: dvrsn
mimetype: text/plain
icomment:
  There are two reasons why I said error-ing is undesirable.  

  First, because the documentation doesn't suggest that it can throw an error due to badly formed html.  (It raises errors for incomplete html, but that is an intentionally raised error).  If an error like this was detectable and raised as "insane html" or something like that, and this was documented, that might be ok.  Unbalanced braces or incorrect number of arguments gives no clue as to the nature of the error.

  Second, an error being raised in this case would allow partial parsing, but only up to the point of the error.  This malformed html is roughly comparable to line noise, where there's a glitch somewhere in the middle but after that things can continue.  But raising an error doesn't let things continue, even if the caller wanted to do so.  A document can be made completely unparsable by having this malformed string at the beginning.  


login: tomk
username: tomk
mimetype: text/plain
icomment:
  OK, I agree with your comments. After reading the docs for the command it's it looks like your interpretation for the string is the only one that will work with the defined interface. Including a "/" in the tag doesn't make sense because it should be detected and returned as a flag in the callback. Thus, you really only have one chose.


login: dvrsn
username: dvrsn
mimetype: text/plain
icomment:
  The cause behind this bug and duplicate 3504018 is that the trnasformation into a command stream is done by a pair of regexps, and when the param value (i.e., tag attributes) of a null end tag construct looks like html, it gets reparsed by the second regexp, making things break in interesting ways.

  The first regexp handles NET cases, resulting in commands that make it look like a opening tag followed immediately by a closing tag.  It can be changed to actually rewrite those tags to be an opening tag followed by a closing tag, and then have the normal tag regexp reparse it intentionally instead of accidentally.  The effect is the same, but the mechanism prevents already formed commands from being changed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Re: " It can be changed to actually rewrite those tags to be an opening tag followed by a closing tag"

  Do you have a patch for this change, per chance ?


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241931: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241934: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241936: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


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

  This is partially done already. All the manpages in the CVS should by now have a section abouts Bugs, and Feedback, and pointing to the SF Bug tracker for Tcllib.


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

  That's sounds very useful. Adding it to a README in either the top, src, or devdoc directory seems like another useful location.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13555: registry

  Logged In: YES 
  user_id=75003

  Added a file containing some general
  thoughts about such a registry.


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

  1. with regards to the 'suppress the auto-dectection to
  prevent spawning of infinite number of processes' - isn't
  this "just" a simple lock of some sort - perhaps an open
  socket - that gets released at the appropriate times?

  2. what would be the use of comm send without registry?

  3. Re: communicating via an environment variable - how about
  through the Tcl option database or something?  Environment
  variables are nasty as they require user intervention - this
  mechanism to be transparent needs some other method.

  4. It sure would be useful if the resulting mechanism was be
  able to support, when needed, cross-machine comm send - so
  that multi-user internet apps could be built on the
  structure.


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

  Ad 1. The scenario I saw was the startup of the registry 
  immediately upon loading comm. As the registry needs comm 
  itself comm starts the registry before the registry opened 
  its server socket. So comm when loaded by the registry does 
  not find the registry and thus tries to start it again, ad 
  infinitum. With the current model of starting the registry 
  only when it is accessed for the first time this cannot 
  happen as the registry needs comm, but not the part about 
  accessing the registry itself. Reinhard Max's scenario of 
  the first application automatically acting as the registry 
  itself does not have this problem either.

  Ad 2. Applications which are coded to know about each other 
  by some other means. For example an application launching a 
  child and explicitly telling it on the command line where 
  to find the parent.

  Ad 3. What we need for the scenario is some means of 
  automatically sharing this information. I don't believe 
  that the tcl option database can do this. Or do you mean 
  about setting and querying the option database on an X 
  server ? Do we have code to do this ? About the user 
  intervention bit. As this is about an application and its 
  child processes the environment is passed automatically 
  without user intervention. ... Ok, the per-user setup 
  requires work from the user.

  Ad 4. comm itself automatically support cross-machine send, 
  as the hostname is part of the communication handle, and 
  not only the port to talk to. So we only need a way for 
  cross-machine registries. A proxy would be a more safe way 
  IMHO than directly talking to a remote registry. The proxy 
  can for example to encryption without burdening the local 
  applications with this task.

  Reinhard Max proposed that the first application able to 
  open the listening socket should automatically act as the 
  server. If it goes away for wahtever reason one the other 
  applications opens the socket and starts to act as 
  registry, with the other applications reregistering.

  Another proposal of his is to include a notification 
  mechanism so that applications can get events if other 
  applications (de)register. Using that all applications 
  could maintain a local copy of the registry.


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

  Enclosed a file with more thoughts incorporating the
  discussion below.


login: rmax
username: rmax
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=124643

  I'd like to modify my proposal (one of the applications
  becomes the registry server) a little bit. Instead of acting
  itself as registry, an application should start a separate
  registry process in the background, if it won the election.
  This prevents the registry from being blocked by the hosting
  application and reduces the occurrence of new elections and
  re-registration. The registry process should by default exit
  some time (10-60 sec.) after the last app has de-registered.


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

  Added a manpage in doctools format describing a possible 
  API for a registry configuration package. Not for the 
  registry query functionality itself.


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

  While not really automatic the 'nns' module (nano-nameserver) is step towards this.
  zzzzzz


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Its the various set statements. If the given variable exists
  in the global namespace then that is set. Remember that
  namespace name resolution looks at the current namespace and
  the global namespace only.

  The fix is to use variable everywhere -- this passes the
  test suite and doesn't affect existing global variables.


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:
  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: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=13222

  Irrg.

  For the DropSite formating error, search for <b>baseop</i>
  and replace with <b>baseop</b>.

  For the DragSite formating error, search for <b>copy</i> and
  replace with <b>copy</b>


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

  Checking ... not so for Linux. Seems to be windows 
  specific. "file type" code ... That is something we got from 
  Phil Ehrens.


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

  Relevant code section:

      } elseif { $binary && [string match "\x1f\x8b*" $test] } {
          lappend type compressed gzip

      } elseif { $binary && [string match "\x89PNG*" $test] } {
          lappend type graphic png

  It seems that the string match'es fail. (The 'binary' is 
  correctely detected, so the flag $binary is set).

  Reproduced on my Windows 2000 system. IOW, deeper 
  digging can be done locally. ... dump hex of pattern and data


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

  The testsuite creates a number of files which are then tested. 
  The creation step already fails. The bytes 0x89 and 0x8b are 
  both stored as 0x3f. The command used is 'tcltest::makeFile'.

  Now writing the files explicitly, using -encoding binary.
  Now the testsuite works. This is a problem in whatever tcltest 
  you are using. ... Mine is 2.2.2. We have to talk to Don Porter 
  now.


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

  Added a fix to the testsuite which circumvents binary data 
  issues in 'makeFile'.


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

  I do not get these errors when I tested the CVS head on Windows today. I have some other failures for install and relative path computations, but not for file type. Closing.


login: das
username: das
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=90580

  same problem in tklib:

  Index: Makefile.in
  ==================================================
  =================
  RCS file: /cvsroot/tcllib/tklib/Makefile.in,v
  retrieving revision 1.2
  diff -u -r1.2 Makefile.in
  --- Makefile.in 26 Feb 2002 08:04:26 -0000      1.2
  +++ Makefile.in 16 Sep 2002 03:45:26 -0000
  @@ -44,7 +44,7 @@
   
   DESTDIR                =
   
  -pkglibdir      = $(prefix)/lib/@PACKAGE@@VERSION@
  +pkglibdir      = $(libdir)/@PACKAGE@@VERSION@
   
   top_builddir   = .
   


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Please show me the code which cause the problem again.

  I tested yaml/huddle by Tcl-8.4.4(Windows)+dict-8.5.3, and all test are green.


login: al_chou
username: al_chou
mimetype: text/plain
icomment:
  Here's the transcript of my wish session:

  (albertc) 1 % package require yaml
  0.3.3
  (albertc) 2 % set y {bar: 
  >  fruit: apple 
  >  name: steve 
  >  sport: baseball
  > }
  bar: 
   fruit: apple 
   name: steve 
   sport: baseball

  (albertc) 3 % ::yaml::yaml2dict $y
  can't read "data(current)": no such element in array
  (albertc) 4 % puts $tcl_version
  8.4


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  OK.
  I found yaml::data(current) may not be initiailzed.
  Speaking concretely, this problem's arising, when there is not empty line or "---" at the beginning of yaml.


login: jlewandowski
username: jlewandowski
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=790368

  My today work. Problem is in parsepart funkcjon in fragment:
  if {$pos > $last} {
  #error "termination string missing in $state(content)"
  set line "--$boundary--"


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  this was fixed in response to a previous report. remove the
  "#" in the front of "#error".


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

  Fixed in head. Also added code to recognize metakit 
  database, also when attached to a file of a different format.


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

  It seems that bwidgets isn't correctly recreating some hidden 
  widgets that it gets info from.


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

  This is a general design issue of bwidgets, that you cannot
  destroy the windows that it uses that are hidden.  Someone
  will have to revisit this that wants to make bwidgets more
  easily reloadable.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Tim,

  could I just please you not to destroy the internal BWidget widgets.

  Thus modify your deletion loop like that:

  foreach ch [winfo children .] {
      if {![string match ".#BWidget*" $ch]} {
  catch [list destroy $ch]
      }
  }

  Thank you and sorry for the inconvenience.

  Harald


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

  Fixed. Duplicate of [1892687]. Do not try to use a command you have just deleted from the sub interpreter to make it safe.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Fixed in the CVS head now. Although I used 'fconfigure' to make it more explicit that this requires binary settings.

  Regarding 'A Category Is Missing', the category 'jpeg' is quite present.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  allow_comments - 1

  This was handled by having a header added by the website that returns a list of current bridge names. This is requested when you first login and fetches the current tkchat version and the lolcatz message and so on.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I believe this is a 8.3 / 8.4 difference I inadvertently added in 
  there.

  Fast testing. This went in maybe an hour ago :)
  Thanks.


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

  Fix committed to head. Made 8.4 message the message 
  shown, and updated the test suite to use this instead of 
  something dynamically constructed.


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I have downloaded the zip file and I will incorporate the code and 
  the documentation in the math module. This means:
  - Changing the namespace for the package to math::statistics
  - Adding a standard header
  - Transforming the documentation to man page format
  - Using tcltest for the test case(s)


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Thanks! I have one fix to the man page. I realized that I made an incorrect description of what the tstat function does. Sorry about that. The attached man page should be correct.

  File Added: mvlr.man.txt


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

  I have updated the man page and converted the example to a test in accordance
  with tcltest.

  However, I came across two nasty/surprising aspects:

  - The statistics package now depends on the linear algebra package. I had to 
    add the command "useLocal linalg.tcl math::linearalgebra" at the start to 
    avoid set-up errors (still some spurious messages occur).

  - Leaving out the backslashes at the end of the data lines causes an error 
    in mv-wls: it will see but a single data point. This leads me to conclude 
    that the API is not quite appropriate yet: it should be possible to store the 
    data in a list of lists - right now it is more of a string that happens to
    contain some lists.

  We will need to look into this more closely


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Thank you for checking and spotting those problems! I should have mentioned the dependency on the linear algebra package. What is the best thing to do in this case? It will not be easy to recreate the features of the linear algebra package that I need, but I could do it.

  Regarding reading in data files - you're right, it should allow for that. I see that it's not robust enough. I'll work on that.

  Thanks again.


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

  The dependency on math::linearalgebra is not the actual problem: I would rather
  encourage the reuse of this functionality than duplicating it.

  No, the issue is that the test utilities as we use them in Tcllib have to know 
  of this dependency too. That is what I was asking about - it is new to me and it
  was actually very puzzling.

  More important is the issue with the backslashes - I will have a look myself too.


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

  I realised what is going wrong without the backslashes: [eval] will then break up the
  data into separate lines! 

  Hm, perhaps we should use a different API:

     ols $alldata

  and 

     wls $alldata_with_weights

  instead of separate arguments.


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  That sounds right. It also avoids the awkwardness of using "eval" when calling the proc when the argument has been built as a list.


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

  Okay, we'll do it that way - only a very small change required.
  And avoiding eval is - in general - a worthy goal :)


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

  Done.

  The call to the regression routines now take a single argument: a list of data or an alternating list of
  data and weights. This allows us to avoid [eval] and makes the precise formatting of the data much
  less important.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  Feel free to hand off any of these that I have submitted to
  me to close/commit - I have the time at the moment.


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

  Enclosed a patch implementing the feature. Exception: 
  Giving up ownership is not implemented. This would require 
  a complete reworking of how the ftp package operates. It is 
  a big sync. statemachine and cannot give up ownership of a 
  channel because this requires jumping out of the SM. IOW, 
  we would have rewrite the thing to be completely async.

  It might be possible to achieve a similar effect by using 
  special in-memory channels, for example fifo2.


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

  Enclosed a test script for the new functionality. Requires 
  the ftp example "ftpd.test", to be submitted as part of the 
  implementation of this FR.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13552: 481161.diff.2

  Logged In: YES 
  user_id=75003

  Updated the implementation, bugfixes and an specializedftpd 
  for testing.


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

  See http://www.oche.de/~akupries/soft/autodoc/
  for existing app, also http://www.oklin.com/zdoc/.

  Should/could make use of tclpro/tclparser for this to be a 
  robust system (no execution of code!).


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

  Note: For a true tcllib application we need a pure tcl 
  replacement of tclparser. This is heavy weight against
  it.

  See also
  FR [ #520940 ] New application bundle - tcldevapps


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

  I have an almost finished implementation of TIP 40 that just
  does this (well, it uses the conventions from the Style
  Guide by Ray Johnson). It requires some further testing and
  it should use - in my opinion - the doctools format as the
  default (right now it uses the TIP format, but as all is
  done by traversing a tree of the documentation elements that
  should not be too hard). 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7493: 0.diff

  Logged In: YES 
  user_id=75003

  Here is the patch. Moving the line causes my emacs to not
  recognize it anymore, pity. So I see it as better to remove
  it completely.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7494: 1.diff

  Logged In: YES 
  user_id=75003

  Ok, next version of the patch,removing the faulty line in
  md5.n, report.n and struct/matrix.n too.


login: todolson
username: todolson
mimetype: text/plain
icomment:
  File Added - 24471: csv.tcl

  Logged In: YES 
  user_id=450877

  A revised version of cvs.tcl is attached.  Still csv package
  version number 0.2.


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

  There is a bug in split parsing, but it is not in the handling of 
  inner fields. It is the outer fields, i.e. first and last which are 
  off, i.e. wrongly handled.

  The string {"" "" ""} parsed with separator character <space> 
  does not contain three empty fields. It contains 3 fields each 
  of which contains a single ". See the definition of the CSV 
  format. This might be even more clear when parsing {"","",""} 
  using the comma as separator character. An empty field is 
  specified by two adjacent separator characters without any 
  intervening other characters. In the case of <space> this 
  means a space following a space, or a space at beginning 
  and/or end of the string.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 25748: 565051.diff

  Logged In: YES 
  user_id=75003

  Here is a patch for the true problem. Contains an extended 
  testsuite.


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

  Argghhh...I forgot to check the upload box (why does it need
  to be there, anyhow, when you've obviously selected a file?)
  See *next* post.


login: egavilan
username: egavilan
mimetype: text/plain
icomment:
  While I've tried to write 8.4 compatible code, is untested with this Tcl version. The first problem noted: ascii85::checkrange contains a [return -level] command, which is an 8.5 feature.
  Solution is either to remove it, or make the package dependant on 8.5, in which case some code could be simplified using newer features ( unsingned [binary scan]s, "in" operator, etc)


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

  That is actually a feature showing you the "view" window 
  functionality of trees.


login: vwartelle
username: vwartelle
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=157122


  Joined suggested patch for tree.tcl in the "demos"
  directory.

  V.Wartelle.


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

  I guess the behaviour you ask for is
  to set the linked cell in the matrix
  to the empty string, right ?


login: kenj
username: kenj
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=260635

  Yes, I think that would be the correct behavior for it. In the sample 
  application in which I discovered the bug, I had a TkTable widget and a 
  matrix object both linked to the same global array variable. The goal was 
  for changes in one to be propagated to the other. I discovered that when I 
  deleted a row or column from the TkTable, the matrix object didn't pick up 
  the change, even though the global array variable correctly reflected 
  the change.

  Doing a bit of tracing and debugging, I noticed that the 
  MatTraceIn assumes that if it was triggered because of a "u" operation, 
  the entire array variable must have been unset and so it unlinks the matrix 
  object from the array. I believe that an appropriate behavior would be to 
  check if only a single array element was unset, and if so, set the linked 
  cell in the matrix to a null string.

  Based on my (inexpert) analysis of 
  the TkTable's trace output I generated, I believe that this behavior 
  would correctly keep a TkTable widget and matrix object synchronized 
  through the global array. (When deleting rows or columns, the TkTable 
  widget copies the contents of a cell into an adjacent cell, then deletes 
  the contents of the original cell. For the linked array variable, this 
  results in a "w" operation to create a new array element reflecting the 
  copy to the new cell, and a "u" to delete the original cell's array 
  element.)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 20402: 532791a.diff

  Logged In: YES 
  user_id=75003

  Extended patch containing additional test.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is likely not a bug in the docs, but a bug in the
  generation of the usage string.

  Ok, having looked at the output as I have it (CVS Head) I
  see a clear demarkation between the -v and the character
  '1'. Basically the output has two columns. In the first we
  see the option, like "-v", or "-foo value", with the string
  "value" as indicator that the option takes an argument. The
  second column then shows the default value, if there is one.

  I have no problem seeing that -v is a boolean option not
  taking an argument (missing string "value"), and true by
  default. Whereas -foo is an option taking an argument,
  indicated by "value".


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Wolfgang,
  thank you for the bug report.
  I am sorry, IMHO the report is not adequate because it uses the widget not the way it is documented.
  You should use the frame returned by "getframe" to place any childs in.

  Please do:

  set sw [ScrolledWindow .t.s -auto none]
  set cw [$sw getframe]
  text $cw.t -width 10 -height 4

  ---
  Or am I missing something?
  Regards,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks for the patch.
  I applied it now, with changes.

  See branch "apn-dtplite-kwlinks", revision http://core.tcl.tk/tcllib/info/44d847703f
  Please test if my changes still work for you.

  (1) Fixed your bug-fix in "HeaderSetup", added comments explaining the conditions.
  (2) Disabled "IdxWrite" when no keywords were found.
       This means that not only the navbar links are gone, but the essentially empty "index.html" as well.
  (3) Consolidated the check into a proc [HaveKeywords].
  (4) Got rid of the superfluous "kwpresent" flag. We need only "kwid".


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Thanks, will try it out. 

  The reason for the extraneous kwpresent was that with -merge option I was finding kwid always empty. Perhaps I was looking in the wrong spot.

  Will try your changes and let you know.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Just tried it out, with and without keywords, with and without -merge option, and seems to work as desired in all cases. Thanks!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Committed: http://core.tcl.tk/tcllib/info/7593991c41 (Updates to collateral, bumped version to 1.1).
  Merged: http://core.tcl.tk/tcllib/info/c148f532c8
  Pushed.
  Completed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Committed: http://core.tcl.tk/tklib/info/a6173e19d4
  Pushed.
  Bad that this was closed as fixed with the fixes just attached, and not actually committed :(
  See also patch 3607261.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Patch looks ok.
  Would be helpful if a demonstation script would be provided.

  Committed to csv.

  Thank you, Wolfgang !
  Harald


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

  This is definitely a server problem. I have seen that in
  some RISKS digests as amusing examples of bad Y2K patches.

  Yeah, I guess we can accomodate the servers. And also a nice
  log message.


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=456242

  I get the same thing when uing ActiveTcl 8.4.1.0 on a Linux
  (Mandrake 8.2) box. Here the error is 
  Cannot open libmd5crypt.so
  --Jasper


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

  Once upon a time the Trf package included some crypto
  functions. These have since been split off into the Trfcrypt
  package but the md5 function remains in the core Trf but
  depends on something that comes with Trfcrypt.

  The mime package should be modified to cope without Trfcrypt
  in the way it currently handles missing Trf. 

  In fact - better would be to fix mime to use the tcllib md5
  package, and then fix the md5 package to check that the md5
  call actually works. This is a bug for the md5 package too.


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

  I've checked in a small change to use the tcllib md5 package
  if Trf isn't available. The md5 package tries to use Trf and
  then uses a tcl only implementation if Trf isn't available.
  This bug is also present in the tcllib md5 package - but
  we'll handle that to.


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

  IMHO this is not a good idea. The whole point of doctools 
  is to have one "standard" format for manpages. This means 
  that anyone who is writing a new output format knows what 
  to implement. Structure of manpages and their visual 
  appearance is completely separate.

  But with this facility we are going back to the state where 
  each package and manpage defines its own extensions, 
  actually format, and visual appearance, and a writer for a 
  new format does not know what to expect at all.

  Regarding the "dislike of the default of [strong]" ... This 
  is exactly where a new output format comes in. I for 
  example plan to write an "ActiveState HTML" format which 
  renders the manpages so that they fit into the general 
  visual appearance of ActiveState's webpages. Right now I 
  can do this because format is fully specified. If this 
  macro facility is implemented I cannot do this anymore, or 
  rather it is much more difficult, simply because where 
  could be a plethora of macros out there I will know about 
  only if I encounter them, meaning continuous work on 
  updating my format, handling different packages using them 
  same macro name with different meanings, etc.

  I strongly advise against this feature.

  Reassigning to Joe English for a second opinion.


login: boakley
username: boakley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=249075

  I'll admit the "I don't like how [strong] looks..." is a 
  bad example.

  If we think it shouldn't be exposed to the end user, I 
  still think it's a good idea for implementing the 
  individual formats, if for no other reason than to make it 
  so that mpexpand doesn't have to be modified every time 
  someone wants to add a new standard macro. 

  Personally, I still think it should be supported. We should 
  discourage its use in general, but having document-specific 
  macros could be a real time-saver for document authors. We 
  could always make it where a document can't redefine a 
  macro, but can only define new ones, if we're concerned 
  with maintaining the visual appearance.

  One of the goals of the doctools is to make it easy to 
  write standard formats for man pages. For me, the key word 
  here is "easy", and I think being able to create my own 
  macros would make it easier. 

  Perhaps I wouldn't want it so bad if we already had a 
  robust format definition, but we don't. Both times I've 
  tried to use it I've run up against small obstacles in 
  creating a standard man page. The first was the case of how 
  the synopsis was generated, the second in creating a 
  section detailing widget options. I'm sure there will be 
  others until doctools becomes a bit more mature.

  Maybe it would help if we tried converting some of the 
  standard tcl and tk man pages, just to see where some of 
  the holes are in the existing set of macros.


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

  I agree with Andreas -- user-defined macros that expand
  directly to html/nroff/other output notations are not a good
  idea.  You'd have to include a separate implementation for
  all the known output formats, plus all the ones that you
  don't know about yet.  Since the latter is pretty difficult
  :-), I think this is a non-starter.

  However, [proc] *is* a legal doctools command (although this
  isn't documented, I believe it is intententional), so you
  can write your own macros that call other doctools
  routines.  This would take care of things like a copyright
  macro, application-specific table types like "WIDGET
  OPTIONS", et cetera.


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

  Ok, we will not add a generic macro facility to
  doctools.

  We will add some more commands which will bring
  it nearer to TMML, and the rest can be handled
  by [proc]s in the manpage themselves.


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: beric
username: beric
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=493507

  Hello,

  I have done some bug / style fix since I have used it in
  real application.
  Here is the latest version.


login: boakley
username: boakley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=249075

  Yes, I'll try to find time to review it, though it might
  take me a couple days. What sort of review are you looking for ?


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

  How good a fit is this for tklib ? Coding standards ?
  Completeness of the submission (Documentation present ?
  Testsuite present ?). Does the API make sense ? Is that
  something you would find useful for yourself and use as well ?

  A meta-topic to consider: There is not much in tklib yet, so
  anything we add now will at least partially set the tone for
  future packages.

  I placed the burden on you as I am not that much of a Tk
  person, whereas I believe you are such :) I hope that is ok.


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

  There is already a -linestipple for the tree.  Use -linestipple 
  gray50 for that effect.  Or is this something else?


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

  Arjen, how much of this has been done already. I have seen
  the math::optimize, but do not know how much it fulfills
  this request.
  Or if others fulfull it (partially).


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

  All of the above has been done, with the sole exception of 
  cluster analysis. And I should revisit the FFT examples - Lars 
  Hellstrom suggested some much better alternatives.

  I consider it closed


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Applied the patch, extended testsuite. Bumped version to 1.8.2.
  Committed. Pushed. (Fossil repository setup working).


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

  Sending this over to Dr. Vogeler, the creator of the code in
  question.


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

  The above example has been added as a testcase to textutil.
  For tcllib 1.4 the new test does fail. Using tcllib 1.6 the
  test suceeds. IOW the problem has indeed been fixed for
  Tcllib 1.6.


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

  Bryan, please try that again using the newest doctools 
  straight out of CVS. I just tried to reproduce this and 
  failed. The generated HTML contained the single and double 
  backslashes and netscape rendered it correctly.

  get single and double backslashes in the generated html and 
  both my Netscape and IE renders it correctly.


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

  Interesting. From a recent thread on c.l.t the symptoms seem
  to indicate that the smtp server is closing the connection
  on you while you are sending data. It is however unclear to
  me why it should do so if the buffersize is not set. The
  algorithm for that is a bit odd too. The /4*3 magic looks
  like preparation for base64 encoding or similar (3 byte
  binary -> 4 byte printable).

  Marshall ?

  To what type of smtp server are you talking to ? Also, what
  do you see if you use sockspy (http://www.tcl.tk/sockspy) to
  monitor the connection between smtp server and your example
  script ?

  Sorry that this did not get into the 1.6 release.


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

  Had not planned to remove it. Just curiosity. Change applied
  to CVS head.


login: deery
username: deery
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=278157


  P.S. OK... I could have sworn I tested my fix correctly, 
  but Wish now complains about the (obviously) missing curly 
  braces. The workaround should read:

      fconfigure $chan -translation { binary crlf }

  -- AH.


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

  Actually I cannot see a reason for the binary on the input 
  side either. It should be auto. I.e. lenient if the server 
  doesn't do the EOLs correctly. I'll have to query Scott 
  Redman about this, I guess.


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

  Scott's answer is that MS Exchange will not work without 
  the translation binary. Maybe this server expects LF only 
  for commands. Is there a way to identify MS Exchange 
  server, maybe through some string in their greeting ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9182: tcllib.3.diff

  Logged In: YES 
  user_id=75003

  Added a patch to fix this problem and also [443619] and 
  [443645]. The patch also fixes some unreported bugs 
  introduced by the change to a faster RETR: The fast code 
  does not EOL-translation on the incoming data and also does 
  not unstuff .-stuffed lines. Both is done now, courtesy of 
  [string map].

  Side note: Translation "binary" _is_ required, or we will 
  miscount the number of bytes read and try to read more than 
  the server is sending, hanging the command and thus the 
  calling script.


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

  The refresh button got removed. This bug has since been
  dealt with.


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

  I see what you mean and I have implemented this request.

  It would be more helpful to provide a context diff (diff -c)
  and also to  generate your diff the right way round in
  future (diff -c oldfile newfile > patchfile). However, the
  idea is good and is now checked into the CVS tree.


login: gionco
username: gionco
mimetype: text/plain
icomment:
  File Added - 34048: patch_from_1.3

  Logged In: YES 
  user_id=635197

  Ok, here is the context diff, with some other similar
  patches I've
  added in other cases (after HELO, QUIT, etc...)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. Will have to search where the code comes from. 
  "configure" is a generated file.
  Patches to it make no sense because the next time it is generated from configure.in (and tclconfig.m4, etc.) the change will be gone. Will have to grep where the sources for this line are.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was the see method, which showed only the text and not an eventual present icon or window.
  The attached fix resolves the issue.


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

  Added. Incomplete. No testing of 'delete' yet. See pop3 bug 
  about delete. Will be done as part of that item ([501577] 
  Delete reorders requests?)


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

  I'm not sure what the expectations are here.  The widgets do
  expand as the ScrollableFrames expand, but they are
  constrained in that frame.


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

  Quick note that the different log-levels were/are intended to be this type suppression-levels.

  You seem to interpret them more as categories of messages, and wish to have an additional argument denoting what I would call the 'priority' of the message inside of its category.

  Do I understand that right ?

  If yes, then me asking you to look at the 'logger' package (same module of Tcllib) is superfluous, as it has the same type of categorization, and no priorities. What it does have is the ability to create multiple independent loggers (actually a tree), which allows us to give each package its own logger, with independent suppression of categories.

  Interestingly enough, when I worked on the cvs2fossil application (*) I did not use 'log', nor 'logger', but wrote a new system with exactly that kind of priority based system you seem to look for. It had no multiple loggers however, and no categories either. But it also made sure that code in leog messages was executed only if the message was actually to be printed.

  It might be interesting to take this RFE and merge it into logger, to get a system having all of multiple loggers, categories, and priorities.

  I am reassigning to Michael Schlenk, as he is the maintainer of 'logger', as I wish to get his opinion on this as well.


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

  Logger could do such additional suppression levels in a hackish way, by defining subloggers with numerical names, it would just need some syntax sugar to make it nicer.

  Simply changing the signature of the logging function to ${log}::<level> suppLevel msg would have the bad side effect that disabled suppression levels would still eat runtime when disabled.

  Its basically a decision how to setup your logging subsystem, the more simple log package doesn't allow you to create fancy output/suppression schemes, while loggger allows it with some tinkering.

  So yes, i think this RFE is a good idea and could be done with the current logger code with just small compatible changes.

  Michael


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

  I should note that IMHO this type of enhancement may warrant a change of the major version number, and this would allow us to complete redesign the API as we see fit. no hacks would be needed as we would be able to redesign everything from the ground up.

  Of course, if compatible changes allow us to support this we could go that route.

  OTOH, IIRC we have some other RFE for logger currently done hackish, maybe it is time for a redo. I do not remember what this change was/is/might be.


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

  Yes. There are more things in logger that could improve (e.g. the logger proc signature and some others) and a lot of the internals could be done nicer.

  I think it would also be good to unify to just one logging package and not two or even more.


login: mocallins
username: mocallins
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=931198
  Originator: YES

  Yes Andries, for sake of discussion I called them categories, simply because I wanted to refer to the suppression as a "level", but "priority" is just as accurate. 
  I did look at logger and just as you referenced it didn't provide a "priority"/"level" as well.

  Excellent to see that it wasn't just me thinking that we needed some enhancements.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Done. I have split up the code into two procedures (analyse-Kruskal-Wallis and group-rank)
  and added a toplevel one, test-Kruskal-Wallis, to get the same type of interface as the other
  test procedures (namely: a decision result, rather than numerical data)


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Hm. dtplite simply does 'package require doctools' and then assumes that the package management of the Tcl core will be set up to find it. When you installed tcllib into the local directory, was the tclsh you used correctly set up to find packages in that directory ?

  Note, if I add code like 'lappend auto_path ...' to extend the package search from within dtplite, then testing an uninstalled dtplite will be come difficult too ...

  I will have to look where tcllib and dtplite go, i.e. both prefix ? Is exec-prefix involved. If things are simple enough I should be able to write code which properly extends package search for all cases ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 247453: dtplite.autopath.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: dtplite.autopath.tcl


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

  I have now attached a small tcl script, "dtplite.autopath.tcl", which may fix the problem. Its contents have to be inserted after the 'exec tclsh' at the top of dtplite. The code basically computes the location of dtplite itself, then looks into the filesystem for the two places where tcllib modules can be and adds the one it found to the package management.

  It should not only be tested that this fixes the problem, but also that it doesn't break the regular setup, i.e. when installed without a --prefix.


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES


  Small typo. lappend auto_path is missing in the second arm:

      if {[file exists [file join $topdir modules]]} {
          lappend auto_path [file join $topdir modules]
      } elseif {[file exists [file join $topdir lib]]} {
          [file join $topdir lib]
      }


  Anyway, the above prefers the older version of tcllib (1.9 on my machine, distro installed) unless I do this:

      if {[file exists [file join $topdir modules]]} {
          set auto_path [linsert $auto_path 0 [file join $topdir modules]]
      } elseif {[file exists [file join $topdir lib]]} {
          set auto_path [linsert $auto_path 0 [file join $topdir lib]]
      }

  With the above change, dtplite finds and uses the correct version of tcllib when
  installed with --prefix. Without the change, it uses a mish-mash of old and new tcllibs.

  However...

  I'm not sure this is the right fix in the general case. It's not really a question
  of --prefix but --libdir, as that is what is used in the Makefile to install:


      pkglibdir = $(libdir)/@PACKAGE@@VERSION@
      ...
      install-libraries:
          $(TCLSH_PROG) `$(CYGPATH) $(srcdir)/installer.tcl` \
          -pkg-path   $(DESTDIR)$(pkglibdir) ...


  There is not necessarily a direct relationship between libdir and bindir, as both can be set independently on the configure command line. And that means you can't find your way to libdir by starting with [info script].

  For example, I already have tcllib-1.9 installed in /usr/share/tcl8.4 (standard fedora 7 rpm), with dtplite in /usr/bin, and to make sure the above fix works without passing a weird --prefix I wanted to install to /usr/share/tcl8.4, which is in my Tcl's library path.

  The directories tcllib1.10 and tcllib1.9 do not clash, but the dtplite script would overwrite the existing one in /usr/bin. So I used:

    ./configure --bindir=/home/sd/tmp/bin --libdir=/usr/share/tcl8.4

  which doesn't work. dtplite picks up tcllib-1.9.



  So the above fix works for a standard install where tcllib lives somewhere on the Tcl package path. And it works if you install somewhere non-standard by using --prefix at configure time. But it doesn't work if you install somewhere non-standard by using --libdir and/or --bindir/--exec-prefix.

  I think the usual way people handle relocatable autoconf packages is by embedding the paths in the scripts/binaries and/or using -rpath. Not sure if you want to handle that here. 


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

  Oops on the typo, apologies.

  Regarding bindir/libdir/prefix ... That is the part I had not yet looked into. Given your explanations it is now clear that I have to put a placeholder into the code of dtplite, and modify tcllib's installer to replace them with the correct path during installation ...

  That is a pain, because for ActiveTcl (*) I will have to replace the placeholder with a placeholder, or not at all, so that the distribution's installer can do the final replacement :(

  (*) Any other batteries included distribution will have the same problem.

  It is not clear why the linsert works but not the lappend. Package management reads all pkgIndex.tcl files in all paths, and later simply asks for a package satisfying the requested version. Only for packages with multiple implementations but the same version should order become important :(

  Note that 'tcllib 1.9' is not relevant information. The version of the 'doctools' package counts. Which is 1.3 in tcllib 1.10, and was 1.2.1 in tcllib 1.9. dtplite simply asks for doctools, no version, so should get the highest. If that is not the case something else is wrong. Or the tcllib 1.9 you have is from a CVS head and already at v1.3.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  hmmm... when i run your test code, the two lines that are
  printed are the same, so "it works for me".

  what are you getting?

  /mtr


login: giggls
username: giggls
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=293301

  looks like the Problem has gone in tcllib 1.3 so you may
  close this.

  Regards

  Sven


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  it would certainly help matters if you would provide the 
  actual command you're invoking instead of saying 
  everything except that.


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

  Also note that it is better to attach (long) scripts, error 
  traces and log information to a report instead of placing 
  them inline. It allows to write concise report containing 
  references to the supplemented information. This is not 
  only easier to read, the mail sent by SF are also smaller 
  and there not so much scrolling involved to get and the 
  interesting information.


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

  George@Orwellian.Org replies: 

  mtr wrote:
  #  it would certainly help matters if you would provide the 
  #  actual command you're invoking instead of saying 
  #  everything except that.

  The actual command is shown. See "Build_SMTP2=".
  That gets eval'd.

  AK wrote:
  # it is better to attach long...

  The SourceForge form I am using has no "attach" function.


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

  Hm. When I hit "submit new" I come to a form which has the
  following fields near the bottom:

  * A checkbox labeled "Check to upload & attach file",
  * followed by an entry to add the filename (to the right is
  a browse button).
  * followed by an entry to describe the file (labeled "File
  description").

  The same fields are available on the page for an existing
  tracker item.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  When I hit "submit", that's it. It says, "Accepted".

  I'll bet that's the difference between having a login
  on SourceForge versus not.

  Gawd, another username/login. Okay, I've registered.
  When I hit submit, I bet I'll see it this time.


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

  Clarification: I meant the link "submit new", not the button
  "submit". For a new item the fields for attaching data will
  be just above the "submit" button.

  Good luck with your account.


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

  Very likely.
  What version of snit was this ?
  IIRC Will made some changes to the option command and I might use the newer features.


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

  Made the dependency more strict, now requesting snit 1.3 or higher (incl. v2+, if using Tcl 8.5).


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  I think that those test failure is caused not by json module but by dict comparison.

  I might recommend to use proc dictsort2 in yaml.test for the tests.


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: rokar
username: rokar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=612057

  I am really sorry - it really looked like that, but the mail
  client I used did not
  read a 250-.... line and run out of track ....


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Added a patch for comm.tcl which replaces lindex/lreplace with Word0, a procedure emulating the 'lindex <list> 0' behaviour pre Tcl 8. I.e. takes the first word of a list, assuming that this word is well-formed, the remainder of the list does not have to be well-formed.

  Passes comm's testsuite.

  Please check in your environment as well.


mimetype: text/plain
icomment:
  Downloaded and installed the patch and reran the scenario that caused the crash. The patch appears to fix the problem.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks for the feedback, and glad to know that it seems to work in your environment as well.
  I will commit the change ASAP, hopefully today.


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

  Please make it an "update idletasks" as opposed to just plain "update" -- it's safer


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed, but acceptable by design.

  It is better when updates are coded manually than within the BWidget library.
  Nevertheless update is necessary to evaluate the required widget sizes.

  It would be possible to add a hint in the scrollwindow documentation.


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

  This has to do with Widget::focusPrev moving the focus from 
  the .w2.e true entry to .w2 frame, which has -takefocus 
  acceptable on it since it is a megawidget.  That must be 
  improved to check that we aren't just moving from a bwidget 
  child to its megawidget parent container.


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

  If you set
  .w2 configure -takefocus ""
  (instead of the default '-takefocus 1'), then Tk / BWidget's
  standard traversal algorithm does the right thing:
  [tk_focusNext .w1] is .w2.e (instead of .w2), and
  [tk_focusPrev .w2.e] is .w1 (instead of .w2).

  Perhaps the right fix is to make '-takefocus ""' the default
  on the frame widget.  Does that sound reasonable?


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

  No. First it does not work for me. And second, if I use
     $myCombobox configure -takefocus 0
  I would expect, that the widget doesn't take the focus any
  more during keyboard traversal.


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

  Hm.  In what way does it not work?

  Anyway, taking a closer look, this isn't the right solution
  after all.  Widget::focusNext / Widget::focusPrev would work
  correctly if the outer frame had '-takefocus 0' and the
  inner entry widget had '-takefocus 1', but due to some
  BWidget voodoo that I don't quite understand the -takefocus
  option on both widgets are tied together.  Plus -- as Rolf
  mentioned -- from the user's point of view it's preferable
  to set -takefocus on the ComboBox itself, not on one of its
  components.  (BTW, I think [ComboBox .cb -takefocus 0] will
  do the right thing, as will [ComboBox .cb -takefocus ""],
  but [ComboBox .cb -takefocus 1] causes a problem with
  Widget::focusPrev).

  Next possible solution: modify Widget::focusPrev to never
  transfer focus from a descendant to an ancestor.  I think
  this would be the right thing in almost all circumstances 
  -- typically only "leaf" widgets take keyboard focus,
  container widgets do not -- is there a counterexample?

  And an observation: the focus traversal code is deeply
  confusing :-(


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

  Attached patch changes Widget::focusPrev to skip over
  non-leaf widgets.  This makes shift-tab work correctly for
  ComboBoxes and other megawidgets.
  This needs to be reviewed very carefully: I'm not convinced
  that the patched version always terminates (I don't *think*
  an infinite loop is possible, but can't prove it).


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

  I've added a hack that checks that we don't step into the
  immediate parent if it is a proc (like a BWidget megawidget
  would be).

  Joe's idea that -takefocus should optionally allow a widget
  name that you should redirect to sounds very good as a
  better future solution, but would require more careful
  rewriting of -takefocus handling.


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

  This is fixed in the head - leaving it open based on
  alternate idea from Joe.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 34309: latest.diff

  Logged In: YES 
  user_id=240

  The attached patch seems to make the problem go away, but I
  don't know if it really fixes it.  It still passes all the
  tests.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 44163: 14167

  Logged In: YES 
  user_id=240

  Uploading a spam file that triggers the bug.


login: kripke
username: kripke
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=282725

  this properly errors out if you remove the # comment from
  the line
  error "termination string missing ..." (in mime 1.3.2)


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  yes, we should remove the '#' character to get the original
  behavior.


login: zoro2
username: zoro2
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=191529

  Here's my patch to mime.tcl, which seems to handle things
  better than davidw's patch:

  --- mime.tcl.orig       2003-06-11 22:22:18.000000000 +0200
  +++ mime.tcl    2003-06-11 22:24:56.000000000 +0200
  @@ -682,10 +682,11 @@

       set inP 0
       set moreP 1
  +    set retries 0
       while {$moreP} {
           if {$fileP} {
               if {$pos > $last} {
  -        #        error "termination string missing in
  $state(content)"
  +                if {[incr retries]>50} {error "termination
  string missing in $state(content)"}
                    set line "--$boundary--"
               } else {
                 if {[set x [gets $state(fd) line]] < 0} {


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  Reopening because the fix in CVS doesn't seem optimal.

  Further thoughts:

  1) Mime should try and parse even bad data, by default, on the
     principal of "be liberal with what you accept".

  2) Maybe we should have an option to tell it to be strict,
  in which
     case it errors out on bad data?


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  well, the "official practice" when encountering bad mime
  data is to wrap the thing inside an application/octet-stream
  and declare victory. experience shows that any other
  recovery strategy just doesn't work.

  perhaps the thing to do here is to keep the "error ..." and
  put a wrapper around the proc that creates an
  application/octet-stream bodypart.

  /mtr


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  I committed two of the spammy email messages as well as two
  new test cases to CVS, in order to have something to test
  this problem against.


login: eee
username: eee
mimetype: text/plain
icomment:
  This bug is open more than ten years. It need sto be revalidated and either fixed or wontfixed. Poking the priority to fraw attention.


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

  The tests pass on tcl 8.4.0. The first failure is due to the
  new lindex syntax which returns the entire list if the
  second argument doesn't exist. Fixed this (it was a mistake
  anyway).

  The second one I am investigating. Under both 8.3 and 8.4
  the polynomial lookup table is generated correctly but the
  calculation is coming up with the correct numbers under 8.4
  and not under 8.3. I'm investigating this. I presume it's
  some kind of 64bit dependency.


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

  The issue turns out to be this:

  tcl8.4: 
  % format %#x [expr {0x80000000 >> 8}]
  0x800000

  tcl8.3:
  % format %#x [expr {0x80000000 >> 8}]
  0xff800000

  Fixed by masking off the exposed bits.


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

  mime::initialize -canonical text/plain -string message \
   -header [list Content-Disposition "attachment;
  filename=\"qqq\"]
  will do the trick fine.
  I've not found any reference in RFC2046 that excludes
  MIME-Version from the parts. I shall look into Content-ID in
  the main part but I suspect it is permitted (how else might
  one refer to that part if necessary).


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

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

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

  Refering bug to Brett first.


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

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

       --brett


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

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


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

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


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

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

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

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

  Thanks


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

  Sure, no problem at all.

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

  [*] I.e. ssh schwarzkopf@tcllib.sourceforge.net


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 46466: crcbugs.out

  Logged In: YES 
  user_id=15949

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


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

  Larry, your attachment is present.

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

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


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

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

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

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

  Perhaps Trf is already fixing the byte order?


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

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

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

      array get tcl_platform

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

  ==== crcbugs-0.0 FAILED

  modules/crc/sum.test


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


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

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

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


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

  I believe that this bug is fixed in CVS Head and the released 
  Tcllib 1.6. I applied a patch by Gerald Lester and in the q&a 
  about the various part there was one chunk to fix such an 
  error. Please try tcllib 1.6.


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

  I'm fairly sure those are necessary, and their parentage is 
  also necessary due to limitations with how things might 
  otherwise communicate.  As this is really just a problem 
  interactively, the only thing really needed is a better way 
  to filter out that stuff.


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

  In my environemt I get an error message

  % base64::decode ""
  can't read "output": no such variable
  %

  Is that what you mean by crash ?
  If not my next question is: Do you have Trf installed ?


login: chdamm
username: chdamm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=274893

  I also get

  % base64::decode ""
  can't read "output": no such variable

  so that's what I meant by crash.

  I don't have Trf installed.


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

  Ok. I had to ask because ifTrf is installed it used that 
  and so this entry could have been an error in Trf.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This was possibly due to the new dependency of math::statistics on math::linearalgebra. That was fixed in the Tcllib CVS head. Please test if your problems is still present. Platform is solaris ?


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

  This is a problem with BWidget itself and not the ActiveTcl 
  distribution. The procedure is missing in 'color.tcl' as 
  downloaded from SourceForge.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9384: bwidget.449276.diff

  Logged In: YES 
  user_id=75003

  Added patch fixing the problem.


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Another thing to try is the jpeg::exif command in the new
  jpeg module. This is in the CVS head.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Thomas,

  Thank you reporting the bug.

  For me, it does not freeze. It just does not display. But a console window is still responsive. Actually, it is moved out of the screen.
  > winfo geometry .tst
  290x1035+695+-6007

  I will try to fix it.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was, that "winfo reqheight" was used as real height.
  The real height is not jet known, because the window is not jet mapped.
  When mapped, the size is bound on the screen size which highly reduces the height in this case (reqheight was around 16000).

  The estimated value is now bound on the screen size.

  The patch was committed to utils.tcl in cvs.

  Thank you,
  Harald


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  --- ftpd1.2.5/ftpd.tcl(revision 2177)
  +++ ftpd1.2.5/ftpd.tcl(working copy)
  @@ -1301,7 +1301,7 @@
   
       set path [file join $data(cwd) $filename]
   
  -    if {[file exists $path]} {
  +    if {[::ftpd::Fs exists $path]} {
           if {[::ftpd::hasCallback authFileCmd]} {
               set cmd $::ftpd::cfg(authFileCmd)
               lappend cmd $data(user) $path write
  @@ -1358,7 +1358,7 @@
       }
   
   
  -    if {![catch {::ftpd::Fs rename $data(renameFrom) $path} msg]} {
  +    if {![catch {::ftpd::Fs rename $data(renameFrom) $path $sock} msg]} {
           unset data(renameFrom)
       } else {
           unset data(renameFrom)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Fixed in CVS head. Plus a fix in ftpd::fsFile::fs (branch 'rename', sock -> outchan).


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

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


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

  Unfortunately there is more to it than just that - after repairing this and
  a few other bugs I get a division by zero. I will have to check the original
  implementation and add a proper testcase! (Serves me right for not having 
  done that)


login: mezis
username: mezis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=276102
  Originator: NO

  Confirmed.
  The whole eigenvectorsSVD (as well as the rest of the SVD-related code) either doesn't run or produces erratic results.


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

  I know the solution for eigenvectorsSVD - it is much simpler than I thought, 
  but note it is _only_ meant for real symmetric matrices. I have not committed 
  it yet, as I wanted to be sure I understand the solution correctly.

  mezis, can you provide an example where the other SVD-related code does 
  not do its job?


login: mezis
username: mezis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=276102
  Originator: NO

  I finished patching eigenvectorsSVD. I've submitted my patch against 1.10 :
  https://sourceforge.net/tracker/index.php?func=detail&aid=1852519&group_id=12883&atid=312883


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

  Applied the patch, added a simple test case. Increased the version number to 1.0.3
  Thanks again. (Tcllib 1.10 is slightly old though, I had already corrected a
  number of glitches)


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

  Patch committed.

  This report will now change into an RFE. The handling should 
  be moved into the type/instance namespace to allow 
  types/objects in the future to run independent of snit itself.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  As the comment below says, the actual fix for this problem was 
  committed over a year ago; and since then we've made the decision that 
  it's OK for snit types and widgets to depend on Snit run-time code (this 
  was a space issue).  So this RFE is no longer needed.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  it appears mks is writing the very old style tar format. the tar package really only handles the posix ustar format. I will leave this open as a reminder to look at supporting the old format.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Tried v0.5 from CVS as requested.  This change does untar the original test file. However, when the test file has multiple directories there are errors. This seems due to trouble distinguishing between ordinary files and directories as header(type) == 0 even for directories.
  attached is console snap showing one example of error
  also attached is test2-mks.tar which demos the error.
  There is a second look to the error that happens on my large file. I will describe that one if needed.

  BTW, I notice that the -glob option to ::untar does not appear in my ActiveState doc page.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Confirming the "fixed" closed modification now works for my two test cases.

  Thanks very much!

  Roy


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  [14:33]colinaku, reported md5 bug 2906306
  [14:33]colinit's strange because it's happening on *close* not open.
  [14:34]akuFirst, what is underneath the md5 ? Plain Tcl, or one of the accelerators ? (Trf, tcllibc)
  [14:34]colinHow do I find out?
  [14:34]akuinfo loaded tells which shared libs are loaded, that is one indicator
  [14:35]akuThere is also some array in md5 which tells exactly
  [14:35]colin|{/usr/lib/tcl8.6/Mk4tcl/Mk4tcl.so Mk4tcl} {/usr/lib/tdbc1.0b13/libtdbc1.0b13.so Tdbc} {/usr/lib/sqlite3.6.19/libsqlite3.6.19.so Sqlite3}
  [14:35]colinso it would appear to be the plain tcl version
  [14:35]colinshame, I want the accelerated one 
  [14:35]akuOk, no accels loaded, should be the plain Tcl => IIRC this uses a channel internall to process a file => Pat Thoyts has written this code.
  [14:36]colinleave that for another day.
  [14:36]colinok.  patthoyts, seems to be a strange bug in md5.  It would appear that the file has been closed already.
  [14:36]akuI will paste this part of the chat into the bug and then reassign
  [14:36]colinwhen it comes to be closed under ::md5::md5 -file
  [14:36]colinok.


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: wordtech
username: wordtech
mimetype: text/plain
icomment:
  The patch can be tested with this code:

  package require BWidget

  Tree .t
  pack .t

  .t insert end root Foo -text Foo 
  .t insert end root Bar -text Bar
  .t insert end root Baz -text Bas

  bind .t <<TreeSelect>> {puts "foo"}

  The keyboard up-down buttons will print "foo" to standard output. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Kevin,

  thank you for the patch. IMHO this is half-baken. I am not at all familiar to the tree widget, please help.

  The patch proposes to also bind up and down keys to the virtual event <<TreeSelect>>.

  The documentation says: Event <<TreeSelect>> fires if the selection changes. (documentation lacks the trivial fact, that it does not fire if selection changes by the select command).

  The selection does not change by the up-down key bindings. Only the current node changes. In consequence, <<TreeSelect>> is not fired - that is ok.

  There are IMHO multiple alternatives:

  1) Change the way keyboard navigation works:
  - if select mode is single, the keybard navigation will change the selection
  - if select mode is multiple, the space bar should toggle selection and not expand/collapse the tree. Tree expansion/collapse may be done with the +/- keys.

  2) Also fire the event <<TreeSelect>> whenn the current node changes.
  A more careful patch must be created to invoke
      event generate $path <<TreeSelect>>
  within
      proc Tree::_keynav
  each time, the current node changes.

  3) Create new event <<CurrentNode>> which is fired each time the current node changes.
  (similar to 2))

  The effect of the proposed patch may be achieved by two bind commands after widget creation. But key-right and key-left should also be used.

  Please comment.

  Thank you,
  Harald


login: wordtech
username: wordtech
mimetype: text/plain
icomment:
  Revised patch file moves <<TreeSelect>> event firing to keyboard navigation proc (_keynav) and adds right-left arrow. 


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  I think the new patch is ok, except that it misses the first part of the "down" case in the switch statement.

  Harald, I think the Tree widget does not have single/multiple selection modes like the listbox. I found some references to it in the source code, but it seems to be incomplete and there is no API to use it.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you Koen,
  what do you think of using "select" methods inside key navigation instead of the current stuff. Does the current node and selected node make any sense ?

  Thank you,
  Harald


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Harald,
  I don't understand what you mean with "select" methods. Currently, the _keynav procedure contains [selection set] commands. That seems ok to me.
  Looking at the source code, I think the current_node stuff does not make any sense. It tests for [info exists selectTree::selectCursor], which is never set. Even the namespace does not exist. (Unless there is some cleverly obfuscated code where it is set -  I've not tested it.)
  Koen


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: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: NO

  This problem has already been fixed by splitting expose-1.1 in two, 
  with one version for snit1 and one for snit2.  Thanks to whoever fixed it!


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: 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: fvogelnew1
username: fvogelnew1
mimetype: text/plain
icomment:
  I have provided this report AND the bug fix quite some time ago now.

  What does prevent it to be included in the source code?


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  allow_comments - 1

  Applied suggested fix.
  re: your comment - someone needs to notice the bug and do the work. Feel free to become a maintainer.


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: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Committed workaround.  Leaving bug open, because the
  real fix is to stop accessing Tk internals.


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

  I see six places invoking this command. We cannot use 
  [<widget> invoke] as that bypasses even processing. The 
  only way I see to get around using internal is to use 
  [event generate] to explicitly simulate a mouse click.

  Which is a bit ironic because "tkButtonInvoke" was written 
  exactly to simulate a click on the button with the mouse 
  when the button is invoked through the keyboard. It is 
  exactly this for which the command is used here in the 
  example, but we are not allowed to do so as it is declared 
  private.

  Question: Do we have plans to make parts of the ::tk 
  command public ?


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

  increased priority. as 8.4 release approaches this is more
  important.


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: 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: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 10369: lb_patch.txt

  Logged In: YES 
  user_id=98533

  *sigh* I should've learned by now to attach files and not to
  paste. Properly formated code is attached separately.


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:
  allow_comments - 1

  Ditto for the applications 'nns' and 'nnslog'.
  Fix for all committed to head.


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

  What version of the ldap module do you use? (what is returned by package require ldap)


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

  Does it also fail with a more recent ldap version (best use 1.6.8 from cvs if you can, you need an updated asn package too). If you don't know how to check those out from cvs i can send you a small zip file with both packages, just email me...

  The output from the ::errorInfo when the error occurs would also help to pinpoint the problem.

  1.2 is already quite old, and i cannot reproduce the bug it with my local setup and ldap 1.6.8.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted with some changes:
  - New version is 0.8, as this is a new feature, i.e. backward compatible API extension. Not a bugfix.
  - The argument is called 'delMode' instead of 'forceDel'. The original name evokes a boolean flag, which the argument is not.
  - The default value is "auto" for the existing behaviour.
  - The new behaviour is activated for delMode == "always".
  - Added a test case.
  - Because of the use of "ne" ("eq" respectively) version 0.8 requires Tcl 8.4 instead of 8.3.


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  This is and always has been the intent. It just needs developers/testers to do the work or to submit suitable patches.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Sorry, it is bindText, not bindTag:
  - Script -
  pack [ListBox .l -selectmode single]
  .l insert end list:#auto -text 111
  .l insert end list:#auto -text 222
  .l insert end list:#auto -text 333
  .l configure -width 10
  proc p {args} {puts "p $args"}
  .l bindText <Button-1> p
  - End -
  After the binText method invocation, mouse selection will not work any more.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was, that bindText/bindImage mathods interfere with the internal selection bindings.
  The attached patch decouples the bindings.
  The Patch runs against release 1.9.0. The patch of Bug 2995969 is also included.
  It concerns some identical lines and they would be exclusive otherwise.


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  It is not surprising that bindText <Button-1> does not work, since there is already a binding for <Button-1>.
  The normal workaround is to add a "+" to the binding:

  .l bindText <Button-1> +p

  That solves the issue for me.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This belongs to the Tcl core, pretty much. that is which provides 'http'.
  Still, assigned to Pat, as he is the guy handling 'http'.


login: karll
username: karll
mimetype: text/plain
icomment:
  I've uploaded a file that contains a patch to provide the -compress switch for the tcl 8.5 version.


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: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  fixed for 1.4.2 (should be in a minor release, but it's too minor 
  to worry ...).


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

  That fix looked trivial enough to me, so I committed it on
  my own. Also added a test for it to the testsuite.


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: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  tcllib is a tcl script only collection of modules. 

  I suspect what you are after will turn out to require some C bindings to some library.

  I suggest posting a request for someone to write what you are after over on comp.lang.tcl (see google news for one way to access that newsgroup).


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

  I just took a look at the ruby and perl net::ssh modules. Normally you won't see Tcl do a lot of that. It isn't that it isn't possible. Most Tcl programmers don't bother. They prefer to use exec to invoke ssh directly to get done what needs to be done.

  The other thing you will tend to see in the Tcl community is self-motivation. That is to say, needs tend to be met by the people who have the needs. 

  This kind of dove tails with my first point. Since most tcl developers use exec, few have encountered a need for a more direct binding. Things that need a more secure layer between processes use TLS (ie ssl) and things that need functionality of ssh use ssh.

  It's a different cultural outlook - that not everything need be done within the language.

  However, if you have a strong need for it, I am sure that you will find help as you develop the Tcl extension.


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

  There is more than one reason Tcllib does not have an ssh module currently, the most compelling reason: No one has committed code for it yet...

  But for some other reasons:
  1. Expect. Its nearly trivial to automate ssh interactions in Tcl with the Expect package, no need to implement the protocol in Tcl itself and having the maintainence burden.
  2. Speed. A plain Tcl version of a crypt protocol may be doable in reasonable speed with Tcl 8.5s arbitrary length integer support, otherwise it would be really slow.
  3. Other secure IPC. Tcllib has the comm package, which, paired with TLS is quite a good solution for remote access, no need to add ssh to the mix if you control server and client.


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

  In this case, the use of "exec" make it not portable.
  The problem won't be on Linux, but 
  ssh is not an internal command on Win.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  Snit 0.93 has two new commands, snit::typemethod and snit::
  method, that allow typemethods and instance methods to be 
  defined (or redefined) for a previously existing snit::type, snit::
  widget, or snit::widgetadaptor.  These commands can be used in 
  the same source file as the snit::type command, or anywhere 
  else; a snit::type object can even use them to dynamically add 
  new methods to itself.


login: petasis
username: petasis
mimetype: text/plain
icomment:
  File Added - 271523: test.tcl

  Logged In: YES 
  user_id=92283
  Originator: YES

  Please run the test.tcl script, to reproduce the problem. The file abox_graph_struct.txt must exist in the same directory.
  File Added: test.tcl


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

  I can confirm a crash in a tcl_panic in tcllibc.so giving the message 'array index out of bounds'. Is that the crash you are talking about?


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

  Yes, this is the error message I have received. I am sorry I have forgotten to add it to the bug report.


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

  Aha. We have 2795 parallel arcs from node x to node y. Total number of nodes 26. The check I used to filter out duplicate result nodes is wrong, causing the filter to try and stuff all arcs into the result, way over the max of 26, so it it bombs in my assert. Yay defensive asserts otherwise this would have not been that easy to find. ... The filtering for -in is bad in the same manner. Fixing both makes the test script run fine. I am guessing that when I copied things from arc filtering to node filtering the adaption was not done right/fully.

  Ok, making test cases for this is easy.


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

  Fixed in head, with testcases. Reviewed the other filters, and they were ok.


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

  I will fix the code to make sure it is looking at the
  caller's context via [uplevel]. And documentation will state
  this to be the case. This has, at least, been my intent from
  the start (just was not aware that this could be a problem).
  The test cases will need to be adjusted to make sure that
  the lookup occurs as intended.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  File Added - 23868: calculus.tar.gz

  Logged In: YES 
  user_id=400048

  I have updated the documentation, the code and the test
  script to get proper behaviour in different namespaces 


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 24162: calc.patch

  Logged In: YES 
  user_id=80530

  I took the tarball of updated files, made a
  few corrections and created the attached
  patch against the HEAD.


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

  Took the chunk patching calculus.test and applied it. 
  Checked for differences between the whole patch and my 
  patch, applied some other changes in Don's patch.

  Committed to head.


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

  I see, the RE does not handle the user information at all.
  Fixed in CVS Head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9757: 448634.diff

  Logged In: YES 
  user_id=75003

  Updated the patch to fit into the
  recent changes of the pop3 module.


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

  Committed a fix to the CVS head. Package version 0.6.1.


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

  The man page I am seeing says this:
   
  FORMAT
       Each record of a csv file (comma-separated values, as
  exported
       e.g. by Excel) is a set of ASCII values separated by
  ",". For
       other languages it may be ";" however, although this is not
       important for this case (The functions provided here
  allow any
       separator character).
   
       If a value contains itself the separator ",", then it
  (the value)
       is put between "".
   
       If a value contains ", it is replaced by "".
  ---- 

  1. the format is a bit off in the man page - it probably
  should be 
  (the functions ...)
   ^                                                         
              

  2. The "it" in the third point is a bit vague - probably
  should say something
  like "If a value needs to contain the " character, the
  character must be 
  represented as "".
                                                             
             
  2. I don't see anything here that references missing data.
  And that was the
  point of at least 2 or more bug reports.


login: todolson
username: todolson
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=450877

  The package certainly works as advertised.  However, there
  are many applications that generate the ill-defined CSV
  format. The most common CSV files that I see are exported
  from MicroSoft Access, such as what was provided in the
  original bug report. The utility of this package would be
  greatly improved if it could parse files exported from these
  programs. Otherwise, those of us who deal with such data
  have to roll our own CSV parsers, as some of my collegues
  do, or patch every release of tcllib.

  I could easily provide a small number of test files which
  include the awkward cases.


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

  Actually there is a sampledata file in the attached tarball. I 
  am looking into this now.


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

  Committed changes to head. Please test. The testsuite has 
  one of the new cases marked as knownBug. I.e. this code is 
  completely correct, but handles the majority of cases. It 
  dislikes "" inside of a value and handles that incorrectly.


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

  Did a complete rewrite of the parser for the alternate syntax. 
  The one I committed last was a derivate of the original parser 
  and simply could not handle the nested "". The new parser 
  just splits into the primary tokens (", sepchar, remainder) and 
  then converts the token sequence through a tcl-coded DFA 
  (state-machine). This is able to detect an embedded "" 
  sequence correctly.

  Committed now. No known bugs in the extended testsuite. 
  Full pass.


login: eee
username: eee
mimetype: text/plain
icomment:
  The problem here is the handling of invalid data. The email declares itself to have a content type of "text/plain; charset=us-ascii", and a content transfer encoding of "quoted-printable". However, there are FormFeed characters and eight-bit "smart quotes" characters imbedded in both the headers and the body of the message.

  This error occurs at line 1574 of mime.tcl, when mime::getbody tries to decode what it thinks is quoted-printable data read from a file, and it looks like the same would occur at line 1639 if the invalid data were passed to mime::initialize as a string. Hmm, looks like it could be triggered at line 806 too? In all cases, it's calling a command "quoted-printable -mode decode" that appears to be coming from the Trf package.

  I'm really not sure what the correct way to handle something like this should be.


login: eee
username: eee
mimetype: text/plain
icomment:
  The mime module does document the behavior on error, and since the input was invalid and erroneous, the mime module was behaving as documented.

  In the general case, and especially when dealing with hostile input such as arbitrary email, the application needs to account for the possibility that invalid input will cause an error, and the application needs to handle the error in some manner, such as offering the user the raw content of the email.


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: 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!


