# ticketchng

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

  I suppose I'm the culprit for this bug. I would have liked
  to attach the patch to resolve this below, but SourceForge
  doesn't let me do this here. I've opened a new patch report
  for this: #501210

  Regards,
     Bastien


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

  Logged In: YES 
  user_id=202636

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


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

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


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

  Extended the pop3 testsuite (CVS head after Sep 3, 2002, 
  12:30pm Westcoast TZ). The supplied script was used as 
  template for the test. This uncovered a bug in the pop3 server 
  of tcllib, introduced while fixing other bugs during the 
  weekend. Fixed this bug.

  I was unable to reproduce the bug. Maybe I am not using 
  enough messages in the maildrop ? The server (srv.tcl) is 
  currently hardwired to provide 3 messages per user, fvor two 
  users.

  The RFC regarding pop3 states that the server must not 
  renumber messages after the deletion of a message until 
  after the connection was properly closed (QUIT command). 
  During the transaction message ids stay the same, and 
  trying to retrieve or delete a deleted message cause a 
  negative response (-ERR something).

  Can you supply me with more data ? Now that we have a 
  testsuite this should become easier.


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425

  It's been a while, but if I remember properly, it skips alternate messages. (Against the "real" pop3 servers I've tried, 
  not the pop3 server in TclLib.) I just sent myself eight messages, "TEST ONE" thru "TEST EIGHT", in that order. I 
  then ran this program (modified to print out the message itself as well) and the output was

  x=8
  msg len=940
  msg= ... TEST ONE ...
  msg len=980
  msg= ... TEST TWO ...
  msg len=950
  msg= ... TEST THREE ...
  msg len=960
  msg= ... TEST FOUR ...
  msg len=0
  msg len=0
  msg len=0
  msg len=0

  Then when I went to fetch my mail, TEST FIVE, TEST SIX, TEST SEVEN, and TEST EIGHT were still in my inbox.

  Perhaps the ::pop3::delete is implicitly incrementing the message number even if given a specific message 
  number?


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

  I know, the delay is completely my responsibility. Got to work 
  on the pop3 testsuite last weekend.

  ... Checking.
  ... The pop3::delete maps msgid 0 to msgid 1, but does no 
  increment on the id.

  What happens if you do close the connection after each 
  retrieve/delete and always retrieve the first message, until 
  status returns 0 messages ?

  I will add log statements to the client in the evening so that 
  we can trace commands, their arguments, and server 
  responses.


login: dnew
username: dnew
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37425

  Closing and reopening the connection was the work-around I used, yes. That renumbers the messages (except on 
  an Exchange server, if you don't delay long enough. Strange one, that, letting multiple users modify the mailbox at 
  once.)


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

  Allowing more than one connection to the same maildrop is 
  not allowed according to the RFC (1939, see pop3d module).


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

  Ok, the CVS head now uses the 'log' module of tcllib to trace 
  the activity of the pop3 client. Places where logging was 
  adding:

  pop3::send
  pop3::RetrFast
  pop3::RetrSlow

  Everything send to and retrieved from the server goes through 
  these three commands.

  Can you use that to create a trace of the problem when 
  talking with your pop3 server ?


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

  Extended to 10 messages, tried testsuite. It hangs itself 
  when trying to retrieve message number 7. The first 6 are ok. 
  Now I can look deeper into what is happening.


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

  More info. When I tried to log the server side the testsuite did 
  not hang. ... I used a custom log procedure to divert the 
  output of package 'log' into the server log file. ... Removing 
  this hangs on ... Supressing log messages. No hang again.

  Tentative conclusion: The output of log messages by the 
  server to stdout/err hangs the system somehow, when a pipe 
  or whatever fills up and then blocks, causing the server to 
  hang in the log output routine.

  However that does not match your experience, as you talked 
  to an external server. Hm.

  Despite this I will update the testsuite to more than 10 
  messages and supressed log output, for you to use in testing 
  the other server.


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

  We cannot repro this, and the testsuite doesn't find any 
  inconsistencies either. Closing.


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

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


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

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


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

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


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

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

  We can change the makefile to assure this.



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


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

  I recommend 8.4's panedwindow, enhanced in 8.5 (and also a new ttk::panedwindow)


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

  Can you be more explicit?  There is a 'string tolower' done 
  on the description, so the f should be lower in the regexp.


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

  I've applied a fix for this and checked it for 'make
  install' on OpenBSD and by sourcing the test script into a
  wish session. Should be OK now.


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

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

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


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

  Duplicate of bug #507242 except for the locale issue.

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


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

  True regarding duplication.

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

  What's your opinion ?


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

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

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

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

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


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

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


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

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


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

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


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

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


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

  This is a duplicate of tcllib patch 511692, recently 
  accepted and committed to head.


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

  One more vote in favor of this one. Right now I am way back
  in the history, but would really like to see the current
  discussion as well.


