# ticketchng

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

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


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

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


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

  Confirmed.

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


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

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


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

  Proposed new ::ftpd::read solves problem:

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

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


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

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


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

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


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

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

  Committed fix to both 1-6 branch and Head.


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

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


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

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

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


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

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


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

  Notes for future reports:

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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


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

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


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

  Good or bad is of course a matter of taste.

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

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

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

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

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


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

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

  I'll have to think more about this.


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

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

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

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


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

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


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

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

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

  Lio.


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

  "Tk Toolkit" is the correct place.

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


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

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


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

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


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


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

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


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

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


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

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

  Should I  close this then ?

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


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

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


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

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

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


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

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


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

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

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


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

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


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

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


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

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

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


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

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


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

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


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

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


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

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


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

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

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


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

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


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

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

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

  Digging deeper.


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

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

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

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


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

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


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

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


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

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


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

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

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


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

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


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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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


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

  Ooops, there is TclMagick already!

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


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

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


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

  This is a nice bug in ListBox::_mouse_select.

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


  The return value is required in ListBox::_multiple_select


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

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


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

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

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

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


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

  Ok. I changed this to use 

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

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

  This will be committed.

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


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

  Also note the other report about this, at

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

  This one was without code however.


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

  Thanks for the better fix!

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

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

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

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

  George


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

  This demonstrates the problem:

  % package require struct::tree
  2.0

  % struct::tree
  ::tree1

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


  Whereas this works:

  % package require struct::tree
  2.0

  % package require struct::list
  1.4

  % struct::tree
  ::tree1

  % tree1 children root filter puts
  % 


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

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

  Ditto for method "descendants".

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


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

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


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

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

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

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

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


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

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

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


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

  The return values of determineScale seem to be correct.

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


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

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


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

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


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

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


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

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

  Also added a few tests to fileutil.test.


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

  Just committed a fairly complete man page for the geometry 
  submodule


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

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

  exerpt:

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

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

  [call [arg net] [method logname]]

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


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

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


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

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

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


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

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


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

  Discussion on the chat.

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


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

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


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

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


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


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


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

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


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

  Bah.

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

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

  This is ActiveTcl 8.4.11.0.172579 btw.


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


  Here's the first failure:

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

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

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


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

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

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

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

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

  This will be a pain to untangle.

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


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

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

  Now looking at the crc problem with Trf.


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

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

  This bug is now done.


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


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

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

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


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

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

  Also done for md4.

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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


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

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

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


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

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


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

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


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

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


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

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

  I will take action to improve this.


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

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


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

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

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


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

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

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


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

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

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


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

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

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

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

      4.  Examples

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

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


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

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


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

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

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


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

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

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

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

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

  How would this work for you?


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

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

  modules/math/linalg.test

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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


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

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

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


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

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

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


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

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


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

  Accepted the patch, committed to CVS head.

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

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


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

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

  That remains to be done!


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

  jlib is a jabber library depending on TclXML...

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


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

  Where is the source for jlib?

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

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

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


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

  jlib is part of coccinella.

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

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

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

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

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

  Re-assigning to pascal about that.


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

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

  I am able to select all items at once.

  I close the bug


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

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


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

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


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

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

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


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

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

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


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

  Still got that error with v 1.263:

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

  As for Miguel, otherwise tkchat works as normal.


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

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


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

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

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


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

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


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

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


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

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


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

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


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

  Aamer, some questions and notes on this code.

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

  Questions:

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

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

  More musings:

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

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

  And then various laws, like DeMorgan to handle negatives:

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

  A | B, A ^ B have similar rules.


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

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


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

  This has been fixed. A postprocessing step ensures that \fB.
  and \fBI. do not occur at the beginning of a line. By
  appending such offending lines to the end of the previous line.


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

  Fixed in the CVS head. List of glob patterns is defined
  platform dependent now.


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

  I have asked Salvatore Sanfilippo, who wrote this package to
  look into these problems


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

  I ought to add the proposed tests (mind you: bit operations 
  are not my cup-of-tea - I will need some help on the 
  correct outcome or can I rely on the bit operations in Tcl 
  for ordinary integers?


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

  Rely on the ordinary operations how ?
  They do work correctly assuming that the Tcl integers are
  limited-precision (32 or 64 bit). In 8.5 they are themselves
  extended for bignums. ... That may mean that you can use 8.5
  regular ops to determine what results the tests should
  expect. Kevin might be able to help you with that.


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

  I made a correction to the rshift proc (not the rshiftBits 
  proc that it uses, as that is used in more than one place). 
  The idea for the test cases is to reproduce the results of 
  Tcl's expr for those integers that can be represented by 
  ordinary integers and by bignum.


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

  http://support.microsoft.com/?id=819961 suggests it will be
  of the form http://servername:port/
  Elsewhere MS documentation says "ProxyServer  This entry
  specifies the URL and port number for the proxy server."

  However, if you fill in different servers for each proxy
  type in the Internet explorer settings you indeed get the
  above string. This is with IE6. Probably the same for other
  versions.

  I think it is safe to split the string using ; and we will
  want the proxy for the protocol desired - that may be http
  or https for autoproxy purposes.


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

  Added support for this to the autoproxy package. At this
  time we do not have sufficient information to differentiate
  between https and http at the point where we hook into the
  http package - therefore we always use the http proxy setting.

  The http package should be enhanced to support this -- but
  then the http package needs many enhancements and a general
  support for proxies is one part of that.


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

  Committed/added to CVS head. Lars will be added as developer
  to Tcllib as well, and bug reports etc. in the docstrip
  category will be (auto-)assigned to him.


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

  Thanks for reporting this. 

  It is a bug, (now fixed with version 0.5.1), as the children
  only picked up level changes after their creation but did
  not inherit the current level configuration of the parent.

  Michael


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

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

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


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

  I can confirm this and can offer two possible fixes:
  1. keep the current interface to logprocs and hack around it
  (quite a mess with alias introspection and other uglyness,
  but keeps the two parameters logprocs...)
  2. Change the interface of the logprocs and give the service
  as a parameter to the logging proc.

  The second version is much cleaner and better, but breaks
  compatibility.

  I have to think about, how to do it _right_, perhaps even
  introducing an args parameter for future extension (like
  format strings or similar things).

  Michael


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

  There is now a fix in CVS for this. 
  Basically the info was not passed down the inheritance
  chain, which is now working. 

  It now works with all combinations of logger::import, even
  if -all is not given (which failed in the older fix).

  Michael


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

  This fix has introduced a side-effect. The uplevel or [info
  level] cmd called from a custom logproc is 1 level deeper.
  see the following example:

  package require logger

  proc print args {
     set lvl [expr {[info level]-1}]
     set caller "global"
     if {$lvl > 0} {
         set caller [lindex [info level $lvl] 0]
     }
     puts "PRINT: level = $lvl, caller = $caller, args=$args"
  }

  namespace eval ::foo {

      set log [logger::init foo]
      logger::import -all -namespace log foo
      log::setlevel notice

      log::logproc warn  print
      log::logproc info  print
      log::logproc debug print
  }

  proc ::foo::x args {
      log::warn   "foo::x warn"
      log::debug  "foo::x debug"
  }

  ::foo::x

  When I execute the above, it used to print:

  hlavana-u5:143> tclsh foobar.tcl-v3
  PRINT: level = 1, caller = foo::x, args={foo::x warn}
  hlavana-u5:144>

  However, it now prints the following with logger.tcl in cvs
  head:

  hlavana-u5:143> tclsh foobar.tcl-v3
  PRINT: level = 2, caller = log::warn, args={foo::x warn}
  hlavana-u5:144>

  The caller proc name is no longer printed as foo::x.

  Hemang.


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

  Yes, this is correct, as the internal are handled
  differently now (one extra layer of indirection, as always
  the solution).

  I added a uplevel 1 in the fix, and now the callstack looks
  nice again.  (fix is in cvs, logger 0.5.3)

  Is this callstack an important feature of logger for you? If
  yes, please file a RFE, so it either gets documented and
  gets part of the public API or an API is created to get the
  caller and callstack (excluding logger internals), so you
  can depend on it being stable between releases. (currently
  this is not tested).

  I hope i can keep the current clean callstack behaviour, but
  i thought of it as an internal detail, not a public thing. 

  Michael


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

  Ok, here's one more error with the latest fix:

  hlavana-u5:158> tclsh foobar.tcl-v3 
  wrong # args: should be "print msg"
      while executing
  "::logger::tree::foo::warn foo::x warn"
      invoked from within
  "interp eval {} ::logger::tree::foo::warn {foo::x warn}"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [linsert $args 0 interp eval {} [list
  ::logger::tree::foo::warn]]"
      (procedure "log::warn" line 1)
      invoked from within
  "log::warn   "foo::x warn""
      (procedure "::foo::x" line 2)
      invoked from within
  "::foo::x"
      (file "foobar.tcl-v3" line 33)
  hlavana-u5:159> cat foobar.tcl-v3 
  #!/bin/sh
  # \
  exec tclsh "$0" ${1+"$@"}


  package require logger

  proc print msg {
     set lvl [expr {[info level]-1}]
     set caller "global"
     if {$lvl > 0} {
         set caller [lindex [info level $lvl] 0]
     }
     puts "PRINT: level = $lvl, caller = $caller, msg=$msg"
  }
  namespace eval ::foo {

      set log [logger::init foo]
      logger::import -all -namespace log foo
      log::setlevel notice

      log::logproc warn  print
      log::logproc info  print
      log::logproc debug print
  }

  proc ::foo::x args {
      log::warn   "foo::x warn"
      log::debug  "foo::x debug"
  }

  ::foo::x
  hlavana-u5:160>  

  Note that I am not able to get latest version via anonymous
  cvs so e-mail me to verify further fixes.

  Hemang.


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

  The last change had introduced an (uneccesary) double eval,
  removed one, now it works.


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

  It is the caller's job to call [update] within his loop if
  that is the intended behavior.  Man page modified to note this.


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

  You should never get an error about being unable to find
  tls.  Tls is an optional package. If it's present then it
  will enable the use of SSL but tkchat is happy to not have it.

  Can you try the current version (located at
  http://tclers.tk/~jabber/tkchat.kit) and update this bug
  with the result.

  It's possible that the error is related to the dodgy support
  for Solaris in the tls.kit rather than tkchat.kit itself.


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

  I downloaded the suggested tkchat.kit , along with the
  current tls.kit.
  I executed the new tkchat.kit, and it appears to start up
  without the error I was seeing before.

  So things appear to be working better.  Thanks!


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

  This error appears to have returned:
   $ tkchat.kit
  couldn't load library
  "/volws/lwv28/ldatae/bin/tls.kit/lib/tls/SunOS-sparc/tls.so":
  no such file or directory
      while executing
  "load
  /volws/lwv28/ldatae/bin/tls.kit/lib/tls/SunOS-sparc/tls.so "
      ("package ifneeded" script)
      invoked from within
  "package require tls"
      ("foreach" body line 4)
      invoked from within
  "foreach tlsname {tls.kit tls-win.kit tls-lin.kit} {    
      if { [file exists [file join $kitdir $tlsname]] } {
          source [file join $kitdir $tls..."
      (file "/volws/lwv28/ldatae/bin/tkchat.kit/main.tcl" line 5)
      invoked from within
  "source /volws/lwv28/ldatae/bin/tkchat.kit/main.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel [list source [file join $self main.tcl]]"
  I did an sdx update tkchat.kit today:
  2005/04/14 07:07:40  30545-10419  /ldatae/bin/tkchat.kit


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

  Is this bug still relevant ? IIRC tkchat has evolved at lot,
  version somewhere at 1.320+


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

  This error continues to occur. I downloaded the latest 
  tkchat.kit from mini.net, ran sdx update tls.kit, and when 
  I start tkchat.kit, I get:

  $ /volws/lwv27/ldatae/WWW/tkchat.kit
  invalid command 
  name "#####################################################
  ###########################################################
  ################################################LJÀÀ"
      while executing
  "source /volws/lwv27/ldatae/WWW/tkchat.kit/main.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel [list source [file join $self main.tcl]]"

  Note that when I rename tls.kit to tlsbad.kit, tkchat.kit 
  starts up without a problem.


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

  This should be fine by now. At least on Solaris 10 sparc I
  can make use of the tls.kit at http://mini.net/sdarchive/tls.kit


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

  One implementation of that is:

  proc fileutil::jail {jail filename} {
      set sjail [file split [file nativename $jail]]
      if  { ! [string equal [file pathtype [file join $sjail]]
  "absolute"] } {
  error "$jail must be an absolute path"
      }
      set sfilename [file split [file nativename $filename]]

      if {[string match ${sjail}* $sfilename]} {
  set path $sfilename
      } else {
  set path [concat $sjail $sfilename]
      }
      return [eval file join $path]
  }


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

  Ok, then. Why 'normalize' ?
  I believe to know, would like a confirmation.


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

  Chat

  14:27]<davidw>aku: to take out all the ../../ stuff
  [14:27]akuOk.
  [14:28]akuWe should mention that explicitly in the docs,
  as security measure. You cannot escape using ..
  [14:28]akuIt will block symlinks trying to escape as well,
  right ?
  [14:28]<davidw>it should


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

  It is fileutil::find which has the problem, not
  findByPattern. findByPattern is implemented in terms of 'find'.

  'find' calls itself recursively for all directories it finds
  in the base directory, making the subdirectory the new base
  directory.

  Looking at the code of 'find' it further seems to me that
  the 'glob' command is listing 'sys' deeply somewhere under
  c:\, 'file isfile' claims that it is not a file, but 'file
  isdirectory' claims that it is a directory. In complete
  contrast to the error message returned by 'cd'.

  The only time I have remotely similar behaviour, i.e.
  completely conflicting information from the various
  subcommands of the 'file' command, 'cd', 'glob', and the
  like was for a system file, in my case 'page.sys'.

  Given the name of the directory my guess is that this is a
  special directory of Windows which looks like a directory,
  behaves like directory, and yet is not a directory, not even
  there. To regular file/dir commands.

  My plan for fixing this is to add a catch around the 'cd
  $basedir' which errors out, and to ignore the
  pseudo-directory. In other words, neither sys, nor anything
  inside of it would show up in the out of 'find',
  'findByPattern', ever.

  One thing might wish to try in the interim is to locate this
  'sys' directory by conventional means, i.e. MS Explorer, and
  then to run various file related commands of Tcl on it, like
  'file exists', 'file isdir', 'file attributes', 'glob',
  'cd', etc.


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

  The only other thing I can think of is that the permissions
  of the directory prevent you from entering it. The error
  message however is evidence against that. Still, I cannot
  exclude this, i.e. maybe the error message given by Windows
  is wrong.

  Well, I just tried this on Linux with a directory I made
  inaccessible (chmod -x). And an attempt to cd into that
  directory, in tclsh, returned the message "file or directory
  does not exist", but 'file isdir' and 'file isfile' returned
  the proper information. This is an indicator that
  permissions can be the problem as well. ... And 'find'
  errors out in the same manner as demonstrated.

  This would however not change the fix. The unix 'find'
  command ignores inaccessible directories, and we can do the
  same.


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

  Small correction: The 'sys' directory itself will appear in
  the output of 'find', and of 'findByPatttern', if matching
  the pattern. Files and directories under 'sys' will not.


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

  Looking over the other bugs I find that this one is actually
  a duplicate of
  http://sourceforge.net/support/tracker.php?aid=862491

  See there for more discussion which was had on the Tcler's chat.
  I have decided to fix this with a catch, ignoring any
  problematic directories. I will also file an RFE asking for
  an API change which allows us to set an error handler, to be
  called for the problematic directories.


login: jcw
username: jcw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1983

  Forgot to mention that the webdav package relies on a modified httpd 
  package (mods by Vinde Darley and Pat Thoyts AFAICT, included in the 
  starkit) to support DAV requests.  There is incomplete support for HTTP/
  1.1 in there, which would probably speed up the case of lots of back-to-
  back requests.


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  From the Tcl'ers Chat today (times UTC-0400):

  [13:18]<siyb>is jcw available by any chance?
  [13:19]kbkHe isn't often in the room, but he answers email. Can someone else help?
  ...
  [13:19]<siyb>kbk: it's about his davkit implementation. i was looking for a source version if one is available
  [13:21]<siyb>kbk: do you know if his email is still up to date (jcw@equi4.com)
  [13:22]   * kbk would have to check contact information at http://jeelabs.org/ - but hold on...
  [13:23]kbkdavkit is available as a starkit at http://tcl.tk/starkits/
  [13:23]kbkI just did an 'sdx unwrap'...
  [13:24]kbkand I found a bunch of Tcl code, and then...
  [13:24]kbk... native code in the Tclxml and Tclexpat packages...
  [13:24]kbk... both of which are readily available in source form.
  [13:24]kbkSo it looks as if downloading and unwrapping the starkit gives you all the pieces.
  [13:24]<siyb>thanks 
  ...
  [13:34]akuWe should possibly still ask jcw if he would be willing to put the sources up on github
  [13:36]kbkMaybe... didn't the 'webdav' package get added to Tcllib at some point? That's really all that the kit is: webdav + dependencies (base64, Tclexpat, Tclxml, and uri)
  [13:37]akuHm. Let me check ...
  [13:38]akuNo, no webdav in tcllib
  [13:58]kbkhttp://wiki.tcl.tk/13480 says, "The webdav and davvfs packages have been submitted to Tcllib for consideration, review, and possible inclusion."
  [13:58]kbkso it's obvious what Jean-Claude's intention was.
  [13:58]akuHm.
  [13:59]akuI don't remember that. I'll have a look through the bug database ...
  [13:59]kbkSuspicion: does the XML stuff (expat+tclxml) always require native code, and if so, did that cause a rejection?
  [14:00]akuIMHO should not. (Even if would prefer tDOM)
  [14:01]akufound it, assigned to Pat - 1115865
  [14:06]kbksiyb - Looks as if we dropped the ball about 6.5 years ago, but we're picking it up again. Better late than never.


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

  This problem is fixed in the CVS.

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

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


login: skielty
username: skielty
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=355872

  if -drawcross option isn't used -- this doesn't happen -- if it 
  is allways it does -- I didn't check the auto or never options 


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

  This was a tkCanvBmap.c issue and has been fixed in 8.4
  branch and HEAD.


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

  I added tests (14.x) for this feature and will add it to the
  documentation for the next release.


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

  Haven't we fixed that in the head ?
  Yes, in April 2005 according to the ChangeLog.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  I was looking for something more limited, but a subset of
  this. I find the width of the log's lines more than
  necessary.  I would like to be able to set the time format
  to be "%D %T" instead of the current default clock format.

  This can currently be done by using logproc to overwrite
  existing logprocs, or by cheating and replacing stdoutcmd
  and stderrcmd (which look to me like they should be
  refactored, since they do the same thing except for the
  channel).


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  One other element that I forgot; right now the log file is
  actually determined by the standard handles for stdout and
  stderr. It would nice if the file handles for different
  levels could be configured. Again, the logproc is sufficient
  to override this, but that's something that must be customized.

  The current definition of logproc does not say what
  namespace the command to execute must exist in.  While there
  is a sample replacement proc, there is no example  logproc
  command to use it. So, would it be ${log}::logproc notice
  ::logtoserver
  ?


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

  ProgressBar now makes explicit check, disallowing having a
  -maximum 0.


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

  Creating a server socket and giving port 0 should never be a
  privileged op. Passing port 0 means pick a random available
  port. So the issue is really about Windows XP's firewall
  implementation. 

  Maybe we might avoid this for that platform.

  hmmm


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

  Replaced on windows with a call to ipconfig which also
  returns information about the IP address on windows 98 and
  above.


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

  You should use the newer statistics submodule instead.
  (Though it does not - yet - compute the coefficient of 
  variation ...)

  The situation you sketch is one where the coefficient is not 
  defined. The procedure should return a more descriptive 
  message ...


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

  Has something happened here ?
  The reference to 'statistics' seems to indicate that we can
  close this entry, no ? Maybe as 'out-of-date' ?


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

  Looks like we just need to check that these elements are
  present in the array.  Fixed (for 1.266)


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

  It seems jabberlib went and changed the interface for the
  send_iq command - which is a bit rude. Fixed


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

  This might also need a way to ask for the current serial
  number, no ? I do not believe that we have that already, so
  it needs to be added.


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

  We're covered: [$chan config -serial] will give us the
  serial number.


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

  The following script show this problem. It's not leaked
  arrays  or event handles. Watching the process shows no sign
  of leaked memory or windows kernel handles. Must be a tcludp
  limit in the recv queue?

  set file [file join [file dirname [info script]] dns.tcl]
  if {[file exists $file]} { source $file }

  package require dns
  dns::configure -nameserver [lindex [dns::nameservers] 0]

  proc LookupDone {ndx max name tok} {
      if {[dns::status $tok] eq "ok"} {
          #puts "$ndx [dns::address $tok]"
      } else {
          puts stderr "[dns::error $tok]"
      }
      dns::cleanup $tok

      incr ndx
      if {$ndx < $max} {
          dns::resolve $name -command [list LookupDone $ndx
  $max $name]
      } else {
          set ::forever 1
      }
  }

  proc Main {name {limit 10}} {
      set forever 0
      dns::resolve $name -command [list LookupDone 0 $limit $name]
      vwait ::forever
      puts done
  }

  if {!$tcl_interactive} {
      set r [catch [linsert $argv 0 Main] err]
      if {$r} { puts stderr $err }
      exit
  }


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

  Looks like it is something to do with the DNS activity and
  not just the UDP package. A similar script to the one below
  but using SNTP completed 70000 requests.

  set file [file join [file dirname [file dirname [info
  script]]] ntp time.tcl]
  if {[file exists $file]} { source $file }

  package require time

  proc LookupDone {ndx max name tok} {
      if {[time::status $tok] eq "ok"} {

      } else {
          puts stderr "[time::error $tok]"
      }
      time::cleanup $tok

      incr ndx
      if {$ndx < $max} {
          time::getsntp -command [list LookupDone $ndx $max
  $name] $name
      } else {
          set ::forever 1
      }
  }

  proc Main {name {limit 10}} {
      time::getsntp -command [list LookupDone 0 $limit $name]
  $name
      vwait ::forever
      puts done
  }

  if {!$tcl_interactive} {
      set r [catch [linsert $argv 0 Main] err]
      if {$r} { puts stderr $err }
      exit
  }


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

  We were using the query id to locate the DNS state token but
  this restricts us to 65535 queries as the value is packed
  into a short. It isn't necessary and doesn't work.
  You can show this problem more easilly by setting the
  initial value of the uid variable to 65530 instead of 0.


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

  Fixed this - the test file was assuming it was started in th
  e same directory as the source files for plotchart. I took
  the opportunity to make it fit into the test framework just
  a bit nicer. Still requires some work, but at least it runs,
  the windows appear and disappear and it all counts as one
  successful test.


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

  For future reference, please create patches in unidiff
  format. They have infomration about which file they apply
  the regular plain patch you provided does not have. They
  also have context information which allows the patch to to
  find the location even if in the presen of slight changes in
  other parts of the file, shifting the locations around a bit.


  Also: Please specify exactly which images from the exif site
  you used. I.e. links to the pages containing the image(s),
  liks to the images themselves.

  If possible, can you please attach test images as well, if
  they are not too large ?

  All of the above is required by me so that I can extend the
  testsuite  to cover the new code. Test cases covering when
  encountering an unknown tag should be provided as well, but
  I am willing to drop this part.

  As you said "most 2.2 tags" I would like to know which of
  the tags  are _not_ handled by your code.


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

  Reassigning to Michael Schlenker, AFAIK he was the last to
  touch this code as part of his ASN work.


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

  After some analysis, it appears that too many configure and
  resize events are being generated, causing Tk's event ring
  buffer to overflow.[1]  As an experiment, I ran the provided
  test program under differing window managers; the shaking
  behavior occurs when differing number of items are added to
  the ListBox.  I see no clean way of resolving this problem.

  [1] This error was first reported as Bug 795608, "tk binding
  problem in Gnome and Ximian".  My analysis to comp.lang.tcl
  may be found at http://tinyurl.com/l6dfd.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  It does not happen for me on current cvs on linux or windows for tk8.5.7.

  This might also be due to an improved locking in the widget.

  I close the bug, complain if it is still an issue.


login: kjnash
username: kjnash
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=991282

  I've run into the same bug:  if a tabbed page is deleted
  from the notebook, its records of pages and indices are
  corrupted.

  Operations like adding or removing further pages may fail,
  sometimes with bgerror.  Pages may be mapped to the same
  index in the notebook, and gaps appear in the tabs.

  Thanks for the fix.


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

  Please try the current CVS head of tcllib, if it fixes this
  it could trivially be backported to the tcllib1.7 release
  version. The installer and confiigure now recognizes and
  respects ./configure --bindir ...

  dtplite is needed to create the nroff and html documentation
  for tcllib

  If it does not work, please report back with your configure
  / install values, so we can check whats wrong. If it works,
  report back so i can close the report.


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

  This is AFAIK fixed in the CVS head. An 1.8 release is upcoming.
  Is the submitter willing to pre-test it ? so that we can be
  sure that a debian package can be created from it ?


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

  The submitter was mailed directly regarding the new release
  too, no response. The entry is now on auto-close row.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is wrong usage. Please try:

  set swg [ScrolledWindow .swg]
  set p [$swg getframe]
  set wg [NoteBook $p.nb]
  pack $wg -fill both -expand 1


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

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


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

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


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  This seems to be a simple bug caused by the fact that Tcl
  has two
  logically-equivalent-but-not-actually-string-equivalent
  names for commands:  one which includes the "::" prefix
  indicating the global namespace, and one which does not. 
  The profiler is saving descendent information using the
  unscoped name (no "::" prefix), but then trying to query it
  using the scoped name (with a "::" prefix).

  I added code to the profiler to try and account for this. 
  It should work in most scenarios, but I didn't test it
  exhaustively, so there may be corner cases not handled
  correctly.


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

  Three simple typos, refering to 'token' by 'tok'. Fixed,
  committed to head.


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

  Done in CVS head.
  Keeping the report open, it might actually be a deeper
  conflict between tar and vfs::tar.


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

  fixed as recommended on 9/30/05 by akupries. Open a new 
  report for any new issues or conflicts.


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

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


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

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


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

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

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


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

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

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

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

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


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

  Committed the fix to head. Had to move a namespace eval
  before the condition so that the namespace would exist
  before trying to put a variable into it.


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

  Workaround:  
    
  ----------------------------------------------  
  puts [encoding convertfrom utf-8 $t(cn)]  
  ----------------------------------------------  
   
  Why UTF-8 strings resulting from a LDAP search are not 
  automagically converted into Unicode to be handled like 
  normal strings? 


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

  The ldap package probably just returns the ASN OctetString
  type and does not interpret it in any further, but the
  application is free to interpret it in the way it likes to.
  I need to check the LDAP RFC what is expected to happen with
  the search result encodingwise.


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

  According to RFC 2253 the string should probably be
  converted to the UTF-8 encoding.
  http://www.ietf.org/rfc/rfc2253.txt
  and
  http://www.ietf.org/rfc/rfc2251.txt
  (Section 4.1.2).
  So yes, this is a bug und output should be converted to
  utf-8 or the encoding given in RFC 2253. Direct access to
  the ASN.1 values should be optionally possible.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  This is not a bug in the LDAP module.  
     
  According to RFC 2251, paragraph 4.1.2, only "LDAPString" types are  
  encoded in UTF8. Decoding depends on the schema used. 
   
  This should be made clear in the documentation. 
   


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  The attached patch provides a correction:
  - addition of a new function ::ldap::api_version, which 
  defaults to 1 (compatibility with buggy API)
  - when set to 2, ::ldap::add expects multi-valuated values 
  for each attribute.

  The new function api_version is meant, in the future, to 
  be set automatically by new functions to manipulate LDAP 
  entries at a higher level.

  This patch also removes duplicated code between asn.tcl 
  and ldap.tcl (asn* functions are removed from ldap.tcl, 
  and some functions from asn.tcl are updated).


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

  Thanks for the patch.

  Some comments:
  1. prefixing all the calls with asn:: isn't necessary, this
  is a perfect usecase for 'namespace import', so just
  throwing out the duplicated code and adding a namespace
  import works fine

  2. I don't really like the 'api_version' command, such
  things should usually be done with a major version change of
  the package (see md5 for an example where this happend)

  Basically i would just go for fixing the error with multiple
  attributes, so that your $arrtval2 should work, but the docs
  talk about 'dictionary' which implicitly forbids duplicate
  keys in the typical tcl hashtable sense.  

  The main problem with using the list approach (like
  $arrval1) you choose is the fact that there is no way to
  find out if a list or a simple string is passed, so it would
  always require listification of all values.

  Repeating the name and value for multiple values and letting
  the code check for duplicates and create the appropriate
  response set would probably be better. This would change the
  documentation from the strict "dictionary" to the less
  strict "name value list" which would allow duplicate keys.
   
  This had the bonus, that it would not break but only extend
  the current api, and so the package could stay at api
  version 1.x.

  3. What kind of functions do you have in mind when you talk
  about 'higher level functions to manipulate entries'? Would
  be very interested in your ideas there.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  1- I don't like "namespace import". IMHO, it obfuscates 
  the code.

  2.a- Ok for removing api_version command and use a 
  different version number (2.0) for ldapx.tcl. May I 
  seriously change some APIs? Candidates 
  are: ::ldap::connect (take an URI and 
  remove ::ldap::secure_connect, ::ldap::bind 
  and ::ldap::unbind) and ::ldap::search (use a more 
  extensible way of specifying options).

  2.b- attr-vallist (attrval1) or duplicate keys (attrval2)?
  You seem to prefer attrval2, but this is not compatible 
  with ::ldap::search result which should be an objective 
  IMHO. The current spec is buggy, and we cannot cope with 
  it.

  3- I'm playing with some ideas at this time. Follow-up by 
  private mail.


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

  1. Ok, will consider 'namespace import' or the prefixed
  versions..., both would work...

  2a. In a major new version the api may change quite a bit,
  thats the reason for a major revision, so if you have a
  patch or good ideas, go on.

  2b. Yes, the spec is buggy, so if it is fixed in a 2.0 it
  should be done consistent in ldap search and other places.
  There are other things which should be done (use the SASL
  package and fix the SSL stuff).


login: pdav
username: pdav
mimetype: text/plain
icomment:
  File Added - 189010: ldap.diff2

  Logged In: YES 
  user_id=1268042

  Here is the final (I hope) patch to close this PR.

  - The "add" function allows multiple tuples with the same 
  attribute. This API change maintains compatibility with 
  the old one, while allowing multi-valuated attributes. 
  However, a additionnel loop makes this function slower.
  - A new "addMulti" function extends the API with a list 
  where each value in a pair is itself a list of all values 
  for this attribute.

  So, to summarize:

  1. I namespace-imported the asn module

  2a. There is no API change. Instead, thanks to Michel 
  Schlencker, a new module (ldapx.tcl) will provide a 
  higher-level interface based on Snit objects. The current 
  ldap.tcl will remains as the low-level interface upon 
  which ldapx.tcl is built

  2b. We get the two syntaxes at the same price ;-)

  3. Some progress is being made. But this is no longer 
  related to this PR.


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

  (msw) I just tried to reproduce it and I can't with 1.311.
  It may depend on the other side's setting of 1-1 chats
  though so not 100% sure it's really fixed.


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

  (msw) uh, which version... this happened with the up-to-date
  version (or maybe -1) of the time I submitted the bug; I've
  wiped it some time back when I was cleaning up thus can't
  tell exactly which version (i.e. 275 - 282 although the
  interesting question probably is was it 282 or pre-282 - I
  can't tell :( )


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  version had to be 282, introduction of the counter 
  variable was done then.

  The only way I can see this variable not being set would 
  be by using a pre-282 version and updating to v282, or 
  newer, via the "debug->retrieve script" menu.


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

  Added a possible solution (the fix I use, since I really
  need the multi-line text):

  REPLACE in ftp.tcl
  while { [string equal $multi_line "-"] } {
      set number [gets $sock bufline]
      if { $number > 0 } {
  append buffer \n "$bufline"
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line
      }
  }
  WITH:
      if { [string equal $multi_line "-"] } {
          while { ![string equal $multi_line " "] } {        
                 
          set number [gets $sock bufline]
              if { $number > 0 } {
                  regexp -- "(^\[0-9\]+)?( |-)?(.*)$" $bufline
  all rc multi_line buffer
                  append msgtext \n "$buffer"
              }
          }
      }


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

  Christophe, can you walk me through your changes ?

  Having looked at the wider context I think I now see where
  the 'msgtext' variable comes from, and why you said that
  'buffer' is thrown away. Because apparently the 'msgtext' is
  the final destination for the multi-line result, not the
  'buffer' itself.

  I do note that in the current setup the multi-line is
  accumulated in 'buffer'. I wonder why this is not simply
  appended to msgtext after the loop ? In your loop the buffer
  changes from accumulator to contain only part of a bufline,
  apparently. It is further unclear to me why an additional
  'if' was put around the loop, and why the loop-condition was
  changed, double-inverted in a way. I guess I have to see the
  low-level server responses and how they flow through the old
  and new loops. Part of the problem is likely that I do not
  know how a multi-line response looks like at the very lowest
  level, i.e. what exactly is coming in over the control
  connection.


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

  Let me explain me changes:

  A multi-line should the following specs:
  Start with 999(rc) followed by a hyphen (-) and (optionally)
  msgtext
  Followed by line 1
  Line 2
  Line n
  End with 999(rc) followed by a space and (optionally) msgtxt

  Example:

  550-Start of Message
  Line1
  Line2
  550 End if Message

  Why not just append: because in the "original while" only
  the first line is red (condition is equals "-"),
  when reading. You should only start reading if we have a
  multi-line and the reading should stop when 
  the multi-line posistion equals " " (space).


  My approach (Added some comments, and some improvements to
  the previous code):


  # Only start reading the next (sub-line) if the current line
  has the multi-line indicator
  if { [string equal $multi_line "-"] } {
      # Keep on looping until the prefix equals the
  stop_prefix (original rc + space)
      set stop_prefix "$rc "
      while { $stop_prefix != $prefix } {        
          # Read a line
          set number [gets $sock bufline]
          if { $number > 0 } {
              # Improvements to RE:
              # Use curly braces, and remove back-slashes
              # (rc must be three digits and followed by a
  space or hyphen) this I call prefix, this entire prefix is
  optional                       
              regexp --  {^(([[:digit:]]{3})( |-))?(.*)$}
  $bufline all prefix rc multi_line buffer            
              # Add to msgtext, the real 'data'-variable
              append msgtext \n "$buffer"
          }
      }
  }


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

  I forgot to copy paste one line of code in my previous post
  (--> set prefix "") :

  if { [string equal $multi_line "-"] } {
      # Keep on looping until the prefix equals the
  stop_prefix (original rc + space)
      set stop_prefix "$rc "
      set prefix ""
      while { $stop_prefix != $prefix } {
          # Read a line
          set number [gets $sock bufline]
          if { $number > 0 } {
              # Improvements to RE:
              # Use curly braces, and remove back-slashes
              # (rc must be three digits and followed by a
  space or hyphen) this I call prefix, this entire prefix is
  optional                      
              regexp --  {^(([[:digit:]]{3})( |-))?(.*)$}
  $bufline all prefix rc multi_line buffer            
              # Add to msgtext, the real 'data'-variable
              append msgtext \n "$buffer"
          }
      }
  }


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

  I was thinking about your remark, why not just "Why not just
  append".
  Indeed, if you just add the line "set msgtext $buffer" just
  after the while loop it ALSO works fine.
  I was misled with the RE:
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line

  If we have a multi-line then the multi_line variable
  contains "-".
  For every next line the above RE will not be matched, thus
  the variables "rc and multi_line" will not be touched at all
  (I thought it would initialize it to empty, but NOT).

  The ending line will have a match and multi_line will
  contain a space, the loop will stop.
  So and easier, and less risk solution will be (the entire
  loop + "set msgtext $buffer")

  Code:
  # multi-line format detected ("-"), get all the lines
  # until the real return code

  while { [string equal $multi_line "-"] } {
      set number [gets $sock bufline]
      if { $number > 0 } {
  append buffer \n "$bufline"
  regexp -- "(^\[0-9\]+)( |-)?(.*)$" $bufline all rc multi_line
      }
  }
                  # This is the added line
  set msgtext $buffer


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

  Thanks for going through this so thoroughly.
  So, under the assumption that lines between multi-line start
  and end will never have the form of three digits followed by
  blank, followed by whatever we can use a very simple fix. I
  will put this simple fix in first, and then we can think
  more about the assumption and if it truly holds.


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

  Just to make sure "...assumption that lines between
  multi-line start
  and end will never have the form of three digits followed by
  blank..."

  I checked the RFC and this states:
  <<<The user-process then simply needs to search for the second
         occurrence of the same reply code, followed by <SP>
  (Space),
         at the beginning of a line, and ignore all
  intermediary lines.
         If an intermediary line begins with a 3-digit number, the
         Server must pad the front to avoid confusion.>>>

  So this means the problem should never occur if the server
  follows ths specs.


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

  Wonderful. In that case I believe that we can consider the
  problem truly and fully solved. And fixed. Closing the bug now.


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

  This should be an option - clearly some people will want to
  know if a function is not called at all.


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

  I think this is really a Tcl bug, but for the time being,
  it's probably a good idea to provide a workaround here.  The
  Tcl bug in question is this: 681877


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  I think you must be misunderstanding something.  The
  profiler makes no distinction between time spent "executing
  Tcl code" versus "executing C code".  In fact, practically
  speaking there is no way that it could do so.  I offer the
  following counter example as proof:

    package require profiler 1.6
    ::profiler::init

    proc testProf {} {
        after 3000
    }

    testProf
    testProf
    testProf

    puts [::profiler::print ::testProf]


  Here I have used the [after] command as a stand-in for your
  [C1] command.  Keep in mind that just like [C1], [after] is
  implemented in C code, and by definition, [after] takes some
  significant amount of time to execute.  When I run this in
  my interpreter, I get the following output:

  Profiling information for ::testProf
  ============================================================
              Total calls:  3
      Caller distribution:
    GLOBAL:  3
             Compile time:  3001000
            Total runtime:  9021000
          Average runtime:  3007000
            Runtime StDev:  5292
           Runtime cov(%):  0.2
    Total descendant time:  0
  Average descendant time:  0
  Descendants:
    none

  You can see that the time spent in the [after] command
  itself is clearly accounted for and billed to the testProf
  procedure.

  I happened to have my own Tcl extension here that implements
  several new commands, and I repeated this test calling those
  commands from testProf instead of [after], just to be sure
  that the profiler was not somehow treating built-in commands
  specially.  I obtained similar results with this experiment
  as well.


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

  Thank you very much Eric for your careful handling. I will
  work more with the profiler and let you know if I meet some
  special behaviors sometime.


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=456242

  (I seem to be having trouble attaching the file; email me if
  you need it)


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

  I bet that this was due to MD5 processing with the (new for
  8.5a2) arbitrary-length integers. The MD5 package was fixed
  to keep the calculation restricted to a 32 bit values size
  even when arbitrary length integers are available.


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

  Applied. Parts of jabberlib require 8.4 so there is no going
  back to 8.3 support now.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  As Tile v0.5 is being package required, there's also no 
  need for a check on the ttk:: namespace, and as the 
  namespace is being imported there is no need for the use 
  of ::ttk::scrollbar anyway (that the first patch was 
  changing tscrollbar to).


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  updated patch to current head.
  This patch removes the ttk:: and tile:: namespace checks 
  as Tile v0.5 has changed over to ttk:: fully.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  File Deleted - 133259: 



  File Added - 133295: tkchat.NickListv2.diff

  Logged In: YES 
  user_id=596509

  Updated patch.
  Found a problem in addAction proc, where it was creating a 
  new nick in the nicklist for bridged messages. (ie. it was 
  leaving '<' and '>' on).


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  File Added - 133614: tkchat.NickListv3.diff

  Logged In: YES 
  user_id=596509

  updated for current head. v1.287


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

  In your example, are transmitter and receiver of the
  commands in the same process ? Have you tried this across
  different processes ?

  I am trying to understand the exact nature of the problem,
  and the examples given are a bit short.

  For example I do not see described where any of the errors
  is reported, in the client, or in the server process ? That
  does make a difference for the sync and async calls.

  Note also that 'after 1000 comm::send' is not async call. It
  is delayed invoked in the client, but the communication is sync.

  Async communication is 'comm::send -async {...}'.


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

  Confirmed for the HTML tarball. However the Windows CHM is
  ok. This has to be a glitch in the ActiveTcl build system,
  not in tklib itself. Please report at the ActiveState site.
  The tktable problem has already been reported at the
  Activestate site.


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

  Hi Andreas,
  I will if you can provide a link. Following advice I got at
  clt I already tried to find the correct place at
  activestate.com to submit it there, but didn't see anything
  obvious.
  Thanks
  Helmut Giese


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

  Hm. I am quite sure that I would not use a report object to
  convert a matrix to csv. That can be done much more
  directly. Get all cells of the matrix, which is a list of
  lists, then iterate over the outer list and use csv::join to
  generate the csv lines, [join] them. ... I better pack that
  into a utility procedure.

  Are there any other use cases there a report with a
  right-ragged column makes sense ?


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

  proc ::csv::joinmatrix {matrix} {
      set csv {}
      foreach line [$matrix get rect 0 0 end end] {
  lappend csv [joinlist $line]
      }
      return [join $csv \n]
  }


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

  Oops. I was to quick, buggy. It is much simpler.

  proc ::csv::joinmatrix {matrix} {
      return [joinlist [$matrix get rect 0 0 end end]]
  }


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

  Confirmed. Difficult to solve. We have to protect special
  characters in the string we try to flatten while stripping
  out a listlevel. The latter _requires_ eval, not using it is
  not an option.


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

  A fix has been committed to the CVS head. The testsuite has
  been expanded to cover this, and similar cases.


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

  Cross-reference. See patch
  http://sourceforge.net/tracker/index.php?func=detail&aid=1254934&group_id=12883&atid=312883
  for a possible solution.


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

  The test case attached to the patch definitely shows the
  \r\n's added to a part, by part creation, and part composer
  repectively.


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

  The original patch was incomplete, a new patch has been
  added to the cross-referenced entry. Please test.


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

  Committed the patch, this should be fixed now. In the demo
  of the x-ref entry it is.


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

  mime::getheader $token  returns a list of header value pairs.
  getbody doesn't make sense for a multipart message.


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  > getbody doesn't make sense for a multipart message.

  ?? Then how do I combine the mime and http packages
  to implement HTTP form data?  The http package wants
  the body separately.  At least that was the case when
  I filed this RFE, I admit that haven't looked at the
  issue since.


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

  Confirmed the problem. All other .msg files are ok. Note
  that the fr messages are incomplete as well. Compare to
  c.msg which also has the TOC and IDX related messages.

  Fixed, and committed to head.


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

  This is a problem for Pat. He maintains the md5 critcl
  stuff, and has possibly integrated it into smtp. It might
  also be a problem in the md5 package itself.


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

  Does this still happen with the current CVS head of Tcllib ?

  The only place I can think of where this can happend is the
  procedure "md5_init" in smtp.tcl. Can you check that this
  procedure is executed ? It does a regular "package require
  md5". Was md5 loaded before ? If yes, what version. If not,
  then we are likely getting v2, which is in md5/md5x.tcl, and
  it tries to load md5c in md5::LoadAccelerator. However this
  procedure catches any error from that, so you should never
  see the 'no package md5c' error.

  This part is however something which was rewritten some time
  ago, so maybe the old way of looking for md5c did fail.

  Hence my question at the beginning.


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

  I'm going to junk this. I've never seen this occur and there
  have been no other similar reports
  Also, I'm just removing all the authentication code from
  smtp.tcl and replacing it with code that delegates to the
  SASL package for this purpose.


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

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

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

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

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

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


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

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


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

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

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

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

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


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

  Mistake - Quite likely. So you have code like

      [subsection FOO intro.history.ancient]

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

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

  ? (The second would be the LaTeX approach).

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

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

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

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

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

  Will do some more thinking.

  Thanks for the comment.


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

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

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

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


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

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


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

  I'm not sure how to fix the problem.  In the mean time, I
  added a note to the man page that %W does not work.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is by design. An access to the label window path is not prevued.
  Instead use the returned node id and the provided functions to manipulate the node.

  I removed the remarks in the docs about that.
  IMHO this should not work. We are on a higher level here.

  Technically, canvas items have no window paths and thus could not be returned.

  Please reply in case of other opinions.


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

  OK. RFC 2821 sec 3.7 agrees. Fix committed. The core server
  will accept such addresses and the programmer can then
  decide what to do in the validate_sender procedure.

  The example smtpd code will reject such mails.


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

  Closed as duplicate, requested by Don.
  The original RFE is

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


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

  This is a duplicate to:
  http://sourceforge.net/tracker/index.php?func=detail&aid=870429&group_id=12883&atid=112883
  Bug: 870429.

  Michael


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

  to win :

  html::init {text.size ""}
  puts [::html::textInput "txt" "myValue" {size="23"}]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, very nice bug report.

  Specially, because some lines upwards, the non-existance case is handled in a similar way.

  Updated in cvs.


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

  This is not a bug, but a request for enhancement. I am
  rejecting this request as featuritis we should avoid. It is
  easier and simpler, IMHO to simply negate the condition in
  the used filter command. I should also mention that I
  believe that the number of options lsearch has is already
  way to high, i.e. it makes a bad example to convince me.


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

  I have been able to trace this problem down to 
  the ::ftp::CopyNext routine and the StateHandler routine. 

  The CopyNext routine will always unset ftp(state.data) 
  once the transfer is complete or there is an error.  Then 
  the StateHandler routine in the put_sent switch arm, will 
  try to unset it again if the return code is not 1 or 2, 
  and it's passive mode.  

  All that's needed to fix this is either a catch, or a 
  cleaner way would be something like:

  if [info exists ftp(state.data)] {unset ftp(state.data)} 
  in the StateHandler routine.


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

  Thank you for tracking this down. I went the easy route of
  wrapping the offending command into a catch. The code had a
  lot more of them, in basically all of the xxx_sent states. I
  decided to wrap them into 'catch' as well for good measure.

  This has been committed.


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

  I think you have interchanged the first two arguments: first
  the x values then the y values.


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

  OK. Simpler is to give -maxlen 0 to the base64::encode
  command to turn off the wrapping functionality.

  I'm not going to do this to DIGEST-MD5 unless there are
  reports of similar problems.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I checked it on Windows and Linux - works for me.

  Could you please check, if there is still an issue ?

  Thank you,
  Harald


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  allow_comments - 1

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


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

  Fixed the message used for SNTP - as TIME servers don't care
  what message they get we will send the SNTP request to TIME
  servers too.

  The module is for network time protocols (hence the
  directory name) and the first one implemented was for the
  TIME (RFC 868) protocol. It turns out that there are
  insignificant differences between the implementation for
  TIME and for SNTP (RFC 2030) so I left the package as 'time'
  and just added a 'getsntp' api.

  I don't see any good reason to restrict the SNTP usage to
  UDP - but I have added comments into the man page to point
  out the likely requirement for UDP. In theory SNTP could be
  operated over TCP and I note that the services file reserves
  port 123/tcp and 123/udp for ntp.

  Added support for ceptcl in addition to tcludp for UDP support.
  I've checked the new implementation against ntp2a.mcc.ac.uk
  and ntp.blueyonder.co.uk for SNTP access along with a local
  server running OpenBSDs minimal NTP server.


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

  Sorry forgot to include version number.

  tcllib-1.7

  I believe the solution should/would be to have the Makefile
  install target pass the ${prefix} and ${exec-prefix} to the
  install.tcl script

  Instead, it appears to be taking the name of the tclsh program.

  Thanks.


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

  Arjen, this is likely not a problem in the installer, but in
  how you updated your tcllib workspace. My guess is that you
  used a plain  "cvs update", right ?

  You have to run "cvs update -d" to ensure that any _new_
  directories in the CVS are created in your workspace as
  well. -d for directory. A plain update ignores new
  directories, which is bad. And the fully proper way is to
  use "cvs update -dP". The -P option ensuring that
  directories which were emptied in the CVS are removed from
  your workspace (Prune).


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

  You are (of course) completely right: I always do "cvs
  update" without any options. Hm, it looks like I should
  change that habit to "cvs update -dP"

  Arjen


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

  Yes, definitely. To not have -dP as defaults is IMNSHO a
  misfeature of the cvs client.


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

  It doesn't seem to me to make any difference to the output.
  I tried to create a test for this condition and plumped for
  test mime-9.0 {bug 1254934} {
    list [catch {
       set toka [mime::initialize -canonical text/plain
  -string testing]
       set tokb [mime::initialize -canonical
  application/octet-stream \
             -string [string repeat \0 160]]
       set tok [mime::initialize -canonical multipart/related \
            -parts [list $tok1 $tokb]]
       set r [mime::buildmessage $tok]
       mime::finalize $tok -subordinates -all
       set r
    } res] $res
  } {0 {}}

  Checking the output with and withouth these "\r\n" appended
  makes no difference to the buildmessage output.

  Can we get some sort of test case that shows the problem?


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

  Erland, please provide a test case or example of the bug,
  and how it is fixed by you patch.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  The test case is a bit complicated - it involves setting up
  a web server script (I use PHP) to receive an uploaded file,
  and calculate a checksum which will differ from the sent file.

  The Tcl code is fairly cumbersome to handle HTTP headers and
  what not.

  I need some time to extract the relevant functions from my
  code and construct a nice, minimal test case, maybe with a
  PHP script as the client. I will be revisiting the upload
  part of my project soon, I'll get back to you with the test
  case. 

  Thank you for your attention.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Ok, here is a demonstration of the problem.

  This Tcl program (testMIME.tcl) uploads a file
  (transferFile.txt) to a web server (currently connects to
  one of my servers, I will also post the receiving PHP script
  so you can put it on the server of your choice).

  The program will print the size of the file, and then show
  the response from the web server. In my case I created a
  text file with the word 'Hello'; the Tcl script reported a
  file length of 5, and the HTTP server a file length of 7.

  You will have to create the transferFile.txt.

  I believe my patch fixes this discrepancy.

  FWIW, I wish Tcl's http class had a method for doing this.
  The code in testMIME is taken from examples on the Tcl Wiki.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Does anyone have the time to look at the testcase (if you
  have a PHP5 web server, then it shouldn't be too hard)?

  As I believe this is a bug in the Tcl MIME handling, that I
  believe I fixed in August, if would be nice if someone could
  take the time to hopefully approve it and get it checked in
  (or comment on any objections).


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

  Running the tet script I see the webserver reporting an
  11-byte 'hello world' as 13 byte. Adding more logging of
  values to the script I find:

  The part generated in 'form-data-add_binary' seems to be ok.
  It has \r\n at the end, this however might be very necessary
  to put the separator line later closing the part on its own
  line.

  However the message then composed from all the parts, in
  'form-data-compose' has an additional \r\n before the
  separator line.

  There seems to be a disagreement between parts and their
  umbrella which of them has to add the \r\n for the separator
  line to the whole message. Now apparently both do it.

  It is unclear if this happens only for encoding binary.
  This has to be tested.

  I wonder if the problem is that the binary part is not
  generated with some 'size' information in the headers.


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

  Cross-reference: See bug report
  http://sourceforge.net/tracker/index.php?func=detail&aid=1213527&group_id=12883&atid=112883


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

  Tried out the patch and have to report that the provided
  patch does NOT solve the problem. The path in question in
  question is actually not used at all by the demo ...

  Now trying to find the code paths actually used.


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

  Note: Whatever we do to buildmessage and helpers we will
  likely have to replicate for copymessage and helpers as
  well. 'build...' is for getting a string, 'copy...
  ' writes directly to a channel. Structurally they should
  work identically.


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

  The command is 'buildmessageaux'. It has a 3-way switch for
  file, strings, and parts. The patch modified the 'file'
  branch. Modifying the 'string' branch provides the desired
  result. Given the structural similarty the fix to the file
  branch is likely right as well, just not used in the example.

  An alternate fix might be to change only the 'parts' branch,
  as that is where the \r\n in fron of the separator line is
  added.

  This depends however on what a plain part would look like,
  outside of a composition. Gut feeling tells me that making
  the change in parts is wrong.


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


  Ah, slogging through the relevant RFC's showed the solution.
  According to RFC 2046 the \r\n before the boundary itself
  belongs to the boundary, not the body, so changing the
  'parts' branch is out. It has to be 'strings' and 'file'.

  I will make a new patch and upload it here.


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

  Aamer,

  I have to delete this entry. The inlined manpage is
  unreadable (*) in both the HTML and in the notification
  mails generated by SF. And the latter has the additional
  problem of causing SF to mail _very large_ mails around, as
  it duplicates the whole comment thread, including your large
  initial manpage.

  Please refile this report, and attach not only
  ipExtension.tar.gz, but also the manpage.

  (*) I am not sure what format the manpage is in, but it is
  not a plain text format. Possibly *roff output ? If so,
  attaching the file is again the right thing to do.


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

  Pat, pretty please give me an opinion if this can be added
  to Tcllib, or if additional work/polishing is needed to
  bring it to up to our standard.


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

  Decided to accept the code and integrated it. Committed to
  CVS head.


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

  The two constants '0' and '1' have been defined in each
  high-level proc.
  The test suite was improved with new tests, including tests
  not devoted to this evolution. (division, modulo, remainder...)

  A hook (_treat) was created to handle the constants :
     _treat var ?var ...?

  Replace each variable named 'var' by the internal
  representation if it is equal to one of the constants : '0'
  or '1'. If the variable is already in internal repr, nothing
  is done.

  Please close this feature request, or tell the issues, if
  they are some.


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

  I was thinking about this myself for -validatemethod.  I
  wanted to be able to allow things like:

  option -place -default center -validatemethod [list ListOf
  $placeValues]
  option -modal -default none -validatemethod [list ListOf
  $modalValues]
  ....


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

  The current behavior is as it is by design; there was considerable discussion
  on the Snit mailing list about at the time.  I forget the details; you can find
  them in the Snit mailing list archives (which you can find via the Snit
  home page, http://www.wjduquette.com/snit).

  As for the -validatemethod, it will soon be deprecated; it's being replaced
  by a "-type" option.  I've got the code written and will be starting on the
  documentation updates this week; the new version will be included in
  the Tcllib release for this year's Tcl/Tk conference in October.


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

  Note that "option -type" is now available in CVS.  As for updating -
  configuremethod and -cgetmethod as described here, I'll have to think about it 
  some more.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is for instance only used with the parameter -message of MessageDlg which is renamed to -text.

  Test script:
  MessageDlg .d
  Sets option:
  -> option add *MessageDlg.frame.msg.message  widgetDefault
  When applying the proposed patch, this is:
  -> option add *MessageDlg.frame.msg.text  widgetDefault
  Which sounds reasonable.

  OK, updated in CVS.


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

  My problem is that I currently have no good idea for the
  commands needed to define tables. Not sure if the HTML style
  is good enough, or if something more like TeX should be used
  ... How far do we wish to go with cells spanning multiple
  rows and/or columns ?


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

  HTML, Latex, tbl (nroff) and docbook all support column
  headers, boxes around the table, framing each entry,
  multiple column spans, multiple row spans, highlighting
  entries (bold, italic), and some other features.

  I'd be happy starting out with defining a table in each
  format engine's default form.  Then it should be straight
  forward to add other features later.

  All of the engines define tables with commands for each row
  and cell entry.  We could have a syntax with commands for
  each row and element, but this would be pretty verbose.  I
  would vote for one command per row, or even one command per
  table, something like shown at the bottom of
  http://wiki.tcl.tk/3150 (Displaying tables).

  [begin_table]
  Quantity                Unit Name    Abbr.
  Length                  meter        m
  Mass                    kilogram     kg
  Time                    second       s
  [end_table]


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

  Is the column separator in your exmaple multiple spaces, or
  tabs, or one space, or a mixture ? ... Wait, one space
  cannot be a separator in your example, see 'Unit Name',
  which is in one column.

  Maybe several table commands, from the most primitive to one
  which supports lots of features ?


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

  Oh, drat.  I meant to quote "Unit Name" as a single word. 
  And now that I look at it, I've got the begin/end backwards too.

  If I was going to make up a syntax, then I'd try to parallel
  manpage_begin/end and list_begin/end.  Both mark the start
  and end of blocks, and other doctool commands are valid
  within the block.  I like the simplicity of using Tcl's
  natural line and word boundaries to denote row and element
  breaks, but I can imagine optional row and element commands,
  [row] and [elem], and a special command for the header row,
  [header].

  Although a few doctool commands have optional arguments,
  none of them have Tk-style options.  But I think that would
  be the best way to implement table appearance features. 
  Options to [table_begin] would apply to the entire table. 
  Options to [row] would apply to the whole row, and options
  to [elem] would apply to just that element.  Just for fun,
  include a [columns] command, which takes a list of option
  lists, and applies them to each column in the table.  Common
  options would be

  -align {left center right}
  -colsep {true false}     draw a line to the right of the cell
  -rowsep {true false}     draw a line below the cell

  Options just for [table_begin] would be

  -title "table title text"
  -frame {all bottom none bottom sides top topbot}

  And I've grown fond of grid's relative placement syntax, so
  I'd use that to denote entries spanning more than one column
  or row.

  So without careful declaration of all the syntax, I present
  some examples of how you might use these commands.  For
  starters, apply some global formatting to the table with
  attributes supplied to [table_begin].

  [table_begin -align left -frame none]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  [table_end]

  Generate the same table, but center the rightmost column, so
  we need both [row] and [elem] commands.

  [table_begin -align left]
  [row Quantity      "Unit Name"  [elem -align center Abbr.]]
  [row Length        meter        [elem -align center m]]
  [row Mass          kilogram     [elem -align center kg]]
  [row Time          second       [elem -align center s]]
  [table_end]

  But if we have a [columns] command, then we can apply
  formatting to just the third column.

  [table_begin -align left]
  [columns {} {} {-align center}]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  [table_end]

  Same table, but use a special [header] command for the first
  row, which might give it special highlighting.

  [table_begin]
  [header Quantity   "Unit Name"  Abbr.]
  [row Length        meter        m]
  [row Mass          kilogram     kg]
  [row Time          second       s]
  [table_end]

  Create an entry in the second column which spans two rows,
  using the [grid] command's relative placement code.  This
  will render the "meter" entry in a box that is two rows
  high.  In the case of nroff format, it will probably leave a
  blank line.  This implies quoting single characters of ^, x,
  and - somehow, to avoid the special meaning.

  [table_begin]
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass            ^          kg
  Time          second       s
  [table_end]


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

  Huh. I'll have to think about the various examples ... First
  "-quoting in regular text is not something the frontend
  recognizes. It is simply passed to the backend. This is
  important because all structural stuff should be in the
  frontend, and nothing in the backend. ... In your example I
  would have to handle the text between the table begin/end
  markers as a CSV, apparently. Except when the row/elem
  commands are used ... Definitely not easy to parse ...

  More thinking required.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  Almost Free Text (http://www.maplefish.com/todd/aft.html),
  txt2html
  (http://txt2html.sourceforge.net/txt2html.html#input_file_format),
  and txt2tags (http://txt2tags.sourceforge.net/rules.html)
  have methods of supporting table output based on character
  markup coming in.

  Just to show some examples of how other processors handle
  the task.


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

  Thanks for the examples, David.  I see that from these, and
  the others with which I am familiar, just about everything
  requires some sort of delimiter between column entries.  And
  I've also looked at how the formatting engines handle lists
  and examples.  

  It appears that for the "plain" formats I suggested, using
  line delimters for rows and word delimiters for columns, it
  would be necessary to have fmt_plain_text change modes of
  operation in a table environment.  This is presently only
  done for latex examples (as far as I looked).  So it would
  take a global (i.e., _in_table) and a switch inside of
  fmt_plain_text to make it work.

  It would also be possible to only support a single-command
  format for a  table, much like the short form of example. 
  So your table would be created with something like:

  [table -align left -title "Units Abbreviations" {
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  }

  This has the advantage of having all the table data in once
  piece, so you can compute column widths for text formats. 
  Your choice as to using Tcl words or a special delimiter
  character to deliniate column entries, but I think I still
  prefer words, just because it seems tclish.


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

  This looks pretty good. First some performance comments
  - All [expr] expressions should be braced - [expr {....}]
  - Avoid excessive [expr] eg: if {[expr ...]} is better
  written if {(...)}
  - You can copy arrays quickly using [array set tempState
  [array get state]]
  - The inverse sbox function is twice as fast if we use a
  table lookup.

  by making the above changed changes can speed the encryption
  from about 26000ms per iteration to around 8000ms per iteration.

  Second I would think the programming API should be closer to
  that used for rc4 and blowfish in tcllib. I would rather see
  an aes::encrypt and aes::decrypt pair - but more importantly
  I think we should be able to do:
   set key [aes::Init $secret cbc]
   while {receiving data} {Output [aes::Encrypt $key $data]}
   aes::Finish $key
  in other words maintain all state in a opaque token that is
  created by Init and cleaned up by Finish and permit calling
  Encrypt or Decrypt multiple times. This fits well with use
  with network channels where we want to use the
  Encrypt/Decrypt call in the fileevent body on chunks of data
  read from the stream.

  It is also important that we can do ECB and CBC mode
  encryption - it's not specified anywhere what mode is being
  done here and I've not tried to work it out yet.

  Attaching my performance enhanced version.

  Nice job though. :)


login: fattobi
username: fattobi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1333726

  Thanks for the quick response and performance improvements.

  At the moment, there is no chaining of blocks implemented,
  just one block gets en-/decrypted.
  I will work on the API, but don't expect it done too soon.

  Thanks for your help,

  Thorsten


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

  Imported into CVS so that we can properly maintain the
  history of this code. I will try and fix the programming
  interface before we release the next version of tcllib.
  Fixing the API should also make supporting CBC mode simpler.
  New module: aes


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

  Integrated with CVS head. some shuffling, utilities are in
  their own namespace, not "::logger".


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

  The math tests are a likely source of changes to
  tcl_precision. We can check this by

      tclsh sak.tcl test math units

  Confirmed. The above is enough to cause the unit tests to fail.
  We should bring "sarnold75" and "arjenmarkus" into this.


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

  Grepping ...

  bigfloat, calculus, lingalg, optimize are the math packages
  whose testsuites change tcl_precision.


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

  This can be fixed by setting tcl_precision back to the
  default in units.test.  This would work around the side
  effect from other unit tests.

  Perhaps a different solution would be to have the math
  libraries reset tcl_precision to the default after they are
  done with it.

  But the real root of the problem seems to come from tcllib's
  all.tcl, which goes to great length to run all the module
  tests in a slave interpreter.  Since all interpreters share
  tcl_precision, it leaks between modules.  It is also leaking
  ::env, and this scheme may also have trouble with tests
  checking -output and -errorOutput.  This might be causing
  the errors in docstrip.test.

  So why doesn't tcllib just execute tcltest::runAllTests,
  like everybody else?


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


  Even with [runAllTests] these
  leakage issues ought to be
  addressed to support the
  -singleProc 1 configuration.


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

  runAllTests - Likely for historic reasons.

  Note however also the insertion of special test contraints,
  and helper commands. IIRC these are not done by runAllTests.
  I would say that this should be reported in a new entry, and
  investigated separately from these failures.

  I agree that the math tests should take care to restore the
  tcl_precision.


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

  The tests check these branches. The if branches seem  to not
  trigger correctly and the value is formatted by the next
  larger range with the wrong extra padding.

      if {($number >= -8388608) && ($number < 8388608)} {
          set numberb [expr {$number & 0xFFFF}]
          set numbera [expr {($number >> 16) & 0xFF}]
          return [binary format H2H2cS $tag 03 $numbera $numberb]
      }
      if {($number >= -2147483648) && ($number < 2147483648)} {
          return [binary format H2H2I $tag 04 $number]
      }
      if {($number >= -549755813888) && ($number <
  549755813888)}     {
          set numberb [expr {$number & 0xFFFFFFFF}]
          set numbera [expr {($number >> 32) & 0xFF}]
          return [binary format H2H2cI $tag 05 $numbera $numberb]
      }

  This is entirely strange..., kann someone please check that
  if is sane on solaris..., basically this check fails:
   
      set number 8388608
      if {($number >= -2147483648) && ($number < 2147483648)} {
             puts "ok"
      } else {
            puts "bad"
      }

  I do not have a solaris box to test on...


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


  Thanks for looking into it.  The
  bug is in Tcl 8.5a4, now reported
  as 1274287.  You'll want to keep
  an eye on it.


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

  Still an 8.5 specific problem, different (default)
  precisions. Should we  use 'format' to round the value to a
  specific precision ?


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

  Went with my idea and used 'format' to get results with a
  deterministic precision across all versions. Committed.


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

  The difference is in the floating point values of
  FocalPlane(X,Y)Resolution. In Tcl 8.5 the value has several
  more digits.

  We are not tracking this until the Tcl 8.5 numerics have
  stabilized.


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

  Went with my idea and used 'format' to get results of a
  deterministic precision across versions. Committed.


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

  I could not reproduce the bug : I ran the testsuite successfully
  My environment is ActiveTcl 8.5a3 and Tclkit85a2 on WinME.

  Please, could you grab the latest 'bigfloat.test' from CVS
  and make a more precise bug report.
  Could you also give a short description of your environment.
  But the best thing would be to isolate *one* command that
  failes in your environment.

  Regards,
  Stéphane Arnold


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


  Thanks for the renumbering.

  The failing tests are 2.6c and
  2.6e.

  This is with the latest HEAD
  of Tcl development sources, 8.5a4.


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

  I found the reason : it is a bit strange, but
  in Tcl 8.5a3 :
    expr round(0.5) gives 1 and
    expr round(-0.5) gives -1
  and in Tcl HEAD 8.5a4 both expressions return 0.

  Should we close this bug report and submit one in Tcl.sf.net?


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


  the change in Tcl 8.5a4 is likely
  an intentional change away from
  the (arguably buggy) biased
  rounding rule "0.5 rounds to the
  integer with greater magnitude"
  to the unbiased rule "0.5 rounds
  to the even integer".

  A bug report should still be opened
  on the topic, so it's clear that there
  are at least test scripts that do care
  about the change.  You should also
  review just what it is you are trying
  to test and whether it can be done
  in a manner not sensitive to this
  fine detail of Tcl's rounding rule.


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


  With Tcl 8.5 HEAD, these now fail
  in a different way:

  syntax error in expression " $msg == Infinity ": extra
  tokens at end of expression


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

  This happens specifically with Tcl 8.5 (I tried on
  Sun/Solaris with Tcl 8.4.3 - that worked fine. It also
  worked on Windows XP with Tcl 8.4.1 and 8.4.5)

  Something is seriously wrong then! 


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

  dgparjen, miguel: just a guess, but 1272910 is likely a
  tcl_precision sensitivity getting exposed.


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



  It appears that fixing Tcl
  Bug 1275043 has fixed this.
  Please confirm and close.


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

  I can confirm this: tclkit 8.5a4 returns the same result as
  Tcl 8.4. So, indeed: closed


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

  Oh, oh, the profiler is using clock internally, and in 8.5
  they are procedures and thus show up in the trace. Hm. I am
  not sure if we can exclude them, as they may _also_ come in
  due to the profiled code.

  So maybe just using a version dependent test result to fix
  this ?


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


  simplest thing would be a more
  forgiving match like -match glob
  or -match regexp.


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

  Duplicated the test. Original constrained to 8.4-, new
  variant for 8.5+ with changed result. Committed.


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

  This looks like Tcl bug #1220058.  It has to do with having a rename trace 
  on a namespace ensemble that gets renamed out of existence.  This 
  should be transferred over to the Tcl bug tracker rather than the Tcllib bug 
  tracker.


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

  The non-Trf versions use ` as this is the 0 byte
  representation and this follows other uuencode
  implementations (notably perl's pack('u', ' ');) The tilde
  character is invalid which makes it helpful in recognising
  excess bytes but may cause interoperability problems for
  other decoders. In standard usage each line is prefixed by a
  byte the gives the length in bytes of the relevant data so
  the choice of padding should not be too important.

  Interestingly I looked for a standard and found IEEE Std
  1003.1-2001 gives a specification for uuencode which
  specifies = as the padding character! Solaris'
  implementation is using a space.


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

  In other words, this area is even more of a mess than I thought.
  :(
  Ok,  I will consider this a low-prio thing then.
  Get to unconfuse the testsuite first/only.

  Hm. Might make sense to choose a padding character we can
  easily detect later and then convert into whatever is needed
  for compatibility when the result is used in specific tools,
  like uuencode.


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

  Ok, I committed a change which deconfuses the testsuite's
  belief about which accelerator is loaded and active. Keeping
  this open for dealing with the padding mess, retitled entry
  for that.


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

  Accepted and committed the patch. I also added an "unset v"
  statement after the loop, as the variable is not really
  needed after the initialization.


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

  We now provide a jabber accessible pasting site at
  paste.tclers.tk so we should hook up to send messages to
  there. It replies with the new URL.


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

  Added a dialog and menu items to send clipboard or pasted
  text to the paste.tclers.tk site.


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  I get the same problem here while just sending mail (I am not doing 
  anything with dates myself).  Smtp.tcl calls 
   
    parsedatetime -now proper 
   
  and that throws an error, just because I am on de_DE. There is no 
  valid reason for that to happen here, I think. 
   
  I don't know if the other parts of parsedatatime are a 
  problem or not, they are not used in mime.tcl or smtp.tcl. 
   
  I trivial fix for "parsedatetime proper" is to use an ISO-style time 
  spec instead: 
   
    set gmt [clock format $clock -format "%Y-%m-%d %H:%M:%S" \ 
                       -gmt true] 
   
  This works with 8.4.7 here. 


login: cc_benny
username: cc_benny
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=143885

  Ah, I see that the OP already mentioned this kind 
  of patch. 
   
  There are more problems though, because the 
  formatting part of "parsedatetime proper" is also 
  broken. 
   
  I have posted a patch on the patch tracker as 
  #1312869. 
   
  Note: I see that the same bug has been reported 
  as #911580 in 2004. 


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

  Adding the patch file from the patch entry. It is not clear
  to me why asnother entry was opened. Files/patches can be
  attached everywhere.


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

  Nuts. Fixed the fault. Should really ensure that both critcl
  and non-critcl paths are tested with windows.


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

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

     set a [$object info self]

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

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

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


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

  Consider:

  package require snit

  snit::type Y {
  }

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

      constructor {
  install Y using Y %AUTO%
      }
  }

  X x;

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

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

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

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

  Colin.


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

  OK, I see what you're after.

  In your example, "x y" can't return the Y object's name; I'm using
  [namespace ensemble] for the dispatch now, and [namespace ensemble]
  requires a subcommand.

  Yes, "info self" would give you what you want; and it would certainly
  be easy to do.  I'll think about it.


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

  Using the CVS Head of Tcllib I am unable to reproduce this.
  I used Tcl 8.3.5.
  I also used tclsh together with vwait, instead of wish.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  I understand it doesn't happen under tclsh in 8.3.5
  but that's not the environment I have to support, which is
  wish 8.3.4.

  When I get a chance I can try upgrading to 8.3.5 but it won't
  be soon.


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

  I understand, however from my perspective it is a quite
  likely a bug in the tcl core tripping comm, seeing that
  8.3.4 does not work, yet 8.3.5 does, with comm unchanged
  between the two. And that is something which is difficult to
  impossible to work around.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  OK, thanks for investigating and explaining. I will try to 
  schedule time to attempt an upgrade to 8.3.5. In the 
  meantime I will have to install comm4.0 in parallel with
  comm4.2 and load that version explicitly when running under 
  8.3.4.


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

  I believe the problem is that the makefile target
  install-libraries does not define the option -app-path, and
  so takes a default directly from the executing tcl shell.
  This was fixed in the CVS Head at March 25.


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

  Very bizar when I change the line to 

      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 1]
  OR !!!! (it does not matter???)
      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 0]

  Both work FAST ??? (Via Solaris tcl_patchLevel  8.4.5)


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

  Added to CVS Head. Added documentation, which was missing,
  and a tiny testsuite for nl2br.


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

  This is actually already fixed in the CVS. The application
  manpages are installed in the same location as the package
  manpages.


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

  This is also fixed in the CVS Head of Tcllib. installer.tcl,
  line 167ff


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

  However internal results can still be larger than int, right ?

  Should we care ?

  How much performance do we lose for pre-8.5 Tcl because of
  the additional conversions ?


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


  After TIP 237, you do not want
  to allow the computed numbers
  to grow without bound.

  Whether you limit them to 32-bits
  or 64-bits doesn't really matter, IMHO.
  (That's why I suggest int(.) as the 
  fix, without regard to what length that means)
  At either range you'll stick to computation
  that can be done with native types, either
  long or Tcl_WideInt.

  But without some limit, pretty soon
  you're chugging away on values literally
  thousands of digits long, just to keep the
  last 10 or so.  The small test suite literally
  runs for hours.

  Dunno about performace cost to 8.4 and
  earlier.  It's something that can be dealt
  with if needed though.


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

  Adding some extra ops to truncate seems to make it a bit
  slower with both 8.4 and the current 8.5 head. Using int()
  or &0xffffffff seem to be equally slow. 

  I'm going to rig it to switch on the interpreter version and
  try and get the fastest implementation that will remain correct.


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

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

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

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

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


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

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

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

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

  Thanks for the effort!


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

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

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

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


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

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


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

  Closing this, moved the attachment to the bug entry, where
  it truly belongs IMHO.


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

  It can be the struct module. You are likely using
  struct::tree, and for that one we have a critcl based
  implementation. I believed to have found and fixed all my
  overflow bugs, but apparently not.

  I do test the critcl struct::tree and that testsuite passes
  (I test both critcl and tcl impl., whatever is available,
  using the same tests. You know how, I copied this
  (LoadAccel, SwitchTo, etc basically from your test). I
  wonder what hmlparse is doing different to cause this.

  Use TCLTEST_OPTIONS='verbose bpste' to get motre information
  from the test run, i.e. which tests where started, passed,
  etc. This should give you a better idea where the crash
  happen at the higher levels.

  There is a way to activate memory debugging for critcl based
  code too. I have to dig this out.


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

  File tree_c.tcl is the main entry to the struct::tree critcl
  code. At the top we have critcl::cheaders/debug commands, so
  memory debugging should be on. however for -g to be handled
  correctly the 'critcl' application has to be modified a bit
  as well.

  File "critcl.vfs/lib/critcl/critcl.tcl". Line 612. Disable
  this line. "append cmdline ... -O2 ...".


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

  A first attempt at reproducing the crash failed. I basically
  loaded tcllibc, all the tcllib modules and ran the series of
  tree commands as generated by the html test suite. I mean, I
  ran the htmlparse testsuite and used logging to determine
  the sequence of tree commands, and their arguments. This log
  was converted into a script.

  As said before, this failed. The crash happens only from
  within the htmlparse testsuite :( The interesting result is
  that the first tree test fails. Not a crash, but different
  results. I.e. there is also a regular bug in the critcl tree.

  The crash can happen after the first test alone, but
  sometimes a bit later, when the second test is initialized
  or started. Looks really like an overwrite bug.


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

  The bug exposed by the first test may also point into the
  direction of the memory problem. The htmlparse does a
  Reorder. This is a walk which _also_ modifies the structure
  of the tree. This may invalidate data structures at the C
  level where I do not expect this, causing me to write where
  I should not. Note that the C code fails to do the reordering.


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

  The basic bug is one of refcounting. The object holding the
  name of the loop variable has refcount 1, and after the
  first loop it hold a different value. My guess is that is
  was reused when the loop body was compiled, for a different
  literal. This caused me to write to a different variable and
  the Reorder proc was always called for the node from the
  first iteration. This does not explain the memory problem,
  not really. Having the walker holding a reference to the
  varnames fixes this.

  ... further checking shows that this is likely also the
  reason for the crash ... We do not get any anymore after
  this fix alone.

  Will also have to rewrite the iteration over children, the
  way I am doing it now it can go boom if the structure
  changes, as it does here. The array can not only be
  reallocated, but also shrink, expand, invalidating the index
  I have into it. I have to use my sibling pointer (next). ...
  No, does not work. Not the same behaviour as the Tcl impl.
  ... Ah, I essentially copy the children in Tcl before I walk
  them, so their move to a node already processed has no
  effect ... I have to emulate that at the C level ...

  Done, for all dfs walks. The bfs walks are quite different
  and should not suffer.

  Still, we do need test cases for the behaviour of the
  struct::tree walkers in all modes, when children and parent
  nodes are moved around, added, and deleted during the walk.

  In this area, walking a tree while changing it at the same
  time, we may still have (crashing) bugs lurking. And stupid
  behaviour in general, even for the Tcl implementation.


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

  It's an endian-ness thing. Have to find a way to determine
  the byte order in the pre-processor.


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

  Added code to set the byte order macro. Tested with gcc and
  msvc on Windows and gcc on SunOS-sparc, OpenBSD-x86 and
  Linux-x86. Should be ok everywhere as we use tcl's idea of
  the byte order.


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

  The culprits for this are logger.test 3.0 and 3.1.

  Those basically should test if the default logprocs are
  called, which print to stdout, but do not really do it.
  Should probably be rewritten with the newer tcltest -output
  option, to check whats printed to stdout.


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

  Done - I left in messages about aborting the package when
  not found, though.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

  What do you mean exactly? I get:
  $ tclsh stooop.test
  stooop.test: Total 103 Passed 103 Skipped 0 Failed 0


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

  I got 

  Module:stooop
  modules/stooop/stooop.test
  env array elements created:STOOOPCHECKOBJECTS

  But now I see that this must be part of the tcllib test
  harness.  My mistake.


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

  Done. Disabled the commands only, no removal. May be needed
  in the future for debugging.


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


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

  still looking...


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

  Yes. I'm seeing this too -- on FreeBSD-6.0/amd64. Please, 
  advise. 


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

  I think, I found a fix. For some reason, attachments seem  
  disabled on this page, so here is the patch inline (be careful  
  of the white-space mangling):  
    
  --- modules/dns/ipMore.tcl      Fri Sep 30 14:03:58 2005  
  +++ modules/dns/ipMore.tcl      Tue Oct 18 01:15:38 2005  
  @@ -400,8 +400,9 @@  
   proc ::ip::maskToInt {mask} {  
       if {[string is integer -strict $mask]} {  
  -        set maskInt [expr {(0xFFFFFFFF << (32 - $mask)) &  
  0xFFFFFFFF}]  
  +        set maskInt [expr {(0xFFFFFFFF << (32 - $mask))}]  
       } else {  
           binary scan [Normalize4 $mask] I maskInt  
       }  
  +    set maskInt [expr $maskInt & 0xFFFFFFFF]  
       return [expr wide([format "0x%08x" $maskInt])]  
   }  
   
  This seems to work for me... 


login: aakhter
username: aakhter
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=736414

  The bug is currently assigned to me, but I don't have a 64 bit 
  system to work on this. Do I have write access to CVS to 
  commit this fix?


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

  Aamer, I have a 64bit system (linux/amd64) and have verified
  the patch as well. I will commit it in a few minutes,
  currently doing the admin work for it.

  Beyond that, yes, you do have write access to the Tcllib CVS
  at SF. It enabled that at the time I added you as a developer.


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

  Committed to CVS head. Only one change to the patch: The
  masking expression got braced.


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

  If only you did a PRE-release testing on a single 64-bit 
  platform :-( 


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

  Dude, I did plenty of pre-release
  testing, but you sneaked this module
  in just days before release, missing
  all the testing that was done.

  The closer to the deadline you make
  code changes, the less testing you
  can reasonably expect them to get.


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

  The fault is that [encoding convertto unicode $str] produces
  different byte-order output on sparc and intel. NTLM
  requires little-endian unicode strings.
  Fixed by byte-swapping on big-endian systems.


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

  The directory failures seem to be BSD specific. Solaris
  could have them too, as that allows to read a directory is
  if it were a file.

  Regarding /var/log/messages, what user were you ? IIRC this
  file is usually read-only root, i.e. unaccessible to anybody
  else. Right now I have now idea how fumagic will react if it
  doesn't have the permissions to read a file. You could try
  to make readable copies of messages and COPYRIGHT and try to
  get results for that.

  Have you also tried it on other text files, not only pictures ?


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

  file(1), when applied to a directory responds with 
  "directory" -- try `file /' on any system. 
   
  /var/log/message is readable to all on my system and 
  yes, I did try other text file (/COPYRIGHT, for example). 
   
  file(1) works properly: 
   
  % file /COPYRIGHT  
  /COPYRIGHT: ASCII English text 
   
   


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


  still fail in 
  - tcllib::testutils 1.1
  - fileutil::magic::rt 1.0
  * fileutil::magic::filetype 1.0.1
  (tcllib-1.9-rc1)

  on Solaris 9


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

  Fixed the test failures. Committed to head.
  Nothing done yet regarding /var/log/messages, copyright, etc.


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

  Does the Tcllib 1.9 RC2 have the same problems ?
  The foundations (programmed dialog) of the testsuite was
  changed completely.

  Urls to download the RC2 on the Tcllib-devel mailing list.
  Alternatively retrieve CVS Head. Identical modulo ChangeLog
  tags.


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

  Would you like an account on my FreeBSD/amd64 system?

  Please, send me your ssh public key and your /etc/passwd 
  entry. Yours,

         -mi


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

  Why the /etc/passwd ? would you not need only a user name
  and passwd ? The latter even disposable, chsnged on first
  login ?

  Otherwise, yes, interested.


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

  /etc/passwd does not contain the actual password (which I 
  don't need and you will not use anyway). What I need is 
  your login-name, your numeric ID, your preferred shell, 
  etc. All of this is nicely specified in the single line 
  of /etc/passwd. You'll get it by running something like:

  fgrep andreas /etc/passwd

  (substitute "andreas" with your actual login-name).

  And the SSH-key, of course. If you use PuTTY, it has a way 
  to export the key in the "OpenSSH format".

  You can e-mail this to me directly at 
  mi+sourceforge@aldan.algebra.com

  Yours,

         -mi


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

  I got my account and ran the testsuite. The problems
  reported here are gone now. Closing.


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

  Done. However only for the schemes which are actually known
  to the uri::split command.


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

  Good catch: that file only documents the old procedures 
  cov, fibonacci, ...

  I am not sure yet how to proceed: I would like to retain 
  the old documentation and point to the new stuff too.


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

  bug 1 was fixed on 4/2/05 i suggest upgrading to the latest 
  version before submitting a bug report. I will look into #2


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I think, this is fixed, does not happen for me on windows.
  Report, if this is not the case.

  Thank you,
  Harald


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

  Done. The new file is 'mime.bench'. The unstructured
  benchmarks have been removed now.


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

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


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

  Ah. I believe I understand. cpush creates a context, but did
  not initialize the location information for the context. And
  somewhere later the location data was accessed, and not
  present. Ok. Accepted the patch.


login: wart
username: wart
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=244388

  Now that I take a closer look, this isn't entirely correct.

  aclocal.m4 contains a pointer to config/tcl.m4, which is not
  in the source tarball.  However, configure.in doesn't
  reference any macros that would be in tcl.m4, so aclocal.m4
  isn't even necessary and should be removed.

  configure.in does reference a 'config' subdirectory which
  does not exist.  This directory should either be added or
  configure.in should be modified so that it doesn't look for it.


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

  BWidget no longer uses autoconf, therefore there is no need
  for tcl.m4.


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

  CVS version of configure.in was updated a while ago.  No
  idea why this case hasn't been closed yet.


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

  thanks for pointing out my mistake. I fixed this problem in
  removeComments and also in removeExif


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Please increase the version number of the package after this
  change.

  If package would have version 0.3, scripts which need
  working removeComments/removeExif may

  package require jpeg 0.3

  and fail immediately if user have buggy version of package
  instead of destroying user images.

  It is that very kind of changes which should be reflected in
  the minor version number, because it is even more than new
  functionality added - functionality which was destructive
  for user data, became useful.


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

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

  Happy New Year


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

  You are quite right. I have corrected the procedure angle 
  and I have added a procedure crossproduct.

  Thanks for reporting this.

  The new files are in CVS


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

  Confirmed, will fix.

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

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

  Michael


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

  What version of mime is this ?
  If it is not from Tcllib 1.8, can you try with Tcllib 1.8 too ?

  Also note: As you your are sourcing the files directly, in
  what namespace are your source commands ?

  Reason for my question: mime.tcl provides a package, and the
  package management _always_ sources such a file from within
  the global namespace. Because of this it is quite possible
  that mime.tcl contains tcl code which will only work for
  that environment, and not when the file is sourced within a
  different namespace.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  data_type - 362883

  Logged In: YES 
  user_id=302287

  This is more of a feature request than a bug.


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

  As for the errors in BWidget I was unable to recreate.  Is
  there an example script available?

  As for the BWidget demo I was able to recreate and then fix.


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

  The current ldap TLS code just uses a different port and
  wraps the connection into TLS. A different solution would be
  to do the ldap starttls handshake to setup a TLS connection.
  Its not hard to do and i have it nearly done.


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

  I'll submit an updated ldap.tcl (version 1.6), which
  supports StartTLS. Not sure if that does a graceful fallback
  yet, but should improve things.


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

  Added the new starttls code to the ldap module, which allows
  to upgrade a standard connection to TLS secured.

  As the LDAP RFC is more critical about validating TLS
  connections an automatic fallback to unencrypted is not a
  good idea. 

  Please have a look at the current code in CVS, I'll set the
  status to Pending, so it gets closed if there is no response.


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

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in
    his patch for [SF Tcllib Bug 1276561], see 2005-10-04 entry.

    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0. 
    * (parsedatetime): For month index, use "%m" + scan
  instead of
      wrong "%e".


login: clmcavaney
username: clmcavaney
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1425189

  Apologies - should have checked the CVS version first.
  Thanks for the rapid response though.


login: aldobu
username: aldobu
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=979524

  Just to push for a quick bug-fixing,
  I suggest an alternative solution:

  # change line 1836  (tree.tcl  v.1.52)
  # from
   set data(dnd,afterid) [after 200 [list Tree::_scroll 
  $path $scroll]]
  # to
   set data(dnd,afterid) [after 200 Tree::_scroll $path 
  $scroll]

  ** Tested with Tcl 8.4.12 **


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

  Bug still present in csv head (1.8 got rolled out, with it).
  The 'quick fix' by aldobu has the problem, that it will fail
  for widget pathes with spaces in it (though, widget names
  with spaces in it aren't best practice and will probably
  break BWidget at other places also). The fix in the original
  bug report looks OK. 


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Further investigation shows that 1.1 (from tcllib 1.6)
  doesn't work too.

  Offending function in both cases is log::loghex


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

  Followed your advice and removed the use of the log package
  completely. It simple enough to add useful debugging code
  when its really needed.


login: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=410366

  Here is the patch which seems to fix the bug:

  --- /usr/lib/tcllib1.8/sasl/sasl.tcl    2005-09-19
  16:12:39.000000000 +0400
  +++ /usr/local/lib/sasl1.0.0/sasl.tcl   2006-03-18
  21:24:10.736909032 +0300
  @@ -76,7 +76,7 @@
       set context [namespace current]::[uid]
       variable $context
       upvar #0 $context ctx
  -    array set ctx [list mech {} callback {} proc {} service
  {} server {} \
  +    array set ctx [list mech {} callback {} proc {} service
  smtp server {} \
                          step 0 response "" valid false type
  client]
       eval [linsert $args 0 [namespace origin configure]
  $context]
       return $context
  @@ -401,7 +401,7 @@
                   set realm [eval $ctx(callback) [list
  $context realm]]
               }

  -            set uri "smtp/$realm"
  +            set uri "$ctx(service)/$realm"

               set A1 [md5_bin "$username:$realm:$password"]
               set A2 "AUTHENTICATE:$uri"


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

  You get the message about 'no benchmarks' when specifying
  "-verbose". I have chnaged the default level now to 'warn'
  (from 'critical', and elevated the message itself from
  'info' to 'warn' as well.

  Regarding the splitting it might be better to simply make
  all keys fully fledged lists. That way we get correct
  quoting all the way.


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

  However, using lists as keys requires a full-blown rewrite
  of the internals, as that requires changes everywhere.


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

  Ok, did the rewrite of the internals, all keys are lists now.
  With that all issues have been addressed.


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

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


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

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


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

  also:

  modules/tie/tie_rarray_comm.test
  - tcllib::testutils 1.0
  - comm 4.3
  - snit 1.1
  - cmdline 1.2.4
  - tie 1.0.1
  * tie::std::rarray 1.0
  WARNING: cleanupTests deleting /local/src/tcllib/spawn...


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

  Maybe this is naive, but why not just use the clock
  functions' '%b' format option, which outputs the abbreviated
  month name?


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

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in his patch for [SF Tcllib Bug 1276561], see
  2005-10-04 entry.

  * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

  * (parsedatetime): For month index, use "%m" +
  scan instead of wrong "%e".


login: ricardoj
username: ricardoj
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=388133

  Ok, sorry not to double check on CVS. :(

  The problem using %b, is that command is locale specific, so
  if your system is in english then you get the correct answer
  for the month, otherwise not !


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

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


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

  This is a duplicate of
  http://sourceforge.net/tracker/index.php?func=detail&aid=1428544&group_id=12883&atid=112883


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

  Corrected this and extended the test suite. The problem was 
  that I used lists as either row vectors or column vectors, 
  thinking the difference would not be possible.

  It is, though. The [matmul] proc is adjusted for this.


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

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

  for this version. Should be changed to:

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

  to maintain compatability with tcl versions earlier the 8.4.

  Thanks,

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


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

  I believe this is actually a problem on your server. The
  script provided works fine (although you should add the
  following lines to get the To and From headers added)
    set from "\"$fullname\" <$emailaddr>"
    mime::setheader   $token From $from
    mime::setheader   $token To $to

  I have tried this using the files you attached to the
  ActiveState bug on a Microsoft SMTP server and on Postfix
  (on Linux) and both worked ok. If you want to test this
  yourself locally I suggest you add -debug 1 to the options
  for smtp::sendmessage. This gets it to record the SMTP
  conversation to stderr. 
  You might also try the sample smtp server that is part of
  tcllib itself. If you start the example server (wish
  tcllib\examples\smptd\tk_smtpd) and set the port number to
  25 you can ue your script and send mail to localhost as the
  server. This way you can see both sides of the conversation.
  It's possible that your server is using the SIZE extension
  and limiting SIZE to something very small.

  I am going to close this as works for me - but reopen if you
  have more information to add. 


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  Ok, seems I left out something. I am sending the email 
  through an external email server owned by a reputable 
  hosting company. I believe this may effect the outcome. So 
  I am re-opening this report and adding some new info. I 
  have attached a file that contains the smtp dump after 
  turning on the -debug flag, a code snippet used to send 
  the message and the tcl result error. Also, the mail gets 
  sent but it's truncated to something less than 10KB.

  Also, the machine that is running my program is the same 
  machine that I use for my personal email client 
  (Thunderbird). It works just fine for sending large email 
  bodies.

  Please let me know what you think. You might also try 
  sending a message to an external server and see what you 
  get. Please make sure to use a large file and ensure that 
  received file is approximately the same size. My test file 
  was 52KB.

  Thanks Patt


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  Oh, one more thing, the path you gave to the example smtp 
  server does not exist on my install of ActiveTcl 8.4.11.2


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

  Using information contained in your attachment I have sent
  myself the mime.tcl file (108K) using your script on a
  Windows XP machine and sending via your server. In all cases
  I have got the full file. I'll separately mail you some
  extra bits.


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

  I get the same error when sending mail attatchments bigger 
  than 6-7 kb. The smtp package stops the base64 encoded 
  part, sends a newline and a dot, then RSET and QUIT. (no 
  ending boundry)

  The error message is "400: error writing "sock244": invalid 
  argument"

  Here, a ethereal dump of the end of the conversation with 
  mail server:
  <dump>
  dWJ0eXBlL1RydWVUeXBlPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvRW5j
  b2RpbmcvQmFzZUVu
  Y29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9qL
  .
  RSET
  QUIT
  250 198182198 mailfe02 Message accepted for delivery
  250 SMTP state reset
  221 mailfe02.swip.net SMTP closing connection
  </dump>
  Looks like smtp tries to send rest of the data, but 
  allready has closed the connection.
  Rgds.
  Jesper


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

  In addition to my previously post.
  Just tested the setup thru sockspy, and the error didnt 
  occur. This could look like some socket issue in the smtp 
  package code.

  Rgds
  Jesper


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  This issue was resolved for me by Pat Thoyts. It turned 
  out to be an problem with the TCLs standard socket 
  implementation. Here's the solution:

  One last thing I thought of is there is an alternative 
  socket implementation for Tcl on windows - the iocpsock 
  extension provides a socket2 command. It was written as a 
  performance enhanced socket layer and uses the winsock 
  APIs rather than the BSD socket APIs. There is a slight 
  chance this might produce a different result for you. You 
  would use it by doing:

  package require Iocpsock
  interp alias {} socket {} socket2


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1373320

  This issue was not resolved. It appeared that it was 
  working because I move from the standard socket to the 
  iocpsock package which allowed a larger portion of the 
  email to be sent before something went wrong.

  I did some more testing and here's what I discovered:

  I went into the the smtp package and disabled the trf 
  package call. This allowed me to send large emails and 
  attachments but I was not happy with this solution so I 
  poked around some more and found that the tls package was 
  not installed on my system. I assumed everything needed 
  was there since I'm using ActiveTcl from ActiveState. 
  Those guys are usually pretty good about including 
  everything but I've since been informed that the package 
  was excluded from ActiveTcl due to export restrictions on 
  the crypt stuff.

  Second, if I send an email WITH "-usetls true" the mail 
  sends just fine (this is how Pat Thoyts was sending his 
  emails). However, when I send emails with "-usetls false" 
  it fails miserably and I get the dreaded iocpsock/sock 
  error!

  I'd like to see if you can send a large email soemthing in 
  the neighborhood of 1MB with the -usetls set to false. 
  There's obviously still something wrong with the way the 
  smtp package is handling the trf stuff.


login: dunkfan
username: dunkfan
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1183601

  FWIW, this bug has just appeared after an upgrade to tcllib-1.9
  tcllib-1.8 was/is working fine so I'll stick with it for the moment.
  System Win XP PRO SP2, iocpsock does not improve the situation. (tcl 8.4.13)
  Code is as follows:

  set token [mime::initialize -canonical text/plain -string $body]
  catch {smtp::sendmessage $token \
     -recipients $recipient\
     -header [list From $from]\
     -header [list To  $recipient]\
     -header [list Subject $subject]\
     -servers $email_server -usetls 0} error
  mime::finalize $token


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

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

  Thank you,
  Harald


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

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

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

  Thank you,
  Harald


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

  I was able to recreate the problem and fixed it using your
  suggestion.  Thanks.


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

  Proc NoteBook::delete might profit from a line like:
  unset data($page,width)
  although I am not sure this solves the trouble.


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

  My mistake. I've still got a memory leak, but a more careful
  look shows me that it's not the BWidgets notebook widget.

  However, the notebook does seem to leave some info in data()
  after deleting, as you suggest. This seems to clean it up
  without side-effects:

      # Clear out page-related info
      foreach ndx [array names data -glob "*$page*"] {
          unset data($ndx)
      }

  Thanks, and sorry about the incorrect diagnosis.


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

  I wish I could set multiple resolution. This is out of date,
  and fixed in the CVS head. See also the items 

  https://sourceforge.net/tracker/index.php?func=detail&aid=1403452&group_id=12883&atid=112883
  https://sourceforge.net/tracker/index.php?func=detail&aid=1425947&group_id=12883&atid=112883

  Changelog:

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in his patch for [SF Tcllib Bug 1276561], see
  2005-10-04 entry.
    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

    * (parsedatetime): For month index, use "%m" + scan
  instead of wrong "%e".


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=295103

  Forgot to mention - this bug report is for version 1.2 of
  widget::dialog. Tcl/Tk 8.4.12 on Windows XP


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

  Error recreated using your test code.  Correction applied
  via your suggestion.  Thanks.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Themes will be included in BWidget 2.0. This is IMHO not a bug but a feature request.
  So I will close the bug report here.


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

  The ugliness seems to be due to the wish interpreter
  invoked.  Using wish from /usr/bin/wish8.4 (OS X 10.4.7) I
  get the black background as per your screenshot.  However
  when I invoked wish from fink, the notebook's
  -activebackground seems to be set correctly.


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

  Investigated this further and it is rooted deep inside the
  implementation. Basically this is a user error that is uncaught.

  There is no easy fix to this, unless i completely rework the
  internal linkage structure.


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

  Although specifying multiple arguments may be a user error, I would like to see logger package support such multiple arguments. I need to pass multiple arguments so that my custom log proc can invoke argument specific actions. Consider the following example:

  ${f}::debug -subst {List of files = [glob -nocomplain *]}

  In above, the message is enclosed within curly braces so glob command is not invoked when debug level is disabled. However, if -subst flag is present and debug level is enabled, my custom proc can invoke [subst $msg] in the caller's context to get the list of files and print them in the log msg.


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

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


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

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


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


  If you're going to rely
  on alpha releases, you'll
  have to pay some attention
  to ongoing development.

  Are you confident that you're
  working with the actual 8.5a2
  release?  Or could this be
  a snapshot of the development
  sources taken before release?
  The 'changes' file reports:

  ...
  2004-10-08 (new feature)[TIP 201] "in" and "ni" expr
  operators (fellows)
  ...
  --- Released 8.5a2, December 7, 2004 --- See ChangeLog for
  details ---
  ...

  so any install of the actual 8.5a2
  release (or better yet, 8.5a3, or
  an 8.5a4 release candidate, or the
  latest development snapshot you can
  stand), ought to resolve the issue.

  If there's a bug here, it might be
  that things would be a bit better
  if snit could indicate its need
  for 8.5a2 or better, so that a
  [package require] might fail instead
  of a random command.  There are
  two obstacles to that.

  First, the [package] command fails
  to support version numbers with
  alpha or beta designations.  This
  is Tcl Feature Request 219296.

  Second, during alpha development,
  it's fairly common to run into
  an interpreter that isn't based
  on any official release, but is some 
  development snapshot that may or
  may not have the same features as
  its [info patchlevel] would indicate.
  So even a working
  [package require Tcl 8.5a2] would
  not help since your interp claims
  to be 8.5a2 but lacks the features
  of the real 8.5a2 release.  One can
  imagine version number bumping
  schemes that could deal with that, but
  getting them followed reliably seems
  unlikely.

  Update your Tcl to one that supports
  the "in" operator.


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

  Ok, thanks. Did not even know there's a new "in" keyword.
  I guess I was using the latest ActiveState Mac release.

  Dylan.


login: jepler
username: jepler
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2772

  I'm using bwidget with tcl/tk8.4.10.  There are still
  N-squared behaviors with "-selectfill 1".


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

  The problem appears to be because the widget's path has
  parantheses.  Once they were removed I no longer get the
  error message reported.


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


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

  Looked a bit into this. When the remote interpreter receives
  an incoming connection it calls the commIncoming callback
  for the listening socket. The second argument is the ip
  address of the host the connection is coming from. That is
  the reason for the use of an ip address instead of a
  hostname. The remote interp has nothing else.

  Tcl is asymmtric in this regard. The side opening a
  connection can use ipaddr or hostname, and Tcl will use the
  OS to resolve hostnames to ip. The remote side however has
  only the ip address, not a hostname, and Tcl does not do
  reverse resolution. Note also that the revers lookup is also
  not unambigous. We may have several hostnames for an ipaddr.

  To get the hostname either the host opening the connection
  has to send its name as part of the first message, like it
  already does for offered protocol versions, or the remote
  host has to perform some sort of reverse dns lookup (ip ->
  hostname).

  The first is possible, means that the protocol goes a
  version higher. Disadvantage: The name as send may not be
  visible as is in the DNS of the remote host. Meaning that
  trying to connect back to that will fail. This will likely
  work best if both hosts use the same dns server. Not in
  general however.

  And reverse dns lookup, well, that is neither built into
  Tcl, not do I remember a package which could do it. Maybe
  tcllib::dns ? No idea. That has the disadvantage that the
  reverse lookup takes time, i.e. more time until the
  connection is open.

  The id value for the hooks is likely depending on whether
  this is a 'local' or a 'remote' hook. The remote hooks do
  not have host names, the 'local' hooks use whatever id the
  user specified when the connection was opened.


  There is definitely no quick, easy, and full solution for
  this (pick two).

  Well, the protocol extension maybe, with a quick check if
  the received name can be resolved. If not then fall back to
  the regular behaviour.


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

  Be more careful what you type :)
  As I understand it, some lines get understood by the server.
  It's possible this is no longer the case with the Jabber MUC
  but I am not certain.


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

  This is because the type *is* a namespace.  In your example, the ::ns::myObj 
  constructor runs in the ::ns::myObj:: namespace, not the ::ns:: namespace.  
  This is extremely unlikely to change.

  I do agree, I would often find it convenient if ::ns::myObj's code could use any 
  command from ::ns:: without having to import it or qualify it.  I believe there's
  a TIP in progress which would allow me to tell Tcl that when it's in the 
  ::ns::myObj:: namespace it should look for unqualified command names in
  ::ns::myObj, and then in ::ns::, and then in ::, instead of just in ::ns::myObj::
  and ::.  If that pans out, it would be an obvious enhancement--and one that
  I'd welcome.


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

  Ah, you want a script, like used by 'foreach', instead of a
  command prefix. And the script has access to a variable
  containing the current element.

  Specialized foreach commands, both of them. Called them
  'mapfor' and 'filterfor'.

  Committed, with test cases, and documentation.

  Administriva: Please put tcl code into a files and attach
  them. Inlined code is unreadable.


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

  I have nothing to do with Bwidgets and its internals. DamonC
  and JeffH are the maintainers. Possibly Daniel South
  (wildcard_25) as well. As it was with Damon already it now
  goes to Jeff.


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

  I didn't see that bug anymore, but I saw it in the past.
  IIRC, check in:

  Wed Jan 26 01:01:24 2005 UTC (16 months, 2 weeks ago) by hobbs
  Branch: MAIN
  Changes since 1.145: +5 -0 lines
  Diff to previous 1.145

  * notebook.tcl: reverted lester patch - too many bugs
  related to
  deleting and reinsertion of tabs.

  fixed the problem. 

  At least something like


  package require BWidget

  wm geometry . 200x200
  NoteBook .nb
  pack .nb -fill both -expand yes
  foreach page {zero one two three four five} {
      .nb insert end $page -text $page
  }
  after 2000
  foreach page {two three four five} {
      .nb delete $page
  }

  works for me as expected, with a almost recent BWidget cvs
  version.


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

  Could only reproduce after a lot of clicking on the Buttons,
  not just the few clicks you reported.

  As you use Dialog -modal global this is probably a global
  grab which is not released.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi,
  thank you for reporting, it is reproductible on windows.
  Considering the following code on windows tk without BWidget:
  ---
  pack [button .b -text t -command "tk_messageBox"]
  focus .b
  raise .
  grab -global .b
  -EOF-
  we get a similar deadlock effect.
  As a workaround, I suggest to release the grab (or not use global grabs at all) before opening another window.

  This is filed as tk bug  2814003

  As a workaround, a tk_messageBox routine might be created like
  set grabcur [grab]
  if {"" ne $grabcur} {
      grab release $grabcur
  }
  tk_messageBox ...
  if {"" ne $grabcur} {
      grab $grabcur
  }


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

  Hm. There are a number of packages which can use tcllibc,
  and IIRC none of them look for and use an installed critcl
  to compile the acceleration codes dynamically.

  Yes, extending the installer should be possible, to have it
  look for critcl, and build tcllibc if it is present. That
  should alleviate most concerns I think. Otherwise we have go
  deeper into the code of all the packages loading their
  various accelerators and have it check for critcl alone as well.

  The other stuff are documentation issues I will address
  after we have consensus regarding tcllibc/critcl. I have
  notified Pat Thoyts directly, as he wrote most of the
  packages using critcl in general, and uuid in particular.


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

  Oh dear, this is an unexpected side effect of that stuff.
  I have checked the other modules too - there may be a
  similar effect in stooop, but I have no experience with that.

  Other modules seem unlikely to cause trouble (cmdline and
  doctools)

  I have committed the changes to CVS 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Gregor,
  thank you for the report. It is now fixed with the assumption, that:
  - all screens have the same size
  - all screens are directly one beside the other
  Unfortunately, both are not true in general, but the current solution is a step forward.

  I have read that there is no way to find the screen geometries of the other screens with tk, so this seams the best possible solution.

  The fix in cvs also includes your solution.


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

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

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


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

  Closed the request - Plotchart has the possibility to dispaly histograms


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Stephen,
  this option is documented and implemented as readonly.

  Unfortunately, I first fixed it and then read the manual. So I fixed the manual too.
  Please check, if current cvs works for you.


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

  I have partial code that does this. I'll see if i can beat
  it into usable shape. 


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

  I am not able to find a file 'tclunits.tcl' in the tcllib
  units module, nor anywhere elase in tcllib. There is also no
  file containing the string 'cto(capturing)' from the patch
  anywhere else in tcllib (in case the file was renamed).
  Based on that it seems that this patch/bug does not refer to
  tcllib, or to an old revision of tcllib (I checked the CVS
  head).

  Setting to pending, for auto-close in a about 2 weeks. This
  will automatically re-open the bug if new information comes
  in within this timeframe.


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

  Tclunit is in tclapps.  It is a real module, and has a real
  bug.  I just haven't had the mental energy or time to fix it.

  Changing status back to open.


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

  Ok, changed back to state none, and added clarification to
  subject line. We have no category for this one. Should we
  add it ?


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

  I see 17 apps, and two of them with categories of their own.
   Perhaps a category for just "apps" which would at least
  give you a hint about where to find the module.


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

  did both. General category, and one for tclunits. You are
  the auto-assigned maintainer for the latter category.


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

  All fixed.  Thanks for the bug report and repair suggestion.


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

  Adding the lines below (diff with 1.339) allows the proxy 
  password to be saved. 

  C:\Program Files\tkChat>diff -u tkchat-
  torsten.vfs\bin\tkchat.tcl tkchat-
  torsten.vfs.proxypw\bin\tkchat.tcl
  --- tkchat-torsten.vfs\bin\tkchat.tcl   Tue Jun 27 15:16:38 
  2006
  +++ tkchat-torsten.vfs.proxypw\bin\tkchat.tcl   Tue Jun 27 
  16:38:11 2006
  @@ -3437,6 +3437,10 @@
          ${NS}::label .logon.lpap -text "Proxy Auth 
  Password" -underline 13
          ${NS}::entry .logon.epan -textvariable 
  Options(ProxyUsername)
          ${NS}::entry .logon.epap -textvariable 
  Options(ProxyPassword) -show {*}
  +       ${NS}::checkbutton .logon.rprxpw \
  +               -text "Remember Proxy Password" \
  +               -variable Options(SaveProxyPW) \
  +               -underline 0
          ${NS}::label .logon.lnm -text "Chat Username" -
  underline 9
          ${NS}::label .logon.lpw -text "Chat Password" -
  underline 6
          ${NS}::entry .logon.enm -textvariable 
  Options(Username)
  @@ -3529,6 +3533,7 @@
          grid x          .logon.lph    .logon.fpx   -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpan   .logon.epan  -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpap   .logon.epap  -in $lf -
  sticky w  -pady 3
  +       grid x          .logon.rprxpw    -                 -
  in $lf -sticky w  -pady 3
          grid .logon.lnm .logon.enm    -            -in $lf -
  sticky ew -pady 5
          grid .logon.lpw .logon.epw    -            -in $lf -
  sticky ew
          grid x          .logon.rpw    -            -in $lf -
  sticky w  -pady 3
  @@ -4251,7 +4256,7 @@
          Emoticons EnableWhiteboard EntryMessageColor errLog 
  ExitMessageColor
          Font,* Fullname Geometry HistoryLines 
  JabberConference JabberPort
          JabberResource JabberServer LogFile LogLevel 
  LogStderr MyColor Nickname
  -       OneToOne Pane Password ProxyHost ProxyPort 
  ProxyUsername SavePW
  +       OneToOne Pane ProxyPassword Password ProxyHost 
  ProxyPort ProxyUsername SaveProxyPW SavePW
          ServerLogging Style Theme Transparency UseBabelfish 
  UseJabberSSL
          UseProxy Username Visibility,*
       }
  @@ -4298,6 +4303,9 @@
       if { !$Options(SavePW) } {
          unset -nocomplain tmp(Password)
       }
  +    if { !$Options(SaveProxyPW) } {
  +       unset -nocomplain tmp(ProxyPassword)
  +    }

       # Save original Nickname
       if { [info exists ::tkjabber::baseNick] } {
  @@ -5145,6 +5153,7 @@
          ProxyPort               ""
          ProxyUsername           ""
          SavePW                  0
  +       SaveProxyPW                     0
          ServerLogging           all
          Style                   any
          Theme                   ""


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

  This is intentional - partly to avoid storing your network password in a plaintext file and partly to avoid having your account locked because of tkchat retrying too many times after a password change.


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  File Added - 184182: bwidget.diff.txt

  Logged In: YES 
  user_id=152318

  that diff has lost its indent.  Let me attach a file...


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=152318
  Originator: YES

  Here you go:

  package require Tk
  package require BWidget

  proc do_write {} { BWidget::write [file join $::env(HOME) bwidget.out] }

  Button .b1 -text "launch BWidget::write" -command do_write
  Button .b2 -text Exit -command exit
  pack .b1 .b2 -side top


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

  Thanks. Yes, your correction is right. I have accepted it,
  and extended the testsuite as well.


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

  The above suggested change excludes hidden files on Windows;
  the below line could be used in both the Windows and Unix
  implementations of find:

  replace 

   set filenames [glob -nocomplain * .*]

  with:

   set filenames [glob -nocomplain *] ; set filenames [concat
  $filenames [glob -nocomplain -types hidden *]]

  Note how much easier this whole problem would be if there
  were a "-types all" option provided by glob.


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

  This should be fixed by the recent rewrite of fileutil::find which is now in the CVS head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 186333: valgrind.txt

  Logged In: YES 
  user_id=75003

  I can confirm the same crash with Tcl 8.4.CVS and
  struct::tree critcl. (Aborted with a "malformed bucket chain
  in Tcl_DeleteHashEntry").

  And I managed to get some more information where the
  problems by using valgrind.

  Hm. I wonder if I can manage to get more by compiling
  struct::tree with symbols.

  Ok, than you very much Helmut for investigating this so far,
  i.e. making the problem reproducible, and also reducing it
  to such a simple and small script. 


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

  This can actually be seen as two problems.

  (1) The auto-generation of node-names is out of whack for a
  tree loaded from a serialization. It creates node-names
  which are already present.

  (2) The code for the destruction of tree is not able to
  handle a tree with duplicate node names.

  The latter is the crash. However (1) is the real problem.
  All parts of the tree implementation assume that node names
  are unique. all the methods for rename, etc. check that the
  result is not violating this assumption.

  Ok, the plan: Make the destruction more robust against dup
  names, if possible. By detecting an already deleted node.
  Panic with a proper message. Then fix the generation of dup
  names by the C impl. after a tree was loaded from file. Put
  this example into the testsuite.


login: hgiese
username: hgiese
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=522169

  Hi Andreas,
  I have been thinking a bit about this issue.
  You can use the same approach the Tcl version uses - that is
  on every node creation you keep incrementing the counter and
  compare the resulting name against all existing nodes. This
  is an O(n) operation for each newly created node.
  How about the following approach: On deserialisiation you
  check for the highest node index present and set your
  'unique number' from there. This is also an O(n) operation
  but it happens only once.

  Why aren't you on vacation at this time of the year?
  Greetings from a very hot place
  Helmut


login: hgiese
username: hgiese
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=522169

  Hi Andreas,
  just a last thought:
  On deserialising you are bound to look at each node. Why not
  note 'in passing' the highest "auto generated name" and when
  thru using it to initialise the 'unique number'?
  This should be negligible wrt changes in the code and
  run-time impact.
  Ok, I'll forget about it now and leave the rest to you.
  Greetings
  Helmut


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

  Fix committed to head.
  t_newnodename extended to skip existing nodes while
  generating names.
  tn_new extended with check for duplicate name, panic. This
  latter ensures that, should we have other places which can
  cause generation of dup names, we panic early and with a
  good error message, and with damaged hashtable during
  destruction.


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

  Hm. Could actually have a huge impact on runtime in
  pathological cases. For the better. Consider a very large
  tree, several thousand nodes, all auto-generated.

  I start from the bottom (node1) to find and fill any gaps.
  If there are none I have to iterate over the thousands of
  names to to find the max. Takes a long time.

  The tcl version is most impacted by this. The C version is
  way faster, but even so this only means that the point where
  such the iteration takes a noticeable amount of time is
  pushed to higher numbers of nodes, not that the problem goes
  away.

  So, doing some precomputation when desrializaing makes sense.

  On the other hand, this precomputation has to 'string match'
  or 'regexp' each node name and see if it is of the form
  'nodeFOO', FOO an integer number. This is not cheap in
  runtime I believe.

  Well, in the end what we need is to benchmark this and see
  how the various cases behave and what the big-O constants are.


  --
  And thanks again for the concise test case. This made the
  debugging a snap.


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

  Thanks for the patch. Applied it to the current CVS Head,
  its in logger version 0.7. I needed to fix some minor
  failures in the testsuite (to specific pathes to the
  logger.tcl file, wrongNumArgs which were not prepared for
  running with Tcl 8.5).


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

  This has been fixed, and test "bug-3.1" has been added to the Snit test suite to 
  cover the error condition.


login: yahalom
username: yahalom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=130120

  I got very troubled from the response. the pervious bug 
  mentioned was fixed in the days of the tcllib1.3 we are now 
  in tcllib1.8 and the bug is still there!!!! this means that 
  the bug fix is not in the head version and therfore is 
  still open


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

  The bug was closed in July 2006, so the fix is only inside
  CVS currently, not in a released version. CVS HEAD is not
  equivalent to the latest released version...

  Take a look at ncgi.tcl in CVS and the nvlist proc, it does
  not contain a regexp anymore.... 

  So this is really closed.


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

  I checked as well and can confirm Michael's findings. The
  unreleased code we have in the CVS really is without RE's in
  nvlist.


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

  Does this happen for the current CVS head as well ? I just checked and the installer code in the CVS head does not contain 'package require fileutil', so the problem might be gone.

  If not note that the Makefile calls on 'installer.tcl' as well, with a series of arguments for non-gui operation. So, when you call the installer directly, using them same arguments, does the error then happen ?


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

  Makes sense. Easy client side.
  Note: lcl_id aka local_id can be had automatically from the
  comm channel used to setup the "alias".

  Not really aliases, but forwarder, delegators ... I like the
  last name, matches with what snit does.

  More complex delegation would allow -async and -command.
  -async is actually easy, -command can have a variety of
  semantics, depending on when we wish to declare the callback
  (when delegator is created, or when it is used).

  Well, let us stay with the simple stuff first.


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

  "delegate" sounds good to me. And -async would be a nice
  addition too -- it can be very useful for logging messages
  to a central server where we know that the client doesn't
  have to wait for any responses. The -command stuff can wait.


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

  Implemented in the CVS head, new module 'interp', doing
  interp creation, and additional packages for the creation of
  delegation procedures and methods (snit).


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

  Stupid typos. Wonder why this wasn't detected when the code
  was extracted from the ldap module.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  File Deleted - 189465: 



  File Added - 189517: ldap.patch

  Logged In: YES 
  user_id=1268042

  New patch (which supersedes the first one) with a small 
  bug corrected in the attrsOnly option handling.


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

  A workaround is in place in the ldap module, which looks for
  the namespace var storing the nonce count and resetting it,
  before a new attempt. Not perfect but works. If this gets
  fixed in the sasl module, it would be better, but its not a
  showstopper for ldap sasl support.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 242826: bug1545306.patch

  Logged In: YES 
  user_id=202636
  Originator: NO

  You might try the attached patch which moves the nonce count into the context structure. SASL::cleanup will remove it so a new context will begin again at 1.
  To reuse a SASL context as described in the RFC you should call SASL::reset. As the context remembers the original server challenge and now the noncecount it will compose a new auth request as before but with an incremented noncecount and should re-authenticate. This needs confirming -- I don't have an LDAP setup to try against and my SMTPd doesn't do re-authentication.
  File Added: bug1545306.patch


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

  Added this to the ldap module as ldapx.tcl based on the last
  version i received by email and some minor stylistic changes
  (unset -> array unset where appropriate, added some missing
  --, changed some string equals to eq, and so on)


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Added - 190935: tooltip.tcl.patch

  Logged In: YES 
  user_id=368971

  I've added a patch which fixes this bug. It withdraws the
  tooltip when the cursor is on the widget for which the
  tooltip is cleared.


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Deleted - 190935: 

  Logged In: YES 
  user_id=368971

  A tooltip isn't shown immediately when the cursor is already
  on the item. This bug isn't fixed in the patch.


login: mbroeken
username: mbroeken
mimetype: text/plain
icomment:
  File Added - 190937: tooltip.tcl.patch

  Logged In: YES 
  user_id=368971

  I've improved the previous patch to correctly clear and set
  tooltips on items with the cursor over them.


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

  in tooltip 1.4.  I didn't do the display if you just add the tooltip, just the clear if removed.

  BTW, diff -u is much easier to read.


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

  asn::asnRetag allows precisely this scenario -> closed


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

  oh damn, forgot to experiment a bit, found just add a .0 to
  the end to make it work with decimals.

  please delete this feature request, sorry to waste your
  time. feel free to slap me about with a trout :/


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

  See also "[ 1563137 ] NList fails for files with spaces".
  This report contains a fix as well.
  The fix was applied and committed.


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


  IMHO...

  Nothing to repair; this is
  not a bug.

  [namespace import] the
  ::math::linearalgebra::scale
  command into your namespace,
  not the global one.

  If you insist that you must
  import both commands into
  the same namespace then
  [rename] one of them.  This
  is name conflict resolution 101.


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Ooops...

  ::html::tableFromArray 

  That also contains uppercase:

  append html "<TR><TH colspan=2>$arrname</TH></TR>\n"


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

  Fixed in CVS head. Also changed the SELECTED and CHECKED
  things to lowercase.


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193325: ntlm.patch

  Logged In: YES 
  user_id=1463011

  Attached patch allows me to successfully bypass our
  corperate proxy server. Via: 1.1 hostname (NetCache
  NetApp/6.0.2P2D2)


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193343: ntlm.test.patch

  Logged In: YES 
  user_id=1463011

  Test SASL-NTLM-1.1 now fails because of additional changes
  in the way of including the flags and session keys fields in
  the type-3 message.
  Attached a patch on the ntml.test file. 


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

  Applied patches plus a little reconfiguring. Tests ok on my
  unicode using systems.


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

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

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


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

  Please attach the result of package require ldap, so i know
  which ldap version your working with (must be a recent CVS
  checkout).


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

  Do other large searches work? The search interface and the
  underlying structures changed quite a bit, so there may be
  some more bugs lurking...


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

  Ok, i can reproduce the error.

  The ldap code had a wrong calculation for missing length
  bytes and broke when it got a long response like the
  subschema query.


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

  This is fixed in CVS now, get package version 1.6.2 , along
  with some other bugs in the info subcommand.


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

  Apart from a bug in this script ($b}] should be $b]), there
  was a genuine error in the leastSquaresSVD routine. This has
  been solved - see the CVS repository.

  Added this as a test case


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 194111: installer.tcl

  Logged In: YES 
  user_id=302287

  Diff adding an error dialog attached. Please review.


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

  A quick look seems to be ok, only a nit: [catch {}] == 1 can
  be shortened to [catch {...}] I do not thank that we care
  about break, continue, etc. Will have a closer look when I
  ma home, i.e. patch and look at the whole context.


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

  Accepted with very small changes yesterday, committed this
  morning. The nit, and slighty different formatting.


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

  You should add a -- to terminate the option list. Thus:
  ::blowfish::blowfish -mode ecb -dir decrypt -key -- $key
  Or use the programming api style as in the man page.

  I will note the -- option termination in the manual page and
  looking at the option code this can be made smart enough to
  tell that the final argument is data and avoid trying to
  handle it as an option.


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

  I have a tclsh 8.5 and can see what this is about. In the
  meantime use Tcl 8.4 to run sak and specify the shell to use
  for the testsuite itself using "test run -s SHELL ...".


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

  Uh. This seems to a something with the new 8.5 ensemble
  and/or namespace path stuff snit v2 uses.

  The constructor of tie::std::file has a call

       [file normalize $thepath]

  and this seems to be interpreted as call into the class or
  constructed instance now. In snit v1 this resolves to the
  global command.

  For now I will fix this using ::file, however I wonder if
  that is something which is a snit problem and not of the
  defined class.

  It is an incompat for sure.


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

  Fixed. Also fixed a syntax error in an example uncovered by
  emacs syntax highlighting. A closing double-apostroph was
  missing.


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

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


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

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


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  The use of [file join . / *]
  in these tests is suspect.
  Perhaps it's combining with
  [glob] and [file] bugs here?

  What's intended by these tests?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The glob outout (.//foo) certainly looks broken. If this is
  the expected output and the intentation of thests. I don't
  know. They test the 'fileutil::install' command ... Written
  by David Welton in 2003. So he should be able to get us
  better answers. He is 'davidw' here, we could reassign this
  to him.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  ok, at least one relevant issue
  is a [glob] bug fix apparently
  not backported to 8.4.

  % info patch
  8.5a5
  % glob *
  foo
  % glob -dir . /foo
  ./foo


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Heh. I just ran into these test failures again, I think. Ok on Linux, failed on Windows.
  Will try to understand what is done and wanted.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks. I have to ask 'how quick' ? The testsuite is failure
  free for 8.4, the main release of the core, and the plan was
  to go final this evening (Monday Oct 2). I could move that
  one, at most two days, but no longer, as I want to have GA
  well before the conference.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

  I don't think I'll be done in 2 days, maybe, but not for
  sure... Sorry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I expected that answer ... Ok, if you manage we can put into
  the release, otherwise it has to wait for the next, and I
  hope that you will not min that. As it affects only the 8.5
  alpha it can be considered as relatively low-priority. On
  the other hand, several tcllib math failures uncovered bugs
  in the rewritten Tcl 8.5 number handling, so we should not
  leave it uninvestigated.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks Jean-Luc for the quick investigation and work. I saw
  your commit and tested it, the testcase is not failing
  anymore. I will now close the report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Used [format] to get a deterministic precision of the result
  across versions. Committed to head.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the test: the failure was due to the changed default
  for tcl_precision.
  By explicitly setting the value, the previous behaviour has
  been restored 
  and the test succeeds. 

  Note: the original value for tcl_precision is restored at
  the end to ensure
  consistent behaviour for other tests.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I made a fix to the dialog module and also to the pop3
  testsuite. This is in the head. Can you check if your
  problem still happens ?

  Note: The fixes I made were because the tests pop3-2.8 and
  pop3-5.0 were failing consistently on Solaris. Not on Linux.
  I never saw pop3-6.1 failing on solaris. And my failures
  were not dependent on running the whole tcllib testsuite,
  pop3 alone was sufficient. So, there are quite few
  differences. I am however not excluding that it is the same
  problem, just appearing in different places due to different
  system speed.

  In previous incarnations of the testsuite driver it was
  possible that a testsuite coming before pop3 forgot to kill
  a timer and it fired during the later test, smashing
  something. However in the current setup each module is
  tested using a new sub-process. So it should not be possible
  to leak stuff between modules. The only thing I can think
  off is timing differences between pop3 alone vs the whole
  testsuite.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  I can't repro the failure
  today, so either your changes
  fixed it, or it's not a real
  reproducible bug in the first
  place.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. Making it low-priority then. If a repro comes good,
  otherwise closing in a month or so.


login: sarnold75
username: sarnold75
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1160227

  I am sorry, I have tested the package 2.0 with Tcl HEAD
  (updated and recompiled today) Windows XP (32-bit), and
  there is no problem - the test suite runs with no error.

  I guess the bug is somewhere in 64-bit integers handling,
  and/or even bignums.
  Maybe others areas of tcllib are impacted, this may be a
  problem related to the core, and which does not happen on
  32-bt systems.

  I feel sorry for you, but I'd only seek for a solution if I
  have a 64-bit system under my (dirty :^) hands...


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Selecting bigfloat-int2float-2.9.2.3
  for more analysis, on 32-bit system
  I see:

  % int2float [fromstr 5000000000] 5
  F 21474836480000000000 -32 42951

  On 64-bit I see:

  % int2float [fromstr 5000000000] 5
  F -125100849711610 -32 42951


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

   looked again and you need Trfcrypt, not Trf, I got confused
  by a switch-label. Trfcrypt does not come with ActiveTcl, so
  you are using the pure Tcl impl. of blowfish.
   
  I also note on further reading that the mode you are using
  is CBC aka Cipher Block Chaining. IIRC my crypto right this
  mode always operates on whole blocks, which are 64bit, aka 8
  byte
  for blowfish
  (http://en.wikipedia.org/wiki/Blowfish_%28cipher%29).
   
  This means that the padding done is correct. It likely
  actually is done to the input to make it a set of full blocks.
   
  Found some references:
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29
   
  And
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
  for methods padding which can be done before CBC is invoked
  and is exactly reversible. I do not know if the code in
  Tcllib uses any of these block padding schemes or is leaving
  that to the caller. I guess that it is the latter.
   
  Pat, I think we should add these wikipedia entries as
  references.
   
  I also grepped the manpage for information regarding padding
  and found none. IMHO this is a doc bug we should correct.
  This is one area where people can trip.
   


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Documented the padding a bit more explictly. Also added a
  -pad option to the blowfish command which can be used to
  turn off this padding feature (in which case you get an
  error if the data is not a multiple of the block size) + tests.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is DIGEST-MD5::client ... switch branch 1 ...
  CreateNonce not coming back ... Ah, reading from dev/random
  ... Checking ... /dev/random is readable, opened, reading 16
  bytes then hangs. My guess is that the machine has not
  enough randomness and is waiting for it accumulate.

  What now. In a way the report is invalid, as the testsuite
  hangs not on its own, but because of something in the
  environment. 

  Interesting, for machines without /dev/random, i.e. Win*,
  something based on clock, pid, and Tcl rand() is used.

  Oh, it is worse. The subprocesses not only hang, they cannot
  be killed anymore. Not even kill -KILL works :(


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  It seems we should read from /dev/urandom to avoid blocking.
  Modified to use this source.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  I've fixed the alert mechanism to raise the alert for the window concerned now. This is fixed in 1.415.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed in CVS head on Friday Oct 7 after reported by Mikhail
  Teterin, a FreeBSD maintainer. He has the fix as patch as
  well, to be put into the ports build system.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494
  Originator: NO

  The units library already has most of this functionality.

  If, for example, you want to convert between inches and meters, or square feet and yards, you can do so like this:

    % package require units
    2.1
    % units::convert 4meters^2 yards^2
    4.7839601852
    % units::convert 22inches meters
    0.5588

  The referenced library also has some volume conversions between quarts, pints, and gallons, but the constants are for UK units.  I didn't put these units into the standard library because it might be misleading to have ambigious units.  But you can easily add them.

    #  Add UK gallons
    units::new impGallon 4.54liters


login: goodegod
username: goodegod
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1294134

  Even better would be to have tcl smart enough to not trip 
  an error if the variable unset is trying to unset doesn't 
  exist.  What is the harm in that?  It should be similar to 
  the tk destroy command.  

  That's just my two cents...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In newer Tcl's (since 8.4 IIRC) we have 'unset -nocomplain'
  for this. However 'ftp' is old and geared to run with Tcl
  8.2 as well. That needs either catch or the if-info-exists.

  In general you could, also, do

  rename unset unset_orig
  proc unset {args} {foreach v $args {upvar 1 $v var ; catch
  {unset_orig var}}}

  I.e. redefine 'unset' to do what you want, unset without
  tripping.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Reviewing the patch ...
  The move of the close/unset I understand. Takes the
  fileevent away.
  Unsetting ftp(state.data) I understand as well, after
  reading WaitComplete. It is necessary to prevent this
  command from doing a vwait without having an event source.
  However, why is there a 'read ftp(CtrlSock)' in the patch ?
  The Ctrlsock is already at eof, so this is a no-op.
  The close alone should be enough.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have now committed the patch without using the 'read
  CtrlSock'. If that causes the head (rev 1.44) to still fail
  with an infinite recursion please re-open this bug.

  Side note: Thank you providing a patch, and for attaching it
  to the report instead of inlining it. Despite this I have a
  small nit. Please use the command 'diff -u' the next time
  you create a patch for us. The '-u' switch causes 'diff' to
  generate a patch in the 'unified' format. This format
  generates larger patches, this however is offset by the fact
  that the result is much easier to understand when read by a
  human. In other words, it makes the reviewing of a patch
  easier for us maintainer. Thank you.


login: hofkensg
username: hofkensg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1625850

  You are right about the no-op.
  I have tested revision 1.44 and it works fine.
  I will use the diff -u in the future.
  Thanks,
  Guy


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Extra scenario:
  Installed apache ftp server from
  http://incubator.apache.org/ftpserver/ on win-xp (all default).

  And the output is (as you can see even other behaviour,
  nothing is prefixed now):
  % package require ftp
  2.4.4
  %
  % set h_ftp [ftp::Open 10.17.101.53 anonymous myPwd -port 21
  -mode active]
  0
  % # Case 1
  % ftp::NList $h_ftp  edidata/Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 2
  % ftp::NList $h_ftp  edidata/Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML
  % ftp::Cd $h_ftp edidata
  1
  % # Case 3
  % ftp::NList $h_ftp  Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 4
  % ftp::NList $h_ftp  Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The ftp packages NList command basically just passes through
  whatever it receives from the FTP server, without
  postprocessing, so you directly see the server differences
  (similar to what you would see if you used a typical command
  line ftp client).

  The RFC does not make any real assumptions how the returned
  filenames have to look like:

           NAME LIST (NLST)

              This command causes a directory listing to be
  sent from
              server to user site.  The pathname should specify a
              directory or other system-specific file group
  descriptor; a
              null argument implies the current directory. 
  The server
              will return a stream of names of files and no other
              information.  The data will be transferred in
  ASCII or
              EBCDIC type over the data connection as valid
  pathname
              strings separated by <CRLF> or <NL>.  (Again the
  user must
              ensure that the TYPE is correct.)  This command
  is intended
              to return information that can be used by a
  program to
              further process the files automatically.  For
  example, in
              the implementation of a "multiple get" function.

  It talks about 'valid pathname', if the results you see do
  not match the description in the RFC the server is buggy.
  The exact specification for 'pathname' is vague at best:

        pathname

           Pathname is defined to be the character string
  which must be
           input to a file system by a user in order to
  identify a file.
           Pathname normally contains device and/or directory
  names, and
           file name specification.  FTP does not yet specify
  a standard
           pathname convention.  Each user must follow the
  file naming
           conventions of the file systems involved in the
  transfer.

  The only 'safe' way i see is to CD to the working directory
  your interested in an invoke the NLIST command there, as
  that excludes all directory name prefix issues.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  I did some extra testing and I now convinced this is a
  ftp-server problem, not a tlclib problem. (thanks mic42 for
  the remark)
  * If you want to Use set directory listing to UNIX (to solve
  backslash problem)
  * Always add a slash to the end of a directory when using
  NList (solves directory prefixing)

  Is this something to add to the doc. as a remark ?


login: matzek
username: matzek
mimetype: text/plain
icomment:
  File Deleted - 200000: 



  File Added - 200122: new_conf_option.patch

  Logged In: YES 
  user_id=330806

  I am sorry. Had to replace the patch again, as the usage of
  AC_ARG_ENABLE was just wrong. Now triple checked...

  kind regards -- Matthias Kraft


login: bugant
username: bugant
mimetype: text/plain
icomment:
  File Deleted - 201918: 



  File Added - 202048: ftp.tcl.patch

  Logged In: YES 
  user_id=1391120

  Andreas Kupries suggested to change the -hylafax
  option to a more generic -temp. This is a good idea.
  The patch attached do this (I'm removing the previous one).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  The "Diagrams" package was obsoleted by "diagram" (lowercase, no trailing 's').


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=317958
  Originator: NO

  This problem is not Tablelist-specific.  Replace the tablelist with another widget, e.g., a Tk listbox or text widget, and you will see exactly the same behavior.

  I am no [incr Tk] expert, but apparently it is the

      itk_component add table {
          tablelist::tablelist $itk_component(sf).table
      } {}

  command in your script that causes the trouble (probably because $itk_component(sf) is a scrolledframe widget).  Replace it with

      set cs [$itk_component(sf) childsite]
      tablelist::tablelist $cs.table

  and update the pack command accordingly.  After these changes, the script will work as expected.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Not only with syslog, also with Andreas log package.

  I'll consider it. Its quite easy to do.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 214446: logger.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

  File Added: logger.diffs


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Wrong. The above is incorrect HTML. The JavaScript is incorrect, a < has always to be quoted as < unless it is inside a CDATA section.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I don't see anything in http://www.w3.org/TR/html4/interact/scripts.html that would indicate that. Can you provide a reference? None of the examples that I have seen on the web follow such a convention. (The CDATA section is deprecated, according the the W3 page above.)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Your right its valid, but there are some problems lurking in that area, see:
  http://www.w3.org/TR/html4/appendix/notes.html#notes-specifying-data

  It works because the DTD for HTML4 declares <script> as having a CDATA value, but may blow up in apps that don't fully respect the DTD. So its dangerous ground...


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I was able to work around the problem by adding spaces around the < in the files I had access to (which would not always be the case). Pragmatically, I don't know what the fix should be, but handling of SCRIPT might need to be more special than it is.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  Looking at your reference, it's pretty clear that the script tag cannot end until a </[a-zA-Z] is found. Looks like the recognizer needs to be a bit more discriminating.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  This problem is now more urgent than it had been before. I'm working with JavaScript that is writing the HTML as it runs, including adding new <SCRIPT>...</SCRIPT> code inside of JavaScript document.write statements. htmlparse is getting seriously confused inside the JavaScript, and the resulting nodes are truly mucking up my parse tree. Some nodes aren't even at the right level any more, which makes my post processing lose them, which is very bad news for my application.


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=99768
  Originator: NO

  Oops, didn't I close this when I committed the change?

  Thanks again for the patch!


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433
  Originator: NO

  It looks like after this patch, it's necessary to call [dns::wait] after [dns::resolve].

  (It's probably always been necessary, just that I never called [dns::wait] before and managed to get away with it.  Took a while to find out what was going wrong after upgrading to tcllib 1.10)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Basically the url is invalid according to:
  http://www.ietf.org/rfc/rfc1738.txt (Section 3.3), the ? is reserved inside the searchpart of an URL and would have to be escaped.
  http://www.ietf.org/rfc/rfc2396.txt (Section 3.4) agrees with this.

  This appears a lot in the real world (especially due to PHPs crappy and incorrect url and form handling), so perhaps the URI package should deal with such broken urls.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I agree that we should try to handle this, at least if it can be done in a simple manner. Like looking for the first ? instead of the last. as we are using regexes this may require higher versions of Tcl and Advanced RE stuff (non-greedy ops) ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed using 'string first' instead of RE's. Extended testsuite. Version now is 1.2.1.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  To what combobox do you refer? tcllib doesn't have one, and the only thing in tklib that I see with a combobox is tablelist.

  $ tclsh
  % package require tablelist
  4.6
  % ComboBox .cb -values {a b c a b c}
  invalid command "ComboBox"
  %

  Give us info on what version of tcl and tk and what combobox you are using.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  According to the category the bwidget one. bwidget is in this project.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  Sorry, thought, the category would be enough, but ... I missed the BWidget version I use.

  I tried this behaviour with the BWidget version 1.7 and the most current one I know 1.8.

  Hope this helps!

  Martin


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Martin,
  thank you for the report.
  The issue is fixed in current cvs by adding a variable holding the last set index.

  This also solves the issue:
  % .cb setvalue 5
  % .cb getvalue
  2


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  I fully agree that the doctools docs need improvements.
  Most Tcllib authors probably use sak.tcl to generate the docs from their doctools formatted man pages, where it simply is: sak.tcl doc html <packagename> IIRC, but that kind of magic should be exported into a general use package for non-tcllib packages.
  So i agree that point 3 should be easy to do and have a big bang for the buck ratio.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  For reference, the wiki pages, which should be included (at least partially) into the doctools docs:
  http://wiki.tcl.tk/doctools
  http://wiki.tcl.tk/dtp

  These document at least the basics. Would they be enough to satisfy your 3. point?


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: YES

  Actually, the Wiki seems to address a majority of the insufficiencies in the documentation. Removing the "incorrect" information from the manual page (like the EBNF that's wrong) and either incorporating the examples and specifics from the Wiki or including a prominent pointer to the Wiki in the man page would probably be sufficient to answer most questions. I guess I'm just old-fashioned and haven't gotten into the habit of checking the wiki before the man pages. :-)


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  One thing that needs to be carefully kept in mind as doc for this package is written is that at least two types of documentation is needed.

  One type of doc is for someone who is going to be working on the code itself. That code would focus on design decisions, what the plugin architecture is for and how to use it, etc.

  The other type of doc is for someone who wants to write code in doctools format. For that person, the emphasis needs to be on SEMANTICAL use of the format. One of the reasons for doctools is semantical markup of text. In a semantical view, one doesn't care whether the resulting text is bold faced, underlined, etc. What matters is that people CORRECTLY marks the various parts of text. If one marks the text correctly, then the doctools tools should be able to generate things in a format that is useful later.
  And viewing the doc from that perspective is invaluable.  

  I wonder if some sort of tool would be useful to have that would somehow display the documentation visually emphasizing the semantical markup, so that one could easily look at text and identify where something had a mistaken markup?  I'm not certain about a good way to do this - something to think about.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 216376: doc.tgz

  Logged In: YES 
  user_id=75003
  Originator: NO

  Now attached a first go at a set of new man pages for the doctools markup language. Please review and respond.

  Looking at this again, (4), ... The error messages do tell the location of the problem, line number and column.

  Of the 4 documents the command reference likely needs most of the expansion (i.e. more argument descriptions, add examples for each command).

  File Added: doc.tgz


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  This looks a lot better to me! The intro doc is excellent. The other thing I would suggest is perhaps adding one more document that is simply a collection of examples of each type of command. That is, a web page where one could cut-and-paste the formatting for a widget, for a command that takes -name/value pairs that are optional, etc etc etc. It would be just a matter of digging out representative samples from the existing package documentation and putting them in an easy-to-find place. Even just a list of "to see a sample mega-widget documentation, check package Yadda. To see a sample OO class document, see package Boogle" would do the trick, I think. Just some place that makes sense of the different formatting commands at a detailed level.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok, yesterday I committed the whole set of updated documentation, not only for doctools, but the docidx and doctoc formats as well. FAQs have been added, but are relatively small so far. All manpages now have a section about how and where to provide feedback. This is something I will add over time to all manpages in Tcllib. I made the doctools language nicer too (See changelog for the details. I mainly loosened a number of constraints, and added better names for the various list types and list item commands. The docs show the updated language, old stuff is still accepted, but deprecated and causes warnings).


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: NO

  I don't believe this is a bug. Headers are allowed to be repeated, such as for "Received" headers. Putting "Received" in a list and other headers not in a list would require the mime package and the user to know every possible header, and it would require everyone knowing that a header that appears only once might in other messages appear multiple times. If you expect only one instance of a header in your message, just access the zero'th element of the list returned.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  I do still think, that this is a bug!

  The Content-Id inside a "header" of a message part must be a real identifier!
  There is only one Content-Id per message part, or the message is mal formed!

  So the Content-ID should not be a list.

  I think from my own experience, that there is some addition quoting/bracing because of the "$" inside the Content-ID.
  If this is needed during parsing the message part ... ok.
  But returning the additionally braced value is ... not ok and unexpected, because of the intention of this value, the Content-ID.

  Good morning from Berlin/Germany,

  Marti


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: NO

  There are many headers that are only supposed to appear once, and many that may appear multiple times. There's no easy way to provide a list of all headers that should only appear once and all headers that may appear multiple times. Now that you know why it happens, why not simply take [lindex ... 0] of any header that your code expects to appear only once? Or, alternately, check that the list length is indeed only 1, and provide an error message if you are given a malformed message?


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  Added the "package require" statements. I noticed that the chemical structure example needs fixing though.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  The problem is not that the extra points introduced for an already closed polygon get in the way, but the specific choice of the "point far away". The round coordinates I chose for my
  test case make the point intersect two sides at the vertices. 

  This is a corner case that needs to be solved!


login: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Jasper,

  I have tried the following on a windows computer with two screens on tcl 8.4.18 and 8.5.7:

  pack [ComboBox .c -values {1 2}]

  Move the window (with the mouse) on screen one or two and open the drop-down box.

  It worked as it should.

  I will set the state to pending. I have no Mac and I suppose it is a Mac issue of Tcl (and not BWidget).
  I would appreciate if someone could check further.

  Thank you,
  Harald


login: decosterjos
username: decosterjos
mimetype: text/plain
icomment:
  File Added - 211706: tkchat356.diff

  Logged In: YES 
  user_id=370749
  Originator: YES

  Updated patch: moved subject alert menu item, fixed typo
  File Added: tkchat356.diff


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  I've applied your googlefight, wikip and wikid mods already (1.358). I'll check the highlight stuff soon and see how it works.


login: decosterjos
username: decosterjos
mimetype: text/plain
icomment:
  File Deleted - 211706: 



  File Added - 226721: tkchat_diff_377_377sh

  Logged In: YES 
  user_id=370749
  Originator: YES

  File Added: tkchat_diff_377_377sh


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug and reason confirmed.

  Proposed solution:
  Check password widget if state disable, confirm if so, otherwise change focus

  This is in cvs now.

  Test cases:

  PasswdDlg .p -passwdstate disabled
  PasswdDlg .p


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Thanks Michael. This has been fixed now in the CVS.

  2007-01-22  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * mime.tcl (word_encode): Ensured the return of the empty string
    when given the empty string.


login: cbascom
username: cbascom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1600284
  Originator: YES

  The above description did indeed fix the out of scope variables issue, but I hadn't realized until now that the event hooks were getting evaluated twice.  The first time they are evaluated is inside the if/else clause that checks to see whether another interpreter is in use or not.  In this case, the uplevel 1 was used when evaluating in the current interpreter so variables were indeed in scope.  The same event hook is then evaluated a second time by the eval command just below that if/else clause and at that point the variables are out of scope.  I believe the fix is simply to remove that eval.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This is fixed in the CVS. See the ChangeLog, entry below.

  2006-11-29  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * comm.tcl (commRunHook): Fixed double execution of the hook
    script. Thanks to Will Duquette for the report.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: YES

  Done - several other extensions as well: legend, background 


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  File Added - 213235: asn.tcl.diff

  Logged In: YES 
  user_id=757679
  Originator: YES

  File Added: asn.tcl.diff


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Agreed, that there is a problem with too strict checks in some places, there is also a RFE talking about a similar issue. I'll give it a bit more thought, as there are other issues like decoding CHOICE and SET structures, which is currently quite cumbersome, which would also need relaxed tag type checking and tag introspection to select the correct decoding (similar to the current string decoder).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  The confusion is that the double-\ is in the output, right ?
  In the input I am likely needing the double-\ to prevent interpretation as continuation line.
  That is a doctools problem, in the generator for HTML output.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Examples to check out

  [example {
      a \
      b
  }]

  [example {
      a \\
      b
  }]

  [example_begin]
      a \
      b
  [example_end]

  [example_begin]
      a \\
      b
  [example_end]


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902
  Originator: YES

  I'm not bothered what the origin of the problem is; I'm bothered that the output is misleading users of the documentation. How you resolve it is your business. :-)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Donal, not sure why you seem to think that I am bothered about something. I added the examples as a reminder to myself of the test cases I should use to investigate the problem, i.e. trace it through the layers of processing, and later for the test suite.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  I have a case where my filesystem is local, there are no symlinks, and I also get invalid results. I am uploading a ksh that creates a directory subtree that models the above description, then runs the tcl script (in my environment, it uses the latest tcllib and tcl). The resulting tar file will also be uploaded.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  hmm - guess not - stupid web app won't let me upload here!

  Here's the text of the script:
  #! /bin/ksh

  mkdir /tmp/tartest
  cd /tmp/tartest
  cat >tartest.tcl <<EOF
  #!/projects/sprs_lwv/tcl85/bin/tclsh
  package require tar
  ::tar::create tarball.tar devdir_4.1
  EOF

  chmod 755 tartest.tcl

  mkdir -p devdir_4.1/subdir1 devdir_4.1/subdir2
  for j in subdir1 subdir2 ; do
    cd /tmp/tartest/devdir_4.1/$j
    mkdir -p exec/bin export server/bin lib
    for i in exec/bin export server/bin lib ; do
          touch $i/file1 $i/file2 $i/file3
    done
  done

  cd /tmp/tartest
  ls -lR /tmp/tartest/devdir_4.1 > ls.output

  /tmp/tartest/tartest.tcl
  ls -l tarball.tar
  gtar tf tarball.tar | sort > tar.tcl.output

  and here's what I see in terms of output:

  cat ls.output

  /tmp/tartest/devdir_4.1:
  total 32
  drwxr-xr-x   6 lwv27    dept27       364 Feb  8 08:04 subdir1
  drwxr-xr-x   6 lwv27    dept27       364 Feb  8 08:04 subdir2

  /tmp/tartest/devdir_4.1/subdir1:
  total 64
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 exec
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 export
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 lib
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 server

  /tmp/tartest/devdir_4.1/subdir1/exec:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir1/exec/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/export:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/lib:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/server:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir1/server/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2:
  total 64
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 exec
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 export
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 lib
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 server

  /tmp/tartest/devdir_4.1/subdir2/exec:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir2/exec/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/export:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/lib:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/server:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir2/server/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  and here's the output from the tar file:

  devdir_4.1/subdir1/exec/bin/file1
  devdir_4.1/subdir1/exec/bin/file3
  devdir_4.1/subdir1/export
  devdir_4.1/subdir1/export/file3
  devdir_4.1/subdir1/lib
  devdir_4.1/subdir1/lib/file1
  devdir_4.1/subdir1/lib/file2
  devdir_4.1/subdir1/lib/file3
  devdir_4.1/subdir1/server
  devdir_4.1/subdir1/server/bin/file1
  devdir_4.1/subdir1/server/bin/file3
  devdir_4.1/subdir2
  devdir_4.1/subdir2/exec/bin/file1
  devdir_4.1/subdir2/exec/bin/file3
  devdir_4.1/subdir2/export
  devdir_4.1/subdir2/export/file1
  devdir_4.1/subdir2/export/file3
  devdir_4.1/subdir2/lib
  devdir_4.1/subdir2/lib/file1
  devdir_4.1/subdir2/lib/file2
  devdir_4.1/subdir2/lib/file3
  devdir_4.1/subdir2/server
  devdir_4.1/subdir2/server/bin/file1
  devdir_4.1/subdir2/server/bin/file3

  Notice that file2 is missing in nearly every directory in which it resides. Also note that file1 is missing from export directory.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Would it make sense to use 'fileutil::find' instead of re-implementing directory traversal in 'tar' ?
  The skipping of links (-dereference 0) can be implement via the 'filter command' callback of 'find'.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This seems to have been fixed by Aaron on Feb 8 if I read the ChangeLog right. Can we please get feedback that that fix is working for the submitter ?


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  Using the latest tcllib, today, Feb 12th, the discrepancies that I saw between files included has been resolved.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=812825
  Originator: NO

  submitter has confirmed previously commited changes have fixed the issue.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Historical note: The pages which have a struct_ prefix are the pages whose names without the prefix clash with manpages of either the core, or previously existing packages.

  I agree regarding the confusion. Given the clashes I noted I would propose to simply go forward with all manpages in the module having the 'struct_' prefix to eliminate the confusion.


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
  Originator: NO

  1. Fixed
  2. Fixed
  3. The problem is the . starting the '.btn'. Having this as first character on the line causes the roff formatter to interpret it as a command. A command it does not understand. It apparently simply drops the whole line. Fixed by indenting the example, i.e. working around the problem. Better would be to fix the doctools nroff formatter to somehow quote a leading '.' in plain text to prevent interpretation as a roff-command.
  4. Fixed.
  5. See explanation for 3. Same fix.
  6. Actually the two examples are different. The first one demonstrates instance destruction (spot destroy), the second type-destruction (dog destroy). It might be beneficial to put both examples together into at the end of the block.

  I am leaving the decision regarding item 6 to Will. The others the pure typos and such and have been fixed in the CVS head now.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I have downloaded the zip file and I will incorporate the code and 
  the documentation in the math module. This means:
  - Changing the namespace for the package to math::statistics
  - Adding a standard header
  - Transforming the documentation to man page format
  - Using tcltest for the test case(s)


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Thanks! I have one fix to the man page. I realized that I made an incorrect description of what the tstat function does. Sorry about that. The attached man page should be correct.

  File Added: mvlr.man.txt


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I have updated the man page and converted the example to a test in accordance
  with tcltest.

  However, I came across two nasty/surprising aspects:

  - The statistics package now depends on the linear algebra package. I had to 
    add the command "useLocal linalg.tcl math::linearalgebra" at the start to 
    avoid set-up errors (still some spurious messages occur).

  - Leaving out the backslashes at the end of the data lines causes an error 
    in mv-wls: it will see but a single data point. This leads me to conclude 
    that the API is not quite appropriate yet: it should be possible to store the 
    data in a list of lists - right now it is more of a string that happens to
    contain some lists.

  We will need to look into this more closely


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Thank you for checking and spotting those problems! I should have mentioned the dependency on the linear algebra package. What is the best thing to do in this case? It will not be easy to recreate the features of the linear algebra package that I need, but I could do it.

  Regarding reading in data files - you're right, it should allow for that. I see that it's not robust enough. I'll work on that.

  Thanks again.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  The dependency on math::linearalgebra is not the actual problem: I would rather
  encourage the reuse of this functionality than duplicating it.

  No, the issue is that the test utilities as we use them in Tcllib have to know 
  of this dependency too. That is what I was asking about - it is new to me and it
  was actually very puzzling.

  More important is the issue with the backslashes - I will have a look myself too.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I realised what is going wrong without the backslashes: [eval] will then break up the
  data into separate lines! 

  Hm, perhaps we should use a different API:

     ols $alldata

  and 

     wls $alldata_with_weights

  instead of separate arguments.


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  That sounds right. It also avoids the awkwardness of using "eval" when calling the proc when the argument has been built as a list.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  Okay, we'll do it that way - only a very small change required.
  And avoiding eval is - in general - a worthy goal :)


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  Done.

  The call to the regression routines now take a single argument: a list of data or an alternating list of
  data and weights. This allows us to avoid [eval] and makes the precise formatting of the data much
  less important.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  It is true, the current value is replaced by the value of the bwidget configuration value
  buttonwidth.
  So, one may use the correct option index:
  option add *MessageDlg.buttonwidth 10 100

  Unfortunately, this was not documented jet.
  (but is now in cvs)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  Thats because your DNS server is handing out a CNAME for the first response. You might try 
   foreach answer [dns::result $token] {
      array set A $answer
      puts [list $A(type) $A(name) $A(rdata)]
   }
  Now RFC974 which covers MX records say "There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias  for some other domain name. The query should be repeated with the canonical domain name." which seems to me that you need to go and do a lookup on the CNAME from the application layer.


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: 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
  Originator: NO

  Fixed, now reporting the actual name of the missing variable, not the name used internally.


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
  Originator: NO

  Note: The newest revision of dtplite in the Tcllib CVS is able to link to a document by its title (per [titledesc]), when said title is marked up via [term]. This is hackish. It also does not support references to specific sections. This might need the RFE for explicit labels on (sub)sections (to get around problems with non-unique section titles) so that we can use these labels in the external references.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Restrictions on node names: I am not aware of any. The testsuite actually uses node names which have spaces in them. 

  Instead 'elements ("strings")' I would prefer to say 'named elements', and the 'named' implies that strings are involved.

  Added a paragraph 'The element names can be arbitrary strings'. This should also enforce the information you wanted about elements and strings.

  I have taken and added your comparison to the documentation as is.


  Side question: Was the new section in the struct::tree manpage about where and how to give feedback useful for you ? 


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  Is it intentional that the new Bugs section of the man pages do not show up in the generated (nroff at least) reference pages?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Are you sure ? I did a 'sak doc nroff' on a small sample right now and I see the feedback sections. Are you looking at the right directory ? Please put  this into a new bug report. It has nothing to do with Lars' doc improvement of struct::tree. (Despite my side question).


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  I think you can disregard that last comment. I'm seeing peculiar behavior by my man command here - I suspect the problem is bigger than tcllib man pages.

  What I am seeing in Sun's man command is occasionally missing sections, or parts of sections.

  No error msgs generated - stuff just isnt there _sometimes_ and is there later.

  Not fun.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  Re: Bug reporting section

  This hadn't (and still hasn't, I think) shown up on tcllib.sourceforge.net/doc, so I didn't use it. The info doesn't feel new to me, but I suppose the direct link might sometimes be useful (saving some clicks). OTOH, that's easily dwarfed by looking around the list of reported bugs to see if the one one has had already been reported.

  Re: Node name restrictions

  On lines 382-383 (description of [$tree insert]) it says:
  If names are specified they must neither contain whitespace nor colons (":").

  I can see the technical reason for the colon restriction (namespace hickups), but not for the spaces.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Bug reporting: Yes, the doc thing is updated only every once in a while.

  Name restriction. Thanks for the reminder and reference. The limits should be gone, the comment might be old and out of date. The node names are keys into arrays, there should be no namespace interaction at all. I will check. I am quite sure that whitespace in node names is fine.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok. Have checked. I believe you are using an older revision of "tree_tcl.tcl". The file found in the CVS head does not have 'neither whitespace nor colon' anywhere in it. The restriction may apply to the revision you have, but head revision definitely does not have it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Committed the changes I made. Just reopen this RFE if you have more comments.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed. The new section was put by accident into the list of references instead of after.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Patch for this is https://sourceforge.net/tracker/?func=detail&atid=312883&aid=1693491&group_id=12883
  Was accepted.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  this is a property inherited from a frame.
  If you replace the top by a frame, you have the same behaviour.
  If you want to reset the frame size, use
  $f configure -width 1 -height 1

  It might be correct that the observed behaviour is not the desired, but it should be modified within tcl, not Bwidgets.


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: 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: mic42
username: mic42
mimetype: text/plain
icomment:
  data_type - 112883

  Logged In: YES 
  user_id=302287
  Originator: NO

  Its there. Its just missing in the docs..., so this is really a documentation bug

  Try:

  asn::asnNull

  Michael


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: YES

  Note: We do not seem to have test cases for asnTag/asnPeekTag regarding PRIVAT, nor CONTEXT either. Only UNIVERSAL and APPLICATION.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  nyademo, do you have a png file with which we can demo the problem and fix ? I am currently extending the testsuite to show problem and fix, and found that the 2 images which have comments we have here are not triggering the problem. Therefore unsuitable for testing.


login: nyademo
username: nyademo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=932722
  Originator: YES

  Hi.
  I had to write my environment first, sorry.
  It seems to me that the problem is not exists on the png file.
  It is on my japanese environment. cp932 is default encoding 
  on windows. Maybe other languages have their own default encodings...
  It is a reason what output endoding must be binary.

  encoding system cp932
  png::removeComments $file

  This code may enable you to find the bug.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Updated testsuite now too. Won't fail for bug on unix, but does on win32, which is good enough for me. No need to fiddle with the system encoding.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641
  Originator: YES

  Raising the priority slightly, because this problem, unless solved promptly, is going to force me to code my little utility in C instead of Tcl.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Questions ...

  Do you a small script with which we can try to reproduce the problem ?

  Given that you seem to be already on the trail of the problem (unset get:channel) do you have by chance a patch/fix for it already too ?

  Regarding the placement of -async, I pass. Unfortunately it seems that Stephen Traeger, the original author has dropped from the net, so we cannot ask him.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641
  Originator: YES

  Ok, here is the little patch which resolves the problem -- for me.

  The comment above this piece of code is quite explicit, that get:channel must always be unset, but I don't think, it is quite true. In the case of an async Get (ftp(Command) is non-empty) the procedure will be returning right away and the get:channel must exist after it returns.

  Someone more familiar with code needs to verify the change, though...

  The beginning hunk of the patch makes the debug diagnostic include errorInfo -- just in case. It is not necessary for solving this particular problem, but may help solving future ones.
  File Added: ftp.tcl.diff


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 228232: ftp-test-async-get.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok, I tried to verify that the change doesn't do undue harm, and for that I wrote a test script to reproduce the problem. As I feared, and why I asked for a test script in beginning, is that my test script does not crash and burn, even if the submitted patch is not applied. In other words, I cannot reproduce the problem, and I have not enough information to say if it is my test script which is wrong, or if something else has to be different.

  I am attaching my test script together with this comment. Note: I am using CVS head of Tcllib, the revision of the ftp.tcl in question is 1.45. I am mentioning this because when I applied the patch the second chunk was done with an offset of 22 lines. This indicates that the submitters revision of ftp.tcl is different than what I am using, and that may influence the problem, or maybe it was fixed already by a different change.

  Given the knowledge I have right now I cannot distinguish between the possible cases.

  File Added: ftp-test-async-get.tcl


login: kot
username: kot
mimetype: text/plain
icomment:
  File Added - 228247: test.tcl

  Logged In: YES 
  user_id=173641
  Originator: YES

  Andreas, the script you attached does not use the ``-async'' flag... It should be:

  ftp::Open ftp.tcl.tk anonymous a@b -command yourproc

  I'm attaching a modified version of the script (it only performs one Get), which helps reproduce the problem with the unpatched version here. The patched version works fine.

  Yours,

       -mi
  File Added: test.tcl


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ah. See, I am stupid this way. I thought 'async get' just means use of the '-channel' option.

  Using that I can confirm that it fails before the patch and succeeds after.

  Looking deeper the comments at the change location make some kind of sense, adding instrumentation to all places dealin with get::channel reveals that the get:channel information is not reset anymore ...

  I am wrong ... For comparison I tried non-async, and added the second Gets again, and it works fine, despite the missing unset ... And going to pre-patch, non-async. I see that get:channel is unset, but DestCI is not, contrary to the comments written at the patched location. This code is a mess. A mess.

  I am accepting the patch as is, with a comment refering to the bug id and why we removed the catch, with reference to the location in handledata which blows up if the catch/unset is present. If this causes a new bug we can investigate deeper ...

  Best solution would be the creation of a new package with completely new innards.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I do not see this stacktrace, using tclsh 8.4.15.
  What version of tclsh was used for this ?


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: YES

  I use strace to check where this happens: It happens when scanning the tcllibc module (a tcllibc dir is created below modules when i use ./sak.tcl critcl first)


  So to reproduce first build the critcl modules.

  ./sak.tcl critcl
  ./sak.tcl validate

  I tried with 8.5a6 (HEAD from today)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Yes. Using this recipe I can confirm the problem, using Tcl 8.4. I.e. this is version independent, and simply something in the pkgIndex.tcl of critcl sak has trouble understanding ... Investigating now ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO


  Fix is to add

      # Now a stronger check for the actual command
      if {![regexp {package[ ][ ]*provide} $line]} {continue}

  in line 251 of sak.tcl

  The line 35 of critcl.tcl slips past the filters because I check for 'package' and 'provide' separately, and not as command. The above adds the stronger check.

  Fixed in head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Side note regarding use of this tracker: Pretty please _attach_ files in the future. Copy/pasting them out of the browser through windows and the X server to the editor is ... inconvenient. Downloading to the right location is much easier. Will conserve formatting (indentation, line breaks, etc.) too.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Was able to confirm demonstrated behaviour.
  Commenting the load of the 'tie' package makes it go away.
  Changing the order of loading has no influence, the problem remains.
  Starting to partially load tie.tcl to see how much is needed to trigger the problem.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  'tie' is not problem.
  Just loading 'snit' (used by tie) triggers the problem.
  Continuing the investigation ...
  It is the new library of validation commands (validate.tcl) ...
  Defining the first validation snit::type (boolean) does it.
  Which reflects us back to snit itself. Rather, the actual use
  of snit, versus just loading its code.
  Disabling Comp.Define setting the type definition ...
  Not enough ... Comp.Compile is enough to trigger.
  Yes, disabling the snit type compiler makes it go away.
  Comp.Init is enough.

  Ah, ah. This creates a sub interpreter, via [interp create]. Bets that this is the problem. std channels are shared between interpreters, and I guess that there is osmething in there which messes TclX up.

  Confirmed ... 

  Replace the 'puts [package require tie]'
  with 'puts [interp create]'
  and you get your bug.

  Tie only exposes this, the root cause is somewhere in the core, its handling of std channels, and interaction with Tclx.

  I am closing this bug here, please report this in Tcl's bug tracker.

  (And while I am nominally responsible for Tcl's I/O system, and thus the std channels, the sharing of them between interpreters is not something I fully understand. And how this could influence TclX. Actually not fully true ... A first guess would be that TclX dup's the channel at OS level, making a new channel at Tcl level and somehow Tcl then gets confused.)


  Another question to consider ... When you went back to Tcllib 1.8, did you also change Tcl intepreters ? I.e. an older revision of the Tcl core itself ? Because I am quite sure that 'tie' in Tcllib 1.8 ... Ah, ok. Yes, tie in tcllib 1.8 uses snit already, however snit did not have the validation stuff ... Despite this tcllib 1.8 should exhibit the bug you see as well, the moment a snit::type is defined ... Was not dependent on snit in 1.8 ? You can try and remove thesnit dependency from tie ... I see nothing immediate why it is present ... Ah. While the tie core is not dependent on snit the standard data sources all are. However they are not loaded immediately, so not snit type is defined when tie is loaded and things go okay. For a while. When you get a sub interp later on by the first snit definition, or something else TclX will likely blow too. It is just delayed a bit.

  For now I consider the bug report as 'Rejected' here, because it is only a sympton for a Core/TclX bug.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  This is the same problem already mentioned in Bug 1645333 (for asnGetContext), which is fixed in CVS HEAD (since Version 0.8.1).


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  won't there also be a problem if the file to be ftp'd has spaces in the name?


login: nobody@207.203.88.15
username: nobody@207.203.88.15
mimetype: text/plain
icomment:
  Logged In: NO 

  Yeah, I forgot to mention that I rewrote the STOR command in my ftp server.  The ftpd::read command will get a line like:

  "STOR this is my file name.txt"

  If you split that line, it looks exactly the same.  Then it calls ftpd::command::STOR and currently: 

  set filename [lindex $list 0]  which would have a file on the server called "this"

  However, my STOR command says: set filename $list

  I think it's important that this package allow spaces in the names, since most windows users like to have spaces.  That's just my two cents.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Re-reading the RFC 959 I think that the whole command/argument processing in the server is wrong. We are treating the line as  Tcl list (set parts [...]) but the RFC says that after the command comes one separating space char, and everything after to the end of the line is one argument field, spaces and all. Which means that the code separating command and argument has to be redone ... Hm ... Possible solution is 'regexp' to find and split on first space.

  regexp {^([^ ]+) (.*)$} $command -> cmd argument

  and the lindex/lrange commands in lines 538 and 553 can be removed, replaced by the variables set by the regexp.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 230158: ftpd.diff

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 230163: ftpd.diff.2

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff.2


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 242204: tsrsplit.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  Attaching a quick hack I made quite some time ago for regular tcltest logfiles, 'tsrsplit.tcl'. That one was for getting expected/is output for use with tkdiff.
  File Added: tsrsplit.tcl


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: YES

  Are there log files generated when I do a normal make test? If so, where? All I was aware of was the "fancy" output that was displayed.

  Would the attached script be appropriate to add in the tcllib distribution?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Attached script in tcllib - not yet. It was a quick hack, not very polished, and only useful in combination with other commands, like tkdiff or eskil, i.e. lots of manual work still. It is semi-related, as it also processes test output.

  log files via 'make test'. The CVS head got some changes to 'make test': 'make test_interactive' -> fancy output, 'make test_batch' -> detailed output. 'make test' now chooses automatically. Fancy normally, and when redirected to a file it does the detailed log.


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1312539
  Originator: NO

  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  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: 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: kakaroto
username: kakaroto
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=686750
  Originator: NO

  oups.. submitted as nobody. should be submitted as 'kakaroto'. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hello KaKaRoTo,

  thank you for the report.
  I have tried to emulate the situation with the following script.
  Unfortunately, I could not reproduce the situation.
  May you:
  - check if the issue is still there with the current implementation
  - provide a demo script.

  Thank you,
  Harald

  #-- Test script ---
  wm geometry . 500x500
  pack [ScrolledWindow .w -bg red] -fill both -expand true
  ScrollableFrame .w.f -constrainedwidth 1 -bg green -height 500 -width 500
  .w setwidget .w.f
  set f [.w.f getframe]
  pack [frame $f.f -bg yellow -width 100 -height 100]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  By direct mail, KaKaRoTo provided the following test script:

  Anyways, the latest release is from 2006 and is 1.8.0 which is the same that we have in aMSN.. I just tried again to reproduce it (removing our workaround) and the issue is still there.. I wrote a small test program to reproduce it :
  #!/usr/bin/wish
  package require BWidget
  wm geometry . 500x500
  ScrolledWindow .sw
  ScrollableFrame .sw.sf -constrainedwidth 1
  .sw setwidget .sw.sf
  pack .sw -anchor n -side top -expand true -fill both
  set frm [.sw.sf getframe]
  canvas $frm.c -width 100 -height 100 -bg white
  pack $frm.c -expand false  
  All you have to do is *slowly* resize the window to a smaller size and you'll see the scrollbar appearing..If you only resize the height (without modifying the width), then the scrollbar will become smaller and you can move it.. as soon as you click on it, it will disappear...
  If you add these lines to the end of the script, the issue will disappear :
  proc ::ScrollableFrame::_frameConfigure {canvas frame width height} {
     $canvas:cmd configure -scrollregion [$canvas:cmd bbox all]
  }
  I hope this was helpful and I hope you can fix it upstream soon!
  Thank you,
  KaKaRoTo

  I have checked it:
  - Release 1.8.0: issue is there
  - current cvs: issue is not there (I don't know why but I don't bother
  at the moment).

  So if you allow, I will close the ticket without modifications on the current code.


login: federico__
username: federico__
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1628983
  Originator: YES

  sorry, Tcl Wiki is under maintenance. best to check that: http://rafb.net/p/tQ0k4t70.txt


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I will be looking into these shortly. I got the code from "ratfb" as a reference implementation.
  What we will need further is a few test cases and documentation. But let me study the code a bit
  first :)


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I have started the incorporation of the code into the linearalgebra package.
  That is: I am writing some tests to check the code (removing Tcl8.5-isms and
  one or two bugs along the way).

  Suggestion for the determinant:
  Use LU decomposition and then multiply the diagonal elements to obtain
  the determinant. (I am not familiar with cofactors, I am afraid, so I 
  cannot comment on their usefulness, but this would speed up the 
  computation).


login: federico__
username: federico__
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1628983
  Originator: YES

  hmmm....
  didn't know about LU (LDU) decomposition. I quickly read about it on wikipedia, an I see it is a slightly modified Gauss-Jordan algorithm.

  AFAIK Gauss elimination *changes* the determinant (well, it does in a predictable way). I can't find this information on the "LU decomposition" page though...
  also the Gauss algorithm has some quirks that make the code more complicated (if one wants to work with any kind of matrix), so it will require me time & knowledge (now I am a bit busy with exams)


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  No, Gauss elimination does not change the determinant: you add a multiple of an existing row to another row and determinants are invariant under this operation. LU decomposition is indeed little
  more than Gauss elimination (I use the terms as synonyms).

  We should not be hasty - better do a good job that takes a bit longer than a sloppy one. So don't
  worry.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  File Added - 240843: toregexp.dtx

  Logged In: YES 
  user_id=938835
  Originator: YES

  OK, I now have a working implementation, but it's nowhere near being integrated with the grammar::fa package. I probably won't do further work on this for a while, so I just wanted to make the results available.

  To load the code as provided, do:
   package require docstrip
   docstrip::sourcefrom toregexp.dtx pkg

  Top-level commands made available:

     grammar::fa::op::toRegexp $serialization
  Returns RE for the language accepted by the automaton whose serialisation is $serialization.

     grammar::fa::op::toRegexp2 $serialization
  Same, but tries to expand choices in the regexp.

     grammar::fa::op::simplifyRegexp $RE
  Seeks to simplify a regexp by converting it and all its subexpressions to an automaton (which is minimized) and back, picking the shorter of the two. (Seems to find some simplifications, but not others.)

     namespace inscope grammar::fa::op::tclre $RE $dict
  Converts a grammar::fa-style regular expression $RE to a Tcl-style regular expression (or rather a pair of a "surface type" and the actual regular expression). The $dict maps symbol names to such pairs. If a symbol is not in the dict then single-character symbols are interpreted as those characters and other symbols are interpreted as character class names.

  I will also attach a typeset form of the source. It might help explain the algorithm used.
  File Added: toregexp.dtx


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  File Added - 240844: toregexp.pdf

  Logged In: YES 
  user_id=938835
  Originator: YES

  In case you're not completely discouraged by the power series interpretation of formal languages that underlies the algorithm I used, the book

  Werner Kuich and Arto Salomaa:
  Semirings, automata, languages,
  Springer-Vlg, 1986 (ISBNs 0-387-13716-5 and 3-540-13716-5)

  develops this theory in more detail.
  File Added: toregexp.pdf


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  We actually had a method which nearly did what you wanted, symbols@. Was not really documented however.
  This method has been extended for what you need:

      FA symbols@ s1 s2

  returns the set of symbols which transition from state s1 to state s2. The set is empty if there are no transitions between the two states. The empty symbol in the set indicates epsilon-transitions.

  That should make the generation of the matrix simpler.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Note: The nullary .| has been submitted and can be used for this now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Accepted, and integrated. small change: toRegexp(2) takes an FA instead of a serialization of one. The serialization is done inside of the proc.
  Also wrote a wrapper command to the tclre namespace for infic translation => toTclRegexp.
  I would now really like to have examples and test-cases for this.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  I'm currently away at a conference and have very shaky internet connection, but I'll see what I can do.

  A catch concerning testing toRegexp (did it get spelt that way?) is that there can be many REs representing the same language, so it's a bit difficult to compare against. Maybe the best way is to have a set of test words and verify that Tcl's RE engine recognises the same subset of them as the grammar::fa engine does.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Note: I already added some minimal testing for toRegexp, toRegexp2, simplifyRegexp, and toTclRegexp, based on a FA I found in some online material about FA theory.
  Of course, more testing is welcome, very much so.


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  Fixed it - thanks for reporting this (I must have overlooked running the doctools)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed the description of the basic layer and messages.
  The SYNOPSIS section is currently always generated, even if not needed. This would be an RFE for doctools, not comm.
  EOL shown as whitespace fixed. I guess that doctools handled the \n in the text incorrectly. This could be a doctools bug, either general, or in specific backends.
  Added comm as keyword.
  Leaving 'communication' as keyword. The keywords describe the general topic of the document, and communication is certainly fitting.

  Committed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Synopsis lists commands in the order they are listed in the manpage body. Actually doctools hasn't specified any type of order for the sysnopis ... I.e. this is an undocumented implementation detail ... Fixed order in the body.

  Capitalization ... Apparently most explanations use uppercase tag names. See html::bodyTag, checkbox, checkSet, etc. I guess it is simply a kind of markup. ... Changing to lowercase now, and using 'term' as markup for tags, i.e. relatively general semantics. ... Done.

  openTag ... Worse, the param argument is even optional and not documented as such. It is actually not documented at all. Fixed.

  row ... done.

  Examples ... I haven't written this module and don't really know how to use it, therefore I am not really suited to writing examples.

  I am leaving this report open, with modified summary, unassigned, for whoever is able to provide examples.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  I also noticed this.  The explanation for title says: ::html::title title 
  Side effect only. Call this before ::html::head to define the TITLE for a page.

  This is incorrect.  ::html::title is called by ::html::head; calling ::html::title before calling ::html::head would have no effect. Calling ::html::title after callilng ::html::title would change the result of calling ::html::getTitle, but it does not affect the title of the page.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  A couple more clarifications.

  tableFromArray creates a two-column table with a heading that matches the array name, and each row containing a name, value pair. The array names are sorted by lsort before use.

  tableFromList creates a two-column table from a nonempty, with each row containing a label, value pair. 


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  The following procedures exist in html.tcl but are not documented: css, doctype, js, tagParam, urlParent.

  The following procedures are not listed in alphabetical order: init, minorList, paramRow, set.
  This makes their documentation harder to find.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Going through the accumulated comments

  html::title - Are you saying the documentation is wrong, that the behaviour of the package is wrong, or both ? From the description you give it seems to me that the documentation may be right, and actual behaviour wrong. However, not being the author, I am not really sure. Should the behaviour be wrong then this should be submitted as a separate bug.

  TableFromArray/List - I am guessing that you are asking me to extend the documentation for them, based on the described behaviour ?

  Undocumented procedures - I do not know what they do either. Can you draw up some documentation for them for me, and attach to this bug ?

  Sorting minorList, paramRow, etc. - I sorted these yesterday, see my first comment 'Fixed order in the body.'


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099
  Originator: YES

  html::title documentation is wrong. It's used inside the package, but having the user call it makes no sense since it's called by html::head where the title is required anyway.

  Yes, I think the real behavior of tableFromArray/List should be documented.

  I can try to infer documentation to the undocumented procedures.

  I wasn't sure if you fixed all the sorting problems.

  I've been thinking of making a different version of this that would allow creation of more than one stack.  I might if I can find the time.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  tableFrom{Array,List} documentation extended. html::title documentation disabled (effectively removed from output, still in the .man, as comment). Committed. When documentation for the undocumented commands comes in this bug can be re-opened, or a new bug made.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  Previous version used to pad keys to 64 bits so the key because "SeCrEt\0\0"
  Added an improved error message for short keys.
  If using the old command options, enable key padding with nulls.
  Added test.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Check ... Is the -type feature supported by Tcl 8.3 ? The 'file join' can be replaced '-directory $dir *' as well. Also a feature not likely present in 8.3. Work on that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This is partially done already. All the manpages in the CVS should by now have a section abouts Bugs, and Feedback, and pointing to the SF Bug tracker for Tcllib.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: YES

  That's sounds very useful. Adding it to a README in either the top, src, or devdoc directory seems like another useful location.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This was possibly due to the new dependency of math::statistics on math::linearalgebra. That was fixed in the Tcllib CVS head. Please test if your problems is still present. Platform is solaris ?


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  What version of the ldap module do you use? (what is returned by package require ldap)


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  Does it also fail with a more recent ldap version (best use 1.6.8 from cvs if you can, you need an updated asn package too). If you don't know how to check those out from cvs i can send you a small zip file with both packages, just email me...

  The output from the ::errorInfo when the error occurs would also help to pinpoint the problem.

  1.2 is already quite old, and i cannot reproduce the bug it with my local setup and ldap 1.6.8.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed.
  Listbox deltes the item widget as bwidget (bwidget::delete) but postphones the delete in the canvas to a after idletasks routine.
  An eventual pending resize event may be executed between the two tasks.
  The error may arise due to the half deleted item widget.

  A patch is attached. It consists of a check if the widget (to update) is on the "to-delete" list.
  Alternate solutions:
  - a simple catch -> drawback -> errorInfo pollution
  - a check if the widget was removed (widget::exists path.item

  Patch for listbox.tcl:
  1069,1070c1069,1072
  <         $path.c itemconfigure "n:$item" \
  <             -fill [_getoption $path $item -foreground]
  ---
  >         if {-1 == [lsearch -exact $data(upd,delete) $item]} {
  >             $path.c itemconfigure "n:$item" \
  >                 -fill [_getoption $path $item -foreground]
  >         }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok, made a commit which fixes most of the trouble. The only thing I still have to look into is 'snit'. When generating a DVI from its LaTeX file LaTex complains about 'too deeply nested'. I have to see what is happening there regarding nested lists and such.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed latex processing completely. Problem was usage of 'quote'-environments in list-items. TeX restricts us to 6 levels, we had 4 + the quote's made 7. Now we can nest lists 6 levels. Also fixed a lot of quoting problems for special characters, when they are needed, when they have to be quoted, prevent double-quoting of already quoted parts. Etc. Added code to SAK for pdf generation.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  fileutil::findByPattern is based on fileutil::find and this command likely exhibits the same behavior. IIRC the basedir is 'normalized' and you get that back in the results. I.e. [file normalize /net/<machine>/export/disk1/...] is '/export/disk1/...'. IIRC (again) this is cross-platform behavior.

  There are efforts underway to redo fileutil::find to be more maintainable (currently we have about 3 or 4 variant implementations for win vs unix, Tcl 8.4+ vs Tcl 8.3- etc.). This report could be addressed as part of that work.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok. Fixed with the recent rewrite of fileutil::find, and committed to CVS head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  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
  Originator: NO

  Yes, a duplicate of [ 1774302 ] error in CommRunHook error handling, @ https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1774302&group_id=12883

  Already fixed in the CVS 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: pointsman
username: pointsman
mimetype: text/plain
icomment:
  File Added - 242147: patch_v2

  Logged In: YES 
  user_id=13222
  Originator: YES

  After email feedback by Andreas Kupries, I updated the patch. Minor changes, the propose still stands as outlined in the feature request.

  Patch is still bare implementation.
  File Added: patch_v2


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Committed a modified patch, with slightly different option processing (-pkgdir (singular)) and defaults. All the wanted functionlaity is still present.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Something in just this test ... I am not sure about that. The test framework in sak uses Ctrl-M, aka CR, aka \r, aka 0x0D to move the cursor to the beginning of the current line without advancing a line, before printing the next line. To me it looks a bit like the terminal or other is gobbling this character, or transforming into linefeed (LF, \n).

  Well, I am running now on a solaris box too, will see if I can see the same problem. Setup is similar, xterm, Exceed server on WinXP. No gnome tough.


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: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287
  Originator: NO

  This can be done with the logger package with a custom logproc that uplevels, look at the examples at the end of the manpage:
  http://tcllib.sourceforge.net/doc/logger.html


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  TIP#190 ... Right, we should make a reference to that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Applied and committed to head. Thank you.
  No reference to #190 yet.


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Duplicate of https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1793855&group_id=12883
  Note: While this is fixed in the CVS Head it came to late for inclusion into the 1.10 release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed, v0.2 of pluginmgr committed to head. Cause was bogus space between a * and its backslash, i.e. the code read '\ *' instead of '\*'. This prevented the conversion of the * into (.*), so the resulting RE pattern had no capturing parentheses, and so the 'plugin' variable was not set to the plugin name part of the package name, but left empty.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Confirmed. Fixed. Committed to the head. Now 'struct::list 1.6.2'. Thanks.


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Regarding section titles. They are passed through as is from the input, currently by all backends. If you do not write all-caps they will not be all-caps in the output ... Could the real request be that you wish to write your titles normally, and the nroff backend convert it to all-caps, with the html backend passing them unchanged, as it does now ?

  Regarding the Table of contents. Do you have a concrete proposal or ideas for how the formatting of the TOC should be done instead ? Regarding the Synopsis the same question applies. Ditto regarding the formatting of examples.

  Paragraphs. As far as I know that is legal HTML, although possibly not legal XHTML. I agree, closing them would be nicer. The same for definition lists. I have added these to my TODO lists.

  dtplite has possibly quite rigid expectations. That is part of the reason it has the 'lite' moniker, as it made the implementation less complex. Is it possible for you to write up how your directory structure looked like, how dtplite behaved on it, and how your symlink forest helped in that regard ? Is it also possible to clarify the question on "how to add C library docs" a bit ? I have trouble understanding the problem with that ? From dtplite's perspective this would simply be another module in another directory. I think, if I interpret your question correctly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  The closing of list elements (dt, dd, li) is now done. The closing of paragraphs is mainly done. Paragraphs in list elements do not get closed yet.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I think I am will use this bug report as the one where we can discuss HTML styling in general.
  From the tcler's chat ...

  [15:43]<RockShox>aku continuing from yesterday re doctools
  [15:43]<RockShox>the class names dont matter as long as its documented
  [15:45]akuI guess. I added lots of lcass names today, no docs however yet for them.
  [15:52]<RockShox>its nice to have some divs too
  [15:52]<RockShox>like around the toc
  [15:52]<RockShox>or examples
  [15:53]akuI have no idea what you can do with CSS, please file bug/enhancement reports with examples of how you wish to change the HTML
  [15:55]<RockShox>you dont need to know what i can do with css
  [15:55]<RockShox>you just need to give me a way to address the distinct parts of a doc
  [15:55]<RockShox>if that makes sense
  [15:56]<RockShox>it probably means most doctools commands should generate something within a div or an individual tag with a class name
  [15:58]akuI may have phrased  my words badly too ... I have no idea what exactly you want me to put into the HTML which would support CSS. What is a div ? what attributes does it  have? things like that. I can work better when I see a concrete example of the change wanted, for this
  [16:00]<RockShox>a div is just a division
  [16:00]<RockShox>it doesnt really do much
  [16:00]<RockShox>but if you give it a class then the css can distinguish anything within that div
  [16:01]<RockShox>like i could make a link inside an example div different than a normal link
  [16:01]<RockShox>by addressing that class
  [16:05]akuso you are talking just about adding <div class=XXX>...</div> around certain things, or most things ?

  What is your opinion about this ?

  I am amenable to redo the generator to make it more accessible to CSS based styling.
  This pertains to the items in the report here too. Will adding divs and classes make the nested table superfluous, to be added back if wanted by css, or overridable by CSS, or ... ?


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES


  Re formatting block level elements...


  The auto-generated table of contents at the top of each page currently looks like this:


  <h2><a name="table_of_contents">TABLE OF CONTENTS</a></h2>

  <p>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#table_of_contents">TABLE OF CONTENTS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#synopsis">SYNOPSIS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#description">DESCRIPTION</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#commands">COMMANDS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#examples">EXAMPLES</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#see_also">SEE ALSO</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#keywords">KEYWORDS</a><br>


  (bug: note that "TABLE OF CONTENTS" appears twice; as a header and within the table of contents.. :-)


  It probably should look something more like this:



  <div id="table-of-contents" class="section">

    <h2>Table of Contents</h2>

    <ul>
      <li><a href="#synopsis">Synopsis</a></li>
      <li><a href="#description">Description</a></li>
      <li><a href="#commands">Commands</a></li>
      <li><a href="#examples">Examples</a></li>
      <li><a href="#see-also">See Also</a></li>
      <li><a href="#keywords">Keywords</a></li>
    </ul>

  </div>



  The synopsis should probably look something more like this:


  <div id="synopsis" class="section">

    <h2>Synopsis</h2>

    <ul>
      <li><a href="#ns_sls-get"><strong class="cmd">ns_sls get</strong> <i class="arg">key</i> <span class="opt">?<i class="arg">value</i>?</span></a></li>
      ...
    </ul>

  </div>



  The commands sections currently looks like this:



  <h2><a name="commands">COMMANDS</a></h2>
  <p></p>

  <dl>

  <dt><a name="1"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> ?<i class='arg'>args</i>?</a></dt>
  <dd>Pre-startup procs are called...
  <br><br>
  </dd>

  <dt>...



  It should look something more like this:



  <div id="commands" class="section">

    <h2>Commands</h2>

    <dl class="definitions">
      <dt id="ns_atprestartup" class="call"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> <span class="opt">?<i class='arg'>args</i>?</span></dt>
      <dd>Pre-startup procs are called...</dd>

    </dl>
  </div>



  The pattern is:

  - All sections have their own <div>, and the div wraps everything including the title

  - They all have a class of 'section', and an id. An id is like a class, you can use it for styling. However, it must be unique within a page, and is the recommended way of linking within a document. So, this works: cmd.html#synopsis. 

  - The id is the section name

  - Definition lists seem to be reused within doctools, i.e. [call ...] is another way to say [def ...], so we add a class of 'call' to the <dt>, even though it already appears within a <dl> classed with 'definitions'.



  The styling that used to be applied directly to the HTML elements can be moved to an embedded style sheet at the top of the page. If, the user passes a -style option to dtplite, the embedded styles are omitted and the link inserted.

  For example, to some vertical space between each section, and indent the Table of Contents, the styles will look like this:

  <head>
    <style type="text/css">
    <!--
      .section {margin-bottom: 2em;}
      #table-of-contents {padding-left: 4em;}
    -->
    </style>
  </head>


  The Table of Contents is a section, so it has both styles applied.



  Also, the whole content section should be enclosed in a div, like so:


    <body>
      <div id="doctools"
        ...
      </div>
    </body>


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Some clarifications ...

  Wrapping sections into div's ... A bit more complicated than you might think, as I know when a section starts, but not immediately where it ends. May need state flags ... At least I have to number more than one place ...

  id = section name ... you seem to actually use 'lower case section name'. what about spaces in the section name, is that allowed to be in the id too ? Or should we replace with underscore ?

  'call' = 'def'. Not quite. 'call' wraps an anchor around the defined item, and puts the information into the synopsis. 'def' doesn't do these things. Beyond that they are identical, yes.


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  Yes, I canonicalised ID's by bashing to lower case and replacing spaces with dashes.

  I'm pretty sure you can't have spaces in ID names. If it were a class it would be considered two class names, but for ID's I'm pretty sure you can only have one anyway. Still, ID names are also used in fragments (the bit after the #hash in a URL) and in general it's a pain to have spaces there.

  I used dashes instead of underscores again because of the URL fragment. URLs are often shown underlined and it's sometimes difficult to distinguish an underscore from a space when the word is underlined.

  I forced to lowercase because of the requirement that nroff and html output titles in deferent cases. Probably best here to accept any input from the source, and force to uppercase for nroff, title case for html, and lower case for ID names. It's predictable for people generating URLs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I found later that I am generating the id's by going to lower case, and replacing
  spaces with underscores. Point taken regarding underscore/space vs. dash.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Started to work on this again in the last few days (*) - cvs head now contains:
  - sections, subsections are now closed. they are put in div's.
  - examples are in divs (still have to drop the wrapping in table), sectref in spans.
  - whole body in a div
  - still to do: redoing toc and synopsis, embedded style, and lots of other small things.

  (*) Now that I have a big set of formatting examples used by the testsuite to check the output.
      (see doctools/tests/man/* for the testcases, doctools/tests/html/* for the current results).

  Regarding id's I have seen another way of generating them, in the tcler's wiki.
  It uses the crc16 or crc32 of the section title, formatted as hex.
  I believe an md5 would be better, more collision resistant. for subsections merge in the section title
  predictable generation, no issues with any type of casing, no spaces, no dashes, no underlines.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  It seems section titling is the only thing I have left to do with this, and the generation of nice (sub)section ids.

  Examples are now properly classed, without lots of tables and such. TOC and synopsis are now styled through the CSS as well, and a standard CSS is placed in the output. At least if the 'meta' engine parameter is not set. If it is it is assumed that its contents will specify their own style, be it internal, or external. Paragraph handling is now done into, through and in lists / list elements as well, so that should look nice too, now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Anchors for (sub)sections are now nicely generated (sectionNNN, subsectionNNN), nroff does automatic upper-casing of (sub)section titles, HTML doesn't do that any longer. The automatic sections (like keywords, see also, etc.) are now camel-cased instead of full uppercase. This completes the handling of this report.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  Added option to left justify the label.
  I'm not so sure about adding an option -- I can't really see the utility of centering the text.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  Fixed up the manual with this plus comments for all the commands.


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: 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:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed in cvs head. Not sure if I got everything. One of the other bugs you reported seems to suggesst (implicitly) that we should add classes to list start/item/end as well. That I have not touched. Not yet done either is documentation for the class names in use in the output.


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  This seems to cover at least the markup I've used so far. Great, thanks.

  I did notice that the [opt ...] macro doesn't output any HTML tags, just surrounds
  it's argument with ?...? pairs. Can this also have an HTML tag?

  So, this code:

    [opt [option "-maxrun [arg n]"]]


  Which results in this HTML:

    ?<b class='option'>-maxrun <i class='arg'>n</i></b>?


  Should instead produce this:

    <span class="opt">?<b class='option'>-maxrun <i class='arg'>n</i></b>?</span>


  i.e. wrap the whole thing in a span with CSS class opt.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Re [opt]. Yeah, could be done. Question. Rockshox asked to add <div>'s around things. Now here you are saying <span>. What is the difference between both ? Or, in the concrete case of [opt], could a <div> be used instead of <span> ? how interchangeable are they ?


login: sdeasey
username: sdeasey
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=87254
  Originator: YES

  A <div> is a block-level element. Like a <p> or <ul>, it begins a new line, and
  the content following it begins on a new line. A <span> is an inline element, like
  <b> and <i>.

  So in this case you need a span, because it needs to appear inline with the rest of
  the arguments and options.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  The cvs head of tcllib doctools should have class names for all the semantic markup now, and span where classes where not possible, so I am closing this one. If there are classes/ids/spans/divs missing please open a new bug for them specifically, or put the notice into http://sourceforge.net/tracker/index.php?func=detail&aid=1798427&group_id=12883&atid=112883, the general bug about HTML output and its styling (while it is open).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed in the CVS head. This was problem with the doctools core, not just dtplite. The layer doing syntax checking generated the warnings in all passes. For HTML, a two-pass backend, that caused two warnings per actual problem. Modified to suppress generation of warnings in a ll but the first pass. Errors were no problem, as they stopped execution, i.e. in the first pass.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Fixed in cvs head. Note that IMHO The * belongs to the Ns_Sls, not the 'sls'. I.e. it should be part of the type, not the function.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Accepted. Command is 'uevent::list'. Advanced package version to 0.2. This command was also needed for a proper testsuite, to allow us to check that bind/unbind work as expected.


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636
  Originator: NO

  next time, provide a complete description of what you are doing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I am guessing that this the same as RFE [892318], just more detailed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Tcllib 1.9 ... Can you try Tcllib 1.10, or even the CVS head, fileutil 1.13.3 ?

  If the problem is still there please attach a script which creates a directory hierarchy which with it is possible to demo the problem.

  The traverser has code to avoid following circular symlinks, however the symlinks themselves should appear in the output.

  Note that we also have 'fileutil::traverse' which might be different, or not. It would be interesting to know, for comparison.


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214
  Originator: YES

  Further analysis shows that the [glob] used in GLOBF and GLOBD for tcl8.5 doesn't return a reference to a symlink which has a non-existent target.

  Thus, it's impossible to use fileutil::find to locate and resolve such symlinks (which is what I was trying to do :)

  I'm not sure if this is a bug or not, anymore.  It's unexpected though.


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214
  Originator: YES

  On further reflection, it's clear that [glob -type XXX] can't return a broken symlink no matter what XXX is, unless it's 'l' for link, because after all it can't determine the type of a loose link.

  It may be worth noting in the docs that such links won't be returned by find.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  OTOH, it should be possible to ask for '-types l' and then filter out those which are file/dir and thus not dangling, leaving us with dangling symlinks we can add to the result. We have 'file type' for an easy check.

  I think I will add a testcase first, if we don't have it already.


login: mstrhh
username: mstrhh
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1928531
  Originator: NO

  I submitted the bug.

  The bug makes it impossible to run automatic email processing with file attachments.


login: mstrhh
username: mstrhh
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1928531
  Originator: NO

  Debugging gives this analysis:

  the parsepart code has a fixed line ending sequence of "crlf" coded in. Converting the input file to crlf line endings solved the extraction problem.

  So expect to have problems on Mac and Unix with this code.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  The bug has been fixed now, and the modification is now in the SF Tcllib CVS, together with an extended testsuite.

  Deeper analysis:

  The trouble is line 893 mime.tcl

  parsepart has parsed a part of the multipart out of it and is about to recurse into this sub-part for further analysis (part headers).

  It has start/end offsets, both of which are ok and now computes the size of the part. The general formula is
  size = end-start-1 = end-(start+1)

  However the actual size of the part is without the last EOL char (sequence). So this changes to

  size = end-start-eol-1 = end-(start+eol+1)

  Looking at the code we see a 'end-(start+3)', implying that mime assumes eol = 2, i.e. a 2 char eol sequence. Which for our case (plain unix file) is wrong. Luckily for use we can determine the actual length of the eol sequence in line 855f. If a \r is detected and removed eol = 2. Otherwise eol = 1.

  Replacing +3 with eol+1 and eol per above gives us a good size for the part and the resulting file is ok, without missing characters.


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  I will have a look at it - perhaps a problem with integer values (rather than floats)?


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Apparently not an integer problem:

   ::math::statistics::cdf-normal 0.0 1.0 0.0

  gives the same error.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048
  Originator: NO

  No, I assumed it was because that is a common mistake with converting Fortran or C code to Tcl.
  However, we are in some limit situation for the algorithm. The quick-and-dirty solution is treat 
  x=0 as a special case. 


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  I can do the quick-and-dirty workaround no problem. Thanks! I just wanted to bring it to your attention.

  Take care,
  Eric


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Converted and committed (See bottom of tests/faop_regex.test). Note: T'was a bit difficult to copy the code out the report, well, and then fixing the broken lines to get back usable Tcl. Please _attach_ examples and such as a file next time.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This seems to be a dict'ionary ordering thing. The tcllib testsuite support provides a 'dictsort' command to generate a canonical representation, whatever the ordering returned by Tcl. This is not as important any longer now that dicts are keeping insertion order. It was originally made because Tcl 8.4 and 8.5 returned dicts and arrays in differing orders due to changes in the underlying hash(table).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Committed updated tests to CVS. Note: The tests can run with a Tcl 8.4 using the backported dict package. This combination will now fail as the backported dict does not have the ordering changes of the Tcl 8.5 dict. either the backport has to be updated, or the testsuite has to get two tests per actual test, one per variant.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  This tests relies on the output of the builtin string command of the core in case a bogus method is used. It seems that the methods 'totitle' and 'toupper' have switched places. The new order is alphabetical ... It seems that the two tests are both already constrained to Tcl 8.5 only, that makes fixing it trivial, no need to create separate test cases for 8.4/8.5.


login: nobody@69.3.114.94
username: nobody@69.3.114.94
mimetype: text/plain
icomment:
  Logged In: NO 

  Also, the error message begins with a different string: "unknown or ambiguous subcommand" as opposed to "bad option".


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859
  Originator: NO

  Surprisingly, I don't have a test case for this--but in fact it's perfectly OK for an object to destroy itself.

  Of course, it shouldn't try to do anything else after calling "$self destroy".... 


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  There was an error in random-gamma. Here is the corrected version:

  # Generate a list of gamma-distributed random deviates
  # Use Cheng's envelope rejection method, as documented
  #   in Dagpunar, J.S. 2007. "Simulation and Monte Carlo:
  #   With Applications in Finance and MCMC"
  proc random-gamma {alpha beta number} {
      if {$alpha <= 1} {
          set lambda $alpha
      } else {
          set lambda [expr {sqrt(2.0 * $alpha - 1.0)}]
      }
      set retval {}
      for {set i 0} {$i < $number} {incr i} {
          while {1} {
              # Two rands: one for deviate, one for acceptance/rejection
              set r1 [expr {rand()}]
              set r2 [expr {rand()}]
              # Calculate deviate from enveloping proposal distribution (a Lorenz distribution)
              set lnxovera [expr {(1.0/$lambda) * (log(1.0 - $r1) - log($r1))}]
              if {![catch {expr {$alpha * exp($lnxovera)}} x]} {
                  # Apply acceptance criterion
                  if {log(4.0*$r1*$r1*$r2) < ($alpha - $lambda) * $lnxovera + $alpha - $x} {
                      break
                  }
              }
          }
          lappend retval [expr {1.0 * $x/$beta}]
      }
      
      return $retval
  }


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Also, adding a better way to test the random deviates. Now for the testing routine, add the pdf to the histogram of values. Here's the revised testing code:

  ##########################################################################################
  ##
  ## TESTING
  ##
  ## Can test pdf & cdf by running in a console. For random numbers, generate histograms:
  ##
  ##########################################################################################
  canvas .c
  pack .c -side top
  frame .f
  pack .f -side bottom
  label .f.alphal -text "alpha"
  entry .f.alphae -textvariable alpha
  pack .f.alphal -side left
  pack .f.alphae -side left
  label .f.betal -text "beta"
  entry .f.betae -textvariable beta
  pack .f.betal -side left
  pack .f.betae -side left
  button .f.run -text "Run" -command runtest
  pack .f.run -side left

  proc runtest {} {
      set vals [random-gamma $::alpha $::beta 5000]
      set remainder 5000
      for {set x 0.0} {$x < 20.0} {set x [expr {$x + 0.25}]} {
          lappend bins $x
          set distvallow [pdf-gamma $::alpha $::beta $x]
          set distvalhigh [pdf-gamma $::alpha $::beta [expr {$x + 0.25}]]
          # Total trials (5000) * step (0.25) * average value
          set distval [expr {int(5000 * 0.25 * 0.5 * ($distvallow + $distvalhigh))}]
          lappend distcounts $distval
      }
      # Assume none are left
      lappend distcounts 0.0
      set bincounts [::math::statistics::histogram $bins $vals]
      .c delete hist
      .c delete dist
      math::statistics::plot-scale .c 0 20 0 [math::statistics::max $bincounts]
      math::statistics::plot-histogram .c $bincounts $bins hist
      math::statistics::plot-histogram .c $distcounts $bins dist
      .c itemconfigure dist -fill {} -outline green
  }

  set alpha 1
  set beta 0.5
  runtest


