# ticketchng

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: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  As of [a9488befa9bdb1ca], the mime package provides tools to access and serialize headers and body parts independently.  With these tools it should be possible to use mime in conjunction with the http package and other packages.


login: lewca43
username: lewca43
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=299572

  This problem presented itself in "bwidget1.5" as distributed
  with ActiveTcl-8.4.1

  - Bryan


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

  See tcllib bug 472718 for new ScrolledWindow 
  implementation (for v1.6).


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

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

      "[528392] Missing commands in nroff format".


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

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

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


  stack used by macro


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

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

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


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

  it would certainly help matters if you would provide the 
  actual command you're invoking instead of saying 
  everything except that.


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

  Also note that it is better to attach (long) scripts, error 
  traces and log information to a report instead of placing 
  them inline. It allows to write concise report containing 
  references to the supplemented information. This is not 
  only easier to read, the mail sent by SF are also smaller 
  and there not so much scrolling involved to get and the 
  interesting information.


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

  George@Orwellian.Org replies: 

  mtr wrote:
  #  it would certainly help matters if you would provide the 
  #  actual command you're invoking instead of saying 
  #  everything except that.

  The actual command is shown. See "Build_SMTP2=".
  That gets eval'd.

  AK wrote:
  # it is better to attach long...

  The SourceForge form I am using has no "attach" function.


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

  Hm. When I hit "submit new" I come to a form which has the
  following fields near the bottom:

  * A checkbox labeled "Check to upload & attach file",
  * followed by an entry to add the filename (to the right is
  a browse button).
  * followed by an entry to describe the file (labeled "File
  description").

  The same fields are available on the page for an existing
  tracker item.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  When I hit "submit", that's it. It says, "Accepted".

  I'll bet that's the difference between having a login
  on SourceForge versus not.

  Gawd, another username/login. Okay, I've registered.
  When I hit submit, I bet I'll see it this time.


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

  Clarification: I meant the link "submit new", not the button
  "submit". For a new item the fields for attaching data will
  be just above the "submit" button.

  Good luck with your account.


login: 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: nobody@129.247.247.239
username: nobody@129.247.247.239
mimetype: text/plain
icomment:
  BWidget 1.8 / T cl 8.5.2 / Windows-XP

  Perhaps the following observation is related to this case:
  Changing the foreground color with [option add ...] does not affect SpinBox Arrow buttons.
  The arrow buttons are displayed black-on-black while the show read-on-blach, when the mouse cursor moves over.
  I'm using the following color settings:
      #
      # Night-Mode colors
      #
      option add *backgroundblackwidgetDefault
      option add *foregroundred4widgetDefault
      option add *insertBackgroundred4widgetDefault

      option add *disabledBackgroundblackwidgetDefault
      option add *disabledForegroundred4widgetDefault

      option add *highlightBackgroundblackwidgetDefault
      option add *highlightColorblackwidgetDefault

      option add *selectColorblackwidgetDefault
      option add *selectBackgroundblackwidgetDefault
      option add *selectForegroundred3widgetDefault

      option add *activeBackgroundblackwidgetDefault
      option add *activeForegroundred3widgetDefault


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Okay, I withdraw my previous comment.
  using the default "interactive" priority solves the problem.

  option add *foreground red4 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  That is true by design. The default value is hard coded to 15x15.

  Is there any need to transfer it to a BWResource ?

  The option declaration is as follows:
      Widget::declare ArrowButton [list \
      [list -typeEnum button 0 [list arrow button]] \
      [list -dirEnum top    0 [list top bottom left right]] \
      [list -widthInt150"%d >= 0"] \
      [list -heightInt150"%d >= 0"] \
      [list -ipadxInt00"%d >= 0"] \
      [list -ipadyInt00"%d >= 0"] \
      [list -cleanInt20"%d >= 0 && %d <= 2"] \
      [list -activeforegroundTkResource""0 button] \
      [list -activebackgroundTkResource""0 button] \
      [list -disabledforeground TkResource""0 button] \
      [list -foregroundTkResource""0 button] \
      [list -backgroundTkResource""0 button] \
      [list -stateTkResource""0 button] \
      [list -troughcolorTkResource""0 scrollbar] \
      [list -arrowbdInt10"%d >= 0 && %d <= 2"] \
      [list -arrowreliefEnumraised0[list raised sunken]] \
      [list -commandString""0] \
      [list -armcommandString""0] \
      [list -disarmcommandString""0] \
      [list -repeatdelayInt00"%d >= 0"] \
      [list -repeatintervalInt00"%d >= 0"] \
      [list -fgSynonym-foreground] \
      [list -bgSynonym-background] \
      ]


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

  Applied the patch.
  Installation of README - IMHO no,
  However it should be part of a released distribution.


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

  Oh, a client not waiting for the response from the server, and 
  the [after idle] is executed after the [eof] was recognized in 
  the fileevent handler (HandleCommand).

  Fixed. Fix committed to head. We now remember the handle 
  of the event and kill it if the connection is closed before the 
  event is executed.


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

  The submitter is Frank Pilhofer
  <520065607613-0001@t-online.de>.

  Patch now enclosed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13561: 483125.diff

  Logged In: YES 
  user_id=75003

  Enclosed an updated patch (minor changes to the proposed 
  docs, fmt changes in the docs, nits in the comments. 
  Functionality unchanged)


login: guardus
username: guardus
mimetype: text/plain
icomment:
  Better workaround:

      proc ::fileutil::GLOBF {current} {
          global tcl_platform
          if {[file type $current] eq {link}} {
              set tgt [fullnormalize $current]
              if {![file readable $tgt]} {
                  return {}
              }
              # At least in Windows XP, a junction can point to same name as a file.
              # This will create a glob error below.
              if {$tcl_platform(platform) eq {windows}} {
                  if {[file isdirectory $current] != [file isdirectory $tgt]} {
                      return {}
                  }
              }
          }
      ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The aes::aes command already accepts a (currently undocumented) option -- (double-dash) which stops option processing and forces interpretation of data, even if starting with a dash. See line 532, about 10 lines after where you patched.

  Is that good enough for your case (plus documenting this option) ?


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

  Decided to accept the change, as it should be pretty much backward compatible.
  Additionally documented the option -- also.
  Version bumped to 1.1. (Visible API change).
  I am lucky that this package does not have C accelerator code requiring the change also.
  That said, getting some C code here for speed would be nice.


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: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Another problem -
  fileutil::stripPath c:/temp/foo/bar c:/temp/foo\\bar
  generates a Tcl error as it executes a file join with no arguments.


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Below is an alternative implementation that I think fixes both above problems. But note the DANGER comment about other platforms. And only tried on 8.6 though I believe should work with 8.4

  ---
  proc ::fileutil::stripPath {prefix path} {
  # [file split] is used to generate a canonical form for both
  # paths, for easy comparison, and also one which is easy to modify
  # using list commands.

  # Convert \ -> /
  set prefix [file join $prefix]
  set jpath [file join $path]
  set prefix_len [string length $prefix]
  if {[string equal -nocase -length $prefix_len $prefix $jpath]} {
      set jpath_len [string length $jpath]
      # Optimize for common case where path is a prefix
      if {$jpath_len > $prefix_len} {
  # DANGER DANGER - is path separator after a join (above)
  # a "/" on ALL platforms ? True on Win, Unix and OS X. Others?
  if {[string index $jpath $prefix_len] eq "/"} {
      return [string range $jpath [incr prefix_len] end]
  }
      }
      if {$jpath_len == $prefix_len} {return "."}
  }
  return $path
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I added a different patch. Basically adding a space between ${prefix} and the '*', to account for the separation of the list elements returned by 'file split'. This should fix the basic issue.

  Not sure if that helps with the ...\\bar case as well.

  I still have to test this on windows. Unix had the same basic issue, there my patch is a fix.

  Note: It is better to attach changes to the report by 'add'ing files. Inlined code as you provide in your comments gets badly formatted.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed. Both issues. Committed to head, with extended testsuite. The \\bar issue was fixed by moving the 'string equal' after the file split, forcing comparison of the canonical list representation of the paths, without an for- and backward slashes. Version bumped to 1.14.1.


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

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


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


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

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


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

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


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

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

  Should I  close this then ?

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


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

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


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

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

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


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

  Further comments: install.bvat does not copy "doctools",
  "fileinput" and "irc" (note that "fileinput" is an empty
  module right now)


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

  Hrm. doctools, irc I don't know ... They are listed in 
  MODULES of Makefile.in and in install.bat themselves.
  fileinput is a still-born module. Use option -P for cvs 
  update/checkout to ensure that it is not in your CVs 
  snapshot. It is also not part of the source distribution, and 
  thus its non-installation is quite understandable.

  The other points about the env variable are taken. ... I will 
  write up something about tcllib installation this weekend. If 
  not, remind me.

  (I want to try a starpack based installer for windows, tarball 
  and starkit for unix).


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

  Ok, I consider this fixed: The .sh/.bat files and the old all-tcl 
  installer are discontinued and removed, and the new all-tcl 
  installer handles all these things.


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

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


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

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

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


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

  This needs some further investigation


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

  The problem is likely

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

  and later

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

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


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


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

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

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

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


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

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

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

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

  Committed to head, version 1.2.5.


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


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

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


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

  Larry, you have tested tcllib using tcl8.4aXX from the CVS. 
  This interpreter had some changes in the error messages 
  thrown for illegal # arguments for procedures.

  The errors in the testsuite should go away if you use a Tcl 
  8.3.3 interpreter.

  Making the testsuite robust against such changes is 
  difficult.


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

  Good idea.  Just to be clear, you need something like:

  proc foobar ......

  ${loggerinstance}::setdeletecallback foobar

  That is then called when that logger has 'delete' called?


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

  Something like it, yes. Preferably bevor the namespace is
  finally deleted..


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

  Try the following patch and let me know if it's what you need.

  Thanks!


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

  I looked at the patch. Two comments:

  1. In most extensions callbacks are executed in the global
  scope via uplevel (think of bind and fileevents)
  2. it would be nicer if delcmd could be a script, as
  otherwise one needed interp alias to curry extra arguments
  (like channel names of the logging channel to close etc.)

  So perhaps change:
      variable delcallback

      logger::walk [namespace current] delete
      catch { $delcallback [namespace current] }
       namespace delete [namespace current]

  to:
              variable delcallback

      logger::walk [namespace current] delete
      catch { uplevel #0 $delcallback [namespace current] }
       namespace delete [namespace current]

  Otherwise it works fine.

  Michael


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

  Ok, I updated it in CVS.  I'll leave the bug open until I
  update the man page and you are happy with the new behavior.


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

  I've added some help for the special commands to the
  Help->About dialog. We should do something more
  comprehensive - but it's unlikely to happen.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the patch.
  The -uniform option was introduced in tcl/tk 8.4, so I would like to make it conditional to this release version.

  I will look for it next week.

  Could you please provide a test script to check the new functionality ?
  (horizontal and vertical)


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Here 's a test script. Note that -homogeneous only works for horizontal layout anyway.

  pack [ButtonBox .bb -homogeneous 1]
  .bb add -text A
  .bb add -text B
  .bb add -text C
  .bb itemconfigure 1 -text BBBBBBBBBBBBBBBBBB


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Please don't consider Tcl/Tk 8.3 anymore! Including the patch conditionally will complicate the code instead of simplifying it. Note that 8.4 was released in 2002...
  Maybe you should ask advice from a TCT member on this, but I think that those who really want to stick with Tcl/Tk 8.3 (or older), can also keep using BWidget 1.8 !
  (In fact,  I even think this holds for Tcl/Tk 8.4, since also 8.5 is already almost 2 years old.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Koen,
  thank you for the patch and comments.

  I included the patch into cvs with a condition on tcl 8.3.

  I have posted a release strategy on "tcllib-dev" and nobody complained.
  I want to stay backward compatible for the 1.9 release at the end of this month.

  There is a 2.0 release planed end august to include additional ttk support.
  Within this release, the code < tcl 8.3 might be removed and will effectively lead to much clearer code.


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

  Instead of just skipping anotehr possibility is to return a list of 
  failed directories, beyond the normal return value of found 
  files.


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

  More brainstorming:

  akudavidw, your take on bug 862491 ?
      * <davidw> looks
  <davidw>hrm...
  <davidw>well... unix just prints out failures
  steveo has left the chat!
  akuOn stderr I guess. Not something a library routine 
  should do IMHO.
  <davidw>it seems like it would be difficult to return 
  a list of failures, which is the first thing that comes to mind
  <davidw>right
  akulist of failures ... also an good idea. I'll note that 
  down in the report.
  kbkPerhaps do what the http package does and return 
  a token that can be used to retrieve the list of failures?
  <davidw>maybe an option? -nocomplain or something
  jenglishDo not ever add a "-nocomplain" option to any part 
  of Tcl ever again.  Thank you 
  <davidw>kbk: mmmm yeah, that starts getting 
  complex when the standard use case is just to fetch a list of 
  files though
  <davidw>jenglish: why's that?
  akuNote: changing the result to list of found files + list 
  of failures is an API change. Requires major version number for 
  fileutil
  <davidw>I'm thinking of the glob one
  dkfPerhaps we should add a -nocomplain option to 
  [error]
  akuEeew
  <davidw>more brainstorming: API change: hand it a 
  proc to deal with 'errors'
  <davidw>dkf: ha ha
  jenglish[unset -nocomplain], [glob -nocomplain], etc. are 
  signs that the original API was flawed.
  <davidw>jenglish: oh, well there's an argument for 
  that
  jenglishIf the exceptional case (variable you wanted to 
  unset isn't there to begin with, no files match glob pattern) is 
  common enough that it warrants adding a "-nocomplain" 
  option, then it warrants fixing the command to not return an 
  error in the first place.
  akuHm, error handler. We already have a filter handler. 
  So it could fit. API change: Use options, instead of just 
  optional arguments.
  kbkjenglish: Yes, they are indeed an indication that the 
  API was flawed. We worry, though, about what stuff might be 
  depending on the flaws.
  kfCeilings
      * kbk : "This house has no flaw!" "What do you walk on?" 
  jenglishHavoc Pennington calls this sort of thing a "please 
  unbreak my program" switch.  (Also: "crackrock")


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

  See also http://sourceforge.net/support/tracker.php?aid=1111153
  for a duplicate entry.

  I have decided to add catch around the cd's, and ignore the
  problematic directories for now. This will close this and
  the other bug.

  I will however also file an RFE asking for an API change
  which allows us to set an error handler to be called for the
  directories we error out on.


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

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


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

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


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

  interestingly enough, if you do a 
  make nroff-doc
  the make runs to completion, showing this error for the irc
  and the multiplexer man pages.

  Weirdly enough, the make nroff-doc was done _before_ the
  install - so install should not have had to try to build
  anything, even though it proceeded to say it was generating
  the docs.


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

  the multiplexer man page error is really this:
  Gen (nroff): ../modules/multiplexer/multiplexer.man
  @--> invalid command name "option"
      while executing
  "::doctools::_format dt {[comment {-*- tcl -*- doctools
  manpage}]
  [comment { $Id: multiplexer.man,v 1.2 2003/05/19 13:40:22
  davidw Exp $ }]
  [manpage_be..."
      ("eval" body line 1)
      invoked from within
  "eval [list ::doctools::_$cmd $name] $args"
      (procedure "::doctools::DoctoolsProc" line 15)
      invoked from within
  "dt format [get_input]"
      (procedure "main" line 15)
      invoked from within
  "main"
      (file "../modules/doctools/mpexpand" line 152)
  child process exited abnormally


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

  Please do not inline such large files in the comment 
  section. Attaching them as files is much better.

  Anyway

  The uuencode errors seem to be a duplicate of #553732
  "uuencode.test warnings: 64 bit"

  The yenc warnings seem to be a duplicate of #548354
  "yenc testsuite trouble".

  For the stooop messages I have no duplicate report.
  I am passing this to jfountain as author of stooop.


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

  I would very much like to fix that.

  Unfortunately, I do not have a fast enough cvs access from home, and from work the firewall prevents 
  cvs.

  Is there somewhere a 8.4a5 snapshot tarball that I could download via http or ftp?

  Thanks.

  Jean-Luc


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 23186: pat.yencode.test

  Logged In: YES 
  user_id=15949

  I am attaching a patch to yencode.test that fixes its test
  suite error.  There were two problems.  First was that
  tcllib test runs from the top level directory, but
  yencode.test expects it is being run from the modules/base64
  directory where its datafile is located.

  The second problem was a wrong variable, which I have fixed
  as well.

  Can someone fix this in the cvs?


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

  Committed: http://core.tcl.tk/tklib/info/a6173e19d4
  Pushed.
  See bug 3458158 for the actual changes chosen.
  Apparently a long-existing fix to the problem which was never committed, just attached to its bug.


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

  Trivial bug in __elementcompare ( ">" should be "<")

  This fixes it:

  # ::struct::prioqueue::__elementcompare 
   #
   # Compare helper with the sort options. 
   #
   #
   
   proc ::struct::prioqueue::__elementcompare {prio newPrio
  sortopt sortdir} {   
      if {[string equal $sortopt "-integer"] || [string equal
  $sortopt "-real"]} {
          set result [expr {$prio < $newPrio}]
      } elseif {[string equal $sortopt "-ascii"]} {
          set result [expr {[string compare $prio $newPrio] < 0}]
      } elseif {[string equal $sortopt "-dictionary"]} {
          # need to use lsort to access -dictionary sorting
          set result [string equal $prio [lindex \
                      [lsort -increasing -dictionary [list
  $prio $newPrio]] 0]] 
      }
      
      return [expr {[string equal $sortdir "-decreasing"] ?
  $result : !$result}] 
   }


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

  MJ, if you are able to use CVS directly, then please
  retrieve the current HEAD of Tcllib and check if this has
  been addressed by the adjust rewrite recently committed by
  Dr. Vogeler.

  You will need revision 1.13 of the file. You may have to
  wait one or two days for it to appear on the anon SF CVS
  server (They sync only once a day AFAIK).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Some questions after reading the code:

  Your rotext seems to disable interactive editing (i.e. anything done through the bindings), and allow non-interactive (programmatic) editing. Is that right ?

  Is this based per-chance on some code on the Tcler's Wiki (http://wiki.tcl.tk) ?
  If yes, that are the page numbers ?

  Note that an alternative way of doing a rotext is wrap around text and disable the 'insert' and 'delete' method, without touching the bindings . This will disable all editing, interactive and programmatic. The latter can then be restored by providing differently named methods for programmatic access.


login: daapp
username: daapp
mimetype: text/plain
icomment:
  > Your rotext seems to disable interactive editing (i.e. anything done
  > through the bindings), and allow non-interactive (programmatic) editing. Is
  > that right ?

  Yes, you are right.

  >
  > Is this based per-chance on some code on the Tcler's Wiki
  > (http://wiki.tcl.tk) ?
  > If yes, that are the page numbers ?

  I write this code myself, but idea is so simple, so may be wiki contains simular code.

  >
  > Note that an alternative way of doing a rotext is wrap around text and
  > disable the 'insert' and 'delete' method, without touching the bindings .
  > This will disable all editing, interactive and programmatic. The latter can
  > then be restored by providing differently named methods for programmatic
  > access.
  >

  I saw such alternative code on the Tcl wiki, but my idea was leave text api as is, just disable interactive editing. Example, in my application I have one text widget for code editing, one other text widget for viewing this code after some preprocessor. Also, I found this widget useful in some other situations.

  P.S: may be it will be good to add my code  to widget::scrolledtext, but this at your discretion.


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

  Sorry, forgot to mention that: HTML. 

  The problem occurs in MS Internet Explorer 4.x and 5.5. The
  black thick line amplifies the effect. 
  Note: in Netscape it looks quite okay!


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

  Please go to the the file doctools/mpformats/fmt.html,
  line 188 (example_begin), remove the string
  "align=center" and check if that causes the
  result to look better.


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

  I have removed the "align=center" from the <p align=center>
  tag in the html-file (was the quickest way), and this does
  the job!

  Thank you


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

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

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

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

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

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

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


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

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

  package require BWidget

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

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

  .w2 configure -state normal


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


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

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


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

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

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

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

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

  .w2 configure -state normal

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


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

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


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

  This bug is a duplicate of
  "[ 810298 ] ::fileutil::tempfile can't find temp dir with env".

  This was fixed in the CVS on Sep 3. Excerpt of changelog:

  (tempfile): Added 'global env', access to 'env' was bad, 
  causing malfunction on windows.


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

  Is this still an issue?  It may have been fixed in the
  latest version.


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: erickb
username: erickb
mimetype: text/plain
icomment:
  File Deleted - 260356: 



  File Added - 260358: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260368: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  I'm attaching a version of the incomplete beta function that is significantly faster (about 10 faster for some values) than the original version I posted.
  File Added: beta.zip


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



  File Added - 260370: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260371: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260396: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  Attaching a new version. Fixes an edge case that can make the routine hang. Also introduces a short-cut in case of integer value for b.
  File Added: beta.zip


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



  File Added - 260397: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260416: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260418: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is a better implementation for the beta distribution. First, I extended the useful range for the pdf. Second, I implemented a much faster algorithm for the incomplete beta function, using a continued fraction from Abramowitz & Stegun. (I used the GNU Scientific Library for inspiration, but ended up using a different continued fraction expansion than they used, so there's no GPL concern here. The speeds are comparable.)
  File Added: beta.zip


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

  Incorporated this. One thing to think about:

  pdf-beta a b 0.0 or 1.0 are edge cases that should give either 0 or infinity (depending on a and b).

  Right now, they give 0 only.


login: arjenmarkus
mimetype: text/plain
icomment:
  Should have been closed a long time ago. Small correction to the code: if x is 0 or 1, the result is either 0 or Inf.


login: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Well, given that the other app in tklib is called 'bitmap-editor', I'd choose something like 'diagram-processor'.


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

  New name: diagram-viewer
  Committed: http://core.tcl.tk/tklib/info/f294879b5c
  Pushed.


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

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

  I suppose, you thought about the text "Base colors" and "User colors".

  They are missing in the language files. For a german translation, you could add this to lang\de.rc:

  ! --- symbolic names of label of SelectColor dialog ----------------------------

  *baseColorsName: Grundfarben
  *userColorsName: Benutzerdefinierte Farben

  I will make the translations of German languages and initialise the rest to english.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Committed to CSV branch bwidget.

  Please feel invited to provide translation for da, es, fr, hu, nl, no, pl for the subchapter head strings "Base colors" and "User colors".


login: prezso
username: prezso
mimetype: text/plain
icomment:
  This is a button text in the font.tcl:
  set but [button $colf.button -command $script -text "Color..."]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Reading helps - file font.tcl, not color.tcl.
  Added new translation key "colorPickerName" and its translations.

  Comitted to CVS sticky tag bwidget


login: aldobu
username: aldobu
mimetype: text/plain
icomment:
  My apologies for my inexperience ...
  The sample pretty-printed dictionary in the above "detail" field, lost all its pretty "tabs" ...

  If you want to see the good "indented" sample tcl-dictionary, open the [patch-request.txt]  attached file. 


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

  I see the same problem -- a clean download of tcllib fails 
  to do anything with './configure' on Cygwin.  This seems to 
  be the usual issue where TEA is supposed to help everyone, 
  but instead fails miserably.  Can't we have a simple .tcl 
  file to install 'tcllib'.  It could easily list the set of 
  all packages included with a simple 'glob' and we'd never 
  have to mess with makefiles and configure scripts again.


login: das
username: das
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=90580

  on a linux box I managed to install from a cvs checkout by 
  doing the following in tcllib/

  ln -s . config

  and adding this mkinstalldirs script to tcllib/

  #! /bin/sh
  # mkinstalldirs --- make directory hierarchy
  # Author: Noah Friedman <friedman@prep.ai.mit.edu>
  # Created: 1993-05-16
  # Public domain

  # $Id: mkinstalldirs,v 1.1.2.1 2001/02/15 18:32:31 dgoddeau 
  Exp $

  errstatus=0

  for file
  do
     set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// 
  /g;s/^#/\//;p'`
     shift

     pathcomp=
     for d
     do
       pathcomp="$pathcomp$d"
       case "$pathcomp" in
         -* ) pathcomp=./$pathcomp ;;
       esac

       if test ! -d "$pathcomp"; then
          echo "mkdir $pathcomp"

          mkdir "$pathcomp" || lasterr=$?

          if test ! -d "$pathcomp"; then
            errstatus=$lasterr
          fi
       fi

       pathcomp="$pathcomp/"
     done
  done

  exit $errstatus

  # mkinstalldirs ends here


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

  I've had the same problems since I started playing with the 
  TclLib CVS about a month ago.
  I used a standard linux box, tho with tcl8.4a3 installed in 
  my shell's root vs. the default install locations.
  It took me a while, but I finally got past this by opening 
  the configure file and removing the /config part of the 
  path call that was tripping it up.  After that mess, it 
  errored on looking for a mkinstalldirs file, which I fixed 
  by digging up a copy and sticking it in the src dir.

  At any rate, maybe it's just me, but there seems to be an 
  enormous lack of simple documentation with tcllib.  I 
  understand of course that it's still under development and 
  docs are not going to be complete for some time, but I am 
  refering to even the most basic of instructions as far as 
  installation and using the mkIndex & mkInstallScripts 
  files.  Obviously every machine is going to be a little 
  different, but it might not be a bad idea to put a hint or 
  two in the readme file next time you have 5-10 minutes 
  available.
  Aside from that, my only gripe is that the struct module 
  makes me painfully aware of my need to learn higher level 
  scripting/programming formats.  But alas, that's one "bug" 
  I KNOW won't ever make it on your "TODO" lists.  ;)


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

  This is something we can fix for "releases".

  But trying to fix this for plain checkouts
  will get us a lot of duplication for the
  stuff in the config directory.

  Alternate solution: A checkout script which
  retrieves all required parts ... 


login: lduperval
username: lduperval
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=40456

  Can this be fixed by putting an entry either in the README or the
  configure.in that says *where* to find the config directory? Ideally, it 
  should be part of the tcllib CVS repository then any other module
  which requires it would require a checkout of tcllib/config.

  I *still* don't know where to find it. Fortunately, someoen made a
  "mistake" in tklib and checked in the config directory. That's where I got a copy.


login: vincentdarley
username: vincentdarley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=32170

  I can't believe this bug still hasn't been fixed.  Why oh 
  why do we want to make things so difficult for new users.

  This seems to be a recurring problem with Tcl.  I install 
  Tcl.  Now I want to install package 'X'.  I download X. But 
  now package X needs something else, 'Y'.  Unfortunately 
  there are no instructions telling me where to get Y, and I 
  wasn't informed when I downloaded X that I would also need 
  to download something else.

  The whole point of Tcl is to be easy and cross-platform and 
  nice, but it gets held back by completely ridiculous things 
  like a 'config' module being missing.


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

  Fix committed to CVS.
  tclpro/config is now duplicated in tcllib/config


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

  Quick glance, the README looks to be outdated a bit (with regard to {expand} at least).
  One thing we can quibble with is the dependency on 'xml' aka TclXML.
  I would be more comfortable with a dependency on tDOM. Not a blocker however.
  Dependency on Tcl 8.5 is ok. Jeff's JSON package is nearly as well.
  The testsuites needs a bit of boilerplate to fit into Tcllib's framework.
  Have it in my sandbox now, will work on the integraton over the next days.
  Right now my first/only change was to convert it from DOS to unix EOL convention.


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

  Added the physical files to Tcllib.
  Modified the testsuites to have Tcllib's boiler plate.
  Added module to the installer.
  Notes...
  - The docs convert without error.
  - The testsuite has errors for me
  -- xsxp : I am guessing that this is due to differences in the xml package loaded (I have TclXML 2.6, and it is using the expat parser I think).
  -- S3loadkeys fails for me. Apparently the code assumes that S3-test.config is in the current working directory. Bad for tests, Tcllib runs them from the toplevel directory, and not the module directory.


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

  Stuart, thanks for reminder on this. We had a discussion on 
  tcllib-devel about this around end of May, beginning of June 
  this year, but it died off when I got distracted. I have now 
  restarted the discussion on tcllib-devel. When it concludes I 
  will post a summary here. For taking part iin the discussion 
  please subscribe to tcllib-devel. The subject of the past and 
  now discussion is 'discrepancy in original intent and current 
  status wrt licensing'.

  A partial thread is at 
  http://sourceforge.net/mailarchive/message.php?
  msg_id=5094650


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

  I have been thinking about doing this myself as I've
  recently done just this for the MD4 implementation. 

  See md4.tcl for how it will look.


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

  This has been comitted now.  Use 'package require md5 2' and
  then you can do
   set tok [md5::MD5Init]
   md5::MD5Update $tok $data
   md5::MD5Update $tok $data
   set hash [md5::MD5Final $tok]


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

  This is the means by which this incorrect
  but widely used usage is being deprecated.
  Follow the "programming instructions"
  and you won't have to worry about it anymore.


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Do you have an example script I could convert into a test case ?
  - TODO - Comparison to internals of read2matrix. Same bug there ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Trying to remember this may have been done as a primitive form of a path jail, i.e. to keep absolute paths within the basedir assigned to the user. I'll have to check this a bit more however.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  > Also: graphops.test seems to depend on setup done
  > by graph.test, cannot run without. Fix.
  This part has been fixed as part of the GSoC 2009 integration.


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

  Logged In: YES 
  user_id=202636

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

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


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

  The wiki page http://mini.net/tcl/693.html
  lists some applications with partial IMAP
  support built into them.

  We can start from these.


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

  Your help is appreciated.

  An incomplete codebase for imap4 was committed today to the
  CVS head of Tcllib here at Sourceforge. The author is
  Salvatore Sanfilippo. Contact information can be found in
  the code. This code is not ready, is has not even a package
  index, nor version number. It is however something which can
  definitely be used for testing, debugging and
  experimentation in general.


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

  I would need a 8.4a5 tarball by http or ftp as I have bad cvs bandwidth.

  Please let me know if that is possible.

  Thanks.

  Jean-Luc


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

  The feature has been added as an option to tostr: -nosci.
  Tests have been added, and passed for both bigfloat 1.2 and 2.0.
  Manual has been updated.


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

  fixed for 1.4.2 (should be in a minor release, but it's too minor 
  to worry ...).


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

  RFC868, while being quite vague in parts, specifies a 32bit
  signed integer as the datum returned to clients. We then
  subtract 2208988800 to convert to unix time. As this is
  supposed to be current time (we are not dealing with history
  here) this should give us something between about 0xc3e8fc4c
  and 0xffffffff which means some time during 7 Feb 2036 we
  have a bit of a problem with this protocol.

  However, I don't know that testing this way is especially
  relevant under 64 it platforms (not having such a machine).
  Do you actually get correct times out of this?


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


  Just ran this test again on
  64-bit Linux/Alpha with the
  ntp that came as part of
  tcllib 1.6.  The test still fails.
  The value of $t during failure
  is -3217070557

  Hope that helps.


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

  We are seeing this too on FreeBSD-amd64. With tcl-8.4.6. Must 
  be a 64-bit vs. signedness thing. The time as returned by 
  time::unixtime in the time-1.3 test is something like 
  -3197788553. 
   
  This is with tcllib-1.6. 


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

  Was the 'still failing' for Tcl 8.4 or 8.5 ?
  For 8.4 I now get

  modules/ntp/time.test
  - time    1.2

  ==== time-1.3 time::unixtime FAILED
  ==== Contents of test case:

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

  ---- Result was:
  1 {error: data format not recognised}
  ---- Result should have been (exact matching):
  0 1
  ==== time-1.3 FAILED

  A bit different.


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

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

  ==== time-1.3 time::unixtime FAILED
  ==== Contents of test case:

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

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


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

  On the machine I am on State(data) aka <token>(data)
  contains 7 bytes, and expected were either 4, or 48+. That
  is the cause for my error message

  Oh, the ClientReadEvent is bad IMHO. The moment it has
  received 4 or more characters it stops receiving. This is
  bad if the 48+ byte is received in chunks, as the receiver
  will stop before it has gotten all data.

  But is that the root cause for my test failure. I have to
  determine how much data is actually sent. For 32 and 64 bit
  systems.


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

  For RFC868 (time::gettime) the data that we send as a client
  is irrelevant as it is only used to get the server to
  respond to us. For TCP connections we don't send anything.
  For SNTP we should always send 48 bytes.

  Added code to the ClientReadEvent to stop reading when we
  have received the amount expected for the protocol in use
  (ie: 4 bytes for RFC868 and 48 for RFC2030). We should not
  really get data in chunks as RFC2030 really only operates
  over UDP and the server response is handled as a single UDP
  packet.

  I wonder why I don't see 64-bit related failures on my sparc64.


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

  I have no idea so far regarding the 64bit failures. I will
  test your changes to see if that got rid of my 'data format
  error'. Maybe I will have a failure, maybe not. I will
  report back when I have done this.


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

  Ok, I found the reason for my data format errors. Yes, I
  still had them despite the change in ClientReadEvent. But I
  knew that I should have gotten 4 characters, instead of the
  actual 7.

  In the fake server the _listening_ socket is fconfigured to
  binary. The actual socket however is not. After I fixed that
  the data format error goes away. So the translation got some
  EOL characters and expanded on them.

  With this gone I have to report that I now see the same test
  failure Don was reporting originally. This I still have to
  look into. However with that change maybe even your sparc64
  is able to repro the failure ;)


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

  Ok, it was a simple masking problem as we had before with
  png and crc. Just restrict the results to 32 bit to get the
  correct information. Committed a fix.


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

  Maybe duplicate existing underscores to quote them ?

  a_b c ==> a__b_c
  a b_c ==> a_b__c


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

  Good thought.  Alternatively, Snit could assign each method an index number when it's defined; the index number
  would then appear in the name.  Then, "a b_c" and "a_b c" would have different numbers.

  But I rather like yours, as it means that you can determine the method name from the proc name, which is useful
  during debugging.


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

  Here are some procs that mangle and demangle hierarchical 
  method names using Andreas' scheme.  I don't *see* any obvious
  corner cases....

  proc method2proc {name} {
      set subs [list _ __ " " _]

      return "Snit_hmethod[string map $subs $name]"
  }

  proc proc2method {name} {
      set subs [list __ _ _ " " Snit_hmethod ""]

      return [string map $subs $name]
  }

  proc rt {name} {
      set proc [method2proc $name]
      list $proc [proc2method $proc]
  }


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

  Me neither. OTOH, I proposed it, I may be too near to the thing.


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

  Hmmm.  "__ _" and "_ __" both expand to "______".  Granted, it's an even obscurer case than "a_b c" and "a b_c", but still troubling.

  What I'd like is a solution that:

  1. Mangles every possible method name distinctly
  2. Supports demangling
  3. Does not place any new constraints on method names.
  4. Can be demangled easily "by eye".

  It's easy to get 2 *or* 3; I'm not sure how easy it easy
  to get both.

  Unless Snit provided a demangler that took the type into
  account.  Then my scheme of providing an index number for
  each method meets all three constraints without playing
  weird text-manipulation games.  I.e., mangle method
  "a b_c" and "a_b c" as

     Snit_hmethod_4_a_b_c
     Snit_hmethod_5_a_b_c

  (assuming that they were the 4th and 5th methods to be
  defined).

  A demangling routine would pick out the index, and look up
  the method name in the Snit variables in the same namespace.
  And a human being can unambiguously demangle such names
  "by eye" if they avoid pathological cases in their code 
  (as is usually the case).


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

  So we need a quoting schema which converts ' ' and the quoting character itself distinctively. Actually, the problem may be that the coding for <space> is a prefix for the coding of <underscore>, leading to ambiguity when decoding, i.e. we cannot say exactly where a code ends/starts, as demonstrated. We need a prefix-code with unique prefixes for anything we code.

  Say, hex-coding: ' ' => %20, and the quoting char is '%', encoded as %25, using the hex-coded ascii values.

  Now:
      a_b c == a_b%20c
      a b_c == a%20b_c
      % %   == %25%20%25
      %% %  == %25%25%20%25
      % %%  == %25%20%25%25

  Now lets try this

      ' ' => '__' 
  and '_' => '_%'

  Now the encoding of <space> is not a prefix of the encoding for underscore

  __ _ => _%_%___%
  _ __ => _%___%_%
  a_b c => a_%b__c
  a b_c => a__b_%c

  Now what happens if we have % in the name ... There should be no ambiguity in the encoding result, as newly introduced % will be prefixed by _, making decoding proper.

  a%b => a%b
  a_%b => a_%%b

  It looks relatively readable as well.


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

  And that looks like it would work; actually, both the "__"/"_%" scheme and the hex coding scheme.  Cool!


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

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

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


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

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

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

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

  set alpha 1
  set beta 0.5
  runtest


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

  Logged In: YES 
  user_id=816411
  Originator: YES

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

  File Added: gamma.zip


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

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


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

  Revision [343787b53ab6a48bf6f0c15032d808d16f7a3862].
  Pushed.
  Version in Fossil now is 0.5.


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

  File (patched version) added:  imap4-0.5.tgz
  Content: ChangeLog, imap4.man, imap4.tcl, pkgIndex.tcl
  Bug repaired.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Gerhard, how does the attached tarball compare against the changes I made?
  See https://core.tcl.tk/tcllib/ci/343787b53a?sbs=0
  Also, contact me by mail so that I can re-create a dev account for you at the fossil repository.


login: exgerhardr
username: exgerhardr
mimetype: text/plain
icomment:
  Andreas, basically all your changes are included in my tgz, but in addition a bug is repaired (which was never reported).
  I've added a diff (imap4-0.51.patch) against your version 0.5 (https://core.tcl.tk/tcllib/ci/343787b53a?sbs=0), so this patch only removes the bug now. 


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

  Thanks Gerhard.
  Reviewing the change it seems that the bug could only trigger for bad data, when trying to report that problem.
  That explains why we have not seen it before, nobody had bad data, it seems.
  And without a test suite at all where error could be forced it was never detected.

  Ok. Accepted.
  Revision [b3a3d726b1].
  Pushed.
  Version bumped to 0.5.1.


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: 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: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  Some of these issues were previously fixed, and issues that apply to the current implementation are fixed in [62cc52d167857f94].  A welcome additional feature would be recognition of character sets and encodings.


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

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


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

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


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 35180: latest.diff

  Logged In: YES 
  user_id=240

  Patch adds the ability to split and join news: url's.

  I'm not really convinced by my JoinNews function - but it
  seems that none of the others throws errors, either.


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

  Nit: [manpage_end] should be on its own line (uri.man).
  Beyond that it looks ok.

  David is now looking at M Rose's nntp_geturlk.tcl I got.


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

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


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

  Followup: rolling combobox.tcl back to r1.25, with no other
  changes, restores the old behaviour.  I don't see any
  obvious changes between r1.25 and r1.26 that look like they
  would cause this difference...


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

  Followup followup: the bug was introduced in revision 1.27,
  not 1.26.
  This looks like the culprit (~line 422, and again ~line
  439):
          ::bind $listb <<ListboxSelect>> \
                  "ComboBox::_select $path \[%W selection
  get]"

  Also: the $listb bindings are broken:
  (ComboBox::_create_popup, end of function):

      ::bind $listb <Return>   [list ComboBox::_select $path]

  Pressing <Key-Return> with the listbox posted now raises an
  error.  (It looks like these bindings were broken prior to
  1.25 (improper [eval] quoting), fixed in 1.26, then broken
  again in r1.27.)


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  This was most definitely introduced with my changes.  I will
  fix and commit shortly.


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  Fixed and committed as well as made the BWidget listbox able
  to handle the same feature (by adding keyboard navigation).


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

  Reopening.

  Damon, it seems that your fix to the combobox keyboard 
  traversal broke the selection in the list via the mouse.

  To reproduce:

  * Start the bwidget demo
  * Click into the font selector combobox at the top left.
  * When using the arrow keys the listbox pops down, an entry 
  can be selected, and return closes the list, the selection 
  appears in the entry.
  * Now use the mouse to click the list open, and click on an 
  item _different_ from the one in the entry. The listbox goes 
  away, that is ok. However the selected item is _not_ shown 
  in the entry. That is incorrect.


login: ethanp
username: ethanp
mimetype: text/plain
icomment:
  Here's the patch for the 0.1.5 version of huddle.tcl:
  242a243,244
  >     } elseif {$len == 1} {
  >         set path [lindex $path 0]

  For some reason I could not attach multiple files, so I only attached the test file.


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

  I do not understand this report.

  What exactly was tried, what happened,
  what was expected to happen ?

  A reference to the mentioned google
  search would be nice. Same for example
  scripts demonstrating the problem.


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

  Noticed the same behaviour. Take two listboxes fill one
  leave one empty. Then do DND from full to empty => kaboom.

  This seems to fix it.. (hope the patch doesn't get garbled
  here)

  diff -u -w -b -B -r1.4 listbox.tcl
  --- listbox.tcl 2001/06/11 23:57:04     1.4
  +++ listbox.tcl 2001/11/01 09:40:14
  @@ -1034,7 +1000,7 @@
       }
       $path.c delete drop
       set data(dnd,scroll) ""
  -    if { [llength $data(dnd,item)] } {
  +       if { [llength $data(dnd,item)] || ![llength
  $data(items)]} {
           if { [set cmd [Widget::getoption $path -dropcmd]]
  != "" } {
               return [uplevel \#0 $cmd [list $path $source
  $data(dnd,item) $op $type $dnddata]]
           }


login: klaren
username: klaren
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=364921

  Hi,

  Here's the clarification (sorry I didn't post this earlier,
  was very busy..)

  Take two Listboxes one filled one empty. Both dropenabled
  etc. attempt to drag items from filled one to empty one 
  -> dropcmd not called.
  Add one item to the empty one repeat procedure
  -> dropcmd is called (expected behaviour)

  Small snippet:

  ---snip---
  package require BWidget

  proc drophandler { args  } {
          puts "Drophandler $args"
  }

  set left [ListBox .l -dropenabled 1 \
          -dragenabled 1 \
          -dropovermode wp \
          -droptypes { LISTBOX_ITEM { move {} } } \
          -dropcmd drophandler ]

  set right [ListBox .r -dropenabled 1 \
          -dragenabled 1 \
          -dropovermode wp \
          -droptypes { LISTBOX_ITEM { move {} } } \
          -dropcmd drophandler ]
  grid $left -row 0 -column 0
  grid $right -row 0 -column 1

  $left insert end test1 -text bla1
  $left insert end test2 -text bla2

  # Notice that now dragging items from left to right the
  drophandler is not
  # called...

  # But if you uncomment the following line it will be called.
  #$right insert end test3 -text bla3
  ---snip---

  Cheers,

  Ric


login: klaren
username: klaren
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=364921

  Hi,

  I noticed a problem with my previous patch. It is now
  possible that dropcmd is called with an empty third argument
  (the 'where' part).

  Here's a correction patch:

  --- listbox.tcl.origTue Feb 26 15:03:46 2002
  +++ listbox.tclTue Feb 26 15:06:58 2002
  @@ -1000,10 +1000,14 @@ proc ListBox::_drop_cmd { path
  source X 
   }
   $path.c delete drop
   set data(dnd,scroll) ""
  -if { [llength $data(dnd,item)] || ![llength $data(items)]}
  {
   if { [set cmd [Widget::getoption $path -dropcmd]] != "" }
  {
  -return [uplevel \#0 $cmd [list $path $source
  $data(dnd,item) $op $type $dnddata]]
  +# set sane default for the where part..
  +set where widget
  +if { [llength $data(dnd,item)] } {
  +# override when we got more accurate data
  +set where $data(dnd,item)
   }
  +return [uplevel \#0 $cmd [list $path $source $where $op
  $type $dnddata]]
   }
   return 0
   }


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: redman
username: redman
mimetype: text/plain
icomment:
  'string equal' is not provided prior to 8.2, I'm going to use this instead:

  [string trimright $line] == "." 

  Now if only the CVS server would let me commit the files, this would be fixed.


login: redman
username: redman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=106931

  Andreas Kupries reminded me that I hadn't checked this in...and so I tried and cvs on sourceforge seems
  to be working again.  Should be fixed now.


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

  References of importance:
  *   http://www.kfs.org/~abw/tpc5/kitesurf/
  *   http://www.wjduquette.com/expand/index.html


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12948: expander.zip

  Logged In: YES 
  user_id=75003

  The attached archive contains the heart of William
  Duquette's [expand] processor as an object.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13079: expand.diff

  Logged In: YES 
  user_id=75003

  Enclosed a patch adding the expander to textutil, as a 
  subpackage. Adds a nroff manpage too.


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

  The expander patch is now committed to tcllib/textutil. 
  This means that the heart of the FR is now fulfilled IMHO.

  Larry ?


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  I found the place where to set the focus. I've attached the new passwddlg.tcl (taken from nightly cvs)


login: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 7806: passwddlg.tcl

  Logged In: YES 
  user_id=98533

  Darn, Opera didn't attach the file the first time, sorry.


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

  This seems to contain a backward incompatible
  change, the removal of "-editable", right ?

  What was the effect of the removed option ?


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  Nope, there was no -editable option for the passwddialog,
  just a -passwdeditable.

  Just on the contrary, the changes re-enable the -editable
  option
  for the login LabelEntry (I don't know why it was removed in
  the first place), and renames this to -logineditable for
  consistency.

  Step by step explanation:

  The login field inherits its options from a standard
  LabelEntry with the line

    Widget::bwinclude PasswdDlg LabelEntry .frame.lablog

  and then removes some of its feature in the following line

    remove [list -command  ***-editable*** -justify -name
  -show -side ... 

  The -editable (which I emphasized by asterisks) happens to
  be among them. So, by removing -editable from the remove
  list, -editable is in fact reinstated.

  Then, by adding the -editable to the 'prefix' line tells
  BWidget to rename the -editable for the login entry to
  -logineditable by prefixing 'login' to -editable.

    prefix [list login -editable -helptext -helpvar -label
  -text \ ... 

  This is to achieve consistency with the existing
  -passwdeditable option.

  So, this change is fully backward compatible.

  The full patch (including the change to focus setting) are
  in the uploaded file. The changes discussed above (in the
  very first lines of the file) are accompanied by a change
  that sets the focus to the login entry or passwd entry
  depending on the respective editable flag (search for 'bach'
  in the code, it's around line 119).

  Salut,
        Bastien


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

  How are these screens configured?  One global, large 
  screen, or as distinctive individual screens?  When testing 
  using Unix and displaying to different distinct displays, 
  everything seems to work OK.  I don't have a multiple 
  monitor Windows system to test on.


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

  Windows allows you to setup multiple screens with the usual
  wizard style of "don't let the user worry about the details"
  so t's pretty hard to know. However, Tk seems to believe
  that it's arranged as one large screen. As my secondary
  screen is on the left of the primary the wm geometry values
  are negative.

  I'm happy to test things out on my system if I've some
  general pointers on what to look at. I'm not familiar with
  the BWidgets code but I can learn. It seems to me that these
  windows are ignoring the sign of the horizontal position.
  The vertical position is correct - but on the wrong monitor.
  They actually appear at 0,v on the primary monitor (where v
  is the vertical position of the combobox editfield.


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

  Well, one would have to figure out if it is Tk or bwidgets 
  that isn't behaving right.  Negative indices seem odd to 
  me, and it should be checked if that is "correct".  If so, 
  we need to make sure windows respect that.


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

  There appear to be two issues here. One is to fix
  BWidget::place to cope with negative geometry values. TThe
  other is a more general problem for Tk to enable a
  programmer to know how many screens of what size and depth
  exist on a windows system. Windows does this somewhat
  differently to X.


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

  I have modified BWidget::place in util.tcl to support
  negative placements when the platform is windows. The
  BWidget ComboBox and dialogs now place correctly for each
  secondary monitor position. I also changed the demo/tree.tcl
  file to permit geometry settings like 100x100+-100+100 which
  windows can produce.
  Added a bit of documentation for BWidget::place too.


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

  Can you attach a small script/patch which show how you 
  modfied DisplayMsg ? I would basically like to know if you 
  check for a specific error message, or just that there was 
  an error message. If you know which error message you get, 
  well, that would be helpful as well. The ftp sources are a 
  bit convoluted and any piece of information you can give me 
  will make it easier to find the place where it should error 
  out instead of returning a false-positive. Especially as I 
  am not the original author of this code.


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

  With the error message in your patch I find 'ftp::Timeout'. The 
  interesting thing about this procedure is that it sets ftp
  (state.control) to "1". This value seems to become the result 
  of the command in execution, and means 'Ok'. Which IMHO 
  is not ok. The error value is '0'.


login: drcampbell
username: drcampbell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=526050

  I've modified 'ftp::Timeout' to set ftp(state.control) to "0" and 
  I'm in the process of testing.  I've not yet managed to recreate 
  the exact scenario to judge the behaviour with this 
  modification, but it does appear to be behaving as one would 
  hope.


login: drcampbell
username: drcampbell
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=526050

  I have an undesirable result from "set ftp(stat.control) 0" 
  in "ftp::Timeout".

  This time we had an unreliable connection that was timing-out 
  on the ftp::Get.  When trying to close the connection with 
  ftp::Close the call to ftp::Timeout from ftp::WaitOrTimeout 
  would not return.  Instead, it just hung.  If I ignored trying to 
  close the connection, the connection hung when trying to 
  connect next.

  The only reliable solution was to return to "set ftp
  (state.control) 1" in ftp::Timeout, then to close the connection 
  with ftp::Close as soon as an error was discovered when 
  having run ftp::Get.


login: hofkensg
username: hofkensg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1625850
  Originator: NO

  I sometimes see the following crash during a ftp::Get :

  can't read "ftp(Start_Time)": no such element in array
      while executing
  "expr {$stop_time - $ftp(Start_Time)}"
      (procedure "ElapsedTime" line 5)
      invoked from within
  "ElapsedTime $s [clock seconds]"
      (procedure "ftp::Get" line 87)


  I think this happens because the proc ftp::WaitOrTimeout (used at the end of ftp::Get) returns 1 on timeout i.s.o. 0. And so ftp::Get tries to calculate the elapsed time in ftp::ElapsedTime, while ftp(Start_Time) is not yet existing, resulting in a crash.
  I have looked at all usage of ftp::WaitOrTimeout, and the return code should be 1 on success, 0 on error. Therefore I suggest to change ftp::Timeout to put ftp(state.control) to 0.

  It solves the crash for me and I think it will solve the related bugs of this thread as well.

  As I am not able to add a patchfile to this comment, I will paste the diff (only a 1 needs to be changed to a 0) :
  --- ftp1.45.tcl2007-03-16 21:25:07.954228800 +0100
  +++ ftp.tcl2007-03-18 19:45:10.498745600 +0100
  @@ -121,7 +121,7 @@
       upvar ::ftp::ftp$s ftp
   
       after cancel $ftp(Wait)
  -    set ftp(state.control) 1
  +    set ftp(state.control) 0
   
       DisplayMsg "" "Timeout of control connection after $ftp(Timeout) sec.!" error
       Command $ftp(Command) timeout


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

  The ldap library is naive in listufy the filterString in line 1352-1353 in ldap.tcl. This can be fixed by parsing the string. The code below should do the trick. Escaping of () in data in the search string remains the responsibility of the library user.

  Example:

  ldap::parseFilter "(&(objectGUID=3fas93*\\(#}\\))(&(cn=*)(on=*)))"
  & objectGUID=3fas93*(#\}) {& cn=* on=*}

  Code: 

  # include procs

  proc ldap::parseFilter {filterString} {
        if {![regexp -- {^\((.*)\)$} $filterString -> filterComp]} {
    error "invalid filter string: syntax is \"( ..... )\""
        }
        return [parseFilterComp $filterComp]
  }

  proc ldap::parseFilterComp {filterComp} {
        set first [string index $filterComp 0]
        set rest [string range $filterComp 1 end]
        switch -- $first {
   & -
           | -
           ! {
       return [linsert [parseFilterList $rest] 0 $first]
           }
   default {
           # we have an item return as a single element list
  return [string map {"\\(" "(" "\\)" ")"} $filterComp]
           }
        }    
  }

  proc ldap::parseFilterList {filterList} {
      puts "pfl: $filterList"
      set filters {}
      if {[string length $filterList] == 0} {
         return {}
      }
      if {[string index $filterList 0]!="("} {
    error "invalid filter component, syntax \"( ....\""
      } else {
          set filter [ldap::getFilterListElement filterList] 
          puts $filter
          return [list [parseFilter ($filter)] {*}[parseFilterList $filterList]]
     }
  }

  proc ldap::getFilterListElement {filterListVar} {
     upvar 1 $filterListVar filterList
     set prev {}
     set depth 0
     set idx 0
     foreach cur [split $filterList ""] {
          switch -- $cur {
              ( { if {$prev ne "\\"} {incr depth} }
              ) { if {$prev ne "\\"} {incr depth -1} }
          }
         incr idx
         set prev $cur
         if {$depth == 0} {
            set item [string range $filterList 1 $idx-2]
            set filterList [string range $filterList $idx end]
    return $item
         }
     }

  }

  # and replace regexps by: set filterString [parseFilter $filterString]


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

  What I posted before will fail on {(GUID=\\)} for example. 


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

  Hm the correct format according to the RFC is \hh where hh are hex digits, so my examples are incorrect.


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

  The following version works correctly on strings I have tested

  # include procs

  proc ldap::parseFilter {filterString} {
        if {![regexp -- {^\((.*)\)$} $filterString -> filterComp]} {
    error "invalid filter string: syntax is \"( ..... )\""
        }
        set result [parseFilterComp $filterComp]
  }

  proc ldap::parseFilterComp {filterComp} {
        set first [string index $filterComp 0]
        set rest [string range $filterComp 1 end]
        switch -- $first {
   & -
           | -
           ! {
       return [linsert [parseFilterList $rest] 0 $first]
           }
   default {
  return [subst -nocommands -novariables [regsub -all {\\(..)} $filterComp {\\u00\1}]]
           }
        }    
  }

  proc ldap::parseFilterList {filterList} {
      puts "pfl: $filterList"
      set filters {}
      if {[string length $filterList] == 0} {
         return {}
      }
      if {[string index $filterList 0]!="("} {
    error "invalid filter component, syntax \"( ....\""
      } else {
          set filter [ldap::getFilterListElement filterList] 
          puts "filter: $filter"
          return [list [parseFilter ($filter)] {*}[parseFilterList $filterList]]
     }
  }

  proc ldap::getFilterListElement {filterListVar} {
     upvar 1 $filterListVar filterList
     set depth 0
     set item {}
     while 1 {
        set char [string index $filterList 0] 
        puts $char
        switch -- $char {
             (   {incr depth}
             )   {incr depth -1}
        }
        append item $char
        puts $item
        set filterList [string range $filterList 1 end]
        if {$depth == 0} {return [string range $item 1 end-1]}
        if {[string length $filterList] == 0} { error "missing ')' brace" }
     }
  }


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

  Note that an even easier (complemetary) solution would be to use Tcl variables for binary data so one could write:

  set data (())))
  set query {(GUID=$data)}


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

  would you please do

      diff -c oldfile newfile

  and attach that, so i can see exactly what you're proposing?

  thanks,

  /mtr


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7493: 0.diff

  Logged In: YES 
  user_id=75003

  Here is the patch. Moving the line causes my emacs to not
  recognize it anymore, pity. So I see it as better to remove
  it completely.


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

  Logged In: YES 
  user_id=75003

  Ok, next version of the patch,removing the faulty line in
  md5.n, report.n and struct/matrix.n too.


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9757: 448634.diff

  Logged In: YES 
  user_id=75003

  Updated the patch to fit into the
  recent changes of the pop3 module.


login: anyeli
username: anyeli
mimetype: text/plain
icomment:
  Example:

  package require math::linearalgebra
  # -> 1.1.3
  namespace import ::math::linearalgebra::*
  set A {{4 5 6} {7 8 9}}
  shape A
  # -> 2 3
  lassign [determineSVD $A] U S V
  shape $U
  # -> 2 3 (should be 2 2)
  shape $S
  # -> 3 (could be 2)
  shape $V
  # -> 3 3 (could be 2 3)


login: msofer
username: msofer
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=148712
  Originator: YES

  All these errors are indeed "inconsequential". I verified that all but one error are due to the new "wrong # args" format for commands taking args. The remaining one (tree-tcl-4.4.17) is due to a slightly changed stack trace.


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

  Notes
  * Lowering the priority as I am not inclined to chase error message differences during an alpha cycle.
  * The testsuite currently has quite a bit of code to handle the wrong#args differences between <= 8.4, and 8.5.
    It might be possible to reuse that framework to handle the 8.6 changes as well.
    Or, of course, to go with the proposal and use tcltest2 and -glob/-regexp matching to check only the most
    relevant pieces of the error message.


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

  eeep. This is a very bad bug, right. The workaround
  as shown in essentially a reversal to "RetrSlow".

  A believe that a better solution would be to check
  the read message if the last character is EOL. If
  it is not, the next [gets] will return the remainder
  of the partially read line, and only after this we
  are allowed to check for a termination line ...

  Right ?


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

  Actually when I said "partial line" I meant a line for 
  which we have part at the beginning from the read, but
  no end yet. And gets should be able to read that
  trailing part.

  May I have an email address so that we can talk more 
  directly ?


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

  It's tcllib-1.2 (I didn't show the end of the func).

  My email address is still George@Orwellian.Org,
  as show on the first line of the initial submission.


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

  My apologies. I missed the email address. My not awake 
  enough when reading this.


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

  I saw your email to me ...

  I am currently working on adding a pop3
  server to tcllib. When that is in place
  I hope to be able to write something
  which can be used to torture a pop3
  client with.


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

  what exactly is this patch fixing?  what is an example of a 
  non-functional vertical progressbar?


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

  the following code simply didn't work: (progressbar wouldn't 
  show for values 0-14):

      set pb [ProgressBar $lssf.pb -maximum 15 -
  variable ::iggui::gLaneSkew${i} -orient vertical -height 2c -
  width .5c]

  with the fix it did work... (logically, as I copied the scheme 
  from the horizontal layout...)


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  I couldn't reproduce this in the CVS version from 21.06.2001. Please specify the version you used.


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

  I used wish 8.4a3 (ActiveTcl 8.3.3.3) and the
  current head of bwidgets (Sep 6, 2001). The
  demo executed correctly.


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

  I was seeing a similar error (see below) when doing 
  an ::ftp::Put with a large binary file members.rogers.com ftp 
  server.   

  "
  can't read "multi_line": no such variable
      while executing
  "string equal $multi_line "-""
      (procedure "::ftp::StateHandler" line 28)
      invoked from within
  "::ftp::StateHandler 4 sock488"
  "

  I added some 'puts' statements in ftp.tcl to see what 'bufline' 
  was and determined that the server was giving me 
  "-450-Error during write to file: Disc quota exceeded"
  (which explained my problem right there!)

  So I altered the two regular expressions (in tcl\lib\tcllib1.5
  \ftp\ftp.tcl) around lines 255 & 265 from
  "(^\[0-9\]+)( |-)?(.*)$"
  to
  "^-?(\[0-9\]+)( |-)?(.*)$"
  to make this be handled slightly better.

  Really, the return value of regexp should also be checked and 
  something clever done if it fails.


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

  If have accepted the change to the pattern. Also added some 
  code around the regexp to handle future match failures better.


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

  The commit was bad. See the report at 
  http://bugs.activestate.com/show_bug.cgi?id=28433
  This has been fixed now.
  Fix confirmed by OS, committed to head.


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

  This is using the 'pipe' command from Tclx. As such it
  doesn't meet the requirements for tcllib that it should not
  rely on compiled extensions.

  If there is a method for substituting the 'pipe' command
  with something else when Tclx is not available then this
  looks like a fine candidate for the control module of tcllib.

  Comments?


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  I found a "fix" of sorts. Not a real fix because
  I'm not prepared to explain how/why it works.

  The change is to switch the channel to -buffering line
  and to change -translation {binary crlf} to -translation binary


  Based on
  # RCS: @(#) $Id: pop3.tcl,v 1.25 2003/04/11 20:07:24 
  andreas_kupries Exp $

  Here is the diff
  -------------------------------------------------

  738 C:/p/t/spam> diff pop3-works-under-windows2000-tk.tcl 
  pop3.tcl
  274c274
  <     fconfigure $chan -buffering line  -translation binary
  ---
  >     fconfigure $chan -buffering none
  282c282
  <       # fconfigure $chan -translation {binary crlf}
  ---
  >       fconfigure $chan -translation {binary crlf}

  Makes my issue go away at least for now.


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

  log::log is usually inactive, i.e. not producing output. Setting 
  it a null proc will accomplish nothing with respect to output. 
  It may make the code a bit faster as there won't be any 
  checks for possible logging anymore.

  Please remove your null log::log and then activate logging 
  (Via [log::lvSupressLE critical 0]). That way we can see what 
  is going inside the library and on the wire to the pop server.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  I tried this again with logging as requested by Andreas. The 
  observed behavior was different this time but still always a 
  failure. My stop-gap fix continues to work without any known 
  errors. 
  The failure is an unknown (no error string) error out of 
  pop3::send, which is reported by pop3::top. This results in 
  only the first message top being retrieved by the code.

  In roytest2.tcl see line 586 for the call to top. Again this all 
  works fine (and I use it continously) for days and weeks on 
  end with the patched version.  Seems pretty clear that fiile 
  events are being mismanaged somehow in the standard code 
  such that running in Windows Tk fails.
  Please see attached log/console: roytest2.output.txt
  and roytest2.tcl

  PS: Regarding log enable/enable I have learned through 
  painful experience to be suspicious of performing "console" 
  (and sometimes even file output) during tk event processing.  
  In the past this has lead to some lockups and crashes. That 
  is why I disabled logging. Unfortunately logging in this case 
  really doesn't seem to reveal much but here you have it 
  anyway in the .txt file.

  Thanks,
  Roy Terry

  - more -

  I tried "standard" versions of pop3.tcl 
  < # RCS: @(#) $Id: pop3.tcl,v 1.25 2003/04/11 20:07:24 
  andreas_kupries Exp $
  ---
  > # RCS: @(#) $Id: pop3.tcl,v 1.21 2002/10/14 19:17:23 
  andreas_kupries Exp $
  and they failed identically. 
  The saved output from tkcon is attached. and I 've added a 
  note at the bottom of it.  I've also attached the program files 
  I used to execute the test with my personal server 
  information deleted.


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

  Irrg.

  For the DropSite formating error, search for <b>baseop</i>
  and replace with <b>baseop</b>.

  For the DragSite formating error, search for <b>copy</i> and
  replace with <b>copy</b>


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

  Follow-up: with Tcl 8.4 this will not be a problem as the
  list elements will be cached, amounting to 256 distinct
  Tcl_Objs only (Donal Fellows checked this).


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

  This is mostly a problem in that we are sucking in the
  entire file in one go and then processing it. I have
  implemented a more moderate buffering read which will reduce
  the memory requirement, Doesn't work for Trf based crc32 though.


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

  How does this sound instead:

         ftp::List handle ?pattern?
                This  command  returns  a  human-readable 
  list  of
                files.  Wildcard  expressions  such  as 
  *.tcl  are
                allowed.   If  _pattern_  refers to a specific
  direc­
                tory, then  the  contents  of  that 
  directory  are
                returned.   If the pattern is not a
  fully-qualified
                path name, the command lists  entries 
  relative  to
                the  current  remote  directory.   If no
  pattern is
                specified,  the  contents  of  the  current 
  remote
                directory is returned.


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

  A few questions, if you don't mind.

  Are the wildcards really the same as arguments to glob ? 
  Might be useful to mention that so the developer knows what
  kinds are permitted.

  What happens if the argument provided doesn't exist?

  If a wildcard is provided, is the result a list? or what? 
  The text says "a human readable list" - but all lists are
  basically human readable.  Is it going to be a valid Tcl
  list of file names, or is it file names, permission symbols,
  size, etc. - aka an ls -l type output?  If it is a simple
  tcl valid list, does it include all files (including . and
  ..)?


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

  > Are the wildcards really the same as arguments to glob ?
  > What happens if the argument provided doesn't exist?
  > If a wildcard is provided, is the result a list?

  This all depends on the FTP server implementation.
  Traditional Unix servers just pass the _pattern_ argument to 'ls -l'; other servers like WU-FTPD and Dan Bernstein's 'publicfile', Mac, Windows, and VMS servers usually use a different listing format.

  > The text says "a human readable list" - but all 
  > lists are basically human readable.

  "Human-readable" was intended to mean "not computer-readable".  Because of the wide variation in server implementations, FTP clients can't reliably parse LIST output.  NLST produces a computer-processable file listing - one filename per line - but even with NLST the interpretation of wildcards is server-dependent.


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

  Fixed in head. Also added code to recognize metakit 
  database, also when attached to a file of a different format.


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

  That's right, there is no -label switch for comboboxes since
  several releases.


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

  It seems mystifying to me; have you checked that it is not
  an [encoding] problem? If the problem really is a 64-bit
  nasty, it might be fixable with a quick [expr {...&0xff}] in
  the right spots to trim all the offending bits...


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

  More data:  I see these test failures in a Tcl 8.3.3
  and in a Tcl 8.4a2 interp.  I do not see them in a
  Tcl 8.4a3 interp.

  More magical corrections from the Unicode update?

  Anyhow, a [package require Tcl 8.4] might eventually
  take care of this.


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

  I don't see this bug anymore with tcl8.4.  It does seem to
  produce different results for the first failed test on x86 

  Test de caract=FFres accentu=FFs : =FF =FF =FF =FF et
  quelques contr=FFle=s =22=5B=7C=5D()=22

  and my linux ppc (unsigned char) machine:

  Test de caract=C3res accentu=C3s : =C3 =C3 =C3 =C3 et
  quelques contr=C3le=s =22=5B=7C=5D()=22


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


  If this package needs Tcl 8.4 to work
  correctly. lets just add [package require Tcl 8.4]
  and declare victory.


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

  Better solution, IMHO: Add known bugs section to mime 
  manpages and add info about this problem.

  Forcing the large set of 32-bitters to switch to 8.4 for a bug 
  hitting only the small 64-bit crowd is not so good IMHO.


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

  Man page is extended now with section about known bugs, 
  and this item was filed.

  Modding down, no other change for the 1.4 release.


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

  Apparently. No test failures for me on a x86_64 platform as
  well. Across Tcl 8.[2345].


login: 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:
  Better quoting would be

  set ProcName [uplevel 2 [list info command $ProcName]]"

  in case proc name contains spaces.


login: droll
username: droll
mimetype: text/plain
icomment:
  Stephen,
  Please check my comment I posted on May 21. For me this issue is already fixed in the newest package that is inside the Fossil repository (revision 0.4.1 from March 25th). Please confirm.
  Thanks,
  Andreas


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  I have downloaded version 0.4.1 from fossil.  It passes the test script and I have put it into my application where it works fine.  I consider the issue closed.


login: aku
mimetype: text/plain
icomment:
  It has been confirmed that TEPAM revision 0.4.1 of the Fossil repository (http://core.tcl.tk/tcllib/dir?ci=07518949a0ede378&name=modules/tepam) fixes already this issue.


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

  Regarding ascii output format ... This format exists, and is
  called 'text'. It might be that this format is not listed,
  like observed for wiki.


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

  Implemented and committed to head. Have _not_ regenerated
  the distributed dtp kit yet. Will be done asap, and placed
  in the Files section of Tcllib (at SF).


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

  I will fix the code to make sure it is looking at the
  caller's context via [uplevel]. And documentation will state
  this to be the case. This has, at least, been my intent from
  the start (just was not aware that this could be a problem).
  The test cases will need to be adjusted to make sure that
  the lookup occurs as intended.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  File Added - 23868: calculus.tar.gz

  Logged In: YES 
  user_id=400048

  I have updated the documentation, the code and the test
  script to get proper behaviour in different namespaces 


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 24162: calc.patch

  Logged In: YES 
  user_id=80530

  I took the tarball of updated files, made a
  few corrections and created the attached
  patch against the HEAD.


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

  Took the chunk patching calculus.test and applied it. 
  Checked for differences between the whole patch and my 
  patch, applied some other changes in Don's patch.

  Committed to head.


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

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

  Agreed, the package does 'creative writing' :(
  Fix is correct as well, and has been applied.
  The package version gas been bumped to 1.3.1.


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

  This seems to be a http package issue. See tcl bug #1818565


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: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Deleted - 80156: 



  File Added - 80254: tkchat-tile.patch

  Logged In: YES 
  user_id=202636

  Updated it again.


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

  Note that the "Really adventurous" method (namepsace import
  -force tile::* at global scope, no other changes required)
  is about 95% successful with the current CVS HEAD.   I've
  been using that for a couple days now.

  A few of the dialog boxes raise errors (tk::ButtonInvoke
  sets '-state active', which isn't supported ATM), but the
  main UI works OK.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  I've hardcoded a fix for my usage.

  In proc ::smtp::initialize_ehlo, after the TLS code, I added:

     if [catch {smtp::talk $token 300 "AUTH PLAIN"} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 334}  {
         puts stderr "Bad response to AUTH PLAIN = '$response(diagnostic)'."
         catch {close $state(sd)}
         return {} 
     }    

     if [catch {smtp::talk $token 300 "A------------
  redacted----------------------hZGE="} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 235}  {
         puts stderr "Bad response to the base64 password = 
  '$response(diagnostic)'."
         catch {close $state(sd)}
         return {}
     }    

  It took a bit of Googling to find out the format, the RFC didn't state it.

  FYI, you'd better give the user a choice of AUTH methods, because
  I first coded this for AUTH LOGIN and it seemed to work - gave a
  success for authorization - but it would fail to work if I was sending
  to a different domain (and it was a forward, not a POP box) that
  was handled by the same POP server. I don't know if this was a
  qmail quirk or not. Switching to AUTH PLAIN worked. If the (eventually)
  fixed smtp.tcl doesn't give a choice and it chooses the first one listed
  by the EHLO output, it would fail for local aliases at my provider.

  I'm suggesting to my provider to drop AUTH LOGIN from the EHLO output.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  Update: regarding giving a choice of AUTH methods, it turns out
  that was a problem on my end, nevermind. It may or may not be
  a useful thing to be able to specify.


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

  The current CVS version of the smtp package has AUTH support
  for DIGEST-MD5, CRAM-MD5, LOGIN and PLAIN. It also supports
  the use of the STARTTLS extension to enable a secure link if
  you have the tls package available. This has been tested
  against sendmail, postfix and Microsoft's SMTP server.


login: petasis
username: petasis
mimetype: text/plain
icomment:
  File Added - 271523: test.tcl

  Logged In: YES 
  user_id=92283
  Originator: YES

  Please run the test.tcl script, to reproduce the problem. The file abox_graph_struct.txt must exist in the same directory.
  File Added: test.tcl


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

  I can confirm a crash in a tcl_panic in tcllibc.so giving the message 'array index out of bounds'. Is that the crash you are talking about?


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

  Yes, this is the error message I have received. I am sorry I have forgotten to add it to the bug report.


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

  Aha. We have 2795 parallel arcs from node x to node y. Total number of nodes 26. The check I used to filter out duplicate result nodes is wrong, causing the filter to try and stuff all arcs into the result, way over the max of 26, so it it bombs in my assert. Yay defensive asserts otherwise this would have not been that easy to find. ... The filtering for -in is bad in the same manner. Fixing both makes the test script run fine. I am guessing that when I copied things from arc filtering to node filtering the adaption was not done right/fully.

  Ok, making test cases for this is easy.


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

  Fixed in head, with testcases. Reviewed the other filters, and they were ok.


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

  Just past line 125 the socket is opened.  Add a  
  fconfigure to allow the correct transmission 
  of binary (yEnc) messges. 
   
      set sock [socket $data(host) $data(port)] 
      fconfigure $sock -encoding binary 
   
  This may not be the best way to fix this ... perhaps 
  it should be an option for ::nntp::nntp 
   


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  The next release of TclTKAquaBI came out, I loaded it,
  and it cause failure of my invocation of the NNTP procs
  to load yEnc posts without corruption.

  I had to edit the NNTP proc source code again.

  Perhaps someday the bugfix will be entered.

  Does Andreas consider this unimportant
  because he personally doesn't use the procs
  to scan Usenet for pictures?


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

  andreas - this looks fine, go ahead and apply it to the 
  cvs tree.

  /mtr


login: cleverly
username: cleverly
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=22080

  This problem still exists in mime 1.3.2 in tcllib 1.3.  It
  looks like the patch was never applied.


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

  Patch applied to cvs head, and committed. My apologies for 
  the delay.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I saw warnings when I generated it myself, but there was no additional information, so, them being
  warnings, I ignored them. The nroff generator apparently gives more info. Thanks, I will repair it.


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

  This issue must have been solved "somehow", as I can not reproduce it with the current documentation.


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

  To help out, soundex is already at
  http://web.uvic.ca/~erempel/tcl/Soundex/Soundex.html


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

  Taken this soundex instead of the soundex from the wiki 
  (http://mini.net/tcl/675). The latter is only slightly different 
  from the Knuth soundex.


login: gwlester
username: gwlester
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=121110

  Fixed and committed to head (ftpd.tcl CVS version 1.24). 
  This will be in the next release of tcllib.

  You may want to check out the current version and verify the
  fix.


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=152318

  oops, actually the typedCmdline does.
  Perhaps make 
  the typed* stuff a separate package


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

  I currently see no real reason to split the package, despite 
  the diffferent requirements.


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

  For some reason SourceForge won't let me attach the
  files to this report. I've put them on
  http://anselm.our-isp.org/tcltk/fileinput.tar.gz
  for the time being. Sorry!


login: lingnau
username: lingnau
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=65359

  Andreas is right. Here is a trimmed-down version that
  uses »continue« in place of »fileinput::nextfile« and
  »break« in place of »fileinput::close«.

  Feel free to put this into the »fileutil« package if
  you think it ought to go there. I think its scope is
  somewhat different from the other commands in that package (which attempt to clone Unix commands) but
  it's no big thing to me. Remember that you will have
  to either change the name of the »foreach« command
  or else change the »namespace export« in fileutil.tcl
  or chaos will ensue.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9758: fileinput.tar.gz

  Logged In: YES 
  user_id=75003

  Retrieved the trimmed-down version from Anselm's website 
  and attached it here.


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

  I had a look at some TclX commands now (for_file, 
  for_recursive_glob, 'scan*'-commands) and come
  to the conclusion that it might be better to take
  these and include them in tcllib. Partially they
  are already written in Tcl. They just need btter 
  names. With them it is possible to write the 
  submitted 'fileinput' in maybe 10 lines of tcl.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9797: 449531.diff.2

  Logged In: YES 
  user_id=75003

  Added patch which adds not 'fileinput' but two lower level 
  commands ripped from TclX which can be used to 
  create 'fileinput'.


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

  In the near future we should also add pure-tcl versions of 
  the scan-commands coming with TclX.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you. Fixed in the CVS head now.
  Bumped version number to 1.9.
  Kept the 8.4-ism you had patched out and made the package require Tcl 8.4 instead.


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

  This doesn't correctly handle the changing of -entrybg after 
  the fact.  Also, is it really correct to tie the listbox 
  background to the entry background?


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  > This doesn't correctly handle the changing of -entrybg 
  after the fact.

  Ermm, I didn't get this one. 

  > Also, is it really correct to tie the listbox background to 
  the entry background?

  I'd plead for the simplicity and behaviour according to the 
  least surprise effect. We could introduce special colors for 
  the listbox colors, but I think that this leads to GUIs that 
  are not conforming to actual style guides.

  I have attached a tar containing three screenshots of an 
  actual application: 

  - combocolors.gif shows the colors given to the entry of a 
  combobox
  - combonopatch.gif shows how the listbox is drawn 
  without the patch. Note that it is in the standard grey color 
  while the entry is still white, and the "select" colors are 
  also not what one would expect. This is also an example of 
  what could happen if we'd introduced special colors for 
  the listbox.
  - combopatch.gif shows the effect of the patch where the 
  combobox behaves like people know it from Windows, KDE 
  etc.


login: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 24426: patch_images.tar

  Logged In: YES 
  user_id=98533

  Forgot to say: screenshots taken from a Sun display, I don't 
  know wether the Windows standard colors for entry and 
  listbox are grey, too.


login: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 24499: combopatch.tar.gz

  Logged In: YES 
  user_id=98533

  Changed the patch: now also reacts to configure changes 
  while the listbox is shown


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

  fixed in 1.4.2.  I didn't add the one-line part1 fix because that 
  breaks common behavior, and the ability to click into another 
  widget, then later paste the selected combobox data there.


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

  Additionally, this command is not correctly returning the tab 
  name that was specified when it was created. For instance, 
  it will return TABNAME:text or TABNAME:top or TABNAME:bot. 
  These seem to be the names of the embedded widgets within 
  the tab.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The cause of the change is, I suspect, a change in textutil:

  * adjust.tcl (::textutil::adjust::undent): Fixed whitespace regexp
  * adjust.man: which lost the tab character. Rewritten to make it
  * pkgIndex.tcl: less likely to happen again. Bumped to 0.7.1.

  That was a last-second change just before releasing 1.14. I fixed a bug which had caused a leading \t to not be removed by the 'undent' command. So, the expected result is wrong and the new actual result is right, the \t gets removed, now.


login: decosterjos
username: decosterjos
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=370749

  I further modified this function so it can created ordered
  (numbered) or unordered (bulleted) lists.

  Also added a new function html::paramRow to generate row but
  which allows to pass parameters for the row and for the
  cells.


login: twylite
username: twylite
mimetype: text/plain
icomment:
  Proposed fixes pushed to branch bug-3601370-td.

  In combination with the Tcl tcltk-man2html fixes it looks like the only remaining issues are invalid copyright statements:

  expander: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) William H. Duquette, http://www.wjduquette.com/expand
  namespacex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) 200? Neil Madden (http://wiki.tcl.tk/12790)
  namespacex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) 200? Various (http://wiki.tcl.tk/1489)
  smtpd: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) Pat Thoyts <patthoyts@users.sourceforge.net>
  soundex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) ????, Algorithm: Donald E. Knuth

  I think it would be a good idea for the doctools checker to include a check that the manpage name does not contain spaces, and to warn if the copyright statement has an inappropriate format.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  New revision on the branch: [6606f5686a].

  Added check to manpage_begin, reject spaces in
  title. Message catalogs extended with new warning 'mptitle' for
  spaces in the manpage title. The french catalog contains the english
  text, and needs a translation.

  For the copyright check I would need a nice regexp, or two.

  Even without that check, and the missing french translation of my change I see no trouble to merge this into the

  tcllib-1-15-rc

  branch and work in that.


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

  Merged into the release branch now. Bumped version to 1.4.14. Closing. Reopen or create new bug for the missing french translation of the new warning message, and/or the regexes to check for issues with copyright lines.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Not wrong number of arguments, but wrong command called; it should have been math::numtheory::isprime. Also, 127 turns out to be too small to test what was meant to be tested.

  Fixed in CVS.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted. Although the option will take the text of the banner, and not be a callback.
  Note that some parts of the banner stay hardwired, namely status code (220), server-address, and the timestamp.


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

  SourceForge wouldn't let me attach the file. Here it is
  (watch out for spaces vs. tabs):

  --- all.tcl     Mon Jan 21 12:55:22 2002
  +++ all.tcl     Mon Jan 28 14:30:41 2002
  @@ -122,4 +122,5 @@
       # import the auto_path from the parent interp, so
  "package require" works
       $c eval {
  +       set ::argv0 [pSet ::argv0]
          set ::tcllibModule [pSet module]
          set auto_path [pSet auto_path]


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

  Duplicate of bug #507242 except for the locale issue.

  Hmm. How do we ensure the C locale from within Tcl during a 
  test?


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

  True regarding duplication.

  However this patch seems to be more general than the patch 
  in #507242. Application stops future problems with argv0 
  immediately.

  What's your opinion ?


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

  This certainly seems like a reasonable patch. It appears
  that none of the current tests depend upon argv0 now but
  this would prevent future problems.

  I don't know about the locale issue though. I've tried
  running the mime tests with LANG set to fr, de and C but it
  has passed every time.

  I've committed this patch as it doesn't cause any new failures.

  Need to confirm the locale issue either on a unix system or
  have someone who natively uses a non-english locale to check
  for any such depencency.


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

  FIY. My LANG is set to uk_UA.KOI8-U. I observed failures 
  on FreeBSD. The FreeBSD port now sets LANG to C prior 
  to running tests (or anything), which provides the 
  work-around. 


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

  Renaming this - we now use 'sak.tcl' to run the test suite -
  but I'm certain the same problems will be present. Need to
  retry with
   tclsh sak.tcl test


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

  Moved this from patches to bugs as the patch has been
  applied and this is now a bug discussion.


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

  Has the discussion closed ? As the patch has been applied,
  can the entry be closed as well ? What issues are open and
  unresolved ?


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

  Just looked at the the index script. It orders the conditions 
  such that then logger is registered, log is too. I.e. the 
  restrictive condition for logger comes after log is registered, 
  after a less restrictive condition.

  That is not beautiful, but does work.
  Priority down.


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

  This bug was assigned to me, but I'm not responsible for adding 
  mclistbox to sourceforge. Someobody else did that and added
  the configure script. I don't even know if that version is
  the same as the 
  version I maintain (though it probably is, as I haven't
  fixed any bugs
  in mclistbox in ages).

  There has been a tiny bit of interest in putting this in
  tklib, but I 
  don't have the time to do it right now. I guess we should ping 
  whomever put the code in tcllib originally.


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

  The uuencode errors should be gone in the latest CVS head 
  of Tcllib (See tcllib bug #700327).

  Bugs in struct::record to Brett Schwarz.
  Crc might be influenced by Trf, or by changes
  made by Pat to enforce 32bit math (Feb 11).

  Refering bug to Brett first.


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

  For some reason, I don't have write access. I remember now
  that's what I had trouble with before (but then I forgot to
  follow up). So, if someone can check on that, or do the
  commit for me, that would be great.

       --brett


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

  The crc bug is annoying. It doesn't occur for me on my intel
  platforms and I don't have another architecture available
  for testing on. I have attached another test file to this
  bug - Larry, could you run this file and append the results
  to this bug.


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

  Brett, I updated yor permission record for tcllib, can you 
  check if you now have write-access ?


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

  I have been trying for the past couple of days, and I still
  do not get write access. Here is the exact error message:

  cvs [server aborted]: "commit" requires write access to the
  repository
  cvs commit: saving log message in /tmp/cvsHy50Gw

  Andreas, can I just send you the updated file until this
  gets resolved?

  Thanks


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

  Sure, no problem at all.

  I just compared your permissions to those of Pat Thoyts who
  most certainly has cvs write access. You have actually more
  rights from what is reported. The only thing I can think of
  right now is that you are somehow in  this cvs_acls script
  they mention ... Checking. No, we don't have such a script.
  ... IMHO we should file a support request for this. ...
  Question: Have you setup your SSH keys ? Can you log in to
  the project server via ssh [*] ? If not then that is the
  problem you have.

  [*] I.e. ssh schwarzkopf@tcllib.sourceforge.net


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 46466: crcbugs.out

  Logged In: YES 
  user_id=15949

  Pat, I have downloaded the new test file, and executed it
  against the latest CVS head Tcllib and tcl 8.4.2 .  I am
  attempting to attach the results with this msg.


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

  Larry, your attachment is present.

  Brett, I got your new testsuite and applied to the CVS head. 
  The tests are now ok, no erors reported. I did some additional 
  changes: (I) Cosmetics, i.e. it now has an -*- tcl -*- header to 
  force emacs into the correct mode, and indentation is now 
  nice. (II) All tests had id 0.1. I have now renumbered them so 
  that all have unique id's. Thanks for your help.

  As we now have only the crc stuff I am reassigning to pat 
  (and will keep an eye on it, just in case Trf has something to 
  do with that).


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

  Cheers Larry,
  Well it's clearly a byte order problem. I notice that you
  are using the Trf based version of crc32 - crc16 doesn't
  defer to Trf so it's using the tcl-only implementation.

  So - at line 124 in crc32.tcl we have:
          if {$::tcl_platform(byteOrder) == "littleEndian"} {
              set conv i
          } else {
              set conv I
          }

  It seems likely that we don't need this. So if you replace
  these lines by
    set conv i
  and redo the tests I think this will clear up the problem.

  Perhaps Trf is already fixing the byte order?


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

  Pat, after I make the change in my copy of crc32.tcl, I see
  this from the test suite:
   
  Module: crc
  modules/crc/cksum.test
  modules/crc/crc16.test
  modules/crc/crc32.test
  modules/crc/crc32bugs.test

  ==== crcbugs-0.0 get platform info - THIS IS SUPPOSED TO
  FAIL FAILED
  ==== Contents of test case:

      array get tcl_platform

  ---- Result was:
  osVersion 5.8 byteOrder bigEndian machine sun4u platform
  unix os SunOS user lwv26 wordSize 4
  ---- Result should have been (exact matching):

  ==== crcbugs-0.0 FAILED

  modules/crc/sum.test


  Question - is the change you propose one for me personally,
  for anyone using Trf, or for anyone using this module?


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

  Until I hear otherwise I think this is a general fix.
  Basically we only have bigEndian or littleEndian and it's
  now successful with both. Seems I didn't have to treat them
  differently after all.

  I've committed this change now, plus the additional tests
  (in case we need them again).


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

  There is already a -linestipple for the tree.  Use -linestipple 
  gray50 for that effect.  Or is this something else?


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

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


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

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


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

  Logged In: YES 
  user_id=75003

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

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

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


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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 278581: base64-tcllib-1-10.patch

  Logged In: YES 
  user_id=75003
  Originator: YES

  Original submitter of patch is gustaf neuman.

  File Added: base64-tcllib-1-10.patch


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

  An example script was submitted, but cannot be attached here, SF rejects it as too large even when max compressed (bzip2).


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

  Notes from further correspondence.
  (1) We can special maxlen 76 with different wrapchar, that case allows full-speed string map
  (2) RFC 2045, RFC 3548 section 2.1 state that MIME uses 76 by default, the 60 char default in tcllib is non-optimal.

  => Change default maxlen to 76 per mime.
  (4) As wrapchar default is \n this change will cause us to hit the zero-time special case (no reflow needed at all) most of the time, and for the remainder we get fast linear-time algorithms with this patch and per (1). No square-time at all.


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

  Negative -maxlen values ...
  Tcl implementation => The wrapchar sequence is added after _every_ regular coding character.
  Trf => The Reflow algorithm (current) will enter an infinite loop (string length can be reduced to at most 0, and will always be > maxlen, causing the loop to not terminate). The generated result will further not contain anything from the regular output, but only wrapchars. The commands extracting the regular result will return the empty string.

  The new reflow algorithm will not loop indefinitely, howver the result will be as bogus as before, only wrapchars, and nothing else.

  Definitely has to be checked. maxlen 0 is already bad. maxlen 1 is the smallest value we can work with.


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

  Ah, maxlen 0 is special, it means: Do not wrap at all. ... The new reflow code should special case that, the loop can be skipped entirely, only 'string map' to remove \n is needed.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 32747: diffs.txt

  Logged In: YES 
  user_id=24077

  what's going on here, i think, is that in one case Trf's
  base64 is being called and on the other system, Tcllib's
  base64 is being called.

  it appears to be that the routines aren't identical in the
  sense that one has a "\n" at the end.  since the copymessage
  routine chunks at 32766 octets, this explains why a "\n"
  shows up in the file.

  try the attached patch and see if it works


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

  I tried this patch and the behaviour is still the same.
      --Jasper


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

  Ok, I tried my hand now. I can confirm that the new
  character comes in after 2^15-1 characters, and at the very
  end. Trf has no influence on this either. The problem
  happens with and without.

  New finding: Base64 is no problem either. Looking at the
  intermediate file model.mm1 I see that quoted-printable was
  chosen.

  Another new finding: When looking at the equivalent position
  in model.mm1 (line 488, .cnv = line 152) I do _not_ see
  additional newlines. In other words, the characters are
  _not_ added during writing. This exonerates copymessage.
  They have to come in during _reading_ and we have to look at
  'getbody' instead.

  Urrk. That looks like a complex state machine ... value,
  canonicalP, encoding ... Ok, we know the latter one. ...
  canonicalP as welll ... This seems to be in this while loop
  going through the input in some chunks ... With and without
  Trf, so mime::qp_decode is most likely not the culprit. I
  will have to look deeper at this loop.


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

  Arg. Got thrown off, the same data is a bit earlier than the
  line in question. It is a 492, and in the output, i.e.
  model.mm1. Ok, it is still copymessage to look at. Stopping
  now, evening, obviously my mental capacity is going down.


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

  I believe I found it. In command 'copymessageaux', near the
  end (lines 1637, and 1639), we have two puts commands. These
  should use 'puts -nonewline'. The reason: We are reading the
  input with read and convert it, so the output of the
  conversion has to be written without newlines. The converter
  is itself responsible for the insertion of newlines where it
  sees fit.

  This asymmetry of reading/writing caused the problem.


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

  Fix committed to cvs head. Added a testcase to the testsuite
  as well. Thanks Jasper, for the report, and your patience.


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

  This happens specifically with Tcl 8.5 (I tried on
  Sun/Solaris with Tcl 8.4.3 - that worked fine. It also
  worked on Windows XP with Tcl 8.4.1 and 8.4.5)

  Something is seriously wrong then! 


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

  dgparjen, miguel: just a guess, but 1272910 is likely a
  tcl_precision sensitivity getting exposed.


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



  It appears that fixing Tcl
  Bug 1275043 has fixed this.
  Please confirm and close.


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

  I can confirm this: tclkit 8.5a4 returns the same result as
  Tcl 8.4. So, indeed: closed


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

  I have added a new option to the smtpd package. 

  smtpd::configure -deliverMIME delivery

  calls the 'delivery' procedure with a MIME token. If the
  -deliverMIME option is unset then the original package
  behaviour is maintained. The user now needs to write
  something like:
    proc delivery {token} { ... }

  I've updated the documentation and added a new example
  'tk_smtpdMIME' to the examples directory.


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

  Hmm. People not involved in the project (or the item) can't
  attach files. That's a sucky piece of interface design,
  SourceForge!  Here's the patch anyway, but with some long
  lines chewed about...

  Index: csvdiff
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/examples/csv/csvdiff,v
  retrieving revision 1.1
  diff -u -r1.1 csvdiff
  --- csvdiff     17 Jan 2002 17:07:25 -0000      1.1
  +++ csvdiff     1 May 2002 19:32:08 -0000
  @@ -28,7 +28,7 @@
       exit -1
   }

  -foreach {inA inB} $argv break
  +foreach {fileA fileB} $argv break


   if {[llength $keySpec] == 0} {
  @@ -61,8 +61,8 @@
   set keySpec $idx


  -set inA [open $inA r]
  -set inB [open $inB r]

   # ----------------------------------------------------
   # Actual processing, uses the following information from the
  @@ -93,36 +93,48 @@

   set order [list]
   array set map {}
  +set linenum 0
   while {![eof $inB]} {
       if {[gets $inB line] < 0} {
          continue
       }
  -
  +    incr linenum
       set data [::csv::split $line $sepChar]
  +
       set key [keyof $data]
  -    set map($key) .
  +    if {[info exist map($key)]} {
  +       puts stderr "warning: $key occurs multiple times in
  $fileB (lines $linenum and $map($key))"
  +    }
  +    set map($key) $linenum
       lappend order $data
   }
   close $inB

  +set linenum 0
   while {![eof $inA]} {
       if {[gets $inA line] < 0} {
          continue
       }
  +    incr linenum
       set data [::csv::split $line $sepChar]

       set key [keyof $data]
       if {[info exists map($key)]} {
  -       unset map($key)
  +       if {$map($key) < 0} {
  +           puts stderr "warning: $key occurs multiple times
  in $fileA (lines $linenum and [expr {-$map($key)}]"
  +       } else {
  +           set map($key) [expr {-$linenum}]
  +       }
          continue
       }

       puts stdout [::csv::join [linsert $data 0 -] $sepChar]
   }
  +close $inA

   foreach data $order {
       set key [keyof $data]
  -    if {[info exists map($key)]} {
  +    if {$map($key) > 0} {
          puts stdout [::csv::join [linsert $data 0 +] $sepChar]
       }
   }


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

  Applied the patch manually. Note that the lines opening the
  files were removed, not changed. This is wrong and was
  corrected. New app sent to Larry for review.


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

  This is handled by the new magic(5) based recognizer, new
  module fumagic aka fileutil::magic. Therefore done.


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

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


login: 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: decosterjos
username: decosterjos
mimetype: text/plain
icomment:
  File Added - 32705: cvsdiff_dynhelp

  Logged In: YES 
  user_id=370749

  Updated the patch to work with the latest BWidget


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

  I will have a look, but no promises. Why is the removal of
  the -h support so important ? Was it replaced with something
  else ? Or just an error message ?


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

  The attached code doesn't do anything if unexpected options
  are encountered. It just shuffles them into the $argv
  variable like it does with non-option arguments. It's much
  easier to use this in proc's than the other parser because
  you don't want procs to print help information if they get
  bad options -- you want the proc to decide what to do,
  usually thats just returning an error message.


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

  Well, the given example will barf if a list element contains
  spaces. The split command in the script will get the wrong
  number of arguments. In other words, this type of
  substitution is an easy way to create subtle errors, and to
  quoting hell when trying to fix such errors.

  For what is wanted here it is much better to place the code
  into a proper procedure. Also note that "Lmap" is an
  internal command name. The proper and documented entry is
  the "::struct list" command. "Lmap" is allowed to change
  from version to version in incompatible ways.

  proc varset {varval} {uplevel 1 set [split $varval =]}
  ::struct::list map {name=vogel ...} varset

  No quoting hell, spaces in the parameter are properly
  handled too.


login: svogel
username: svogel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=250752

  Oooops. Damn spaces :-)
  Yes, you're definitely right.
  Best regards
     Stefan

  ... closing this item ...


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

  Writing this file is code for debugging the testsuite. It is not 
  used by the testsuite itself. Deactived this call and rewrote 
  the 'makeFile'-call and the usage of spawn to allow an 
  arbitrary setting of -tmpdir.


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

  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

  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: quantifier
username: quantifier
mimetype: text/plain
icomment:
  Additionally, if there should protection from overlong forms, the second one could say:
  {%([CDcd][A-Fa-f2-9]|[Dd][01])%([89ABab][A-Fa-f0-9])}


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Quantifier, do you have test cases which demonstrate which characters the original regexes are not covering, and test cases demonstrating which illegal sequences are accepted ?

  If yes, please attach here.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Tried the changes and they pass the existing test suite, so we should not be worse off than we were before. Put them into the repository, on a branch --> "bug-3601995-ncgi". The moment we have test cases it should be ready for merging.


login: quantifier
username: quantifier
mimetype: text/plain
icomment:
  Correct utf-8 characters that are not accepted by original regexps, are any sequences that have continuation byte in range 0x80-0x9F:
  % http::formatQuery ą ;# a with ogonek, \u0105
  %C4%85
  % ncgi::decode %C4%85
  %C4%85
  % http::formatQuery † ;# dagger, \u2020
  %E2%80%A0
  % ncgi::decode %E2%80%A0
  %E2%80%A0
  %http::formatQuery \u2810 ;# a braille pattern
  %E2%A0%90
  %ncgi::decode %E2%A0%90 ;# accepted as two-byte sequence, third byte left hanging
  â %90

  Legal sequence that are erroneously accepted as utf-8 character can be for example two consecutive characters (regexp converts 'ó' and half of 'ę', leaving naked continuation byte):
  % http::formatQuery óę ;# o with acute, e with ogonek, \u00F3\u0119
  %C3%B3%C4%99
  % ncgi::decode %C3%B3%C4%99
  óÄ%99

  Illegal sequence accepted could be three-byte with last byte missing:
  % http::formatQuery Ⱡ
  %E2%B1%A0
  % ncgi::decode %E2%B1 ;# not a two byte sequence, but accepted as one.
  â±


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

  Test cases made, and verified that they fail before the change, and pass after.
  Commit [b6632970f6] @ bug-3601995-ncgi branch.
  Commit [66adc26a8b] @ tcllib-1-15-rc (merged to release work).
  bug-3601995-ncgi branch closed.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13555: registry

  Logged In: YES 
  user_id=75003

  Added a file containing some general
  thoughts about such a registry.


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

  1. with regards to the 'suppress the auto-dectection to
  prevent spawning of infinite number of processes' - isn't
  this "just" a simple lock of some sort - perhaps an open
  socket - that gets released at the appropriate times?

  2. what would be the use of comm send without registry?

  3. Re: communicating via an environment variable - how about
  through the Tcl option database or something?  Environment
  variables are nasty as they require user intervention - this
  mechanism to be transparent needs some other method.

  4. It sure would be useful if the resulting mechanism was be
  able to support, when needed, cross-machine comm send - so
  that multi-user internet apps could be built on the
  structure.


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

  Ad 1. The scenario I saw was the startup of the registry 
  immediately upon loading comm. As the registry needs comm 
  itself comm starts the registry before the registry opened 
  its server socket. So comm when loaded by the registry does 
  not find the registry and thus tries to start it again, ad 
  infinitum. With the current model of starting the registry 
  only when it is accessed for the first time this cannot 
  happen as the registry needs comm, but not the part about 
  accessing the registry itself. Reinhard Max's scenario of 
  the first application automatically acting as the registry 
  itself does not have this problem either.

  Ad 2. Applications which are coded to know about each other 
  by some other means. For example an application launching a 
  child and explicitly telling it on the command line where 
  to find the parent.

  Ad 3. What we need for the scenario is some means of 
  automatically sharing this information. I don't believe 
  that the tcl option database can do this. Or do you mean 
  about setting and querying the option database on an X 
  server ? Do we have code to do this ? About the user 
  intervention bit. As this is about an application and its 
  child processes the environment is passed automatically 
  without user intervention. ... Ok, the per-user setup 
  requires work from the user.

  Ad 4. comm itself automatically support cross-machine send, 
  as the hostname is part of the communication handle, and 
  not only the port to talk to. So we only need a way for 
  cross-machine registries. A proxy would be a more safe way 
  IMHO than directly talking to a remote registry. The proxy 
  can for example to encryption without burdening the local 
  applications with this task.

  Reinhard Max proposed that the first application able to 
  open the listening socket should automatically act as the 
  server. If it goes away for wahtever reason one the other 
  applications opens the socket and starts to act as 
  registry, with the other applications reregistering.

  Another proposal of his is to include a notification 
  mechanism so that applications can get events if other 
  applications (de)register. Using that all applications 
  could maintain a local copy of the registry.


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

  Enclosed a file with more thoughts incorporating the
  discussion below.


login: rmax
username: rmax
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=124643

  I'd like to modify my proposal (one of the applications
  becomes the registry server) a little bit. Instead of acting
  itself as registry, an application should start a separate
  registry process in the background, if it won the election.
  This prevents the registry from being blocked by the hosting
  application and reduces the occurrence of new elections and
  re-registration. The registry process should by default exit
  some time (10-60 sec.) after the last app has de-registered.


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

  Added a manpage in doctools format describing a possible 
  API for a registry configuration package. Not for the 
  registry query functionality itself.


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

  While not really automatic the 'nns' module (nano-nameserver) is step towards this.
  zzzzzz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Thanks for reporting.

  I fixed the problem, at huddle-0.1.5 .
  I committed this at the tcllib repository.

  enjoy! :)


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

  The tcllib/ChangeLog records only high-level changes.

  Changes to the individual modules are recorded in their
  own ChangeLogs, see for example modules/base64/ChangeLog


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

  I've lodged sf bug [ 954346 ] 'tcllib mime / md5 problem
  stops tclhttpd loading' against tclhttpd, because tcllib 1.6
  and the upcoming release of tclhttpd aren't compatible.


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

  package mime requires 'md5 1', i.e. any version of md5 in
  the 1.x series. That is the reason for the opposite order to
  work. Mime loads md5 on its own, and the second require
  simply uses and reports that package. In the regular order
  the mime package cannot satisfy its constraint.

  The problem is that md5 1.x and 2.x series have definite API
  incompatibilities, hence the change in the major version
  number. And having mime require v1 was the easy way to
  satisfy it without bigger changes to the code.

  Now looking into this some more the situation is actually
  even worse. While mime requires md5 v1, smtp on the other
  hand requires md5 v2 (see proc auth_CRAM-MD5).  :(

  I will write up some code which adjusts itself at runtime to
  whatever package it gets when asking for any md5 version,
  i.e. handling both possible APIs.


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

  Applied changes to head which cause mime and smtp to adapt
  at runtime to whatever version of md5 is loaded.


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

  Hm. Atleast the BWidgets module has its own released tar 
  files. mclistbox and widgets could go together as a tklib. 
  tclbench as it is right now is quite developer centric, 
  especially in handling. I would not add it to the tcllib 
  release in this state. It needs a bit of cleanup to make it 
  easier to use. tclapps could have its own release too.


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

  Are you sure that's a good idea?  I thought we were going to 
  leave Tk packages out of tcllib, and put them in some future tklib.  
  The package structure is separate for each of the different 
  directories.

  But now I see that Jeff created tklib as a package parallel to 
  tcllib.  And it would also appear that almost everything in the 
  tcllib cvs is tagged with tcllib-1-1-0.  But would it make sense 
  to have  several different directories all in the same tcllib.tar.gz?  
  Can I package and release that as tcllib-1.1.0, when it will include 
  a lot of new stuff?  How do I number the BWidget library directory 
  name?  Tcllib-1-1-0 is quite a few changes newer than 
  bwidget-1-3-1.

  I was really expecting the maintainers of mclistbox, tclapps, tclbench, 
  and widget to eventually mark a new release with whatever number 
  was appropriate for that package, and I could then release a separate file.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  [14:33]colinaku, reported md5 bug 2906306
  [14:33]colinit's strange because it's happening on *close* not open.
  [14:34]akuFirst, what is underneath the md5 ? Plain Tcl, or one of the accelerators ? (Trf, tcllibc)
  [14:34]colinHow do I find out?
  [14:34]akuinfo loaded tells which shared libs are loaded, that is one indicator
  [14:35]akuThere is also some array in md5 which tells exactly
  [14:35]colin|{/usr/lib/tcl8.6/Mk4tcl/Mk4tcl.so Mk4tcl} {/usr/lib/tdbc1.0b13/libtdbc1.0b13.so Tdbc} {/usr/lib/sqlite3.6.19/libsqlite3.6.19.so Sqlite3}
  [14:35]colinso it would appear to be the plain tcl version
  [14:35]colinshame, I want the accelerated one 
  [14:35]akuOk, no accels loaded, should be the plain Tcl => IIRC this uses a channel internall to process a file => Pat Thoyts has written this code.
  [14:36]colinleave that for another day.
  [14:36]colinok.  patthoyts, seems to be a strange bug in md5.  It would appear that the file has been closed already.
  [14:36]akuI will paste this part of the chat into the bug and then reassign
  [14:36]colinwhen it comes to be closed under ::md5::md5 -file
  [14:36]colinok.


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

  Logged In: YES 
  user_id=241231

  Updated comment for the second patch


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

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

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

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

  Known caveats:

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


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

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

  -- Luke Myers


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

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


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

  Hmm, it says:

  File Delete: ArtifactFile: Permission Denied

  well, that's okay since they are identical AFAIK


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

  Logged In: YES 
  user_id=241231

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


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

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


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

  dup'ed by 817351 - working on making this handle namespace 
  correctly


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

  --- ftp.tcl     1 May 2003 00:17:40 -0000       1.32
  +++ ftp.tcl     3 Jul 2003 08:39:50 -0000
  @@ -1653,6 +1653,7 @@
   # stop_time -          ending time
   
   proc ::ftp::ElapsedTime {s stop_time} {
  +    variable VERBOSE
       upvar ::ftp::ftp$s ftp
   
       set elapsed [expr {$stop_time - $ftp(Start_Time)}]
  @@ -1660,7 +1661,9 @@
           set elapsed 1
       }
       set persec [expr {$ftp(Total) / $elapsed}]
  -    DisplayMsg $s "$ftp(Total) bytes sent in $elapsed
  seconds ($persec Bytes/s)"
  +    if { $VERBOSE } {
  +        DisplayMsg $s "$ftp(Total) bytes sent in $elapsed
  seconds ($persec Bytes/s)"
  +    }
       return
   }


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

  Checking ... not so for Linux. Seems to be windows 
  specific. "file type" code ... That is something we got from 
  Phil Ehrens.


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

  Relevant code section:

      } elseif { $binary && [string match "\x1f\x8b*" $test] } {
          lappend type compressed gzip

      } elseif { $binary && [string match "\x89PNG*" $test] } {
          lappend type graphic png

  It seems that the string match'es fail. (The 'binary' is 
  correctely detected, so the flag $binary is set).

  Reproduced on my Windows 2000 system. IOW, deeper 
  digging can be done locally. ... dump hex of pattern and data


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

  The testsuite creates a number of files which are then tested. 
  The creation step already fails. The bytes 0x89 and 0x8b are 
  both stored as 0x3f. The command used is 'tcltest::makeFile'.

  Now writing the files explicitly, using -encoding binary.
  Now the testsuite works. This is a problem in whatever tcltest 
  you are using. ... Mine is 2.2.2. We have to talk to Don Porter 
  now.


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

  Added a fix to the testsuite which circumvents binary data 
  issues in 'makeFile'.


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

  I do not get these errors when I tested the CVS head on Windows today. I have some other failures for install and relative path computations, but not for file type. Closing.


login: 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: 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: lvirden
username: lvirden
mimetype: text/plain
icomment:
  After a bit more play, I figured out it should be
  [list_begin enum]

  and with that additional change, it appears the doc then builds.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Uurps. These were all my bugs, and easily fixed. Would have been better had I validated the syntax before committing :( Fixes are now in the head.


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

  Implemented and committed to head. All predefined formatters
  have been updated to generate something hopefully sensible.
  TMML is an exception, it has to ignore the label, the output
  DTD has no place where I can store this information.


login: robert_hicks
username: robert_hicks
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1528214

  I would like this added as well plus a way to add a
  javascript script. I have coded the following and tested
  using TclHttpd server.

  # ::html::css
  #Create the text/css tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the css file to include the filename
  and path
  #
  # Results:
  #HTML for the  section

  proc ::html::css {href} {
      variable page
      ::set html ""
      append html "<link rel=\"stylesheet\" type=\"text/css\"
  href=\"[quoteFormValue $href]\">\n"
      lappend page(css) $html
      return ""
  }

  # ::html::js
  #   Create the text/javascript tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the javascript file to include the
  filename and path
  #
  # Results:
  #HTML for the  section

  proc ::html::js {href} {
      variable page
      ::set html ""
      append html "<script language=\"javascript\"
  type=\"text/javascript\" src=\"[quoteFormValue
  $href]\"></script>\n"
      lappend page(js) $html
      return ""
  }

  I then changed the ::html::head section to include these
  like meta tags:

  # ::html::head
  #
  #Generate the <head> section.  There are a number of
  #optional calls you make *before* this to inject
  #meta tags - see everything between here and the bodyTag proc.
  #
  # Arguments:
  #titleThe page title
  #
  # Results:
  #HTML for the <head> section

  proc ::html::head {title} {
      variable page
      ::set html "[openTag html][openTag head]\n"
      append html "\t[title $title]"
      ::if {[info exists page(author)]} {
  append html "\t$page(author)"
      }
      ::if {[info exists page(meta)]} {
  ::foreach line $page(meta) {
      append html "\t$line\n"
  }
      }
      ::if {[info exists page(css)]} {
      ::foreach style $page(css) {
          append html "\t$style\n"
      }
      }
      ::if {[info exists page(js)]} {
      ::foreach script $page(js) {
          append html "\t$script\n"
      }
      }
      append html "[closeTag]\n"
  }


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Addendum: For the html::js (and I am not sure how) it needs to know whether it 
  is in the <head> section or the <body> section I am thinking. You don't embed 
  a .css file in the body of the html but you *can* with .js files.


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

  Committed the implementations, after reworking them to be a
  bit simpler. I am bailing out on the javascript-in-body issue.


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

  What platform and version of Tcl was this? 

  I tested it on Windows XP with ActiveTcl 8.5.0 - and the math module passed all tests.

  matchNumbers actually tests up to seven decimals (0.1e-6), but it still does not fail.

  The difference between the numbers is:
  0.707107 - 0.70710678118654757 = 0.22e-6 

  So the failure seems justified - hm, why doesn't it fail on Windows XP then?

  I will need to investigate further, but I am still interested in your platform


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

  Ok, the original system it failed in this manner was a plain Linux/Intel (32bit) box.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Actually no. On the boxes where I have tested tcllib I haven't seen any errors in math except for the beta-distribution thing which I reported a few days ago and you have already corrected. I guess that we can close this as 'out of date' or 'invalid'.


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

  This has to do with Widget::focusPrev moving the focus from 
  the .w2.e true entry to .w2 frame, which has -takefocus 
  acceptable on it since it is a megawidget.  That must be 
  improved to check that we aren't just moving from a bwidget 
  child to its megawidget parent container.


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

  If you set
  .w2 configure -takefocus ""
  (instead of the default '-takefocus 1'), then Tk / BWidget's
  standard traversal algorithm does the right thing:
  [tk_focusNext .w1] is .w2.e (instead of .w2), and
  [tk_focusPrev .w2.e] is .w1 (instead of .w2).

  Perhaps the right fix is to make '-takefocus ""' the default
  on the frame widget.  Does that sound reasonable?


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

  No. First it does not work for me. And second, if I use
     $myCombobox configure -takefocus 0
  I would expect, that the widget doesn't take the focus any
  more during keyboard traversal.


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

  Hm.  In what way does it not work?

  Anyway, taking a closer look, this isn't the right solution
  after all.  Widget::focusNext / Widget::focusPrev would work
  correctly if the outer frame had '-takefocus 0' and the
  inner entry widget had '-takefocus 1', but due to some
  BWidget voodoo that I don't quite understand the -takefocus
  option on both widgets are tied together.  Plus -- as Rolf
  mentioned -- from the user's point of view it's preferable
  to set -takefocus on the ComboBox itself, not on one of its
  components.  (BTW, I think [ComboBox .cb -takefocus 0] will
  do the right thing, as will [ComboBox .cb -takefocus ""],
  but [ComboBox .cb -takefocus 1] causes a problem with
  Widget::focusPrev).

  Next possible solution: modify Widget::focusPrev to never
  transfer focus from a descendant to an ancestor.  I think
  this would be the right thing in almost all circumstances 
  -- typically only "leaf" widgets take keyboard focus,
  container widgets do not -- is there a counterexample?

  And an observation: the focus traversal code is deeply
  confusing :-(


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

  Attached patch changes Widget::focusPrev to skip over
  non-leaf widgets.  This makes shift-tab work correctly for
  ComboBoxes and other megawidgets.
  This needs to be reviewed very carefully: I'm not convinced
  that the patched version always terminates (I don't *think*
  an infinite loop is possible, but can't prove it).


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

  I've added a hack that checks that we don't step into the
  immediate parent if it is a proc (like a BWidget megawidget
  would be).

  Joe's idea that -takefocus should optionally allow a widget
  name that you should redirect to sounds very good as a
  better future solution, but would require more careful
  rewriting of -takefocus handling.


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

  This is fixed in the head - leaving it open based on
  alternate idea from Joe.


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

  Would this really be useful?  ISTM that factorial is mostly useful as an example demonstrating how to implement recursively-defined functions; it's rarely used in real applications.  (E.g., it's a really bad idea to explicitly calculate n! in combinatorics problems due to overflow issues; usually the gamma function is a better choice.)


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

  Patches attached.  Anyone have any comments before I write the man page?


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

  This changes the public interface, hence an update of the 
  major version number for this package and tcllib is in 
  order. Marking this item with

  MAJOR_VERSION_UPDATE

  to find it and others of thre same kind in a search.


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

  Integrated most of the patch attached here:
  * tempfile is in fileutil
  * import_file added
  The change in the order of env/urlStub decls (command 
  urlStub) was ignored. I see no reason for that.

  The change for binary was _not_ integrated yet.
  The testsuite currently does not trigger anything because the 
  command reads from stdin, which is empty when the 
  testsuite is run.

  When you are talking about form data, is that just the values 
  for the various form elements, or could that be uploaded file 
  data, in fill binary glory, ie. not xxx-encoded ?


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

  Integrated chunk for binary data too. This completes the 
  integration.


login: stevecassidy
username: stevecassidy
mimetype: text/plain
icomment:
  File Added - 53284: ncgi-import-fix.patch

  Logged In: YES 
  user_id=105411

  ncgi::import_file had a bit of stray code in the previous
  patch. This patch fixes that and adds some tests to
  ncgi.test for import_file. It also changes the way that
  binary file upload is tested so that it doesn't use external
  files (multipart data is generated by procedures rather than
  being read from formdata). This makes it robust against
  newline munging of the formdata.txt file. 


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:
  The patch contains a number of other changes beyond what is described in this bug.
  Can you explain ? (Changes to binary scan, file handling, int/float differences).


login: a_kovalenko
username: a_kovalenko
mimetype: text/plain
icomment:
  Umm, sorry, almost all of them are safely ignored, many are redundant and many depends on newer Tcl than ico.tcl itself. Sorry again, I should have prepared a cleaner patch. 

  Float->int replacement doesn't alter semantics for icon dimensions that are multiples of 8. It was added during a vain attempt to track down the size calculation problem. The same can be said about [open] flags ("b" is redundant as soon as -encoding and -translation are set in a later code) and [binary scan] ("u" flag is more convenient than format %u and &0xFFFF, but, alas, it increases required Tcl version).

  The only thing making sense, of those other changes, is commenting out a check for [file exists] in writeIcon: ICO backend is able to create files from scratch, so the file doesn't _have_ to exist (I should report it as a separate bug and attach a separate patch, of course). 

  As of other changes, please drop them out.


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

  Ok. Done. Version is 1.0.5. See my attachment for the final patch I committed to CVS head. Please check that it works for you. If not, reopen the bug.


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

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


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


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

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

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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report.
  I have tried your script on windows and on Linux.
  In both cases, Item_27 is visible. The items are on two lines for me, making the display quite cluttering and results in a slightly clipped item 27 at the bottom.

  Maybee, my default fonts or sizes are different than yours.

  My thoughts about the update solution:
  tk requires "update idletasks" to evaluate required screen sizes, so scrollwindow may not work without an update. So an update might be required by design.

  update is always a tradeoff, because other tasks (like after or file events) may occur withoin the update. For this reason, it is often helpful, if updates are coded manualy (and not within BWidget library), so you are able to control them.

  In consequence, your update solution may be a good solution.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed, but acceptable by design.
  Please use "update idletasks" to update widget sizes before using the see subcommand.


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

  stooop also defines [::_proc] ( the renamed [::proc] ).

  Packages in tcllib are not supposed to create commands
  outside their namespaces.


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

  As English is not my native language, please define what you mean by Yuck!

  Would you also please include a short script which demonstrates the bug?

  Thanks.

  Jean-Luc


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

  The README for tcllib says:
  ...
  There are some base requirements that a module must meet
  before it
  will be added to tcllib:

  * the module must be a proper Tcl package
  * the module must use a namespace for its commands and
  variables
  * the name of the package must be the same as the name of
  the
    namespace
  ...

  This means that the package "stooop" should only
  define commands that match ::stooop::* .

  However, the package stooop is currently
  defining a command named ::proc and a command
  named ::_proc , against the tcllib policy.

  "Yuck!" means "I'm tasting something bad."


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

  Stooop needs to overload the proc command in order to make such code transparent:
  proc memberProcedure {this ..} {...
  virtual proc virtualProcedure {this ..} {...
  ...

  Now Consider the following package:

  package provide n 1.0
  namespace eval n {
      proc proc {name arguments args} {
          uplevel 1 ::_proc [list $name $arguments] $args
      }
      namespace export proc
  }

  and the following user code:

  package require n
  rename proc _proc
  namespace import n::*
  proc p {} {}

  Note that in order to use the n package, the user needs to rename proc to the predefined _proc (otherwise n::proc 
  will fail), and in the correct order, before importing n exported procedures.

  Do you have anything better, simpler than the above (and backward compatible)?

  Jean-Luc


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

  Here's the right approach:

  package provide stooop $version
  namespace eval stooop {
      namespace export proc
      ::proc proc {name arguments args} {
  # Use fully qualified name to get Tcl's
  # built-in [proc].
  uplevel 1 ::proc [list $name $arguments] $args
      }
  }

  And the user code:

  namespace eval user {
      package require stooop
      namespace import ::stooop::proc
      proc p {} {}
  }

  It is true that you will not be able to
  [namespace import] the command [::stooop::proc]
  into the global namespace.  Depending on your
  perspective, you can attribute this to:

  1) stooop's choice of re-using a command name
     already used by Tcl.
  2) Tcl's choice to put built-in commands directly
     in the global namespace rather than ::tcl.

  Code in the global namespace would be able to use
  the fully qualified [::stooop::proc] to distinguish
  from [::proc].

  I'm not a stooop user or developer, so it's not clear
  to me what you accomplish by overwriting [::proc] and
  whether the alternative above is compatible.  However,
  what you are currently doing is incompatible with tcllib.


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

  dgp wrote:

  > It is true that you will not be able to [namespace import] the command [::stooop::proc] into the global 
  namespace.  Depending on your perspective, you can attribute this to:
    1) stooop's choice of re-using a command name already used by Tcl.
    2) Tcl's choice to put built-in commands directly in the global namespace rather than ::tcl.
  > Code in the global namespace would be able to use the fully qualified [::stooop::proc] to distinguish                 
  from [::proc].

  Thank you for the explanations. I understand well now.

  > I'm not a stooop user or developer, so it's not clear to me what you accomplish by overwriting [::proc]
  That is required in order, for example, to detect member procedures (this as first argument), constructors 
  (procedure name = class name), setup internal namespace variables, ...

  > and whether the alternative above is compatible.
  I am sure that it is incompatible with most if not all of the stooop code out there.

  > However, what you are currently doing is incompatible with tcllib.
  Well, I could internally use a stooop::proc instead of a proc, but the rename I am afraid cannot be removed.

  So, do you want to remove stooop from tcllib? Should I (can I) do it myself?

  Jean-Luc


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

  Before you do anything that severe, I'll assign this over 
  to Andreas for another opinion.  Maybe he will see a way
  to resolve the problem.

  The real problem is that stooop apparently needs to "wrap"
  a command provided by another package (Tcl, in this case)
  and the facilities for doing this with [rename] between
  namespaces do not work well.  We were just chatting about
  this a few days ago.

  I think offering an alternative for import is more modular than
  direct wrapping, but perhaps you've got a case where direct
  wrapping is required.  I haven't looked into the stooop code
  in detail.

  To help clarify matters, what are the compatibility requirements
  for stooop users?  You suggeted that there must continue to
  be a command named [::_proc], but why?  Isn't that an "internal"
  detail of stooop, on which users do not have to rely?


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

  Don Porter (dgp) wrote:

  >To help clarify matters, what are the compatibility
  requirements for stooop users?  You suggeted that there must
  continue to be a command named [::_proc], but why?  Isn't
  that an "internal" detail of stooop, on which users do not
  have to rely?

  The requirements are simply that for example the following
  code keeps working: 

  class c { 
    proc c {this p} { 
      set ($this,m) $p 
    } 
    proc s {} {} 
  } 
  proc c::~c {this} {} 
  virtual proc c::v {this} {} 
  delete [new c 0] 

  That requires, according to our previous postings, renaming
  the proc command (I rename it to ::_proc, but it could be
  any name, so users do not need to know that particular name)
  so that the stooop::proc can take over and detect whether
  the procedure name is "c" (the constructor, in the "c"
  namespace), "~c" (the destructor), that a procedure first
  argument is "this" (normal member procedure) or not "this"
  (static member procedure). Also a "variable {}" instruction
  is added at the beginning of a member procedure so that it
  is possible to store member data in the empty named
  namespace array using the "($this,...)" conventionnal
  construct. 
  Note that virtual member procedures are implemented using
  "stooop::virtual" which takes the "proc" string as first
  argument for visual compatibility with the other member
  fonctions. 
  I hope that this summary helps you. 
  I will be happy to provide further details if needed. 
    
  Thank you for your help.

  Jean-Luc


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

  To complement myself:
  > That requires, according to our previous postings, renaming the proc command (I rename it to ::_proc, but it 
  could be any name, so users do not need to know that particular name) so that the stooop::proc can take over...

  The thing is that proc needs to be overriden and the only way to do that so that it works in the global namespace is 
  to rename ::proc (at least that is the only way I know...).
  Also, stooop::proc obviously needs to invoke the original ::proc for procedures that do not belong to a stooop class.

  Jean-Luc


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

  Here is a log from discussion on the Tcler's chat about this.

  akuIf I understand JF explanations correctly at least 
  _proc can be moved into the stooop namespace.
  dgpYes, fortunately, Tcl's [:roc] does not care what 
  namespace it lives in.
  aku... Off the top of my head I see now way around 
  the redefinition of :roc to accomplish what he wants, i.e. use 
  of a unadorned [proc] inside of stoop classes to define 
  member commands.
  dgpInside of stooop classes ought to be no problem, 
  right?  It's outside of them in the global namespace where we 
  have trouble.
  akuI retract my opinion about the renamed proc aka 
  _proc a bit. stooop does not know if the command it renames 
  is the builtin proc, or a different command/procedure from 
  another package. If the latter is the case it might require to be 
  in the global namespace
  dgpExcept for the global namespace, this is why 
  importing by the user is better than wrapping by the provider.
  akuI don't know how the [class] command is 
  implemented. I deduce from his explanations that [class] sets 
  up some namespace and or internal variables and then 
  executes the class definition script in the global namespace. 
  So [proc] in the class definition is executed in :: . If the class 
  def script were executed inside of ::stooop it would use the 
  internal stooop:roc
  akuBack to _proc - Because of what I said the safest 
  way for stooop might indeed be to leave _proc in ::, as bad as 
  that is
  dgpOK, maybe, but that could be changed.  My point 
  is that stooop is in control at that point and could take care of 
  the problem.
  akuI guess so. We have to source-dive.
  akuAnotrher approach could be to use a different 
  interp, specially setup to interp class definitions. That way 
  only the class commands are possible. It also disables fun 
  stuff like loops to generate a series of similar member 
  commands


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

  more chat:

  akuOh, wait. His example explictly has member commands
  defined outside of the class definition script.
  akuFor that he definitely either has to overload [proc], or
  use a qualified name [stoop:roc]. The latter breaks existing
  code
  dgpOr his users have to code in their own namespace.
  dgpBut, yes, it's a compatibility problem with his current
  user base.
  dgpI could imagine having an additional command in stooop
  that set up the new [::proc] definition.
  dgpThen for compatibility, current stooop users would have
  to call that command to support their direct call to
  [::proc].
  dgpBut stooop itself would not force that definition on
  everyone.
  akuThat might be best. Have the user make explicit that
  they use this feature. Still requires them to change their
  code, but not as much as replaced all proc's with
  stooop::proc's


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

  Thanks for enlightnening discussions, which led me to the following solution proposal:

  namespace eval stooop {
      namespace export class new delete
      variable proc ::proc
      ::proc proc {name arguments args} {
          variable proc
          # invoke the real Tcl proc command:
          uplevel 1 $proc [list $name $arguments] $args
          # unless it is a class procedure:
          # ... stooop specifc code here ...
      }
      ::proc import {args} {
          variable proc
          set proc stooopRenamedProc
          namespace export proc
          uplevel 1 "
              catch {rename proc $proc}
              foreach pattern $args {
                  namespace import stooop::\$pattern
              }
              catch {namespace import stooop::proc}
          "
      }
      ::proc class {args} {}
      ::proc new {classOrId args} {}
      ::proc delete {args} {}
  }

  Then the user can optionally use:
    stooop::import *
  instead of the former:
    namespace import stooop::*

  Please let me know what you think.

  Thanks, Jean-Luc


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

  Thoughts:

  1. I wish this had been ready to be in tcllib-1.3

  2. The idea seems good.

  3. The implementation needs some corrections. ([uplevel] between
  namespaces is always tricky.)

  The export of stooop::proc appears to be conditional on calling
  [stooop::import].  Is that right?  Is [stooop::proc] part of
  the package
  interface or not?

  Our previous analysis indicated that import into the global
  namespace
  needed special treatment.  I don't think I see that here.

  Perhaps a sketch of the documentation that would accompany this
  change will help me follow it.


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

  >1. I wish this had been ready to be in tcllib-1.3
  I wish you had told me as I was not aware 1.3 was about to be released.

  >3. The implementation needs some corrections. ([uplevel] between namespaces is always tricky.)
  Please suggest some corrections. Unfortunately, I cannot do any better than what I proposed...

  > The export of stooop::proc appears to be conditional on calling [stooop::import].  Is that right?  Is [stooop::proc] 
  part of the package interface or not?

  Since the Tcl proc command was renamed, a new proc is needed to replace it. That is what the "namespace 
  export proc" and the "namespace import stooop::proc" do in stooop::import{}. Maybe there is a better way to 
  achieve that effect?

  >Our previous analysis indicated that import into the global namespace needed special treatment.  I don't think I 
  see that here.

  I do not understant the above. What I understood is that the renaming of proc should not be forced on the user, and 
  that is what is achieved by the optional use of stooop::import. If the user chooses not to invoke stooop::import, 
  then he has to explicitely use stooop::proc in his code.

  >Perhaps a sketch of the documentation that would accompany this change will help me follow it.

  I was waiting for the change to be accepted before writing the documentation, but it is quite simple:

  - if the user does not use stooop::import, then he has to use the qualified stooop procedures, as in:

  stooop::class c {
    stooop::proc c {this} {}
    stooop::proc ~c {this} {}
  }
  stooop::proc c::p {this m} {}
  stooop::delete [stooop::new c]

  If he uses:
    stooop::import *
  then the compatibility with the existing stooop code is maintained (the sample code in one of my previous 
  messages should work in that case).

  Jean-Luc


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

  hmmm... there I go assuming context again... sorry.

  A subscription to the tcllib-devel@lists.sf.net mailing list
  would
  be a good idea.

  I intend to propose revisions, that's why I needed documentation
  of intent.  Your comments indicate that you do not want or plan
  for stooop users to use [namespace import] at all.  I think
  that's
  a mistake.  [namespace import] is the general mechanism, and
  people are going to use it.  Offering [stooop::import] in
  addition
  is a good idea if it helps work around the global [::proc]
  problem,
  but [namespace import] should still work, and the docs should be
  clear about what commands are exported as stooop's public
  interface.

  Since we can't make tcllib-1.3 anyway, and other Tcl 8.4-related
  things have quicker deadlines right now, I'll get back to
  this later.


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

  if you like, you can assign this report to me, then I'll be sure
  not to forget about it.


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

  > A subscription to the tcllib-devel@lists.sf.net mailing list would be a good idea.
  I would like it, but unfortunately, I have a very bad Internet connection from home and I am not allowed to do that at 
  work...

  > I intend to propose revisions, that's why I needed documentation of intent.  Your comments indicate that you do 
  not want or plan for stooop users to use [namespace import] at all.

  That is incorrect. As a matter of fact, that is how the current version of stooop works. The problem that I overlooked 
  is that it also renames proc no matter what, so that the stooop's proc always kicks in, which is needed for stooop 
  to work at all, as we have seen in the previous postings.

  > I think that's a mistake.  [namespace import] is the general mechanism, and people are going to use it.  Offering 
  [stooop::import] in addition is a good idea if it helps work around the global [::proc] problem, but [namespace 
  import] should still work, and the docs should be clear about what commands are exported as stooop's 
  public interface.

  At this time, I believe that it is clear what stooop exports (both in the documentation examples and in the source 
  file with the "namespace export" line).
  Now for the proc problem (assuming the stooop code is rewritten based on my latest proposal a couple of 
  messages ago):
  - if the user does not want to import anything, then he has to use stooop::proc and other fully qualified stooop 
  commands, in which case stooop is a well behaved package
  - the user either has existing stooop code, or wants to use class, new, delete, ... and other commands directly. As 
  we have seen in the previous postings, that requires the modified stooop proc to replace the Tcl proc command at 
  the global level. That is why I proposed the "stooop::import *" instruction which does just that and that can be used 
  as a replacement for the currently used "namespace import stooop::*". This way, the only thing that all the current 
  stooop users have to do is to modify a single line of code to use the new and improved stooop.

  I think that it is a good compromise, provided that change and the effects are properly documented, which is the 
  first thing I would do once we reach an agreement.

  Jean-Luc


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

  will look this over again, to see if
  I want to propose any changes
  for tcllib 1.4 release.


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

  Logged In: YES 
  user_id=75003

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

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

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


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

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


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

  Logged In: YES 
  user_id=75003

  New patch containing a corrected version of tabify.


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

  Changes to control modules described have been committed.

  Still need fixes to the master Makefile.in.


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

  Note:  Be sure that 'make dist' as well as 'make install'
  copies over any tclIndex files.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12840: control.diff

  Logged In: YES 
  user_id=75003

  Enclosed a patch for the master Makefile(.in).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12841: control.diff.2

  Logged In: YES 
  user_id=75003

  New patch. Fixes an additional heretofore unknown error in
  the "make dist" target I found when exercising my changes.
  Please review.


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

  The patch still needs changes to mkInstallScripts.tcl
  so that the Unix installer script installs tclIndex
  files.


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

  OK, the latest patch works.

  All of the error messages:

  cp: base64/tclIndex: No such file or directory
  ....
  cp: sha1/tclIndex: No such file or directory

  when running install.sh are less than ideal.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12947: control.diff.4

  Logged In: YES 
  user_id=75003

  New patch, checking existence of tclIndex before copying.


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

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

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

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

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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks for the patch.
  I applied it now, with changes.

  See branch "apn-dtplite-kwlinks", revision http://core.tcl.tk/tcllib/info/44d847703f
  Please test if my changes still work for you.

  (1) Fixed your bug-fix in "HeaderSetup", added comments explaining the conditions.
  (2) Disabled "IdxWrite" when no keywords were found.
       This means that not only the navbar links are gone, but the essentially empty "index.html" as well.
  (3) Consolidated the check into a proc [HaveKeywords].
  (4) Got rid of the superfluous "kwpresent" flag. We need only "kwid".


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Thanks, will try it out. 

  The reason for the extraneous kwpresent was that with -merge option I was finding kwid always empty. Perhaps I was looking in the wrong spot.

  Will try your changes and let you know.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Just tried it out, with and without keywords, with and without -merge option, and seems to work as desired in all cases. Thanks!


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

  Committed: http://core.tcl.tk/tcllib/info/7593991c41 (Updates to collateral, bumped version to 1.1).
  Merged: http://core.tcl.tk/tcllib/info/c148f532c8
  Pushed.
  Completed.


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

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


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

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

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


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

  My today work. Problem is in parsepart funkcjon in fragment:
  if {$pos > $last} {
  #error "termination string missing in $state(content)"
  set line "--$boundary--"


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

  this was fixed in response to a previous report. remove the
  "#" in the front of "#error".


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Good call.  I implemented a fix a little differently from the patch, by moving the floating point conversion (and octal leading zero issue) into units::reduce.


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

  I will compare this to the MD5 speedup patch done by Donal
  Fellows before committing.


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

  Logged In: YES 
  user_id=75003

  Attached the final patch, speeding up base64 and md5, adding
  sha1.


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  The contents of the history pane stops after the second line of these lines taken from the history in the main tkchat window:

  [03:23]<[Azbo]>test
  [03:24]<}>test2
  [03:24]<µ>3


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

  This is caused by the text widget cloning code using [append] to build strings when it should be using lists.
  Fixed in version 1.424


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

  I dealt with the userinfo bugs yesterday as part of another
  bug notice. The uri::geturl ftp support I have raised as a
  feature request.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Added guard commands to the read2 and split2 procedures, extended testsuite. Bumped to version 0.7.1. Committed to head.


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

  The only case in which this arises is if you use "delegate option * 
  to...".  So what if the full syntax was "delegate option * to 
  <widget> except <list_of_exceptions>"?


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

  Yes, that would work ...

  delegation option * to hull except {
      -text -textvariable
  }

  This looks ok.


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

  The "except" clause should be made to work for "delegate method 
  *" as well.


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

  This was implemented in Snit 0.9, as the "except" clause on the 
  delegate command.


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

  The commands were modeled after the core builtins [file
  split] / [file join], which exhibit the same sort of asymmetry.


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

  Just tried

  % t move root 2 node0
  % t children root
  node1 node0 node2
  % t index node0
  1

  It seems to be an off-by-one problem in 'move'.


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

  Ok, I looked deeper and it is truly more complicated than that.
  I accept the patch. It seems to be the best solution. I will add 
  some clarifications to the manpage as well.


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

  Logged In: YES 
  user_id=240

  The attached patch seems to make the problem go away, but I
  don't know if it really fixes it.  It still passes all the
  tests.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 44163: 14167

  Logged In: YES 
  user_id=240

  Uploading a spam file that triggers the bug.


login: kripke
username: kripke
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=282725

  this properly errors out if you remove the # comment from
  the line
  error "termination string missing ..." (in mime 1.3.2)


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

  yes, we should remove the '#' character to get the original
  behavior.


login: zoro2
username: zoro2
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=191529

  Here's my patch to mime.tcl, which seems to handle things
  better than davidw's patch:

  --- mime.tcl.orig       2003-06-11 22:22:18.000000000 +0200
  +++ mime.tcl    2003-06-11 22:24:56.000000000 +0200
  @@ -682,10 +682,11 @@

       set inP 0
       set moreP 1
  +    set retries 0
       while {$moreP} {
           if {$fileP} {
               if {$pos > $last} {
  -        #        error "termination string missing in
  $state(content)"
  +                if {[incr retries]>50} {error "termination
  string missing in $state(content)"}
                    set line "--$boundary--"
               } else {
                 if {[set x [gets $state(fd) line]] < 0} {


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

  Reopening because the fix in CVS doesn't seem optimal.

  Further thoughts:

  1) Mime should try and parse even bad data, by default, on the
     principal of "be liberal with what you accept".

  2) Maybe we should have an option to tell it to be strict,
  in which
     case it errors out on bad data?


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

  well, the "official practice" when encountering bad mime
  data is to wrap the thing inside an application/octet-stream
  and declare victory. experience shows that any other
  recovery strategy just doesn't work.

  perhaps the thing to do here is to keep the "error ..." and
  put a wrapper around the proc that creates an
  application/octet-stream bodypart.

  /mtr


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

  I committed two of the spammy email messages as well as two
  new test cases to CVS, in order to have something to test
  this problem against.


login: eee
username: eee
mimetype: text/plain
icomment:
  This bug is open more than ten years. It need sto be revalidated and either fixed or wontfixed. Poking the priority to fraw attention.


login: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  The reported issue was previously fixed and is not reproducible in the current version.  Any related issues or feature requests can be handled in future tickets.


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

  Do you have a piece of example code we can use to 
  reproduce the problem ? This is important for writing a test 
  case too.

  Question: When using the same type of sent code via Tk's 
  [send], does the same problem occur ? In other words, if 
  you 'send' your problematic code to a different application 
  using Tk instead of comm, do you have the same problem 
  there too ?


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

  Please review the "EVAL SEMANTICS" section of the doc to 
  ensure that it isn't working as expected.


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

  Okay, I will look into this - it should be easy to fix :)


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

  I have corrected the man page. Thanks for noticing this


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

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

  The whole eval isn't necessary in Tk 8.3+.  Corrected for post-
  1.6.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted, and committed to CVS head.

  However, please provide me with a small script demonstrating the before/after behaviour, so that I can extend the testsuite

  Side note: In the future, please provide patches in the 'uified diff' format (generated by 'diff -u'). This easier to read, and easier to apply.


login: cnassau
username: cnassau
mimetype: text/plain
icomment:
  Here is a test that verifies that the base64-encoded "message/*" is parsed. Previously that code raised an error.

  test mime-12.0 {Bug 3483716} {
      set token [mime::initialize -string {Content-Type: message/delivery-status; name="deliverystatus.txt"
  Content-Disposition: attachment; filename="deliverystatus.txt"; size=138;
  creation-date="Thu, 02 Feb 2012 13:50:05 GMT";
  modification-date="Thu, 02 Feb 2012 13:50:05 GMT"
  Content-Description: deliverystatus.txt
  Content-Transfer-Encoding: base64

  T3JpZ2luYWwtUmVjaXBpZW50OiA8L2ZheD1ibHViYkBndW1taS5ib290PgpBY3Rpb246IGZhaWxl
  ZApEaWFnbm9zdGljLUNvZGU6IHNtdHA7IDU1MCAjNS4xLjAgQWRkcmVzcyByZWplY3RlZC4KUmVt
  b3RlLU1UQTogNTMuMjQuMjgyLjE1MA==
  }]
      set parts [mime::getproperty $token parts]
      mime::getheader [lindex $parts end] Remote-MTA
  } 53.24.282.150

  Side note: I believe the test message does not follow the respective RFC 1894 because that states that 7bit encoding "MUST" be used for message/delivery-status types. The base64-encoded version that broke the previous package was observed in the wild, however, so it seems wise to accept it noentheless.  


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you very much. The test has been added now. Confirmed that with your patch disabled an error is thrown, and with it the data is properly decoded.

  I agree regarding the reasoning about accepting the base64 encoded form.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 28560: 582668.diff

  Logged In: YES 
  user_id=75003

  The attached patch should fix the problem. Please check.


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
  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:
  Accepted with some changes:
  - New version is 0.8, as this is a new feature, i.e. backward compatible API extension. Not a bugfix.
  - The argument is called 'delMode' instead of 'forceDel'. The original name evokes a boolean flag, which the argument is not.
  - The default value is "auto" for the existing behaviour.
  - The new behaviour is activated for delMode == "always".
  - Added a test case.
  - Because of the use of "ne" ("eq" respectively) version 0.8 requires Tcl 8.4 instead of 8.3.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12276: 466746_ftp.diff

  Logged In: YES 
  user_id=75003

  The fix is correct. Enclosed a patch containing the official
  change.


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

  That fix looked trivial enough to me, so I committed it on
  my own. Also added a test for it to the testsuite.


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

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

  % .pg configure
  unknown option -geometry

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


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

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


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

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


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

  Logged In: YES 
  user_id=75003

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


login: 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: rkeene
username: rkeene
mimetype: text/plain
icomment:
  --- ftpd1.2.5/ftpd.tcl(revision 2177)
  +++ ftpd1.2.5/ftpd.tcl(working copy)
  @@ -1301,7 +1301,7 @@
   
       set path [file join $data(cwd) $filename]
   
  -    if {[file exists $path]} {
  +    if {[::ftpd::Fs exists $path]} {
           if {[::ftpd::hasCallback authFileCmd]} {
               set cmd $::ftpd::cfg(authFileCmd)
               lappend cmd $data(user) $path write
  @@ -1358,7 +1358,7 @@
       }
   
   
  -    if {![catch {::ftpd::Fs rename $data(renameFrom) $path} msg]} {
  +    if {![catch {::ftpd::Fs rename $data(renameFrom) $path $sock} msg]} {
           unset data(renameFrom)
       } else {
           unset data(renameFrom)


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

  Fixed in CVS head. Plus a fix in ftpd::fsFile::fs (branch 'rename', sock -> outchan).


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

  The files left behind are intentational. The represent internal 
  targets which are done. Without that we get a full regen of all 
  documentation whenever we say "make install".


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

  yes.

  I'm still not happy about the *-doc files, but that's not so
  much a bug as a design disagreement.


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

  Ad 2, question: What is expected as result of the search ? 
  The row,col index of the cell containing the value ? The 
  indices for all cells in the search range containing the 
  value, ...


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

  Re: searching of matrix

  I would envision the mechanism to work like this.

  If given no restrains, a matrix would return a list of
  paired coordinates matching the (regular expression) term
  being sought.

  If given a range of columns and/or rows restraining the search,
  the list returned would be those items only in the
  restricted area.

  In other words, the default would be the entire matrix, but
  one could if they so desired, restrict the search to some subset of the matrix.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13734: 481022.diff

  Logged In: YES 
  user_id=75003

  Enclosed an implementation of the FR.


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

  which version of Tcl and what platform? I am using ASTcl
  8.4.7 on windows, and it works. I think the ability to do a
  package require struct::record was just added, so you might
  have an old tcllib (even if it does say 1.6)


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

  My apologies. As I find out that working fulltime with tcl
  over the day leaves not much energy for doing it in the
  evening. This has created not very nice backlog of things to
  do.

  Patch committed. Note that the part of the patch dealing
  with "mime.tcl" is already covered by the patch for SF
  #477088, committed Nov 1, 2001.


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: stwo
username: stwo
mimetype: text/plain
icomment:
  That information should be in the documentation, I guess.
  I found them like this:
  $ cd /dir/which/contains/tklib
  $ ./sak.tcl doc validate


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Which commands are these ?
  I replaced [nl] today with [para].

  Revision [6205def19e5f9a12f1ea7e896d578ae695efb6aa].
  Pushed.

  If these were all we can close as fixed.
  This is also in the newly made tklib-0-6-rc branch.


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

  Committed a fix. Note that the section SYNOPSIS
  in the manpage (ftpd.n) lists which tcl version
  is required. This was not changed, just updated
  to 8.3.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Looks good. I will have to find a place to put those AD specific things and write some tests for it. If nothing else i might put it at least inside the examples section.


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

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


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

  Can you please post a script that shows the visual 
  irregularity?  I believe that 'canvas xview moveto 0' or the like 
  might be more appropriate.


login: lewca43
username: lewca43
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=299572

  Here's an example that illustrates the problem. Note that even 
  though I am using Tclkit, the problem exists in plain old wish.

  > tclkit
  % parray tcl_platform
  tcl_platform(byteOrder) = bigEndian
  tcl_platform(machine)   = sun4u
  tcl_platform(os)        = SunOS
  tcl_platform(osVersion) = 5.8
  tcl_platform(platform)  = unix
  tcl_platform(user)      = bschofie
  tcl_platform(wordSize)  = 4
  % puts $tcl_patchLevel
  8.4.1
  % package require Tk
  8.4
  % file tail [pwd]
  bwidget
  % lappend auto_path .
  /homes/bschofie/bin/tclkit/lib/tcl8.4 /homes/bschofie/bin/tclkit/l
  ib /homes/bschofie/bin/tclkit/lib/tk8.4 .
  % package require BWidget
  1.5
  % option add *Canvas.borderWidth 0
  % pack [NoteBook .n] -fill both -expand 1 -padx 2 -pady 2
  % .n insert end a ; .n raise a
  a

  The  result will be that the left side of the notebook is not 
  visible because it is drawn at -1 x coordinate. The canvas 
  could adjust its viewport or just make sure it doesn't draw 
  anything past 0. I found this problem because I use the option 
  data base heavily in all my applications to maintain a 
  consistent (more profesional, imo) look. Since I 
  think "*BorderWidth: 1" produces a nice look I use that, but 
  some widgets do better with no borderwidth by default. For 
  example, frame and canvas widgets usaully need 0 
  borderwidth to prevent small offsets in alignment. Thus the 
  need for *Canvas.borderWidth: 0 option.

  By the way, there are also minor rendering issues when the 
  borderwidth is somthing larger than 2... but who want that? :-)

  - Bryan Schofield


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

  This appears to be an error lower in the notebook code.  The 
  notebook already restricts the -bd option to [1..2], but 
  obviously not at creation time.


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

  Corrected by always checking that bd is 1 when used, 
  although it might be better to force that in the configure.


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

  Have tried the same for an existing directory ?
  I do not believe that you can GET a directory at
  all. Only LIST its contents.


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

  sorry for confused message, i am trying to get file and save
  it into different directory. It happend that that direcoty
  didn't exists at that time.

  ftp::Get $fd FILEtoGET FILEnameInWrongDirectory


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

  Ah. It seems that the ftp package does not generate
  the directory for ta target file and then gets
  confused if that directory does not exist. I classify
  that as a true bug. Not enough argument checking on
  the target file. Some other operations could have the
  same problem.

  IMHO the correct solution is to have the package 
  check "FILEnameInWrongDirectory" and immediately
  throw an error if the drectory does not exist. I
  believe that this is safer than simply creating
  the directory.


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

  But why does it go into infinite loop by calling itself so
  many times, if it couldn't create that file, open command
  failed and the system could throw exception.
  I suspect something with state machine also, because i use
  this package inside AOLServer, and with infinite loop it
  crashes the whole server which is not reliable solution i am
  building. Would be greate if ftp package would control stack
  level or loop count.
  Thank you


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 16080: 503471.diff

  Logged In: YES 
  user_id=75003

  Enclosed a patch which should solve the problem.


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

  The given result is correct. The canonical CSV
  representation of the lists [list f1 {} f2]
  and [list f1 {"} f2] are

  csv::join [list f1 {} f2]   =>  f1,,f2
  csv::join [list f1 {"} f2]  =>  f1,"""",f2

  Notice the following sentences in the CSV manpage:

  1) If a value contains itself the separator ",",
     then it (the value) is put between "".

  2) If a value contains ", it is replaced by "".

  There is no ',' between the two "" in {f1,"",f2},
  so rule (1) did not apply, but (2) does. This
  causes the given result.


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  I noticed that the latest CVS version already contains a protection against the <Leave> event being called twice, namely by catching {unset _saved}. But I think it is better to use an appropriate condition instead of simply using [catch].


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, Koen !
  Patch integrated. Please check current cvs (this evening) if everything works for you.


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

  This is definitely not the right place.
  Please go to SF project
      http://sourceforge.net/projects/tktable
  and (re)submit the bug there.


login: arjenmarkus
mimetype: text/plain
icomment:
  This ticket should have been closed long ago - the code has been incorporated in the statistics package.


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

  Jeff, this seems to be your domain. IIRC you have some code 
  called 'widget'.


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

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

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

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

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


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

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


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

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

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

  What is your opinion about this ?

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


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


  Re formatting block level elements...


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


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

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


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


  It probably should look something more like this:



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

    <h2>Table of Contents</h2>

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

  </div>



  The synopsis should probably look something more like this:


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

    <h2>Synopsis</h2>

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

  </div>



  The commands sections currently looks like this:



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

  <dl>

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

  <dt>...



  It should look something more like this:



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

    <h2>Commands</h2>

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

    </dl>
  </div>



  The pattern is:

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

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

  - The id is the section name

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



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

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

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


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



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


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


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

  Some clarifications ...

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

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

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


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

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

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

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

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


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

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


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

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

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

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


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

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

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


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

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


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

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


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

  Interface change, this means an update of the major version 
  number for this module and tcllib as a whole. The following 
  is a keyword I will use to mark such items so that I can 
  find them later through a search.

  MAJOR_VERSION_UPDATE


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

  I have made up my mind about this and decided to reject the 
  proposed change. I want to keep the interface to the [find] 
  command simple, consistent and without hidden surprises 
  (KIS). Changing the "formatting" of the paths in the result 
  based upon a special value for the "basedir"ectory does not 
  meet my criteria for KIS.

  I believe that is the responsibility of [find] to return a 
  list of found paths in a uniform format and that of the 
  calling application to decide if a non-standard formatting 
  is required and to apply it.

  Given that I make the counter proposal to write a command 
  [stripPwd] instead which strips the current working 
  directory from a path, if the path is inside of the CWD. 
  Another command could strip N elements from the beginning 
  of a path, N an argument of the command. Both of these can 
  be used by the application to create the desired effect.


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

  This is a duplicate of 899204, and has been fixed in the CVS
  head (March 6). See
  http://sourceforge.net/tracker/index.php?func=detail&aid=899204&group_id=12883&atid=112883

  inifile.test: Fixed [Tcllib SF Bug 899204] by (a) rewriting all
    tests to be completely independent of each other and (b)
    changing the mode when opening the test file to 'r'. It should
    be noted that the write facilities of the module are not
  covered
    by the testsuite. That is unfortunate.


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

  There was a patch by private E-Mail


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

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

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

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

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

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

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

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

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

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

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

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


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

  For me, the patch has the following issues:

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

  Could you reinvestigate the patch, please ?


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

  Bug closed, thank you all,
  Harald


login: 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: afaupell
username: afaupell
mimetype: text/plain
icomment:
  moved the destroy command to the per-connection section of the manual. this is consistent with the code.


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

  I found out through a second bug report that tree was not just 
  used here out of thin air, but is in conflict with a BLT 
  manpage. Fixed that.

  The topic in general is something we have to hash out among 
  all of us, on tcllib-devel. This should be kept on radar for after 
  the 1.4 release.

  For the 1.4 release I prefer specific bug reports about clashes 
  we can fix immediately.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Tweaked the documentation as proposed.

  Note: For Prim's algorithm I only stated the range of complexities, but not the exact complexity of our implementation. The problem is, I do not exactly know where our implementation lives, complexity-wise. The main influence is likely the struct::prioqueue implementation, and I have no exact idea about its complexity. On quick glance it seems to maintain a sorted list, I do not believe that it is a binary heap, fibonacci heap, or other similar structure.


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

  i agree. in addition to adding the query/ratio branch, perhaps we can add 
  a default branch?


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

  I will do that. This seems to be case of where the
  reflection transform in Trf evolved, but mime was not
  adapted to the change. I checked and the 'query/ratio', and
  some other messages are missing. I will add them. One
  branch, create/read is duplicated. Will fix that as well.

  Note: A default branch is actually present, and it generates
  an error message "Unknown command FOO".


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

  > Note: A default branch is actually present, and it generates
  > an error message "Unknown command FOO".

  i have no idea what i could have been thinking when i wrote that. please 
  keep the default branch and just get rid of the contents, i.e.,
      default {}


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

  Hm. This could lead to difficult to diagnose errors, when
  another new method is asked for, returns boguis result or
  does nothng ... silent failure. I rather like it more to
  throw the error. As long as it is not caught somewhere up
  the chain.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ad 1. Cloning is essentially a serialize+deserialize operation. Using snit introspection it should be possible to automate basic support for this, maybe even in a snit::macro. Note, this implies that currently there is no such support in snit, AFAIK. Now further, if the object to clone is more complex, like using timers, sockets, files, i.e. any type of state which is not stored directly in the object, the basic clone will not be enough. For these cloning will need custom written support code which handles all the complex parts.

  Ad 1. The struct::{graph,tree} structures in Tcllib, while not based on snit, contain '(de)serialize' methods, fully custom written, and assignment/copy methods on top, even with support for copy during construction.

  Ad 2. No idea, defering to Will for that.

  Ad 3. No idea, defering to Will for that.


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  File Added - 45770: list.test

  Logged In: YES 
  user_id=99768

  Verified using TDK that list.test has full (line-based)
  test coverage of the source code.


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

  Created subpackage struct::list in module struct of tcllib,
  as per our discussion in the tcler's chat.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 47547: prioqueue.test

  Logged In: YES 
  user_id=302287

  I have made some improvements (some more tests, better
  argument checking, use of DKF's K combinator where
  appropriate, addition of package require Tcl 8.3, name
  change of toppriority to peekpriority).


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

  Ignore the package require 8.3, should be 8.2. (using lsort
  with -integer etc. options and string equal).

  Could write docs, but what format? 


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

  note that the struct package
  already enforces a
  Tcl 8.2 requirement.


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

  you do not indicate where in the program the replaced code 
  causes an error, but from cursory inspection it is the use of 
  pack that isn't well handled.  pack and grid do not function 
  together, and you have to correctly setwidget code in a 
  scrolledwindow without further pack or grid calls to not cause 
  an infinite loop.


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

  Sorry I didn't realize the argument of setwidget would be 
  added to the display list without explicitly being packed! 
  Had to look at other closed bugreports to see the cause of 
  this is that bwidget now uses grid to do this, and the 
  cause of my problem was trying to pack it afterwards... 


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

  ![string compare ...] is equivalent to [string equal ...], but 
  string equal is new in 8.1+.  It appears that what bwidgets is 
  doing is OK.


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

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

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

  $compiler alias clock ::clock

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

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

  Any thoughts?


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

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

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


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

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

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

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

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


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

  Logged In: YES 
  user_id=72656
  Originator: NO

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

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

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

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

  File Added: namespace-snit.diff


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

  Logged In: YES 
  user_id=72656
  Originator: NO

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


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



  File Added - 265078: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

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


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

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

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


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

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


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

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

  I see:

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

  How does that differ in principle from

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

  The second case fails with

  invalid command name "foo"

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

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


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

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


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

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

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


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

  After reading bug 1178045 I fear I might overuse conversion to LDAPString in my code. Let me check and re-upload the fixed patch.


login: flatworm
username: flatworm
mimetype: text/plain
icomment:
  File Added - 284706: ldap.diff

  Logged In: YES 
  user_id=1350198
  Originator: YES

  Attached an updated patch with the logic regarding encoding of attribute descriptions and assertion values made more consistent on the source level.

  Also added more tests, comments made more clear and some procs renamed to better mirror their purpose.
  File Added: ldap.diff


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

  Accepted the patch with some minor changes to the test suit organisation.


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

  Quick note that the different log-levels were/are intended to be this type suppression-levels.

  You seem to interpret them more as categories of messages, and wish to have an additional argument denoting what I would call the 'priority' of the message inside of its category.

  Do I understand that right ?

  If yes, then me asking you to look at the 'logger' package (same module of Tcllib) is superfluous, as it has the same type of categorization, and no priorities. What it does have is the ability to create multiple independent loggers (actually a tree), which allows us to give each package its own logger, with independent suppression of categories.

  Interestingly enough, when I worked on the cvs2fossil application (*) I did not use 'log', nor 'logger', but wrote a new system with exactly that kind of priority based system you seem to look for. It had no multiple loggers however, and no categories either. But it also made sure that code in leog messages was executed only if the message was actually to be printed.

  It might be interesting to take this RFE and merge it into logger, to get a system having all of multiple loggers, categories, and priorities.

  I am reassigning to Michael Schlenk, as he is the maintainer of 'logger', as I wish to get his opinion on this as well.


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

  Logger could do such additional suppression levels in a hackish way, by defining subloggers with numerical names, it would just need some syntax sugar to make it nicer.

  Simply changing the signature of the logging function to ${log}::<level> suppLevel msg would have the bad side effect that disabled suppression levels would still eat runtime when disabled.

  Its basically a decision how to setup your logging subsystem, the more simple log package doesn't allow you to create fancy output/suppression schemes, while loggger allows it with some tinkering.

  So yes, i think this RFE is a good idea and could be done with the current logger code with just small compatible changes.

  Michael


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

  I should note that IMHO this type of enhancement may warrant a change of the major version number, and this would allow us to complete redesign the API as we see fit. no hacks would be needed as we would be able to redesign everything from the ground up.

  Of course, if compatible changes allow us to support this we could go that route.

  OTOH, IIRC we have some other RFE for logger currently done hackish, maybe it is time for a redo. I do not remember what this change was/is/might be.


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

  Yes. There are more things in logger that could improve (e.g. the logger proc signature and some others) and a lot of the internals could be done nicer.

  I think it would also be good to unify to just one logging package and not two or even more.


login: mocallins
username: mocallins
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=931198
  Originator: YES

  Yes Andries, for sake of discussion I called them categories, simply because I wanted to refer to the suppression as a "level", but "priority" is just as accurate. 
  I did look at logger and just as you referenced it didn't provide a "priority"/"level" as well.

  Excellent to see that it wasn't just me thinking that we needed some enhancements.


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

  Patch already applied - but let me check the code to be sure


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

  Just checked: changelog refers to thi patch dd 23 december 2007


mimetype: text/plain
icomment:
  something i realized after a few tests.  The key set is not always generated with the equal amount of bits specified, and that is what causes the problem at the time of the signing.

  Something that may patch the problem (not the actual fix) would be to recalculate the bitlenth using the way parse_key proc does and set retkey(l) to that value before returning the set of values at the end of the generate proc.


mimetype: text/plain
icomment:
  I uploaded a different algorithm that works for me, still slow on the prime search on bigger keys (2048)

  hope it helps


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

  Install.tcl is for use by source distributions. A CVS snapshot 
  is no such. install.tcl does not support CVS snapshots. A 
  CVS snapshot currently requires 'configure ; make install'.

  Changed the script to notify the user of this.
  Keeping open, want to change this.


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

  Ok, I consider this fixed: The .sh/.bat files and the old all-tcl 
  installer are discontinued and removed, and the new all-tcl 
  installer correctly handles installing from either src-dist or 
  CVS snapshot.


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

  I'm fairly sure those are necessary, and their parentage is 
  also necessary due to limitations with how things might 
  otherwise communicate.  As this is really just a problem 
  interactively, the only thing really needed is a better way 
  to filter out that stuff.


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

  The ActiveTcl version issue was recently corrected.  The
  other problem I'm referring to Damon.


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  Can you provide a piece of sample code along with what you
  expect the result to be?  I'm not exactly sure what I'm
  looking for here.


login: rmaris
username: rmaris
mimetype: text/plain
icomment:
  File Added - 75892: test.tcl

  Logged In: YES 
  user_id=968757

  Here is the sample code.
  Note that automatic placement "above" when there is not 
  sufficient space for placement "below" does not work, too.


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  I'm not sure what result I'm looking for.  I tested it
  against the last version of BWidgets, and it seems to work
  as advertised.

  If I put the window against the left side of the screen and
  ask for a left placement, it goes to the right.  Vice versa
  on the other side.

  The same goes for above and below.  What are you expecting
  to see that you're not seeing?  Can you tell me where to put
  my window or modify the test code to place the window
  exactly where you're seeing the problem?


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  Oh.  I see now.  I think I already fixed this from another
  bug that was reported.  I will commit my changes tonight and
  see if that fixes your problem.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  What does the command 'info loaded' report regarding loaded C packages ?
  crc can use a number of C extensions to accelerate its operation and knowing which is loaded should help us finding which of them leaks.


login: pedietz
username: pedietz
mimetype: text/plain
icomment:
  % info loaded
  % package require cksum
  1.1.1
  % info loaded
  % 

  No packages.

  This problem happens under 8.4.14 with tclllib1.1.10
  and 8.5.6 with tcllib 1.1.11.

  This is the entire program:
  package require cksum
  while { 1 } {
  set a [crc::cksum helloworld]
  }

  Run that.  Then in another shell do 'ps aux | grep tclsh'  and watch the number grow.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Phil, thank you for the additional information. With none of the accelerators loaded this definitely looks to be a problem within the cksum Tcl code itself.


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

  Fixed in CVS head. Bumped to version 1.1.3. The CksumFinal command missed the 'unset state' cleaning up the internal state token/array. I.e. the code generated thousands of tokens = array variables and never removed them.


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.


mimetype: text/plain
icomment:
  there are 3 adendums i made regarding to key generation, kay parse and key convert2pem
  how should i submit them?


mimetype: text/plain
icomment:
  following the bug ID: 3439693, looks like replacing ::asn::asnPrintableString to ::asn::asnString in ::pki::x509::_list_to_dn solves the problem too.


login: gwlester
username: gwlester
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=121110

  Larry,

  Can you tell me which parts of this bug report are against
  the ftp module of tcllib as opposed to hpupdate?

  That way I can go hunt down and kill the offending bug(s).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13443: 476804.diff

  Logged In: YES 
  user_id=75003

  Enclosed a patch implementing the FR for ftp urls.


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

  This doesn't work too well. I'll work on this a little and
  generate a patch but 
    uri::geturl ftp://luser:lpasswd@ftpserver/file.txt
  should use the user and password, hence:

      array set urlparts [uri::split $url]

      if {$urlparts(user) == {}} {
          set urlparts(user) anonymous 
      }
      if {$urlparts(pwd) == {}} {
        set urlparts(pwd) user@localhost.localdomain
      }

      set fdc [ftp::Open $urlparts(host) \
          $urlparts(user) $urlparts(pwd)]

  But more significantly the ftp::List processing fails
  completely when I'm using a windows based ftp server and
  also fails on the client side when I'm working within tkcon.

  For tkcon the ftp::List command has been renamed so:

      # Fix for the tkcon List enhancements in ftp.tcl
      set List ::ftp::List_org
      if {[info command $List] == {}} {
          set List ::ftp::List 
      }

  but I'm still working on the list processing. Maybe tonight
  when I can play with Windows, Linux and OpenBSD servers.
  We'll need to try this on a VMS server and any other
  weirdies too I guess. (Are there still any VMS servers?)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 15911: ftp_geturl.patch

  Logged In: YES 
  user_id=202636

  Here is a patch that works for my win32 based ftp server.
  I'm suspect it would be better to fix the ParseList proc
  rather than avoid it but it's difficult to be sure of
  parsing ls -l output from different platforms (I'm thinking
  VMS could be _really_ different).


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

  Re-opening because I failed to notice that this was closed
  and I donT want to copy everything into a new bug report.


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

  I'm going to commit this patch now. My only outstanding
  concern is that I'm currently not using the ftp::ParseList
  code. Really I should fix the split to cope with DOS/unix ls
  results. I think this does the job though.


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

  Feel free to hand off any of these that I have submitted to
  me to close/commit - I have the time at the moment.


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

  This is in principle handled by the new magic(5) based
  recognizer, new module fumagic aka fileutil::magic. However
  the magic(5) file the current code was generated from
  apparently did not contain checks for Targa. Therefore
  keeping this entry open.


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

  Ok, I am giving in. fumagic / fileutil::magic is enough for
  this. No need to dup functionality.


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

  "One of the debugging tools" is ?? (pro tools ?)

  .man editor, but that could go into doctools.


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

  See also
  FR [ #516723 ] javadoc like application.

  From the chat: "One of the debugging tools" = One of the 
  simpler debuggers not equal to tclpro.


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

  After some discussion on the Tcler's Wiki chat room we
  elected to add tkinspect as a CVS module under the tkcon
  project. This is partly to avoid creating a new sourceforge
  project for it and partly because there will likely be some
  integration of tkinspect and tkcon in the near future.


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

  The  crc32 test code checks that the Trf crc's and tcl crc
  values are the same. You can explicitly call each one even
  when Trf is available by using crc::Crc32_trf and
  crc::Crc32_tcl.
  As far as I can tell these two functions are producing
  identical results. Can you post a set of tests that
  illustrate the incorrect value and give the version of
  tcllib and trf that you are using.

  The crc package and Trf zlib values should be identical.


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

  Nothing happening. As this works for me I'm closing it to
  this effect.


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: tomk
username: tomk
mimetype: text/plain
icomment:
  Andreas,
  A trigger on ::argv would be a simple solution and I wouldn't think there would be bad side effects. I've modified ::argv in several applications and followed it with an update of ::argc. I don't think a trigger on ::argv would break mine or similar code. My personal feeling is I don't care if the change is made or not.
  tomk


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

  Marshall, does this make sense ?

  Or should we have a special command just for parsing the
  header of a mail or mime part ?


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The newly attached file is an extended testsuite where I tried to reproduce the reported problem. See the test cases 3.0 to 3.2 at the bottom.

  Sadly these tests all pass (*), so I was not successful.
  Is it possible for you to attach a script which reproduces the issue exactly ?
  That way I can not only see the problem you have, but also have a piece of code ready to become a test case.

  ~~~~~~~~~~~~~~~~~~~~
  (*) I used Tcl 8.5 head (8.5.11+), and Tcl 8.6 head (8.6b2+) from the core source repository.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Attached a patch (unified diff) of a possible fix for this.
  Please test.
  If possible please provide a small test script demonstrating the issue also.
  Something I can add to the package's testsuite.


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

  I confirm that there is no canonical method of copying a
  tree, short of walking.

  I have to admit that I dislike the proposed syntax. ... How
  about this

    ::struct::tree a        ; # creates an empty tree a
    ::struct::tree a := b ; # creates tree a as copy of tree b

  This seems to be more natural.

  Another possibility are tree methods

    ::struct::tree a
    ::struct::tree b
    a = b
    b copy-to a

  A logical extension to the copy methods would be to copy a
  subtree instead of the complete tree. IOW to use a specific
  node != root as the root of the copied tree.


login: davidhbigelow
username: davidhbigelow
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=664837

  Well - the syntax is recognizable as to what it does by 
  anyone who reads it. Althought the -copy -- option may be in 
  the wrong spot for the current command.

  Since it looks easier to add the option to the end of the 
  command why not use something like the following:

  ::struct::tree myTree copyto myTree2

  ::struct::tree myTree -> myTree2

  ::struct::tree myTree myTree2


  Regarding the other possibilities.

  a = b --- looks a little too much like an invalid "set"  but if you 
  know what you are doing may make sense.

  b copy-to a -- looks like it would be easier to work with.

  FORMAL NEW OPTION REQUEST/SUGGESTION:
  ---------------------------------------------------------------------------
  Per your logical extension - If "b copy-to a" is implemented, 
  please also have the ability to use this for specific nodes and 
  branches also.  For example:

  b <node> copy-to a <target node> <location>

  <node> = Specified Node of Current Tree
  <target node> = Target node location in Target Tree
  <location> = Position wtihin the Target Tree of the <target 
  node> (e.g., 0, end, end-1, end -2, etc..)

  EX: b l_door copy-to a root end
  --> Copies node "l_door" within tree "b" to "a" and places it 
  (and all of it's children) into the "root" node at the "end"



  To be honest.  ":=" does not scream what it does as I read 
  it.  I have not see this used elsewhere within tcl (but then 
  again I am not as seasoned as the core developers and I may 
  learn somthing thought this process) ;)


  Any Questions?

  Dave Bigelow
  davidhbigelow@compuserve.com