login: treincke
username: treincke
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=370915

  I have added the splitting part to tkchat (revision 1.341). 
  Search in the histroy is not yet implemented


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


  I think this request is fulfilled
  by the struct::list command.

  It may not (yet) have all the
  subcommands cited, but
  that's SMOP.


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

  This request is fulfilled with the new 'struct::list' command. 
  Future requests should be logged in that category.


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

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


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

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


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

  See http://www.oche.de/~akupries/soft/autodoc/
  for existing app, also http://www.oklin.com/zdoc/.

  Should/could make use of tclpro/tclparser for this to be a 
  robust system (no execution of code!).


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

  Note: For a true tcllib application we need a pure tcl 
  replacement of tclparser. This is heavy weight against
  it.

  See also
  FR [ #520940 ] New application bundle - tcldevapps


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

  I have an almost finished implementation of TIP 40 that just
  does this (well, it uses the conventions from the Style
  Guide by Ray Johnson). It requires some further testing and
  it should use - in my opinion - the doctools format as the
  default (right now it uses the TIP format, but as all is
  done by traversing a tree of the documentation elements that
  should not be too hard). 


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

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


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

  Proposed additional semantic markup (See
  tcllib-devel mailing list, subject
  "doctools tagging").

  * sectref  - section x-ref
  * syscmd   - Shell commands ('cat', 'ls')
  * method   - Subcommands or methods
  * option   - Options (-exact, -nocase, -textvariable)
  * widget   - Widget classes (Entry, Text)
  * fun      - C functions (Tcl_CreateInterp)
  * type     - C typedef names (Tcl_DString)
  * package  - package names
  * class    - class names (a la [incr tcl], stooop, etc)
  * var      - Tcl variables (errorInfo)
  * file     - file names
  * uri      - URIs


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

  I talked to Marshall Rose, the creator of
  the "mime" and "smtp" modules. He says that
  parseaddress is designed to parse addresses
  as they come in the envelope and headers of
  incoming mails. It is not designed to cope
  with data entered by a user in a MUA.


login: chris_nelson
username: chris_nelson
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=107514

  So, it remains, essentially, impossible to write a MUA in Tcl; parseaddress can only cope with
  well-formed, server-to-server data and there is no routine to handle the  harder-to-parse 
  user-entered data.


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

  For now, yes, it seems so. Note that the Marshall Rose, 
  developer of smtp/mime is now a developer for Tcllib and 
  got these two categories in the trackers assigned to him.
  IOW, new FR's about things like this go to him.


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

  Making # lines comments is difficult, as the underlying 
  processor (textutil::expander) recognizes only macros (in 
  []), and text.

  Would a comment command/macro, like

          [rem foo bar]
  or      [rem {foo bar}]
  or      [comment ...]

  be sufficient for your purposes ?


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

  That would be fine. Especially if it's short! [c foo bar] ?

  [comment ...] would seem to be in keeping.


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

  Ok, I will add a comment macro, together with a bunch of 
  other semantic markup.


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

  I nearly forgot - I'm looking for comments and complaints
  before I go and commit this as a new 'dns' module.


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

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


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

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

  Version 1.52 of tkchat fixes this problem & also properly 
  handles multi-line messages correctly


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

  Some comments by Will

  At 09:09 AM 2/27/02 -0800, you wrote:

  >Hello William, can you comment on how hard this would be 
  to implement ?

  Is it hard to implement?  Probably not, but I don't think 
  it's desirable.

  In a body of text to "expand", all text is either inside or 
  outside of
  macro brackets.  Currently, the role of the plain text hook 
  is to allow
  you to do transformations on the text *outside* of the 
  macro brackets.
  You shouldn't need such a thing on the inside of the 
  brackets; it's the
  macro's responsibility to produce output in the correct 
  form.  And anyway,
  there's a better way to do it.  Instead of writing this:

           A bunch of plain text. [macro {With a bunch of 
  plain text.}]
          More plain text.

  Write this:

           A bunch of plain text [macro]With a bunch of plain 
  text.[/macro]
           More plain text.

  In this form, the interior text "With a bunch of plain 
  text." goes
  through the plain text hook normally.  If [macro] pushes 
  the context stack
  then [/macro] can acquire the bracketed text and process it 
  as desired.

  Alternatively, in the first form, [macro {With a bunch of 
  plain text.}],
  the macro can recursively call "expand" on its argument.

  In short, there are much better ways to do what they want 
  to do, without
  making any changes to the expander at all.

  Will


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

  Since the problem which prompted the submission of this bug (doctools->tmml converter mishandling markup in macro arguments) has since been fixed, and since I agree with Will's analysis, I'm closing this issue.  We should leave things as they are.


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

  this required a bit more work because the which needed to be 
  optional, and I added more checking.  In for 1.4.1.


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

  This bug is already fixed in the CVS head of tcllib/md5.
  Excerpt of ChangeLog:

  2002-02-07  Andreas Kupries  

  * md5.tcl: Adding -- to hex/md5 commands to prevent
    misinterpretation of data if starting with -.


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

  Grrrr...  My Mozilla apparently does bad things with TABs...

  Anyway... tried to install using the

     ./configure
     make
     make install

  but ran into:

  $ make
  make[1]: Entering directory `/usr/local/src/tcllib'
  Gen (nroff): ./modules/base64/base64.man
  can't find package textutil::expander
      while executing
  "package require textutil::expander"
      (file "./modules/doctools/mpexpand" line 5)

  Apparently I must have the latest tcllib installed in
  order to install the latest tcllib.  Oops!


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

  Very. ...

  Given that there is no environment
  variable I can use to add paths to
  the library search path I believe
  the only solution to this problem
  is to patch the mpexpand application
  so that it looks for packages
  relative to its own location too.

      Right ?


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

  Look when I made the comment. It seems my memory subsystem 
  was down at that time. I will try TCLLIBPATH.


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

  Using TCLLIBPATH fixes the problem. Instead of 
      $(DOC_EXP) ...
  use
      TCLLIBPATH=$(srcdir)/modules $(DOC_EXP) ...

  Patch coming.


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

  To illustrate the effect *only* on catch, it may be better
  to avoid measuring the time spent in the funny loops; after
  building them, do just

  set body "
      catch {set b}
      return  
      $nestedRanges
  "


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

  Oops ... forgot to close this: new test was committed on
  15-03-2002


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

  Committed to head, and version number bumped to 4.0 as 
  requested by John LoVerso (original author).


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

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


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

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

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

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


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

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


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

  Bryan, please try that again using the newest doctools 
  straight out of CVS. I just tried to reproduce this and 
  failed. The generated HTML contained the single and double 
  backslashes and netscape rendered it correctly.

  get single and double backslashes in the generated html and 
  both my Netscape and IE renders it correctly.


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

  Note that
      [usage [cmd "package require Tk 8.2"]]
  is better written as
      [require Tk 8.2]

  Otherwise the patch accepted, and extended
  to cover the formats TMML ad NULL as well.


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

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

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

  Right ?


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

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

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


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

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

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


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

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


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

  I saw your email to me ...

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


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

  Sorry, forgot to mention that: HTML. 

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


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

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


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

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

  Thank you


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

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


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

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


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

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


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

  Logged In: YES 
  user_id=75003

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

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

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


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

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


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

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

      "[528392] Missing commands in nroff format".


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

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

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


  stack used by macro


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

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

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


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

  The method is "format". Use "2string" without a report 
  reference to see simple output. Same for "2chan", but 
  because of argument ordering use {} for the rpeort to 
  achieve the effect.

  As for tabular reports see the "report" module of tcllib. 
  The manpage has examples to define reports, and the 
  testsuite of report actually formats a matrix and thus can 
  serve as example.


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

  Added examples to the doctools manpages for matrix and 
  report. Committed changes.


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

  I later realised that the report object that was mentioned
  in the matrix documentation is indeed part of the report
  module. Perhaps the text in the matrix documentation should
  be slightly adjusted (add a reference to that module?) to
  make the link clearer.


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

  As you already did that - forget my suggestions. (It came
  later in a long list of e-mails; probably I should not just
  scan them from old to new but use a more intelligent
  browsing method :-)


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

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


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

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

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


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

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

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

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


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

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


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

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


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

  George@Orwellian.Org replies: 

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

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

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

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


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

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

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

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


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

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

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

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


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

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

  Good luck with your account.


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

  I have added a new option to the smtpd package. 

  smtpd::configure -deliverMIME delivery

  calls the 'delivery' procedure with a MIME token. If the
  -deliverMIME option is unset then the original package
  behaviour is maintained. The user now needs to write
  something like:
    proc delivery {token} { ... }

  I've updated the documentation and added a new example
  'tk_smtpdMIME' to the examples directory.


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

  certainly you an do something like

  mime::initialize -string "whatYouGotFromPOP"

  but the issue, i guess, is what to do if it's a 
  multipart...


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

  Marshall, this is not about what a user got from pop,
  but about the innards of a pop3 server.

  Scenario:
  User contacts pop3 server, opens a mailbox, then
  asks for the first 10 lines of the message 5
  (TOP command). The pop3 server executes a callback
  to get the mail to send. The result of that
  callback is a mime token. Now I want to use an
  extended "mime::copymessage" or now "copypartial"
  command in the pop server to construct and send
  the partial message over the pop3 connection to the
  user who requested the partial mail.

  Right now I am using "mime::buildmessage" and a
  split/lrange/join combo to get the partial message.


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

  Note that Tcllib FR #527114 now has docs attached, so the 
  interface between pop3 server and its storage backend is
  now specified, and definitely a mime token (This makes 
  things like dot-stuffing much easier for me, as I can rely 
  on the functionality in mime and don't have to reimplement 
  it again).


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

  i guess i'd have to understand how the mime token is being 
  constructed in order to figure out the best way to do 
  this. for example, i don't know what mime::buildmessage is.

  certainly, we could add a switch to mime::copymessage to 
  accomplish what you want...

  /mtr


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

  mime::buildmessage is like copymesage, but constructs the 
  final message in memory, as a string instead of writing 
  directly to a channel.

  I will think more about this.


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

  Committed a fix. Note that the section SYNOPSIS
  in the manpage (ftpd.n) lists which tcl version
  is required. This was not changed, just updated
  to 8.3.


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

  Added. Incomplete. No testing of 'delete' yet. See pop3 bug 
  about delete. Will be done as part of that item ([501577] 
  Delete reorders requests?)


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

  tkchat has a blushing smiley now - so maybe this was applied.

  No patch attached.


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

  I guess the behaviour you ask for is
  to set the linked cell in the matrix
  to the empty string, right ?


login: kenj
username: kenj
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=260635

  Yes, I think that would be the correct behavior for it. In the sample 
  application in which I discovered the bug, I had a TkTable widget and a 
  matrix object both linked to the same global array variable. The goal was 
  for changes in one to be propagated to the other. I discovered that when I 
  deleted a row or column from the TkTable, the matrix object didn't pick up 
  the change, even though the global array variable correctly reflected 
  the change.

  Doing a bit of tracing and debugging, I noticed that the 
  MatTraceIn assumes that if it was triggered because of a "u" operation, 
  the entire array variable must have been unset and so it unlinks the matrix 
  object from the array. I believe that an appropriate behavior would be to 
  check if only a single array element was unset, and if so, set the linked 
  cell in the matrix to a null string.

  Based on my (inexpert) analysis of 
  the TkTable's trace output I generated, I believe that this behavior 
  would correctly keep a TkTable widget and matrix object synchronized 
  through the global array. (When deleting rows or columns, the TkTable 
  widget copies the contents of a cell into an adjacent cell, then deletes 
  the contents of the original cell. For the linked array variable, this 
  results in a "w" operation to create a new array element reflecting the 
  copy to the new cell, and a "u" to delete the original cell's array 
  element.)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 20402: 532791a.diff

  Logged In: YES 
  user_id=75003

  Extended patch containing additional test.


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

  ![string compare ...] is equivalent to [string equal ...], but 
  string equal is new in 8.1+.  It appears that what bwidgets is 
  doing is OK.


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

  IMHO this is not a good idea. The whole point of doctools 
  is to have one "standard" format for manpages. This means 
  that anyone who is writing a new output format knows what 
  to implement. Structure of manpages and their visual 
  appearance is completely separate.

  But with this facility we are going back to the state where 
  each package and manpage defines its own extensions, 
  actually format, and visual appearance, and a writer for a 
  new format does not know what to expect at all.

  Regarding the "dislike of the default of [strong]" ... This 
  is exactly where a new output format comes in. I for 
  example plan to write an "ActiveState HTML" format which 
  renders the manpages so that they fit into the general 
  visual appearance of ActiveState's webpages. Right now I 
  can do this because format is fully specified. If this 
  macro facility is implemented I cannot do this anymore, or 
  rather it is much more difficult, simply because where 
  could be a plethora of macros out there I will know about 
  only if I encounter them, meaning continuous work on 
  updating my format, handling different packages using them 
  same macro name with different meanings, etc.

  I strongly advise against this feature.

  Reassigning to Joe English for a second opinion.


login: boakley
username: boakley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=249075

  I'll admit the "I don't like how [strong] looks..." is a 
  bad example.

  If we think it shouldn't be exposed to the end user, I 
  still think it's a good idea for implementing the 
  individual formats, if for no other reason than to make it 
  so that mpexpand doesn't have to be modified every time 
  someone wants to add a new standard macro. 

  Personally, I still think it should be supported. We should 
  discourage its use in general, but having document-specific 
  macros could be a real time-saver for document authors. We 
  could always make it where a document can't redefine a 
  macro, but can only define new ones, if we're concerned 
  with maintaining the visual appearance.

  One of the goals of the doctools is to make it easy to 
  write standard formats for man pages. For me, the key word 
  here is "easy", and I think being able to create my own 
  macros would make it easier. 

  Perhaps I wouldn't want it so bad if we already had a 
  robust format definition, but we don't. Both times I've 
  tried to use it I've run up against small obstacles in 
  creating a standard man page. The first was the case of how 
  the synopsis was generated, the second in creating a 
  section detailing widget options. I'm sure there will be 
  others until doctools becomes a bit more mature.

  Maybe it would help if we tried converting some of the 
  standard tcl and tk man pages, just to see where some of 
  the holes are in the existing set of macros.


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

  I agree with Andreas -- user-defined macros that expand
  directly to html/nroff/other output notations are not a good
  idea.  You'd have to include a separate implementation for
  all the known output formats, plus all the ones that you
  don't know about yet.  Since the latter is pretty difficult
  :-), I think this is a non-starter.

  However, [proc] *is* a legal doctools command (although this
  isn't documented, I believe it is intententional), so you
  can write your own macros that call other doctools
  routines.  This would take care of things like a copyright
  macro, application-specific table types like "WIDGET
  OPTIONS", et cetera.


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

  Ok, we will not add a generic macro facility to
  doctools.

  We will add some more commands which will bring
  it nearer to TMML, and the rest can be handled
  by [proc]s in the manpage themselves.


login: beric
username: beric
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=493507

  Hello,

  I have done some bug / style fix since I have used it in
  real application.
  Here is the latest version.


login: boakley
username: boakley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=249075

  Yes, I'll try to find time to review it, though it might
  take me a couple days. What sort of review are you looking for ?


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

  How good a fit is this for tklib ? Coding standards ?
  Completeness of the submission (Documentation present ?
  Testsuite present ?). Does the API make sense ? Is that
  something you would find useful for yourself and use as well ?

  A meta-topic to consider: There is not much in tklib yet, so
  anything we add now will at least partially set the tone for
  future packages.

  I placed the burden on you as I am not that much of a Tk
  person, whereas I believe you are such :) I hope that is ok.


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

  Committed the attached code head, after fixes in the .man
  and .test files. The .html and .n files are generated,
  therefore left out.


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

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

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


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

  i don't mind fixing bugs, but this is a feature request 
  without any clear set of requirements...someone else needs 
  to worry about it.

  /mtr


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

  My apologies. As I find out that working fulltime with tcl
  over the day leaves not much energy for doing it in the
  evening. This has created not very nice backlog of things to
  do.

  Patch committed. Note that the part of the patch dealing
  with "mime.tcl" is already covered by the patch for SF
  #477088, committed Nov 1, 2001.


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

  Note that the patch as provided here is malformed. Manual 
  application is performed.


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

  Logged In: YES 
  user_id=202636

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

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


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

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


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

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

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

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

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

  rolf


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

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


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

  Committed a fix. Cleaned up the selection code a bit beyond 
  this. Added proper argument checking and extraction, 
  documented some undocumented subcommands and 
  options, added toggling of selection per Control-Button-1.


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

  As of RFC-2616 sec. 14.17 Content-Type header have format:

    Content-Type = "Content-Type" ":" media-type

  Where media-type is (sec. 3.7):

    media-type   = type "/" subtype *( ";" parameter )
    type         = token
    subtype      = token

  ncgi.tcl attempts to recognize just ``type/subtype'' part, not the
  optional parameters.  It's an error.


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

  In my environemt I get an error message

  % base64::decode ""
  can't read "output": no such variable
  %

  Is that what you mean by crash ?
  If not my next question is: Do you have Trf installed ?


login: chdamm
username: chdamm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=274893

  I also get

  % base64::decode ""
  can't read "output": no such variable

  so that's what I meant by crash.

  I don't have Trf installed.


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

  Ok. I had to ask because ifTrf is installed it used that 
  and so this entry could have been an error in Trf.


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

  Larry,

  Can you tell me which parts of this bug report are against
  the ftp module of tcllib as opposed to hpupdate?

  That way I can go hunt down and kill the offending bug(s).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 23208: pat.yencode.test.txt

  Logged In: YES 
  user_id=75003

  Attaching a patch submitted by Larry Virden to a bug report 
  of his.


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

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


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

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


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

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


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

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

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

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


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

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

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


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

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

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


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

  Patch committed, with slight changes to the error messages.
  Also committed the associated patches for the graph
  structure.


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

  I see the same notice on my 32-bit Solaris machine.
  Perhaps this is an intended feature of the test?
  Is this message seen on other platforms as well?


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

  Checking ... I see them on my linux 32bit machine too.
  Source dive ... uuencode.tcl, line 62, proc uuencode::pad
  Uses the log package to generate the warning.


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

  I should delete this message. It is just an alert to notify
  us that a provided uuencoded string is technically invalid.
  That is the generating program didn't pad the string out to
  a multiple of four characters. We therefore pad it with some
  nulls which may end up in your decoded result.

  If it's a uuencoded file then the line carries the number of
  chars so it's not a problem but if you are decoded a simple
  string you'll get some spare nulls - hence the notice.

  In short - this isn't a problem, it's just noise.


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

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


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

  Logged In: YES 
  user_id=400048

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


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

  Logged In: YES 
  user_id=80530

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


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

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

  Committed to head.


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

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


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

  OK. It is modified as suggested.

  I will enter it in cvs in a few days I hope.

  Jean-Luc


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

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

  Please let me know if that is possible.

  Thanks.

  Jean-Luc


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

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

  Anyway

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

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

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


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

  I would very much like to fix that.

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

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

  Thanks.

  Jean-Luc


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

  Logged In: YES 
  user_id=15949

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

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

  Can someone fix this in the cvs?


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

  i agree.

  andreas - please remove the "#" in front of the error 
  statement.

  /mtr

  ps: i'm not sure who was taking care of this package after 
  i initially wrote it, but geez...


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

  the actual problem was that the key was for some reason 
  changed.  I removed the special casing of end in 3 instances, 
  since that has been a recognized valid index since at least 
  8.0.  Fixed in 1.4.1.


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

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


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

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

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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 24607: 564670.diff

  Logged In: YES 
  user_id=75003

  Reason for the problem: Usage of [dns::configure] during 
  variable initialization, before the command is actually defined.
  Moving code to the end. Patch enclosed.


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

  This is a TCP versus UDP problem. While DNS/tcp is not 
  blocked by the firewall (as initially suspected) it is the DNS 
  server itself in this particular configuration which is UDP only, 
  and thus not usable with this module.

  On a different machine dns::resolve worked as expected.


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

  This isn't a programming problem so I'll close this. At some
  point we should enhace the code to use UDP if available but
  I don't need this so I don't imagine I'll find the time.


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

  I have confirmed that this is the case with the attached 
  script using 8.4.0.1b2.  Don't know if it is a BWidgets 
  quirk or something more subtle in Tk though.


login: todolson
username: todolson
mimetype: text/plain
icomment:
  File Added - 24471: csv.tcl

  Logged In: YES 
  user_id=450877

  A revised version of cvs.tcl is attached.  Still csv package
  version number 0.2.


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

  There is a bug in split parsing, but it is not in the handling of 
  inner fields. It is the outer fields, i.e. first and last which are 
  off, i.e. wrongly handled.

  The string {"" "" ""} parsed with separator character <space> 
  does not contain three empty fields. It contains 3 fields each 
  of which contains a single ". See the definition of the CSV 
  format. This might be even more clear when parsing {"","",""} 
  using the comma as separator character. An empty field is 
  specified by two adjacent separator characters without any 
  intervening other characters. In the case of <space> this 
  means a space following a space, or a space at beginning 
  and/or end of the string.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 25748: 565051.diff

  Logged In: YES 
  user_id=75003

  Here is a patch for the true problem. Contains an extended 
  testsuite.


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

  The files left behind are intentational. The represent internal 
  targets which are done. Without that we get a full regen of all 
  documentation whenever we say "make install".


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

  yes.

  I'm still not happy about the *-doc files, but that's not so
  much a bug as a design disagreement.


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

  Install.tcl is for use by source distributions. A CVS snapshot 
  is no such. install.tcl does not support CVS snapshots. A 
  CVS snapshot currently requires 'configure ; make install'.

  Changed the script to notify the user of this.
  Keeping open, want to change this.


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

  Ok, I consider this fixed: The .sh/.bat files and the old all-tcl 
  installer are discontinued and removed, and the new all-tcl 
  installer correctly handles installing from either src-dist or 
  CVS snapshot.


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

  The  crc32 test code checks that the Trf crc's and tcl crc
  values are the same. You can explicitly call each one even
  when Trf is available by using crc::Crc32_trf and
  crc::Crc32_tcl.
  As far as I can tell these two functions are producing
  identical results. Can you post a set of tests that
  illustrate the incorrect value and give the version of
  tcllib and trf that you are using.

  The crc package and Trf zlib values should be identical.


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

  Nothing happening. As this works for me I'm closing it to
  this effect.


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

  This request appears to be a duplicate of tcllib 
  FR # 514475 [Virden].

  On reflection over a conversation that dgp and I had this
  past weekend, I now wonder whether ::struct is actually
  the best place for the putative [listx] command. All the
  other exported commands in [::struct] present object-based
  interfaces. For example, one creates a queue with
  the [::struct::queue] command - and the newly-created
  queue appears in the command namespace. It's the same
  for graph, matrix, stack, tree, and so on.  I don't think
  this type of interface is what anyone has proposed
  for [listx], so it seems a poor fit to the [struct] package.

  Nevertheless, we do need the thing *somewhere* -
  Don, are you ok with using FR # 514475 as a placeholder
  for this issue?


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

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


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

  Just tried

  % t move root 2 node0
  % t children root
  node1 node0 node2
  % t index node0
  1

  It seems to be an off-by-one problem in 'move'.


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

  Ok, I looked deeper and it is truly more complicated than that.
  I accept the patch. It seems to be the best solution. I will add 
  some clarifications to the manpage as well.


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

  Bug was introduced when rewriting the HTML format to be able
  to generate various TMML lists, and either compact or
  wide-spaced lists. It now generates the HTML escapes to
  early, in the rewritten HandleText.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 26627: 578465.diff

  Logged In: YES 
  user_id=75003

  Patch fixing the problem, confirmed by submitter.


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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 28560: 582668.diff

  Logged In: YES 
  user_id=75003

  The attached patch should fix the problem. Please check.


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

  Writing this file is code for debugging the testsuite. It is not 
  used by the testsuite itself. Deactived this call and rewrote 
  the 'makeFile'-call and the usage of spawn to allow an 
  arbitrary setting of -tmpdir.


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

  What module are we talking about ? 'counter' ? or 'html 
  display' ? Or is html display a command in 'counter' ?


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

  The ncgi functions are used in "counter" in the following proc:

  counter::histHtmlDisplayRow

  The package ncgi isn't required.


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

  submitter mailto:
  Jussi Kuosa <Jussi.Kuosa@tellabs.com>

  Items 2. and 3. fixed.
  Item 1. is to ambiguous. I don't know
  which part of the code to fix.

  See also
  2002-01-16  Andreas Kupries
  <andreas_kupries@users.sourceforge.net>

  * nntp.tcl: Fixed bug #502250 reported by Andreas Otto
    <aotto@t-online.de> which caused the package to wrap each
    message into braces, causing nntp servers to reject the
  data.

  Is this message about tcllib 1.3, nntp 0.2 ?


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

  Private conversation: Submitter used tcllib 1.1 containing the 
  problem. Tcllib 1.3 is fixed.


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

  Argghhh...I forgot to check the upload box (why does it need
  to be there, anyhow, when you've obviously selected a file?)
  See *next* post.


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

  Please see the attached cmdline.tcl file, which 
  includes a new proc "cmdline::parseargs". 

  Here is a usage example: 

  cmdline::parseargs \ 
  {startPath.arg {safeFlag} port.arg {host.arg 127.0.0.1}} \ 
  {stuff {morestuff 0}} $argv 

  This gives the proc the following cmdline: 
  -startPath <path> -port <port> ?-safeFlag? ?-host? 
  stuff ?morestuff? 

  It's been a tremendously valuable proc for my own work. 
  Enjoy -- it's yours. If possible, I'd appreciate 
  inclusion of the credit line in the file head (see 
  attached file) but you can take it out if you want. 


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

  Can you extend the usage example a bit ?

  I would like to see a complete procedure which calls
  'parseargs' to handle its own arguments.

  The reason I ask is that I am unsure about 'args' argument
  of 'parseargs'. Depending on how you intend to call the
  command the name is ok, or wrong. ... This may also factor
  into the 'singleVarFlag' code. and some other I saw later.
  I definitely need a complete example for a procedure here.
  Your example is for an application, using argv.

  Other comments and questions

  The automatic usage of -h|--help will interfere if a command
  has its own -h|--help to process.

  What happens if an option with an argument has no default
  value, and is not present in the argument list. Will a
  variable be set ? If yes, to what value. If not, what
  happens to an pre-existing variable of the same name.

  The command seems to assume that the variables it is setting
  in the callers context are scalars. What happens if a
  variable exists before the call, but is an array ?

  Do you have a testsuite for your command ?

  I have to admit, this [subst] construct at the end
  of the procedure looks a bit scary. I believe it is possible
  to rewrite that without subst, and using 'upvar' instead of
  'uplevel'. I won't start on this however until I have more
  understanding on how the command should work.

  I am also suspicious of this 'massage selected list if
  multiply escaped' code. Can you explain me in what situation
  it will kick in ?


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

  I suspect this is due to Tk/Aqua issues, like Tk bug 653895, 
  not bwidgets related.


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

  The man page I am seeing says this:
   
  FORMAT
       Each record of a csv file (comma-separated values, as
  exported
       e.g. by Excel) is a set of ASCII values separated by
  ",". For
       other languages it may be ";" however, although this is not
       important for this case (The functions provided here
  allow any
       separator character).
   
       If a value contains itself the separator ",", then it
  (the value)
       is put between "".
   
       If a value contains ", it is replaced by "".
  ---- 

  1. the format is a bit off in the man page - it probably
  should be 
  (the functions ...)
   ^                                                         
              

  2. The "it" in the third point is a bit vague - probably
  should say something
  like "If a value needs to contain the " character, the
  character must be 
  represented as "".
                                                             
             
  2. I don't see anything here that references missing data.
  And that was the
  point of at least 2 or more bug reports.


login: todolson
username: todolson
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=450877

  The package certainly works as advertised.  However, there
  are many applications that generate the ill-defined CSV
  format. The most common CSV files that I see are exported
  from MicroSoft Access, such as what was provided in the
  original bug report. The utility of this package would be
  greatly improved if it could parse files exported from these
  programs. Otherwise, those of us who deal with such data
  have to roll our own CSV parsers, as some of my collegues
  do, or patch every release of tcllib.

  I could easily provide a small number of test files which
  include the awkward cases.


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

  Actually there is a sampledata file in the attached tarball. I 
  am looking into this now.


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

  Committed changes to head. Please test. The testsuite has 
  one of the new cases marked as knownBug. I.e. this code is 
  completely correct, but handles the majority of cases. It 
  dislikes "" inside of a value and handles that incorrectly.


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

  Did a complete rewrite of the parser for the alternate syntax. 
  The one I committed last was a derivate of the original parser 
  and simply could not handle the nested "". The new parser 
  just splits into the primary tokens (", sepchar, remainder) and 
  then converts the token sequence through a tcl-coded DFA 
  (state-machine). This is able to detect an embedded "" 
  sequence correctly.

  Committed now. No known bugs in the extended testsuite. 
  Full pass.


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

  would you please do

      diff -c oldfile newfile

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

  thanks,

  /mtr


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

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


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

  same problem in tklib:

  Index: Makefile.in
  ==================================================
  =================
  RCS file: /cvsroot/tcllib/tklib/Makefile.in,v
  retrieving revision 1.2
  diff -u -r1.2 Makefile.in
  --- Makefile.in 26 Feb 2002 08:04:26 -0000      1.2
  +++ Makefile.in 16 Sep 2002 03:45:26 -0000
  @@ -44,7 +44,7 @@
   
   DESTDIR                =
   
  -pkglibdir      = $(prefix)/lib/@PACKAGE@@VERSION@
  +pkglibdir      = $(libdir)/@PACKAGE@@VERSION@
   
   top_builddir   = .
   


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

  The command .pg is created, but does not work as expected.

  % .pg configure
  unknown option -geometry

  % .pg configure -bg red
  unknown widget .pg:cmd  


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

  Since this seems to never have worked ... you can set all the 
  options to start, but not change them.  BWidgets is fairly 
  obtuse with the arg handling here.


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

  Maybe its an error in the call of cmd, is there a ":" missing? 
  Would .pb::cmd work?


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

  hmmm... when i run your test code, the two lines that are
  printed are the same, so "it works for me".

  what are you getting?

  /mtr


login: giggls
username: giggls
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=293301

  looks like the Problem has gone in tcllib 1.3 so you may
  close this.

  Regards

  Sven


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

  The tests pass on tcl 8.4.0. The first failure is due to the
  new lindex syntax which returns the entire list if the
  second argument doesn't exist. Fixed this (it was a mistake
  anyway).

  The second one I am investigating. Under both 8.3 and 8.4
  the polynomial lookup table is generated correctly but the
  calculation is coming up with the correct numbers under 8.4
  and not under 8.3. I'm investigating this. I presume it's
  some kind of 64bit dependency.


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

  The issue turns out to be this:

  tcl8.4: 
  % format %#x [expr {0x80000000 >> 8}]
  0x800000

  tcl8.3:
  % format %#x [expr {0x80000000 >> 8}]
  0xff800000

  Fixed by masking off the exposed bits.


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

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


login: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 32747: diffs.txt

  Logged In: YES 
  user_id=24077

  what's going on here, i think, is that in one case Trf's
  base64 is being called and on the other system, Tcllib's
  base64 is being called.

  it appears to be that the routines aren't identical in the
  sense that one has a "\n" at the end.  since the copymessage
  routine chunks at 32766 octets, this explains why a "\n"
  shows up in the file.

  try the attached patch and see if it works


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

  I tried this patch and the behaviour is still the same.
      --Jasper


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

  Ok, I tried my hand now. I can confirm that the new
  character comes in after 2^15-1 characters, and at the very
  end. Trf has no influence on this either. The problem
  happens with and without.

  New finding: Base64 is no problem either. Looking at the
  intermediate file model.mm1 I see that quoted-printable was
  chosen.

  Another new finding: When looking at the equivalent position
  in model.mm1 (line 488, .cnv = line 152) I do _not_ see
  additional newlines. In other words, the characters are
  _not_ added during writing. This exonerates copymessage.
  They have to come in during _reading_ and we have to look at
  'getbody' instead.

  Urrk. That looks like a complex state machine ... value,
  canonicalP, encoding ... Ok, we know the latter one. ...
  canonicalP as welll ... This seems to be in this while loop
  going through the input in some chunks ... With and without
  Trf, so mime::qp_decode is most likely not the culprit. I
  will have to look deeper at this loop.


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

  Arg. Got thrown off, the same data is a bit earlier than the
  line in question. It is a 492, and in the output, i.e.
  model.mm1. Ok, it is still copymessage to look at. Stopping
  now, evening, obviously my mental capacity is going down.


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

  I believe I found it. In command 'copymessageaux', near the
  end (lines 1637, and 1639), we have two puts commands. These
  should use 'puts -nonewline'. The reason: We are reading the
  input with read and convert it, so the output of the
  conversion has to be written without newlines. The converter
  is itself responsible for the insertion of newlines where it
  sees fit.

  This asymmetry of reading/writing caused the problem.


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

  Fix committed to cvs head. Added a testcase to the testsuite
  as well. Thanks Jasper, for the report, and your patience.


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

  Laurent,

  I just tried your example and encountered no problems.

  Please verity weither you are still having the problem and
  post results here (you may want to put an unset trace on i
  and print out the call tree at that point).

  If I don't see anything in a week or two I'll close this bug
  as non-reproducable.


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

  I've tested this with 1.88 and it seems to be working fine.
  I'll check it in later today.

  Nice work. :)


login: pascalscheffers
username: pascalscheffers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=582857

  Added a highlight [while] loop to mark all occurences in one
  go and then start jumping through the results.


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

  I see what you mean and I have implemented this request.

  It would be more helpful to provide a context diff (diff -c)
  and also to  generate your diff the right way round in
  future (diff -c oldfile newfile > patchfile). However, the
  idea is good and is now checked into the CVS tree.


login: gionco
username: gionco
mimetype: text/plain
icomment:
  File Added - 34048: patch_from_1.3

  Logged In: YES 
  user_id=635197

  Ok, here is the context diff, with some other similar
  patches I've
  added in other cases (after HELO, QUIT, etc...)


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  File Added - 40901: bwidget-tree-lsearch.patch

  Logged In: YES 
  user_id=68433

  Previous patch (against rev 1.37) no longer applies cleanly.
  Uploading refreshed patch, generated against current HEAD
  (rev 1.38).


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  File Deleted - 40901: 



  File Added - 40903: bwidget-tree-lsearch.patch

  Logged In: YES 
  user_id=68433

  Oops.  One more time, this time against the *current*
  current HEAD (r1.39).


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

  I get the same thing when uing ActiveTcl 8.4.1.0 on a Linux
  (Mandrake 8.2) box. Here the error is 
  Cannot open libmd5crypt.so
  --Jasper


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

  Once upon a time the Trf package included some crypto
  functions. These have since been split off into the Trfcrypt
  package but the md5 function remains in the core Trf but
  depends on something that comes with Trfcrypt.

  The mime package should be modified to cope without Trfcrypt
  in the way it currently handles missing Trf. 

  In fact - better would be to fix mime to use the tcllib md5
  package, and then fix the md5 package to check that the md5
  call actually works. This is a bug for the md5 package too.


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

  I've checked in a small change to use the tcllib md5 package
  if Trf isn't available. The md5 package tries to use Trf and
  then uses a tcl only implementation if Trf isn't available.
  This bug is also present in the tcllib md5 package - but
  we'll handle that to.


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

  Done for bug #649383.

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


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

  Logged In: YES 
  user_id=240

  The attached patch seems to make the problem go away, but I
  don't know if it really fixes it.  It still passes all the
  tests.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 44163: 14167

  Logged In: YES 
  user_id=240

  Uploading a spam file that triggers the bug.


login: kripke
username: kripke
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=282725

  this properly errors out if you remove the # comment from
  the line
  error "termination string missing ..." (in mime 1.3.2)


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

  yes, we should remove the '#' character to get the original
  behavior.


login: zoro2
username: zoro2
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=191529

  Here's my patch to mime.tcl, which seems to handle things
  better than davidw's patch:

  --- mime.tcl.orig       2003-06-11 22:22:18.000000000 +0200
  +++ mime.tcl    2003-06-11 22:24:56.000000000 +0200
  @@ -682,10 +682,11 @@

       set inP 0
       set moreP 1
  +    set retries 0
       while {$moreP} {
           if {$fileP} {
               if {$pos > $last} {
  -        #        error "termination string missing in
  $state(content)"
  +                if {[incr retries]>50} {error "termination
  string missing in $state(content)"}
                    set line "--$boundary--"
               } else {
                 if {[set x [gets $state(fd) line]] < 0} {


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

  Reopening because the fix in CVS doesn't seem optimal.

  Further thoughts:

  1) Mime should try and parse even bad data, by default, on the
     principal of "be liberal with what you accept".

  2) Maybe we should have an option to tell it to be strict,
  in which
     case it errors out on bad data?


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

  well, the "official practice" when encountering bad mime
  data is to wrap the thing inside an application/octet-stream
  and declare victory. experience shows that any other
  recovery strategy just doesn't work.

  perhaps the thing to do here is to keep the "error ..." and
  put a wrapper around the proc that creates an
  application/octet-stream bodypart.

  /mtr


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

  I committed two of the spammy email messages as well as two
  new test cases to CVS, in order to have something to test
  this problem against.


login: eee
username: eee
mimetype: text/plain
icomment:
  This bug is open more than ten years. It need sto be revalidated and either fixed or wontfixed. Poking the priority to fraw attention.


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

  Yes, it is. This was a problem in the main Makefile of
  tcllib and has actually been fixed for quite some time in
  the CVS.

  Here's the entry in the changelog

  2002-08-15  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>

  * Makefile.in (DOC_EXP): Use the tclsh found during configuration
    to run mpexpand. This ensures that mpexpand does not pick
    something from the path on its own, possibly something too old
    to understand TCLLIBPATH. Problem noted by Elchonon Edelson
    <edelson@pobox.com>.


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

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


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

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


login: rokar
username: rokar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=612057

  I am really sorry - it really looked like that, but the mail
  client I used did not
  read a 250-.... line and run out of track ....


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

  Feel free to hand off any of these that I have submitted to
  me to close/commit - I have the time at the moment.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  File Added - 35487: latest3.diff

  Logged In: YES 
  user_id=240

  This patch fixes the problem, and, IMO, makes the code
  cleaner and more compact.  It passes all the tests,
  including those added by this patch.


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

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

  Yes, I found and fixed that when I wrote the testsuites for 
  pop3 and pop3d and testing them against each other.


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

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

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


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

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

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

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

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

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


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

  David, I have no knowledge of docbook, but hope that you
  have. See the TMML engine for an example generating XML
  output. Do you believe you are able (and have time) to use
  this as template to create a docbook engine ?


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

  I could probably make it work, but unless there were a
  concerted effort to move to docbook itself, in some ways I
  think it might not be worth it - mostly because it probably
  just won't buy is that much. Maybe we should flag this bug
  'pending' or close it.


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

  Hm. Would a docbook backend buy us some connection to
  debian, or other linux distribution, i.e. better docs for them ?


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  File Added - 37972: tkchat.patch

  Logged In: YES 
  user_id=241231

  Updated comment for the second patch


   This code provides to highlight interesting text in the
  tkchat message window.

  The user interface can be invoked in two ways:
  1.) Through the Find entry on the FIle menu.
  2.) By entering /find in the message post window.
  (command line) The /find command may have an optional
  argument, which will then be used as the search string.

  To highlight an exact string or regexp pattern, enter
  it in "Find text" field. All matches in the chat
  window will be highlighted. Should the search be a
  time consuming one, it will pause when the Find dialog
  is closed and resume when it is re-opened.

  To remove all highlighting, clear the "Find text" field
  in the Find dialog.

  Known caveats:

  Sub-strings are not highlighted separately from the
  rest of the matching text when using regexp
  sub-matching. The whole match will be highlighted the
  same. This is a limitation of of the [text] -search
  command.


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  EE, Thanks for all your help as I tried to get up to speed
  on these development tools.

  -- Luke Myers


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  Looks like there were two identical .tar.gz archives added.
  I will try to delete one duplicate...


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=241231

  Hmm, it says:

  File Delete: ArtifactFile: Permission Denied

  well, that's okay since they are identical AFAIK


login: lukekalemyers
username: lukekalemyers
mimetype: text/plain
icomment:
  File Added - 38579: patch.diff

  Logged In: YES 
  user_id=241231

  Yet another revision. This patch includes support for
  navigating between results in the chat window and obsoletes
  all previous patches.


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

  We have applied another patch for a find function that uses
  /?regex typed into the entry widget. However, we might want
  to add a Find menu item like this too.


login: eee
username: eee
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=661010

  This is a duplicate of patch number 654976, was mistakenly created as a new patch instead of simply updating that one. This has been corrected, so I'm closing it.


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

  There are no files attached to this item. Stupid SourceForge
  (There is a checkbox you have to check for upload. When you
  forget no attachment is created. And it is easy to forget).

  Please attach the necessary changes. The changes to tclvfs
  should be reported in the tclvfs project and not here.


login: ddrogahn
username: ddrogahn
mimetype: text/plain
icomment:
  File Added - 45940: ftp.patch

  Logged In: YES 
  user_id=676429

  I hope I wasnt that out of it to not check the checkbox, I 
  seem to recall the help next to the checkbox was the wrong 
  item (so maybe the checkbox was having issues too)

  Anyway... I've figured out diff a bit since then, so hopefully my 
  patch is a bit easier to work with.
  (and I'll check to see the file got uploaded this time)


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

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


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

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


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

  Hm.

  "$tag -== 15" is line 554 in the current codebase.
  And the nearest applicable variable I see is "val", not "value".
  At last I count 11 references to $v. These are enough 
  differences to make me hesitate in simply changing the code 
  without knowing what you actually changed in your code to 
  make it work.

  Please create a patch detailing your changes and either 
  attach it to this report, or send it directly to both 
  <andreas_kupries@users.sourceforge.net> and 
  <andreask@activestate.com>. Thanks.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 46502: exif.patch

  Logged In: YES 
  user_id=75003

  Got the patch. I see that that the change was to rename 'val' 
  to 'v' and correct the places refering to 'val' instead of the 
  places refering 'v' (of which we have more).

  There also spelling fixes, additional tags, exporting a 
  thumbnail file if possible, and interface changes (stream to 
  file). Regarding the latter I will change the code to provide 
  both interfaces, without losing the thumbnail stuff.


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

  Patch applied. File based interface added. documentation 
  updated. No work on the jpeg stuff and usage of Img. Better a 
  separate feature request. Code for that left in, commented out.


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

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

  - Bryan


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

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


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

  I see the index script fix.  

  Now add a

      package require Tcl 8.3

  to irc.tcl to complete the fix.


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

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

  Added storage for memo messages to an mbox format file
  ~/.tkchat_msgs. Need to add a diaplay dialog to list and
  show them.


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

  I have corrected the source code and the documentation
  w.r.t. the remarks by Andreas and Larry


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

  Arjen, as tcllib developer you should have write access to the 
  CVS of tcllib. In other words, you should be able to commit 
  this.


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

  I have not tried this yet - out of "coldwater fear" :) Let
  me try though ...


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

  This has been committed by Arjen. some minor formatting 
  work by me now too.


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

  That is actually a feature showing you the "view" window 
  functionality of trees.


login: vwartelle
username: vwartelle
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=157122


  Joined suggested patch for tree.tcl in the "demos"
  directory.

  V.Wartelle.


login: pascalscheffers
username: pascalscheffers
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=582857

  I fixed this by adding a regexp for multiline actions and
  handling those the same way as multiline messages and
  helptexts are handled.

  Fix is in CVS tkchat.tcl revision 1.94 


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

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


login: 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: 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: jaspert
username: jaspert
mimetype: text/plain
icomment:
  File Added - 42845: buginfo.tgz

  Logged In: YES 
  user_id=456242

  Oops, seems my files didn't get uploaded, I'll try again 


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

  The attached patch is not a self-contained example.  Could 
  you narrow it to a smaller code snippet?


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

  You should be able to reproduce the problem with these files. I 
  didn't develop this code I am just trying to port the tool to Linux. If I 
  have time I'll try and find a simpler procedure that causes the 
  segfault. 


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

  When trying with those files and your example, it complains 
  about a missing image and nothing works ... perhaps rework 
  without the images?


login: jaspert
username: jaspert
mimetype: text/plain
icomment:
  File Added - 43020: mre.tcl

  Logged In: YES 
  user_id=456242

  OK I've edited mre.tcl and removed the references to other things 
  that were lying around my system (I hope...) Also I found that after 
  the frame is drawn by the RunEnv::Create dummy command, you 
  can get the segfault directly with the command 
   
  .mre.mainframe.frame.mainpw.mainDisplayPane.notebook.fpage/1.panedwindow 
  sash place 0 2 5 
   
  (but change that last 5 into an 8 and it accepts the command) 
  Hopefully that makes it easier to trace 


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

  It's much easier on developers when problems like this are 
  distilled down.  This can be repeated in 3 lines of code:

      panedwindow .p
      .p add [frame .f -width 20 -height 20 -bg pink]
      .p sash place 0 2 5

  It's also a core bug, not a bwidgets bug.  Please reissue in 
  the Tk tracker (unfortunately SF doesn't allow moving bugs 
  between projects).


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

  I went ahead and fixed this for 8.4.  The code is actually an 
  error - the first sash only exists when 2 panes exit.  This is in 
  8.4.2.  You will get an error now from your original code 
  sequence.


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

  Just send the patch to 
  <andreas_kupries@users.sourceforge.net> and I will attach 
  the patch.


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

  I believe this is out-of-date.  Please reverify with the CVS 
  head of bwidgets.  IOW, it works for me.


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

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

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


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

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

  See md4.tcl for how it will look.


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

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


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

  The refresh button got removed. This bug has since been
  dealt with.


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

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

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

  What other ways of starting a page do you envision ?

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


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

  Currently there is not much. Engines may 
  support 'parameters'. The HTML engine supports

  meta, header, footer, xref

  meta - Insert HTML code immediately before </head>
  header - Insert HTML immediately after <body>
  footer - See header, before </body>
  xref - cross reference information

  meta for example can be used inject a CSS reference into the 
  generated HTML. I do this for the ActiveTcl docs to get the 
  AS specific colors, fonts, etc.

  The tags themselves cannot be changed. For this you have to 
  take the existing fmt.html engine and modify it to your liking.

  NAME/DESCRIPTION settable could be done through 
  parameters. Optional ... More difficult.

  I had talked with Joe English about this too. Parameters was 
  one possible approach and so far the ine easiest for me to 
  implement. Other approaches are to write an egnine in some 
  OO system and then generate customized engines by 
  derivation or aggregation. [incr Tcl] for example is more 
  geared towards inheritance, and SNIT better if you use 
  aggregation (wrapping + delegation).

  Given the above this is at least partially out of the scope of 
  doctools. The engines which are present are useable, and 
  also examples for people wishing to write their own engines, 
  or wishing to customize the existing one more heavily.


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

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


login: kennykb
username: kennykb
mimetype: text/plain
icomment:
  File Added - 45770: list.test

  Logged In: YES 
  user_id=99768

  Verified using TDK that list.test has full (line-based)
  test coverage of the source code.


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

  Created subpackage struct::list in module struct of tcllib,
  as per our discussion in the tcler's chat.


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

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

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

  Refering bug to Brett first.


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

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

       --brett


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

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


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

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


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

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

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

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

  Thanks


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

  Sure, no problem at all.

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

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


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

  Logged In: YES 
  user_id=15949

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


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

  Larry, your attachment is present.

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

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


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

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

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

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

  Perhaps Trf is already fixing the byte order?


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

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

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

      array get tcl_platform

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

  ==== crcbugs-0.0 FAILED

  modules/crc/sum.test


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


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

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

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


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

  Why not use the more complete native Tk core spinbox in 8.4 
  which already has this behavior?  Otherwise, can you please 
  provide a diff -u patch of the file against the latest BWidget 
  spinbox.tcl.


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

  This is a nice feature, but not a bug, and this is already a 
  feature of the core spinbox, so I won't add it now.


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

  Can you please submit a small standalone code fragment that
  reproduces this fault. For instance,

   % package require BWidget
   1.6
   % LabelEntry .le0 -label Label -labelwidth 20 -labelanchor
  w -textvariable  ::_le0
   .le0
   pack .le0 -side top -fill x

  works fine for me. This is with the current CVS head for
  BWidgets.


login: aspenlogic
username: aspenlogic
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=494080

  Any word on this bug? Is it pilot error or is there a real
  problem with the widget?


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

  We would need to be able to reproduce this to call it not pilot 
  error.  You are sourcing a site-specific file, so anything might 
  have gone wrong before Bwidgets was used.


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

  I believe this is a 8.3 / 8.4 difference I inadvertently added in 
  there.

  Fast testing. This went in maybe an hour ago :)
  Thanks.


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

  Fix committed to head. Made 8.4 message the message 
  shown, and updated the test suite to use this instead of 
  something dynamically constructed.


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

  Checking ... not so for Linux. Seems to be windows 
  specific. "file type" code ... That is something we got from 
  Phil Ehrens.


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

  Relevant code section:

      } elseif { $binary && [string match "\x1f\x8b*" $test] } {
          lappend type compressed gzip

      } elseif { $binary && [string match "\x89PNG*" $test] } {
          lappend type graphic png

  It seems that the string match'es fail. (The 'binary' is 
  correctely detected, so the flag $binary is set).

  Reproduced on my Windows 2000 system. IOW, deeper 
  digging can be done locally. ... dump hex of pattern and data


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

  The testsuite creates a number of files which are then tested. 
  The creation step already fails. The bytes 0x89 and 0x8b are 
  both stored as 0x3f. The command used is 'tcltest::makeFile'.

  Now writing the files explicitly, using -encoding binary.
  Now the testsuite works. This is a problem in whatever tcltest 
  you are using. ... Mine is 2.2.2. We have to talk to Don Porter 
  now.


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

  Added a fix to the testsuite which circumvents binary data 
  issues in 'makeFile'.


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

  I do not get these errors when I tested the CVS head on Windows today. I have some other failures for install and relative path computations, but not for file type. Closing.


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

  Modified to continue reading from the socket until all data
  received.
  Added a catch clause to avoid any bgerror's.

  It's a bit hard to test this - none of my servers do this to
  me, but these fixes should avoid such a problem.


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

  It seems that bwidgets isn't correctly recreating some hidden 
  widgets that it gets info from.


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

  This is a general design issue of bwidgets, that you cannot
  destroy the windows that it uses that are hidden.  Someone
  will have to revisit this that wants to make bwidgets more
  easily reloadable.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Tim,

  could I just please you not to destroy the internal BWidget widgets.

  Thus modify your deletion loop like that:

  foreach ch [winfo children .] {
      if {![string match ".#BWidget*" $ch]} {
  catch [list destroy $ch]
      }
  }

  Thank you and sorry for the inconvenience.

  Harald


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

  Reassigning to me as David is out of reach for a while given 
  his move to Italy.


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

  On a linux system, and using either tcl 8.3.1 or 8.4.1.1
  I do not get these errors. This could be a platform
  specific problem.


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

  Applied a fix - check for possible zero sum values in
  profiler::stats. For tcl < 8.4 there are no execution
  traces, so no execution time stats available - hence the
  zero problem.


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


  I disagree.  Each package should decide for
  itself how to manage safe interps.  The most
  tcllib should do is decide whether or not to
  include a package if its safe interp management
  is not acceptable.

  I find it helpful to imagine whether a proposal
  would make sense if the package was released
  independently from tcllib.  If not, then it's probably
  the wrong thing.


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

  Agreeing with Don. It is not the packages in tcllib which
  have the problem per se, but the way tcllib as a whole is
  installed.

  A bad interaction between assumptions of the safeBase and
  how tcllib installs itself. The problem is that the safebase
  accepts (by default) only paths in auto_path _and_ their
  _immediate_ subdirectories for packages. But tcllib installs
  its packages in subdirectories of a subdirectory of a
  directory in auto_path. 

  So changing in the future to a flatter installation will
  solve the problem. 
  There are problems with doing so (see tcllib-devel mailing
  list) for the upcoming tcllib 1.4, so this report will have
  to keep open a while longer.


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

  We can not reporduce the problem with the curent (1.5)
  release of Tcllib.


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

  The new flat layout of packages in tcllib 1.4 has fixed this
  issue.


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

  These tests are actually meant to fail (see the
  description). They fail because in the version of tcltest
  that was used during development of the package, it was not
  possible to set up custom comparison routines.

  (It led to TIP #85 and the corresponding new version of
  tcltest. Perhaps it is time to update the test file.)


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

  No. Tests never fail(in the absence of bugs).
  If a test drives the functionality intentionally into an error state 
  then the test has to check that the error state has occured, 
  and report that as a sucess. And if the intended error state 
  did not occur, then that is a failure of the functionality, and 
  that is a failure of the test.

  Example (taken from struct, graph)

  test graph-0.1 {graph errors} {
      graph mygraph
      catch {graph mygraph} msg
      mygraph destroy
      set msg
  } "command \"mygraph\" already exists, unable to create 
  graph"

  We intentionally call commands in an illegal way, catch the 
  error message produced by the graph commands and check 
  that this message is the correct one. If it is the test is 
  sucessful. If the message is not right, then the test failed, as 
  something in the functionality is not as we expected it.


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

  Okay, that is a very reasonable (and probably the only good)
  solution. I will repair this and submit a new test suite


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

  Thank you. With a weeping eye. Did you run a cvs update 
  before your changes ? Or did you get a message about 
  conflicts when you tried to commit, and then copied the new 
  version of the one provided by the CVS ?

  Because the improved version is based on the code you 
  originally submitted, and thus overwrites the bugfixes and 
  cleanups I did. Especially the bugfix to make the file operable 
  overall as part of the tcllib testsuite.

  Ok, water under the bridge. I will now re-apply my changes to 
  your improved version to get these fixes back. However I do 
  ask you to make sure that your development is either based 
  on the code we have in the tcllib CVS, or to make sure that 
  your updates are correctly merged instead of simply 
  overwriting anything which was done with what is essentially 
  an old version with different changes.


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

  Committed re-applied fixes. Verified that the changes fix this 
  bug too. Done.


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

  I have been too hasty - I apologize. I did not do a cvs
  update. Curiously enough I also did not get any conflicts
  ... 

  I have not had the luxury to work with CVS these past few
  years (we switched to another product that I still can not
  feel at ease with), so I have to relearn the proper
  etiquette. 


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

  Have you checked that patterns are not allowed by the 
  documentation?


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

  > Have you checked that patterns are not allowed by the
  documentation?

  Yes.  The only user-level commands where it _might_ make
  sense are [$w exists ...] and possibly [$w index ...], and
  the documentation doesn't mention glob patterns here.


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

  This has been added to the CVS head. Note that the code is 
  not optimized for speed. (We could cache such information, 
  but currently don't).

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


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

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

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


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

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

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


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

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

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

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

  Committed the changes.


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


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


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

  Confirming that we have nothing in the interface of tree for
  checking the existence of a tree ... This is a request I
  have think longer about, given that it is possible to check
  for existence of the object in other ways ... Do other
  object systems (like [incr Tcl], XOTcl, SNIT, ...) provide a
  class method or global command to check the existence of an
  object ? Or do they rely too on the introspection
  capabilities of Tcl ?


login: davidhbigelow
username: davidhbigelow
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=664837

  Good point about introspection.  It did not hit me about that 
  until I spent some time trying to figure out how to detect this 
  so that I could avoid trying to create something that was 
  already there and dealing with errors.

  However, if we have the ability to destroy a tree using 
  the "myTree destory" - then we should be able to easily 
  detect it's existance within the same command set and not 
  have to jump to a more complicated string of commands to 
  determine existance (e.g., [string equal [info commands 
  myTree] myTree]) -- seems logical.

  Any Questions?

  Dave
  davidhbigelow@compuserve.com


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

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

  Oh, my error - analogous changes would need to be made for
  each setting of visited($node) in that function.


login: svenn
username: svenn
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=918049

  There is a complete example on  http://mini.net/tcl/8787 with 
  data and a picture of the wanted result. 


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

  Is that true? I will look into this - the $expression
  arguments turned out to be a problem in another module too,
  calculus. I will adopt the same solution.


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

  I have fixed this problem. The tests now all work. Still
  need to commit the new version.


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

  I found out through a second bug report that tree was not just 
  used here out of thin air, but is in conflict with a BLT 
  manpage. Fixed that.

  The topic in general is something we have to hash out among 
  all of us, on tcllib-devel. This should be kept on radar for after 
  the 1.4 release.

  For the 1.4 release I prefer specific bug reports about clashes 
  we can fix immediately.


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

  As of 23-04-2003 the stats module has been removed.

  Use cvs update -Pd to ensure that directories are (P)runed
  or created are needed.


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

  Changed sak, reverted changes to package provide.
  Comitted to CVS head.


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

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


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

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


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

  This has been added to tcllib post-1.4 as comm v4.1 with the -
  command callback option.


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

  andreas - just remove the comment symbol in front of the
  'error "termination string ...'


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

  Well, that was rather vague!  What I meant to say, but
  didn't was that the above two changes should be made to the
  dtp help cmdline data.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  I have tried to connect manually thru a telnet client. The
  server responds ok but as soon as I try to type something on
  the keyboard the errormessage is sent to me. I have
  contacted customer support for my email-service provider and
  (not very likely) maybe I will get a serious response in a
  couple of days. In the meantime if anyone has any ideas
  about what the cause of this might be I'd be thankful?


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Problem solved, it appears that the problem was that the
  emailserver only accepts connections over SSH. Perhaps a
  reason for considering an openSSH implementation in an
  encryption package ;-).

  In the meantime I will incorporate the use of a commandline
  SSH-client in the UIE communicator. Since most SSH-users
  have SSH installed, and if not can install it this should
  not be a major setback in peoples possible willingness in
  trying out UIE communicator.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Perhaps one might supply an enhanced error message. When
  this error occurs, try to connect through SSH instead?
  I think this would be very helpful as it most probably is a
  situation that will occur with many mailservers.


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

  Can this situation be detected in general ? If possible try to 
  create a trail of comminucation between the pop3 module and 
  the server without SSH in place:

  1. package require pop3
  2. package require log
  3. Enable logging or all levels.
  4. Divert logging into a file (optional)
  5. Run the pop3::open
  6. If 1-5 are in a script you can redirect the log output from 
  stdin and stderr into a file.

  A good error message will be possibly if and only if the 
  information from the contact with the mail server is good 
  enough to know that SSH is expected. I'd rather just 
  say "Problems with talking to server" than assuming that 
  SSH is asked for if the returns from the server do not state 
  this explicitly. Because that would be a bit of misdirection 
  and confusion for the user.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  What actually happens is that after the initial connect,
  i.e. replying with the server adress, anything sent to the
  server returns -ERR authorization first. When telneting I
  got this for every character typed on the keyboard. When
  using pop3::open, I did get a reply of +OK after user, this
  occured when password was sent.
  I'll have a look at this next week when I get home. The
  problem as I see it is that if one isn't aware of this, then
  it is going to confuse users. So some sort of information is
  needed. Perhaps a suggestion in the docs or somewhere to try
  Telnet if pop3::open fails, when telnet'ing this is much
  clearer as nothing at all can be sent to the server apart
  from the initial hello.

  But as I said, I'll have a look at this next week, and will
  see if I can get some definitive answers and such. It would
  be best of course if the servers had to reply with some
  meaningful error message, but alas that is most probably not
  going to happen. I'll post back here next week when I have
  investigated this further.


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  I have done some additional checking running a socket by
  hand thru tcl. The situation is as follows:
  After USER-command is sent the mailserver responds
  +OK
  -ERR authorization....

  however

  The connection is in fact correct and if I continue by
  sending command PASS I am logged into the mailserver.

  pop3-module will tell me that there is an error (since my
  mailserver sends two replies to the first command) and I am
  disconnected. It seems that if it first sends +OK then the
  rest could be disregarded?

  - Veronica


login: mindtrader
username: mindtrader
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=156789

  Workaround for now, removed the errorchecking catch around
  ::pop3::send $chan "user $user"
  ::pop3::send $chan "pass $password"

  Certainly not good in the long run but it works, just have
  to make sure to supply valid username and password.


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

  +OK immediately followed by -ERR without intervening 
  command ? That is seriously broken. A pop3 server is simply 
  not allowed to send more than one response to a single 
  command.

  That is not something we can handle automatically. We 
  cannot automatically detect if there is a second response 
  after the first. Well, we can, by waiting for some additional 
  response with a timeout, and assuming that nothing is wrong 
  if the timeout expires. This however slows the client down 
  considerably. I am not willing to support such in the default 
  setup. If anything this should be explicitly activated by an 
  option (i.e. expect two responses after USER and ignore the 
  second, or something like that). The workaround is fragile, 
  actually, IMHO, because it could also cause the client and 
  server to lose synchronization as there is one more response 
  in the pipe than expected. Or does the server does not send 
  a response after PASS ?

  In general I believe it is good to extend the documentation 
  with some general tips how to handle problems, like activation 
  of logging, using telnet, etc.


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

  Nothing has happened with this for a long time, no new info
  etc. Setting to pending, will auto-close in a few days.


login: ciffer
username: ciffer
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=856292

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

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

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

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

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


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

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


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

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


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

  Irrg.

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

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


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

  dup'ed by 817351 - working on making this handle namespace 
  correctly


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

  All subcommands for which it made sense, i.e. which were
  writing to stdout, now understand an option "-out file".
  When specified the output is written to this file. Note that
  the pre-existing option -out for sub-command 'map' was
  renamed to '-outdir'.


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

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


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

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


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

  Is adding a [catch] around the failing unset statement 
  sufficient to make the problem go away ?

  (The ftp code we have inherited here is very convoluted and I 
  am trying to get away with a change as minimal as possible).


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

  The line in question is an artifact of the udp support. It
  should have been removed. For tcp/37 connections we are not
  supposed to send anything but just await an answer. For
  udp/37 we have to send an empty packet first. Evidently
  FreeBSD's service is a bit on the strict side.

  I'll fix this so an empty packet is only sent if UDP is in use.


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

  With some testing it seems that the webpub server only
  responds to tcp connections. If you do a 
  set tok [time::gettime -protocol udp ntp.webpub.net]
  time::status $tok
  it returns 'error' and ::time::error $tok tells you it timed
  out.
  If you set the protocol to tcp then it's happy.

  UDP is used if you have tcludp installed. You can opt for
  tcp by using the -protocol switch.


login: jlewandowski
username: jlewandowski
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=790368

  My today work. Problem is in parsepart funkcjon in fragment:
  if {$pos > $last} {
  #error "termination string missing in $state(content)"
  set line "--$boundary--"


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

  this was fixed in response to a previous report. remove the
  "#" in the front of "#error".


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

  Missed the stupid checkbox for attaching files. So here it is as a comment:


  *** mime.tclMon May  5 09:14:49 2003
  --- mime.tcl.newMon Jun  2 16:05:50 2003
  ***************
  *** 3512,3518 ****
    error "unknown charset '$charset'"
        }
    
  !     switch -exact -- $method {
    B {
                set method base64
            }
  --- 3512,3518 ----
    error "unknown charset '$charset'"
        }
    
  !     switch -exact -- [string toupper $method] {
    B {
                set method base64
            }


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

  This is user error, not a bug.  Stop packing - bwidgets 
  controls that.


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

  I am sorry, but I don't understand your comments. This 
  problem is not occurring with the BWidgets pacakage version 
  1.4.1, so I don't uinderstand what you mean by user error. I 
  would expect backwards compatibility to be maintained. 


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

  what you wrote wasn't correct for 1.4.1 either, it just didn't 
  conflict with the gm, which is now grid in 1.6.


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

  I am sorry for bothering you, but I need a clear answer to this 
  issue I am having. So, are you saying that I shouldn't pack a 
  tk widget inside a bwidget control? Or are you saying that I 
  should use grid instead of pack? If so, why?


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

  The use of pack on the widget for setwidget is redundant, and 
  arguably incorrect.  In 1.6 the scrolledwindow now uses grid 
  (better gm), so it really is now incorrect.


login: dejavo
username: dejavo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=57232

  If you want a temp work arround
  I use ::List and get lindex 7 which is the time thingy just
  before
  the filename/dirname starts then i do split to the whole line
  and use lsearch to find its new place then i do lrange from
  its place+1
  to the end of the line and use the join command.
  Now I have the filename / dirname only without the other params.
  I also do string range to the first char if its "d" then its
  a directory.


login: oliversix
username: oliversix
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1091745

  Hi,

  the reason for this behaviour is the line
  return [ lsort $ftp(List) ]
  near the end of ::ftp::NList. I changed this to
  return [ lsort [ split $ftp(List) \n ] ]
  an it works perfectly.

  Bye Oliver


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

  Urgh. 3yrs old, and a solution for a year as well.
  See also 1553919, and 1563137. The latter has
  basically the same solution.
  Accepted, and committed.


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

  --- ftp.tcl     1 May 2003 00:17:40 -0000       1.32
  +++ ftp.tcl     3 Jul 2003 08:39:50 -0000
  @@ -1653,6 +1653,7 @@
   # stop_time -          ending time
   
   proc ::ftp::ElapsedTime {s stop_time} {
  +    variable VERBOSE
       upvar ::ftp::ftp$s ftp
   
       set elapsed [expr {$stop_time - $ftp(Start_Time)}]
  @@ -1660,7 +1661,9 @@
           set elapsed 1
       }
       set persec [expr {$ftp(Total) / $elapsed}]
  -    DisplayMsg $s "$ftp(Total) bytes sent in $elapsed
  seconds ($persec Bytes/s)"
  +    if { $VERBOSE } {
  +        DisplayMsg $s "$ftp(Total) bytes sent in $elapsed
  seconds ($persec Bytes/s)"
  +    }
       return
   }


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

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

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

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

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

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

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


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

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

  package require BWidget

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

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

  .w2 configure -state normal


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


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

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


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

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

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

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

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

  .w2 configure -state normal

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


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

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


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

  doesnt return the "anonymous" names

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


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

  Two notes:

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

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


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

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

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


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

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


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

  I have to disagree.

  The ncgi::valueList returns a list of form values, without
  metadata, unless your fetching a multipart/* value (in which
  case its an user error anyway).

  So its a value list and lsearch simply looks if the value
  exists to set it to selected if it exists.

  The form element can have multiple values if the 'multiple'
  option is specified, multiple options can be selected
  (especially common combined with size to get a Tk listbox
  style widget).


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

  What I propose to do is to bring TclDES' des.tcl file into
  tcllib's des module and rename it tcldes.tcl. I have written
  a wrapper to replace the current des code and re-implements
  the current interface in terms of the TclDES interface. This
  also permits me to give the des module the same style of
  programming api we have for the other crypto packages (ie:
  set Key [DES::Init ...]; DES::Encrypt $Key $data; DES::Final
  $Key)

  I have raised a patch request on the tcldes project because
  I found some significant performance improvements for tcldes.

  I would prefer to imort the 3des/des version and not deal
  with DESjr but if Mac Cody wants to close the TclDES project
  and maintain the code in the context of tcllib there is no
  problem with having both.

  To summarize, [package import tclDES] would load up TclDES'
  API as currently released by Mac Cody. [package require des]
  will load TclDES and provide a tcllib standard API that
  includes backward compatability with the previous tcllib
  version.

  If someone wants to review the code before I check it in -
  contact me.


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

  This is still true today for question mark (mime version 1.5.2). Since question mark is part of the delimiter used in the subject content (=? and ?=) of a mime message, it causes error at decode time on client side.


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

  Applied to the cvs head, and committed. Updated the
  documentation for getbody as well.


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

  That fix looked trivial enough to me, so I committed it on
  my own. Also added a test for it to the testsuite.


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

  This has to do with Widget::focusPrev moving the focus from 
  the .w2.e true entry to .w2 frame, which has -takefocus 
  acceptable on it since it is a megawidget.  That must be 
  improved to check that we aren't just moving from a bwidget 
  child to its megawidget parent container.


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

  If you set
  .w2 configure -takefocus ""
  (instead of the default '-takefocus 1'), then Tk / BWidget's
  standard traversal algorithm does the right thing:
  [tk_focusNext .w1] is .w2.e (instead of .w2), and
  [tk_focusPrev .w2.e] is .w1 (instead of .w2).

  Perhaps the right fix is to make '-takefocus ""' the default
  on the frame widget.  Does that sound reasonable?


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

  No. First it does not work for me. And second, if I use
     $myCombobox configure -takefocus 0
  I would expect, that the widget doesn't take the focus any
  more during keyboard traversal.


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

  Hm.  In what way does it not work?

  Anyway, taking a closer look, this isn't the right solution
  after all.  Widget::focusNext / Widget::focusPrev would work
  correctly if the outer frame had '-takefocus 0' and the
  inner entry widget had '-takefocus 1', but due to some
  BWidget voodoo that I don't quite understand the -takefocus
  option on both widgets are tied together.  Plus -- as Rolf
  mentioned -- from the user's point of view it's preferable
  to set -takefocus on the ComboBox itself, not on one of its
  components.  (BTW, I think [ComboBox .cb -takefocus 0] will
  do the right thing, as will [ComboBox .cb -takefocus ""],
  but [ComboBox .cb -takefocus 1] causes a problem with
  Widget::focusPrev).

  Next possible solution: modify Widget::focusPrev to never
  transfer focus from a descendant to an ancestor.  I think
  this would be the right thing in almost all circumstances 
  -- typically only "leaf" widgets take keyboard focus,
  container widgets do not -- is there a counterexample?

  And an observation: the focus traversal code is deeply
  confusing :-(


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

  Attached patch changes Widget::focusPrev to skip over
  non-leaf widgets.  This makes shift-tab work correctly for
  ComboBoxes and other megawidgets.
  This needs to be reviewed very carefully: I'm not convinced
  that the patched version always terminates (I don't *think*
  an infinite loop is possible, but can't prove it).


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

  I've added a hack that checks that we don't step into the
  immediate parent if it is a proc (like a BWidget megawidget
  would be).

  Joe's idea that -takefocus should optionally allow a widget
  name that you should redirect to sounds very good as a
  better future solution, but would require more careful
  rewriting of -takefocus handling.


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

  This is fixed in the head - leaving it open based on
  alternate idea from Joe.


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

  Grrr. The RFC does not tell us here.  The 'nlst' style did
  not print ., nor .. Copied the code from that part ot
  'list'. Committed.


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

  A pattern match on the attribute keys of a particular node is 
  now in the CVS head. Note: Due to other changes to the 
  attribute interfaces the version of struct jumped to the next 
  major version, i.e. "2.0".


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

  Logged In: YES 
  user_id=32170

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


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

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

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

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


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

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

  This is definitely not the right place.
  Please go to SF project
      http://sourceforge.net/projects/tktable
  and (re)submit the bug there.


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

  Patch committed.

  This report will now change into an RFE. The handling should 
  be moved into the type/instance namespace to allow 
  types/objects in the future to run independent of snit itself.


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

  As the comment below says, the actual fix for this problem was 
  committed over a year ago; and since then we've made the decision that 
  it's OK for snit types and widgets to depend on Snit run-time code (this 
  was a space issue).  So this RFE is no longer needed.


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

  The ftp package treats its two channels (data, control) as 
  internal and does not provide access to them. It is also AFAIK 
  unable to take pre-existing channels and use them. This 
  makes an easy integration with TLS difficult. The package has 
  to change for this.


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

  I have a couple of questions on expected implementation.

  What would be the expected result if you requested SSL/TLS
  and it was not available on the client machine (i.e. the
  machine you are running on)?

  What would be the expected result if you requested SSL/TLS
  and it was not available on the server machine (i.e. the
  machine you are connecting to does not support it)?

  Can you point us to a site which uses ftp with SSL/TLS (note
  sftp does not run ftp protocol over SSL/TLS but an entirely
  different protocol)?


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

  The whole eval isn't necessary in Tk 8.3+.  Corrected for post-
  1.6.


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

  I see now difference between the first 'list' which returns an 
  empty list, and the second one returning a list with twice the 
  contents. The text around them seems to imply that they are 
  different command. Or do you wish to say that the second 
  command is identical, but behaves different nonetheless ?

  Could this be a buffering issue ? The result from the first 
  command somehow stored internally and returned together 
  with the result of the next command ?

  What happens when verbose logging is activated ? (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".)

  This could tell us more about the data actually going to and 
  coming from the ftp server.


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

  Fixed in the CVS head. The code now distinguishes pre/post 
  8.4. In pre 8.4 we use the old code, with unconditional 
  checking of device/inode. In post 8.4 we use the [file system] 
  to deactivate dev/inode checks when needed. While [file 
  system] is still present in the code it is not executed in pre 
  8.4 interpreters anymore.


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

  Fixed. Using direct source of proper file, not 'package
  require', now.


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

  DES operates on 64 bit blocks -- your 6 bytes of data has
  been padded with nulls to 64 bits. If this matters to you
  you will have to handle the padding protocol yourself.


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

  Its the various set statements. If the given variable exists
  in the global namespace then that is set. Remember that
  namespace name resolution looks at the current namespace and
  the global namespace only.

  The fix is to use variable everywhere -- this passes the
  test suite and doesn't affect existing global variables.


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

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


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

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


login: zoro2
username: zoro2
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=191529

  This patch is correct, except that 'identity' encoding
  should be used instead, so that non-utf-escaped binary
  strings (which shouldn't happen, but should be considered
  for some pre-unicode packages).


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

  -translation binary should not lose any data - it will treat it all 
  as 8-bit clean data.  You just have to interpret on the 
  receiving end ... perhaps comm requires some sort of 
  encoding command.  The reason that binary is used currently 
  is that this is compatible with the use of comm by a Tcl < 8.1 
  interpreter.  Forcing a different encoding now would also 
  possibly be an incompatible comm version change.


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

  schlenk correctly noted that -trans binary appears to be 
  stripping, not converting the unicode.  :(
  I've made the change for comm to use utf-8 by default, 
  which is mostly compatible with the previous semi-broken 
  stuff, and going forward is fully i18n happy.


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

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

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


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

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

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


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

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

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

  Makes my issue go away at least for now.


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

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

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


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

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

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

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

  Thanks,
  Roy Terry

  - more -

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


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

  see also 741653.

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


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

  Yes, this is a bug: the problem is that the data are
  identical numbers. That becomes a problem in the
  determination of the variance (all basic statistical
  parameters are calculated, even with the mean proc):
  sometimes the result is a very small negative number and
  then taking the square root causes a domain error.

  The solution is to add the following lines:
        if { $var < 0.0 } {
           set var 0.0
        }
  in the if-block where the variance is determined (proc
  BasicStats).
  This is the corrected fragment:

  if { $number > 1 } {
        set var    [expr
  {($sumsq-$mean*$sum)/double($number-1)}]
        #
        # Take care of a rare situation: uniform data might
        # cause a tiny negative difference
        #
        if { $var < 0.0 } {
           set var 0.0
        }
        set stdev  [expr {sqrt($var)}]
     }

  I will submit an updated version plus an updated test script
  later


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

  Just committed the patches. 

  Can you let me know that this is indeed working? Then we can
  close the bug report 


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

  No response for nearly a month. Considering this as closed.
  Set to auto-close if no further response within 7 days.


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: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 64215: struct.diff

  Logged In: YES 
  user_id=302287

  Some patches that should clean up bad eval use for the
  struct module..., please review.


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

  Applied patch in file 64215. Keeping the issue open for more
  patches.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  File Added - 69368: eval_use.diff

  Logged In: YES 
  user_id=302287

  Some more patches for:
  irc
  inifile
  mime
  uri
  fileutil
  pop3
  nntp
  html


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

  Applied, slightly modified and committed to head. 
  Modifications: Corrected indentation in some places. The tmp 
  variable used to create the list for string map had no 'variable' 
  declaration and was thus in the global namespace. 
  Added 'variable tmp' to ensure existence in the package 
  namespace. Modified the incomplete html handling code 
  minimally, replacing an [expr] by [incr -1].


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

  Do you have a piece of example code we can use to 
  reproduce the problem ? This is important for writing a test 
  case too.

  Question: When using the same type of sent code via Tk's 
  [send], does the same problem occur ? In other words, if 
  you 'send' your problematic code to a different application 
  using Tk instead of comm, do you have the same problem 
  there too ?


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

  Please review the "EVAL SEMANTICS" section of the doc to 
  ensure that it isn't working as expected.


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

  Well, the given example will barf if a list element contains
  spaces. The split command in the script will get the wrong
  number of arguments. In other words, this type of
  substitution is an easy way to create subtle errors, and to
  quoting hell when trying to fix such errors.

  For what is wanted here it is much better to place the code
  into a proper procedure. Also note that "Lmap" is an
  internal command name. The proper and documented entry is
  the "::struct list" command. "Lmap" is allowed to change
  from version to version in incompatible ways.

  proc varset {varval} {uplevel 1 set [split $varval =]}
  ::struct::list map {name=vogel ...} varset

  No quoting hell, spaces in the parameter are properly
  handled too.


login: svogel
username: svogel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=250752

  Oooops. Damn spaces :-)
  Yes, you're definitely right.
  Best regards
     Stefan

  ... closing this item ...


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

  if the object being sent doesn't end in \r\n, then the code in question 
  will fail. however, the patch you propose will append a newline to 
  well-formed messages. what, exactly, are you providing as the 
  argument to the smtp::sendmessage function? 


login: col_ford
username: col_ford
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=891419

  Below is the tcl that I'm am using to contstruct the
  message. It tries to construct a message with a body and
  four attachments - the last being a binary file.

  set body_mime[ mime::initialize  -canonical text/plain
  -param [ list charset us-ascii ] -encoding 7bit -string $body ]

  set log_mime [ mime::initialize -canonical text/plain -file
  $log_file -header [ list Content-Disposition inline ] -param
  [ list name $log_file_d ] -param [ list filename $log_file_d
  ] -encoding 7bit ]

  set yuma_mime [ mime::initialize -canonical text/plain -file
  $yuma_file -header [ list Content-Disposition inline ]
  -param [ list name $yuma_file_d ] -param [ list filename
  $yuma_file_d ] -encoding 7bit ]

  set ephem_mime[ mime::initialize -canonical text/plain
  -file $eph_file -header [ list Content-Disposition inline ]
  -param [ list name $eph_file_d ] -param [ list filename
  $eph_file_d ] -encoding 7bit ]

  set data_mime[ mime::initialize -canonical
  application/octet-stream -file "$OUT_FILE_NAME"  -header [
  list Content-Disposition attachment ] -param [ list name
  $scn_file ] -param [ list filename $scn_file ] -encoding
  base64 ]

  set multiT [ mime::initialize -canonical multipart/mixed
  -parts [ list $body_mime $log_mime $yuma_mime $ephem_mime
  $data_mime ]]

  smtp::sendmessage $multiT \
  -header [ list From $ADMIN_EMAIL ] \
  -header [ list To $XML_DATA(email) ] \
  -header [ list Subject $SUBJECT_EMAIL ] \
  -servers $SMTP_SERVER


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

  The problem shows up when you send a very short text mail using
   set tok [mime::initialize -canonical text/plain -string "body"]
   smtp::sendmail -server localhost $tok \
     -header {From root} -header {To root} -header {Subject
  testing}
  On unix systems with a tls capable sendmail this hangs up
  waiting for the SMTP data termination sequence (CRLF.CRLF)
  I've applied a patch that fixes the problem only for mail
  bodies that do not already have a terminating LF. The
  problem does not show up when Trf is used to process the
  body data.


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

  Note: In struct v2 the name of the root node is returned by 
  the method "rootname". And like any other node it can be 
  renamed through the method "rename".

  Added this informaiton, plus what was asked for to the 
  documentation of struct/tree.

  Comitted to head.


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

  mime::initialize -canonical text/plain -string message \
   -header [list Content-Disposition "attachment;
  filename=\"qqq\"]
  will do the trick fine.
  I've not found any reference in RFC2046 that excludes
  MIME-Version from the parts. I shall look into Content-ID in
  the main part but I suspect it is permitted (how else might
  one refer to that part if necessary).


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

  Frank, please attach the tests you have to this report. 
  Having updated documentation (See profiler.man) would be 
  nice too. I assume that the change in tZero was done to 
  make the counting a bit more accurate by doing the [pstirng 
  map] mgmt before the timebase is set.

  start/stop:
      start => watchForNewProcs
      stop =>  stopWatching
  ?


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 65538: profiler_devel.tar.gz

  Logged In: YES 
  user_id=118601

  Hallo Andreas,
  > Frank, please attach the tests you have to this report.
  I have added my development 'package' with the tests. It
  contains the improved 'profiler.tcl' and the tests
  'profiler.test' as well as the 'all.tcl' to invoke them
  and some devel procedures (which are NOT needed, but
  sometimes they are quite nice) in 'profile_devel.tcl'.
  BTW, tracking 'puts' in tcltest is quite 'tricky', because
  it is redefined, when the option -output is set.
  > Having updated documentation (See profiler.man) would be 
  > nice too.
  Hummpf, is this done manually ??
  (That means not generated from the source ?)
  > I assume that the change in tZero was done to 
  ...
  Exactly, I forgot to mention, sorry. Other things I forgot
  is that I have done the work only for Tcl 8.4 and later.
  And still the empty info level problem with my application
  which I cannot track down to a simple example.
  > start/stop:
  >     start => watchForNewProcs
  >     stop =>  stopWatching
  Sounds good. BTW, init should use and should have an
  option to disable it.
  And finally, thank you for being interested.
  <frank/>


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

  Thanks Frank.

  Yes, the documentation is written manually, and not 
  extracted from the sources.


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

  I have few comments below:

  1. It would have been nice if the entire post to c.l.t was
  attached here because I couldn't understand the need for
  these changes just by reading this summary:). Anyway thanks
  to Andreas for adding the url here.

  2. agree about using 'canonical' names for function names

  3. Most of the profiler APIs such as reset, pause, resume
  and dump accept ?pattern? as an argument. I think it would
  make sense to do the same for addCmd and removeCmd APIs
  (instead of the proposed ?name? argument).

  4. Again, most profiler APIs work on commands. So the Cmd
  suffix looks redundant to me -- perhaps we should just have
  ::profiler::add and ::profiler::remove rather addCmd and
  removeCmd.

  5. At first, start/stop looked very similar in functionality
  with pause/resume -- I understood its purpose only after
  reading the full post on c.l.t. How about merging it with
  pause/resume itself so when pause is called, it will stop
  for arranging of procs and calling resume will restart
  arranging of procs. However, there is one caveat here -- new
  procs defined between pause and rename will not be profiled
  unless explicity added using addCmd after resume or
  implicitly added by resume itself. Another alternative is to
  add -nonewprocs option to pause (for stop) and -addallprocs
  option to resume (for start).

  6. The problem with set cmd mentioned here can also occur
  with any other core tcl commands used in the profiler. A
  better alternative would be to modify the TraceHandler proc
  to look at the caller's namespace scope and ignore profiling
  if it is called from the ::profiler namespace. Would the
  following work for you (untested code):

  proc :: profiler::TraceHandler {name cmd args} {

       if {[uplevel 1 namespace current] eq "::profiler"} {
           # Do not profile cmds in profiler namespace
           return
       }
       if { [info level] ...

  Of course this means that the profiler itself cannot be
  profiled but do we really need to do that? Also, use of
  above method will keep the profiler data to scripts only and
  not skew it with data on its internal commands (I don't know
  whether this is good or bad).

  7. I didn't quite understand the code related to 2nd try
  when info level returns empty. Can you elaborate on the
  problem with some examples.

  8. the profProc command should be modified to call addCmd
  API internally instead of replicating the code.

  9. agree about changing tZero for more accurate timings.

  It's good to see your patch on these improvements, because
  being a user myself, such enhancements can be very useful.
  We should definitely discuss the other open issues that you
  mentioned and look upon enhancing the profiler package further.

  Hemang.


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 66079: profiler.ema.txt

  Logged In: YES 
  user_id=118601

  Hallo Andreas and Hemang,

  > 1. It would have been nice if the entire post to c.l.t ...
  Done. Now I understand the cryptic comment. Thanks Andreas

  > 3. Most of the profiler APIs ...accept ?pattern? as an 
  argument.
  Well, the ?name? was a fast hack and I agree ?pattern? 
  would be better, I think this should be easy to add using
  [info commands ?pattern?] and call an internal add function?!
  This means the ?pattern? will have info commands semantics.

  > 4. Again, most profiler APIs work on commands ...
  Agree

  > 5. At first, start/stop looked very similar in functionality...
  I would not merge them together, because pause/resume 
  having to do with measuring time and start/stop (okay, 
  misleading names) are for setting up functions for profiling. So 
  these functions have different concerns and I would not make 
  one out of them.

  > 6. The problem with set cmd mentioned here can also 
  occur ...
  Hmmm, my experiments it occurred only with set, because the 
  profiler state is changed during tracing set. Well how
  wants to profile the profiler?
  Generally I think it is better to put such restrictions into
  the add command and move this item there. Put it here will 
  end up in more inaccurate time measurements.
  > Also, use of above method will keep the profiler data to 
  > scripts only and not skew it with data on its internal 
  > commands (I don't know whether this is good or bad).
  Sorry, I do not understand why the profiler is restricted
  to scripts this way. But I definitely want to measure how much
  time a procedure spends in 'puts' 'append', etc. and what is
  even more interesting how many calls where made to this
  functions.

  > 7. I didn't quite understand the code related to 2nd try ...
  The problem is simple, I do have empty but VALID results
  with [info level -1]. Believe me, I wrote tons of simple
  examples but up to now I cannot track down this effect. But
  unfortunately it is present in our application. So take it as 
  a workaround for our application. As soon as I get a simple 
  example I'll post on c.l.t and good ideas are welcome.

  > 8. the profProc command should be modified to call addCmd 
  API
  I definitely agree, but that's not so easy regarding Tcl 8.3 
  parts. BTW, init should use start.

  > 9. agree about changing tZero for more accurate timings.
  Looking into again, while being in leave trace the time should
  taken when entering the TraceHandler. But then time 
  measurement must be moved out of tMark, and that is 
  somehow ugly, isn't it.


  > It's good to see your patch on these improvements, 
  because ...

  First, thank you for getting involved. When I posted on c.l.t I
  was a little bit disappointed that was practically no response 
  to it.
  So let me say thanks to Jeff here.

  Second allow me to add and elaborate some items.
  - time in descendants. That's the points that leads me to the 
  need of canonical names. But imagine you add '::append' 
  or '::puts' to profiling and go through a procedure having 
  appends and puts in it.
  This will be measured as time in descendant. Well, normally 
  that's not what you expect and I guess not what you want? 
  So I thought about a concept of node and leaf functions 
  where node functions add to time in descendants and leafs 
  not. But which functions are leaf functions and how to detect 
  them automatically?
  Somehow leaf functions are atomic, is it possible to detect 
  them using info body?

  - To ease the pain of recursive procedure calls, I think
  one should store the level and the time. Having this would 
  allow more accurate 'level' statistics.

  - Coverage. I am thinking of the following workflow:
    - use trace execution with enterstep and/or leavestep.
    - restrict this trace to the current level.
    - 'back match' each 'step' with body and count.
    What do you think about that?

  - profiler.man I am working on it.

  <frank/>


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=118601

  I have added a reworked version as tar.gz, which contains an
  alpha of profiler.man and some of the improvements we
  discussed here:
  - ::profiler::add pattern
  - ::profiler::remove pattern
  - ::profiler::watchForNewProcs <enable|disable>

  Please have a close look on it.
  Todo: 
  - set time in descendants according to info procs

  >> 6. ...my experiments it occurred only with set...
  >What does one mean by "profiling the profiler"? Note that
  [snipped]
  >that the profiling of the profiler itself should not affect
  >the stats of my application which is being profiled.
  I agree
  <philosophy>
  Well, it depends on the point of view. Both results are correct
  in some sense. For a user of the profiler the second result is
  definitely the expected and correct one. For the developper
  of the profiler the first one is correct. But I think, and I
  guess
  you agree, this is only a minor issue and we should keep in mind
  what the user needs and provided correct results for him.
  </philosophy>
  So I disable 'profiling the profiler' in the tracehandler.

  >> 7. ...I do have empty but VALID results with [info level -1].
  [snipped]
  >like to take a look.
  Sorry, it is in my company application 
  and I still got no example for this.

  >You are defining caller as EMPTY and the profiler is
  >defining it as GLOBAL in some places. What is the difference
  >between the two?
  GLOBAL means the call was at toplevel
  EMPTY means the caller is deleted (tkInit) or was empty (see
  above)

  >> - time in descendants. That's the points that leads me ...
  [snipped]
  >... The [info proc $name] can be used for this purpose.
  I agree.


  >> - To ease the pain of recursive procedure calls...
  [snipped]
  >with it. Can you elaborate on this issue.
  Yes, IMHO except the 'atomic' time measurements for each
  call, all 
  other 'aggregate' measurements do not make much sense.
  For example you have a tree walker proc, which is typically
  implemented
  by a recursive descending proc. Therefore the time for the root
  node (time to process the whole tree) is quite different from
  the time to process a leaf node. Both results are typically
  quite
  different. And that's where the level come into play. This would
  allow the user to make his own statistics depending on his
  needs,
  whether he wants to profile the whole tree walking or the time
  needed to process a node.

  >> - Coverage. ...
  >I need to give some more thought to coverage.
  okay

  <frank/>


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

  I have made several (minor) changes to your code and have
  attached
  a new tarfile for the same (hmm, I don't see any attach
  button at SF, 
  so I will mail you the tarfile directly). The tarfile also
  contains diffs for profiler.tcl with cvs called
  profiler_cvs.diff and one with your last 
  patch version called profiler_2.diff.

  The major changes are as outlined below:

  * Fixed code to ensure that it works with tcl8.3 as well:
      -- replaced use of eq conditions with [string equal ...]
      -- add and remove cmds can be called in tcl8.3
  * used switch stmt for watchForNewProcs and returns
    an error if the argument is not enable or disable
  * watchForNewProcs api should not change "paused" variable,
    to cover the following scenario
          suspend                                   ;# paused = 1
          watchForNewProcs disable
          watchForNewProcs enable     ;# should still be
  paused = 1
          resume                                     ;# paused = 0
  * Moved disabling of profiler cmds in TraceHandler proc
    to top of the proc so that it does not waste cylces in
    getting the $caller value
  * deleted special handling of set command in resume proc
     because it is no longer needed
  * created a new removeCmd proc similar to addCmd proc

  For EMPTY caller, does it happen only during "leave" traces
  since the caller has been deleted? Or does it happen when
  the caller's namespace has been deleted? Anyway, I will let
  Andreas decide on this issue.

  Okay, I now understand the issue of timings for recursive
  calls, so levels make sense. For coverage, you may want to
  file a RFE and we can take its
  discussion there. Also, have you looked at TIP86 (still in
  draft state) ... I beleive it can make the coverage feature
  very easy to implement.

  Hemang.


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 70081: profiler3.tar.gz

  Logged In: YES 
  user_id=118601

  Upload of Hemang's improvements of 
  my patch.
  Thanks
  <frank/>


login: fstockinger
username: fstockinger
mimetype: text/plain
icomment:
  File Added - 72541: profiler4.tar.gz

  Logged In: YES 
  user_id=118601

  Hallo Andreas and Hemang,

  Now we getting to an end, hopefully.
  But let me add some correction and further improvements.

  - the uplevel in ::profiler::add:
  set addList [uplevel 1 [list ::info commands $pattern]]
  is needed, otherwise the test profile-1.4.1 will fail.

  - I add a list for gathering the call level. But right now
  there is no
  evaluation function for this.

  - And finally I make the time measurement more correct by
  gathering the time date at the beginning of the trace
  handler. ;-)

  - To test the Tcl8.3 part I rearranged the code a little
  bit, to be able to use and test the 8.3 parts with 8.4+.
  (init has an optional parameter to forbid the use of
  'trace'). Then I adapt the Handler of 
  8.3 to conform with the TraceHandler and correct some issues
  to get my tests pass for 8.3.

  - while working with our application I found out that in the
  8.3 mode info procs <profiledProc> does not work as
  expected. AFAIK, the interp alias does not make an entry to
  'info procs' see profile-1.4.3. Therefore programs using
  info proc will not work as expected in profiling mode. 
  I suggest the following change for addCmd:

  # uplevel 1 [list interp alias {} $name {}
  ::profiler::Handler $name]
  set body "\n  return \[uplevel 1 \[list ::profiler::Handler
  $name\] \$args\]\n"
  uplevel 1 [list ::_oldProc $name {args} $body]

  I guess using the above removeCmd must be changed, too?!
  Note, that this change is not in the currently uploaded sources
  'profiler4.tar.gz'.

  - Again it would be nice if someone looks through the code
  and the changes, because last time Hemangs changes made the
  source a lot clearer and better, thanks and a happy new year.

  <frank/>


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

  This is actually a little bit more complicated than adding a
  foreach - what needs to be decided is how tclish this
  command should be, as opposed to behaving exactly like cat.
   For instance, the real cat, even if it is fed a
  non-existant file, cats all the preceding files, and then
  errors out.  Since tcl can only return once... you can't
  really distinguish like that.

  I think the best thing is probably the simple, foreach
  implementation, but it's worth thinking about for a minute
  or two.


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

  David committed changes to head on 2003-11-15 after a short
  conversation on the chat.


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

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

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


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

  Ah, I begin to see. The module does not remember the message
  count at the beginning of the session to know how high
  message id's can go. And using the STAT information we get
  just before is wrong, the message may exist, just a lot of
  others have been deleted before ...

  A fix has been committed to the CVS head.


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

  tcllib 1.4 was released 2003-05-06 and inifile was not added
  until 2003-06-01. it will be in the next version. until then
  it is available from the cvs repository.


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

  This is in principle handled by the new magic(5) based
  recognizer, new module fumagic aka fileutil::magic. However
  the magic(5) file the current code was generated from
  apparently did not contain checks for Targa. Therefore
  keeping this entry open.


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

  Ok, I am giving in. fumagic / fileutil::magic is enough for
  this. No need to dup functionality.


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

  This is handled by the new magic(5) based recognizer, new
  module fumagic aka fileutil::magic. Therefore done.


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

  This is handled by the new magic(5) based recognizer, new
  module fumagic aka fileutil::magic. Therefore done.


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

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


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

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


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

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

  Alternative diff:

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


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

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

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


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

  from Andreas Kupries:

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

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


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

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


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

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


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

  Logged In: YES 
  user_id=80530


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

  Please review and apply if
  acceptable.


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


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

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

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


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

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

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

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


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

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


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

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

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

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


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

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

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

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


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

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


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

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

  proc foobar ......

  ${loggerinstance}::setdeletecallback foobar

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


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

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


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

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

  Thanks!


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

  I looked at the patch. Two comments:

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

  So perhaps change:
      variable delcallback

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

  to:
              variable delcallback

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

  Otherwise it works fine.

  Michael


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

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


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

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


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

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


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

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

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

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


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

  Reopening --  this is back again.

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


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

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

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


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

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


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

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


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


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

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


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

  The relevant part of the spec is

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

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

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

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

  The changes have been committed to the Tcllib Head.


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

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


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

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


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

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


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

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

  I had to edit the NNTP proc source code again.

  Perhaps someday the bugfix will be entered.

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


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

  I will have a look, but no promises. Why is the removal of
  the -h support so important ? Was it replaced with something
  else ? Or just an error message ?


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

  The attached code doesn't do anything if unexpected options
  are encountered. It just shuffles them into the $argv
  variable like it does with non-option arguments. It's much
  easier to use this in proc's than the other parser because
  you don't want procs to print help information if they get
  bad options -- you want the proc to decide what to do,
  usually thats just returning an error message.


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

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


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

  More brainstorming:

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


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

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

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

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


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

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

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


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

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


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

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

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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


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

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

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


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

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


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

  The ActiveTcl version issue was recently corrected.  The
  other problem I'm referring to Damon.


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

  Can you provide a piece of sample code along with what you
  expect the result to be?  I'm not exactly sure what I'm
  looking for here.


login: rmaris
username: rmaris
mimetype: text/plain
icomment:
  File Added - 75892: test.tcl

  Logged In: YES 
  user_id=968757

  Here is the sample code.
  Note that automatic placement "above" when there is not 
  sufficient space for placement "below" does not work, too.


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

  I'm not sure what result I'm looking for.  I tested it
  against the last version of BWidgets, and it seems to work
  as advertised.

  If I put the window against the left side of the screen and
  ask for a left placement, it goes to the right.  Vice versa
  on the other side.

  The same goes for above and below.  What are you expecting
  to see that you're not seeing?  Can you tell me where to put
  my window or modify the test code to place the window
  exactly where you're seeing the problem?


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

  Oh.  I see now.  I think I already fixed this from another
  bug that was reported.  I will commit my changes tonight and
  see if that fixes your problem.


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



  File Added - 80254: tkchat-tile.patch

  Logged In: YES 
  user_id=202636

  Updated it again.


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

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

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


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

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


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

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

  Marshall ?

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

  Sorry that this did not get into the 1.6 release.


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

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


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

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


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

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


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


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


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

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


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


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


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

  Aha!

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

  I'll fix it.


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

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

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


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


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

  Hope that helps.


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

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


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

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

  modules/ntp/time.test
  - time    1.2

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

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

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

  A bit different.


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

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

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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

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


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

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


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

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


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

  The whole dialog system used by this testsuite was
  rewritten. The CVS Head has no trouble on Linux, regular
  intel, and x86_64. Was this tested on Alpha again too ? I
  have no Alpha.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  The HTML Standard 4.01 does not support <list name="List1"
  />, this is XHTML Syntax and for XHTML one is better off
  using a true XML Parser like TclXML or tDOM.

  Empty tags do not have closing tags, so it is correct if no
  closing tag appears in the result list.

  Fixing the class code looks like the wrong thing to do, it's
  2TreeCallback that needs fixes, the tree generation.

  As <list> isn't a valid html tag it should be ignored by
  2Tree anyway.

  If you did it with <li /> and it breaks, thats an other matter.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  See:
  http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines
  C.3 for the suggestion of W3C regarding empty elements with
  non empty content model.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I got another report about this, see 

  http://sourceforge.net/support/tracker.php?aid=1034580

  This one came with code. It changed the empty tag into a
  single closing tag. Which I considered wrong. However based
  on that I was able to create something which transforms an
  empty tag into a pair of opening and closing tag in the
  event sequence. I.e. something like

      <a href="foo"/>

  would be handled as if the input had been

      <a href="foo"></a>

  This is IMHO the most sensible approach to real-world data
  using empty tags.

  Committed my changes to head, see the other report for details.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=146884

  I confirm this defect. When I fixed the code to send 230. My 
  Linux based client (in this a DVR) started working.
  Roy Terry - 17 May 2004


login: gwlester
username: gwlester
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=121110

  Code has been corrected, committed to HEAD, and will be next
  release.

  You may want to pull and validate the fix.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Patch applied.

  It's not misrepresented. The Network Time Protocols module
  in tcllib is intended to collect implementations of such
  protocols. The first one in happens to be RFC 868 TIME as is
  clearly stated at the top of both the man page and the tcl
  code itself.

  Somewhere I have 90% of an implementation of RFC 1035 but it
  hasn't gone in yet.

  I'll see about checking the protocol -- although I don't
  think RFC 868 can really handle that.


login: alathar
username: alathar
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=984964

  Thanks for applying the patch!  As for the rest, sorry - I
  confused "an" NTP with "THE" NTP. <sheepish grin>


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Applied, with same small changes. Chunks irrelevant to
  headers have been ignored.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This should end up in the console now and not pollute the
  starting terminal. On linux /dev/null is ok - there is a
  warning but that is all.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=372859

  This has been implemented in Snit V0.95.  Almost all runtime code has 
  been pulled out of the generated type and into the ::snit:: namespace, 
  where it is shared by all existing snit::types and snit::widgets.


login: cdclercq
username: cdclercq
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=617750

  Had the same problem on UNIX.
  --> LC_TIME=nl_BE.ISO8859-1 
  unable to convert date-time string "03 okt 2005 09:28:47"
  In Dutch october with a "k" io "c"
  unset LC_TIME
  problem solved, altough the procedure should be
  able to handle other LC settings.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Closing this old one as duplicate, nobody will be notified
  anyway of its demise.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Noisy defaults have been changed to silent ones, for
  anything below warning, incl., in CVS head.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  OK Fixed this and I'll check for other similar problems when
  using Trf commands.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This was fixed by Aaron Faupell on July 28, 2003. I guess
  you have Tcllib 1.4 or earlier. Tcllib 1.6 does not have
  this problem anymore.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is a duplicate of
  http://sourceforge.net/tracker/?func=detail&aid=914488&group_id=12883&atid=112883


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This actually works for most type/order combinations. There
  are only three exceptions. The three non-working
  combinations are: dfs/post, bfs/post, and dfs/in. I.e. any
  of the two walking types, in post-order traversal, and the
  in-order traversal. The problem for all of them is that the
  pruning has to happen when entering a node, and for them the
  entering is done only internally, the walk script will not
  see it per definition of the traversal, and thus is unable
  to tell the walker that pruning is wanted for a specific node.

  It might be best to simply document these exceptions, simply
  say that pruning is not possible fro them. And code the
  prune command to test for these situations and throw errors.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Done and committed to head.
  Also added methods 'ancestors' and 'descendants' for treeCL.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is likely not a bug in the docs, but a bug in the
  generation of the usage string.

  Ok, having looked at the output as I have it (CVS Head) I
  see a clear demarkation between the -v and the character
  '1'. Basically the output has two columns. In the first we
  see the option, like "-v", or "-foo value", with the string
  "value" as indicator that the option takes an argument. The
  second column then shows the default value, if there is one.

  I have no problem seeing that -v is a boolean option not
  taking an argument (missing string "value"), and true by
  default. Whereas -foo is an option taking an argument,
  indicated by "value".


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I'll keep this open and assigned to me until I've finished
  the SASL mechanisms I want to support. (Which won't take
  long -- they just need testing.)


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Deleted - 80424: 



  File Added - 80518: smtp-auth.patch

  Logged In: YES 
  user_id=202636

  OK tested CRAM-MD5, PLAIN and LOGIN against Sendmail and
  Microsoft SMTPd

  Committed.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  Hitting the return key on the login name will now always
  focus the password entry.  Hitting return on the password
  entry will now always close the dialog.  The rest of the
  patch was merged.  Thanks.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Note: [file tail] is only the last component in the path.
  You are throwing away the whole directory hierarchy.
  Depending on what you wish to do it may be better to
  [file join /tmp [eval file join [lrange [file split $path] 1
  end]]]
  That preserves the whole directory hierarchy and places it
  under /tmp. It may also require additional code to create
  missing parental directories first.

  Your eval looks good.
  One related eval is in line 675, proc ::ftpd::Fs (Note the
  uppercase). This calls your 'fakefs'. This eval however
  looks ok as well.

  In all places where 'ftpd::Fs' is called the path is at
  least in part taken from the incoming ftp command. IIRC the
  protocol has no quoting provisions for paths containing spaces.

  My advice would be to

  * Use 'sockspy' to log what is going on on the command channel
  * And/or instrument the 'ftpd::command:*' commands to see
  what the server is getting from the socket, before any
  processing. The argument 'list' contains the ftp command. It
  is created in 'ftpd::read'. The server reads a single line
  and splits it at whitespace. ... That may be the culprit.
  Except that I have no idea right now if an ftp client
  performs quoting, or is allowed to perform quoting for paths
  containing spaces, and what the RFC says about this. It
  could be that the general processing of the command in
  'ftpd::read' is wrong. Maybe split should not be used, but
  more something like 'string first' for the first space.
  Depends also possibly on if a command can have more
  arguments after the path.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yes, it looks indeed as if the general argument processing
  in ftpd::read is the culprit. The argument processing is
  individual per command, and for those taking a path name the
  path is everything after the first space to the end of the
  command line.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  See also
  http://sourceforge.net/tracker/index.php?func=detail&aid=1002936&group_id=12883&atid=112883
  for an alternate fix.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003
  Originator: NO

  I believe this is now fixed with a recent commit for Bug 1720144.


login: damonc
username: damonc
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=50387

  The current behavior of the dynamic help balloons is built
  to mimic the behavior of Windows' help balloons, and it does
  that just like it's supposed to.  Help balloons aren't
  usually placed on widgets like text boxes, which is why it
  look kind of weird using them like you are.

  I will add an option (which will be disabled by default) to
  get the behavior you're looking for as I've found myself
  wanting it in the past, but I usually just find another way.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is a duplicate of 899204, and has been fixed in the CVS
  head (March 6). See
  http://sourceforge.net/tracker/index.php?func=detail&aid=899204&group_id=12883&atid=112883

  inifile.test: Fixed [Tcllib SF Bug 899204] by (a) rewriting all
    tests to be completely independent of each other and (b)
    changing the mode when opening the test file to 'r'. It should
    be noted that the write facilities of the module are not
  covered
    by the testsuite. That is unfortunate.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  Looking at the code for the head, the '1' appears to be the
  correct value, as that will extract, eg, "p:2" and give us
  "2" as the page identifier.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This may actually a bug in the mime or smtp package. My
  problem is that I cannot say if all the arguments to the
  mime/smtp commands are correct and what not. I assume for
  now that your 'old' and 'new' are 'body' in the code segment
  coming before them.

  I am assigning this to our smtp/mime expert here, Marshall Rose.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This works for me using the tcllib 1.6 versions of mime and
  smtp.
  I get a warning that To isn't present but here is no problem
  with the message data.

  I call this fixed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I see, the RE does not handle the user information at all.
  Fixed in CVS Head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Another thing to try is the jpeg::exif command in the new
  jpeg module. This is in the CVS head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is actually a duplicate of
  http://sourceforge.net/tracker/index.php?func=detail&aid=784519&group_id=12883&atid=112883

  Tcllib 1.4 has the bug in the multiplexer manpage, and
  during installation of Tcllib 1.6 it seems to take the 1.4
  doctools for the doc generation instead of its own and
  fails. After removal of the installed 1.4 you should be able
  to install 1.6.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  A fix has been committed to the cvs head. In essence nroff
  now uses the same system as HTML and XML to correctly
  protect and handle its special characters in both markup and
  plain text.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The application has been written and committed to the head.
  No default makefile target yet.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  the dtplite application is installed by tcllib 1.7,
  so this can be closed.

  the remaining request - that TEA provide
  an example target rule in its Makefile,
  is better tracked in the TEA/sampleextension
  tracker.


login: yahalom
username: yahalom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=130120

  the bug should be opened as currently microsoft changed the 
  content type. the text/xml comes with additional data so 
  the switch misses it. the fix should do
  text/xml* 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Implemented and committed to head. All predefined formatters
  have been updated to generate something hopefully sensible.
  TMML is an exception, it has to ignore the label, the output
  DTD has no place where I can store this information.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  The $lbf listbox also needed these bindings.  Otherwise
  patch merged.  Thanks.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=302287

  confirmed. Will be availble soon in the cvs version.
  The services feature has also some cleanup bugs in tcllib 1.6. 

  Michael


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  That's right, there is no -label switch for comboboxes since
  several releases.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hour merge - This sounds like tclhttpd - Can this be
  expressed in a test case independent of that application ?

  I guess that this is a rounding/truncation issue somewhere,
  right ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This seems to be a duplicate of

      http://sourceforge.net/support/tracker.php?aid=943984

  Closing as suhc, especially as the other report also has the
  fix.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  i agree. in addition to adding the query/ratio branch, perhaps we can add 
  a default branch?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I will do that. This seems to be case of where the
  reflection transform in Trf evolved, but mime was not
  adapted to the change. I checked and the 'query/ratio', and
  some other messages are missing. I will add them. One
  branch, create/read is duplicated. Will fix that as well.

  Note: A default branch is actually present, and it generates
  an error message "Unknown command FOO".


login: mrose
username: mrose
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=24077

  > Note: A default branch is actually present, and it generates
  > an error message "Unknown command FOO".

  i have no idea what i could have been thinking when i wrote that. please 
  keep the default branch and just get rid of the contents, i.e.,
      default {}


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. This could lead to difficult to diagnose errors, when
  another new method is asked for, returns boguis result or
  does nothng ... silent failure. I rather like it more to
  throw the error. As long as it is not caught somewhere up
  the chain.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Arjen, how much of this has been done already. I have seen
  the math::optimize, but do not know how much it fulfills
  this request.
  Or if others fulfull it (partially).


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=400048

  All of the above has been done, with the sole exception of 
  cluster analysis. And I should revisit the FFT examples - Lars 
  Hellstrom suggested some much better alternatives.

  I consider it closed


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  I'm not sure what the expectations are here.  The widgets do
  expand as the ScrollableFrames expand, but they are
  constrained in that frame.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Do you have small examples which demonstrate the bad
  behaviour ? They would also become test cases.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Mostly accepted. The changes to mapEscapes are outdated,
  this was fixed in a different way, by an additional quoting
  step protecting Tcl's special characters.

  Reordering advice taken.

  Examples are in the testsuite, actually. The relevant
  testcases have been updated.


login: coldstore
username: coldstore
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=19214

  I've lodged sf bug [ 954346 ] 'tcllib mime / md5 problem
  stops tclhttpd loading' against tclhttpd, because tcllib 1.6
  and the upcoming release of tclhttpd aren't compatible.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  package mime requires 'md5 1', i.e. any version of md5 in
  the 1.x series. That is the reason for the opposite order to
  work. Mime loads md5 on its own, and the second require
  simply uses and reports that package. In the regular order
  the mime package cannot satisfy its constraint.

  The problem is that md5 1.x and 2.x series have definite API
  incompatibilities, hence the change in the major version
  number. And having mime require v1 was the easy way to
  satisfy it without bigger changes to the code.

  Now looking into this some more the situation is actually
  even worse. While mime requires md5 v1, smtp on the other
  hand requires md5 v2 (see proc auth_CRAM-MD5).  :(

  I will write up some code which adjusts itself at runtime to
  whatever package it gets when asking for any md5 version,
  i.e. handling both possible APIs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Applied changes to head which cause mime and smtp to adapt
  at runtime to whatever version of md5 is loaded.


login: gwlester
username: gwlester
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=121110

  Fixed and committed to head (ftpd.tcl CVS version 1.24). 
  This will be in the next release of tcllib.

  You may want to check out the current version and verify the
  fix.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Duh - there is a catch but it got disabled during testing
  and left disabled.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Can you attach a tcl script which excersizes the problem ?
  I see that InitDataConn's state switch has no branch for
  'pwd_sent', however I have trouble tracing the spaghetti
  that is ftp's implementation to see how it happens to have
  that value. It is indirectly called via
  Open{Active,Passive}Conn, and no user of these two commands
  has state 'pwd_sent'.

  Note: I am looking at ftp 2.4.4, as found in the CVS Head of
  Tcllib. File revision 1.42.


login: thomasmaeder
username: thomasmaeder
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=714202

  Another failure is http://host/path1/path2?param=value#fragment :

  % uri::split "http://host/path1/path2?param=value#fragment"
  fragment fragment port {} path path1/path2?param=value scheme http host host query {}

  instead of

  fragment fragment port {} path path1/path2 scheme http host host query param=value


  The obvious solution would be to use a variation of the regular expression given in Appendix B of http://www.ietf.org/rfc/rfc2396.txt (the variation being directly splitting host and port).


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  I seem to be able to navigate the boxes with cursor keys. 
  This is on OS X, 10.4.7, using fink's wish.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  The lines were added in response to patch 947109, applied
  2006-09-26.


login: robert_hicks
username: robert_hicks
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1528214

  I would like this added as well plus a way to add a
  javascript script. I have coded the following and tested
  using TclHttpd server.

  # ::html::css
  #Create the text/css tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the css file to include the filename
  and path
  #
  # Results:
  #HTML for the  section

  proc ::html::css {href} {
      variable page
      ::set html ""
      append html "<link rel=\"stylesheet\" type=\"text/css\"
  href=\"[quoteFormValue $href]\">\n"
      lappend page(css) $html
      return ""
  }

  # ::html::js
  #   Create the text/javascript tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the javascript file to include the
  filename and path
  #
  # Results:
  #HTML for the  section

  proc ::html::js {href} {
      variable page
      ::set html ""
      append html "<script language=\"javascript\"
  type=\"text/javascript\" src=\"[quoteFormValue
  $href]\"></script>\n"
      lappend page(js) $html
      return ""
  }

  I then changed the ::html::head section to include these
  like meta tags:

  # ::html::head
  #
  #Generate the <head> section.  There are a number of
  #optional calls you make *before* this to inject
  #meta tags - see everything between here and the bodyTag proc.
  #
  # Arguments:
  #titleThe page title
  #
  # Results:
  #HTML for the <head> section

  proc ::html::head {title} {
      variable page
      ::set html "[openTag html][openTag head]\n"
      append html "\t[title $title]"
      ::if {[info exists page(author)]} {
  append html "\t$page(author)"
      }
      ::if {[info exists page(meta)]} {
  ::foreach line $page(meta) {
      append html "\t$line\n"
  }
      }
      ::if {[info exists page(css)]} {
      ::foreach style $page(css) {
          append html "\t$style\n"
      }
      }
      ::if {[info exists page(js)]} {
      ::foreach script $page(js) {
          append html "\t$script\n"
      }
      }
      append html "[closeTag]\n"
  }


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Addendum: For the html::js (and I am not sure how) it needs to know whether it 
  is in the <head> section or the <body> section I am thinking. You don't embed 
  a .css file in the body of the html but you *can* with .js files.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Committed the implementations, after reworking them to be a
  bit simpler. I am bailing out on the javascript-in-body issue.


login: nobody@129.247.247.239
username: nobody@129.247.247.239
mimetype: text/plain
icomment:
  BWidget 1.8 / T cl 8.5.2 / Windows-XP

  Perhaps the following observation is related to this case:
  Changing the foreground color with [option add ...] does not affect SpinBox Arrow buttons.
  The arrow buttons are displayed black-on-black while the show read-on-blach, when the mouse cursor moves over.
  I'm using the following color settings:
      #
      # Night-Mode colors
      #
      option add *backgroundblackwidgetDefault
      option add *foregroundred4widgetDefault
      option add *insertBackgroundred4widgetDefault

      option add *disabledBackgroundblackwidgetDefault
      option add *disabledForegroundred4widgetDefault

      option add *highlightBackgroundblackwidgetDefault
      option add *highlightColorblackwidgetDefault

      option add *selectColorblackwidgetDefault
      option add *selectBackgroundblackwidgetDefault
      option add *selectForegroundred3widgetDefault

      option add *activeBackgroundblackwidgetDefault
      option add *activeForegroundred3widgetDefault


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Okay, I withdraw my previous comment.
  using the default "interactive" priority solves the problem.

  option add *foreground red4 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  That is true by design. The default value is hard coded to 15x15.

  Is there any need to transfer it to a BWResource ?

  The option declaration is as follows:
      Widget::declare ArrowButton [list \
      [list -typeEnum button 0 [list arrow button]] \
      [list -dirEnum top    0 [list top bottom left right]] \
      [list -widthInt150"%d >= 0"] \
      [list -heightInt150"%d >= 0"] \
      [list -ipadxInt00"%d >= 0"] \
      [list -ipadyInt00"%d >= 0"] \
      [list -cleanInt20"%d >= 0 && %d <= 2"] \
      [list -activeforegroundTkResource""0 button] \
      [list -activebackgroundTkResource""0 button] \
      [list -disabledforeground TkResource""0 button] \
      [list -foregroundTkResource""0 button] \
      [list -backgroundTkResource""0 button] \
      [list -stateTkResource""0 button] \
      [list -troughcolorTkResource""0 scrollbar] \
      [list -arrowbdInt10"%d >= 0 && %d <= 2"] \
      [list -arrowreliefEnumraised0[list raised sunken]] \
      [list -commandString""0] \
      [list -armcommandString""0] \
      [list -disarmcommandString""0] \
      [list -repeatdelayInt00"%d >= 0"] \
      [list -repeatintervalInt00"%d >= 0"] \
      [list -fgSynonym-foreground] \
      [list -bgSynonym-background] \
      ]


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Version 1.164 reinstates support for tcl8.3.
  If this version raises any problems - either bug me on the
  chat or raise a new bug.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  Have corrected these. The problem is due to TAG priority. 
  Still have a couple of minor issues, not mentioned here, 
  to correct before applying a patch.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  Under OS X 10.4.7, /usr/bin/wish8.4 does not appear to hang
  on the BWidget demo.  I could not get the lock up with
  fink's /sw/bin/wish either.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Test by Kevin:
  "I can't reproduce the bug--it was filed against 1.7 and I'm using 1.8. I'd close it as out of date"


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  I've hardcoded a fix for my usage.

  In proc ::smtp::initialize_ehlo, after the TLS code, I added:

     if [catch {smtp::talk $token 300 "AUTH PLAIN"} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 334}  {
         puts stderr "Bad response to AUTH PLAIN = '$response(diagnostic)'."
         catch {close $state(sd)}
         return {} 
     }    

     if [catch {smtp::talk $token 300 "A------------
  redacted----------------------hZGE="} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 235}  {
         puts stderr "Bad response to the base64 password = 
  '$response(diagnostic)'."
         catch {close $state(sd)}
         return {}
     }    

  It took a bit of Googling to find out the format, the RFC didn't state it.

  FYI, you'd better give the user a choice of AUTH methods, because
  I first coded this for AUTH LOGIN and it seemed to work - gave a
  success for authorization - but it would fail to work if I was sending
  to a different domain (and it was a forward, not a POP box) that
  was handled by the same POP server. I don't know if this was a
  qmail quirk or not. Switching to AUTH PLAIN worked. If the (eventually)
  fixed smtp.tcl doesn't give a choice and it chooses the first one listed
  by the EHLO output, it would fail for local aliases at my provider.

  I'm suggesting to my provider to drop AUTH LOGIN from the EHLO output.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  Update: regarding giving a choice of AUTH methods, it turns out
  that was a problem on my end, nevermind. It may or may not be
  a useful thing to be able to specify.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The current CVS version of the smtp package has AUTH support
  for DIGEST-MD5, CRAM-MD5, LOGIN and PLAIN. It also supports
  the use of the STARTTLS extension to enable a secure link if
  you have the tls package available. This has been tested
  against sendmail, postfix and Microsoft's SMTP server.


login: eriklns
username: eriklns
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=113903
  Originator: NO

  Personally, I do not find this too funky at all. In fact, I'm inclined to go one step further and change the default for this option (-exportselection) into 0. 

  The documentation for this option says:
  "The default is usually for widgets to export selections." (meaning the X-selection)

  I question this statement. I haven't seen many applications that show this default behaviour. (Maybe it is a Unix tradition.)

  A combobox is primarily about selecting an item from a collection of items. This is unrelated to selecting a sequence of characters for a copy/paste operation, and we ought not confuse/mix these two different concepts. If users do want to set the X-selection too, they may choose to change the default.


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433
  Originator: NO

  Not my department.  Damon?

  FWIW: On X11, Gtk+ and Qt editable comboboxes do export the selection; ditto spinboxes and entry fields.  The only major toolkit I've encountered that doesn't do this is the one Mozilla-family tools use; there, entry fields appear to use a hybrid X11-style global primary selection combined with Windows-style independent selection (which I personally find very confusing.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The patch seams reasonable to me too.
  Nevertheless, I have checked the behaviour on windows and linux with and without patch. It works fine for both cases.
  #- test script -
  pack [ComboBock .c]
  pack[ComboBox .n -exportselection 0]
  # set a selection in both using the mouse
  .c configure -exportselection 0

  In the first case, the selection is exported and removed if there is somewhere else a selection
  In the second case, the selection is local and not exported to other windows.

  I decided not to apply the patch.
  Please notify, if the patch helps anybody, no issue to put it in neither.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thanky to Eric, I have got the point.
  One requires values to test it.
  Revised test script:
  -----
  pack [ComboBox .c -values {1 2 3}]
  pack [ComboBox .n -exportselection 0 -values {1 2 3}]
  -----
  When clicking on an item in the drop-down box, the result gets selected in the first case. In the second, it does not and the cursor is placed behind the entry.

  A matter of taste. Please post, if you like it or not.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  The extra label options were dropped from the combobox and
  other widgets.  Place it in a LabelFrame.


login: georgeps
username: georgeps
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=585068

  This failure only occurs with Tk 8.5/HEAD.  I can't
  duplicate it with 8.4.6.

  With 8.4.6 this *does not* work:
  ctext::addHighlightClassForRegexp .ct comment navy {#[^\n]*\n}
  That same RE works properly in 8.5/HEAD.

  This RE always seems to work (and interestingly seems to
  avoid the endless loop with 8.5):
  ctext::addHighlightClassForRegexp .ct comment khaki {#[^\n\r]*}

  Time to file a bug for Tk I think.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed. Extended textutil::expander to keep track of location
  and report it as part of errors. Fixed doctools to not snip
  the new location information. Changes have been committed to
  head.


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  An addendum:  The windows and linux machines are behind a
  firewall and are being masquaraded to a different ip
  address.  I don't know if that matters.
  Also, yahoo has a strange mail server.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Their mail server isn't that wierd. It appears to be RFC2821
  compliant at least.

  Here is what I'm using to test this:
   proc send {from to msg {server localhost} {port 25}} {
      set tok [mime::initialize -canonical text/plain -string
  $msg]
      smtp::sendmessage $tok -debug 1 \
          -servers [list $server] \
          -ports [list $port] \
          -header [list From "$from"] \
          -header [list To "$to"] \
          -header [list Subject "RFC 2821 test"] \
          -header [list Date "[clock format [clock seconds]]"]

      mime::finalize $tok
   }

  Note the -debug 1 -- this lets you check the SMTP
  conversation. For which I get
  Trying mx3.mail.yahoo.com...
  <-- 220 YSmtp mta260.mail.scd.yahoo.com ESMTP service ready
  --> EHLO zen (wait upto 300 seconds)
  <-- 250-mta260.mail.scd.yahoo.com
  <-- 250-8BITMIME
  <-- 250-SIZE 15990784
  <-- 250 PIPELINING
  --> MAIL FROM:<patthoyts@users.sourceforge.net> SIZE=265
  (wait upto 600 seconds)
  <-- 250 sender <patthoyts@users.sourceforge.net> ok
  --> RCPT TO:<XXXXXXXXX@yahoo.com> (wait upto 3600 seconds)
  <-- 250 recipient <XXXXXXXXX@yahoo.com> ok
  --> DATA (wait upto 300 seconds)
  <-- 354 go ahead
  --> . (wait upto 120 seconds)
  <-- 250 ok dirdel
  --> QUIT (wait upto 120 seconds)
  <-- 221 mta260.mail.scd.yahoo.com

  So it's not the yahoo server - it's something in the mime
  package -- perhaps you have an old version? I'm testing with
  mime 1.4 and smtp 1.4 here.


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  The problem is fixed if I add the "From" field to the
  header.  When I send mail to hotmail the "From" field is
  added automatically, but sending mail to yahoo throws the
  error if there is no "From" field.

  I downloaded the latest versions of mime.tcl and smtp.tcl
  off the CVS last saturday (July 3rd).  Previously I had been
  using mime.tcl 1.4 and smtp 1.3.5 that came with the active
  tcl distribution.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  It is the 'calendar' module, somehow. It has no
  documentation, and that screws up the system for all modules
  that follow. The simplest way to repro the problem is

      ./sak.tcl nroff calendar FOO

  for any other module FOO, and the doc generation will barf.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The commands were modeled after the core builtins [file
  split] / [file join], which exhibit the same sort of asymmetry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Duplicate of [Tcllib SF Bug 948273].

  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=948273&group_id=12883

  Already fixed in CVS head of Tcllib as of May 25, 2004.


login: schwarzkopf
username: schwarzkopf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=159778

  which version of Tcl and what platform? I am using ASTcl
  8.4.7 on windows, and it works. I think the ability to do a
  package require struct::record was just added, so you might
  have an old tcllib (even if it does say 1.6)


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  Confirmed, the first line in _auto_complete prevents any
  matching when typing in uppercase chars.  Why is that there?


