# ticketchng

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

  I am a bit confused reading this FR.

  When I read the struct::tree doc, what I see is struct::tree
  creating an option, after which the object token is given
  commands .

  I'd think that what is needed is something like this:

  struct::tree t1
  # code here to set various tree nodes
  struct::tree t2
  t2 setfrom t1
  or perhaps
  t2 copyfrom t1
  or even
  t2 <- t1

  Would not this seem more 'struct::tree' like?


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

  copying functionality has been added to the CVS head: Based 
  on functionality to (de)serialize a tree into a value.

  Note: Due to other changes to the attribute interfaces the 
  version of struct jumped to the next major version, i.e. "2.0".


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

  Ah, I missed that this was not only on the wiki, but also
  submitted here. This was fixed in the CVS head on Sep 26.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  do me a favor: add one more change: if 
  options(-maxsecs)<0, then set secs to 0.

  then go and and generate a new, complete patch.

  thanks,

  /mtr


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  uhhh, the two patches are the same... i think you uploaded the 
  same file twice.


login: tcoram
username: tcoram
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=546883

  I just downloaded both...
  There should be a 1 line difference between the two patches.
  The second patch has an additional line:
  >           -maxsecs    {set maxsecs [expr {$value < 0 ? 0 : $value}]}

  The first patch should be deleted...


login: tcoram
username: tcoram
mimetype: text/plain
icomment:
  File Added - 29099: smtp.diff

  Logged In: YES 
  user_id=546883

  Ugh. The patchwork on this one was definitely confusing.
  Result: A missing line that never made it into the patch.
  Here is a patch for the latest in the CVS tree that adds the
  missing line.


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

  Somehow the patching of the multiple select mode didn't 
  work out correctly.  the 'x' and 'y' values are never set, but 
  they are used.  See tcllib bug 594853.


