# ticketchng

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

  Damon, I have seen the latest checkin and played with it.
  The demo now comes up for 8.3 and 8.4. However under 8.4.,
  and only 8.4!, the selection of an item in the list of a
  combobox using the mouse still does not work. It however
  does work for 8.3. So there may be a Tk 8.3/8.4 difference
  in play for that bug too.


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

  Mine tests fine.  I only recently started testing in 8.3, so
  I know that 8.4 works, or I wouldn't have committed the
  code.  Hrmmm...  I don't know what could be happening on
  your end.


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

  this appears to have been a quirk in Andreas' 8.4.  Works in 
  the 8.4 head.


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

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


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

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


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

  I also encountered this issue, but fixed it slightly
  differently. Note that this error occurs only when there are
  unallocated items in the pool.

  Alternative diff:

  --- pool.tcl.orig       Wed Nov 19 03:19:50 2003
  +++ pool.tcl    Wed Nov 19 03:02:54 2003
  @@ -675,6 +675,8 @@
               if { $state($prefer) == -1 } {
                   set index [lsearch $pool(freeitems) $prefer]
                   set item $prefer
  +            } else {
  +                return 0
               }
           } else  {
               set index 0


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

  ipentry and autoscroll are mine. i was following the
  conventions from tcllib so the docs are in the doctools
  format instead of troff and are named .man as opposed to .n

  what should be done about this? i think the installer should
  be fixed and the other man pages be converted to the
  doctools format.


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

  from Andreas Kupries:

  The entire build system for tklib has been replaced with the
  same type of
  build system in use for tcllib. I.e. Swiss Army Knife Tools
  (sak.tcl) with
  attendant files, installer based on that, etc.

  All existing nroff manpages (two) have been converted to
  doctools. All
  modules without any documentation (one) got manpages based
  on doctools. All
  (four) modules are thus documented now.


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

  Snit 0.93 has two new commands, snit::typemethod and snit::
  method, that allow typemethods and instance methods to be 
  defined (or redefined) for a previously existing snit::type, snit::
  widget, or snit::widgetadaptor.  These commands can be used in 
  the same source file as the snit::type command, or anywhere 
  else; a snit::type object can even use them to dynamically add 
  new methods to itself.


login: edsuom
username: edsuom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302938

  Forgot to log in...but this was from me (Ed Suominen). Also,
  if I can figure out how, I'll submit a diff for easy reference.


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

  Logged In: YES 
  user_id=80530


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

  Please review and apply if
  acceptable.


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


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

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

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


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

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

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

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


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

  This has nothing to do with Tcl and everything to do with the 
  changes to md5 v2 where Trf isn't used by default.


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

  The quick solution to this problem is to require md5 1 which
  provides the same support as previous tcllib distributions.
  Version 2 has a different API and is more akin to the C API
  provided by OpenSSL and the RFC reference implementation.
  This allows for incremental updates to the hash, for example:
    set hash [md5::MD5Init]
     while {$accessing_data_in_chunks} {
        md5::MD5Update $hash $data
     }
     set result [md5::MD5Final $hash]

  Unfortunately a bug in Trf means that it can't be coerced
  into performing this way (at least not when I last checked
  this). There is a critcl based implementation but this isn't
  created by the current installation procedure.

  Needs sorting out. You can create a compiled module with
     cd src/tcllib
     ./sak.tcl critcl md5c
  and then copy the modules/md5c dirctory into your installed
  tcllib1.5 tree.


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

  I'm closing this because we would prefer to see tkdnd slated
  for the head, which will make all of bwidget's dnd stuff
  redundant.


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

  Sending this over to Dr. Vogeler, the creator of the code in
  question.


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

  The above example has been added as a testcase to textutil.
  For tcllib 1.4 the new test does fail. Using tcllib 1.6 the
  test suceeds. IOW the problem has indeed been fixed for
  Tcllib 1.6.


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

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

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

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


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

  Reopening --  this is back again.

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


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

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

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


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

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


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

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


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


  Possible fix: add the pair "\01" "-->" to the
  $::htmlparse::escapes string map, so [htmlparse::mapEscapes]
  will change it back.

  Don't know what to do about parsing "<!-- ....-- >", this
  part is beyond me.


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

  The relevant part of the spec is

    http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5

  BOC is always '<!--'. '<--' is not legal. Tidy converts this
  into an entities, and essentially converts the whole string
  into a PCDATA section, plain text. Htmlparse is now doing
  the same.

  EOC is indeed allowed to have whitespace between '--' and
  the closing '>'. This has been fixed, by replacing the
  relevant [string map] with a [regsub].

  All changes have been made to the command "PrepareHtml".

  The changes have been committed to the Tcllib Head.


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

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


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

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


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

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

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

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


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

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


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

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

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

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

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


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

  It seems that there are problems entering text in 
  sourceforge. Contents inside <<>> seems to dessapear.

  The correct line to include in init.tcl is something like:

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


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

  It seems that there are problems entering text in 
  sourceforge. Contents inside <> seems to dessapear.

  The correct line to include in init.tcl is something like:

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


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

  Fixed and committed.  Thanks for hunting down the problem
  and solution. 0-]


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

  Fixed and committed.  The problem was actually in
  BWidget::place and had nothing to do with dialogs
  themselves.  Dialogs were just affected because of the
  geometry problems in place.


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

  The current version is much more complete than the two I
  already attached. I would say that for many practical
  purposes it is already useful. Things to add/change: more
  flexibility, better error handling. One big lump to add: a
  whole new plot type, but that is less "urgent"


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

  Interesting. From a recent thread on c.l.t the symptoms seem
  to indicate that the smtp server is closing the connection
  on you while you are sending data. It is however unclear to
  me why it should do so if the buffersize is not set. The
  algorithm for that is a bit odd too. The /4*3 magic looks
  like preparation for base64 encoding or similar (3 byte
  binary -> 4 byte printable).

  Marshall ?

  To what type of smtp server are you talking to ? Also, what
  do you see if you use sockspy (http://www.tcl.tk/sockspy) to
  monitor the connection between smtp server and your example
  script ?

  Sorry that this did not get into the 1.6 release.


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

  Had not planned to remove it. Just curiosity. Change applied
  to CVS head.


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

  I believe that this bug is fixed in CVS Head and the released 
  Tcllib 1.6. I applied a patch by Gerald Lester and in the q&a 
  about the various part there was one chunk to fix such an 
  error. Please try tcllib 1.6.


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

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


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


  Will suggests these failures
  may trace back to some
  problems in Tk 8.4.6.  Can
  someone familiar
  with the snit internals construct
  a script of Tk commands that
  exhibits similar behavior?


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

  Thinking about it a bit more, I expect this is a problem with the 
  option database.  The above tests set something like 
  "*Dog.background" to "green" using "option add", and then creates 
  a widget with widgetclass Dog.  When the option is retrieved it 
  comes out as a hex string, instead of "green".


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


  This test is failing only on a
  window manager system (CDE 1.5)
  where there are some X options 
  in place.  The priority in these
  tests are "widgetDefault" which
  is too low to overcome the
  system options.


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

  Aha!

  OK, that's definitely a bug in the test suite.  Thanks for tracking it 
  down!

  I'll fix it.


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

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


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

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


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

  The HTML Standard 4.01 does not support <list name="List1"
  />, this is XHTML Syntax and for XHTML one is better off
  using a true XML Parser like TclXML or tDOM.

  Empty tags do not have closing tags, so it is correct if no
  closing tag appears in the result list.

  Fixing the class code looks like the wrong thing to do, it's
  2TreeCallback that needs fixes, the tree generation.

  As <list> isn't a valid html tag it should be ignored by
  2Tree anyway.

  If you did it with <li /> and it breaks, thats an other matter.


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

  See:
  http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines
  C.3 for the suggestion of W3C regarding empty elements with
  non empty content model.


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

  I got another report about this, see 

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

  This one came with code. It changed the empty tag into a
  single closing tag. Which I considered wrong. However based
  on that I was able to create something which transforms an
  empty tag into a pair of opening and closing tag in the
  event sequence. I.e. something like

      <a href="foo"/>

  would be handled as if the input had been

      <a href="foo"></a>

  This is IMHO the most sensible approach to real-world data
  using empty tags.

  Committed my changes to head, see the other report for details.


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

  I confirm this defect. When I fixed the code to send 230. My 
  Linux based client (in this a DVR) started working.
  Roy Terry - 17 May 2004


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

  Code has been corrected, committed to HEAD, and will be next
  release.

  You may want to pull and validate the fix.


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

  Patch applied.

  It's not misrepresented. The Network Time Protocols module
  in tcllib is intended to collect implementations of such
  protocols. The first one in happens to be RFC 868 TIME as is
  clearly stated at the top of both the man page and the tcl
  code itself.

  Somewhere I have 90% of an implementation of RFC 1035 but it
  hasn't gone in yet.

  I'll see about checking the protocol -- although I don't
  think RFC 868 can really handle that.


login: alathar
username: alathar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=984964

  Thanks for applying the patch!  As for the rest, sorry - I
  confused "an" NTP with "THE" NTP. <sheepish grin>


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

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


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

  This should end up in the console now and not pollute the
  starting terminal. On linux /dev/null is ok - there is a
  warning but that is all.


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

  This has been implemented in Snit V0.95.  Almost all runtime code has 
  been pulled out of the generated type and into the ::snit:: namespace, 
  where it is shared by all existing snit::types and snit::widgets.


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

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


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

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


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

  Noisy defaults have been changed to silent ones, for
  anything below warning, incl., in CVS head.


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

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


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

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


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

  This is a duplicate of
  http://sourceforge.net/tracker/?func=detail&aid=914488&group_id=12883&atid=112883


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

  This actually works for most type/order combinations. There
  are only three exceptions. The three non-working
  combinations are: dfs/post, bfs/post, and dfs/in. I.e. any
  of the two walking types, in post-order traversal, and the
  in-order traversal. The problem for all of them is that the
  pruning has to happen when entering a node, and for them the
  entering is done only internally, the walk script will not
  see it per definition of the traversal, and thus is unable
  to tell the walker that pruning is wanted for a specific node.

  It might be best to simply document these exceptions, simply
  say that pruning is not possible fro them. And code the
  prune command to test for these situations and throw errors.


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

  Done and committed to head.
  Also added methods 'ancestors' and 'descendants' for treeCL.


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

  This is likely not a bug in the docs, but a bug in the
  generation of the usage string.

  Ok, having looked at the output as I have it (CVS Head) I
  see a clear demarkation between the -v and the character
  '1'. Basically the output has two columns. In the first we
  see the option, like "-v", or "-foo value", with the string
  "value" as indicator that the option takes an argument. The
  second column then shows the default value, if there is one.

  I have no problem seeing that -v is a boolean option not
  taking an argument (missing string "value"), and true by
  default. Whereas -foo is an option taking an argument,
  indicated by "value".


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

  I'll keep this open and assigned to me until I've finished
  the SASL mechanisms I want to support. (Which won't take
  long -- they just need testing.)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Deleted - 80424: 



  File Added - 80518: smtp-auth.patch

  Logged In: YES 
  user_id=202636

  OK tested CRAM-MD5, PLAIN and LOGIN against Sendmail and
  Microsoft SMTPd

  Committed.


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

  Hitting the return key on the login name will now always
  focus the password entry.  Hitting return on the password
  entry will now always close the dialog.  The rest of the
  patch was merged.  Thanks.


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

  Note: [file tail] is only the last component in the path.
  You are throwing away the whole directory hierarchy.
  Depending on what you wish to do it may be better to
  [file join /tmp [eval file join [lrange [file split $path] 1
  end]]]
  That preserves the whole directory hierarchy and places it
  under /tmp. It may also require additional code to create
  missing parental directories first.

  Your eval looks good.
  One related eval is in line 675, proc ::ftpd::Fs (Note the
  uppercase). This calls your 'fakefs'. This eval however
  looks ok as well.

  In all places where 'ftpd::Fs' is called the path is at
  least in part taken from the incoming ftp command. IIRC the
  protocol has no quoting provisions for paths containing spaces.

  My advice would be to

  * Use 'sockspy' to log what is going on on the command channel
  * And/or instrument the 'ftpd::command:*' commands to see
  what the server is getting from the socket, before any
  processing. The argument 'list' contains the ftp command. It
  is created in 'ftpd::read'. The server reads a single line
  and splits it at whitespace. ... That may be the culprit.
  Except that I have no idea right now if an ftp client
  performs quoting, or is allowed to perform quoting for paths
  containing spaces, and what the RFC says about this. It
  could be that the general processing of the command in
  'ftpd::read' is wrong. Maybe split should not be used, but
  more something like 'string first' for the first space.
  Depends also possibly on if a command can have more
  arguments after the path.


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

  Yes, it looks indeed as if the general argument processing
  in ftpd::read is the culprit. The argument processing is
  individual per command, and for those taking a path name the
  path is everything after the first space to the end of the
  command line.


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

  See also
  http://sourceforge.net/tracker/index.php?func=detail&aid=1002936&group_id=12883&atid=112883
  for an alternate fix.


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

  I believe this is now fixed with a recent commit for Bug 1720144.


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

  The current behavior of the dynamic help balloons is built
  to mimic the behavior of Windows' help balloons, and it does
  that just like it's supposed to.  Help balloons aren't
  usually placed on widgets like text boxes, which is why it
  look kind of weird using them like you are.

  I will add an option (which will be disabled by default) to
  get the behavior you're looking for as I've found myself
  wanting it in the past, but I usually just find another way.


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

  Looking at the code for the head, the '1' appears to be the
  correct value, as that will extract, eg, "p:2" and give us
  "2" as the page identifier.


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

  This may actually a bug in the mime or smtp package. My
  problem is that I cannot say if all the arguments to the
  mime/smtp commands are correct and what not. I assume for
  now that your 'old' and 'new' are 'body' in the code segment
  coming before them.

  I am assigning this to our smtp/mime expert here, Marshall Rose.


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

  This works for me using the tcllib 1.6 versions of mime and
  smtp.
  I get a warning that To isn't present but here is no problem
  with the message data.

  I call this fixed.


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

  I see, the RE does not handle the user information at all.
  Fixed in CVS Head.


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

  Another thing to try is the jpeg::exif command in the new
  jpeg module. This is in the CVS head.


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

  This is actually a duplicate of
  http://sourceforge.net/tracker/index.php?func=detail&aid=784519&group_id=12883&atid=112883

  Tcllib 1.4 has the bug in the multiplexer manpage, and
  during installation of Tcllib 1.6 it seems to take the 1.4
  doctools for the doc generation instead of its own and
  fails. After removal of the installed 1.4 you should be able
  to install 1.6.


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

  A fix has been committed to the cvs head. In essence nroff
  now uses the same system as HTML and XML to correctly
  protect and handle its special characters in both markup and
  plain text.


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

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


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


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

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


login: yahalom
username: yahalom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=130120

  the bug should be opened as currently microsoft changed the 
  content type. the text/xml comes with additional data so 
  the switch misses it. the fix should do
  text/xml* 


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

  The $lbf listbox also needed these bindings.  Otherwise
  patch merged.  Thanks.


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

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

  Michael


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

  Hour merge - This sounds like tclhttpd - Can this be
  expressed in a test case independent of that application ?

  I guess that this is a rounding/truncation issue somewhere,
  right ?


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

  This seems to be a duplicate of

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

  Closing as suhc, especially as the other report also has the
  fix.


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

  Arjen, how much of this has been done already. I have seen
  the math::optimize, but do not know how much it fulfills
  this request.
  Or if others fulfull it (partially).


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

  All of the above has been done, with the sole exception of 
  cluster analysis. And I should revisit the FFT examples - Lars 
  Hellstrom suggested some much better alternatives.

  I consider it closed


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

  I'm not sure what the expectations are here.  The widgets do
  expand as the ScrollableFrames expand, but they are
  constrained in that frame.


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

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


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

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

  Reordering advice taken.

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


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

  Duh - there is a catch but it got disabled during testing
  and left disabled.


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

  Can you attach a tcl script which excersizes the problem ?
  I see that InitDataConn's state switch has no branch for
  'pwd_sent', however I have trouble tracing the spaghetti
  that is ftp's implementation to see how it happens to have
  that value. It is indirectly called via
  Open{Active,Passive}Conn, and no user of these two commands
  has state 'pwd_sent'.

  Note: I am looking at ftp 2.4.4, as found in the CVS Head of
  Tcllib. File revision 1.42.


login: thomasmaeder
username: thomasmaeder
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=714202

  Another failure is http://host/path1/path2?param=value#fragment :

  % uri::split "http://host/path1/path2?param=value#fragment"
  fragment fragment port {} path path1/path2?param=value scheme http host host query {}

  instead of

  fragment fragment port {} path path1/path2 scheme http host host query param=value


  The obvious solution would be to use a variation of the regular expression given in Appendix B of http://www.ietf.org/rfc/rfc2396.txt (the variation being directly splitting host and port).


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

  I seem to be able to navigate the boxes with cursor keys. 
  This is on OS X, 10.4.7, using fink's wish.


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

  The lines were added in response to patch 947109, applied
  2006-09-26.


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

  Version 1.164 reinstates support for tcl8.3.
  If this version raises any problems - either bug me on the
  chat or raise a new bug.


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

  Have corrected these. The problem is due to TAG priority. 
  Still have a couple of minor issues, not mentioned here, 
  to correct before applying a patch.


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

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


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


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

  Personally, I do not find this too funky at all. In fact, I'm inclined to go one step further and change the default for this option (-exportselection) into 0. 

  The documentation for this option says:
  "The default is usually for widgets to export selections." (meaning the X-selection)

  I question this statement. I haven't seen many applications that show this default behaviour. (Maybe it is a Unix tradition.)

  A combobox is primarily about selecting an item from a collection of items. This is unrelated to selecting a sequence of characters for a copy/paste operation, and we ought not confuse/mix these two different concepts. If users do want to set the X-selection too, they may choose to change the default.


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

  Not my department.  Damon?

  FWIW: On X11, Gtk+ and Qt editable comboboxes do export the selection; ditto spinboxes and entry fields.  The only major toolkit I've encountered that doesn't do this is the one Mozilla-family tools use; there, entry fields appear to use a hybrid X11-style global primary selection combined with Windows-style independent selection (which I personally find very confusing.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The patch seams reasonable to me too.
  Nevertheless, I have checked the behaviour on windows and linux with and without patch. It works fine for both cases.
  #- test script -
  pack [ComboBock .c]
  pack[ComboBox .n -exportselection 0]
  # set a selection in both using the mouse
  .c configure -exportselection 0

  In the first case, the selection is exported and removed if there is somewhere else a selection
  In the second case, the selection is local and not exported to other windows.

  I decided not to apply the patch.
  Please notify, if the patch helps anybody, no issue to put it in neither.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thanky to Eric, I have got the point.
  One requires values to test it.
  Revised test script:
  -----
  pack [ComboBox .c -values {1 2 3}]
  pack [ComboBox .n -exportselection 0 -values {1 2 3}]
  -----
  When clicking on an item in the drop-down box, the result gets selected in the first case. In the second, it does not and the cursor is placed behind the entry.

  A matter of taste. Please post, if you like it or not.


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

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


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

  This failure only occurs with Tk 8.5/HEAD.  I can't
  duplicate it with 8.4.6.

  With 8.4.6 this *does not* work:
  ctext::addHighlightClassForRegexp .ct comment navy {#[^\n]*\n}
  That same RE works properly in 8.5/HEAD.

  This RE always seems to work (and interestingly seems to
  avoid the endless loop with 8.5):
  ctext::addHighlightClassForRegexp .ct comment khaki {#[^\n\r]*}

  Time to file a bug for Tk I think.


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

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


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

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


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

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

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

      mime::finalize $tok
   }

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

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


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

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

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


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

  It is the 'calendar' module, somehow. It has no
  documentation, and that screws up the system for all modules
  that follow. The simplest way to repro the problem is

      ./sak.tcl nroff calendar FOO

  for any other module FOO, and the doc generation will barf.


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

  Duplicate of [Tcllib SF Bug 948273].

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

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


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

  Confirmed, the first line in _auto_complete prevents any
  matching when typing in uppercase chars.  Why is that there?


login: anonymous
username: patch:
mimetype: text/plain
icomment:
  @@ -123,8 +123,11 @@
       ## with canvas-'create line', 'create oval'. Computed jump to the
       ## actual drawing command.
   
       Draw_$direction
  +
  +    ## Lowering the gradient items
  +    $canvas lower canvas::gradient
       return
   }
   
   # ### ### ### ######### ######### #########
  @@ -270,6 +273,6 @@
   
   # ### ### ### ######### ######### #########
   ## Ready
   
  -package provide canvas::gradient 0.1
  +package provide canvas::gradient 0.2
   return


login: aku
mimetype: text/plain
icomment:
  The cause of the problem is that the actual gradient items are created late, in response to <Configure> events.

  Fixed in [5c19b0d0e3]. Version bumped to 0.2.
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Added the mentioned missing categories.
  + Examples.
  - All tcllib categories, bwidget, mclistbox, etc. I.e. not applicable.


login: aku
mimetype: text/plain
icomment:
  Applied in revision [8a11db6d15].
  Committed.
  Pushed.

  Note: A more modern heading is the use of /usr/bin/env, i.e. like

    #!/usr/bin/env tclsh
    # -*- tcl -*-

  No need for exec and continuation line shenanigans.
  AFAIK the 'env' implies an internal 'exec'.


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.


