# ticketchng

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

  Consider:

  package require snit

  snit::type Y {
  }

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

      constructor {
  install Y using Y %AUTO%
      }
  }

  X x;

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

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

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

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

  Colin.


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

  OK, I see what you're after.

  In your example, "x y" can't return the Y object's name; I'm using
  [namespace ensemble] for the dispatch now, and [namespace ensemble]
  requires a subcommand.

  Yes, "info self" would give you what you want; and it would certainly
  be easy to do.  I'll think about it.


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

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

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

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

  Regards,
  Frank Gover


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


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

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

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

  Regards,
  Frank Gover


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

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

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

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

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


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

  bug 1 was fixed on 4/2/05 i suggest upgrading to the latest 
  version before submitting a bug report. I will look into #2


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  You can still use the environment variable TCLTEST_OPTIONS to provide additional settings to tcltest ...

  TCLTEST_OPTIONS='-file math.test' ./sak.tcl ... might work.

  An alternate solution would be to put the block 142-280 into a procedure, and call this procedure in "testNeedsTcltest" after we have established the tcltest package ... Oh, and lines 315-372 as well.


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

  Moved the tcltest
  compatibility initialization into a procedure (InitializeTcltest)
  which is called by testNeedsTcltest and a few other places to be
  done only after we are sure that the tcltest package is present.


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

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


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

  Added the -nonewline options. Comitted to head.

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


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

  Fixed in CVS head on Friday Oct 7 after reported by Mikhail
  Teterin, a FreeBSD maintainer. He has the fix as patch as
  well, to be put into the ports build system.


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

  Using the CVS Head of Tcllib I am unable to reproduce this.
  I used Tcl 8.3.5.
  I also used tclsh together with vwait, instead of wish.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  I understand it doesn't happen under tclsh in 8.3.5
  but that's not the environment I have to support, which is
  wish 8.3.4.

  When I get a chance I can try upgrading to 8.3.5 but it won't
  be soon.


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

  I understand, however from my perspective it is a quite
  likely a bug in the tcl core tripping comm, seeing that
  8.3.4 does not work, yet 8.3.5 does, with comm unchanged
  between the two. And that is something which is difficult to
  impossible to work around.