login: decosterjos
username: decosterjos
mimetype: text/plain
icomment:
  File Added - 30708: listbox.patch

  Logged In: YES 
  user_id=370749

  Hi,

  When the new multiple select command was added to
  listbox.tcl, it got mixed up with the _auto_scroll
  procedure. I uploaded a patch to the latest CVS listbox.tcl
  to separate _multiple_select and _auto_scroll

  Kind regards,

  Jos.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed. Looking at the larger stacktrace this seems to be happening while the string channel is constructed. Looking further I find that the events constructor is not called. It seems that I have to chain them manually with 'next', 'oo' is not doing it for me. This may affect all the classes.

  Continuing...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes, "tcl::chan::memchan" was also affected, as was "tcl::chan::variable". The other classes did the proper chaining. Very likely a copy-pasta error during development.


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

  The hostname display part of this patch has already been
  applied to the source code in handling your previous patch.

  The new part - changing the DATA handling - is not permitted
  by the SMTP RFC given our current implementation. Section
  2.3.7 explicitly states that lines end with CRLF (or "\r\n"
  in Tcl terms). This includes the DATA section if no
  extensions are enables.

  The current implementation only supports the miminal SMTP
  protocol.  In particular we do no implement the 8BITMIME
  extension which is what I think you are really asking for here.

  I stongly suspect that outlook is ignoring our non-support
  and using 8 bit mime anyway.

  I'm looking into this - we certainly should be able to
  support this but I am not certain that this is the correct
  way to do this.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 15770: crc32.tcl

  Logged In: YES 
  user_id=202636

  I've optimised the code a bit so here is a faster version.


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

  Also - I have contacted the original author and he is
  agreeable to our including this code within tcllib.


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

  Ok, while I have no access to a Linux/Alpha box a Solaris
  box is at hand.


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

  Hm. I am on a solaris 2.6 box, and cannot repro these
  failures. The testsuite runs fine.


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


  The use of [file join . / *]
  in these tests is suspect.
  Perhaps it's combining with
  [glob] and [file] bugs here?

  What's intended by these tests?


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

  The glob outout (.//foo) certainly looks broken. If this is
  the expected output and the intentation of thests. I don't
  know. They test the 'fileutil::install' command ... Written
  by David Welton in 2003. So he should be able to get us
  better answers. He is 'davidw' here, we could reassign this
  to him.


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


  ok, at least one relevant issue
  is a [glob] bug fix apparently
  not backported to 8.4.

  % info patch
  8.5a5
  % glob *
  foo
  % glob -dir . /foo
  ./foo


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

  Heh. I just ran into these test failures again, I think. Ok on Linux, failed on Windows.
  Will try to understand what is done and wanted.


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

  The application has been written and committed to the head.
  No default makefile target yet.


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


  the dtplite application is installed by tcllib 1.7,
  so this can be closed.

  the remaining request - that TEA provide
  an example target rule in its Makefile,
  is better tracked in the TEA/sampleextension
  tracker.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 11352: 465210.diff

  Logged In: YES 
  user_id=75003

  Enclosed the patch containing the full fix.


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

  Under OS X 10.4.7, /usr/bin/wish8.4 does not appear to hang
  on the BWidget demo.  I could not get the lock up with
  fink's /sw/bin/wish either.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Test by Kevin:
  "I can't reproduce the bug--it was filed against 1.7 and I'm using 1.8. I'd close it as out of date"


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

  Reopening; patch 621331 didn't fully fix the problem.  
  Deleting an ancestor of a selected node still fails:

  package require BWidget 
  pack [Tree .t]
  .t insert end root foo -text Foo
  .t insert end foo bar -text bar
  .t selection set bar
  .t delete foo

  ==> ".t selection set: Cannot select unknown node "bar"."


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

  Looks like this problem was introduced in revision 1.36
  (related to Bug #547245?); "selection set" and other
  commands that modified the selection formerly ignored
  nonexistent nodes, now they raise an error.  But [delete]
  (perhaps inadvertently) relied on the old behaviour.


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

  Attached patch should fix the problem.  
  Fix: remove deleted nodes from the selection in
  Tree::_subdelete instead of Tree::delete.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Done with commit [6a75d04948].

  html bumped to version 1.5. (EF)

  See also ticket [1146362fff], and [a4680273cf].


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

  Does the same thing happen in the "counter" module ?
  (One of the two modules supercedes the other, the other
  is deprecated. Brent knows which is which).


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

  Note: stats is definitely deprecated. Please try the 
  counter module and see if it contains the same problem.


login: twylite
username: twylite
mimetype: text/plain
icomment:
  Upped the priority -- the implementation currently does not pass the NIST test suite for the AES algorithm.


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

  How does MSIE react to the use of the "title" attribute,
  instead of "alt" ?


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  no idea, but the W3 docs say that's how to set the data for
  such a thing. 'alt' is for display in text-only browsers and
  is not documented to carry the data a tooltip might want. 
  Whereas 'title' is documented to carry such info.


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  just search for 'alt=' and replace it with 'title='

  There's only one in modules/counter/counter.tcl


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  http://www.htmlhelp.org/reference/html40/special/img.html:
  "
  The required ALT attribute provides alternate text for those
  not loading images.
  "

  http://www.htmlhelp.org/reference/html40/attrs.html:
  "
  The TITLE attribute provides a title for an element and is
  commonly implemented as a "tooltip" on visual browsers
  "

  I had always thought alt was for a tooltip since the days of
  IE4, just cause I was used to it..  I had never known it was
  wrong until I started using firefox.

  Some recomendations have said to use both alt and title
  until M$ fixes IE to conform to the W3 standard of HTML
  4.01.  I read that on the firefox FAQ sometime ago.


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

  Yes, the first item seems generally known as a splash
  window. The second item might be called a slideshow window
  (that was my motivation for it, at least)


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

  Questions I believe should be answered in the documentation.

  When executing "smtpd::stop", what happens to existing 
  connections ? Are they closed forcibly, or keep on running, 
  or ... ?

  When any of the callbacks throws an error, is that error 
  message delivered to the SMTP client or is that purely 
  internal, for example logging ?

  When are the callbacks called ? Deliver is clear, but are 
  validate host/sender/recipients called them moment when 
  this information is available, or only when all of the 
  infomration was gathered ? Can we assume a specific order 
  for the callbacks ? Can the deliver callback deny message 
  transport by throwing an error ?

  ----

  Notes for future development.

  *   We should extend this module to allow several
      independent servers running on different ports.

  *   Another place for validation might be after all
      mail headers in the message are read. For example
      missing To:/From:, whatever ...


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

  I'll deal with the documentation issues.

  >*   We should extend this module to allow several
  >    independent servers running on different ports.

  I guess so.

  >*   Another place for validation might be after all
  >    mail headers in the message are read. For example
  >    missing To:/From:, whatever ..

  The RFC says that a mail transfer is complete once the DATA
  command has been completed (ie: once we receive the final
  '.' on its own. Issuing a DATA without having previously
  issued both MAIL and RCPT commands is an error and the
  client is sent 503 Bad sequence. I should be noted that SMTP
  connections are stateful so the following sequence is permitted:
  HELO bogus
  MAIL From: me
  RCPT To: aku
  DATA
  mail
  .
  DATA
  more
  .

  Sending two messages to 'aku'. RSET is used to reset the
  state (ie: forget any sender/recpient addresses.)

  I'll add the above to the documentation too then :)


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

  added to 1.4.0cvs.  Note that this would have worked 
  already using the 2 item list "F1 F1".


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: droll
username: droll
mimetype: text/plain
icomment:
  allow_comments - 1

  This has been fixed in TEPAM 0.4.1 that has been commited on March, 25th, 2013.


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

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

  Committed fix to both 1-6 branch and Head.


login: 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: takatsuki
username: takatsuki
mimetype: text/plain
icomment:
  Sorry, I just found a copy-paste error in my patch. In:

  proc ListBox::_init_drag_cmd { path X Y top } {
   set path [winfo parent $path]
    set ltags [$path.c gettags current]
   set item [lindex $ltags 0]
   if { [string equal $item "item"] ||
      [string equal $item "img"] ||
      [string equal $item "win"] } {
          set item [ListBox::_get_node_name $path $id]

  $id is not defined, it should be 

  set item [ListBox::_get_node_name $path]

  Or 

  set item [ListBox::_get_node_name $path current]

  Sorry for that.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  I am sorry, I have tested the package 2.0 with Tcl HEAD
  (updated and recompiled today) Windows XP (32-bit), and
  there is no problem - the test suite runs with no error.

  I guess the bug is somewhere in 64-bit integers handling,
  and/or even bignums.
  Maybe others areas of tcllib are impacted, this may be a
  problem related to the core, and which does not happen on
  32-bt systems.

  I feel sorry for you, but I'd only seek for a solution if I
  have a 64-bit system under my (dirty :^) hands...


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


  Selecting bigfloat-int2float-2.9.2.3
  for more analysis, on 32-bit system
  I see:

  % int2float [fromstr 5000000000] 5
  F 21474836480000000000 -32 42951

  On 64-bit I see:

  % int2float [fromstr 5000000000] 5
  F -125100849711610 -32 42951


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

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


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

  Accepted. Minor code touchups (unbraced expressions 
  reported by frink).


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10222: namespace.cdiff

  Logged In: YES 
  user_id=81875

  Hmm ... this has happened second time that no patch file was
  uploaded. I guess it has to do with some bug in netscape
  browser.
  Hopefully it will upload this time.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10224: namespace.cdiff

  Logged In: YES 
  user_id=81875

  I just realized that my earlier patch had some unwanted
  changes for profiler.n file. So, I am re-submitting the
  patch after deleting that part.


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

  Looks good to me too, but I'm gonna leave acceptance up
  to each maintainer.  Assigning to the first package.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Deleted - 10222: 

  Logged In: YES 
  user_id=75003

  We currently have here no exact maintainer structure as the 
  one for Tcl itself. Taking the item.


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

  Comitted testsuites for the supporting packages (user 
  database (udb), mailboxes in directory (dbox))


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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report.

  I have simplified your demo script using a canvas showing only one box (and not the dot graph) and checked it using windows and linux.

  Unfortunately, there was no unexpected behaviour when zooming in or out (bind buttons or maximize function).

  Chould you please:
  - verify, if the attached script shows the issue for you (eventually change the size of the box)
  - Post your platform and display details (resolution, main window size)

  Best regards,
  Harald

  -Example script-
  lappend auto_path .
  package require BWidget

  set sw [ScrolledWindow .sw]
  set cvs [canvas .sw.cvs]
  $sw setwidget $cvs
  pack $sw -side top -fill both -expand yes
  bind $cvs <Button-1> "zoom $cvs 1.1"
  bind $cvs <Button-2> "zoom $cvs 0.9"
  $cvs create rect 0 0 500 500 -fill red
  $cvs configure -scrollregion [$cvs bbox all]

  proc zoom {cvs factor} {
  $cvs scale all 0 0 $factor $factor
  $cvs configure -scrollregion [$cvs bbox all]
  }
  -EOF-


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Put to pending state. It works for me. Please inform if there is still an issue. Note that the used ScrolledWindow got improved in cvs.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Private E-Mail resulted in the test script:

  set sw [ScrolledWindow .sw]
  set cvs [canvas .sw.cvs]
  $sw setwidget $cvs
  pack $sw -side top -fill both -expand yes
  bind $cvs <Button-1> "zoom $cvs 1.1"
  bind $cvs <Button-2> "zoom $cvs 0.9"
  $cvs create rect 0 0 416 283 -fill red
  $cvs configure -scrollregion [$cvs bbox all]

  proc zoom {cvs factor} {
  $cvs scale all 0 0 $factor $factor
  $cvs configure -scrollregion [$cvs bbox all]
  }

  I got the endless loop when I press zoom, zoom, unzoom, zoom on Linux, not Windows.
  The issue arised, because the window size was changed when the scrollbars were mapped.

  The issue is solved by a more severe locking.

  Please report, if this works or if it raises other issues.


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

  Marshall, any info you can give us here to add to the
  documentation ?


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

  set part_a [mime::initialize -canonical text/plain -filename
  body.txt]
  set part_b [mime::initialize -canonical image/jpeg -filename
  image.jpg \
    -header [list Content-Disposition inline] \
    -param [list filename image.jpg] -param [list name "Image
  of thingy"]
  set mime [mime::initialize -canonical multipart/mixed -parts
  [list $part_a $part_b]]


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

  doesnt return the "anonymous" names

  proc ::ncgi::names {} {
      set query [query]
      set type  [type]
      switch -glob -- $type {
  "" -
  application/x-www-form-urlencoded -
  application/x-www-urlencoded {
      set result {}
      foreach {x} [split $query &] {
  if {[regexp -- (.*)= $x dummy varname]} {
      lappend result [decode $varname]
  }
      }
      return $result
  }
  multipart/* {
      return [multipart $type $query]
  }
  default {
      return -code error "Unknown Content-Type: $type"
  }
      }
  }


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

  Two notes:

  1. 'nvlist' uses 
      split [string trim $query], and not
      split $query. I believe nvlist is more correct.

  2. nvlist also uses 'multipart' for the multipart. This
  means that for multipar data 'names' delivers names and
  values, and not the names alone. This is a bug in the
  proposed code.


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

  try #2, in the same style as ::ncgi::parse. you could also
  get the same list by calling parse and then [array names
  ::ncgi::value]

  proc ::ncgi::names {} {
      set names {}
      foreach {name val} [nvlist] {
          if {$name != "anonymous"} {
              set names($name) 1
          }
      }
      return [array names names]
  }


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

  Added to head, with a small fix. "set names {}" should have
  been "array set names {}".


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1463011
  Originator: YES

  Actually using it in http://wiki.tcl.tk/16631 suggest that for the asnTLV proc the following semantics are more useful:

       proc asnGetTLV { data_var tlv_var } {
   # gets a tag/length/value from the start of the data.
   # return false if no data available, true if succesful
    upvar $data_var data $tlv_var tlv
    dputs "Getting the first element from: [util::string2hex $data]"
  if {[string length $data] < 2} {
      return false
  }
    asnGetByte data tag
    asnGetLength data length
    asnGetBytes data $length temp
  set tlv [asnTLV $tag $temp]
  return true
  }


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

  Which exact version of 8.5 are we talking about here ? There are a lot of alphas. I think I am using a3 or a4 at home and do not see errors.


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

  Sorry, SF doesn't like the logfile, stupid thing..., mail me if you want it.

  Tcl 8.5a6 from todays CVS head.


  schlenk@chronos:~/devel/tcl/build2> tclsh8.5
  % info patchlevel
  8.5a6
  % parray tcl_platform
  tcl_platform(byteOrder)   = littleEndian
  tcl_platform(machine)     = x86_64
  tcl_platform(os)          = Linux
  tcl_platform(osVersion)   = 2.6.16.21-0.13-smp
  tcl_platform(platform)    = unix
  tcl_platform(pointerSize) = 8
  tcl_platform(threaded)    = 1
  tcl_platform(user)        = schlenk
  tcl_platform(wordSize)    = 8

  All errors look like this:
  ==== graph-critcl-critcl-graph-keys-1.1 graph keys, wrong # args, too many FAILED
  ==== Contents of test case:

  SETUP
  catch {CMD keys a b c} msg
  mygraph destroy
  set msg
      
  ---- Result was:
  wrong # args: should be "CMD keys ?pattern?"
  ---- Result should have been (exact matching):
  wrong # args: should be "mygraph keys ?pattern?"


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

  No need for the logfile. Knowing which alpha to look at is good enough. I can now create my own build to repro.
  I think I already know what is happening. Later 8.5 alphas changed the error messages when aliases are involved,
  to deliver the alias name (CMD), and not the command the alias resolves to (mygraph).

  I either get the testsuite to work without using an alias, or have modify the code generating the expected error messages. The latter shuld not be to hard. I am keeping the priority low, I am not sure if I should track this moving target ... I might the fix conditional on the exact patchlevel of 8.5.


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

  Fixed as per dgp's suggestion to insert a check into the
  pkgIndex.tcl file.


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

  I see the index script fix.  

  Now add a

      package require Tcl 8.3

  to irc.tcl to complete the fix.


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

  That will be because the crc16 module has only been added to
  the library after version 1.3 was released. It'll be in 1.4.


login: vincentdarley
username: vincentdarley
mimetype: text/plain
icomment:
  File Added - 55455: notebook.diff

  Logged In: YES 
  user_id=32170

  Attached a patch to fix this and one other problem (the use 
  of 'lsearch' instead of 'lsearch -exact' on page names).


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

  I do not have an issue creating this page with the CVS head 
  of bwidget:

  (tkcon) 50 % package require BWidget
  1.6
  (tkcon) 51 % NoteBook .nb
  .nb
  (tkcon) 52 % .nb insert end {C:\foo\bar} -text {C:\bar\foo}
  .nb.fC:\foo\bar
  (tkcon) 53 % pack .nb -fill both -expan 1

  I think the lsearch -exact fixes should go in.  There may be 
  one or two more 'eval's that could be better protected, but I 
  don't find fault with the current stuff.  That was with 
  AT8.4.3+ on Win2K.


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

  Seems like freenode changed something so the host field stopped working. Added this in now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Can you please test this against older versions of the Tcl core (8.5, 8.4) and/or on other platforms ?

  I am asking because when I tried to reproduce the problem, using Tcl 8.4.15 and 8.5.3, both on Linux, I do not have any trouble. I used fileutil 1.13.6 (CVS Head). The only difference to 1.13.5 is the fix to make stripPath case-insensitive on Windows.

  I have a feeling that this is exposing a bug in the handling of paths by the Tcl core.

  My session logs

  andreask@gila:~/workbench/u/tcllib/modules/fileutil> tclsh
  % source fileutil.tcl
  % package provide fileutil
  1.13.6
  % info patchlevel
  8.4.15
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  %

  andreask@gila:~/workbench/u/tcllib/modules/fileutil> ~/Abuild/bin/tclsh8.5
  % source fileutil.tcl
  % package provide fileutil
  1.13.6
  % info patchlevel
  8.5.3
  %  fileutil::jail /temp /a
  /temp/a
  %  fileutil::jail /temp /a
  /temp/a
  %  fileutil::jail /temp /a
  /temp/a
  %


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Looks like you might be right.  filutil 1.13.4 on Tcl 8.4.19 does not exhibit this behaviour. fileutil 1.13.5 on Tcl 8.6b1 does. Both on XP SP2. I'll load the same tcllib on the 8.4 installation and try it there. That should confirm it.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  I just verified that Tcl 8.4.19 does not exhibit this bug using the same fileutil version (1.13.5) that was being used with Tcl 8.6b1. So it does appear something has changed in the core.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  I've added a bug for this to the Tcl SF bugtracker - 2571597

  (woof) 1 % file pathtype /a
  volumerelative
  (woof) 2 % file normalize /a
  C:/a
  (woof) 3 % file pathtype /a
  relative

  /Ashok


login: jvellamgc
username: jvellamgc
mimetype: text/plain
icomment:
  This is extremely easy to recreate, and is (sadly) very damaging and difficult to debug when it does clobber global variables. Here's all I did, using just plain tclsh and sourcing in the latest version 1.15 of the ini.tcl file:

  % source ini.tcl 
  % set key xxx
  xxx
  % ini::open /tmp/xxx
  ini0
  % set key
  can't read "key": no such variable

  As you can see the code has unset the global "key" variable. This obviously isn't the intent of the code in ini.tcl. There are several places where the code needs to be cleaned up to avoid this problem; specifically, take a look at the "commit" and "_loadfile" code.

  I hope this is helpful. I can tell you this bug impacted our product in a way that was difficult to diagnose, so I really hope it can be fixed in the short term.


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

  Fix committed to cvs head. Version bumped to 0.2.4.

  Reworked the internals more generally to use 'variable' to bring object state into scope instead of playing with 'namespace eval'. That way the local variables are indeed procedure local and not escaping to global scope through the 'creative writing issue' of variable resolution.


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

  Its probably not a good idea to mask an error (and feeding junk into the decoder is clearly an error) by simply returning an empty string.  


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

  You have [catch] for dealing with errors raised. Garbage in should be considered an error. 


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

  Side note regarding Ns_Sls.html ... "Ns_Sls} - Socket local storage" shows me that there is a closing brace to many somewhere in the documentation sources.

  Regarding parentheses and argument types: When doctools was written it was with the intent of documenting Tcl commands. C functions were not on my mind and so are not really supported. You can document them, but a number of things have to be done manually, like adding parentheses around the whole set of arguments to a function, and adding type names to arguments. We currently do not have any markup commands to highlight types.

  Would you be willing to write up a concrete proposal of the extensions (= markup command) needed for clean support on C functions ?


  Regarding "How do do you ... arrange", that is completely out of the scope of doctools. It is intended for the conversion of the manpages to HTML, nroff, and the like, however it has no truck with installing the results. That is left to the Makefile (or equivalent buildsystem) of the package being documented.


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


  Regarding command/function aliases, this seems part of what building a set of man pages is about. Ideally I would point doctools at a directory full of *.man sources and it would output the nroff (as it does now). But also, it would recognise that Ns_Sls.man actually documents half a dozen related functions and would create sym-links: Ns_SlsAlloc.man -> Ns_Sls.man etc. This allows a user to type 'man Ns_SlsAlloc' and have the right man page appear.

  I think you need the database of which commands are documented on which pages anyway, for the cross referencing to work.


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


  With your feedback, I took another go at it and it's looking a lot better:

    http://naviserver.sourceforge.net/3/naviserver/files/Ns_Sls.html


  That's completely not the mental model I had of how the macros worked.

    [call [fun Ns_SlsAlloc]([type Ns_Sls] *[arg sls], [type Ns_Callback] *[arg cleanup])]

  After marking up Tcl commands, I imagined each arg to 'call' was a significant element: func name, arg, option, type, etc. But it's actually just a blob of text..(?).

  The documentation for doctools doesn't really help. There are no examples. It doesn't tell you when or why you might use a particular macro. It doesn't tell you which macros go together.


  How do I handle return values? Do I just add type and arg in front of fun?


  (I haven't got as far as structures and other types yet. I'll have to think about it...)


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

  The extra label options were dropped from the combobox and
  other widgets.  Place it in a LabelFrame.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The attached patch uses ButtonRelease instead Button events for multiple select.
  This avoids the issue with multiple drag and drop.

  The patch was tested by Robert Karen.

  I have the feeling, that there might be other side effects.

  I am planning to make multiple drag and drop in the same widget possible.
  Maybee, someone might help me ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Just uploaded listbox-1.9.0.patch2 with the following properties:
  1) use buttonRelease instead Button events for multiple selection
  2) drag and drop default function now allows to drag multiple items within one widget.

  2) might be relatively weired, because there are so many cases and not all may make everybody happy:
  - if current object is not in selection, this object is dragged
  - if current object is in selection, the whole selection is dragged

  Possible enhancement: select dragged object, if it is not the selection.


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

  I am not able to confirm that. With the patch applied the testcase mime-3.7 in mime.test hangs and strategic output reveals that it is stuck in the infinite loop you wish to avoid.

  What operating system are you on ?
  Maybe that makes the difference between your non-loop and my oo-loop.
  I tried this on Linux.


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

  Meh. Retracting my statement. The mime-3.7 test case is bad in itself. mime-3.8 is a testcase for the same problem and doesn't run into the infinite loop with patch applied. In mime-3.7 the 'badmail1.txt' the given boundary is the terminating boundary, however it is not recognized because the parser newer saw an initial boundary. The patch now faking a terminating boundary cannot help there, its fake boundary will not be recognized either, hence the infinite loop.

  I think I may try to fake a bit more, i.e. set inP as if we had seen an initial boundary.


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

  The 'meaningful' variable 'x' comes from (IIRC), i.e. blame me. Should be 'linelength' or some such.

  2007-11-05  Andreas Kupries  <andreask@activestate.com>

  * mime.tcl (::mime::parsepart): Fixed [SF Tcllib Bug 1825092],
  * mime.test: as reported by Max Strobel
  * pkgIndex.tcl: <mstrhh@users.sourceforge.net>. The code parsing
  * mime.man: multiparts assumed that eol sequences are always two
    characters (cr+lf), this however may not be the case. This
    caused the parser to miscount the last line in a part and
    wrongly remove its last character from the part. Extended the
    testsuite, and bumped the version to 1.5.3.

  Attaching the patch I have sitting in my sandbox. I am not fully satisfied with it. While it avoids the loop some of the commentary in 631314 seems to indicate that I should also munge the mime-type of the new part, i.e. force application/octet-stream, whatever the headers claimed for it.

  The necessary updates to the testsuite are missing as well, however that it is more or less a formality.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 277826: mime-1961881-a.patch

  Logged In: YES 
  user_id=75003
  Originator: NO

  Updated the patch in my sandbox.
  Moved handling of missing starting boundary around.
  Added forcing to app/octstream and handled possibility that part is broken beyond parsability.

  File Added: mime-1961881-a.patch


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

  Accepted my updated patch. CVS head is now mime 1.5.4.


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

  Jeff, could you also take a look at #720032 and the proposed
  fix?  I think that might apply here too.


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

  While related, the other one is a bit more wide-sweeping, 
  while this was a 1-line fix.


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

  I added an improved version that allows control of the fading and better handles the redisplay case.  In tooltip 1.4.


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

  So the Windows and Solaris ftp server generate different
  outputs in response to the request, right ?

  Please try to capture the commands sent by the package, and
  responses received, and attach the resulting log to this report.

  Note: We recently fixed a problem in NLIst regarding the
  handling of 'spaces' in filenames. Could this be a similar
  problem ?

  I.e. not a true difference between the windows/solaris
  servers, just filenames with spaces in them returneed by the
  windows server ? This can be tested by creating some files
  with spaces in their name on solaris and making sure that
  the solaris server sees them ... I think.


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

  I do not think it has anything todo with the 'spaces' problem.

  I noticed in the output that the return-code with the ftp
  list command was 
  226 on solaris - Closing data connection. Requested file
  action successful (file transfer, abort, etc.).

  550 on IIS - Requested action not taken. File unavailable
  (e.g., file not found, no access).

  Thanks for the effort!


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

  Uh. In other words, the windows server sends a failure
  status code when you try to list non-existing files, whereas
  the solaris server is happy to report that it is happy, the
  list of matching files is simply empty.

  And the ftp package in turn is not happy with the failure
  status reported by windows. :(

  I had hoped it was something quickly fixed for the release.
  Now I am not sure. Ok, no fix for this release.


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

  Do you have small examples which demonstrate the bad
  behaviour ? They would also become test cases.


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

  Mostly accepted. The changes to mapEscapes are outdated,
  this was fixed in a different way, by an additional quoting
  step protecting Tcl's special characters.

  Reordering advice taken.

  Examples are in the testsuite, actually. The relevant
  testcases have been updated.


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

  Accepted. Patch applied and example added. The example 
  was not added in the proposed place, but 
  tcllib/example/mime/, which is the canonical location.


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

  Thanks that you haven't forget to raise package version when
  fixed this bug. Now I can package require asn 0.4.1 and be
  sure that my code would throw an error rather than silently
  produce incorrect data.

  Happy New Year


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

  for the missing variable the code would seem to preclude this error:

      variable RES
      set file [file normalize $file]
      FindResources $file
      if {![info exists RES($file,group,$name,members)]} { return -code error "no icon \"$name\"" }


  for the 3 element list or vista icon please reopen this bug or a new one and attach files which demonstrate the problems. this bug was submitted anonymously so I have no one to contact for more information. thanks


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

  I have implemented a first version - it can do only one 
  series of data per histogram, but that ought to be enough.

  I have ideas on how to extend it: stacking the bar on top of
  each other. Other options: cumulative plots in stead of each
  bar on its own... Just let me know.


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

  Closed the request - Plotchart has the possibility to dispaly histograms


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

  Next version of the patch, made after running the newest
  frink, v2.1.3, against tcllib. This cut down on the number
  of bogus 'missing final return' quite good.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7675: 8.diff

  Logged In: YES 
  user_id=75003

  Final patch, frink 2.1.5, new sha1, changed md5, base64.


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

  Oh, I will have to look into that - I do not remember the details of why I made this
  change. 


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

  Yes, the result of matmul_vm (the underlying routine for matmul for the multiplication
  of a row vector and a matrix) actually returned a column vector. 

  (The change from 1.0 to 1.0.1 was meant to solve the issue of row and column vectors,
  there is a natural distintion possible between them. I tried to keep some of the previous, 
  sloppy behaviour, while at the same time being more strict in this distinction. I solved
  the problem by transposing the result - this gives a correct row vector and therefore
  a correct answer with the rest of the computations)

  See the CVS repository (version now: 1.0.2)


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  File Added - 25425: tree-widget.patch

  Logged In: YES 
  user_id=68433

  JeffH points out that the tree should scroll horizontally if
  the label is completely off-screen.

  The amended patch (version 2) implements this behaviour: if
  the label is completely off screen, the tree scrolls so that
  the left edge of the label lines up with the left edge of
  the window (modulo -xscrollincrement).


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  File Added - 25428: tree-widget.patch

  Logged In: YES 
  user_id=68433

  Take 3: this version ensures that the left edge of the label
  is visible; if it is off the right or left side of the
  window, it scrolls horizontally so that the left edge of the
  label is aligned with the left edge of the window.

  This feels the best so far.


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

  As per RFC2821 section 4.1.1.2 the MAIL command expects the
  reverse-path as its first argument.
        "MAIL FROM:" ("<>" / Reverse-Path)
                         [SP Mail-parameters] CRLF

  In section 4.1.2 this is defined:
        Reverse-path = Path
        Path = "<" [ A-d-l ":" ] Mailbox ">"

  So to summarise you _MUST_ put the senders address within
  angle brackets.
  eg: MAIL FROM: <me@localhost>

  The old version was permissive but in order to handle some
  of the SMTP options we need to have these delimiters in place.
  eg: MAIL FROM: <me@localhost> SIZE=281


login: barcellos
username: barcellos
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=804248

  I'm sorry. I don't read RFC2821. I only use that like I use
  all other mail server (Postfix, Sendmail, etc.).

  Thanks.

  P.S.: I will read all SMTP's RFC ;) 


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

  Ok, the .gz file was the only file which was short, and I have re-uploaded it now.
  NOTE: It may still be necessary to download it multiple times, as it seems that even now, about 20 hours after re-upload, some of the mirrors still have short files. At least one mirror is ok tough, returning the full file (5319952 bytes, md5 5bc9567b3a61884716a908d5295d7105).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  A bit more info, the checksums:

  a5133b5380e5ae71faf1c6712a3b11ba  tcllib/1.13/README-1.13.txt
  f2553e4834555b206726461e4600813e  tcllib/1.13/tcllib-1.13.kit
  4625574b88a65031ecf0a0fd7e33764d  tcllib/1.13/tcllib-1.13.tar.bz2
  5bc9567b3a61884716a908d5295d7105  tcllib/1.13/tcllib-1.13.tar.gz
  272f91778ba43e43abe6dea3531062b2  tcllib/1.13/tcllib-1.13.zip

  The Files manager shows this data as well, behind the (I) button of each file.


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

  Applied, with same small changes. Chunks irrelevant to
  headers have been ignored.


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

  Not only with syslog, also with Andreas log package.

  I'll consider it. Its quite easy to do.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 214446: logger.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

  File Added: logger.diffs


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

  Yes, that's what the problem is.  Where the extra ^M is coming 
  from, I'm not sure; it might be a bug in the OS X port of tclsh.  
  Anyway, replacing the calls to "puts" with "puts -nonewline" looks 
  like it solves the problem.


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

  Added the -nonewline options. Comitted to head.

  Note: I believe to know the actual reason for the problem: 
  Backtics are most likely using implicit pipes to capture the 
  output of the process. On Mac OS X pipes are implemented 
  using sockets. Tcl configures translation crlf for sockets. We 
  had this a few weeks backs on the tcl-core list and/or c.l.t.


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

  Is the Tcl package 'scotty' known to the submitter ?

  See http://mini.net/tcl/691.html for description and
  references.


login: tmmenezes
username: tmmenezes
mimetype: text/plain
icomment:
  The bug is located at:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF]\
                  $args]
  }

  and can be fixed by appending '--' at the end of all the options, and before $args:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF --]\
                  $args]
  }


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

  Typically tcl commands use "--" to indicate the end of option processing. If you always add this before the data parameter then you can avoid this problem in many commands that accept options (for instance, switch is best used as 'switch -exact -- $option { .... }').
  However, it is also quite simple to handle a final data parameter that happens to have a leading hyphen. This was fixed previously for crc32 and other tcllib functions. I've applied the same fix here. In the meantime - use '--'.


login: glauss
username: glauss
mimetype: text/plain
icomment:
  Please do not revert to the old implementation.

  Fix in mainframe.tcl
  proc MainFrame::setmenustate { path tag state } {
    variable _widget

    switch -exact -- $state {
    disabled { set state 0 }
    enabled  { set state 1 }
    }

  ....

  Sorry I've not learned how to supply a patch
  As soon I've manage this, i can send the fix


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

  Currently tcllib supports tcl 8.2. So it is a bug if the
  tests cannot be run with tcl8.2. If some tests require
  tcltest > 1.0 then we can mask those tests using contraints
  or provide the missing test features in all.tcl.


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

  After the changes committed last night the "all.tcl" file does 
  work with Tcl 8.2, and there are no errors in the testsuite 
  anymore (8.2/3/4/5, linux)


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

  Rewrote testsuite to use mode 'r', and to have independent
  tests. Committed to CVS head.


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

  There is no file attached to this item. Always check
  the checkbox "Check to Upload & Attach File" (see
  below) when attaching a file.


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

  I know that this is not considered an important issue to
  others, so I bumped down the priority very low.  Perhaps I
  will get time sometime to do something with this.  I at
  least wanted to record the issue so that if others find a
  need for this type functionality, they can add comments on
  other issues relating to this.


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

  The new sak.tcl command now does this. When doing 
    tclsh sak.tcl html
  for instance, it generates new html in the doc/html subdir
  only for modified manual pages.

  I don't know if this completely fixes this request but it's
  probably close.


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

  This is the first step, of three. The second is to extend 
  the "gendist" subcommand to generate documentation and 
  pace it into the distribution. The third and last step is to 
  extend the installer to recognize stored pre-generated docs in 
  an archive and use it instead of performing the generation 
  itself.

  All of the steps are possible. especially given that we are now 
  in tcl, and that installer and sak can share code.


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

  Do you have a patch for this ?

  Or alternatively can you give me an idea how to do the 
  special processing ?


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

  I should have scrolled down. Maybe I do need a coffee in 
  the morning :)


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

  Is it sure that this is really done by snit, and not the
  package management code in general ?


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

  Ah. Ok. I see and understand now. This is my bug, this is
  code I wrote :(


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

  Looks like this was introduced in r1.9:
      regsub -all -- \\\\ $html {\&bsl;} html
  changed to 
      return [string map [list [...] "\\\\" "&bsl;"] $html]

  (i.e., retained one too many levels of \-escaping.)

  Attached patch fixes the problem, and adds a test case.


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

  Reopening --  this is back again.

  htmlparse::PrepareHtml replaces "{", "}", and "\"  (left
  brace, right brace, and backslash) with the nonstandard
  entity references &ob;, &cb;, and &bsl;. 
  htmlparse::mapEscapes used to change these back into braces
  and backslashes, resp.  It looks like this was changed in
  r1.16 (bug #1018574); now backslashes in content come out as
  "&bsl;" (that's "ampersand, b, s, l, semicolon" in case the
  bug tracker mangles it).


login: davygrvy
username: davygrvy
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=7549

  Should be using the numeric entities. &ob;, &cb;, and &bsl;
  aren't documented as entities in HTML 4.01

  (Desktop) 7 % htmlparse::mapEscapes &#[scan \{ %c]\;
  {
  (Desktop) 8 % htmlparse::mapEscapes &#[scan } %c]\;
  }
  (Desktop) 9 % htmlparse::mapEscapes &#[scan \\ %c]\;
  \


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

  Yes, that is what Joe proposed to me a few minutes ago as
  well, on the tcler's chat. I am currently implementing that.


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

  I will add test cases as well and when I am done both bugs
  will be closed.


login: rftghost
username: rftghost
mimetype: text/plain
icomment:
  File Added - 223524: dexec.tcl.diff

  Logged In: YES 
  user_id=1759969
  Originator: YES

  File Added: dexec.tcl.diff


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

  Applies cleanly. Quick check has several failing tests. Investigating.


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

  Test failures were simple. The expected acitiy traces simply did not take the new callback into account. Fixed. Patch accepted and committed.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Not a bug. The puts statements are already commented out in the CVS head.
  However, this action doesn't seem to have been added to the ChangeLog.
  It is therefore unknown who has done the work.


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: franktx
username: franktx
mimetype: text/plain
icomment:
  Hi Andreas,

  I played a little with the original crosshair.tcl code. I added the crosshair::bbox proc and made a few changes. I'll try to get the latest code and make the changes there and I'll upload it too. 

  At this time the code only works for one area of the canvas. I have some problems with the hide to work good as it gets triggered by the bind when it leaves the canvas versus the area. It looks pretty good just a little awkward. I may place the  Xhair in the lower left of the Bbox to hide it. 

  The performance of the code slows down (the lines can not keep up with the mouse pointer) when there is a big number of points in the canvas. This is independent of the code that I added. I am not sure if there is a way to improve the performance.

  Regards,
  Frank Gover


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The slow-down might be an issue with the canvas itself getting sluggish for lots of items to display. Without having re-read the code I seem to remember that the cross-hair creates only 2 lines and then just moves them (i.e. changes coordinates). I do not believe that this can be made faster. Slower, yes, simply destroy and create the lines for each movement. I.e. new items for every change.


login: franktx
username: franktx
mimetype: text/plain
icomment:
  Hi Andreas,

  I made the changes to the version from the SVN repository (uploaded here). The Crosshairs are confined to a bbox and they are hidden when the pointer moves out of the bbox. It seems to be working fine.

  Handling more than one Bbox is not there but can be easily implemented. I think in place of passing a single BBox I will make it to pass a list of BBoxes. Then iterate through them. I don't think it should affect the performace too much. 

  Regards,
  Frank Gover


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Committed variant code handling multiple boxes.
  See  http://core.tcl.tk/tklib/info/9382d1e073
  Branch:  crosshair-bboxes-3603562

  Notes: New flag hidden to explicitly track un/hide state.
  Crosshairs which are out of bounds are destroyed (like it was done for hide only, before).
  They are re-created on unhide and entering a visible area.

  Visible area is the area of all of the bounding boxes.
  Overlapping boxes are allowed as are nested boxes.

  Crosshairs extend the largest amount they can based on all the boxes they are currently inside of.

  Please test. (I already did, using examples/canvas/citygrid.tcl, see the new statements it has).
  After it passes muster I will merge to trunk and release branches.


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: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Sorry, realized I could be a little more specific:
  In proc ::ftp::StateHandler on line 284 the following was added:
  if {$ftp(State) ne "quit_sent"}

  for this version. Should be changed to:

  if { ! [ string equal $ftp(State) "quit_sent" ] }

  to maintain compatability with tcl versions earlier the 8.4.

  Thanks,

  John Mercogliano III
  Contractor, TekSystems
  Systems Integration
  Sentara Health Care
  jxmercog@sentara.com


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

  I do not understand the part about the missing "default way 
  of coordinating the callbacks".

  What do you mean by 'coordinating' ?

  Later you say 'ability to wait on any number of call backs 
  is desirable'. 

  If I undertand you correctly you want to start, say several 
  http requests, and then perform an action after _all of 
  them_ have reported back via the callback you gave them ?

  Can you give me an example script how to use this ?

  Note: It might have been better to attach the above 
  implementation as a file instead of inlining it into the 
  message itself. See the "check to upload and attach file" 
  checkbox and entry items below, after the followups.


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


  I think there are many related ideas here.  Tcl's variable
  and command traces, Tk's widget bindings, the Notifier
  class in [incr Tcl] that Michael McLennan described at
  the latest Tcl/Tk conference, as well as some internal
  code we use on the OOMMF project.  I think this semaphore
  idea is similar too.

  They all have in common the notion of registering a callback
  script to be evaluated later when something happens.  It
  would be a worthwhile exercise for someone to make an
  inventory of these techniques and what they share in common
  and how they differ.  My impression is that the
  implementations are very different, even when the purposes
  are quite similar.

  Perhaps there's a fundamental capability to be extracted
  out and used by all?


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

  Sorry for the long delay.

  By "default way of coordinating callbacks", I mean that 
  currently, if I am using two packages that have callback 
  facilities, I must write my own code to wait on them at the 
  same time. There is currently no mechanism in TCL to invoke 
  asynchronous routines and wait for the one that completes 
  firsts. I must wait for one routine specifically, and then 
  wait for the other routine. If I wait for the wrong one, 
  the following processing timeline is the result.

  1. Start asynchronous routine A (completes in 5 seconds)
  2. Start asynchronous routine B (completes in 2 seconds)
  3. Wait for routine A to complete (5 second idle time)
  4. Process the result of A (2 seconds)
  5. Wait for routine B to complete (0 seconds idle time)
  6. Process the result of B (2 seconds)

  Total time = 5 sec idle + 4 sec processing = 9 seconds.

  I would like to do

  1. Start asynchronous routine A (completes in 5 seconds)
  2. Start asynchronous routine B (completes in 2 seconds)
  3. Wait for routine A or B to complete (2 second idle time)
  4. Process the result of B (2 seconds)
  5. Wait for routine A or B to complete (1 second idle time)
  6. Process the result of A (2 seconds)

  Total time = 2 idle + 2 process + 1 idle + 2 proc = 7 sec

  If A and B are from the same package, this is usually easy, 
  provided that the author build a "wait any" function.
  If A and B are from different packages, I must invent some 
  way to handle this -> semaphores.


  The general concept is that I want to be able to wait for 
  any of the callbacks, without knowing which one will 
  respond first, or possibly waiting for any one of a 
  particular type of callback, again without knowing which 
  one will respond first.

  An example is something like

   http::geturl $A ... -command Semaphore::signal
   http::geturl $b ... -command Semaphore::signal
   timer::set "120 seconds" -command Semaphore::signal

   for {set x 1} {$x <= 3} {incr x} {
     set completed [semaphore::wait *]
     switch -glob -- $completed {
       ::http* { ... }
       ::timer* { ... }
       default { error "Unknown completed semaphore 
  $completed" }
     }
   }

  This way, we don't get stuck on waiting for a response from 
  a web server response, and we can determine timeouts. I 
  realize that the http::geturl has a timeout option, 
  however, the order in which you wait for them to complete 
  becomes critical. With thus structure there is no need to 
  build timeouts into all routines such as ftp, email, http, 
  database, socket listening etc., and one does not have to 
  wait for specific events to finish resulting in the ability 
  to continue processing as soon as the first one completes.

  The above code is very safe, but one could wait on 
  semaphores of the format ::http::* or any other format.


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

  Semaphore , as a package name, concerns me as
  it can have more than one meaning.  On POSIX based
  machines, there is a kernal based IPC data structure
  called a semaphore,

  Given that both uses of the term are common, what
  would be the best way to disambiguate the issue?


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

  This looks good.  Thank you :)  I will most likely add it to
  the cvs repository soon...


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

  I committed this a while ago.  aku made some minor
  improvements.  Thank you Michael :)


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


  A second look make it look like
  Tcl is at fault here, not aes.

  still looking...


login: 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: 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: nobody@207.203.88.15
username: nobody@207.203.88.15
mimetype: text/plain
icomment:
  Logged In: NO 

  You are clobbering the built-in label command with the one from tile. A ttk::label has no option "-highlightthickness". Remove the "namespace import -force ttk::*" and it will work.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Yes, the namespace import ttk::* will break more than just tooltip, and is considered a non-portable operation now.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Bumping priority because it impacts delivery of documentation for packages on which Tcl 8.6 depends; we want the changes fed in upstream rather than having to hold custom patches to the generated nroff.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Investigating further (reading the doctools code ;-) specifically fmt.nroff) I see that there's an assumption that the title of the manpage that is used with [nr_title] is the same as the title that is used with the NAME section. That's not generally true; a number of Tcl's manual pages document multiple things (e.g., the *.3 ones) because they're really documenting an API. However, the name part that ends up in the .TH header (i.e., that's used with [nr_title]) needs to be a single fairly-short word since it goes in a location that can't be word-wrapped when doing actual manpage formatting for an 80-column terminal.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  On, and there needs to be some whitespace compaction when dealing with the $description for the NAME section. Trivial to add a little [regsub] and [string trim]...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok, I added the whitespace compaction at least, and switched examples to .CS/.CE formatting.

  Regarding the other thing (nr_title vs NAME) you are basically saying that I cannot use the 'title' argument for NAME, and need some separate information (*) to allow for the documentation of multiple things. I might be able to use the title if the separate info for NAME is missing, as a fallback.

  (*) Either as additional argument of manpage_begin, or via a new doctools command whose data I pull in in the second phase. Oh, or by using all the command names which will get put into the synopsis anyway, right ? The latter means a bit more data extraction to get the [cmd]'s in [call]'s and [usage] contexts.

  That will take a bit more time.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  This is driven by making the Thread extension have as good documentation as possible. The thing with NAME is particularly driven by wanting to make the derived contents page list the commands instead of just the pages. Critical? No. Important for getting a really good build of the docs? I think so.


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

  >% ::struct::set include myset A <- non initialized set but there is no constructor!
  >can't read "myset": no such variable

  This looks to be a bug.

  > % ::struct::set size myset
  > 1 <- must be 3

  This is operator error. The 'size' method takes a set, not the name of a set variable. I.e. call this as

      ::struct::set size $myset

  Note the $

  Ditto for the 'empty' method.


login: sjeanjean
username: sjeanjean
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2028198
  Originator: YES

  Thanks for the very quick response.
  It's one of the (very few) drawback of Tcl. The commands can take a variable or the name of a variable without a whole coherency.

  For info, the bug of the undeclared set occurs in my test report but not in my code.


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

  Ok. I will see if I can replicate it. If not I will close the bug, otherwise the testsuite will have to be extended and a bug fixed.


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

  Some experimentation shows that the error is shown only for the critcl implementation of struct::set.
  The Tcl implementation of the package is free of it.


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

  Fixed in head. A related problem, the method 'add' did not behave like 'include' just for a set vs item to include, it was not creating a non-existent variable. This was for both Tcl and critcl.implementations, has been fixed as well now. Package version is 2.2.3 now (tcllibc/critcl version unchanged however).


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

  I talked to Marshall Rose, the creator of
  the "mime" and "smtp" packages and he explains
  that there is a difference between the *envelope*
  SMTP stuffs a mail with, and the headers in
  the mail itself. In the envelope the "MAIL FROM"
  command/directive may contain the bounce syntax,
  i.e. <>. The headers of the mail may not.

  The following is an excerpt of Marshall's mail to
  me. Given this I am closing the report now.

  ~~~~~~~~~~~~~~~~~~~~~~~
  In SMTP, you can do

  MAIL FROM:<>

  which indicates that the *envelope* has no return address.

  in 822, if a header requires an address, you can do one of

  fred@example.com
  Fred Flintstone <fred@example.com>
  <fred@example.com>

  the last case isn't legal according to 822, but an early
  sendmail
  generated addresses like that, so everyone updated their
  parsers to
  deal with it. the mega-revision to 822, RFC 2822, explicitly
  allows
  the third case.

  Regardless, what the submitter is trying to do is fine, but
  they're
  doing it the wrong way. here's the right way to do it

  # put the ENTIRE message into $mimeT

  smtp::sendmessage $mimeT \
    -header {Resent-From fred@example.com} \
    -header {Resent-To addr1@example.com} \
    -header {Resent-To addr2@example.com}  ...

  which says to resend the entire message using the envelope
  presented
  in the arguments.


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

  George@Orwellian.Org replies...

  Maybe it's me, or maybe there are almost zero
  examples of how to do non-trivial things with
  these two packages, smtp and mime, but I still
  don't know how to accomplish what I said I was
  doing using the reply just given.

  I said I was replicating popboxen, headers and body,
  when remailing them.

  I am now not only getting four extra "Resent" headers
  using this method, I still can't get the SMTP FROM <>
  equivalent which would set "Return-Path: <>". That's
  when I pass the whole msg in the mime part, and
  set the Resent-From to the address of the originating
  popboxen.

  Then I tried:

  Resent-From seems to set the Return-Path, but
  when I tried to set that to <> for replication purposes,
  it blew up with the same error msg as originally reported:

  error in Resent-From: expecting mailbox in local-part (found
  >)

  Failure to replicate.

  Any other ideas, or can't these packages do it?


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  the packages work just fine. they handled hundreds of 
  messages a day for me. 

  put the original message in a mimeToken and use -header 
  {Resent-From ...} -header {Resent-To ...}

  if you think it is still broken, then reply with a tcl 
  script that demonstrates the problem.

  /mtr

  ps: "<>" is not a valid address. it is used in SMTP to 
  indicate an empty return address.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 19569: README.html

  Logged In: YES 
  user_id=24077

  > There is a dearth of documentation or real world
  > examples associated with packages smpt, mime.

  when i wrote the original mime/smtp package, there was 
  some documentation that went with it. i don't know why/how 
  the document got lost. i'll attach it.

  > What is the exact output result when using
  > the different options? Where is a discussion
  > of header vs. envelope? Why can't some options
  > be set in the header vs. envelope?

  i don't understand the question...

  to answer your two most important questions:

  1. you use -canonical when you are supplying the raw data 
  for a mime body part; if -canonical isn't given, then the 
  input is an 822-formatted message.

  2. to get the behavior you want, try:

  smtp::sendmessage $mimeT -originator "" \
  -header {Resent-From ...} \
  -header {Resent-To ...}


  > Why do these packages twiddle with the upper/lower
  > case of some of the header params submitted by the user?

  in the early days, some software didn't format messages 
  when it displayed for the user. people who used that 
  software would complain if the headers didn't look 
  "right"... so, those of us who were writing some mail 
  software in those days decided to make the headers look 
  pretty.


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

  The original documentation (README.*) is part of the 
  module. It is not installed however. The manpages for smtp 
  and mime are directly derived from these documents.


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

  This is quite similar to the trace log feature in logger.


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

  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:
  Logged In: YES 
  user_id=75003

  The attached changed implementation fails the testsuite.
  As the testsuite as is does not use the new functionality,
  the new code is breaking existing functionality.


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

  Accepted, with small change in join, fixing the testsuite
  breakage. Extended testsuite and docs to cover the new
  functionality.


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

  Grazie, Sebastiano - I fixed this bug by commenting out the
  offending 'puts' lines.


login: oehhar
mimetype: text/plain
icomment:
  This ticket shows as "pending" in bwidget tracker with the same id: 1053086fff and is open here.

  Closed


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 69354: 849829.patch

  Logged In: YES 
  user_id=80530


  Here's a patch that corrects
  the problem.  String comparisons
  of numbers wasn't a good idea.

  Please review and apply if
  acceptable.


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


  while the patch is an improvement,
  it doesn't fully solve the problem.

  the scrolling commands from 8.5's [text]
  have much more precision in their
  arguments, so we run into the "real problem"
  of needing to detect when the second
  argument is "near" 1 rather than when it 
  equals 1, because scrolling as far down
  as possible can leave the second argument
  short of 1 with a value more like
  0.999506793914.

  This might also be viewed as an
  incompatibility in [text].


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

  A little checking shows that when all the text is visible,
  we do indeed get 0.0 and 1.0 for f1 and f2 so the first part
  is fine.

  When lots of text is present, then the following seems fine
  -- we can always adjust the tolerance if needed, but I  have
  yet to force it beyond 1e-4.

  set Options(AutoScroll) [expr {(1.0 - $f2) < 1.0e-6 }]


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

  Actually this can be resolved by simply counting
  subsections, i.e. generating an anchor based on a unique id
  instead of the title. Of course, [sectref] section
  references still need disambiguation.

  A palliative might be to look for the section the subsection
  is in and use it in the construction of the anchor. ... Ah,
  not quite, still needs disambiguation of references ...

  Ok, it seems the best we can do without user intervention is
  warning. For reolsution of ambiguities we need a syntax
  change in the format. I.e. sectrefs, sections, and
  subsections need optional arguments for guide resolution.

  Added code generating warnings to the CVS head. Common
  layer, not the engines. ... In tcllib this code is tripped
  currently only by the snitfaq.

  Keeping open until a complete solution has been committed,
  albeit at lower priority for now.


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

  Will, what do you think would be a way for the author to resolve the ambiguity without changing the titles ?


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

  Basing section cross-references on the section title strings was a mistake, I think.  It works for small documents, but
  breaks down for larger ones.

  What I've started doing in my personal code, when formatting larger documents, is give each section a tag which
  is a list of period-delimited tokens.  Toplevel sections get a tag that's a single token, i.e., "intro".  Subsections
  add a token, i.e., "intro.history" is a subsection of "intro" and "intro.history.ancient" is a subsection of "intro.history".
  Cross references use these tags instead of the section titles.  As a bonus, the structure of the tag indicates both
  the level of the section and its parentage; you can nest subsections arbitrarily deep, and generate section numbers
  automatically if you choose.

  Note that the command used to indicate a cross-reference can be smart about this: it can recognize both section titles
  (as it does now) and tags.

  This would mean updating all of the Tcllib documentation (ugh) but it's probably worth it.


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

  Mistake - Quite likely. So you have code like

      [subsection FOO intro.history.ancient]

  etc. in your documents ? Or do you use two commands ?

      [subsection FOO][label intro.history.ancient]

  ? (The second would be the LaTeX approach).

  Updating Tcllib. With a smart [sectref] and the tags themselves optional updating the sub/section info and references can be done incrementally.

  Hm.     [subsection FOO intro.history.ancient]
  or      [subsection intro.history.ancient FOO]

  Both can support optional tags. The second form is like [uri].

  Deep nesting of subsections ... If we do that, it seems that we would not need section and subsection commands anymore, just a section command ? (Right now doctools does not have arbitrarily deep nesting).

  In general I think that tagging makes sense. LaTeX uses tags as well, except that tags do not need to have structure. They are just labels for locations. Nesting is limited, and each level has its own command.

  Will do some more thinking.

  Thanks for the comment.


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

  I have a "section" command that looks like this:

    <<section intro.history.ancient "Ancient History">>

  Also, I've switched to using "<<" and ">>" as my expand brackets, in place of "[" and "]".  When
  documenting Tcl code, "<<" and ">>" is less like to cause confusion.


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

  Fixed in head. (sub)sections can be given logical names for use in (sub)section references. Anchors are generated internally, different from both (sub)section titles and logical names, always unique (counter). The system warns about ambiguous (sub)section names.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  andreas - i'll confess that i've never understood what the 
  reverse encoding stuff that was added to the mime package 
  does... i'm not the guy to evaluate this patch...


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

  Some of this is fixed in asn 0.8. I added a asn::peekTag, and some others to handle multi-byte tags and retag things. Not the best solution currently, but works. 

  PeekBytes is basically not needed, as the asn data is just a string. If you want a peek at the first x bytes, simply use string range for now, it works fine with binary data.


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

  Thank you. The fix has been accepted, but it was necessary
  to perform the changes manually. Please do not place patches
  like this into the report itself. Place them into a file,
  and attach that file.

  I have also added -no-apps options to the other install
  targets, to make explicit that they do not install the
  applications.


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

  Done for bug #649383.

  The -image and -bitmap options only affect the label so we
  can leave these.


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

  Hmm, the guidelines say that code to be committed must have a test suite OR a man page.  The install 
  script, however, appears to require a test suite AND a man page.  (I was holding off on writing the manual 
  until I had the interfaces stabilized, but if it breaks things, I'll push it up on the list and do it sometime in the 
  next few days).


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

  Larry's snapshot is not uptodate. The current head (as of 
  Jan 16 2002) generates the log below. There is one error 
  message by 'sed' for calendar + the message by 'ginstall', 
  but the installation is not stopped. Because of this I 
  would not consider the operation a failure. Larry is 
  stricter, he simply does not want to see any error message 
  at all.

  We can change the makefile to assure this.



  [andreask@pliers b]$ make install-doc
  /bin/sh ../tcllib/config/mkinstalldirs /home/andreask/sf-
  dev/504350/b/../i/man/mann
  for j in base64 calendar cmdline comm control crc csv 
  counter struct fileutil ftp ftpd javascript html math md5 
  mime ncgi nntp pop3 profiler smtpd textutil uri log 
  htmlparse report sha1 stooop ; do \
      echo "Installing documentation for $j" ; \
      for i in ../tcllib/modules/$j/*.n ; do \
          sed -e '/man\.macros/r ../tcllib/man.macros' -
  e '/man\.macros/d' $i > $$ ; \
          /usr/bin/install -c -m 644 $$ /home/andreask/sf-
  dev/504350/b/../i/man/mann/`basename $i` ; \
          rm $$ ; \
      done; \
  done
  Installing documentation for base64
  Installing documentation for calendar
  sed: can't read ../tcllib/modules/calendar/*.n: No such 
  file or directory
  /usr/bin/install: installing multiple files, but last 
  argument (/home/andreask/sf-
  dev/504350/b/../i/man/mann/uri.n) is not a directory
  Try `/usr/bin/install --help' for more information.
  Installing documentation for cmdline
  Installing documentation for comm
  Installing documentation for control
  Installing documentation for crc
  Installing documentation for csv
  Installing documentation for counter
  Installing documentation for struct
  Installing documentation for fileutil
  Installing documentation for ftp
  Installing documentation for ftpd
  Installing documentation for javascript
  Installing documentation for html
  Installing documentation for math
  Installing documentation for md5
  Installing documentation for mime
  Installing documentation for ncgi
  Installing documentation for nntp
  Installing documentation for pop3
  Installing documentation for profiler
  Installing documentation for smtpd
  Installing documentation for textutil
  Installing documentation for uri
  Installing documentation for log
  Installing documentation for htmlparse
  Installing documentation for report
  Installing documentation for sha1
  Installing documentation for stooop
  chmod 444 /home/andreask/sf-dev/504350/b/../i/man/mann/*
  /usr/bin/install -c -m 
  644 ../tcllib/man.macros /home/andreask/sf-
  dev/504350/b/../i/man


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

  The problem is that [format] (and [binary format] too) use
  Tcl_GetIntFromObj when they would actually be better off
  using Tcl_GetLongFromObj. Unfortunately, the Tcl core is not
  that clean about the difference between these two, and most
  developers do not have a platform which differentiates
  between them (making it a bit tricky to develop fixes.)  :^(


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 11019: sha1.test

  Logged In: YES 
  user_id=80530

  Now that Tcl Bug 219223 has been fixed in Tcl 8.4a4
  and Tcl 8.3.4, the errors in the sha1 package on
  64-bit platforms can be clarified.  Attached is the
  output of the sha1 test suite on a 64-bit platform.


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

  After TIP 72, this bug (or something similar) 
  appears on all platforms.  Try the test suite.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902

  Bother! Can't attach a patch here!  Pasting instead (email
  me if you want an unmangled version):

  Index: modules/sha1/ChangeLog
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/modules/sha1/ChangeLog,v
  retrieving revision 1.5
  diff -u -r1.5 ChangeLog
  --- modules/sha1/ChangeLog      8 Feb 2002 06:05:20
  -0000       1.5
  +++ modules/sha1/ChangeLog      20 Feb 2002 09:51:56 -0000
  @@ -1,3 +1,8 @@
  +2002-02-20  Donal K. Fellows  <fellowsd@cs.man.ac.uk>
  +
  +       * sha1.tcl (initK,sha1): Force 32-bit interpretation
  of constants
  +       larger than INT_MAX on 32-bit processors, due to
  TIP#72.
  +
   2002-02-07  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>
   
          * Version up to 1.0.2 to differentiate development
  from the
  Index: modules/sha1/sha1.tcl
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/modules/sha1/sha1.tcl,v
  retrieving revision 1.5
  diff -u -r1.5 sha1.tcl
  --- modules/sha1/sha1.tcl       8 Feb 2002 06:05:20
  -0000       1.5
  +++ modules/sha1/sha1.tcl       20 Feb 2002 09:51:57 -0000
  @@ -97,7 +97,7 @@
                  0xCA62C1D6
              } {
                  for {set i 0} {$i < 20} {incr i} {
  -                   lappend K $t
  +                   lappend K [expr {int($t)}]
                  }
              }
          }
  @@ -180,11 +180,11 @@
   
          # initial H buffer
   
  -       set H0 0x67452301
  -       set H1 0xEFCDAB89
  -       set H2 0x98BADCFE
  -       set H3 0x10325476
  -       set H4 0xC3D2E1F0
  +       set H0 [expr {int(0x67452301)}]
  +       set H1 [expr {int(0xEFCDAB89)}]
  +       set H2 [expr {int(0x98BADCFE)}]
  +       set H3 [expr {int(0x10325476)}]
  +       set H4 [expr {int(0xC3D2E1F0)}]
   
          #
          # process message in 16-word blocks (64-byte blocks)


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

  This patch restores correct operation on 32-bit
  platforms.  Still broken on 64-bit.


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

  To be precise, I see these test failures
  on Linux/Alpha:

  sha1 1.0.2 (pure Tcl)

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffffa9993e364706816affffffffba3e25717850c26cffffffff9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffff84983e441c3bd26effffffffbaae4aa1fffffffff95129e5ffffffffe54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffffc0044907cf645a436be66354b3dcb7efffffffff9303abb
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff74c1c66ffffffffb6e5089bffffffffc85144c242d5b6a869e4efd1
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8754ab89ffffffff8e5c5bad7875ccf6ffffffff9177cc85fffffffff3dc8d68
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff9d4ac438ffffffffac6a9629ffffffff90d9d10dffffffffed60d04cffffffff88184cce
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  7769bcdaffffffffe977b8731c8be7f3ffffffffd370300e4ba6b57b
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8fb2eba3ffffffff945e91a8ffffffffb21478523535a8aa16695b74
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffffad0202a8ffffffffe9c108f713620267fffffffff0e38586ffffffff80c745b7
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff82a5587fffffffff3abe5b8fffffffff0b4c383ffffffff988fd352ffffffffbbfc4493
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff92f662d9ffffffff923dfeb63636ae4fffffffff85226fa66b9cd7ce
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED


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

  Those test failures were based on a broken Tcl
  (see Tcl Bug 52690).

  Here's the real failures:
  sha1 1.0.2 (pure Tcl)

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffffa9993e364706816affffffffba3e25717850c26cffffffff9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffff84983e441c3bd26effffffffbaae4aa1fffffffff95129e5ffffffffe54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffffc0044907cf645a436be66354b3dcb7efffffffff9303abb
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff74c1c66ffffffffb6e5089bffffffffc85144c242d5b6a869e4efd1
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8754ab89ffffffff8e5c5bad7875ccf6ffffffff9177cc85fffffffff3dc8d68
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff9d4ac438ffffffffac6a9629ffffffff90d9d10dffffffffed60d04cffffffff88184cce
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  7769bcdaffffffffe977b8731c8be7f3ffffffffd370300e4ba6b57b
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8fb2eba3ffffffff945e91a8ffffffffb21478523535a8aa16695b74
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffffad0202a8ffffffffe9c108f713620267fffffffff0e38586ffffffff80c745b7
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff82a5587fffffffff3abe5b8fffffffff0b4c383ffffffff988fd352ffffffffbbfc4493
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff92f662d9ffffffff923dfeb63636ae4fffffffff85226fa66b9cd7ce
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED

  Note the underlying problem appears to be that the
  sha1 package assumes all arithmetic is modulo-2^32.


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

  hmmm... I guess those look the same don't they?
  ^$#*&#$& ./config.site file!

  OK, *Here*'s the real test failures:

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  d5b4f54ca9993e36e86031f24706816aa1834873ba3e2571281e6df67850c26c98fdf6ae9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  a6b14ada84983e449153c7871c3bd26ee1f36da4baae4aa1e91ed56ff95129e561738f02e54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  dd0aac2fe7ad10bdc4ddbc4482b71c3c6f12b75887cd945543829e3113b4f2a6e2f1ad0526c48ef3
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  5a17b268d0e2fa7f2dac78a9561a86c0bf542b56d80f08539e0dc83f2e401cb464e53e7768b82066
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ea0fbc027c29d69390261ca758438a1c2f8ed3364849b033fa9a35cdcacc8a423c2dec038000cdf2
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  cc3ff427d2fbf753a1628cb921ab822b6b6bd9e34426b6e0f56f5309c5a1a77fab50fb292f23dd17
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  1d2da43db1f9a7df97a8aba8f0bb6ccd9559b9da2e1496d7f77aa4e787acf95c47d5421a8ba82409
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  94a6b3c391128572ab943424d5c29d4ca1b9844afa746148dfc1bd81e2e704ddba1093e1f73eb2c
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  6622b6be347a00eca598a3ba0ed2e4dd5e865a18b7413715b88aac85bbaff3d587886185c4b6807
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  f10225d437a408968c2974b33bc2592c9b3b22a533f5ffa2f8defaa449114f19e7a418edab76fadc
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  45e5a8199154232cdacc219d0f5bdf14929d2b0e1e4afad1a0ee7246a413b9965a408dca976eacb
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 18170: 64.patch

  Logged In: YES 
  user_id=80530

  Yes, 32-bit register arithmetic assumption was the
  culprit.  Here's a patch that fixes things.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 14531: 476988.diff

  Logged In: YES 
  user_id=75003

  Enclosed a patch fixing the problem.


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

  I can agree with section. For version I am less sure, it will 
  come in again in the [require] statements. ... It is correct that 
  manpages not dealing directly with a package, overviews and 
  the like, care less about a version.

  Instead of 'command' maybe call it 'title'. Have to think a bit
  more.

  What other ways of starting a page do you envision ?

  I wish a report could be assigned to more than one person. 
  This is also something Joe English is interested in. guess I'll 
  refer him to these items by mail.


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

  Changed code to detect the situation and throw a more properly looking error ('Not enough data to process padding'). This is now version 2.4.2 of base64.


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

  This problem is fixed in the CVS.

  2004-11-22  Andreas Kupries <andreask@activestate.com>

  * rational_funcs.tcl: Removed bad source'ing of file
    polynomials.tcl. Depended on current working directory in the
    right place, and superfluous as well, as immediately after a
    'package require' of the package loaded it in the proper
    manner. Disabled the test code at the end as well.


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

  There is no patch attached.

  Please send the patch to me 
  (<andreas_kupries@users.sf.net> and 
  <andreask@activestate.com>).


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

  Given the current description the canonical return value is, 
  IMHO, either the empty string, or the unchanged path.

  However the sense of the command is best handled by 
  returning ".". A relative path, where the absolute pwd is 
  stripped from the input.

  I agree with that implementation.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I believe this due to a change in Tcl 8.6 regarding 'do nothing gracefully' ...
  TIP 323, item 5: lassign - accept zero variable names.

  When lassign is present as builtin command 'struct::list assign' is aliased to it. The testsuite still assumes the syntax of the pre-TIP 323 builtin lassign, identical to struct::list assign's syntax when implemented by Tcllib if there is no builtin.

  Not sure yet what to change or how much. Thinking about it however.

  The testsuite still expects that assign'


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Skipping the affected tests now. Tests where just the message has changed got extended to handle that case.


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

  see also 741653.

  corrected with better namespace qualification for tcllib 1.5 
  and comm 4.2.


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

  I've confirmed this as a bug in 1.95. I have also checked
  that it was still working properly in 1.93.


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

  The new code to handle multi-line actions is too greedy when
  matching the name. Fixed.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  IMHO, this issue was fixed by [Bug 1842346], so I close it.
  Complain, if the current cvs does not solve the issue.


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

  confirmed. Will be availble soon in the cvs version.
  The services feature has also some cleanup bugs in tcllib 1.6. 

  Michael


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

  The latest installer (CVS head) should have file copy -force in 
  this location of the code. Look into the ChangeLog, there 
  should be an entry (Look for 719616).

  Possibly not yet in your snapshot.


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

  These br's are gone if you write [list_begin definitions compact].
  Not documented tough. And I do not remember why it was added.
  Ah ... ChangeLog:

  2002-04-01  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * Committed changes to list generation (better generation of
    whitespace for HTML, allowing hints). Only the HTML formatter
    currently acknowledges hints. This fixes SF Bug #535382.

  Link to that report:

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

  Do you have additional comments regarding this and the old report ? Is that something we could fix by using proper classes for list begin/end and items, so that a CSS can then influence the spacing instead ?


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

  Well, the br's have been yanked out, ditto the undocumented 'compact' hint. The argument is still accepted from manpages using it, but ignored. Any spacing has to be done through CSS now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10449: 459197.diff

  Logged In: YES 
  user_id=75003

  Added file containing the patch from the description.


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

  Hm. Are the implementations of the ftp commands (ABOR, etc) 
  public API ? I thought not. They are accessed directly from 
  the other parts of the demon and I would not export them.


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

  Perhaps not ... I wasn't sure abourt ABOR, etc so I just included them. 
  I am not also sure whether docRoot and fs are exported or not.
  If we refer to ftpd docs (http://tcllib.sourceforge.net/doc/ftpd.html) it provides only two
  two public APIs ::ftpd::server and ::ftpd::config.

  So, I will leave it upto the author/maintener to decide which APIs to export.


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

  The author is/was Steffen Traeger who is interested
  in other things now and there is no official maintainer.
  (tcllib does not have such a big structure like tcl).

  Ok, I leave ABOR etc. out of the export, docRoot and fs in.


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

  I second to not hard wire http as default scheme.
  The suggested solution would be OK with me (and would be
  better than the behavior, as it is now).


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

  I still would find this a very useful enhancement of the uri
  package. The original submitter need ftp as default, I
  sometimes need file as default

  As far, as I see, the suggested simple implementation seem fine.

  Are there any objections against this proposal, that should
  be disussed? 

  Would it help, to submit a patch (even for such a small change)?

  rolf


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

  Accepted, with slight changes. To stay API compatible with 
  existing application the 'defaultscheme' argument defaults to 
  http, and not the empty string. That way applications not 
  using th new argument are not affected by its absence, the 
  pre-existing behaviour is unchanged.


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

  jlib is a jabber library depending on TclXML...

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


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

  Where is the source for jlib?

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

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

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


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

  jlib is part of coccinella.

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

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

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

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

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

  Re-assigning to pascal about that.


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

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


login: cwjolly
username: cwjolly
mimetype: text/plain
icomment:
  Looked at the new code and modified it to work like what I had done with the 1.0 version with some minor changes. The value quoting is optional and rather than using args to json2dict I use defaults 
  so instead of   "json2dict jsontxt -indexlists 1 "   you have "json2dict jsontxt true true "  where first true is for indexlists and 2nd true is for quotevalues.  I also attach the modified driver script.


login: anonymous
mimetype: text/plain
icomment:
  The quoting around all values is unnecessary; it is sufficient to simply require that a value (string, number or bareword) is parsed as a list of length 1.


login: anonymous
username: heinrichmartin
mimetype: text/plain
icomment:
  Please don't break the representation of lists and dicts. Although the idea of http://rosettacode.org/wiki/JSON#Tcl breaks the EIAS principle and makes use of [::tcl::unsupported], the suggested change would break that working code.

  It looks like you want to default to legacy behavior, so my comment might be void. It is just to give another view on the topic.


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

  Just do it again if you get an error. However, you are using this wrong and will leak arrays if you run this alot. Re-read the manual page and pay attention to 
  "Once you have finished, you should use [cmd cleanup] to release all resources. The default port is [const 37]."

  See the example too. You get a token and you should use that to check for errors before trying to use the time value.
  if {[time::status $tok] ne "ok"} {
    puts "something bad: [time::error $tok]"
    ...retry with next server...
  }


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

  What does the standards say ?
  IOW I am suspicious that this is a bug in Outlook Express.


login: usus
username: usus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=426984

  I'm sure it's an Outlook bug.
  Nevertheless do I need this feature in order to compose 
  messages with long subject strings destined to readers 
  using Outlook.
  You are absolutely right, the standards don't say a word 
  about a special handling of subject strings.


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

  Confirmed, will fix.

  I really need to add more tests to the testsuite for this
  package...

  Please assign further bugs you find directly to mic42, so i
  get notified.

  Michael


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

  Has anyone had a chance to look at this problem? Is this a 
  tcl/tk bug?


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

  You need to provide a much smaller example demonstrating the
  problem.

  package require BWidget
  PanedWindow .p
  .p add
  .p add
  set lb [listbox [.p getframe 0].list -bg white]
  set tb [text [.p getframe 1].text -bg yellow]
  pack $lb -fill both -expand 1
  pack $tb -fill both -expand 1
  pack .p -fill both -expand 1
  foreach c [info vars] { $lb insert end $c }
  bind $lb <Double-Button-1> [list $tb insert end "CLICK\n"]


  Given this sample code, I don't see any problem.


login: donp1
username: donp1
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=849486

  OK, here is a much smaller example. Neither scripts work 
  regardless...

  #! /usr/bin/wish
  package require BWidget

  set tlist [list  "element1" "element2"]
  set mainframe [MainFrame .mainframe]
  set topf  [frame [$mainframe getframe].topf]

   # Paned Windows and Frames
  set pw1   [PanedWindow $topf.pw -side top]
  set pane  [$pw1 add ]
  set pw2   [PanedWindow $pane.pw2 -side left]
  set tpane [$pw2 add -weight 3] 
  set tbox [TitleFrame $tpane.tbox -text "Widgets"]

  set sw_t [ScrolledWindow [$tbox getframe].sw -auto both]
  set tlistbox [listbox [$sw_t getframe].tlistbox -height 18 -
  width 20 -highlightthickness 0 -listvar ::tlist] 
  $sw_t setwidget $tlistbox
  bindtags $tlistbox [linsert [bindtags $tlistbox] 3 tlist_Tag]  
  bind tlist_Tag <Double-Button-1> {puts HI}

  # Placing layout frames and major subframes
  pack $mainframe -fill both -expand yes
  pack $topf -fill both -expand yes 
  pack $pw1 -fill both -expand yes
  pack $pw2 -fill both -expand yes 
  pack $tbox -padx 2 -side left -fill both -expand yes
  pack $sw_t -fill both -expand yes


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

  this works find on my SuSE8.2 box, using CDE, KDE and Xwin32
  as X servers.


login: donp1
username: donp1
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=849486

  It works fine with other X servers, but what about Gnome 
  and Ximian? 


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

  (I'm able to replicate the problem -- Debian sarge, using
  metacity WM under Gnome).

  Jason Tang posted an analysis of the problem to
  comp.lang.tcl  (news:dr320s$4bp$1@news-int.gatech.edu),
  suggesting that the problem may be caused by (1) some WMs
  intercepting ButtonPress-1 events and generating multiple
  events in response combined with (2) the fixed
  EVENT_BUFFER_SIZE in tkBind.c.  

  Specifically, a ButtonPress-1 ends up generating multiple
  EnterNotify events; if the window hierarchy is too deep,
  Tk's event buffer overflows, preventing the double-click
  detection logic from working.

  In a quick test, doubling EVENT_BUFFER_SIZE makes the
  attached double-click-bug.tcl work as expected.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I did not really check your bug report because it is so time intensive to build up a test environment and try to find out what is happening.

  Instead, I want to ask you:
  - is the bug still an issue ?
  - does it still arise with the current cvs of bwidget ?
  - if yes, could you please simplify your code to just the usage of the ComboBox in question.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue is reproductible on windows and on linux.

  I think the following point might be the issue:
  - Dialog sets a global grab on its own
  - The Listbox of the ComboBox gets a global grab if it is posted.
  - There is normally a focusOut binding on the listbox, that when there is a click anywhere else, it is closed and the grab is released (and returned to dialog).
  The (highly risky) issue of grabs has troubble here.

  I do not want to go here any further.
  For me, it is ok at the moment, that it works in the normal case when the normal interface is used.
  Maybe, I will come later to the issue.
  Could you post the simplified version on the web site ?
  It shows the issue on linux and windows and does not have the installation system included.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Michal,
  thank you for the contribution.
  I was on holiday. Will look to your patch propably next week.
  Regards,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I have tried the patch.
  Unfortunately, it breaks compatibility for me.
  - up to now, the font of the tabs was controled by the font attribute of the notebook or by the property *NoteBook.font

  Thus the font might be set by one of the following test scripts:
  <CODE>
  font create F16 -size 16
  pack [NoteBook .n -font F16] -fill both -expand true
  .n insert end a -text a
  </CODE>
  or
  <CODE>
  font create F16 -size 16
  option add *NoteBook.font F16
  pack [NoteBook .n] -fill both -expand true
  .n insert end a -text a
  </CODE>

  unfortunately, this is does not working any more.
  Instead, one may use:
  <CODE>
  font create F16 -size 16
  pack [NoteBook .n] -fill both -expand true
  .n insert end a -text a -font F16
  </CODE>

  I would favor for the change, if the current methods would still work and if the additional option may change the font from this default for the current tab only.

  IMHO, code should be added to transfer the default font, if the font option is not given.

  Sorry,
  Harald


login: sosna
username: sosna
mimetype: text/plain
icomment:
  Hello Harald!
  Sorry for such late response - I was on vacation with limited access to the Internet.
  I was rather thinking about possibility to change font of each tab individaully - for example bolded font for currently selected tab.
  What you've wrote is true - with my modification property *NoteBook.font will not work - since it sets font for the whole widget - I didn't think about that.

  Anyway, thanks for looking into this issue.

  Best regards,
  Michal.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  IMHO it is possible to make both work.
  Set and modify the default font of all tabs
  - by the -font option of the widget
  - by the option data base key (*NoteBook.font)
  Have an own font for a page as page option
  - If no page font is used, the default should be used
    (specially tricky, if the default font is changed later by widget configuration)
  - If a page font is used, use this one for this page.

  Prpably, an additional page property is needed, which is the empty string by default. In this case, use the default font, otherwise use this font.

  Please modify the patch to
  - keep compatibility
  - get your requirements work

  Thank you for your contribution!
  Harald


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

  Followup: a thread on clt gave this workaround (I've put a
  feature request
  at the bottom):

  On Thu, 28 Jun 2001 09:17:19 GMT, Jos Decoster
  <decoster@retarget.com> wrote:   
  >The ListBox and Tree are drawn in a canvas. In the 1.2.1
  release, this canvas  
  >was create with the path-name you supplied. In the current
  CVS release, first a
  >frame is created with class ListBox or Tree (to better
  handle option database  
  >stuff) and in this frame a canvas is
  packed:                                   
  >[...]                                                                          
  >You could try to
  use:                                                          
  >                                                                               
  >       bind .t.c <ButtonPress-3>
  {foo}                                         
  >       bind .l.c <ButtonPress-3>
  {bar}                                         

  This works, put I'd prefer not to use BWidget internal
  naming schemes.
  So I'll request a new command for tree.tcl and listbox.tcl:

        .t getCanvas
        .l getCanvas

  like the 'getFrame' command from panedwindow.tcl.

  Salut,
          Bastien


login: norganos
username: norganos
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=418919

  perhaps bind them to .tree.c or .list.c, the canvas itself? 
  i just know, that i had something similar, that worked 
  after i binded it to the canvas...


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

  Committed a change to doctools which
  * fixes the original problem in the HTML formatter by 
  tracking a bit more state than before and inserting <br> 
  tags at the appropriate places.
  * and allowing the writer of the manpage to provide the 
  formatting engine with a hint about whitespacing.

  The HTML formatter recognizes the hint "compact" which 
  reinstates the old behaviour (i.e. minimal whitespace).


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Deleted - 261236: 



  File Added - 261269: tdist.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  I had put a constant bit of code into the body of a loop. Oops! I'm replacing the library with one that runs a bit faster.
  File Added: tdist.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 261418: tdist.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  I had put a constant bit of code into the body of a loop. Oops! I'm replacing the library with one that runs a bit faster.
  File Added: tdist.zip


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

  Actually, the first problem (server timeout) is still here even after I configured the server to not require SSL from localhost clients.

  According to tcpdump, the message is fed to the server in its entirety, but without the ending `.'... Not sure.

  The server's features are:

  250-bonkers.example.com Hello localhost [127.0.0.1], pleased to meet you
  250-ENHANCEDSTATUSCODES
  250-PIPELINING
  250-8BITMIME
  250-SIZE
  250-DSN
  250-ETRN
  250-DELIVERBY
  250 HELP

  Sender and recipient are Ok-ed, then:

  354 Enter mail, end with "." on a line by itself

  To this sendmessage replies with the entire message, but without the "."

  The server is running sendmail-8.13.8 and no longer offers SSL to localhost clients.


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

  Redirecting to Pat for the TLS problem ... I should note that I thought that smtp could work without TLS, i.e. that it would 'catch' a 'package require tls'. Actually I think that it does that, however the code may not clear the ::errorInfo from that caught 'package require'. Of course, if the server requires SSL then smtp has no choice but to fail if TLS is missing. In that case I agree that the error message should be better, however I have myself no idea where to look and what to modify.

  Regarding the missing '.' ... Is the version of smtp/mime the same, or was that changed too ? Which version of smtp/mime/tcllib is used btw. ?
  Looking at the ChangeLog I see for example that Pat fixed something in the generation of the terminating '.' for the non-Trf path. This was Nov 6, 2006, i.e. about a month after the release of Tcllib 1.9. Given that you might wish to test if you still have the problem when using the Tcllib cvs head.

  There was for example a bug (827436


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

  TLS and the missing "message-id" messages all come from the errorInfo. If the smtp-package relies on catch(n), it should, probably, reset errorInfo so as not to confuse the library-users with the expected-and-caught errors...

  This -- the wrong information in errorInfo upon failure -- is the subject of this bug report.

  As for the actual time-out problem, could you give me a link to Pat's fix in CVS? I'll apply it here and see, if it solves the problem. The new machine is using tcllib-1.9 (Trf not installed), whereas the old one had tcllib-1.7 and Trf.

  Thanks!


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

  The relevant SF bug is
      http://sourceforge.net/tracker/index.php?func=detail&aid=827436&group_id=12883&atid=112883
  There is no patch file attached however. The relevant diff in the CVS is
      http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/mime/smtp.tcl?r1=1.44&r2=1.45


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

  Thanks for the link, Andreas -- Pat's patch solved the time-out problem and I added it to the FreeBSD port.

  The problem of misleading diagnostics in errorInfo still exists, though. It would seem to me, that errorInfo should either be empty or useful upon return from the library.

  In the cases of this timeouts I was having, it contained something about TLS at first and then -- when I disabled TLS on the server -- some other info useless to the caller:

  can't unset "state(route)": no such element in array
      while executing
  "unset state($prop) "
      invoked from within
  "smtp::sendmessage ::mime::1 -servers {localhost}  -originator .....

  Yours,

        -mi


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

  This is hard to avoid and is one reason we have unset -nocomplain in 8.4+. I've masked the errorInfo in the parts covered here.


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

  Duplicate of [Tcllib SF Bug 948273].

  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=948273&group_id=12883

  Already fixed in CVS head of Tcllib as of May 25, 2004.


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

  I'm sorry about that. That's my mistake.
  I've put a new patch on 
  http://www.interq.or.jp/japan/simai/tcltk/download/exif10apa
  tch.zip


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

  I'm sorry about that. Maybe It's MS-IE bug? :-)

  http://www.interq.or.jp/japan/s-imai/tcltk/download/exif10apatch.zip


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

  Parts of the patch are accepted and applied
  * FlashPixVersion
  * Construction of FlashMode

  Not applied parts:
  * SubjectDistance. Patch assumes that unit is millimeter and 
  converts to meter. Spec says that unit _is_ meter. (*). Is it 
  possible that the specific camera of the submitter implements 
  the standard incorrectly ?
  * ShutterSpeedValue. Instead of logical inversion (1/value 
  seconds) I added the proper unit for frequency (Hz).

  (*) http://www.media.mit.edu/pia/Research/deepview/exif.html
  0x9206 SubjectDistance  signed rational 1  Distance to focus 
  point, unit is meter 


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

  Hmmm.  I'm not sure what you mean by "an object inherits publically 
  from another".  Are you referring to the "component" statement's "-
  inherit" flag?  Also, if I implemented an "info self" method, then if 

     set a [$object info self]

  it should always be the case that "$a eq $object".  Unless $object isn't 
  fully qualified--but [namespace which] should help you there.

  There might, on the other hand, be some point to an "info selfns" 
  method that returns the object's private namespace.

  If I'm missing the point entirely, please enlighten me!


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

  Consider:

  package require snit

  snit::type Y {
  }

  snit::type X {
      component Y -public y -inherit true

      constructor {
  install Y using Y %AUTO%
      }
  }

  X x;

  # I would like to know what object [x Y m] will be evaluated in.

  x Y ;# this could return the Y instance?
  x Y self ;# or this?
  x Y info self ;# or this?

  It came up when I wanted to return a handler object, and
  associate some information with the object, and then
  retrieve that information on handler completion by using
  [upvar self] as an implicit argument.

  I couldn't see a way to determine [x Y] easily.  I've coded
  around it, so it's not a dire need, but it occurred to me as
  a possibly useful facility.

  Colin.


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

  OK, I see what you're after.

  In your example, "x y" can't return the Y object's name; I'm using
  [namespace ensemble] for the dispatch now, and [namespace ensemble]
  requires a subcommand.

  Yes, "info self" would give you what you want; and it would certainly
  be easy to do.  I'll think about it.


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

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

  Sample code again:

  # -----------------
  # working sample
  % set bb [huddle create a b c d] ; # create as a dict
  HUDDLE {d {a b c d}}
  % set cc [huddle create e f g h]
  HUDDLE {d {e f g h}}
  % set bbcc [huddle create bb $bb cc $cc]
  HUDDLE {D {bb {d {a b c d}} cc {d {e f g h}}}}
  % set folding [huddle list $bbcc p [huddle list q r] s] ; # create as a list
  HUDDLE {L {{D {bb {d {a b c d}} cc {d {e f g h}}}} {s p} {l {q r}} {s s}}}
  % huddle strip $folding ; # normal Tcl's notation
  {bb {a b c d} cc {e f g h}} p {q r} s
  % huddle jsondump $folding ; # dump as a JSON stream
  [
    {
      "bb": {
        "a": "b",
        "c": "d"
      },
      "cc": {
        "e": "f",
        "g": "h"
      }
    },
    "p",
    [
      "q",
      "r"
    ],
    "s"
  ]


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

  It took me while to understand the description.
  Well, I believe that I understand it now.
  So let me try to describe it in my own words.

  (1) Huddle provides a generic Tcl-based serialization format
  (2) The entries in that format are tagged with simple type information
  (3) The currently the known types are 'L' for list, and 'D' for dict.
  (3a) There are also 'l' and 'd', these I do not understand yet.
  (4) When converting huddle-notation to other serialization formats like
      JSON or YAML this type information is used to select the proper notation.
  (5) And when going from JSON/YAML/... to huddle their notation can be used to
      select the proper huddle type.
  (6) In that manner huddle can serve as a common intermediary format.
  (7) The nice thing about its notation that Tcl can read this format directly
      (list/dict commands) without the need for a special parser.

  Side note: Origin seems to be http://wiki.tcl.tk/21116


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  Thank you for the kind description.
  That's right.

  Huddle provides a generic Tcl-based serialization/intermediary format.
  Currently, each node is wrapped in a tag with simple type information.

  huddle-format: >
    {HUDDLE {tag {huddle-node}}
  huddle-node: >
    {tag {huddle-node(content)}}
  each tag means:
    s: (content is a) string
    l: Tcl's list, each node is a string
    d: Tcl's dict, each node is a string
    L: list, each node is a huddle-node
    D: dict, each node is a huddle-node
  confirmed:
    - JSON
    - YAML(generally, but cannot discribe YAML-tags)
  limitation:
    - cannot discribe the aliase from a node to other node.


  I want to use the format/library for serializing to YAML/JSON streams.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279039: huddle-0.1.1.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  supported for adding user-type/tag.
  removed simple container tags ("l", "d")
  add command "huddle set"
  add command "huddle remove"

  File Added: huddle-0.1.1.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279694: huddle-0.1.2.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  - add command "huddle combine"
  - add command "huddle equal"
  - add command "huddle append"
  - support inheritance for type-callbacks.

  I want to append the library to Tcllib.
  I already have replaced codes in the yaml-lib.(but not committed)

  Although I am going to put on the same directory as yaml-lib, may I commit for a while?
  File Added: huddle-0.1.2.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  It uses in the yaml library now.
  It is in the same directory.


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

  Ah, thanks for catching that one - I should set up a small test file to at least exercise all of these 
  procedures. Just committed a new version.


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

  Forget to provide background info
  (time) 79 % package require mime
  1.3.2
  (time) 80 % package require smtp
  1.3.2
  (time) 81 % info patchlevel
  8.4.2
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = intel
  tcl_platform(os)        = Windows NT
  tcl_platform(osVersion) = 5.0
  tcl_platform(platform)  = windows
  tcl_platform(user)      = Administrator
  tcl_platform(wordSize)  = 4


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  Here is the errorInfo
  error writing "sock240": invalid argument
      while executing
  "puts $channel [$converter -mode encode -- $X]"
      ("file" arm line 37)
      invoked from within
  "switch -- $state(value) {
          file {
              set closeP 1
              if {[info exists state(root)]} {
  # FRINK: nocheck
                  vari..."
      (procedure "mime::copymessageaux" line 75)
      invoked from within
  "mime::copymessageaux $token $channel "
      invoked from within
  "mime::copymessage $part $channel"
      ("foreach" body line 3)
      invoked from within
  "foreach part $state(parts) {
                          puts $channel "\n--$boundary"
                          mime::copymessage $part $channel
            ..."
      ("default" arm line 2)
      invoked from within
  "switch -glob -- $state(content) {
                  message/* {
                      puts $channel ""
                      foreach part $state(parts) {
    ..."
      ("parts" arm line 7)
      invoked from within
  "switch -- $state(value) {
          file {
              set closeP 1
              if {[info exists state(root)]} {
  # FRINK: nocheck
                  vari..."
      (procedure "mime::copymessageaux" line 75)
      invoked from within
  "mime::copymessageaux $token $channel "
      invoked from within
  "mime::copymessage $part $state(sd) "
      invoked from within
  "smtp::wtextaux $token $part "
      invoked from within
  "smtp::sendmessage $allparts       -header [list From 
  $FROM]     -header [list To $TO]         -header [list Subject 
  $SUBJ]  -servers mail.earthlink.ne..."
      (procedure "mb" line 20)
      invoked from within
  "mb"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 mb"
  (time) 84 % 


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  Still encountering this error. 
  Very apparent that the other side is sometimes closing the 
  socket early but why?  I ran it through sockspy and it never 
  failed! Outside of sockspy it fails frequently. The failure point 
  varies but always occurs on "puts $channel ..."

  I would welcome suggestions for further debugging.

  Another wrinkle. When I run the mime entities through a file 
  and reload into separate process the problem is common. If I 
  run smtp::sendmessage in my mine program then I don't see 
  the error.


login: tkmiller3
username: tkmiller3
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1215370

  I have recently encountered this same bug using Tcl 8.4.9 (from 
  ActiveState) sending PDF attachments; package smtp 1.4, mime 1.4.  
  Does anyone have a fix or workaround?  Thanks.


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

  I have, I believe, found the problem, and committed a change
  to the CVS head that should fix it. I am closing this bug
  now (state pending). Just reopen if I am mistaken.

  Here what I wrote into the ChangeLog


  * mime.tcl (::mime::copymessageaux): Removed usage of the
  command
    'unstack'. Its presence is a bug ever since revision 1.3
  (March
    9, 2000) of mime.tcl, when the converters (base64,
    quoted-printable) started to be used in immediate mode
  instead
    of attaching them to the output channel. This also means
  that we
    do not need the fallback implementation anymore either.

    Many thanks to Roy Terry <royterry@earthlink.net> for
  keeping up
    the nagging about [SF Tcllib Bug 754920] which
  demonstrated the
    problem.

    What happened is that the unpaired 'unstack' removes the
  outer
    .-transformation and a second call may close the channel. If
    that happens any further access to the channel errors
  out, and
    the mail server gets and transfers an incomplete mail
  message.
    It is a 'may' and not a 'will' because it seems that
  sometimes
    the channel has a refcount > 0 and then 'unstack' does
    nothing. This part made the reproduction difficult. It was
    originally suspected to be a problem in Trf itself, but is
    actually a problem in how it is used by mime.


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

  I was thinking about this myself for -validatemethod.  I
  wanted to be able to allow things like:

  option -place -default center -validatemethod [list ListOf
  $placeValues]
  option -modal -default none -validatemethod [list ListOf
  $modalValues]
  ....


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

  The current behavior is as it is by design; there was considerable discussion
  on the Snit mailing list about at the time.  I forget the details; you can find
  them in the Snit mailing list archives (which you can find via the Snit
  home page, http://www.wjduquette.com/snit).

  As for the -validatemethod, it will soon be deprecated; it's being replaced
  by a "-type" option.  I've got the code written and will be starting on the
  documentation updates this week; the new version will be included in
  the Tcllib release for this year's Tcl/Tk conference in October.


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

  Note that "option -type" is now available in CVS.  As for updating -
  configuremethod and -cgetmethod as described here, I'll have to think about it 
  some more.


login: 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:
  And we have to put '-no-apps' into the targets 'install-doc' and 'install-libraries', to prevent them from trying to install things beyond what they are supposed to install.


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

  As for the errors in BWidget I was unable to recreate.  Is
  there an example script available?

  As for the BWidget demo I was able to recreate and then fix.


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

  Please try the current CVS head of tcllib, if it fixes this
  it could trivially be backported to the tcllib1.7 release
  version. The installer and confiigure now recognizes and
  respects ./configure --bindir ...

  dtplite is needed to create the nroff and html documentation
  for tcllib

  If it does not work, please report back with your configure
  / install values, so we can check whats wrong. If it works,
  report back so i can close the report.


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

  This is AFAIK fixed in the CVS head. An 1.8 release is upcoming.
  Is the submitter willing to pre-test it ? so that we can be
  sure that a debian package can be created from it ?


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

  The submitter was mailed directly regarding the new release
  too, no response. The entry is now on auto-close row.


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

  The $lbf listbox also needed these bindings.  Otherwise
  patch merged.  Thanks.


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

  Thanks. Yes, your correction is right. I have accepted it,
  and extended the testsuite as well.


login: zoro2
username: zoro2
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=191529

  This patch is correct, except that 'identity' encoding
  should be used instead, so that non-utf-escaped binary
  strings (which shouldn't happen, but should be considered
  for some pre-unicode packages).


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

  -translation binary should not lose any data - it will treat it all 
  as 8-bit clean data.  You just have to interpret on the 
  receiving end ... perhaps comm requires some sort of 
  encoding command.  The reason that binary is used currently 
  is that this is compatible with the use of comm by a Tcl < 8.1 
  interpreter.  Forcing a different encoding now would also 
  possibly be an incompatible comm version change.


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

  schlenk correctly noted that -trans binary appears to be 
  stripping, not converting the unicode.  :(
  I've made the change for comm to use utf-8 by default, 
  which is mostly compatible with the previous semi-broken 
  stuff, and going forward is fully i18n happy.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Is it possible to provide us with a small script demonstrating how to cause the problem, i.e. crash ?


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  I uploaded a small script which reflects a very minimalized version of what is going on in my program. The program runs in a infinite while loop pausing for 60 seconds then rechecking for new files. The program runs continuously. I had a log with the error in it and unfortunately deleted it. It's actually not hard crashing but instead throws a "error" msg with a trace back to the close statement. Since this trace is really not helpful, as it's not really an error in my code, it seems more reasonable to catch this event and pass a more appropriate error msg and not dump a code trace.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. The script looks ok. I will try to reproduce this with some fake ftp server and files.

  (Note: I am uncomfortable with simply putting in a catch without understanding why the close threw an error. It feels too much like simply plastering over hole without killing the termite which created it).

  A pity that you deleted the log already, or I would have asked for the relevant part of it.
  Do you remember what the error message was ? (close has several conditions where it can throw an error, with distinctive messages).


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Ya, I don't remember what the exact error was. I will change things back to the original state and see if it will fail again. Once I have a log I will upload it.


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

  I'm closing this. I think the following was happening: The connection was open, files being transferred, connection was broken by external forces, my app then tried to close the connection but it was already close. This triggered an error. The catch on your close included dumping the error info and we got an odd dump of stuff from a different catch being done in my app that made it look like my app was crashing. I have now utilized your -output option to redirect your output to a proc and I also added clearing the ::errorInfo var to my app so the odd dump is not longer involved. I think this is basically a false alarm. Sorry about that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  No problem, and glad to hear that you figured it out.
  A bug where I have not to do anything is the best kind of bug ;)


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

  ProgressBar now makes explicit check, disallowing having a
  -maximum 0.


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

  Applied, slightly modified and committed to head. 
  Modifications: Corrected indentation in some places. The tmp 
  variable used to create the list for string map had no 'variable' 
  declaration and was thus in the global namespace. 
  Added 'variable tmp' to ensure existence in the package 
  namespace. Modified the incomplete html handling code 
  minimally, replacing an [expr] by [incr -1].


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  >% huddle jsondump [huddle create key 000000]

  >{"key": 000000}

  this is a miss logic about huddle-lib in jsondump sub-command.

  the token '000000' should output as '0' or "000000" (string),
  but jsondump outputs as raw '000000'.

  because in huddle.tcl:455,

  > if {[string is double -strict $data]} {return $data}

  'string is double' returns 1, and the line returns raw.

  but I don't know to treat vague values strictly.

  current huddle classify only 'string' / 'list' / 'dict' only.

  for example, in jsondump, each token will be considered dynamically.

  comments?


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  by the way,

  according to http://yaml.org/spec/1.1/
  > Example 2.19. Integers
  > 
  > canonical: 12345
  > decimal: +12,345
  > sexagesimal: 3:25:45
  > octal: 014
  > hexadecimal: 0xC

  do you think, the integer 000000 is regal?


login: anonymous
username: Ryan Fox
mimetype: text/plain
icomment:
  The "string" values should be checked with this in ::huddle::jsondump in order to determine if they are valid numbers in JSON:

  [regexp {^-?(0|[1-9]\d*)(\.\d+)?([eE][+-]?\d+)?$} $data]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed and tested with:
   Widget::theme 1
   pack [Label .l -text ABC]
   .l configure -foreground yellow


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

  I see only one manpage reference, snitfaq. Agreed that this has to be fixed.
  All other uses I can find are in comments, and the ChangeLogs.
  Fixing the comments is of lesser priority.
  Still, when I come to snitfaq I can do them as well.
  I remember the places.
  I usually put them in when I have a 'eval/linsert etc. combo in the code and write in the comment the more readable 8.5 form.


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

  Fixed snitfaq manpage, and all uses inside of Tcl comments. Committed to CVS Head.


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

  There are no files attached to this item. Stupid SourceForge
  (There is a checkbox you have to check for upload. When you
  forget no attachment is created. And it is easy to forget).

  Please attach the necessary changes. The changes to tclvfs
  should be reported in the tclvfs project and not here.


login: ddrogahn
username: ddrogahn
mimetype: text/plain
icomment:
  File Added - 45940: ftp.patch

  Logged In: YES 
  user_id=676429

  I hope I wasnt that out of it to not check the checkbox, I 
  seem to recall the help next to the checkbox was the wrong 
  item (so maybe the checkbox was having issues too)

  Anyway... I've figured out diff a bit since then, so hopefully my 
  patch is a bit easier to work with.
  (and I'll check to see the file got uploaded this time)


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

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


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

  Using the CVS Head of Tcllib I am unable to reproduce this.
  I used Tcl 8.3.5.
  I also used tclsh together with vwait, instead of wish.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  I understand it doesn't happen under tclsh in 8.3.5
  but that's not the environment I have to support, which is
  wish 8.3.4.

  When I get a chance I can try upgrading to 8.3.5 but it won't
  be soon.


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

  I understand, however from my perspective it is a quite
  likely a bug in the tcl core tripping comm, seeing that
  8.3.4 does not work, yet 8.3.5 does, with comm unchanged
  between the two. And that is something which is difficult to
  impossible to work around.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  OK, thanks for investigating and explaining. I will try to 
  schedule time to attempt an upgrade to 8.3.5. In the 
  meantime I will have to install comm4.0 in parallel with
  comm4.2 and load that version explicitly when running under 
  8.3.4.


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289329: ctext.test

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.test


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289330: ctext.tcl

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.tcl


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

  I fixed this bug in the tcllib/tklib HEAD.  ctext is now at revision 3.2.  I used ctext::getAr and added 3 keys to the array used for storing information about ctext's per-widget state.

  So now this should all be handled by 3 catch {after cancel $configAr(...)}

  Please let me know if you experience further problems.

  Thank you for the unit test as well.  I'll have to see about getting that integrated.


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1573661
  Originator: YES

  Thank you for that bug fix.
  By the way, thank you for ctext !

  The suggested unit tests are the smallest possible amount of testing for the ctext package, that is : create/destroy. More tests (even if interactive) are available in the ctext_test*.tcl currently provided in the repository. Moreover, the tests are more testing the undo feature of the Tk text itself : this is because I discovered a bug in the Tk text, but I previously thought that it was a bug in ctext (I was wrong). The test ctext-1.2 is currently failing because of that bug (may be it is fixed in 8.5).

  I have one last question about the feature. Why exactly to delay the highlight after the insertion has been done ? Does that allow an improvment of the interactivity ? What kind of events may be to process between the insertion and the highlight ?


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Problem confirmed. Aslo confirmed that it does not appear for Tcl 8.5.
  First hypothesis that the ensemblification of the "namespace" command in8.6 may play a role.

  hephaistos:(506) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.5/Install/bin/tclsh8.5
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  0

  hephaistos:(507) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.6/Install/bin/tclsh8.6
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  1

  Side note for the curious.

      ./sak.tcl validate

  does not run the per-package testsuites per se, that is done by

      ./sak.tcl test run


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hah. The problem is the line immediately before, the 'namespace delete ::tcl'.
  In 8.6, with namespace ensemblified the implementations of the namespace methods are in that name, and deleted. At which point the namespace command is broken and gone.

  I think, I should not kill the ::tcl namespace in 8.6. It has started to contain necessary commands.


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

  Fixed.
  Committed: https://core.tcl.tk/tcllib/info/367195678d
  Pushed.

  Thank you for the report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm ... Oh! For Tcllib 1.15 I modified the "json::write" package to not quote "/" characters as "\/" anymore.
  While legal as per JSON syntax it is not really necessary.

  Compare {\"is\":\"/
  Versus  {\"is\":\"\\/

  This is "just" a case of the testsuite requiring an update. Not a bug in the package.
  And me forgetting to run the full testsuite after all the changes going into the release.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Good catch. The default loglevel wasn't propagated for the lowest level loggers.
  Fixed with 0.9.2 (in cvs).


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 266166: Registry

  Logged In: YES 
  user_id=302287
  Originator: YES

  Running it the first time succeeds, but does not add the shell, but it appears in the Registry file inside the home. Attached the Registry file.

  File Added: Registry


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

  Hm. The stacktrace seems to indicate that this is trouble in the 'tie' package, used within a sub-interpreter. This may be Tcl 8.5 specific too. May I ask to test this using a tclsh84 to get an additional datapoint?


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

  Running with tclsh8.4 to add tclsh8.5 fails like below, but i can add a 8.4 tclkit without problem. Trying to add with tclsh85 to run sak.tcl fails also, when adding 8.5, but not with 8.4.

  Trying to run 'sak.tcl test shells' gives the same stack trace with both 8.4 and 8.5 running the script.


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

  Hm. If you Linux, what about that platform?
  Well, that one I can test myself.


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

  Another point:
  It also fails on Solaris DevExpress (Opensolaris basically), Tcl 8.5 from cvs, tcllib head.


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

  Fixed. Duplicate of [1897850]. 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:
  Did you possibly mean 'Keywords should _not_ be always required' ?

  The error is indirect. In the multi-file modes (like when processing a directory) dtplite will generate TOC and INDEX pages, using doctoc and docidx formats. The docidx format doesn't allow an empty index, so, if no page has keywords this error is triggered. If even one of the pages to be processed has keywords nothing happens.

  If dtplite is ordered to process only a single page then neither TOC nor INDEX are made, so the problem cannot occur then either.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed in CVS head. doctools::idx now accepts an empty index (only index_begin and index_end keywords). dtplite will pick that up automatically when the new version of this package is installed.


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

  May I see the error message generated when you try
  to use the commands ?

  Both "lb" and "rb" are commands implemented in the
  textutil::expander package itself, simply returning
  [ and ]. The formats do not have to implement them
  by themselves.


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

  The message was something like "lb" not being available in
  this context. I will have to look up the exact message later
  on, but I was surprised by the text, it did include
  something to this effect.


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

  This is the exact message:
  ::mp cget: lb doesn't exist in this context
      while executing
  "::mp expand $text"
      (procedure "passes" line 8)
      invoked from within
  "passes"
      (procedure "main" line 6)
      invoked from within
  "main"
      (file "d:\tcl83\lib\tcllib1.2\doctools\mpexpand" line 
  286)


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

  Confirmed while reintegrating the new calculus
  code. This could take a bit longer. The HTML,
  TMML, and LaTeX formats do not complain. So
  there is a fundamental difference between these
  and NROFF.


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

  The message is a bit weird. It means that the 
  method 'cget'  was used to query the value of
  the variable 'lb'. The [lb] command (method Op_lb)
  uses the internal command 'Get' to query the
  variable, which does not! generate this message.

  I'll try to track where this is called.


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

  Ok, I know why the message is showing up, but not yet where 
  in NROFF this is caused. The problem is one of stacking 
  contexts. The expander pushes a context when invoked, 
  stores the chosen bracket information and restores the 
  outer brackets after the expansion. At last the context is 
  popped. These brackets have nothing directly to do with 
  [lb] [rb] commands as far as I can tell, we are talking 
  about storing/restoring the information used by the 
  expander to determine where macros start and end.

  In the case of nroff another context (mp) is pushed, but 
  never popped, causing the expander to access a context 
  which does not contain the lb/rb variables when trying to 
  restore the information of the outer invocation. So the
  problem is in the nroff format, but not in the [lb] command.

  The error message is simply misleading. See new tracker 
  item "[530056] Misleading error message in expander".


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

  The overall cause is that the doctools 
  command "manpage_end" is not used to
  close the manpage "calculus.man".

  I will now close this item as "invalid" as the
  problem is the manpage, and not doctools. See
  FR "[530059] Stricter check of incoming manpages"
  for a followup requesting better checks of the
  manpage structure and better error messages.


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

  What did the famous poet say? For want of a nail a shoe was
  lost ...
  Hm, I will add the finishing clause!


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

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

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


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

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


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

  Applied the suggested patch.
  Updated the testsuite of the module on my own.


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

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


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

  As far as I am aware "stats" is deprecated.
  Assigned to Brent for verification.

  A first step would be to remove the deprecated module
  from the installation commands in the makefile.

  A second step would be to remove the files and add a README
  refering the user to the other module. Or to remove the 
  directory completely. The SF cvs supports this.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  I don't think it's necessary to be quite so cautious with
  the deprecation and
  removal of the module.  Tcllib only just hit v1.0; I don't
  think we need to have quite the same rigorous procedures
  that the tcl core follows.  Just
  delete the deprecated module.  If you want to, add a
  "package ifneeded stats ..." to counter's pkgIndex.tcl, and
  maybe have it print out a warning
  on stderr that it's actually loading counter.  Let's try to
  keep tcllib nimble
  while we can.

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc.


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

  Perhaps a compatibility tool could be made available in a
  seperate directory.  If someone needed the stat they could
  install it and references to stat would create aliases to
  the counter classes.


login: welch
username: welch
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=89720

  We should delete stats.
  When I changed it from "stats" to "counter" I left the old
  module in
  for a transition period, but that has long since expired. 
  There are
  no current releases of TclHttpd that depend on stats
  anymore.


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

  Fixed the test: the failure was due to the changed default
  for tcl_precision.
  By explicitly setting the value, the previous behaviour has
  been restored 
  and the test succeeds. 

  Note: the original value for tcl_precision is restored at
  the end to ensure
  consistent behaviour for other tests.


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

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


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

  Accepted and committed the patch. I also added an "unset v"
  statement after the loop, as the variable is not really
  needed after the initialization.


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

  I made a fix to the dialog module and also to the pop3
  testsuite. This is in the head. Can you check if your
  problem still happens ?

  Note: The fixes I made were because the tests pop3-2.8 and
  pop3-5.0 were failing consistently on Solaris. Not on Linux.
  I never saw pop3-6.1 failing on solaris. And my failures
  were not dependent on running the whole tcllib testsuite,
  pop3 alone was sufficient. So, there are quite few
  differences. I am however not excluding that it is the same
  problem, just appearing in different places due to different
  system speed.

  In previous incarnations of the testsuite driver it was
  possible that a testsuite coming before pop3 forgot to kill
  a timer and it fired during the later test, smashing
  something. However in the current setup each module is
  tested using a new sub-process. So it should not be possible
  to leak stuff between modules. The only thing I can think
  off is timing differences between pop3 alone vs the whole
  testsuite.


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

  I can't repro the failure
  today, so either your changes
  fixed it, or it's not a real
  reproducible bug in the first
  place.


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

  Hm. Making it low-priority then. If a repro comes good,
  otherwise closing in a month or so.


login: 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: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 260432: patch.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

  I am attaching a patch and a tcltest to fix this issue.
  File Added: patch.diffs


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

  Patch accepted and applied to head. comm version bumped to 4.5.7.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed as proposed, committed to CVS head. Package version bumped to 1.0.3.
  One issue left: Can you provide us with a small snippet of code which demonstrates the failure ? I would really like to extend the testsuite as well, to catch this in the future.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you for the code.
  What is the input to this code, i.e. the values of salt, password, iterations
  where it fails ?


login: zdia
username: zdia
mimetype: text/plain
icomment:
  >What is the input to this code, i.e. the values of salt, password,iterations
  > where it fails ?

  Gorilla Password is working like this. Salt and the sha256 encoded password are saved in the database with the password.

  Access to the database is granted if  the password taken from a dialog box and encoded with sha256 and the saved salt equals to the db saved password.

  Because the saved 32bit (AS 8.5.8 on Linux) Xi result is not equal to a generated Xi on a 64 bit system (here: Mac Snow Leopard 10.6.2 compiled with 8.5 Tcl/TK Cocoa sources from Daniel Steffens github page) you have no access to the 32bit database.

  Standard iteration is 3000
  SALT is a 256 bit random value
  The password is an integer string like "mypassword"

  After iteration 16 there will be different Xi values.

  Example for the salt:

  pwsafe::int::randomString 15
  proc pwsafe::int::randomString {length} {
      set randomOctets [list]
      
  for {set i 0} {$i < $length} {incr i} {
      lappend randomOctets [expr {127-int(rand()*256.)}]
  }
      }
      return [binary format c* $randomOctets]
  }

  I would be thankful If you could give me a hint on how to check in a script if the system is working on 64bit system

  Regards

  Zbigniew Diaczyszyn


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


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

  The command is "::fileutil::magic::mimetype", as the name of the package. It is possible that in the interactive mode the auto-loader part of the tclsh helps and expands unique abbreviations of command names to the correct command. And "::fileutil::magic::mime" certainly is a unique abbreviation of the correct name. This type of help however is not active when executing a regular script, i.e. non-interactive.


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

  I have checked this and it works :) Thank you for assistance. I will mention this on ActiveState, their documentation seems to be misleading


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

  ActiveState's ActiveTcl pulls the documentation of Tcllib straight form the source. The only thing it does is to convert to HTML. I should know, I am the person doing the building. As such this is more likely a bug in Tcllib's documentation. I will check.


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

  Yes. This was a bug in Tcllib's documentation of fileutil::magic::mimetype (and fileutil::magic::filetype as well). This has been fixed now, and committed to the head.


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

  References
     http://python.sourceforge.net/peps/pep-0282.html
     http://www.red-dove.com/python_logging.html


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

  Bah. Nothing weird about it. It is essentially just a debug command left active in the math-12.1 test case.
  Committed: http://core.tcl.tk/tcllib/info/77088c0306
  Pushed.


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

  Oops, didn't I close this when I committed the change?

  Thanks again for the patch!


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

  It is fileutil::find which has the problem, not
  findByPattern. findByPattern is implemented in terms of 'find'.

  'find' calls itself recursively for all directories it finds
  in the base directory, making the subdirectory the new base
  directory.

  Looking at the code of 'find' it further seems to me that
  the 'glob' command is listing 'sys' deeply somewhere under
  c:\, 'file isfile' claims that it is not a file, but 'file
  isdirectory' claims that it is a directory. In complete
  contrast to the error message returned by 'cd'.

  The only time I have remotely similar behaviour, i.e.
  completely conflicting information from the various
  subcommands of the 'file' command, 'cd', 'glob', and the
  like was for a system file, in my case 'page.sys'.

  Given the name of the directory my guess is that this is a
  special directory of Windows which looks like a directory,
  behaves like directory, and yet is not a directory, not even
  there. To regular file/dir commands.

  My plan for fixing this is to add a catch around the 'cd
  $basedir' which errors out, and to ignore the
  pseudo-directory. In other words, neither sys, nor anything
  inside of it would show up in the out of 'find',
  'findByPattern', ever.

  One thing might wish to try in the interim is to locate this
  'sys' directory by conventional means, i.e. MS Explorer, and
  then to run various file related commands of Tcl on it, like
  'file exists', 'file isdir', 'file attributes', 'glob',
  'cd', etc.


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

  The only other thing I can think of is that the permissions
  of the directory prevent you from entering it. The error
  message however is evidence against that. Still, I cannot
  exclude this, i.e. maybe the error message given by Windows
  is wrong.

  Well, I just tried this on Linux with a directory I made
  inaccessible (chmod -x). And an attempt to cd into that
  directory, in tclsh, returned the message "file or directory
  does not exist", but 'file isdir' and 'file isfile' returned
  the proper information. This is an indicator that
  permissions can be the problem as well. ... And 'find'
  errors out in the same manner as demonstrated.

  This would however not change the fix. The unix 'find'
  command ignores inaccessible directories, and we can do the
  same.


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

  Small correction: The 'sys' directory itself will appear in
  the output of 'find', and of 'findByPatttern', if matching
  the pattern. Files and directories under 'sys' will not.


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

  Looking over the other bugs I find that this one is actually
  a duplicate of
  http://sourceforge.net/support/tracker.php?aid=862491

  See there for more discussion which was had on the Tcler's chat.
  I have decided to fix this with a catch, ignoring any
  problematic directories. I will also file an RFE asking for
  an API change which allows us to set an error handler, to be
  called for the problematic directories.


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  As reported by Helmut both in private mail and on c.l.t., the bug was in his code, not in Tablelist.  The widget .__helpLabel, created by Tablelist, was destroyed by his script.


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

  The tests check these branches. The if branches seem  to not
  trigger correctly and the value is formatted by the next
  larger range with the wrong extra padding.

      if {($number >= -8388608) && ($number < 8388608)} {
          set numberb [expr {$number & 0xFFFF}]
          set numbera [expr {($number >> 16) & 0xFF}]
          return [binary format H2H2cS $tag 03 $numbera $numberb]
      }
      if {($number >= -2147483648) && ($number < 2147483648)} {
          return [binary format H2H2I $tag 04 $number]
      }
      if {($number >= -549755813888) && ($number <
  549755813888)}     {
          set numberb [expr {$number & 0xFFFFFFFF}]
          set numbera [expr {($number >> 32) & 0xFF}]
          return [binary format H2H2cI $tag 05 $numbera $numberb]
      }

  This is entirely strange..., kann someone please check that
  if is sane on solaris..., basically this check fails:
   
      set number 8388608
      if {($number >= -2147483648) && ($number < 2147483648)} {
             puts "ok"
      } else {
            puts "bad"
      }

  I do not have a solaris box to test on...


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


  Thanks for looking into it.  The
  bug is in Tcl 8.5a4, now reported
  as 1274287.  You'll want to keep
  an eye on it.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  if the object being sent doesn't end in \r\n, then the code in question 
  will fail. however, the patch you propose will append a newline to 
  well-formed messages. what, exactly, are you providing as the 
  argument to the smtp::sendmessage function? 


login: col_ford
username: col_ford
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=891419

  Below is the tcl that I'm am using to contstruct the
  message. It tries to construct a message with a body and
  four attachments - the last being a binary file.

  set body_mime[ mime::initialize  -canonical text/plain
  -param [ list charset us-ascii ] -encoding 7bit -string $body ]

  set log_mime [ mime::initialize -canonical text/plain -file
  $log_file -header [ list Content-Disposition inline ] -param
  [ list name $log_file_d ] -param [ list filename $log_file_d
  ] -encoding 7bit ]

  set yuma_mime [ mime::initialize -canonical text/plain -file
  $yuma_file -header [ list Content-Disposition inline ]
  -param [ list name $yuma_file_d ] -param [ list filename
  $yuma_file_d ] -encoding 7bit ]

  set ephem_mime[ mime::initialize -canonical text/plain
  -file $eph_file -header [ list Content-Disposition inline ]
  -param [ list name $eph_file_d ] -param [ list filename
  $eph_file_d ] -encoding 7bit ]

  set data_mime[ mime::initialize -canonical
  application/octet-stream -file "$OUT_FILE_NAME"  -header [
  list Content-Disposition attachment ] -param [ list name
  $scn_file ] -param [ list filename $scn_file ] -encoding
  base64 ]

  set multiT [ mime::initialize -canonical multipart/mixed
  -parts [ list $body_mime $log_mime $yuma_mime $ephem_mime
  $data_mime ]]

  smtp::sendmessage $multiT \
  -header [ list From $ADMIN_EMAIL ] \
  -header [ list To $XML_DATA(email) ] \
  -header [ list Subject $SUBJECT_EMAIL ] \
  -servers $SMTP_SERVER


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

  The problem shows up when you send a very short text mail using
   set tok [mime::initialize -canonical text/plain -string "body"]
   smtp::sendmail -server localhost $tok \
     -header {From root} -header {To root} -header {Subject
  testing}
  On unix systems with a tls capable sendmail this hangs up
  waiting for the SMTP data termination sequence (CRLF.CRLF)
  I've applied a patch that fixes the problem only for mail
  bodies that do not already have a terminating LF. The
  problem does not show up when Trf is used to process the
  body data.


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

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


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

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

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


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

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

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


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

  Still got that error with v 1.263:

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

  As for Miguel, otherwise tkchat works as normal.


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

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


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

  report no longer valid.

  FAQs moved from the tcllib
  project to the tcl project, it seems.


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

  The FAQ is now in thc Tcl project. closing as outdated. Don 
  created a new report there.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The proposal is to add:
      $path.e selection range 0 end
  after
      $path.e selection clear
  within function ComboBox::_select of file combobox.tcl.

  IMHO it is included in BWidget release 1.8 and in the current cvs.

  Please see the following patch reference where tests was made.
  (I did not test anything now)

  https://sourceforge.net/tracker/?func=detail&aid=981545&group_id=12883&atid=312883

  Is the parameter -exportselection 0 sufficient for you ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  After this E-Mail from Erik Leunissen:
  The lines commented out in the above snippet are the changes proposed by
  patch 981545. They do exactly as I propose in a user-configurable
  manner. Just tested with [ComboBox -exportselection 0].

  I definitely support patch 981545.

  Oh, and personally I'd prefer the default value for -exportselection to
  be "0". Maybe that this is a matter of taste ...
  -END-

  patch 981545 was commited to cvs.

  Thank you,
  Harald


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

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


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

  Good or bad is of course a matter of taste.

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

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

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

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

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


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

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

  I'll have to think more about this.


login: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  a) Visual representation:
  A line from the top of the tree widget window downwards to the first node was removed with the following log entry:

  2004-04-21  Jeff Hobbs  <jeffh@ActiveState.com>
      * tree.tcl (_draw_subnodes): Adjust the drawing of the line to the
      first root node to start at the vertical point (not go up). 

  Jeff explained further by E-Mail:
  The reason I made that change was to be visually compatible with Windows (older style, as new style is no lines) when you actually have sub-nodes (the [+] and [-] indicators).  The line to the top is then inconsistent with the way others draw.
  You could try and make that check contingent on whether subnodes exist, but I think that may seem odd. 

  b) tree -helpcmd patch
  Patch is ok, integrated in cvs, command added to docs.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Koen answered on tcl-devel:

  Ok, I already thought that the Windows style you were referring to always had exactly one top node, which is not the case for BWidget (where the real "root" node is actually invisible).

  I propose to make the line dependent on whether there are multiple top nodes. (Harald, the patch for that is below.) It seems we could agree on that, and I prefer it to an extra option (= extra documentation, which will probably difficult to understand without trying out.)

  --Koen


  Index: tree.tcl
  ===================================================================
  RCS file: /cvsroot/tcllib/bwidget/tree.tcl,v
  retrieving revision 1.59
  diff -b -u -r1.59 tree.tcl
  --- tree.tcl30 Jun 2009 16:17:37 -00001.59
  +++ tree.tcl24 Jul 2009 13:26:22 -0000
  @@ -1369,12 +1369,9 @@
           set yp $y1
           set y1 [_draw_node $path $node $x0 [expr {$y1+$deltay}] $deltax $deltay $padx $showlines]
       }
  -    if { $showlines && [llength $nodes] } {
  -if {$y0 < 0} {
  -    # Adjust the drawing of the line to the first root node
  -    # to start at the vertical point (not go up).
  -    incr y0 $deltay
  -}
  +    # Only draw a line to the virtual root node when there are multiple top nodes.
  +    set len [llength $nodes]
  +    if { $showlines && $len && !($y0 < 0 && $len < 2) } {
           set id [$path.c create line $x0 $y0 $x0 [expr {$yp+$deltay}] \
                       -fill    [Widget::getoption $path -linesfill]   \
                       -stipple [Widget::getoption $path -linestipple] \
  ---

  Jeff answered: Agreed.

  ---

  The upper patch is applied and committed.

  Thanks to all.


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

  One possible fix: Add '-disabledforeground' to the tkinclude
  'remove' list
  in entry.tcl:

      Widget::tkinclude Entry entry :cmd \
              remove [list -state -cursor -foreground
  -textvariable -disabledforeground]

  This avoids the problem under Tk 8.4, and is a no-op under
  earlier Tk versions.

  Probably not an ideal fix -- does anyone have any better
  ideas?

  Is it OK if I commit this change?


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2460

  jenglish asked
  > Probably not an ideal fix -- does anyone have any better
  > ideas?

  Not necessarily better, but I submitted a patch last year
  that fixes the problem. 

  See [ #402776 ] BWidget: support for Tk8.4 entry -state.


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


  Re: patch [ #402776 ] BWidget: support for Tk8.4 entry
  -state --

  am taking a closer look.  One issue: it changes the
  behaviour of the '-disabled'
  state (a -disabled  BWidget::Entry can be programmatically
  modified, 
  whereas a -disabled Tk::entry cannot; I've backed that part
  of the patch out.)


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

  OK, this has been fixed now.
  Files changed:
  entry.tcl : r1.14 -> r1.15
  Tested under Tk 8.3 and Tk 8.4


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

  OK. Simpler is to give -maxlen 0 to the base64::encode
  command to turn off the wrapping functionality.

  I'm not going to do this to DIGEST-MD5 unless there are
  reports of similar problems.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed in cvs by hard-coding a 0 padx value.
  I don't know why this happens but anyway, why are the other values hard-coded here?


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hello valli, thank you for your report.

  Is it possible for you to attach a snippet of Tcl code which demonstrates the problem ?
  Right now I am not fully clear on what you are doing, making it it difficult to reproduce what you are seeing.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  I replaced the aclocal.m4 file with tcl.m4 from the former config module, so
  the config directory is not requird.  This is not the best solution probably, but it will do for now.  A better solution would be to figure out how to make
  all the Tcl packages on SF reference the config module, just as they did
  when they all lived at Scriptics CVS.

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


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

  Hm. In my setup I get errors for 'touch',
  but not for 'find'. The touch thing might
  be a linux issue.

  In which directory did you execute 'configure' and 
  then 'make test' ? I usually create a build directory
  outside of tcllib and configure and test from there.


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

  Ok, I get the same errors for find when I configure and 
  test from the top directory of tcllib. So the tests as 
  written are much to dependent on the actual contents of the 
  tcllib directory, thus thrown off by (m)any changes, like 
  new modules, examples, whatever.

  Oh, the touch errors are still there so my belief that this 
  is linux dependent is even stronger.


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

  This should end up in the console now and not pollute the
  starting terminal. On linux /dev/null is ok - there is a
  warning but that is all.


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

  Hm. There are a number of packages which can use tcllibc,
  and IIRC none of them look for and use an installed critcl
  to compile the acceleration codes dynamically.

  Yes, extending the installer should be possible, to have it
  look for critcl, and build tcllibc if it is present. That
  should alleviate most concerns I think. Otherwise we have go
  deeper into the code of all the packages loading their
  various accelerators and have it check for critcl alone as well.

  The other stuff are documentation issues I will address
  after we have consensus regarding tcllibc/critcl. I have
  notified Pat Thoyts directly, as he wrote most of the
  packages using critcl in general, and uuid in particular.


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

  The current ldap TLS code just uses a different port and
  wraps the connection into TLS. A different solution would be
  to do the ldap starttls handshake to setup a TLS connection.
  Its not hard to do and i have it nearly done.


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

  I'll submit an updated ldap.tcl (version 1.6), which
  supports StartTLS. Not sure if that does a graceful fallback
  yet, but should improve things.


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

  Added the new starttls code to the ldap module, which allows
  to upgrade a standard connection to TLS secured.

  As the LDAP RFC is more critical about validating TLS
  connections an automatic fallback to unencrypted is not a
  good idea. 

  Please have a look at the current code in CVS, I'll set the
  status to Pending, so it gets closed if there is no response.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  The results of an ldap search are not autoconverted, because they might be binary data and not utf-8 encoded, for example jpegPhoto attributes or similar things.

  Please check if you get the correct result if you apply [encoding convertfrom utf-8 $data] to the results you get. If that is the case this is the expected behaviour, if not its really a bug.

  The ldapx package has some helpers to do this automatically, see the documentation at:
  http://tcllib.sourceforge.net/doc/ldapx.html especially the -utf8 option.


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

  Thanks for your support. I could not understand it but the fix does work for me (using encoding convertfrom utf-8).

  Reason I could not understand it: I used to code in php and from there the data obtained from ldap search is UTF-8. I especially don't know what sense it make to convert from utf-8 when current locale is utf-8, which means converting from utf-8 to utf-8 solves the problem! But anyway thanks for quick respons, two days later we have big problem delaying the business.


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

  The HTML Standard 4.01 does not support <list name="List1"
  />, this is XHTML Syntax and for XHTML one is better off
  using a true XML Parser like TclXML or tDOM.

  Empty tags do not have closing tags, so it is correct if no
  closing tag appears in the result list.

  Fixing the class code looks like the wrong thing to do, it's
  2TreeCallback that needs fixes, the tree generation.

  As <list> isn't a valid html tag it should be ignored by
  2Tree anyway.

  If you did it with <li /> and it breaks, thats an other matter.


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

  See:
  http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines
  C.3 for the suggestion of W3C regarding empty elements with
  non empty content model.


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

  I got another report about this, see 

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

  This one came with code. It changed the empty tag into a
  single closing tag. Which I considered wrong. However based
  on that I was able to create something which transforms an
  empty tag into a pair of opening and closing tag in the
  event sequence. I.e. something like

      <a href="foo"/>

  would be handled as if the input had been

      <a href="foo"></a>

  This is IMHO the most sensible approach to real-world data
  using empty tags.

  Committed my changes to head, see the other report for details.


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

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


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

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


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

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

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


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

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


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Yes, this needs fixing - for the moment you can set the left margin for 
  the xy-plots via:

  plotconfig xyplot margin left $width_in_pixels


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Oops, try:

  plotconfig xyplot margin bottom $height_in_pixels

  The plotconfig command sets configuration options for the class of plots.
  So all subsequent XY-plots use that option.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Hm, I will definitely have to solve this one by querying the font metrics instead of 
  assuming some size.


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

  See http://www.purl.org/net/akupries/soft/pool/ for 
  transferable functionality.


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

  A calendar module has been opened up for holding this functionality.


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

  Ok, I have some procs already that I have been working on.
  Should everything fall under the calendar namespace, or
  should it be separated out into calendar/date/time? I don't
  care either way. If I want to submit my procs, how do I do that?


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

  Excluded from official distribution per maintainers of the 
  module.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I think, this is fixed, does not happen for me on windows.
  Report, if this is not the case.

  Thank you,
  Harald


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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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


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

  Ooops, there is TclMagick already!

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


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

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


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

  Very bizar when I change the line to 

      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 1]
  OR !!!! (it does not matter???)
      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 0]

  Both work FAST ??? (Via Solaris tcl_patchLevel  8.4.5)


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

  Personally, I do not find this too funky at all. In fact, I'm inclined to go one step further and change the default for this option (-exportselection) into 0. 

  The documentation for this option says:
  "The default is usually for widgets to export selections." (meaning the X-selection)

  I question this statement. I haven't seen many applications that show this default behaviour. (Maybe it is a Unix tradition.)

  A combobox is primarily about selecting an item from a collection of items. This is unrelated to selecting a sequence of characters for a copy/paste operation, and we ought not confuse/mix these two different concepts. If users do want to set the X-selection too, they may choose to change the default.


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

  Not my department.  Damon?

  FWIW: On X11, Gtk+ and Qt editable comboboxes do export the selection; ditto spinboxes and entry fields.  The only major toolkit I've encountered that doesn't do this is the one Mozilla-family tools use; there, entry fields appear to use a hybrid X11-style global primary selection combined with Windows-style independent selection (which I personally find very confusing.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The patch seams reasonable to me too.
  Nevertheless, I have checked the behaviour on windows and linux with and without patch. It works fine for both cases.
  #- test script -
  pack [ComboBock .c]
  pack[ComboBox .n -exportselection 0]
  # set a selection in both using the mouse
  .c configure -exportselection 0

  In the first case, the selection is exported and removed if there is somewhere else a selection
  In the second case, the selection is local and not exported to other windows.

  I decided not to apply the patch.
  Please notify, if the patch helps anybody, no issue to put it in neither.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thanky to Eric, I have got the point.
  One requires values to test it.
  Revised test script:
  -----
  pack [ComboBox .c -values {1 2 3}]
  pack [ComboBox .n -exportselection 0 -values {1 2 3}]
  -----
  When clicking on an item in the drop-down box, the result gets selected in the first case. In the second, it does not and the cursor is placed behind the entry.

  A matter of taste. Please post, if you like it or not.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. I have started looking into this.

  Can you give me the exact unicode code point you used for theweird chars, i.e. in \uXXXX notation, where XXXX is a 4-digit hex-value ?

  They don't seem to have survived the copying out of the bug report. (Which is another reason we ask that such things (scripts, input files, result files), are attached to the report, the chances of getting it back unmangled are significantly better.

  Running with Tcl 8.5.7 I also get an error back for the last example, however the location is two characters further in (12 instead of 10), and a different set of symbols is expected. Alternatively this might be because I used the PEG interpreter instead of converting the PEG into a hardwired snit-based parser.

  I will now compare to a snit parser and also try to thin the PEG, i.e. remove parts not needed for the example. As part of figuring my way through it.


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

  Ok. It was me misunderstanding the quoting rules of Tcl for a moment.
  Look at the following 4 commands, and their output (after running), and you should be able to see the problem and fix:

  (1)    #puts {Structure='}'}
  (2)    puts {Structure='{}'}
  (3)    puts {Structure='\}'}
  (4)    puts {Structure='\{\}'}
  (5)    puts "Structure='\}'"

  The first one you already know, and I explained why it is wrong. The second one fixes the issue, by balancing the nested braces. If that always happens in your case you are now fine. If you allow for unbalanced braces I said to use (3) in my post to comp.lang.tcl. I was wrong. The \ before } protects the Tcl parser from miscounting, true.

  What I thought was that it would also collapse the \} sequence into a single } internally. It doesn't, and re-reading rule [6] the Tcl interpreter is right, and me wrong.

  So your parser sees \} and that is a bad backslash sequence per your grammar, and so it bails out with an error.

  Item (4) in the list is the same as (3).
  Item (5) shows the proper quoting. Use "...", and the \} is indeed collapsed into a single }, which your parser then accepts. "..." quoting does backslash substitution. {...} doesn't. My fault.

  Note that all of this applies _only_ to the parsing of examples you specify directly in Tcl code. If you read your input from a file into a Tcl variable then all this quoting of braces is not necessary at all.

  Final conclusions:
  * ParseTools work correctly.
  * Your parser works.
  * My advice on comp.lang.tcl was faulty. And later in the evening I will post a correction there as well.

  Closing this no as 'invalid' == 'no bug' (except in my brain).


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

  Applied. Parts of jabberlib require 8.4 so there is no going
  back to 8.3 support now.


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

  Yes. I'm seeing this too -- on FreeBSD-6.0/amd64. Please, 
  advise. 


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

  I think, I found a fix. For some reason, attachments seem  
  disabled on this page, so here is the patch inline (be careful  
  of the white-space mangling):  
    
  --- modules/dns/ipMore.tcl      Fri Sep 30 14:03:58 2005  
  +++ modules/dns/ipMore.tcl      Tue Oct 18 01:15:38 2005  
  @@ -400,8 +400,9 @@  
   proc ::ip::maskToInt {mask} {  
       if {[string is integer -strict $mask]} {  
  -        set maskInt [expr {(0xFFFFFFFF << (32 - $mask)) &  
  0xFFFFFFFF}]  
  +        set maskInt [expr {(0xFFFFFFFF << (32 - $mask))}]  
       } else {  
           binary scan [Normalize4 $mask] I maskInt  
       }  
  +    set maskInt [expr $maskInt & 0xFFFFFFFF]  
       return [expr wide([format "0x%08x" $maskInt])]  
   }  
   
  This seems to work for me... 


login: aakhter
username: aakhter
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=736414

  The bug is currently assigned to me, but I don't have a 64 bit 
  system to work on this. Do I have write access to CVS to 
  commit this fix?


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

  Aamer, I have a 64bit system (linux/amd64) and have verified
  the patch as well. I will commit it in a few minutes,
  currently doing the admin work for it.

  Beyond that, yes, you do have write access to the Tcllib CVS
  at SF. It enabled that at the time I added you as a developer.


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

  Committed to CVS head. Only one change to the patch: The
  masking expression got braced.


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

  If only you did a PRE-release testing on a single 64-bit 
  platform :-( 


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

  Dude, I did plenty of pre-release
  testing, but you sneaked this module
  in just days before release, missing
  all the testing that was done.

  The closer to the deadline you make
  code changes, the less testing you
  can reasonably expect them to get.


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

  A question, how are you running ispell ? From an editor, or batch mode like from a terminal. If the latter, what is the invokation ? Also, are you using special options to make sure that you get american-english, vs british-english, etc. ?

  (Background: I am thinkingabout how useful it would be to run ispell from sak.tcl, maybe with a special dictionary to accept tcl commands and doctools stuff, and then we can run it over all files, code (for comments), and documentation).


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

  I just run it from the command line , using either
  ispell
  or, if checking html, using
  ispell -h

  I've thought about creating a tcl specific spelling dictionary, but haven't messed with it recently.


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

  The canonical method for deleting a tree 'myTree' is

      myTree destroy

  Note: All the object-based structures in tcllib/struct have
  a 'destroy' method for the destruction of an existing
  object. ... Checking ... No, 'record' doesn't have it. But
  all others do.

  There is no need for the proposed command.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I am unable to confirm this. Using a self-build Tcl 8.5.11 with memory debugging (--enable-symbols=all) and the attached modified test script I see the current and maximum allocations rock solid at their values, without any increase.

  I tried this with pure-Tcl md5crypt, and md5crypt accelerated via tcllibc. The latter I ran to the full million, the former only to 1000 rounds, gives that it is much slower.

  Output after completions:
  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *
  1009:   m703050 834514^C

  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *       /home/aku/Projects/Tcllib/0.Releases/1.14/Base/modules/tcllibc/linux-x86_64/tcllibc.so Tcllibc
  999999: m683191 750032


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

  I'll keep this open and assigned to me until I've finished
  the SASL mechanisms I want to support. (Which won't take
  long -- they just need testing.)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Deleted - 80424: 



  File Added - 80518: smtp-auth.patch

  Logged In: YES 
  user_id=202636

  OK tested CRAM-MD5, PLAIN and LOGIN against Sendmail and
  Microsoft SMTPd

  Committed.


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

  This looks pretty good. First some performance comments
  - All [expr] expressions should be braced - [expr {....}]
  - Avoid excessive [expr] eg: if {[expr ...]} is better
  written if {(...)}
  - You can copy arrays quickly using [array set tempState
  [array get state]]
  - The inverse sbox function is twice as fast if we use a
  table lookup.

  by making the above changed changes can speed the encryption
  from about 26000ms per iteration to around 8000ms per iteration.

  Second I would think the programming API should be closer to
  that used for rc4 and blowfish in tcllib. I would rather see
  an aes::encrypt and aes::decrypt pair - but more importantly
  I think we should be able to do:
   set key [aes::Init $secret cbc]
   while {receiving data} {Output [aes::Encrypt $key $data]}
   aes::Finish $key
  in other words maintain all state in a opaque token that is
  created by Init and cleaned up by Finish and permit calling
  Encrypt or Decrypt multiple times. This fits well with use
  with network channels where we want to use the
  Encrypt/Decrypt call in the fileevent body on chunks of data
  read from the stream.

  It is also important that we can do ECB and CBC mode
  encryption - it's not specified anywhere what mode is being
  done here and I've not tried to work it out yet.

  Attaching my performance enhanced version.

  Nice job though. :)


login: fattobi
username: fattobi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1333726

  Thanks for the quick response and performance improvements.

  At the moment, there is no chaining of blocks implemented,
  just one block gets en-/decrypted.
  I will work on the API, but don't expect it done too soon.

  Thanks for your help,

  Thorsten


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

  Imported into CVS so that we can properly maintain the
  history of this code. I will try and fix the programming
  interface before we release the next version of tcllib.
  Fixing the API should also make supporting CBC mode simpler.
  New module: aes


login: 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: 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: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 194111: installer.tcl

  Logged In: YES 
  user_id=302287

  Diff adding an error dialog attached. Please review.


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

  A quick look seems to be ok, only a nit: [catch {}] == 1 can
  be shortened to [catch {...}] I do not thank that we care
  about break, continue, etc. Will have a closer look when I
  ma home, i.e. patch and look at the whole context.


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

  Accepted with very small changes yesterday, committed this
  morning. The nit, and slighty different formatting.


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

  After considerable though, it turns out that this isn't delegation at all, but 
  propagation.  The difference is that in delegation the option's value is 
  owned by a component; in propagation, the option's value rightfully 
  belongs to the megawidget, while 1 or more components are constrained 
  to have their options set to the same value as the component's option.

  The best way to handle this at present is through a snit::macro.


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

  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: aku
mimetype: text/plain
icomment:
  I have no idea about the intent of the package author here, and have to defer to him. Re-assigning the bug to the author.


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

  Ditto for the applications 'nns' and 'nnslog'.
  Fix for all committed to head.


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

  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: 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: 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:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Committed a fix to the CVS head. Package version 0.6.1.


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

  bug 1 was fixed on 4/2/05 i suggest upgrading to the latest 
  version before submitting a bug report. I will look into #2


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  You can still use the environment variable TCLTEST_OPTIONS to provide additional settings to tcltest ...

  TCLTEST_OPTIONS='-file math.test' ./sak.tcl ... might work.

  An alternate solution would be to put the block 142-280 into a procedure, and call this procedure in "testNeedsTcltest" after we have established the tcltest package ... Oh, and lines 315-372 as well.


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

  Moved the tcltest
  compatibility initialization into a procedure (InitializeTcltest)
  which is called by testNeedsTcltest and a few other places to be
  done only after we are sure that the tcltest package is present.


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

  Fixed in CVS head on Friday Oct 7 after reported by Mikhail
  Teterin, a FreeBSD maintainer. He has the fix as patch as
  well, to be put into the ports build system.


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

  Thanks.

  I had the changes to pop3 ready (deery's items) by 
  yesterday evening and will commit these first (I had fixed 
  the pkgIndex.tcl as part of the changes, but not the docs) 
  and then apply yours, after suitable merging ...


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

  fixed in 1.5 - -repeatdelay and -repeatinterval are now core 
  options to the button, so they have to be "removed" in the 
  BWidgets sense.


login: szinck
username: szinck
mimetype: text/plain
icomment:
  Hi Russell, I had the same issue as you on the second bug you mentioned.  If the connection is closed before the last line of a multi-line reply is sent, the ftp client will hang.  I couldn't attach a file, otherwise I would've just added it to this bug.  I created a new bug #3288977 and attached a patch.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Shaun's patch has been committed to CVS Head, package version bumped to 2.4.10.

  Russel, you might wish to recheck your problem. If it persists I would like to get a patch/sources for the fix, taking Shaun's changes into account.


login: aku
mimetype: text/plain
icomment:
  This looks to be fixed for quite some time now, with no feedback from the original submitter regarding the veracity of the fix. Closing as fixed.


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

  This has nothing to do with Tcl and everything to do with the 
  changes to md5 v2 where Trf isn't used by default.


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

  The quick solution to this problem is to require md5 1 which
  provides the same support as previous tcllib distributions.
  Version 2 has a different API and is more akin to the C API
  provided by OpenSSL and the RFC reference implementation.
  This allows for incremental updates to the hash, for example:
    set hash [md5::MD5Init]
     while {$accessing_data_in_chunks} {
        md5::MD5Update $hash $data
     }
     set result [md5::MD5Final $hash]

  Unfortunately a bug in Trf means that it can't be coerced
  into performing this way (at least not when I last checked
  this). There is a critcl based implementation but this isn't
  created by the current installation procedure.

  Needs sorting out. You can create a compiled module with
     cd src/tcllib
     ./sak.tcl critcl md5c
  and then copy the modules/md5c dirctory into your installed
  tcllib1.5 tree.


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

  This looks reasonable to me.

  Files changed: mainframe.tcl : r1.8 -> r1.9


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Patch Code - Modified - New Version

  Also added synonym "-bg" for -background (required by ComboBox mega-widget)


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

  To what combobox do you refer? tcllib doesn't have one, and the only thing in tklib that I see with a combobox is tablelist.

  $ tclsh
  % package require tablelist
  4.6
  % ComboBox .cb -values {a b c a b c}
  invalid command "ComboBox"
  %

  Give us info on what version of tcl and tk and what combobox you are using.


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

  According to the category the bwidget one. bwidget is in this project.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  Sorry, thought, the category would be enough, but ... I missed the BWidget version I use.

  I tried this behaviour with the BWidget version 1.7 and the most current one I know 1.8.

  Hope this helps!

  Martin


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Martin,
  thank you for the report.
  The issue is fixed in current cvs by adding a variable holding the last set index.

  This also solves the issue:
  % .cb setvalue 5
  % .cb getvalue
  2


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

  I should clarify that the issue is the inclusion of the -
  disabled* options that do not exist in 8.3.


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

  There is no -disabledforeground/background in 8.3 entry 
  widgets, yet the code tries to declare them as TkResource 
  items.


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

  Damon, I have seen the latest checkin and played with it.
  The demo now comes up for 8.3 and 8.4. However under 8.4.,
  and only 8.4!, the selection of an item in the list of a
  combobox using the mouse still does not work. It however
  does work for 8.3. So there may be a Tk 8.3/8.4 difference
  in play for that bug too.


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  Mine tests fine.  I only recently started testing in 8.3, so
  I know that 8.4 works, or I wouldn't have committed the
  code.  Hrmmm...  I don't know what could be happening on
  your end.


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

  this appears to have been a quirk in Andreas' 8.4.  Works in 
  the 8.4 head.


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

  Haven't we fixed that in the head ?
  Yes, in April 2005 according to the ChangeLog.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  * tree.tcl: Corrected keyboard navigation so that open/close
  commands are invoked when right/left arrows are used to
  open/close
  nodes, patch from [Bug #435097].  Also corrected keyboard
  navigation on right arrow press; previously only opened
  closed
  nodes that had children, but should always open nodes,
  regardless
  of whether it has children.


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  This has been fixed in "pki" version 0.2, which was committed to tcllib a few days ago.

  I initially took the same approach as you before I noticed [asn::asnGetString].


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Side note: The files section contains "release candidate 0" of a 1.14 Tcllib release. This contains pki 0.2. In other words, testing is possible without going through CVS.


mimetype: text/plain
icomment:
  Tested the release candidate version, it works fine with ::asn::asnGetString instead of going through the switch I mentioned.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  The two constants '0' and '1' have been defined in each
  high-level proc.
  The test suite was improved with new tests, including tests
  not devoted to this evolution. (division, modulo, remainder...)

  A hook (_treat) was created to handle the constants :
     _treat var ?var ...?

  Replace each variable named 'var' by the internal
  representation if it is equal to one of the constants : '0'
  or '1'. If the variable is already in internal repr, nothing
  is done.

  Please close this feature request, or tell the issues, if
  they are some.


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

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

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


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=295103

  Forgot to mention - this bug report is for version 1.2 of
  widget::dialog. Tcl/Tk 8.4.12 on Windows XP


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

  Checked the logger stuff, thats just an outdated procheck not knowing the new trace syntax.

  As a side node, there is a sak.tcl command in the cvs version of tcllib to run procheck/frink/nagelfar on the tcllib code, so you don't need your own runner.

  sak.tcl validate


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

  spf - bug, fixed
  term - bug, fixed
  grammar_fa/fa_op - bug, fixed
  nns/nns_auto - fixed (a few days ago, without ref to this bug)
  transfer/copyops - ditto
  math/elliptic - ditto
  tiff/tiff - ditto

  Lots of messages are new tcl 8.5 syntax and functions the procheck used did not understand.
  Keeping open for the moment until I can run the last tclchecker over it.

  I like Erik's runner however, as it summarizes in the main output (.out) instead of blowing your mind with thousands of lines of messages.
  I am currently reworking the 'sak validate' code to do the same, like I did for 'sak test run' before.


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

  For 8.4 I have an epxlanation for the error: The [binary scan] 
  in unixtime fails, thus the variable "r" is not set, and thus 
  does not exist later on. More logging shows that there is no 
  data to scan, the field is empty. The reason for that is not yet 
  known.

  I have added code to throw an error if the scan fails.


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

  The 8.3.4 failures are actually tcltest 1.0.2 failures. The 
  variable tcltest::interpreter was added later. The 8.4 was ok, 
  because it had tcltest 2.2.x. Now added code which falls 
  back to ino nameofexec when tcltest::interpreter is not 
  available.

  ... Now the testsuite fails in the same way as for 8.4 (missing 
  data, failed scan).


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

  Ok, what happens is that the [read] which retrieves the time 
  data from the server may not get data on the first read. As the 
  routine is programmed to simply expect that the first read is 
  successful it can run into failure. What bugs me is that the 
  channel is blocking ... It should wait for data and collect it 
  internally until EOF. ... Hm. If I delay the [close] in the fake 
  server things are ok. So this could also involve stuff in the 
  OS, the close coming to fast or what.

  My solution is to
  - append [read] data
  - bail out of the ClientReadEvent as long as the data is not 
  complete (4 byte)

  I.e. finish only after data is completely received.
  That should be robust with a variety of servers.

  Committed the changes.


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


  The variable $::tcltest::tcltest is available from
  bothe tcltest 1 and tcltest 2, and holds the same
  value returned by [tcltest::interpreter] in tcltest 2.


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

  Done. Disabled the commands only, no removal. May be needed
  in the future for debugging.


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

  ipentry and autoscroll are mine. i was following the
  conventions from tcllib so the docs are in the doctools
  format instead of troff and are named .man as opposed to .n

  what should be done about this? i think the installer should
  be fixed and the other man pages be converted to the
  doctools format.


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

  from Andreas Kupries:

  The entire build system for tklib has been replaced with the
  same type of
  build system in use for tcllib. I.e. Swiss Army Knife Tools
  (sak.tcl) with
  attendant files, installer based on that, etc.

  All existing nroff manpages (two) have been converted to
  doctools. All
  modules without any documentation (one) got manpages based
  on doctools. All
  (four) modules are thus documented now.


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

  Reviewing the patch ...
  The move of the close/unset I understand. Takes the
  fileevent away.
  Unsetting ftp(state.data) I understand as well, after
  reading WaitComplete. It is necessary to prevent this
  command from doing a vwait without having an event source.
  However, why is there a 'read ftp(CtrlSock)' in the patch ?
  The Ctrlsock is already at eof, so this is a no-op.
  The close alone should be enough.


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

  I have now committed the patch without using the 'read
  CtrlSock'. If that causes the head (rev 1.44) to still fail
  with an infinite recursion please re-open this bug.

  Side note: Thank you providing a patch, and for attaching it
  to the report instead of inlining it. Despite this I have a
  small nit. Please use the command 'diff -u' the next time
  you create a patch for us. The '-u' switch causes 'diff' to
  generate a patch in the 'unified' format. This format
  generates larger patches, this however is offset by the fact
  that the result is much easier to understand when read by a
  human. In other words, it makes the reviewing of a patch
  easier for us maintainer. Thank you.


login: hofkensg
username: hofkensg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1625850

  You are right about the no-op.
  I have tested revision 1.44 and it works fine.
  I will use the diff -u in the future.
  Thanks,
  Guy


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  hook: Moved the examples in the hook page to separate lines to avoid the issue.
  doctools: Forced a \n after each .CE to avoid this in future manpages even if they use examples on the same line as text.

  Note: There is a long-standing indentation bug which is also triggered here, even after fixes, where parts of a nested list are out-dented. This is not fixed, it is known, and it is not known how to fix that one.


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

  Proposed new ::ftpd::read solves problem:

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

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


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

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


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

  Cross-reference. See patch
  http://sourceforge.net/tracker/index.php?func=detail&aid=1254934&group_id=12883&atid=312883
  for a possible solution.


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

  The test case attached to the patch definitely shows the
  \r\n's added to a part, by part creation, and part composer
  repectively.


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

  The original patch was incomplete, a new patch has been
  added to the cross-referenced entry. Please test.


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

  Committed the patch, this should be fixed now. In the demo
  of the x-ref entry it is.


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

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

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


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

  Looks like the attachment didn't get there, here are the 
  diffs:

  1065c1065
  <             vwait [subst $token](readable)
  ---
  >             vwait $token
  1144c1144,1147
  <     if {[catch { gets $state(sd) state(line) } result]} {
  ---
  >     if {[eof $state(sd)]} {
  >         set state(readable) -3
  >         set state(error) "premature end-of-file from 
  server"
  >     } elseif {[catch { gets $state(sd) state(line) } 
  result]} {
  1147,1151d1149
  <     } elseif {$result == -1} {
  <         if {[eof $state(sd)]} {
  <             set state(readable) -3
  <             set state(error) "premature end-of-file from 
  server"
  <         }
  1160c1158
  <     if {$state(readable) < 0} {
  ---
  >     if {$state(readable) != 1} {


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

  I got a 'go' by marshall. I don't have
  tcllib 0.6.1 available and therefore
  ask the submitter to generate a patch
  against tcllib 1.2. Please use the
  option "-u" when executing "diff". This
  will generate a "unified diff" which is
  generally easier to read and also easier
  to apply as patch will get some context
  to check against.

  Either attach the patch here or send it
  to me.


login: sjscott
username: sjscott
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=255303

  I've downloaded tcllib-1.2, will generate patch and send it 
  along.
  Thanks


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

  This actually works for most type/order combinations. There
  are only three exceptions. The three non-working
  combinations are: dfs/post, bfs/post, and dfs/in. I.e. any
  of the two walking types, in post-order traversal, and the
  in-order traversal. The problem for all of them is that the
  pruning has to happen when entering a node, and for them the
  entering is done only internally, the walk script will not
  see it per definition of the traversal, and thus is unable
  to tell the walker that pruning is wanted for a specific node.

  It might be best to simply document these exceptions, simply
  say that pruning is not possible fro them. And code the
  prune command to test for these situations and throw errors.


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

  Done and committed to head.
  Also added methods 'ancestors' and 'descendants' for treeCL.


login: aku
mimetype: text/plain
icomment:
  Notes
  - Will extend the docs a bit to make explicit note of the ability to use css/js multiple times and accumulate the arguments.

  - Will rewrite the tests a bit. We can use html::head to show that the side-effect we wanted has occurred.

  - Will add commands to clear the css and js elements. This makes testing easier as well as we can then control the state going into the tests, and coming out of them (i.e. perform proper setup/cleanup).

  Otherwise looks good.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [8564870e90].
  Package version 1.4.2.
  Committed.
  Pushed.

  Note: Testsuite extended a bit more, i.e. check argument handling, single/multiple references.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Nice job finding and fixing this bug, Mark.  Thanks for the patch.  Your fix is integrated into the CVS source tree, and will be included in the next release of the library.

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


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

  Can you tell me which revision of doctools and html backend you are using ? In my version the code not only generates numbered <a name=""> anchors at the command locations, but proper <a href=""> links to them in the Synopsis too.

  Or are you trying to link to specific commands from outside of the manpage, i.e. from other manpages in the same set ?

  That is actually something we know we have trouble with in general. You can link to a complete manpage X from another page Y, by marking up the title of X in Y as a [term], however there is no support at all to directly link to deeper structures, like sections, let alone command definitions.

  There are some extremely rough ideas floating around regarding a TeX like use of 'label' and 'reference' markup, nothing concrete however, and based on your description also not really what you are asking for with regards to commands.

  The links you see are automatically generated purely based on strings ... We might be able to extend the set of terms which can be linked too so that the other commands also refer to the containing manpage ... I have to think about that a bit more ...


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

  I'm using tcllib1.9 (from a couple months ago, IIRC), which I've installed on sourceforge here (directories are executable, should be browsable):

    /home/users/s/sd/sdeasey/local

  But yes, I'm trying to link to a specific command (1 of n) on one page, from another page.

  If you use [cmd ...] it does actually create a link, you don't have to use [term ...]. So the linking machinery is there. The problem is that on the target page the HTML markup looks like this:

  <dt><a name="1"><b class='cmd'>ns_sls set</b> <i class='arg'>key</i> <i class='arg'>value</i></a><dd>

  (from: http://naviserver.sourceforge.net/n/naviserver/files/ns_sls.html )

  The anchor name is "1". The anchor name should be "ns_sls".

  Secondly, which commands are defined in which pages needs to be added to the .idx, .xref or .toc (whichever is most appropriate), as the documentation is being parsed, just like which keywords appear in which pages.

  It seems like most of what's needed is already there. I don't think there needs to be an extra linking mechanism (label, reference), at least, not for this purpose.

  I think it's also important to use the expected string names as anchors, rather than opaque numbers, to allow links to be created from external works, such as wikis. It seems unlikely that there would need to be multiple definitions of a single command on one page, and in such a case, the first one will be linked to.

  I noticed that the linking seems to be case insensitive, at least for terms. This is a problem for commands and C library functions (which are case sensitive anyway). For example, naviserver has the Tcl command ns_log(n) and the library function Ns_Log(3). It would be nice to be able to refer to one from the other.


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

  A workaround is in place in the ldap module, which looks for
  the namespace var storing the nonce count and resetting it,
  before a new attempt. Not perfect but works. If this gets
  fixed in the sasl module, it would be better, but its not a
  showstopper for ldap sasl support.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 242826: bug1545306.patch

  Logged In: YES 
  user_id=202636
  Originator: NO

  You might try the attached patch which moves the nonce count into the context structure. SASL::cleanup will remove it so a new context will begin again at 1.
  To reuse a SASL context as described in the RFC you should call SASL::reset. As the context remembers the original server challenge and now the noncecount it will compose a new auth request as before but with an incremented noncecount and should re-authenticate. This needs confirming -- I don't have an LDAP setup to try against and my SMTPd doesn't do re-authentication.
  File Added: bug1545306.patch


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

  No such error for Tcl 8.5 and higher. The reporting of aliases (which setop is in the testsuite) see-sawed a bit in the 8.5 alpha series. In final old behaviour was restored.


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:
  Logged In: YES 
  user_id=75003

  I have determined how the error is generated.

  In the method "add row" data is set into cells,
  actually into the internal array of the matrix.
  This triggers the trace and via MatTraceOut the
  external array is set too. This then triggers
  the trace we have on that array and MatTraceIn
  is called. This command uses "set cell" to set
  the value into the matrix. But at the time we
  are calling the method we are in the middle of
  "add row" and the internal structures, especially
  the information on how many rows the matrix
  contains, are not uptodate. Because of this the
  *range check* performed by "set cell" fails and
  generates the error message we see, namely that
  the argument to "set cell" are out of bounds.

  My solution would be to disable MatTraceIn when we
  are inside of MatTraceOut. This will take care of
  all situations where this can occur and not only of
  this specific case.


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

  And yes, the "date" vs. "data" thing is a bug,
  one which was already fixed in the CVS head.


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

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


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

  I've checked in a change that allows a type to have a 
  "typeconstructor".  The typeconstructor's body is executed just 
  after the type is defined; all type variables are visible in it.  Thus, 
  it can be used to initialize array-valued type-variables and other 
  resources belonging to the type as a whole.


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

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

  That remains to be done!


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