login: kgsf05
username: kgsf05
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1341876

  OK, thanks for investigating and explaining. I will try to 
  schedule time to attempt an upgrade to 8.3.5. In the 
  meantime I will have to install comm4.0 in parallel with
  comm4.2 and load that version explicitly when running under 
  8.3.4.


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

  Thanks.

  I had the changes to pop3 ready (deery's items) by 
  yesterday evening and will commit these first (I had fixed 
  the pkgIndex.tcl as part of the changes, but not the docs) 
  and then apply yours, after suitable merging ...


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

  fixed in 1.5 - -repeatdelay and -repeatinterval are now core 
  options to the button, so they have to be "removed" in the 
  BWidgets sense.


login: szinck
username: szinck
mimetype: text/plain
icomment:
  Hi Russell, I had the same issue as you on the second bug you mentioned.  If the connection is closed before the last line of a multi-line reply is sent, the ftp client will hang.  I couldn't attach a file, otherwise I would've just added it to this bug.  I created a new bug #3288977 and attached a patch.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Shaun's patch has been committed to CVS Head, package version bumped to 2.4.10.

  Russel, you might wish to recheck your problem. If it persists I would like to get a patch/sources for the fix, taking Shaun's changes into account.


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

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


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

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


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

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

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

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


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

  This looks reasonable to me.

  Files changed: mainframe.tcl : r1.8 -> r1.9


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

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


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Patch Code - Modified - New Version

  Also added synonym "-bg" for -background (required by ComboBox mega-widget)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm ... Oh! For Tcllib 1.15 I modified the "json::write" package to not quote "/" characters as "\/" anymore.
  While legal as per JSON syntax it is not really necessary.

  Compare {\"is\":\"/
  Versus  {\"is\":\"\\/

  This is "just" a case of the testsuite requiring an update. Not a bug in the package.
  And me forgetting to run the full testsuite after all the changes going into the release.


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

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

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


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

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


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

  To what combobox do you refer? tcllib doesn't have one, and the only thing in tklib that I see with a combobox is tablelist.

  $ tclsh
  % package require tablelist
  4.6
  % ComboBox .cb -values {a b c a b c}
  invalid command "ComboBox"
  %

  Give us info on what version of tcl and tk and what combobox you are using.


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

  According to the category the bwidget one. bwidget is in this project.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  Sorry, thought, the category would be enough, but ... I missed the BWidget version I use.

  I tried this behaviour with the BWidget version 1.7 and the most current one I know 1.8.

  Hope this helps!

  Martin


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Martin,
  thank you for the report.
  The issue is fixed in current cvs by adding a variable holding the last set index.

  This also solves the issue:
  % .cb setvalue 5
  % .cb getvalue
  2


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

  I should clarify that the issue is the inclusion of the -
  disabled* options that do not exist in 8.3.


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

  There is no -disabledforeground/background in 8.3 entry 
  widgets, yet the code tries to declare them as TkResource 
  items.


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

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


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

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


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

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


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

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


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

  * tree.tcl: Corrected keyboard navigation so that open/close
  commands are invoked when right/left arrows are used to
  open/close
  nodes, patch from [Bug #435097].  Also corrected keyboard
  navigation on right arrow press; previously only opened
  closed
  nodes that had children, but should always open nodes,
  regardless
  of whether it has children.


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  This has been fixed in "pki" version 0.2, which was committed to tcllib a few days ago.

  I initially took the same approach as you before I noticed [asn::asnGetString].


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Side note: The files section contains "release candidate 0" of a 1.14 Tcllib release. This contains pki 0.2. In other words, testing is possible without going through CVS.


mimetype: text/plain
icomment:
  Tested the release candidate version, it works fine with ::asn::asnGetString instead of going through the switch I mentioned.


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

  The two constants '0' and '1' have been defined in each
  high-level proc.
  The test suite was improved with new tests, including tests
  not devoted to this evolution. (division, modulo, remainder...)

  A hook (_treat) was created to handle the constants :
     _treat var ?var ...?

  Replace each variable named 'var' by the internal
  representation if it is equal to one of the constants : '0'
  or '1'. If the variable is already in internal repr, nothing
  is done.

  Please close this feature request, or tell the issues, if
  they are some.


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

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

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


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=295103

  Forgot to mention - this bug report is for version 1.2 of
  widget::dialog. Tcl/Tk 8.4.12 on Windows XP


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

  Checked the logger stuff, thats just an outdated procheck not knowing the new trace syntax.

  As a side node, there is a sak.tcl command in the cvs version of tcllib to run procheck/frink/nagelfar on the tcllib code, so you don't need your own runner.

  sak.tcl validate


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

  spf - bug, fixed
  term - bug, fixed
  grammar_fa/fa_op - bug, fixed
  nns/nns_auto - fixed (a few days ago, without ref to this bug)
  transfer/copyops - ditto
  math/elliptic - ditto
  tiff/tiff - ditto

  Lots of messages are new tcl 8.5 syntax and functions the procheck used did not understand.
  Keeping open for the moment until I can run the last tclchecker over it.

  I like Erik's runner however, as it summarizes in the main output (.out) instead of blowing your mind with thousands of lines of messages.
  I am currently reworking the 'sak validate' code to do the same, like I did for 'sak test run' before.


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

  For 8.4 I have an epxlanation for the error: The [binary scan] 
  in unixtime fails, thus the variable "r" is not set, and thus 
  does not exist later on. More logging shows that there is no 
  data to scan, the field is empty. The reason for that is not yet 
  known.

  I have added code to throw an error if the scan fails.


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

  The 8.3.4 failures are actually tcltest 1.0.2 failures. The 
  variable tcltest::interpreter was added later. The 8.4 was ok, 
  because it had tcltest 2.2.x. Now added code which falls 
  back to ino nameofexec when tcltest::interpreter is not 
  available.

  ... Now the testsuite fails in the same way as for 8.4 (missing 
  data, failed scan).


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

  Ok, what happens is that the [read] which retrieves the time 
  data from the server may not get data on the first read. As the 
  routine is programmed to simply expect that the first read is 
  successful it can run into failure. What bugs me is that the 
  channel is blocking ... It should wait for data and collect it 
  internally until EOF. ... Hm. If I delay the [close] in the fake 
  server things are ok. So this could also involve stuff in the 
  OS, the close coming to fast or what.

  My solution is to
  - append [read] data
  - bail out of the ClientReadEvent as long as the data is not 
  complete (4 byte)

  I.e. finish only after data is completely received.
  That should be robust with a variety of servers.

  Committed the changes.


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


  The variable $::tcltest::tcltest is available from
  bothe tcltest 1 and tcltest 2, and holds the same
  value returned by [tcltest::interpreter] in tcltest 2.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The attached patch uses ButtonRelease instead Button events for multiple select.
  This avoids the issue with multiple drag and drop.

  The patch was tested by Robert Karen.

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

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


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

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

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


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

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


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

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


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

  Done. Disabled the commands only, no removal. May be needed
  in the future for debugging.


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

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

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


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

  from Andreas Kupries:

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

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


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

  Reviewing the patch ...
  The move of the close/unset I understand. Takes the
  fileevent away.
  Unsetting ftp(state.data) I understand as well, after
  reading WaitComplete. It is necessary to prevent this
  command from doing a vwait without having an event source.
  However, why is there a 'read ftp(CtrlSock)' in the patch ?
  The Ctrlsock is already at eof, so this is a no-op.
  The close alone should be enough.


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

  I have now committed the patch without using the 'read
  CtrlSock'. If that causes the head (rev 1.44) to still fail
  with an infinite recursion please re-open this bug.

  Side note: Thank you providing a patch, and for attaching it
  to the report instead of inlining it. Despite this I have a
  small nit. Please use the command 'diff -u' the next time
  you create a patch for us. The '-u' switch causes 'diff' to
  generate a patch in the 'unified' format. This format
  generates larger patches, this however is offset by the fact
  that the result is much easier to understand when read by a
  human. In other words, it makes the reviewing of a patch
  easier for us maintainer. Thank you.


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

  You are right about the no-op.
  I have tested revision 1.44 and it works fine.
  I will use the diff -u in the future.
  Thanks,
  Guy


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  hook: Moved the examples in the hook page to separate lines to avoid the issue.
  doctools: Forced a \n after each .CE to avoid this in future manpages even if they use examples on the same line as text.

  Note: There is a long-standing indentation bug which is also triggered here, even after fixes, where parts of a nested list are out-dented. This is not fixed, it is known, and it is not known how to fix that one.


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

  Proposed new ::ftpd::read solves problem:

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

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


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

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


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

  References
     http://python.sourceforge.net/peps/pep-0282.html
     http://www.red-dove.com/python_logging.html


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

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


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

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


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

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


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

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


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

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

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


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

  Looks like the attachment didn't get there, here are the 
  diffs:

  1065c1065
  <             vwait [subst $token](readable)
  ---
  >             vwait $token
  1144c1144,1147
  <     if {[catch { gets $state(sd) state(line) } result]} {
  ---
  >     if {[eof $state(sd)]} {
  >         set state(readable) -3
  >         set state(error) "premature end-of-file from 
  server"
  >     } elseif {[catch { gets $state(sd) state(line) } 
  result]} {
  1147,1151d1149
  <     } elseif {$result == -1} {
  <         if {[eof $state(sd)]} {
  <             set state(readable) -3
  <             set state(error) "premature end-of-file from 
  server"
  <         }
  1160c1158
  <     if {$state(readable) < 0} {
  ---
  >     if {$state(readable) != 1} {


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

  I got a 'go' by marshall. I don't have
  tcllib 0.6.1 available and therefore
  ask the submitter to generate a patch
  against tcllib 1.2. Please use the
  option "-u" when executing "diff". This
  will generate a "unified diff" which is
  generally easier to read and also easier
  to apply as patch will get some context
  to check against.

  Either attach the patch here or send it
  to me.


login: sjscott
username: sjscott
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=255303

  I've downloaded tcllib-1.2, will generate patch and send it 
  along.
  Thanks


login: 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:
  Fixed as proposed, committed to CVS head. Package version bumped to 1.0.3.
  One issue left: Can you provide us with a small snippet of code which demonstrates the failure ? I would really like to extend the testsuite as well, to catch this in the future.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you for the code.
  What is the input to this code, i.e. the values of salt, password, iterations
  where it fails ?


login: zdia
username: zdia
mimetype: text/plain
icomment:
  >What is the input to this code, i.e. the values of salt, password,iterations
  > where it fails ?

  Gorilla Password is working like this. Salt and the sha256 encoded password are saved in the database with the password.

  Access to the database is granted if  the password taken from a dialog box and encoded with sha256 and the saved salt equals to the db saved password.

  Because the saved 32bit (AS 8.5.8 on Linux) Xi result is not equal to a generated Xi on a 64 bit system (here: Mac Snow Leopard 10.6.2 compiled with 8.5 Tcl/TK Cocoa sources from Daniel Steffens github page) you have no access to the 32bit database.

  Standard iteration is 3000
  SALT is a 256 bit random value
  The password is an integer string like "mypassword"

  After iteration 16 there will be different Xi values.

  Example for the salt:

  pwsafe::int::randomString 15
  proc pwsafe::int::randomString {length} {
      set randomOctets [list]
      
  for {set i 0} {$i < $length} {incr i} {
      lappend randomOctets [expr {127-int(rand()*256.)}]
  }
      }
      return [binary format c* $randomOctets]
  }

  I would be thankful If you could give me a hint on how to check in a script if the system is working on 64bit system

  Regards

  Zbigniew Diaczyszyn


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Nice job finding and fixing this bug, Mark.  Thanks for the patch.  Your fix is integrated into the CVS source tree, and will be included in the next release of the library.

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


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

  Can you tell me which revision of doctools and html backend you are using ? In my version the code not only generates numbered <a name=""> anchors at the command locations, but proper <a href=""> links to them in the Synopsis too.

  Or are you trying to link to specific commands from outside of the manpage, i.e. from other manpages in the same set ?

  That is actually something we know we have trouble with in general. You can link to a complete manpage X from another page Y, by marking up the title of X in Y as a [term], however there is no support at all to directly link to deeper structures, like sections, let alone command definitions.

  There are some extremely rough ideas floating around regarding a TeX like use of 'label' and 'reference' markup, nothing concrete however, and based on your description also not really what you are asking for with regards to commands.

  The links you see are automatically generated purely based on strings ... We might be able to extend the set of terms which can be linked too so that the other commands also refer to the containing manpage ... I have to think about that a bit more ...


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

  I'm using tcllib1.9 (from a couple months ago, IIRC), which I've installed on sourceforge here (directories are executable, should be browsable):

    /home/users/s/sd/sdeasey/local

  But yes, I'm trying to link to a specific command (1 of n) on one page, from another page.

  If you use [cmd ...] it does actually create a link, you don't have to use [term ...]. So the linking machinery is there. The problem is that on the target page the HTML markup looks like this:

  <dt><a name="1"><b class='cmd'>ns_sls set</b> <i class='arg'>key</i> <i class='arg'>value</i></a><dd>

  (from: http://naviserver.sourceforge.net/n/naviserver/files/ns_sls.html )

  The anchor name is "1". The anchor name should be "ns_sls".

  Secondly, which commands are defined in which pages needs to be added to the .idx, .xref or .toc (whichever is most appropriate), as the documentation is being parsed, just like which keywords appear in which pages.

  It seems like most of what's needed is already there. I don't think there needs to be an extra linking mechanism (label, reference), at least, not for this purpose.

  I think it's also important to use the expected string names as anchors, rather than opaque numbers, to allow links to be created from external works, such as wikis. It seems unlikely that there would need to be multiple definitions of a single command on one page, and in such a case, the first one will be linked to.

  I noticed that the linking seems to be case insensitive, at least for terms. This is a problem for commands and C library functions (which are case sensitive anyway). For example, naviserver has the Tcl command ns_log(n) and the library function Ns_Log(3). It would be nice to be able to refer to one from the other.


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

  A workaround is in place in the ldap module, which looks for
  the namespace var storing the nonce count and resetting it,
  before a new attempt. Not perfect but works. If this gets
  fixed in the sasl module, it would be better, but its not a
  showstopper for ldap sasl support.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 242826: bug1545306.patch

  Logged In: YES 
  user_id=202636
  Originator: NO

  You might try the attached patch which moves the nonce count into the context structure. SASL::cleanup will remove it so a new context will begin again at 1.
  To reuse a SASL context as described in the RFC you should call SASL::reset. As the context remembers the original server challenge and now the noncecount it will compose a new auth request as before but with an incremented noncecount and should re-authenticate. This needs confirming -- I don't have an LDAP setup to try against and my SMTPd doesn't do re-authentication.
  File Added: bug1545306.patch


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 194111: installer.tcl

  Logged In: YES 
  user_id=302287

  Diff adding an error dialog attached. Please review.


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

  A quick look seems to be ok, only a nit: [catch {}] == 1 can
  be shortened to [catch {...}] I do not thank that we care
  about break, continue, etc. Will have a closer look when I
  ma home, i.e. patch and look at the whole context.


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

  Accepted with very small changes yesterday, committed this
  morning. The nit, and slighty different formatting.


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

  Logged In: YES 
  user_id=75003

  Enclosed a patch fixing the problem.


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

  No such error for Tcl 8.5 and higher. The reporting of aliases (which setop is in the testsuite) see-sawed a bit in the 8.5 alpha series. In final old behaviour was restored.


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

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


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

  Logged In: YES 
  user_id=80530

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


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

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


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

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

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


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

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


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

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

  sha1 1.0.2 (pure Tcl)

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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


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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

  Logged In: YES 
  user_id=80530

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


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

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


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

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


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

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

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


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

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

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

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

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


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

  It doesn't seem to me to make any difference to the output.
  I tried to create a test for this condition and plumped for
  test mime-9.0 {bug 1254934} {
    list [catch {
       set toka [mime::initialize -canonical text/plain
  -string testing]
       set tokb [mime::initialize -canonical
  application/octet-stream \
             -string [string repeat \0 160]]
       set tok [mime::initialize -canonical multipart/related \
            -parts [list $tok1 $tokb]]
       set r [mime::buildmessage $tok]
       mime::finalize $tok -subordinates -all
       set r
    } res] $res
  } {0 {}}

  Checking the output with and withouth these "\r\n" appended
  makes no difference to the buildmessage output.

  Can we get some sort of test case that shows the problem?


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

  Erland, please provide a test case or example of the bug,
  and how it is fixed by you patch.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  The test case is a bit complicated - it involves setting up
  a web server script (I use PHP) to receive an uploaded file,
  and calculate a checksum which will differ from the sent file.

  The Tcl code is fairly cumbersome to handle HTTP headers and
  what not.

  I need some time to extract the relevant functions from my
  code and construct a nice, minimal test case, maybe with a
  PHP script as the client. I will be revisiting the upload
  part of my project soon, I'll get back to you with the test
  case. 

  Thank you for your attention.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Ok, here is a demonstration of the problem.

  This Tcl program (testMIME.tcl) uploads a file
  (transferFile.txt) to a web server (currently connects to
  one of my servers, I will also post the receiving PHP script
  so you can put it on the server of your choice).

  The program will print the size of the file, and then show
  the response from the web server. In my case I created a
  text file with the word 'Hello'; the Tcl script reported a
  file length of 5, and the HTTP server a file length of 7.

  You will have to create the transferFile.txt.

  I believe my patch fixes this discrepancy.

  FWIW, I wish Tcl's http class had a method for doing this.
  The code in testMIME is taken from examples on the Tcl Wiki.


login: erl
username: erl
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=116933

  Does anyone have the time to look at the testcase (if you
  have a PHP5 web server, then it shouldn't be too hard)?

  As I believe this is a bug in the Tcl MIME handling, that I
  believe I fixed in August, if would be nice if someone could
  take the time to hopefully approve it and get it checked in
  (or comment on any objections).


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

  Running the tet script I see the webserver reporting an
  11-byte 'hello world' as 13 byte. Adding more logging of
  values to the script I find:

  The part generated in 'form-data-add_binary' seems to be ok.
  It has \r\n at the end, this however might be very necessary
  to put the separator line later closing the part on its own
  line.

  However the message then composed from all the parts, in
  'form-data-compose' has an additional \r\n before the
  separator line.

  There seems to be a disagreement between parts and their
  umbrella which of them has to add the \r\n for the separator
  line to the whole message. Now apparently both do it.

  It is unclear if this happens only for encoding binary.
  This has to be tested.

  I wonder if the problem is that the binary part is not
  generated with some 'size' information in the headers.


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

  Cross-reference: See bug report
  http://sourceforge.net/tracker/index.php?func=detail&aid=1213527&group_id=12883&atid=112883


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

  Tried out the patch and have to report that the provided
  patch does NOT solve the problem. The path in question in
  question is actually not used at all by the demo ...

  Now trying to find the code paths actually used.


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

  Note: Whatever we do to buildmessage and helpers we will
  likely have to replicate for copymessage and helpers as
  well. 'build...' is for getting a string, 'copy...
  ' writes directly to a channel. Structurally they should
  work identically.


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

  The command is 'buildmessageaux'. It has a 3-way switch for
  file, strings, and parts. The patch modified the 'file'
  branch. Modifying the 'string' branch provides the desired
  result. Given the structural similarty the fix to the file
  branch is likely right as well, just not used in the example.

  An alternate fix might be to change only the 'parts' branch,
  as that is where the \r\n in fron of the separator line is
  added.

  This depends however on what a plain part would look like,
  outside of a composition. Gut feeling tells me that making
  the change in parts is wrong.


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


  Ah, slogging through the relevant RFC's showed the solution.
  According to RFC 2046 the \r\n before the boundary itself
  belongs to the boundary, not the body, so changing the
  'parts' branch is out. It has to be 'strings' and 'file'.

  I will make a new patch and upload it here.


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

  I have determined how the error is generated.

  In the method "add row" data is set into cells,
  actually into the internal array of the matrix.
  This triggers the trace and via MatTraceOut the
  external array is set too. This then triggers
  the trace we have on that array and MatTraceIn
  is called. This command uses "set cell" to set
  the value into the matrix. But at the time we
  are calling the method we are in the middle of
  "add row" and the internal structures, especially
  the information on how many rows the matrix
  contains, are not uptodate. Because of this the
  *range check* performed by "set cell" fails and
  generates the error message we see, namely that
  the argument to "set cell" are out of bounds.

  My solution would be to disable MatTraceIn when we
  are inside of MatTraceOut. This will take care of
  all situations where this can occur and not only of
  this specific case.


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

  And yes, the "date" vs. "data" thing is a bug,
  one which was already fixed in the CVS head.


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

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


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


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


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


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

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

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

  That will take a bit more time.


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


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

  Very bizar when I change the line to 

      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 1]
  OR !!!! (it does not matter???)
      set peer [fconfigure $ftp(CtrlSock) -peername -blocking 0]

  Both work FAST ??? (Via Solaris tcl_patchLevel  8.4.5)


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

  Questions I believe should be answered in the documentation.

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

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

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

  ----

  Notes for future development.

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

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


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

  I'll deal with the documentation issues.

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

  I guess so.

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

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

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

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


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

  I've checked in a change that allows a type to have a 
  "typeconstructor".  The typeconstructor's body is executed just 
  after the type is defined; all type variables are visible in it.  Thus, 
  it can be used to initialize array-valued type-variables and other 
  resources belonging to the type as a whole.


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

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

  That remains to be done!


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

  Forget to provide background info
  (time) 79 % package require mime
  1.3.2
  (time) 80 % package require smtp
  1.3.2
  (time) 81 % info patchlevel
  8.4.2
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = intel
  tcl_platform(os)        = Windows NT
  tcl_platform(osVersion) = 5.0
  tcl_platform(platform)  = windows
  tcl_platform(user)      = Administrator
  tcl_platform(wordSize)  = 4


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

  Here is the errorInfo
  error writing "sock240": invalid argument
      while executing
  "puts $channel [$converter -mode encode -- $X]"
      ("file" arm line 37)
      invoked from within
  "switch -- $state(value) {
          file {
              set closeP 1
              if {[info exists state(root)]} {
  # FRINK: nocheck
                  vari..."
      (procedure "mime::copymessageaux" line 75)
      invoked from within
  "mime::copymessageaux $token $channel "
      invoked from within
  "mime::copymessage $part $channel"
      ("foreach" body line 3)
      invoked from within
  "foreach part $state(parts) {
                          puts $channel "\n--$boundary"
                          mime::copymessage $part $channel
            ..."
      ("default" arm line 2)
      invoked from within
  "switch -glob -- $state(content) {
                  message/* {
                      puts $channel ""
                      foreach part $state(parts) {
    ..."
      ("parts" arm line 7)
      invoked from within
  "switch -- $state(value) {
          file {
              set closeP 1
              if {[info exists state(root)]} {
  # FRINK: nocheck
                  vari..."
      (procedure "mime::copymessageaux" line 75)
      invoked from within
  "mime::copymessageaux $token $channel "
      invoked from within
  "mime::copymessage $part $state(sd) "
      invoked from within
  "smtp::wtextaux $token $part "
      invoked from within
  "smtp::sendmessage $allparts       -header [list From 
  $FROM]     -header [list To $TO]         -header [list Subject 
  $SUBJ]  -servers mail.earthlink.ne..."
      (procedure "mb" line 20)
      invoked from within
  "mb"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 mb"
  (time) 84 % 


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

  Still encountering this error. 
  Very apparent that the other side is sometimes closing the 
  socket early but why?  I ran it through sockspy and it never 
  failed! Outside of sockspy it fails frequently. The failure point 
  varies but always occurs on "puts $channel ..."

  I would welcome suggestions for further debugging.

  Another wrinkle. When I run the mime entities through a file 
  and reload into separate process the problem is common. If I 
  run smtp::sendmessage in my mine program then I don't see 
  the error.


login: tkmiller3
username: tkmiller3
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1215370

  I have recently encountered this same bug using Tcl 8.4.9 (from 
  ActiveState) sending PDF attachments; package smtp 1.4, mime 1.4.  
  Does anyone have a fix or workaround?  Thanks.


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

  I have, I believe, found the problem, and committed a change
  to the CVS head that should fix it. I am closing this bug
  now (state pending). Just reopen if I am mistaken.

  Here what I wrote into the ChangeLog


  * mime.tcl (::mime::copymessageaux): Removed usage of the
  command
    'unstack'. Its presence is a bug ever since revision 1.3
  (March
    9, 2000) of mime.tcl, when the converters (base64,
    quoted-printable) started to be used in immediate mode
  instead
    of attaching them to the output channel. This also means
  that we
    do not need the fallback implementation anymore either.

    Many thanks to Roy Terry <royterry@earthlink.net> for
  keeping up
    the nagging about [SF Tcllib Bug 754920] which
  demonstrated the
    problem.

    What happened is that the unpaired 'unstack' removes the
  outer
    .-transformation and a second call may close the channel. If
    that happens any further access to the channel errors
  out, and
    the mail server gets and transfers an incomplete mail
  message.
    It is a 'may' and not a 'will' because it seems that
  sometimes
    the channel has a refcount > 0 and then 'unstack' does
    nothing. This part made the reproduction difficult. It was
    originally suspected to be a problem in Trf itself, but is
    actually a problem in how it is used by mime.


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

  This is already fixed in the CVS Head.

  2005-11-03  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in
    his patch for [SF Tcllib Bug 1276561], see 2005-10-04 entry.

    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0. 
    * (parsedatetime): For month index, use "%m" + scan
  instead of
      wrong "%e".


login: clmcavaney
username: clmcavaney
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1425189

  Apologies - should have checked the CVS version first.
  Thanks for the rapid response though.


login: 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: ferrieux
username: ferrieux
mimetype: text/plain
icomment:
  Why stop halfway ? Comments and settings line would benefit from the same tolerance.
  The simpler patch below does that.

  --- ini.tcl~2013-05-02 18:24:50.000000000 +0200
  +++ ini.tcl2013-05-02 18:25:24.000000000 +0200
  @@ -113,6 +113,7 @@
       seek $channel 0 start
   
       foreach line [split [read $channel] "\n"] {
  +set line [string trim $line]
   if { [string match "$char*" $line] } {
       lappend com [string trim [string range $line [string length $char] end]]
   } elseif { [string match {\[*\]} $line] } {


login: ferrieux
username: ferrieux
mimetype: text/plain
icomment:
  For the record, I know how Stupid SF eats any indentation, which makes any inlined patch nearly unusable, but the same Stupid SF won't allow me to attach anything...


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

  May I see the error message generated when you try
  to use the commands ?

  Both "lb" and "rb" are commands implemented in the
  textutil::expander package itself, simply returning
  [ and ]. The formats do not have to implement them
  by themselves.


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

  The message was something like "lb" not being available in
  this context. I will have to look up the exact message later
  on, but I was surprised by the text, it did include
  something to this effect.


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

  This is the exact message:
  ::mp cget: lb doesn't exist in this context
      while executing
  "::mp expand $text"
      (procedure "passes" line 8)
      invoked from within
  "passes"
      (procedure "main" line 6)
      invoked from within
  "main"
      (file "d:\tcl83\lib\tcllib1.2\doctools\mpexpand" line 
  286)


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

  Confirmed while reintegrating the new calculus
  code. This could take a bit longer. The HTML,
  TMML, and LaTeX formats do not complain. So
  there is a fundamental difference between these
  and NROFF.


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

  The message is a bit weird. It means that the 
  method 'cget'  was used to query the value of
  the variable 'lb'. The [lb] command (method Op_lb)
  uses the internal command 'Get' to query the
  variable, which does not! generate this message.

  I'll try to track where this is called.


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

  Ok, I know why the message is showing up, but not yet where 
  in NROFF this is caused. The problem is one of stacking 
  contexts. The expander pushes a context when invoked, 
  stores the chosen bracket information and restores the 
  outer brackets after the expansion. At last the context is 
  popped. These brackets have nothing directly to do with 
  [lb] [rb] commands as far as I can tell, we are talking 
  about storing/restoring the information used by the 
  expander to determine where macros start and end.

  In the case of nroff another context (mp) is pushed, but 
  never popped, causing the expander to access a context 
  which does not contain the lb/rb variables when trying to 
  restore the information of the outer invocation. So the
  problem is in the nroff format, but not in the [lb] command.

  The error message is simply misleading. See new tracker 
  item "[530056] Misleading error message in expander".


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

  The overall cause is that the doctools 
  command "manpage_end" is not used to
  close the manpage "calculus.man".

  I will now close this item as "invalid" as the
  problem is the manpage, and not doctools. See
  FR "[530059] Stricter check of incoming manpages"
  for a followup requesting better checks of the
  manpage structure and better error messages.


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

  What did the famous poet say? For want of a nail a shoe was
  lost ...
  Hm, I will add the finishing clause!


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

  Idea: Generate the list of modules and descriptions from the 
  other .man pages. Should be easy. Use a special formatter to 
  extract the relevant information as tcl code, then run this 
  code to create the overall manpage.


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

  There is no need for this anymore. The doctools processor in 
  the tclapps module of the tcllib project is able to do just what 
  I proposed. Generation of a table of contents, and a keyword 
  index directly from the .man pages.

  Closing.


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: 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: rftghost
username: rftghost
mimetype: text/plain
icomment:
  File Added - 223524: dexec.tcl.diff

  Logged In: YES 
  user_id=1759969
  Originator: YES

  File Added: dexec.tcl.diff


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

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


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

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


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 266166: Registry

  Logged In: YES 
  user_id=302287
  Originator: YES

  Running it the first time succeeds, but does not add the shell, but it appears in the Registry file inside the home. Attached the Registry file.

  File Added: Registry


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

  Hm. The stacktrace seems to indicate that this is trouble in the 'tie' package, used within a sub-interpreter. This may be Tcl 8.5 specific too. May I ask to test this using a tclsh84 to get an additional datapoint?


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

  Running with tclsh8.4 to add tclsh8.5 fails like below, but i can add a 8.4 tclkit without problem. Trying to add with tclsh85 to run sak.tcl fails also, when adding 8.5, but not with 8.4.

  Trying to run 'sak.tcl test shells' gives the same stack trace with both 8.4 and 8.5 running the script.


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

  Hm. If you Linux, what about that platform?
  Well, that one I can test myself.


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

  Another point:
  It also fails on Solaris DevExpress (Opensolaris basically), Tcl 8.5 from cvs, tcllib head.


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

  Fixed. Duplicate of [1897850]. Do not try to use a command you have just deleted from the sub interpreter to make it safe.


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

  This has been addressed in CVS 1.23 of ftpd.tcl to the
  extent possible (binary files are encoded as binary).


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

  Ah, thanks for catching that one - I should set up a small test file to at least exercise all of these 
  procedures. Just committed a new version.


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

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


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

  Accepted the patch, committed to CVS head.

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

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


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



  File Added - 261269: tdist.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

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


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

  Logged In: YES 
  user_id=816411
  Originator: YES

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Accepted, commited in cvs.

  Koen, do you have any insight of purpose the -managed option of ScrolledWindow ?
  Could you write a text for the man page ?

  Thank you,
  Harald


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  As found in the ChangeLog:
          -managed option: if true, scrollbar are managed during creation,
          so their size are included in the requested size of the
          ScrolledWindow.  If false, they are not.


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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Problem confirmed. Aslo confirmed that it does not appear for Tcl 8.5.
  First hypothesis that the ensemblification of the "namespace" command in8.6 may play a role.

  hephaistos:(506) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.5/Install/bin/tclsh8.5
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  0

  hephaistos:(507) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.6/Install/bin/tclsh8.6
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  1

  Side note for the curious.

      ./sak.tcl validate

  does not run the per-package testsuites per se, that is done by

      ./sak.tcl test run


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hah. The problem is the line immediately before, the 'namespace delete ::tcl'.
  In 8.6, with namespace ensemblified the implementations of the namespace methods are in that name, and deleted. At which point the namespace command is broken and gone.

  I think, I should not kill the ::tcl namespace in 8.6. It has started to contain necessary commands.


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

  Fixed.
  Committed: https://core.tcl.tk/tcllib/info/367195678d
  Pushed.

  Thank you for the report.


login: 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: cleverly
username: cleverly
mimetype: text/plain
icomment:
  File Added - 56581: list.tcl.patch

  Logged In: YES 
  user_id=22080

  I have a patch to both list.tcl (code) and struct_list.man
  (documentation).


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

  The requested feature is 'set intersection' ... Instead of 
  adding this under list I would rather add a whole section for 
  set operations, and then a number of them.


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

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


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

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

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


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


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

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

  #! /usr/bin/wish
  package require BWidget

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

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

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

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


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

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


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

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


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

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

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

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

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


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

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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed. While a bit thin in the description itself the test script allowed me to track this down. The issue was an intermediate value leaving the int32 range when this script is run by Tcl 8.5 and higher. While there was already code limiting such values to int32 not everything was caught.
  Package version bumped to 1.0.2.


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

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

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

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

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

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


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

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


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

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

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

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

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


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

  Mistake - Quite likely. So you have code like

      [subsection FOO intro.history.ancient]

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

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

  ? (The second would be the LaTeX approach).

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

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

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

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

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

  Will do some more thinking.

  Thanks for the comment.


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

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

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

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


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

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


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

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

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

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


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

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


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

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


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

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


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

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

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


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

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

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


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

  I cannot confirm this as a bug on win2k. I'm attaching the
  test server script I ran on using Tcl 8.3.4 on windows 2000.
  I then used the MS command line ftp client to get test.file.
  The file transfer was successful.

  Please try using this example script and see if there is
  still a problem. As this is an anonymous bug - if I don't
  get any feedback within a week or so then I'll consider this
  bug closed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ah, the well-known problem of octal processing in Tcl. 0* is trated as octal, and 08 (09) are out of the proper range for that treatment.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Patch with fix attached.
  Review showed no other place where this is an issue (for month information).
  Unclear yet if days (i.e. 08, 09 in each month) have a similar issue.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. Which version of the calendar widget is this ?

  I tried to reproduce using widget::calendar 1.0 in the CVS head, without my patch, and I did not have the problem. It might be that this already fixed in the CVS head, just not yet in any tklib release ...

  Reviewing the ChangeLog the answer is yes, this got fixed in the CVS
  (about 7 months after the 0.5 release).

  2009-08-17  Jeff Hobbs  <jeffh@ActiveState.com>

  * calendar.tcl: correct leading 0-month issues.
  Make 8.4-friendly by not needing clock scan -format.
  * pkgIndex.tcl: bump calendar to v0.91


login: klu
username: klu
mimetype: text/plain
icomment:
  well,
  http://www.tcl.tk/  links  tklib, version 0.5  to  http://sourceforge.net/projects/tcllib/files/tklib/0.5/ .

  Download this version  tklib 0.5  (2009-01-27)  installs   widget_calendar   Version 0.9 .

  I took your suggestion and installed all widget -files from cvs -Repository, currently the scripts working fine and no error occurred - Thank you very much!

  Maybe, there is time -in the future- to make a bugfix-Release of tklib - Version 0.51 ;)  ?
  kind regards
  Bernd


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok, so definitely a version from before the fix. Glad to hear the CVS is working.
  Yes, we should make a new release of tklib.
  (Side note: I usually use ActiveTcl, and then update individual packages from the teapot, so I usually have near-current packages around. Disclosure: I am a maintainer of ActiveTcl for ActiveState).


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

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


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

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

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

  The server's features are:

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

  Sender and recipient are Ok-ed, then:

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

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

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


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

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

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

  There was for example a bug (827436


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

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

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

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

  Thanks!


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

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


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

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

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

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

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

  Yours,

        -mi


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  this is a property inherited from a frame.
  If you replace the top by a frame, you have the same behaviour.
  If you want to reset the frame size, use
  $f configure -width 1 -height 1

  It might be correct that the observed behaviour is not the desired, but it should be modified within tcl, not Bwidgets.


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

  This is DIGEST-MD5::client ... switch branch 1 ...
  CreateNonce not coming back ... Ah, reading from dev/random
  ... Checking ... /dev/random is readable, opened, reading 16
  bytes then hangs. My guess is that the machine has not
  enough randomness and is waiting for it accumulate.

  What now. In a way the report is invalid, as the testsuite
  hangs not on its own, but because of something in the
  environment. 

  Interesting, for machines without /dev/random, i.e. Win*,
  something based on clock, pid, and Tcl rand() is used.

  Oh, it is worse. The subprocesses not only hang, they cannot
  be killed anymore. Not even kill -KILL works :(


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

  It seems we should read from /dev/urandom to avoid blocking.
  Modified to use this source.


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


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

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

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

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


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

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


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

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


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

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

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

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

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


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

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

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

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

  Thanks for the effort!


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

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

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

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


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

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

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

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


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

  Fix committed to cvs head. Version bumped to 0.2.4.

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug and reason confirmed.

  Proposed solution:
  Check password widget if state disable, confirm if so, otherwise change focus

  This is in cvs now.

  Test cases:

  PasswdDlg .p -passwdstate disabled
  PasswdDlg .p


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9753: 440051.diff

  Logged In: YES 
  user_id=75003

  The reference is #440046.
  Added patch fixing the problem.


login: glennjnn
username: glennjnn
mimetype: text/plain
icomment:
  File Added - 184182: bwidget.diff.txt

  Logged In: YES 
  user_id=152318

  that diff has lost its indent.  Let me attach a file...


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

  Here you go:

  package require Tk
  package require BWidget

  proc do_write {} { BWidget::write [file join $::env(HOME) bwidget.out] }

  Button .b1 -text "launch BWidget::write" -command do_write
  Button .b2 -text Exit -command exit
  pack .b1 .b2 -side top


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

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


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

  A question, how are you running ispell ? From an editor, or batch mode like from a terminal. If the latter, what is the invokation ? Also, are you using special options to make sure that you get american-english, vs british-english, etc. ?

  (Background: I am thinkingabout how useful it would be to run ispell from sak.tcl, maybe with a special dictionary to accept tcl commands and doctools stuff, and then we can run it over all files, code (for comments), and documentation).


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

  I just run it from the command line , using either
  ispell
  or, if checking html, using
  ispell -h

  I've thought about creating a tcl specific spelling dictionary, but haven't messed with it recently.


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

  Accepted with slight changes. In CVS head, package version now is 0.3.5.

  Changes:
  Used hex tag 8825 for comparison, instead of name 'GPSInfo', like for the other special blocks. Moved the handling before the tag -> name conversion.
  Replaced the 'eval "if ..."' contortion and quoting hell with, roughly

      upvar 0 $use_tags thetags
      if {[info exists thetags($tag)]|} ...

  No eval required, no quoting hell.


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

  Quick followup: the [tabifyLine] and [untabifyLine]
  procedures also look useful; could these be added to the
  public API?

  Also: I have write permission on the repository so I can
  commit the patch from here if you like.


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

  Applied to head. Re-indented.
  Package version bumped to 0.7
  Updated documentation.


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

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

  Fixed, and committed to head.


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

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

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

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

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

  How would this work for you?


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

  This should use -showtext (all lowercase) and needs an 
  option for the progressbar -font to handle progressbars of 
  various sizes (now always uses default canvas font ... which 
  may not be desired).


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Hmmmm.  Yeah, that's a bug.  Practically speaking, "from" should:

  1. Only look at even indices.
  2. Remove *all* instances of an option, if there's more than one.
  3. Return the value for the final instance.

  And then, of course, the documentation needs to reflect this.  OK, Andreas,
  you're batting 1000 on this one.


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

  I see that if I configure the background color of the notebook, 
  it does all go to that color.  -tabbackground would be another 
  option, but an incompatible one to users who use -
  background to color their widget.


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

  As far as I am aware "stats" is deprecated.
  Assigned to Brent for verification.

  A first step would be to remove the deprecated module
  from the installation commands in the makefile.

  A second step would be to remove the files and add a README
  refering the user to the other module. Or to remove the 
  directory completely. The SF cvs supports this.


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

  I don't think it's necessary to be quite so cautious with
  the deprecation and
  removal of the module.  Tcllib only just hit v1.0; I don't
  think we need to have quite the same rigorous procedures
  that the tcl core follows.  Just
  delete the deprecated module.  If you want to, add a
  "package ifneeded stats ..." to counter's pkgIndex.tcl, and
  maybe have it print out a warning
  on stderr that it's actually loading counter.  Let's try to
  keep tcllib nimble
  while we can.

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc.


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

  Perhaps a compatibility tool could be made available in a
  seperate directory.  If someone needed the stat they could
  install it and references to stat would create aliases to
  the counter classes.


login: welch
username: welch
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=89720

  We should delete stats.
  When I changed it from "stats" to "counter" I left the old
  module in
  for a transition period, but that has long since expired. 
  There are
  no current releases of TclHttpd that depend on stats
  anymore.


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

  It seems that tclhhtpd is composed out of several packages 
  including one for the core protocol handling. This is just 
  not documented.


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

  Yes, 'yaml' would be more in line with Tcllib conventions.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Deleted - 275878: 

  Logged In: YES 
  user_id=2072360
  Originator: YES

  OK.
  Renamed the name.
  File Added: yaml-0.1.0.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Deleted - 275954: 



  File Added - 277357: yaml-0.2.0.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  wrote a manual.
  reimplemented the parser.
  File Added: yaml-0.2.0.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Deleted - 277357: 



  File Added - 277751: yaml-0.2.1.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  - add timestamp / integer parsing.
  - improved a manual.

  File Added: yaml-0.2.1.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 278109: yaml-0.2.2.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  - begin to implement tag treatment
  - add !!float / !!binary(base64) parsing.
  - merge mapping "<<"

  File Added: yaml-0.2.2.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  Although I consider to implement for processing yaml-tag, it cannot just be going to decide the specification.
  Thereby, a function is offered.
  By registering procedure which the user created, a class can be built from the data described to YAML, or Tk widget can be assembled now.

  - !tcl!widget/scrollbar
    path: $f.textpane.f.yscroll
    orient: vertical
    command: >
      [list $text_secondary yview]
  - !tcl!widget/text
    path: $f.textpane.f.fulltext_secondary
    font: FixedFont
    bd:   0
    wrap: none
    state: disabled
    bind:
      - >
        <1> [list focus %W]
      - >
        <Enter> [list RamDebugger::SecondaryTextHelp begin]
      - >
        <Alt-Left> "RamDebugger::GotoPreviusNextInWinList prev ; break"
    as: text_secondary
  - !tcl!widget/grid
    widgets:
      - $text_secondary
      - $f.textpane.f.yscroll
    sticky: nsew
    columnconfigure: 0 -weight 1
    rowconfigure: 0 -weight 1


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

  yaml 0.2.2 has been added to the CVS head of Tcllib.
  kanryu6 has been added as developer to the Tcllib project.
  The latter means that kanryu6 now has full access to the tcllib cvs repository.
  Future changes to yaml can be committed directly.
  A category 'yaml' was added to the trackers for bugs, patches, and feature requests.
  New entries using that category are auto-assigned to kanryu6.


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

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


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  I'am not sure that the result is improved.
  Suppose that the tcl precision is set to the max and 
  you still get "not so nice" numbers :

  set ::tcl_precision 17
  catch {Plotchart::determineScale 0.99999999999999711  1.0000000000000007} errmsg ; set errmsg
  determineScale : xmin = 0.99999999999999711 xmax = 1.0000000000000007
  shift = 3.5527136788004986e-015
  re = 1e-008
  expon = -8
  factor = 1e-008
  step = 0.2
  xmin = 0.99999999499999714
  0.99999999400000006 1.0000000060000001 2.0000000000000001e-009

  So my fix seems to be unefficient here and I don't exactly 
  what to do...


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I have seen a related behaviour (Tcl 8.5) with the labels on the axis:
  An axis with the labels 0.0 0.2 ... 1.0 also gives a label like 0.6000000001.

  We will have to investigate this - certainly a runtime error is unacceptable.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I thought I could fix this easily with the wide() function and restricting the
  range. That was not as easy as it looks. But I think I have a solution: make
  sure that there is a reasonable range - that is: abs(xmax-xmin) should not 
  be smaller than 1.0e-10*abs(xmax+xmin), say. So: first check that. If it 
  fails, recompute xmin and xmax (you forgot the patch for scaling.tcl, but 
  that does not matter).

  Allowing even smaller ranges is not wise: the precision of the numbers will
  come into play!


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

  report no longer valid.

  FAQs moved from the tcllib
  project to the tcl project, it seems.


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

  The FAQ is now in thc Tcl project. closing as outdated. Don 
  created a new report there.


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

  I could not reproduce the bug : I ran the testsuite successfully
  My environment is ActiveTcl 8.5a3 and Tclkit85a2 on WinME.

  Please, could you grab the latest 'bigfloat.test' from CVS
  and make a more precise bug report.
  Could you also give a short description of your environment.
  But the best thing would be to isolate *one* command that
  failes in your environment.

  Regards,
  Stéphane Arnold


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


  Thanks for the renumbering.

  The failing tests are 2.6c and
  2.6e.

  This is with the latest HEAD
  of Tcl development sources, 8.5a4.


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

  I found the reason : it is a bit strange, but
  in Tcl 8.5a3 :
    expr round(0.5) gives 1 and
    expr round(-0.5) gives -1
  and in Tcl HEAD 8.5a4 both expressions return 0.

  Should we close this bug report and submit one in Tcl.sf.net?


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


  the change in Tcl 8.5a4 is likely
  an intentional change away from
  the (arguably buggy) biased
  rounding rule "0.5 rounds to the
  integer with greater magnitude"
  to the unbiased rule "0.5 rounds
  to the even integer".

  A bug report should still be opened
  on the topic, so it's clear that there
  are at least test scripts that do care
  about the change.  You should also
  review just what it is you are trying
  to test and whether it can be done
  in a manner not sensitive to this
  fine detail of Tcl's rounding rule.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  After taking a break from it, I managed to make a tarball where the difference shows up (see attached file).

  The tar package sees the second file as having the name
  aaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbtcllib/modules/tar/pkgIndex.tcl
  but a command-line tar sees it as having the name
  aaaaa/bbbbaaaaa/bbbbaaaaa/bbbba/aaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbaaaaa/bbbbtcllib/modules/tar/pkgIndex.tcl
  which is different in the fourth path component.


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

  As for the errors in BWidget I was unable to recreate.  Is
  there an example script available?

  As for the BWidget demo I was able to recreate and then fix.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Andreas,
  thank you for the report and fix. It looks good and is in cvs now.

  I wouldn't mind to have an example which shows the issue (I am to lazy to make one).


login: dlittau
username: dlittau
mimetype: text/plain
icomment:
  I was the one who sent this Bug to ActiveState. I took the patch code and tested it in my system. Seems to work. The error I reported no longer exists. 


login: dlittau
username: dlittau
mimetype: text/plain
icomment:
  oehhar, do you know in which release this fix will be included? Is there an upcoming release of the BWidget library? I am going to take your patch and include it in my source code (overwrite the BWidget 1.8 tree::itemconfigure method with the new patched) so that my code will function. Just wondering when this patch will be included into an official release.  


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Dlittau,
  thank you for the report and the test. That is good news.
  I plan a bugfix release in december (see wiki.tcl.tk/bwidget)


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

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


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

  Logged In: YES 
  user_id=370749

  Hi,

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

  Kind regards,

  Jos.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Example from a Makefile

  PT=pt

   parser : xls-parser.peg
          $(PT) generate snit -class xls-parser  -name xls-parser xls-parser.tcl peg xls-parser.peg
          sed -e s/PACKAGE/xls-parser/ < xls-parser.tcl > tmp
          mv tmp xls-parser.tcl


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  It partially a documentation problem, and partially a bug in pt::pgen.

  The bug: documentation promises that -class serves double-duty as package name, and the code doesn't implement that.

  The doc problem: There is an option -package to explicitly set the package name, should it be different from the class name, and this option is not documented.

  Continuing...


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

  Fixed in CVS. -package documented. Cross-initialization of -package from -class implemented, and vice versa. Documented the vice versa as well.


login: lingnau
username: lingnau
mimetype: text/plain
icomment:
  File Added - 27788: ixus.patch

  Logged In: YES 
  user_id=65359

  Oops -- seems I forgot to check the »Upload« box or
  something. Sorry about the hassle.


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

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


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

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

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

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

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

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

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


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

  Okay, it looks like the problem is in fact that the Touch
  proc is trying to update the modification of the hpupdate.ts
  file by opening it for write, writing out a null string,
  then closing it.  If these three lines in Touch are replaced
  by 

          file mtime $filename [clock seconds]

  that part of the script appears to work.

  There are other problems which I have documented elsewhere.


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

  Fixed by checking the version of Tcl and providing a 
  different implementation for 8.4 or greater. No 
  unconditional replacement so that the example will still 
  work with older versions of the core.


login: egavilan
username: egavilan
mimetype: text/plain
icomment:
  File Added - 268927: pop3.man.diff

  Logged In: YES 
  user_id=1852298
  Originator: YES

  Adding a tentative pop3.man patch to document the new -tls option
  File Added: pop3.man.diff


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

  Question: IIRC I have read somewhere that this patch was used to access gogle's gmail. Is that right? Can't seem to remember anymore where I read that.


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

  Another piece of code for the same/similar functionality is at http://wiki.tcl.tk/13352, by mic42.

  And egavilan confirms on the Tcler's chat:

  [09:17]emilianoand the response is yes: it's used to access gmail pops


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

  Committed a patch which takes care of the problem. for
  non-native filesystems we simply do not look at device/inode
  anymore to prevent circles. We simply assume that the
  concrete vFS do not support links.
  For now this is true.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I can confirm this with the picture produced by the following script:

  # chkcubic.tcl --
  #     Check the cubic interpolation method
  #

  package require Tk
  package require math::interpolate
  package require Plotchart

  pack [canvas .c -width 400 -height 500]
  set p [::Plotchart::createXYPlot .c {1 10 1} {0 25 5}]

  set interpol [::math::interpolate::prepare-cubic-splines {1 2 3 4 5} {1 4 9 16 25}]

  for {set x 1.0} {$x <= 5.0} {set x [expr {$x + 0.1}]} {
      set y [::math::interpolate::interp-cubic-splines $interpol $x]

      $p plot data $x $y
  }

  There are clear jumps around x=3 and indications of a jump at x=4.
  Extending the sequence of data points does not show any more pronounced jumps
  and the jumps seem to be independent of the number of data points.

  Clearly this must be checked


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

  Solved! A subtle error in the determination of the B-coefficient. Increased version to 1.0.3


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

  What do you mean exactly? I get:
  $ tclsh stooop.test
  stooop.test: Total 103 Passed 103 Skipped 0 Failed 0


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

  I got 

  Module:stooop
  modules/stooop/stooop.test
  env array elements created:STOOOPCHECKOBJECTS

  But now I see that this must be part of the tcllib test
  harness.  My mistake.


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

  The fault is that [encoding convertto unicode $str] produces
  different byte-order output on sparc and intel. NTLM
  requires little-endian unicode strings.
  Fixed by byte-swapping on big-endian systems.


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

  This is confirmed when doing a syntax check with tclchecker of Tcl Dev Kit

  andreask@gila:~/workbench/tcllib-head/tcllib> echo;./sak.tcl validate syntax -v modules/yaml/|grep WARN|grep warnDoubleDash

  @@ WARN  yaml.tcl: 198 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 273 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 397 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 453 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 481 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 526 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 605 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 644 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 718 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 744 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 782 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 790 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 831 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 911 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch
  @@ WARN  yaml.tcl: 940 (warnDoubleDash) Use -- before this computed word to prevent its possible misinterpretation as switch


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: NO

  modified these "switch"es.

  And syntax checked with frink and nagelfar.
  Almost all syntax holls are maybe modified.
  But I don't have tclchecker.(within Tcl Dev Kit?)
  So not checked with it. sorry.


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

  Joe, can you take a look at this as the creator of the online 
  documentation ? Or is that something which has to be done 
  in the .man file for stooop ? Or both ?

  I see that the manpage has just [uri stooop.html] at the end. 
  Maybe some else is needed to get a reference to the full 
  docs. ... The filename is correct, the HTML document coming 
  with stooop has that name. We have to copy it online, give it 
  a different name, and refer to it form the manpage using that 
  changed name.


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

  It looks like there are three separately-maintained
  documents in the stooop module: stooop.n (nroff source),
  stooop.man (doctools source), and stooop.html (full manual).

  stooop.n looks like it has the same content as stooop.man
  (haven't checked carefully); stooop.html is a much more
  detailed manual.

  Since doctools will generate *.html and *.n from *.man, I
  would recommend: (1) removing stooop.n from the repository
  (after merging changes, if any, back into stooop.man), (2)
  renaming stooop.html to something else (say stooopman.html),
  and (3) changing the link in stooop.man to point to
  stooopman.html.  I'll arrange to upload the full manual to
  tcllib.sf.net/doc/ and keep it in sync with CVS.

  BTW, The doctools [uri] element should probably only be used
  for full URLs, not relative ones (Andreas?).  Maybe
  something like:

   [section EXAMPLES]
   [para]
   Please see the full HTML documentation in stooopman.html, or at
   [uri http://tcllib.sourceforge.net/doc/stooopman.html].


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

  Renamed 'stooop.html' to 'stooop_man.html' and updated the 
  doctools manpage. I did not deprecate the .n file yet.

  The problem with full urls is of course that it ties the 
  documentation to a particular location. This is bad for self-
  contained documentation packages (like for example 
  Windows CHM files - I am thinking of the ActiveTcl 
  documentation here).


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:
  Yes. They are out of order.

  The fact that this always failed however had no influence on the result. It simply defered to [IPv4?] and that did the right thing.

  It seems that this was some attempt at a speed optimization, with [IPv4?] defering to the (presumably) expensive [Normalize4] and catching its ok/error.

  We can either drop thisd check entirely, or maybe make it a part of IPv4?, suitable corrected.
  I am currently leaning towards the latter.


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

  Accepted into CVS head, with modifications. (Put the common checking code into a procedure, calling it at all the modified places).


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

  Oh, oh, the profiler is using clock internally, and in 8.5
  they are procedures and thus show up in the trace. Hm. I am
  not sure if we can exclude them, as they may _also_ come in
  due to the profiled code.

  So maybe just using a version dependent test result to fix
  this ?


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


  simplest thing would be a more
  forgiving match like -match glob
  or -match regexp.


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

  Duplicated the test. Original constrained to 8.4-, new
  variant for 8.5+ with changed result. Committed.


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

  Bah. Nothing weird about it. It is essentially just a debug command left active in the math-12.1 test case.
  Committed: http://core.tcl.tk/tcllib/info/77088c0306
  Pushed.


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

  nyademo, do you have a png file with which we can demo the problem and fix ? I am currently extending the testsuite to show problem and fix, and found that the 2 images which have comments we have here are not triggering the problem. Therefore unsuitable for testing.


login: nyademo
username: nyademo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=932722
  Originator: YES

  Hi.
  I had to write my environment first, sorry.
  It seems to me that the problem is not exists on the png file.
  It is on my japanese environment. cp932 is default encoding 
  on windows. Maybe other languages have their own default encodings...
  It is a reason what output endoding must be binary.

  encoding system cp932
  png::removeComments $file

  This code may enable you to find the bug.


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

  Updated testsuite now too. Won't fail for bug on unix, but does on win32, which is good enough for me. No need to fiddle with the system encoding.


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

  I'm revoking this patch in favour of a new one because the
  CVS source has been changed which this has been here in such
  a way as to cause a conflict. The patch is merged into my
  HTTP redirect following patch.


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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, Andreas, for the hint.
  The CVS starter crew on this side of the ocean was propably not aware of this possibility...


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

  I used a slightly different fix that will accept normal or 
  enabled (actually only worries if "disabled" is passed 
  in).  This is in 1.3.1.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13229: 481023.diff

  Logged In: YES 
  user_id=75003

  Attaching an implementation of the FR as unified diff 
  agaisnt the current code/behaviour.


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

  Should be fixed now (mpformats/fmt.tmml revision 1.12).

  However, I don't think 'make doc' should be invoking 'make
  tmml-doc' in the first place: at present, most users won't
  be able to do anything useful with the TMML renditions, and
  those that do want them can easily build it themselves.


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

  Better use the official IANA list at:
  http://www.iana.org/assignments/uri-schemes


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

  In the dns module I've implemented the dns scheme as a uri
  module extension. Therefore:

  package require dns
  dns::split dns://nameserver.here.bogus/remote.host.com?type=MX

  can do the expected thing. I followed the internet draft for
  this (draft-josefsson-dns-url).


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

  The two supplied examples appear the same, but perhaps the 
  user meant to type something else in.  I also don't see an 
  attached patch.  This needs to be better defined to be 
  fixed.


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

  Enclosed a new patch which corrects two problems:

  - Reset of textcmd to "" is now possible.
  - Code checking for the textcmd made more robust
    against odd macro names (like '5')


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

  With the possible exception of instance creation, this has been 
  implemented in Snit V0.95.


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

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


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

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


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

  This can be a bug. The code we inherited is so convoluted 
  that it is difficult to say. 

  I was thinking that this could also be a DNS resolution 
  problem as the DNS resolver will also wait quite long for a 
  responses, uninteruptible, however I see that you are using 
  an explicit IP address.

  You can activate more verbose logging, maybe this will give 
  us some hints. From the docs:

  The output of the package is controlled by two state 
  variables, ::ftp::VERBOSE and ::ftp::DEBUG. 
  Setting ::ftp::VERBOSE to "1" forces the package to show all 
  responses from a remote server. The default value is "0". 
  Setting ::ftp::DEBUG to "1" enables debugging and forces the 
  package to show all return codes, states, state changes 
  and "real" ftp commands. The default value is "0".


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

  Note that the current internal architecture of
  mpexpand (with its two slave interps) was chosen
  to expressly allow the definition and usage of
  [proc]s inside of doctools manpages without
  disturbing neither the high-level control in
  mpexpand nor the loaded formatting engine. The
  procecedures may use only the declared doctools
  commands and also have limited access to the
  expander object itself (so that they can push/pop
  contexts etc). With this it is possible to create
  higher-level constructs which capture more complex
  documentation structures without giving up the
  separation between structure and visual appearance.

  If wanted I can provide alpha code for a tcllib
  module handling the FIG vector format where one
  of its doctools manpages actually sources part
  of the module and thus extracts documentation
  directly out of the code itself.


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

  Joe, I believe that this can be handled as
  described below, i.e. with a [proc] in the
  manpage, or better, by defining a subpackage
  of doctools which can be required by manpages
  which want to use this highlevel construct.

  IMHO this will give Bryan what he wants without
  having to extend the language or having to add
  a macro facility.


login: boakley
username: boakley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=249075

  I don't quite understand this. In the feature request for 
  the "macro" macro it was argued that allowing one to code 
  macros within a document was a Bad Thing. And yet this 
  discussion explicitly encourages it (via proc rather than 
  macro, but that's splitting a fine hair).

  I guess having a subpackage with the behavior would work, 
  but I don't see the point. What's the argument against 
  adding this feature to the toplevel doctools package?

  I guess my biggest concern is that someone down the line 
  might change the format of a definition list. Maybe add 
  blank lines between the list items, or add a bullet or 
  different coloring. That change will affect this sort of 
  markup when (arguably) it shouldn't. After all, this isn't 
  quite a bona fide definition list, IMHO. It's a specific, 
  unique construct that's been in tk man pages probably since 
  day one.

  What about instead of calling this a tk-specific feature we 
  add another type of list -- compact (eg: [list begin 
  compact]). This type would guarantee that each line is a 
  single physical line with no blank lines between items.


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

  Actually the hair is not that fine.

  The macro facility you would like to have
  places styles information (= translation
  of data into the output format, like HTML)
  into the manpage.

  Defining proc's in a manpage OTOH allows
  you to write format independent macros
  by using the doctools commands inside of
  the proc.

  I have to admit that I cannot prevent you
  from directly generating HTML statements,
  etc. but this is strongly discouraged. This
  is luckily also difficult to get right because
  the interpreter running the code for the
  manpage does _not_ know to which formatting
  engine it is currently connected to. IOW you
  don't know whether to generate HTML or NROFF
  in your proc.

  Node aside: Please attach the hacked fmt.html
  to this item. I would like to see if I can
  rewrite this using just doctools commands.


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

  After some out-of-band discussion by email we (Bryan,
  Joe and I) have come to the conclusion (at least I
  believe so) that this or a similar command should be
  added to doctolls, as part of the special option lists
  provided by TMML. This will bring doctools one step
  nearer to TMML.


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

  Ok, all the formats are now done and committed.
  Documentation is uptodate too.


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

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


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

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


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


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

  What's intended by these tests?


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

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


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


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

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


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

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


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

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


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

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


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

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

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

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

  MAIL FROM:<>

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

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

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

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

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

  # put the ENTIRE message into $mimeT

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

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


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

  George@Orwellian.Org replies...

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

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

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

  Then I tried:

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

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

  Failure to replicate.

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


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

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

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

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

  /mtr

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


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

  Logged In: YES 
  user_id=24077

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

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

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

  i don't understand the question...

  to answer your two most important questions:

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

  2. to get the behavior you want, try:

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


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

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


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

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


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


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

  I am a bit confused reading this FR.

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

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

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

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


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

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

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


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

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

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

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

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


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

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

  Thanks.

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


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

  This patch is incomplete. The testcase profiler-5.1 fails, 
  because it expects a scalar 'enabled' and not an array.

  Working on this now. Always adapt and extend the testsuite 
  for new features too!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9808: p.diff

  Logged In: YES 
  user_id=75003

  Here is the new patch. It changes the version from 0.1 to 
  0.2 too.


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

  Historical note: The pages which have a struct_ prefix are the pages whose names without the prefix clash with manpages of either the core, or previously existing packages.

  I agree regarding the confusion. Given the clashes I noted I would propose to simply go forward with all manpages in the module having the 'struct_' prefix to eliminate the confusion.


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

  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 of a
  deterministic precision across versions. Committed.


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

  The fix has been committed to the head, two new tests have 
  been added to cover these cases.


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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  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: 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: twylite
username: twylite
mimetype: text/plain
icomment:
  Upped the priority -- the implementation currently does not pass the NIST test suite for the AES algorithm.


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

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


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

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

  Tcl 8.5a6 from todays CVS head.


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

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

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


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

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

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


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

  Tcllib does not contain an "http" package.
  There are "html" and "htmlparse".

  And the "autoproxy" package in the http subdirectory.

  ... Ok. The 'Bugs' Tracker had category 'http :: autoproxy', but none of the others.
  This is now fixed.


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

  The simple approach to fix the bug proposed here is
  incorrect. The variable "request_uri" does not contain the
  same information as "env(REQUEST_URI)". Perform the change,
  execute the testsuite and see testcase ncgi-11.2 fail.

  The correct fix is to check again for the existence of
  "env(REQUEST_URI)" and use "env(SERVER_NAME)" if it doesn't
  (exist).

  See attached the patch.


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

  Logged In: YES 
  user_id=202636

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed
  variable  - modules/virtchannel_base
  string    - modules/virtchannel_base
  zlib      - modules/virtchannel_transform
  coroutine - modules/coroutine

  The standard way of fixing things is add the prefix "tcllib_" to the manpages in question.
  (We already have several others so fixed).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks Thomas.

  I have now run this code against the json.test testsuite in Tcllib, and it reports one failure, for the 'menu' test case. The others all pass.

  The JSON it fails on is

  {"menu": {
      "id": "file",
      "value": "File:",
      "unival": "\u6021:",
      "popup": {
          "menuitem": [
                       {"value": "Open", "onclick": "OpenDoc()"},
                       {"value": "Close", "onclick": "CloseDoc()"}
                      ]
      }
  }
  }

  See the attached file X.log for the stacktrace and error message. It basically expected ',' or '}', and got a ':'. I do not know if the test input is wrong, or your code missing something.

  Please check.


login: thomasmaeder
username: thomasmaeder
mimetype: text/plain
icomment:
  Thanks for testing! I had forgotten the 'u' in Unicode character literals ('\u6021').

  I have just (2009-12-10 09:48) attached the fixed json.tcl


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

  The revised json.tcl passes the test suite. Committed to head with slight modifications (changed a few '==' to 'eq' because they were string, well character, comparisons, and 'eq' is better for that, as it doesn't check if the arguments are numeric or not, as '==' does).

  The new version number is 1.1.


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

  I guess that this applies to graph and tree, but not the 
  others (queue, stack), right ?


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

  Note that the 'exists' method is currently used to check
  the existence of nodes (tree, graph) and arcs (graph).

  We have to find a different name.


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

  Yes, how about:

         graphName arc get arc ?-exists key?

  or -keyexists or something of that ilk.  I think 'get' is a
  reasonable place to put these subcommands.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10793: 460230.diff

  Logged In: YES 
  user_id=75003

  Ok, I created a new submethod 'keyexists' for tree nodes, 
  graph nodes and graph arcs. Attached the patch implementing 
  them, their documentation and additional testcases.


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

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

  What do you mean by 'coordinating' ?

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

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

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

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


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


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

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

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


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

  Sorry for the long delay.

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

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

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

  I would like to do

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

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

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


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

  An example is something like

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

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

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

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


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

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

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


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

  Hm, I will have to look into this one, but the result should indeed be a list of three long.


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

  There were several bugs in that piece of code - hidden because there was
  a bug in the boundaryValueSecondOrder procedure that used it in the 
  test too.

  It should be okay now (extended the test script with this example,
  but I realised later that I should include an example with varying
  numbers too)


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

  This seems to be a duplicate of bug
  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1724818&group_id=12883

  That bug has been fixed in the CVS head and is slated for release with Tcllib 1.14 (next week).


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

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

  Possibly not yet in your snapshot.


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

  Possibly true. The Wiki mentions that this was a string 
  match before and was changed regexp. Better be sure.
  Applied change to head now.


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

  I have fixed this by modifying the NoteBook::_draw_page 
  procedure in the notebook.tcl file.

  Instead of this:

      if { $data(select) != $page } {
  # Non-selected pages have tabs 2 pixels lower than 
  the selected one
  incr top 2
  if { $pos == 0 } {
      # The leftmost page is a special case -- it is 
  drawn with its
      # tab a little indented.  To achieve this, we 
  incr xd.  We also
      # decr textOffsetX, so that the text doesn't 
  move left/right.
      incr xd 2

      incr textOffsetX -2
  }
      } 

  Do this:

      if { $data(select) != $page } {
  if { $pos == 0 } {
      # The leftmost page is a special case -- it is 
  drawn with its
      # tab a little indented.  To achieve this, we 
  incr xd.  We also
      # decr textOffsetX, so that the text doesn't 
  move left/right.
      incr xd 2

      incr textOffsetX -2
  }
      } else {
          # The selected page's text is raised higher than 
  the others.
  incr top -2
      }

  Can you please update the source with this fix?


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

  Change accepted, committed to head.
  Note for future: Please use the 'diff' tool to generate a 
  patch file. Unified diff's (See option -u) are prefered.


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

  We can now search within the text in the chat by entering
  "/?<regexp>"


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=317958
  Originator: NO

  Since there is no -disabledbackground option for tablelist widgets, a disabled tablelist uses the normal background color at widget, column, row, and cell levels.  This is implemented with the aid of a text widget tag.  Under some circumstances, parts of the body text widget might lose this tag, thus giving rise to the erroneous behavior reported by Ralf.

  I have checked in a corrected version of the distribution file tablelistUtil.tcl.  This should fix the bug.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The proposal is to add:
      $path.e selection range 0 end
  after
      $path.e selection clear
  within function ComboBox::_select of file combobox.tcl.

  IMHO it is included in BWidget release 1.8 and in the current cvs.

  Please see the following patch reference where tests was made.
  (I did not test anything now)

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

  Is the parameter -exportselection 0 sufficient for you ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  After this E-Mail from Erik Leunissen:
  The lines commented out in the above snippet are the changes proposed by
  patch 981545. They do exactly as I propose in a user-configurable
  manner. Just tested with [ComboBox -exportselection 0].

  I definitely support patch 981545.

  Oh, and personally I'd prefer the default value for -exportselection to
  be "0". Maybe that this is a matter of taste ...
  -END-

  patch 981545 was commited to cvs.

  Thank you,
  Harald


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

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


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

  Ah, you want a script, like used by 'foreach', instead of a
  command prefix. And the script has access to a variable
  containing the current element.

  Specialized foreach commands, both of them. Called them
  'mapfor' and 'filterfor'.

  Committed, with test cases, and documentation.

  Administriva: Please put tcl code into a files and attach
  them. Inlined code is unreadable.


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

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

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

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

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

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


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

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


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

   looked again and you need Trfcrypt, not Trf, I got confused
  by a switch-label. Trfcrypt does not come with ActiveTcl, so
  you are using the pure Tcl impl. of blowfish.
   
  I also note on further reading that the mode you are using
  is CBC aka Cipher Block Chaining. IIRC my crypto right this
  mode always operates on whole blocks, which are 64bit, aka 8
  byte
  for blowfish
  (http://en.wikipedia.org/wiki/Blowfish_%28cipher%29).
   
  This means that the padding done is correct. It likely
  actually is done to the input to make it a set of full blocks.
   
  Found some references:
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29
   
  And
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
  for methods padding which can be done before CBC is invoked
  and is exactly reversible. I do not know if the code in
  Tcllib uses any of these block padding schemes or is leaving
  that to the caller. I guess that it is the latter.
   
  Pat, I think we should add these wikipedia entries as
  references.
   
  I also grepped the manpage for information regarding padding
  and found none. IMHO this is a doc bug we should correct.
  This is one area where people can trip.
   


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

  Documented the padding a bit more explictly. Also added a
  -pad option to the blowfish command which can be used to
  turn off this padding feature (in which case you get an
  error if the data is not a multiple of the block size) + tests.


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

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

  You are quite right. I have corrected the procedure angle 
  and I have added a procedure crossproduct.

  Thanks for reporting this.

  The new files are in CVS


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

  This looks pretty good. First some performance comments
  - All [expr] expressions should be braced - [expr {....}]
  - Avoid excessive [expr] eg: if {[expr ...]} is better
  written if {(...)}
  - You can copy arrays quickly using [array set tempState
  [array get state]]
  - The inverse sbox function is twice as fast if we use a
  table lookup.

  by making the above changed changes can speed the encryption
  from about 26000ms per iteration to around 8000ms per iteration.

  Second I would think the programming API should be closer to
  that used for rc4 and blowfish in tcllib. I would rather see
  an aes::encrypt and aes::decrypt pair - but more importantly
  I think we should be able to do:
   set key [aes::Init $secret cbc]
   while {receiving data} {Output [aes::Encrypt $key $data]}
   aes::Finish $key
  in other words maintain all state in a opaque token that is
  created by Init and cleaned up by Finish and permit calling
  Encrypt or Decrypt multiple times. This fits well with use
  with network channels where we want to use the
  Encrypt/Decrypt call in the fileevent body on chunks of data
  read from the stream.

  It is also important that we can do ECB and CBC mode
  encryption - it's not specified anywhere what mode is being
  done here and I've not tried to work it out yet.

  Attaching my performance enhanced version.

  Nice job though. :)


login: fattobi
username: fattobi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1333726

  Thanks for the quick response and performance improvements.

  At the moment, there is no chaining of blocks implemented,
  just one block gets en-/decrypted.
  I will work on the API, but don't expect it done too soon.

  Thanks for your help,

  Thorsten


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

  Imported into CVS so that we can properly maintain the
  history of this code. I will try and fix the programming
  interface before we release the next version of tcllib.
  Fixing the API should also make supporting CBC mode simpler.
  New module: aes


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

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

  I am attaching a patch to attempt a fix for this problem,
  along with fixing a series of misspelled words, etc. 


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 24883: pat.tcllib.docs

  Logged In: YES 
  user_id=15949

  second try to attaching a patch file.


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

  From the chat

  akuJust looked at the comment problem and patch. 
  what is the correct formatting of an nroff comment ?

  lvirdenThe first line of a man page consists of either a 
  nroff directory, or a specially formatted comment line that 
  indicates that man should invoke additional programs for 
  formatting the text

  lvirden(at least on Solaris)

  akuSo the first line should not have a "normal" 
  comment, right ?

  akuWe can enforce that in the mpexpand processor.


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  Another race condition happened after switching to passive mode in an attempt to avoid the problem mentioned here. In that case the ftp package frequently throws an uncatchable error if the file does not exist:

  can't read "ftp(Start_Time)": no such variable
      while executing
  "if {$ftp(Start_Time) == -1} {
          set ftp(Start_Time) [clock seconds]
      }"
      (procedure "::ftp::HandleVar" line 5)
      invoked from within
  "::ftp::HandleVar 0 sock24"

  This happens when the control connection is closed, which cleans up the ftp array, before the data connection is closed. Then when the event handler for the data connection fires due to an eof situation it tries to access ftp(Start_Time), which no longer exists.

  It looks like some kind of mechanism is needed that can wait for certain events on the data connection before proceeding.


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

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


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

  Now that I take a closer look, this isn't entirely correct.

  aclocal.m4 contains a pointer to config/tcl.m4, which is not
  in the source tarball.  However, configure.in doesn't
  reference any macros that would be in tcl.m4, so aclocal.m4
  isn't even necessary and should be removed.

  configure.in does reference a 'config' subdirectory which
  does not exist.  This directory should either be added or
  configure.in should be modified so that it doesn't look for it.


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

  BWidget no longer uses autoconf, therefore there is no need
  for tcl.m4.


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

  RFC2045 says in section 6.7 
  "A good strategy is to choose a boundary that includes
   a character sequence such as "=_" which can never appear in a
   quoted-printable body"
  and so indeed this is what we do. RFC2046 ( the multipart
  one ) explicitly includes '=' in the BNF description of
  permitted boundary chars in section 5.1.1.
  The uniqueID proc is used to generate Content-ID data and uses 
    <[pid].[clock seconds].[incr mime(cid)]@[info hostname]>
  which is as good as we can reasonably manage. This field is
  often useful in multipart MIME documents where it allows one
  part to refer to another within the same document - for
  instance in multipart/related MIME documents.
  So far I cannot find any explicit reference for denying
  MIME-Version in the sub-parts.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 21740: diff-u

  Logged In: YES 
  user_id=24077

  andreas - apply this "diff -u" to resolve this.


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

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

  Also done for md4.

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


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: NO

  I don't believe this is a bug. Headers are allowed to be repeated, such as for "Received" headers. Putting "Received" in a list and other headers not in a list would require the mime package and the user to know every possible header, and it would require everyone knowing that a header that appears only once might in other messages appear multiple times. If you expect only one instance of a header in your message, just access the zero'th element of the list returned.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=802134
  Originator: YES

  I do still think, that this is a bug!

  The Content-Id inside a "header" of a message part must be a real identifier!
  There is only one Content-Id per message part, or the message is mal formed!

  So the Content-ID should not be a list.

  I think from my own experience, that there is some addition quoting/bracing because of the "$" inside the Content-ID.
  If this is needed during parsing the message part ... ok.
  But returning the additionally braced value is ... not ok and unexpected, because of the intention of this value, the Content-ID.

  Good morning from Berlin/Germany,

  Marti


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425
  Originator: NO

  There are many headers that are only supposed to appear once, and many that may appear multiple times. There's no easy way to provide a list of all headers that should only appear once and all headers that may appear multiple times. Now that you know why it happens, why not simply take [lindex ... 0] of any header that your code expects to appear only once? Or, alternately, check that the list length is indeed only 1, and provide an error message if you are given a malformed message?


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

  Fixed in cvs head. Note that IMHO The * belongs to the Ns_Sls, not the 'sls'. I.e. it should be part of the type, not the function.


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

  Fixed in CVS head. Albeit after the 1.13 release. Missed this or saw and then forgot again. My apologies.


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

  I found the reason for the behaviour. csv::split internally uses 
  regular expressions for its parsing, and | is a special 
  character for the regex engine. So is + for example, or *. 
  These characters fail too (extended the testsuite and tried 
  many separator characters). The sep char has to be 
  protected from special interpretation.

  Fixed in CVS head.


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

  Hide users menu should now fit on-screen due to the 
  NickList being trimmed.
  Bridge users can be hidden.


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

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


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

  kanryu6 applied this patch on 2009/04/17:

  @@ -194,7 +194,7 @@
              # but it may be 0.xxx
              string is double -failindex last $txt
              if {$last > 0} {
  -               set num [string range $txt 0 [expr {$last - 1}]]
  +        regexp -- {-?[\d\.]+([eE][\+-]?\d+)?} $txt num
                  set txt [string range $txt $last end]

                  switch -- $state {


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

  Note that this will not prevent the limitation that everything for 
  a macro has to be on one line when not using lists (comes 
  from expand).


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

  Addendum to last comment: Continuation lines are processed
  properly when doing macros. So line breaks in macros are
  possible.


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

  I believe we should make an exact list for which commands
  this is wanted before jumping into an implementation. We
  will also have to determine if the output of, for example,
  [arg a b c] is equivalent to either "[arg {a b c}]", or
  "[arg a] [arg b] [arg c]". This are differences in the
  formatted output, and also semantic differences. The first
  means: The text is one argument, named "a b c"; and the
  other means: The command was called to makr three arguments,
  named "a", "b", and "c". And this equivalence can be
  different from command to command. This definitely has to be
  specified.
  Note: The whole implementation, including which equivalence
  applies, can be done in "checker.tcl", i.e. the input
  validation layer. There is no need at all to change the
  formatting engines. A good thing actually. No change in that
  API required.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The use of "string equal" makes this version of tcllib dependent on Tcl 8.4.
  Do we want this (already) ? 


login: ericm
username: ericm
mimetype: text/plain
icomment:
  [string equal] has been around since 8.2.  I think it's fine to require at least 8.2.  In the future, tcllib may require the latest stable release, which is fine too.  Users who need an older version can get an older version.

  We might want to make the dependence explicit, however, with a [package require Tcl 8.2].

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc
  ericm at interwoven.com


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

  Yes, this is noted in a different report here too, see
  #232017.
  I would accept the patch and add it to the CVS, but it is
  currently assigned to Scott Redman (It doesn't show here,
  but in the list of Bugs).


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

  Hm. I just tried the current tcllib HEAD, tclsh 8.4.2, win 2k, 
  and have no errors at all (59 tests, all passed).

  I.e. I am unable to repro this


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

  Nothing will/can be done the 1.4 release except if we get a 
  reproducible test case. Modding down.


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

  Well something strange is going on then because with Windows
  2k and tcl 8.4.2 and tcl 8.3.5 I get 4 errors in ncgi-14.3 -
  ncgi-14.6

  I'm using "tclshXX.exe sak.tcl test ncgi" to run the tests.
  I have also tried this using two different machines with
  Win2K (although these have pretty much identical installations).

  With tclkitsh (tcl version 8.4.1) I get 15 failures but some
  of these are  to do with child tclkit's not picking up my
  extended auto_path.


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

  I tried again and I simply do not get these errors in my Win 
  2K box. Used a tclsh 8.4.2, and a tclsh 8.3.4, and ran the 
  tests via sak.tcl, like you. No errors.

  Pat, may I ask you to investigate deeper into this ? As you 
  get the failures and I don't you seem to be in the best place 
  to find the problem. ... This seems to be something in the 
  multipart scanner. Maybe EOL differences ? 


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

  Latest discussion was on the Tcl'ers chat.

  The file 'formdata.txt' is stored in the CVS with DOS line 
  endings, but not declared as binary. This is ok for a unix 
  client, as I used, but a Windows client (as used by Pat) will 
  convert the CR LF to CR CR LF, and that trips the tests 
  because the line endings are now bogus.

  The file has now been declared binary (-kb) and things are ok 
  on both unix and windows, the latter tested by Pat.


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

  Notes, thoughts:

  The 'graph' structure has selection/filtering functionality => 
  See methods 'arcs' and 'nodes'.  Is limited to 'exact value of a 
  key' however.

  So this FR is actually two: Get filtering into tree at all, and 
  extend the filtering on exact value into other areas: glob, 
  regexp matching, arithmetic-relational matching (>, <, ...).
  Maybe easier to allow user-specified 'filter command' called 
  per node and decides what nodes to return ... Hm, this is 
  covered through walking ... Less efficient. Walk also does 
  specific order, filtering has no need for order ... so a special 
  filter method still makes sense. ...

  Complex filters (and, or, not conditions): Can be done through 
  set intersection, set union, set difference operations.


login: davidhbigelow
username: davidhbigelow
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=664837

  Whoops - I accidently re-requested this.  But as I read this, I 
  think it is still a worthy idea; please see the new example of 
  how this might work.

  Dave


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

  The new 'filter' extension to the 'children' command
  provides the desired functionality.


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

  Minimum Tcl version 8.3 (we require the mime package and
  it's minimum version is 8.3).


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

  Thanks, and that's fine for now.

  For future reference, though, you should
  use [package require Tcl $version] to 
  record the Tcl needs of the code in your
  package only.  Trying to chase down the
  needs of the packages you depend on
  (and the packages those pacakges depend on...)
  is an unsustainable maintenance nightmare.
  Let each package take care of its own
  requirements for itself.  That's the
  modular solution.

  Indeed that's the reason I've regsitered these
  bugs in the first place, so that smtpd will
  take care of its own dependencies, so that
  every user of the smtpd package out there
  will not have to.


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

  See http://www.purl.org/net/akupries/soft/pool/ for 
  transferable functionality.


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

  A calendar module has been opened up for holding this functionality.


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

  Ok, I have some procs already that I have been working on.
  Should everything fall under the calendar namespace, or
  should it be separated out into calendar/date/time? I don't
  care either way. If I want to submit my procs, how do I do that?


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

  Excluded from official distribution per maintainers of the 
  module.


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

  Accepted. Changes committed to CVS. I am not sure if my code is correct for nroff. If not, just open a bug.


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

  Applying this patch to 1.4.0cvs fails with:

  lorax [~/cvs/tcllib/bwidget] 47 > wish8.3 demo/demo.tcl
  Error in startup script: invalid command 
  name ".mainframe.status.prg"
      while executing
  "$path cget $realopt"
      (procedure "Widget::cget" line 20)
      invoked from within
  "Widget::cget $path $option"
      (procedure "Widget::getoption" line 6)
      invoked from within
  "Widget::getoption $path -textvariable"
      (procedure "MainFrame::create" line 49)
      invoked from within
  "MainFrame::create .mainframe -menu {
          "&File" all file 0 {
              {command "E&xit" {} "Exit BWidget demo" {} -
  command exit}
          }
      ..."
      ("eval" body line 1)
      invoked from within
  "eval MainFrame::create $path $args"
      (procedure "MainFrame" line 1)
      invoked from within
  "MainFrame .mainframe -menu {
          "&File" all file 0 {
              {command "E&xit" {} "Exit BWidget demo" {} -
  command exit}
      invoked from within
  "MainFrame .mainframe  -menu         $descmenu  -
  textvariable Demo::status  -progressvar  Demo::prgindic"
      (procedure "Demo::create" line 35)
      invoked from within
  "Demo::create"
      (procedure "Demo::main" line 12)
      invoked from within
  "Demo::main"
      (file "demo/demo.tcl" line 209)

  Since there is already a -variable option for the 
  ProgressBar, it would seem easiest to just link to that 
  with an additional label.


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

  Committed revision [214655747d]. Different varname however (SAK instead of xx).


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

  Not only with syslog, also with Andreas log package.

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


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

  Logged In: YES 
  user_id=81875
  Originator: YES

  File Added: logger.diffs


login: 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: jenglish
username: jenglish
mimetype: text/plain
icomment:
  File Added - 25425: tree-widget.patch

  Logged In: YES 
  user_id=68433

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

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


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

  Logged In: YES 
  user_id=68433

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

  This feels the best so far.


login: 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: droll
username: droll
mimetype: text/plain
icomment:
  It is right that some tests of the TEPAM module require Tk. I understand that there may be targets on which Tk is not available. I will modifiy next week the relevant tests in a way that they are only executed when Tk is available.


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

  I have added a category 'comm'. I believe that any 
  documentation bugs falls into the category of the affected 
  module.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13440: 480227.diff

  Logged In: YES 
  user_id=75003

  The enclosed patch adds the namespace information in all 
  relevant places and also changes the formatting of examples 
  so that they are formatted correctly by nroff. Changed 
  references to myself to uptodate values (redirecting SF 
  email, and PURL to pool).

  Also fixed two buggy places in the comm code.


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

  The "Diagrams" package was obsoleted by "diagram" (lowercase, no trailing 's').


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

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


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

  Yes, this was enough info for me. The problem happened when
  I tried to extend the result, either by extending the last
  element, or adding a new chunk, for the case of chunks of
  type 'unchanged'. This was done incorrectly when this
  extension happened at the very beginning, i.e. for a still
  empty result.

  Committed a fix.


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: 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: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289329: ctext.test

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.test


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289330: ctext.tcl

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.tcl


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

  I fixed this bug in the tcllib/tklib HEAD.  ctext is now at revision 3.2.  I used ctext::getAr and added 3 keys to the array used for storing information about ctext's per-widget state.

  So now this should all be handled by 3 catch {after cancel $configAr(...)}

  Please let me know if you experience further problems.

  Thank you for the unit test as well.  I'll have to see about getting that integrated.


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1573661
  Originator: YES

  Thank you for that bug fix.
  By the way, thank you for ctext !

  The suggested unit tests are the smallest possible amount of testing for the ctext package, that is : create/destroy. More tests (even if interactive) are available in the ctext_test*.tcl currently provided in the repository. Moreover, the tests are more testing the undo feature of the Tk text itself : this is because I discovered a bug in the Tk text, but I previously thought that it was a bug in ctext (I was wrong). The test ctext-1.2 is currently failing because of that bug (may be it is fixed in 8.5).

  I have one last question about the feature. Why exactly to delay the highlight after the insertion has been done ? Does that allow an improvment of the interactivity ? What kind of events may be to process between the insertion and the highlight ?


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

  andreas - go ahead and make this change...

  thanks!

  /mtr

  ps: Beat - in future, a patch is always appreciated...


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

  This got added /after/ today's declaration of a CVS being frozen? Still, it's good that it got in; I've been thinking about this the last couple of weeks, but also been too busy to get around to it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The declaration also said 'If changes are needed before 1.12 is released coordinate with me.'.

  Which Aaron did, pinging me on the chat. I reviewed and decided to apply, i.e. decided hat I want to have this in 1.12. It was not Aaron going over my declaration.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This type of putting up an RC and freezing CVS before actually doing the release is mainly there to flush out all the people who have such last-minute stuff and sort of forgot that we are working on making a release. A last wakeup call. I definitely expected for stuff like this come out of the woodwork with my declaration.


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

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


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

  Ye, it is in the CVS. Yes, using '--' will stop this. Made the 
  change now. Thanks for the report.


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

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


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

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

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

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


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

  Thanks for reporting. These links are repaired by replacing tug.org with ctan.org; they probably predate the registration of the ctan.org domain.


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

  I have just checked CVS version 1.12 (15/Oct/2001) and under
  Windows I can copy text from the main chat window and paste
  it into the posting window.

  If this is still a problem, what platform? Or are you just
  after adding the menu items for these operations?


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

  ... This was some trouble I had with transfer of selection 
  between Win* and the X-server and then to the app. Closing 
  this request now.


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

  See also Tcllib FR #531531 for an FR regarding the 
  architecture of the server.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 19658: doc.tar.gz

  Logged In: YES 
  user_id=75003

  Attaching documentation of server and adjunct packages.


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

  Closing this, moved the attachment to the bug entry, where
  it truly belongs IMHO.


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

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


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

  The removal of the 'unset' is not required if the variables are initialized with 'variable'.
  Another instance of what is known as the 'creative writing' problem.
  See http://wiki.tcl.tk/1030

  Fixed in CVS head.


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

  Applied the suggested patch.
  Updated the testsuite of the module on my own.


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

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

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


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

  The return values of determineScale seem to be correct.

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


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

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


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

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


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

  Committed the updated patch (test fix, additional test case,
  qp_encode fix).


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

  Does this happen for the current CVS head as well ? I just checked and the installer code in the CVS head does not contain 'package require fileutil', so the problem might be gone.

  If not note that the Makefile calls on 'installer.tcl' as well, with a series of arguments for non-gui operation. So, when you call the installer directly, using them same arguments, does the error then happen ?


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

  How does this look, as a patch, in setValue?


  @@ -503,7 +503,15 @@
       if {![info exist value($key)]} {
          lappend varlist $key
       }
  -    set value($key) $valuelist
  +
  +    # This if statement is a workaround for another hack in
  +    # ncgi::value that treats multipart form data
  +    # differently.
  +    if {[string match multipart/* [ncgi::type]]} {
  +       set value($key) [list [list {} [join $valuelist]]]
  +    } else {
  +       set value($key) $valuelist
  +    }
       return ""
   }

  If I don't hear back shortly, I will commit.  This makes it
  pass the tests.


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


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

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

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

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

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

  Sorry,
  Harald


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

  Anyway, thanks for looking into this issue.

  Best regards,
  Michal.


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

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

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

  Thank you for your contribution!
  Harald


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

  Commiitted a fix to CVS head. Package version 2.4.9.


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

  Analyzing the problem ...
  The detection of incomplete data at the end of a string is
  ok.

  However a stored incomplete tag is never used in the next
  iteration. That is bad.

  Fixed in head.


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

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

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

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


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

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

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


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

  Yes, a duplicate of [ 1774302 ] error in CommRunHook error handling, @ https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1774302&group_id=12883

  Already fixed in the CVS Head.


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

  I was able to recreate the problem and fixed it using your
  suggestion.  Thanks.


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

  Fixed the 1.4 reference. The README will be done just before 
  release. The contents are such that a continuous update, i.e. 
  keeping in sync with the reality of the code is difficult.


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

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


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

  Committed fix to CVS head (Using double() to explicitly cast the value).
  Bumped package version to 0.3.


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

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


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

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


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

  Rewrote the README to describe the new way of adding 
  modules. Committed to CVS head.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  Sample code again:

  # -----------------
  # working sample
  % set bb [huddle create a b c d] ; # create as a dict
  HUDDLE {d {a b c d}}
  % set cc [huddle create e f g h]
  HUDDLE {d {e f g h}}
  % set bbcc [huddle create bb $bb cc $cc]
  HUDDLE {D {bb {d {a b c d}} cc {d {e f g h}}}}
  % set folding [huddle list $bbcc p [huddle list q r] s] ; # create as a list
  HUDDLE {L {{D {bb {d {a b c d}} cc {d {e f g h}}}} {s p} {l {q r}} {s s}}}
  % huddle strip $folding ; # normal Tcl's notation
  {bb {a b c d} cc {e f g h}} p {q r} s
  % huddle jsondump $folding ; # dump as a JSON stream
  [
    {
      "bb": {
        "a": "b",
        "c": "d"
      },
      "cc": {
        "e": "f",
        "g": "h"
      }
    },
    "p",
    [
      "q",
      "r"
    ],
    "s"
  ]


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

  It took me while to understand the description.
  Well, I believe that I understand it now.
  So let me try to describe it in my own words.

  (1) Huddle provides a generic Tcl-based serialization format
  (2) The entries in that format are tagged with simple type information
  (3) The currently the known types are 'L' for list, and 'D' for dict.
  (3a) There are also 'l' and 'd', these I do not understand yet.
  (4) When converting huddle-notation to other serialization formats like
      JSON or YAML this type information is used to select the proper notation.
  (5) And when going from JSON/YAML/... to huddle their notation can be used to
      select the proper huddle type.
  (6) In that manner huddle can serve as a common intermediary format.
  (7) The nice thing about its notation that Tcl can read this format directly
      (list/dict commands) without the need for a special parser.

  Side note: Origin seems to be http://wiki.tcl.tk/21116


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  Thank you for the kind description.
  That's right.

  Huddle provides a generic Tcl-based serialization/intermediary format.
  Currently, each node is wrapped in a tag with simple type information.

  huddle-format: >
    {HUDDLE {tag {huddle-node}}
  huddle-node: >
    {tag {huddle-node(content)}}
  each tag means:
    s: (content is a) string
    l: Tcl's list, each node is a string
    d: Tcl's dict, each node is a string
    L: list, each node is a huddle-node
    D: dict, each node is a huddle-node
  confirmed:
    - JSON
    - YAML(generally, but cannot discribe YAML-tags)
  limitation:
    - cannot discribe the aliase from a node to other node.


  I want to use the format/library for serializing to YAML/JSON streams.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279039: huddle-0.1.1.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  supported for adding user-type/tag.
  removed simple container tags ("l", "d")
  add command "huddle set"
  add command "huddle remove"

  File Added: huddle-0.1.1.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279694: huddle-0.1.2.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  - add command "huddle combine"
  - add command "huddle equal"
  - add command "huddle append"
  - support inheritance for type-callbacks.

  I want to append the library to Tcllib.
  I already have replaced codes in the yaml-lib.(but not committed)

  Although I am going to put on the same directory as yaml-lib, may I commit for a while?
  File Added: huddle-0.1.2.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2072360
  Originator: YES

  It uses in the yaml library now.
  It is in the same directory.


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

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


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

  There is no patch attached.

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


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

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

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

  I agree with that implementation.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  And we have to put '-no-apps' into the targets 'install-doc' and 'install-libraries', to prevent them from trying to install things beyond what they are supposed to install.


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

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

  I was thinking about this myself for -validatemethod.  I
  wanted to be able to allow things like:

  option -place -default center -validatemethod [list ListOf
  $placeValues]
  option -modal -default none -validatemethod [list ListOf
  $modalValues]
  ....


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

  The current behavior is as it is by design; there was considerable discussion
  on the Snit mailing list about at the time.  I forget the details; you can find
  them in the Snit mailing list archives (which you can find via the Snit
  home page, http://www.wjduquette.com/snit).

  As for the -validatemethod, it will soon be deprecated; it's being replaced
  by a "-type" option.  I've got the code written and will be starting on the
  documentation updates this week; the new version will be included in
  the Tcllib release for this year's Tcl/Tk conference in October.


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

  Note that "option -type" is now available in CVS.  As for updating -
  configuremethod and -cgetmethod as described here, I'll have to think about it 
  some more.


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

  I will have a look at it - perhaps a problem with integer values (rather than floats)?


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

  Apparently not an integer problem:

   ::math::statistics::cdf-normal 0.0 1.0 0.0

  gives the same error.


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

  No, I assumed it was because that is a common mistake with converting Fortran or C code to Tcl.
  However, we are in some limit situation for the algorithm. The quick-and-dirty solution is treat 
  x=0 as a special case. 


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

  I can do the quick-and-dirty workaround no problem. Thanks! I just wanted to bring it to your attention.

  Take care,
  Eric


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

  Fixed. Used the second proposal. I.e. check for the required 
  number of conversions.


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

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

  then go and and generate a new, complete patch.

  thanks,

  /mtr


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

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


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

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

  The first patch should be deleted...


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

  Logged In: YES 
  user_id=546883

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


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

  The current ldap TLS code just uses a different port and
  wraps the connection into TLS. A different solution would be
  to do the ldap starttls handshake to setup a TLS connection.
  Its not hard to do and i have it nearly done.


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

  I'll submit an updated ldap.tcl (version 1.6), which
  supports StartTLS. Not sure if that does a graceful fallback
  yet, but should improve things.


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

  Added the new starttls code to the ldap module, which allows
  to upgrade a standard connection to TLS secured.

  As the LDAP RFC is more critical about validating TLS
  connections an automatic fallback to unencrypted is not a
  good idea. 

  Please have a look at the current code in CVS, I'll set the
  status to Pending, so it gets closed if there is no response.


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

  Wrong tracker. The tcltutorial is in the Tcl project, not in Tcllib.


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

  Is the tutorial part of this SF project, or part of the Tcl SF project? If the latter, then this bug report should be made over there.

  I agree that a category for the tutorial should be created where ever the tutorial is being maintained.


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: afaupell
username: afaupell
mimetype: text/plain
icomment:
  i dont believe the first 2 lines are needed since the example is static html, not ncgi output. I have fixed the ncgi::value call not matching the html name.


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

  This seems to be a dict'ionary ordering thing. The tcllib testsuite support provides a 'dictsort' command to generate a canonical representation, whatever the ordering returned by Tcl. This is not as important any longer now that dicts are keeping insertion order. It was originally made because Tcl 8.4 and 8.5 returned dicts and arrays in differing orders due to changes in the underlying hash(table).


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

  Committed updated tests to CVS. Note: The tests can run with a Tcl 8.4 using the backported dict package. This combination will now fail as the backported dict does not have the ordering changes of the Tcl 8.5 dict. either the backport has to be updated, or the testsuite has to get two tests per actual test, one per variant.


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

  hm... perhaps i need to think before i type,
  the regexp should be more complicated to allow for cases of 
  %%W and %%%W which this one would break...


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

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


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

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

  Note: Is it possible for you to create a jpeg file without
  or minimal image data which has the same exif data which is
  giving you the trouble ? I would like to have something like
  that as test case.

  ... Belay the query about jpeg::exif ... I just see from the
  stacktrace that this happens in the MakerNote decoder of
  exif, and Makernote data is not yet handled by the
  jpeg::exif code. I would still like to have an image showing
  the error for a testcase.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Try this picture of yours truly (above, right) for example:

  http://virtual-estates.net/Izrail/Ira/img_4060.jpg

  BTW, I'm thrilled to learn, there is wider JPEG support in
  the works, than just Exif-handling.

  In particular, it appears, no software out there provides
  for lossless rotation of JPEG images (besides the jpegtran
  part of libjpeg). It would be great, if tcllib was the first
  to offer this valuable feature.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thank you. I got the image now, and will try to compress it
  a bit more. 600K is still a bit big to be lugged arund as a
  testcase in the distribution. I hope you don't mind getting
  more squeezed and blurry :)

  Alas, the jpeg code in tcllib is currently only able to work
  on a number of meta data chunks, like timestamps, comments,
  exif, etc. It has no operations for manipulating the pixels,
  like higher compression, rotation, and the like. However if
  someone writes such methods I would be willing to include them.

  See http://tcllib.sourceforge.net/doc/index.html#DIVnode290
  for the documentation.


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Regarding JPEG manipulation. The way, jpegtran does(1)
  _lossless_ rotation is exactly through manipulating the data
  chunks. Decoding the image, rotating, and encoding it back
  is how everything else does it, which leads to loss in image
  quality. Rotation by 90, 180, and 270 degrees can be done
  without re-encoding, quickly, and losslessly.

  In general, I'd like to see TCL interface to ImageMagick's
  or GraphicsMagick's libMagick -- with and without the Tk
  support (photo(n)).


login: kot
username: kot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=173641

  Ooops, there is TclMagick already!

  http://www.graphicsmagick.org/TclMagick/


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  committed the fix to head. Place holder for the test image
  right now, have to cut it down a bit, 600K is not manageable.


login: 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: 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: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Could you please provide the exact Tablelist version?  The official tklib5.0 release includes Tablelist 10.0.1, but I am not sure you refer to the *initial* tklib version 5.0, because that is already nearly two years old.

  This bug was present in some earlier Tablelist releases, but was fixed in version 4.7.  Unfortunately, it appeared again in Tablelist 5.0, but was fixed in the most recent version 5.2.  For this reason, please run your script with Tablelist 5.2 and let me know whether it still exhibits the problem (it shouldn't).


login: tombert
username: tombert
mimetype: text/plain
icomment:
  The package index tells 4.10.1
  I've checked the CVS sources now ... there have been a lot of changes. My problem was only that I wanted to get a tagged version. So my question: Is it safe to take the latest CVS source?
  thx


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  The latest CVS source is identical to the one contained in the most recent Tablelist version 5.2 (see www.nemethi.de).

  I am somewhat surprised to hear that you found this bug in Tablelist 4.10.1.  Could you provide a simple script helping me to reproduce the problem?

  Also: Does your script behave as expected when using Tablelist 5.2?


login: tombert
username: tombert
mimetype: text/plain
icomment:
  I was adding a second row to my table while hovering with the mouse over it ... maybe it's related to the tooltip I'am using ... I'am using it without a problem for a year now and can't reproduce - so I only had a look into the code and made a few assumptions ...


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  A closer look at the body of the tablelist::addActiveTag proc in the distribution file tablelistBind.tcl reveals that in this case findTabs does assign a valid value to both arguments tabIdx1 and tabIdx2.  Actually, the additional condition making this sure is that data(dispId) doesn't exist (i.e., that all newly inserted rows have already been displayed).  This is, however, checked in tablelistWidget.tcl, before invoking the addActiveTag procedure.


login: edesio
username: edesio
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=147018

  I just checked:

  duron:~/src/xfermail:306> tclsh
  % package require pop3
  1.2
  % 

  This looks like the old bug you referenced.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yep. 1.2 is old. The current version is pop 1.5
  in tcllib 1.1. Please check if this version exhibits
  the same error.


login: edesio
username: edesio
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=147018

  Where can I download tcllib 1.1? I couldn't find it in
  sourceforge nor in activestate.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  I believe we can correct this problem with
  a substantial revision to mkIndex.tcl.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done. The new all-tcl installer handles this now correctly. See 
  devdoc/indexing.txt for discussion of options and chosen 
  solution.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  passing along to rmax.

  You must be testing with Tcl 8.4.  This is a side-effect
  of the changing default usage message from Tcl 8.3 -> 8.4.

  I think there's some facility in the Tcl test suite for
  dealing with this.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  Note that testing against the Feb 19, 2002 version adds a
  new error:


  Module: sha1
  modules/sha1/sha1.test
  sha1 1.0.2 (pure Tcl)

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-2.1 FAILED

  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-2.2 FAILED

  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.1 FAILED

  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.2 FAILED

  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.4 FAILED
  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.5 FAILED

  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.6 FAILED

  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.7 FAILED

  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.8 FAILED

  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.9 FAILED


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Bugs in the sha1 package belong in another
  category.  Open another report.

  Actually, don't open another report.  This
  problem is already noted as Bug 446997.
  It's just that TIP 72 made all platforms
  into "64-bit platforms" so the bugginess of
  the sha1 package is now clear to all.

  Followups on this issue directed to Bug 446997.


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: 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: 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: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  After considerable though, it turns out that this isn't delegation at all, but 
  propagation.  The difference is that in delegation the option's value is 
  owned by a component; in propagation, the option's value rightfully 
  belongs to the megawidget, while 1 or more components are constrained 
  to have their options set to the same value as the component's option.

  The best way to handle this at present is through a snit::macro.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Restrictions on node names: I am not aware of any. The testsuite actually uses node names which have spaces in them. 

  Instead 'elements ("strings")' I would prefer to say 'named elements', and the 'named' implies that strings are involved.

  Added a paragraph 'The element names can be arbitrary strings'. This should also enforce the information you wanted about elements and strings.

  I have taken and added your comparison to the documentation as is.


  Side question: Was the new section in the struct::tree manpage about where and how to give feedback useful for you ? 


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  Is it intentional that the new Bugs section of the man pages do not show up in the generated (nroff at least) reference pages?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Are you sure ? I did a 'sak doc nroff' on a small sample right now and I see the feedback sections. Are you looking at the right directory ? Please put  this into a new bug report. It has nothing to do with Lars' doc improvement of struct::tree. (Despite my side question).


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949
  Originator: NO

  I think you can disregard that last comment. I'm seeing peculiar behavior by my man command here - I suspect the problem is bigger than tcllib man pages.

  What I am seeing in Sun's man command is occasionally missing sections, or parts of sections.

  No error msgs generated - stuff just isnt there _sometimes_ and is there later.

  Not fun.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  Re: Bug reporting section

  This hadn't (and still hasn't, I think) shown up on tcllib.sourceforge.net/doc, so I didn't use it. The info doesn't feel new to me, but I suppose the direct link might sometimes be useful (saving some clicks). OTOH, that's easily dwarfed by looking around the list of reported bugs to see if the one one has had already been reported.

  Re: Node name restrictions

  On lines 382-383 (description of [$tree insert]) it says:
  If names are specified they must neither contain whitespace nor colons (":").

  I can see the technical reason for the colon restriction (namespace hickups), but not for the spaces.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Bug reporting: Yes, the doc thing is updated only every once in a while.

  Name restriction. Thanks for the reminder and reference. The limits should be gone, the comment might be old and out of date. The node names are keys into arrays, there should be no namespace interaction at all. I will check. I am quite sure that whitespace in node names is fine.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Ok. Have checked. I believe you are using an older revision of "tree_tcl.tcl". The file found in the CVS head does not have 'neither whitespace nor colon' anywhere in it. The restriction may apply to the revision you have, but head revision definitely does not have it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Committed the changes I made. Just reopen this RFE if you have more comments.


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed. Also fixed a syntax error in an example uncovered by
  emacs syntax highlighting. A closing double-apostroph was
  missing.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  IMHO...

  Nothing to repair; this is
  not a bug.

  [namespace import] the
  ::math::linearalgebra::scale
  command into your namespace,
  not the global one.

  If you insist that you must
  import both commands into
  the same namespace then
  [rename] one of them.  This
  is name conflict resolution 101.


login: 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: 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

  Accepted, and committed to head. A list of free ids may come
  later. However even with 32-bit ints we have around 4
  billion numbers before we get into trouble. Ignoring this
  issue for now.


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Thank you for the report ...
  Fixed in CVS head now.
  ChangeLog:

          * memchan.tcl: Fixed missing initialization of 'content' instance
            variable. Bumped to version 1.0.2.

          * variable.tcl: Fixed missing invokation of superclass
            constructor. Fixed missing initialization of linked 'content'
            variable, if not existing. Fixed missing import of linked
            variable into the event handling. Bumped to version 1.0.2.

          * cat.tcl: Removed bogus invokation of superclass constructor,
            there is no such. Bumped to version 1.0.1.

          * facade.tcl: Added missing logger requirements, dropped bogus
            call to superclass constructor. Bumped to version 1.0.1.

          * std.tcl: Fixed command scoping issues, and dropped bogus call to
            superclass constructor. Bumped to version 1.0.1.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  With Tcl 8.5 HEAD, these now fail
  in a different way:

  syntax error in expression " $msg == Infinity ": extra
  tokens at end of expression


login: 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: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  I have been able to trace this problem down to 
  the ::ftp::CopyNext routine and the StateHandler routine. 

  The CopyNext routine will always unset ftp(state.data) 
  once the transfer is complete or there is an error.  Then 
  the StateHandler routine in the put_sent switch arm, will 
  try to unset it again if the return code is not 1 or 2, 
  and it's passive mode.  

  All that's needed to fix this is either a catch, or a 
  cleaner way would be something like:

  if [info exists ftp(state.data)] {unset ftp(state.data)} 
  in the StateHandler routine.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I am not able to confirm that. With the patch applied the testcase mime-3.7 in mime.test hangs and strategic output reveals that it is stuck in the infinite loop you wish to avoid.

  What operating system are you on ?
  Maybe that makes the difference between your non-loop and my oo-loop.
  I tried this on Linux.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Meh. Retracting my statement. The mime-3.7 test case is bad in itself. mime-3.8 is a testcase for the same problem and doesn't run into the infinite loop with patch applied. In mime-3.7 the 'badmail1.txt' the given boundary is the terminating boundary, however it is not recognized because the parser newer saw an initial boundary. The patch now faking a terminating boundary cannot help there, its fake boundary will not be recognized either, hence the infinite loop.

  I think I may try to fake a bit more, i.e. set inP as if we had seen an initial boundary.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  The 'meaningful' variable 'x' comes from (IIRC), i.e. blame me. Should be 'linelength' or some such.

  2007-11-05  Andreas Kupries  <andreask@activestate.com>

  * mime.tcl (::mime::parsepart): Fixed [SF Tcllib Bug 1825092],
  * mime.test: as reported by Max Strobel
  * pkgIndex.tcl: <mstrhh@users.sourceforge.net>. The code parsing
  * mime.man: multiparts assumed that eol sequences are always two
    characters (cr+lf), this however may not be the case. This
    caused the parser to miscount the last line in a part and
    wrongly remove its last character from the part. Extended the
    testsuite, and bumped the version to 1.5.3.

  Attaching the patch I have sitting in my sandbox. I am not fully satisfied with it. While it avoids the loop some of the commentary in 631314 seems to indicate that I should also munge the mime-type of the new part, i.e. force application/octet-stream, whatever the headers claimed for it.

  The necessary updates to the testsuite are missing as well, however that it is more or less a formality.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 277826: mime-1961881-a.patch

  Logged In: YES 
  user_id=75003
  Originator: NO

  Updated the patch in my sandbox.
  Moved handling of missing starting boundary around.
  Added forcing to app/octstream and handled possibility that part is broken beyond parsability.

  File Added: mime-1961881-a.patch


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  Accepted my updated patch. CVS head is now mime 1.5.4.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10896: 440064.diff

  Logged In: YES 
  user_id=75003

  Patch updated to current tcllib, also changed to unix EOL 
  convention.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The non-Trf versions use ` as this is the 0 byte
  representation and this follows other uuencode
  implementations (notably perl's pack('u', ' ');) The tilde
  character is invalid which makes it helpful in recognising
  excess bytes but may cause interoperability problems for
  other decoders. In standard usage each line is prefixed by a
  byte the gives the length in bytes of the relevant data so
  the choice of padding should not be too important.

  Interestingly I looked for a standard and found IEEE Std
  1003.1-2001 gives a specification for uuencode which
  specifies = as the padding character! Solaris'
  implementation is using a space.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In other words, this area is even more of a mess than I thought.
  :(
  Ok,  I will consider this a low-prio thing then.
  Get to unconfuse the testsuite first/only.

  Hm. Might make sense to choose a padding character we can
  easily detect later and then convert into whatever is needed
  for compatibility when the result is used in specific tools,
  like uuencode.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, I committed a change which deconfuses the testsuite's
  belief about which accelerator is loaded and active. Keeping
  this open for dealing with the padding mess, retitled entry
  for that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The canonical method for deleting a tree 'myTree' is

      myTree destroy

  Note: All the object-based structures in tcllib/struct have
  a 'destroy' method for the destruction of an existing
  object. ... Checking ... No, 'record' doesn't have it. But
  all others do.

  There is no need for the proposed command.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  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: 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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  Fixed the test: the failure was due to the changed default
  for tcl_precision.
  By explicitly setting the value, the previous behaviour has
  been restored 
  and the test succeeds. 

  Note: the original value for tcl_precision is restored at
  the end to ensure
  consistent behaviour for other tests.


