# ticketchng

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

  Just committed a fairly complete man page for the geometry 
  submodule


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Correct. Patch committed.
  TK:
  Visible when canvas and frame have different default background colors.
  TTK (Widget::themed true):
  The situation is IMHO suboptimal.
  With the patch, we get the background color of the style TFrame (which is better than before, the canvas default color).
  But still, the -bg parameter failes. IMHO this is not easy to solve. Documentation in ScrolledFrame about this fact is missing too.
  In consequence, the -bg and -background parameters are really not available if themed and there is a remark in the documentation.


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

  I fully agree that the doctools docs need improvements.
  Most Tcllib authors probably use sak.tcl to generate the docs from their doctools formatted man pages, where it simply is: sak.tcl doc html <packagename> IIRC, but that kind of magic should be exported into a general use package for non-tcllib packages.
  So i agree that point 3 should be easy to do and have a big bang for the buck ratio.


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

  For reference, the wiki pages, which should be included (at least partially) into the doctools docs:
  http://wiki.tcl.tk/doctools
  http://wiki.tcl.tk/dtp

  These document at least the basics. Would they be enough to satisfy your 3. point?


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

  Actually, the Wiki seems to address a majority of the insufficiencies in the documentation. Removing the "incorrect" information from the manual page (like the EBNF that's wrong) and either incorporating the examples and specifics from the Wiki or including a prominent pointer to the Wiki in the man page would probably be sufficient to answer most questions. I guess I'm just old-fashioned and haven't gotten into the habit of checking the wiki before the man pages. :-)


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

  One thing that needs to be carefully kept in mind as doc for this package is written is that at least two types of documentation is needed.

  One type of doc is for someone who is going to be working on the code itself. That code would focus on design decisions, what the plugin architecture is for and how to use it, etc.

  The other type of doc is for someone who wants to write code in doctools format. For that person, the emphasis needs to be on SEMANTICAL use of the format. One of the reasons for doctools is semantical markup of text. In a semantical view, one doesn't care whether the resulting text is bold faced, underlined, etc. What matters is that people CORRECTLY marks the various parts of text. If one marks the text correctly, then the doctools tools should be able to generate things in a format that is useful later.
  And viewing the doc from that perspective is invaluable.  

  I wonder if some sort of tool would be useful to have that would somehow display the documentation visually emphasizing the semantical markup, so that one could easily look at text and identify where something had a mistaken markup?  I'm not certain about a good way to do this - something to think about.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 216376: doc.tgz

  Logged In: YES 
  user_id=75003
  Originator: NO

  Now attached a first go at a set of new man pages for the doctools markup language. Please review and respond.

  Looking at this again, (4), ... The error messages do tell the location of the problem, line number and column.

  Of the 4 documents the command reference likely needs most of the expansion (i.e. more argument descriptions, add examples for each command).

  File Added: doc.tgz


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

  This looks a lot better to me! The intro doc is excellent. The other thing I would suggest is perhaps adding one more document that is simply a collection of examples of each type of command. That is, a web page where one could cut-and-paste the formatting for a widget, for a command that takes -name/value pairs that are optional, etc etc etc. It would be just a matter of digging out representative samples from the existing package documentation and putting them in an easy-to-find place. Even just a list of "to see a sample mega-widget documentation, check package Yadda. To see a sample OO class document, see package Boogle" would do the trick, I think. Just some place that makes sense of the different formatting commands at a detailed level.


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

  Ok, yesterday I committed the whole set of updated documentation, not only for doctools, but the docidx and doctoc formats as well. FAQs have been added, but are relatively small so far. All manpages now have a section about how and where to provide feedback. This is something I will add over time to all manpages in Tcllib. I made the doctools language nicer too (See changelog for the details. I mainly loosened a number of constraints, and added better names for the various list types and list item commands. The docs show the updated language, old stuff is still accepted, but deprecated and causes warnings).


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

  This has been added to 1.4.0cvs, but undoc'ed for the 
  moment.  '.' is used, as that should be sufficient for 
  getting color info.  The only time that won't work is in a 
  multi-screen situation where . is on another screen, and 
  that screen uses a different visual (very rare).


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

  Ok, made a commit which fixes most of the trouble. The only thing I still have to look into is 'snit'. When generating a DVI from its LaTeX file LaTex complains about 'too deeply nested'. I have to see what is happening there regarding nested lists and such.


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

  Fixed latex processing completely. Problem was usage of 'quote'-environments in list-items. TeX restricts us to 6 levels, we had 4 + the quote's made 7. Now we can nest lists 6 levels. Also fixed a lot of quoting problems for special characters, when they are needed, when they have to be quoted, prevent double-quoting of already quoted parts. Etc. Added code to SAK for pdf generation.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I believe this due to a change in Tcl 8.6 regarding 'do nothing gracefully' ...
  TIP 323, item 5: lassign - accept zero variable names.

  When lassign is present as builtin command 'struct::list assign' is aliased to it. The testsuite still assumes the syntax of the pre-TIP 323 builtin lassign, identical to struct::list assign's syntax when implemented by Tcllib if there is no builtin.

  Not sure yet what to change or how much. Thinking about it however.

  The testsuite still expects that assign'


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Skipping the affected tests now. Tests where just the message has changed got extended to handle that case.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Commited to CVS. Resume:
  Use balloon help font TkTooltipFont if tk <= 8.5.
  Otherwise use helvetica 11 on Aqua
  For TWidget always use TkTooltipFont

  Thank you,
  Harald


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

  The tcllib/ChangeLog records only high-level changes.

  Changes to the individual modules are recorded in their
  own ChangeLogs, see for example modules/base64/ChangeLog


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

  Is the Tcl package 'scotty' known to the submitter ?

  See http://mini.net/tcl/691.html for description and
  references.


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

  I submitted the bug.

  The bug makes it impossible to run automatic email processing with file attachments.


login: mstrhh
username: mstrhh
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1928531
  Originator: NO

  Debugging gives this analysis:

  the parsepart code has a fixed line ending sequence of "crlf" coded in. Converting the input file to crlf line endings solved the extraction problem.

  So expect to have problems on Mac and Unix with this code.


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

  The bug has been fixed now, and the modification is now in the SF Tcllib CVS, together with an extended testsuite.

  Deeper analysis:

  The trouble is line 893 mime.tcl

  parsepart has parsed a part of the multipart out of it and is about to recurse into this sub-part for further analysis (part headers).

  It has start/end offsets, both of which are ok and now computes the size of the part. The general formula is
  size = end-start-1 = end-(start+1)

  However the actual size of the part is without the last EOL char (sequence). So this changes to

  size = end-start-eol-1 = end-(start+eol+1)

  Looking at the code we see a 'end-(start+3)', implying that mime assumes eol = 2, i.e. a 2 char eol sequence. Which for our case (plain unix file) is wrong. Luckily for use we can determine the actual length of the eol sequence in line 855f. If a \r is detected and removed eol = 2. Otherwise eol = 1.

  Replacing +3 with eol+1 and eol per above gives us a good size for the part and the resulting file is ok, without missing characters.


login: glauss
username: glauss
mimetype: text/plain
icomment:
  Please do not revert to the old implementation.

  Fix in mainframe.tcl
  proc MainFrame::setmenustate { path tag state } {
    variable _widget

    switch -exact -- $state {
    disabled { set state 0 }
    enabled  { set state 1 }
    }

  ....

  Sorry I've not learned how to supply a patch
  As soon I've manage this, i can send the fix


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

  The command is "::fileutil::magic::mimetype", as the name of the package. It is possible that in the interactive mode the auto-loader part of the tclsh helps and expands unique abbreviations of command names to the correct command. And "::fileutil::magic::mime" certainly is a unique abbreviation of the correct name. This type of help however is not active when executing a regular script, i.e. non-interactive.


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

  I have checked this and it works :) Thank you for assistance. I will mention this on ActiveState, their documentation seems to be misleading


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

  ActiveState's ActiveTcl pulls the documentation of Tcllib straight form the source. The only thing it does is to convert to HTML. I should know, I am the person doing the building. As such this is more likely a bug in Tcllib's documentation. I will check.


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

  Yes. This was a bug in Tcllib's documentation of fileutil::magic::mimetype (and fileutil::magic::filetype as well). This has been fixed now, and committed to the head.


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

  Do you have a patch for this ?

  Or alternatively can you give me an idea how to do the 
  special processing ?


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

  I should have scrolled down. Maybe I do need a coffee in 
  the morning :)


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

  This has been fixed, and test "bug-3.1" has been added to the Snit test suite to 
  cover the error condition.


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

  Be more careful what you type :)
  As I understand it, some lines get understood by the server.
  It's possible this is no longer the case with the Jabber MUC
  but I am not certain.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 305516: logger.diffs

  I am attaching a patch to support printing of multiple arguments passed to logger APIs. The patch ensures that it does not break any of the existing tcltests. Note that the following invocations are now considered equivalent:

  ${log1}::warn "Danger Will Robinson!"
  ${log1}::warn Danger Will Robinson!

  The output log msg for the above 2 lines will be exactly the same. Earlier, the 2nd call would have only printed "Robinson!".

  As for the patch, it has modified the interp alias command to pass additional argument -_logger::service" for child services. This makes it easier to strip out <service> string from the <txt> log message. The _setservice API has been modified to remove the "-_logger::service <service>" strings from $args.

  Added 1 tcltest to validate the new scenario.

  The version number in the pkgIndex.tcl file will have to be incremented appropriately (patch does not take care of this).


  File Added: logger.diffs


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

  According to the FORMAT section in the manpage of csv a
  value is quoted if it contains the separator character. In
  the example space is not the separator character, hence no
  quoting in the output. In this respect all commands in the
  csv module normalize the input. I.e. they accept quoted
  values even there not necessary but on output quote only
  where truly required.

  Does this behaviour cause problems with other tools ?


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

  the concern on my part is that I believe I have encountered
  csv tools which require a column to be quoted if it contains
  white space or seperation characters.  I am uncertain which
  tools.  I will google for more info on this topic.


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

  This is quite similar to the trace log feature in logger.


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

  Renamed ensemble command to ::coroutine::util to avoid the clash.
  Updated coroutine::auto package, user of this command.
  Committed to CVS Head.
  Versions bumped to 1.1


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I think, this is fixed, does not happen for me on windows.
  Report, if this is not the case.

  Thank you,
  Harald


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

  Thanks. Yes, your correction is right. I have accepted it,
  and extended the testsuite as well.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is for instance only used with the parameter -message of MessageDlg which is renamed to -text.

  Test script:
  MessageDlg .d
  Sets option:
  -> option add *MessageDlg.frame.msg.message  widgetDefault
  When applying the proposed patch, this is:
  -> option add *MessageDlg.frame.msg.text  widgetDefault
  Which sounds reasonable.

  OK, updated in CVS.


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

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

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


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

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


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

  won't there also be a problem if the file to be ftp'd has spaces in the name?


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

  Yeah, I forgot to mention that I rewrote the STOR command in my ftp server.  The ftpd::read command will get a line like:

  "STOR this is my file name.txt"

  If you split that line, it looks exactly the same.  Then it calls ftpd::command::STOR and currently: 

  set filename [lindex $list 0]  which would have a file on the server called "this"

  However, my STOR command says: set filename $list

  I think it's important that this package allow spaces in the names, since most windows users like to have spaces.  That's just my two cents.


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

  Re-reading the RFC 959 I think that the whole command/argument processing in the server is wrong. We are treating the line as  Tcl list (set parts [...]) but the RFC says that after the command comes one separating space char, and everything after to the end of the line is one argument field, spaces and all. Which means that the code separating command and argument has to be redone ... Hm ... Possible solution is 'regexp' to find and split on first space.

  regexp {^([^ ]+) (.*)$} $command -> cmd argument

  and the lindex/lrange commands in lines 538 and 553 can be removed, replaced by the variables set by the regexp.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 230158: ftpd.diff

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 230163: ftpd.diff.2

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff.2


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

  Done - I left in messages about aborting the package when
  not found, though.


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

  This has been fixed in TEPAM 0.4.1 that has been commited on March, 25th, 2013.


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: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  >% huddle jsondump [huddle create key 000000]

  >{"key": 000000}

  this is a miss logic about huddle-lib in jsondump sub-command.

  the token '000000' should output as '0' or "000000" (string),
  but jsondump outputs as raw '000000'.

  because in huddle.tcl:455,

  > if {[string is double -strict $data]} {return $data}

  'string is double' returns 1, and the line returns raw.

  but I don't know to treat vague values strictly.

  current huddle classify only 'string' / 'list' / 'dict' only.

  for example, in jsondump, each token will be considered dynamically.

  comments?


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  by the way,

  according to http://yaml.org/spec/1.1/
  > Example 2.19. Integers
  > 
  > canonical: 12345
  > decimal: +12,345
  > sexagesimal: 3:25:45
  > octal: 014
  > hexadecimal: 0xC

  do you think, the integer 000000 is regal?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10449: 459197.diff

  Logged In: YES 
  user_id=75003

  Added file containing the patch from the description.


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

  Hm. Are the implementations of the ftp commands (ABOR, etc) 
  public API ? I thought not. They are accessed directly from 
  the other parts of the demon and I would not export them.


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

  Perhaps not ... I wasn't sure abourt ABOR, etc so I just included them. 
  I am not also sure whether docRoot and fs are exported or not.
  If we refer to ftpd docs (http://tcllib.sourceforge.net/doc/ftpd.html) it provides only two
  two public APIs ::ftpd::server and ::ftpd::config.

  So, I will leave it upto the author/maintener to decide which APIs to export.


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

  The author is/was Steffen Traeger who is interested
  in other things now and there is no official maintainer.
  (tcllib does not have such a big structure like tcl).

  Ok, I leave ABOR etc. out of the export, docRoot and fs in.


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

  We now provide a jabber accessible pasting site at
  paste.tclers.tk so we should hook up to send messages to
  there. It replies with the new URL.


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

  Added a dialog and menu items to send clipboard or pasted
  text to the paste.tclers.tk site.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the report.
  I tried with current BWidget 1.9.5 and TCL 8.5.11 on Windows Vista:
  package require BWidget
  pack [Entry .foo\ foo]
  pack [ttk::entry .foo\ foo\ 2]

  The error appeared.
  When line 1438 of "widget.tcl" in function Widget::focusOK is changed from
      set value [uplevel \#0 $value $w]
  to
      set value [uplevel \#0 [list $value $w]]
  the error disapears for me.
  This change seams logic to me as uplevel uses concat to assemble its arguments.

  Could you please confirm if this fixes the issue ?
  The modified "widget.tcl" file is attached for your convenience.

  -Harald


login: jaspertheperson
username: jaspertheperson
mimetype: text/plain
icomment:
  This change fixes the issue for me.
  Note that the original issue appeared even if no BWidgets were displayed -- it appears the BWidget traversal handling routines were somehow overwriting the base Tk and Tile versions of the same routines. This in itself is also a bug.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I am not happy that the original is overwritten and I suppose, there are other issues with this. Nevertheless, it seams to work now.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Updated the certs. SimpleCA does not (seem to) allow me to specify an expiration date, it seems to be fixed to a single year. Updated the README.


login: eee
username: eee
mimetype: text/plain
icomment:
  There are still expired certificates in various places.

  examples/smtpd/server-public.pem expired Sep/10/2012 (and appears to be a CA root cert?)

  examples/transfer/certs/receiver.crt expired Apr/08/2010,
  examples/transfer/certs/transmitter.crt expired Apr/08/2010,
  but examples/transfer/certs/ca.crt is good for another six years, and is a CA root cert.

  modules/devtools/receiver.crt expired Nov/08/2012,
  modules/devtools/transmitter.crt expired Nov/08/2012,
  but modules/devtools/ca.crt is good for another 8 years, and is a CA root cert.

  It should be fairly trivial to modify SimpleCA to fix certificates to a ten year lifetime instead of one year, and if you do that I recommend going to 4096 bits as well.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Committed rev [7b80198969]. 10 year certs, 4096bits.
  The README was ok, listing both "comm" and "pop3" as users.

  ... Grr ... Should not have committed ... I still see errors with the new certs, in the two test suites :(
  Claims cert expired. SimpleCA otoh claims valid until 2023.
  Will have to dig deeper, again :(
  Tempted to make 100yr certs, after I understand the continued failure.

  Now how do I again tell TclTLS how to spit out more internal data about the cert verification ?


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

  Found my problem. I extended the root cert validity period also, to 100 years, and this screwed things. I suspect a y2038 problem (aka 32/64 time_t). Going back to 10 years root cert (+10 days), and the result worked. 

  We now have 10 year certs, at 1024 bit.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9810: comm.tar.gz

  Logged In: YES 
  user_id=75003

  Enclosed a version of comm updated for inclusion into 
  tcllib (tests, namespaces, ...).


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

  Hm. Atleast the BWidgets module has its own released tar 
  files. mclistbox and widgets could go together as a tklib. 
  tclbench as it is right now is quite developer centric, 
  especially in handling. I would not add it to the tcllib 
  release in this state. It needs a bit of cleanup to make it 
  easier to use. tclapps could have its own release too.


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

  Are you sure that's a good idea?  I thought we were going to 
  leave Tk packages out of tcllib, and put them in some future tklib.  
  The package structure is separate for each of the different 
  directories.

  But now I see that Jeff created tklib as a package parallel to 
  tcllib.  And it would also appear that almost everything in the 
  tcllib cvs is tagged with tcllib-1-1-0.  But would it make sense 
  to have  several different directories all in the same tcllib.tar.gz?  
  Can I package and release that as tcllib-1.1.0, when it will include 
  a lot of new stuff?  How do I number the BWidget library directory 
  name?  Tcllib-1-1-0 is quite a few changes newer than 
  bwidget-1-3-1.

  I was really expecting the maintainers of mclistbox, tclapps, tclbench, 
  and widget to eventually mark a new release with whatever number 
  was appropriate for that package, and I could then release a separate file.


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

  Retracting this request. The module already contains
  "SplitMailto" and "JoinMailto" commands.

  Should have looked into the module before writing it.


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

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


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

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

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


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

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

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


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

  Still got that error with v 1.263:

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

  As for Miguel, otherwise tkchat works as normal.


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

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


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

  Thanks. This is fixed now. Ditto the missing pkgIndex.tcl in the module itself. Oops.


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

  Error recreated using your test code.  Correction applied
  via your suggestion.  Thanks.


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

  Does the Tcllib 1.9 RC2 have the same problems ?
  The foundations (programmed dialog) of the testsuite was
  changed completely.

  Urls to download the RC2 on the Tcllib-devel mailing list.
  Alternatively retrieve CVS Head. Identical modulo ChangeLog
  tags.


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

  Would you like an account on my FreeBSD/amd64 system?

  Please, send me your ssh public key and your /etc/passwd 
  entry. Yours,

         -mi


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

  Why the /etc/passwd ? would you not need only a user name
  and passwd ? The latter even disposable, chsnged on first
  login ?

  Otherwise, yes, interested.


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

  /etc/passwd does not contain the actual password (which I 
  don't need and you will not use anyway). What I need is 
  your login-name, your numeric ID, your preferred shell, 
  etc. All of this is nicely specified in the single line 
  of /etc/passwd. You'll get it by running something like:

  fgrep andreas /etc/passwd

  (substitute "andreas" with your actual login-name).

  And the SSH-key, of course. If you use PuTTY, it has a way 
  to export the key in the "OpenSSH format".

  You can e-mail this to me directly at 
  mi+sourceforge@aldan.algebra.com

  Yours,

         -mi


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

  I got my account and ran the testsuite. The problems
  reported here are gone now. Closing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  SourceForge should allow you to "attach" files to this report. Such a file can be a "patch" showing the difference between old and new code, or it could be the the whole new code.

  Look for the text "Add a file" on the bug page. As you are the creator of the report you should be able to see this when you are logged in. It is a button you can click on and then enter the path to the file for upload.


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

  Next version of the patch, made after running the newest
  frink, v2.1.3, against tcllib. This cut down on the number
  of bogus 'missing final return' quite good.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7675: 8.diff

  Logged In: YES 
  user_id=75003

  Final patch, frink 2.1.5, new sha1, changed md5, base64.


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


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

  Ah. I believe I understand. cpush creates a context, but did
  not initialize the location information for the context. And
  somewhere later the location data was accessed, and not
  present. Ok. Accepted the patch.


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

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


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

  Enclosed a bug fix. The problem seems to be that conversion 
  from mouse location to row does not work for an unmapped 
  listbox. Added some code to retrieve the first visible 
  column and use that for the conversion.


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

  I have simplified your demo script using a canvas showing only one box (and not the dot graph) and checked it using windows and linux.

  Unfortunately, there was no unexpected behaviour when zooming in or out (bind buttons or maximize function).

  Chould you please:
  - verify, if the attached script shows the issue for you (eventually change the size of the box)
  - Post your platform and display details (resolution, main window size)

  Best regards,
  Harald

  -Example script-
  lappend auto_path .
  package require BWidget

  set sw [ScrolledWindow .sw]
  set cvs [canvas .sw.cvs]
  $sw setwidget $cvs
  pack $sw -side top -fill both -expand yes
  bind $cvs <Button-1> "zoom $cvs 1.1"
  bind $cvs <Button-2> "zoom $cvs 0.9"
  $cvs create rect 0 0 500 500 -fill red
  $cvs configure -scrollregion [$cvs bbox all]

  proc zoom {cvs factor} {
  $cvs scale all 0 0 $factor $factor
  $cvs configure -scrollregion [$cvs bbox all]
  }
  -EOF-


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Put to pending state. It works for me. Please inform if there is still an issue. Note that the used ScrolledWindow got improved in cvs.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Private E-Mail resulted in the test script:

  set sw [ScrolledWindow .sw]
  set cvs [canvas .sw.cvs]
  $sw setwidget $cvs
  pack $sw -side top -fill both -expand yes
  bind $cvs <Button-1> "zoom $cvs 1.1"
  bind $cvs <Button-2> "zoom $cvs 0.9"
  $cvs create rect 0 0 416 283 -fill red
  $cvs configure -scrollregion [$cvs bbox all]

  proc zoom {cvs factor} {
  $cvs scale all 0 0 $factor $factor
  $cvs configure -scrollregion [$cvs bbox all]
  }

  I got the endless loop when I press zoom, zoom, unzoom, zoom on Linux, not Windows.
  The issue arised, because the window size was changed when the scrollbars were mapped.

  The issue is solved by a more severe locking.

  Please report, if this works or if it raises other issues.


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

  Some of this is fixed in asn 0.8. I added a asn::peekTag, and some others to handle multi-byte tags and retag things. Not the best solution currently, but works. 

  PeekBytes is basically not needed, as the asn data is just a string. If you want a peek at the first x bytes, simply use string range for now, it works fine with binary data.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report.
  I have tried your script on windows and on Linux.
  In both cases, Item_27 is visible. The items are on two lines for me, making the display quite cluttering and results in a slightly clipped item 27 at the bottom.

  Maybee, my default fonts or sizes are different than yours.

  My thoughts about the update solution:
  tk requires "update idletasks" to evaluate required screen sizes, so scrollwindow may not work without an update. So an update might be required by design.

  update is always a tradeoff, because other tasks (like after or file events) may occur withoin the update. For this reason, it is often helpful, if updates are coded manualy (and not within BWidget library), so you are able to control them.

  In consequence, your update solution may be a good solution.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed, but acceptable by design.
  Please use "update idletasks" to update widget sizes before using the see subcommand.


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

  Duplicate of https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1793855&group_id=12883
  Note: While this is fixed in the CVS Head it came to late for inclusion into the 1.10 release.


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

  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

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


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

  Logged In: YES 
  user_id=75003

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


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

  Logged In: YES 
  user_id=75003

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


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

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

  Larry ?


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

  I will incorporate this patch in Plotchart. Unfortunately my connection to the Internet from my development PC (at home) is at this moment unreliable at the best of times and non-existent on average.


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

  I am sorry, I have tested the package 2.0 with Tcl HEAD
  (updated and recompiled today) Windows XP (32-bit), and
  there is no problem - the test suite runs with no error.

  I guess the bug is somewhere in 64-bit integers handling,
  and/or even bignums.
  Maybe others areas of tcllib are impacted, this may be a
  problem related to the core, and which does not happen on
  32-bt systems.

  I feel sorry for you, but I'd only seek for a solution if I
  have a 64-bit system under my (dirty :^) hands...


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


  Selecting bigfloat-int2float-2.9.2.3
  for more analysis, on 32-bit system
  I see:

  % int2float [fromstr 5000000000] 5
  F 21474836480000000000 -32 42951

  On 64-bit I see:

  % int2float [fromstr 5000000000] 5
  F -125100849711610 -32 42951


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

  This tests relies on the output of the builtin string command of the core in case a bogus method is used. It seems that the methods 'totitle' and 'toupper' have switched places. The new order is alphabetical ... It seems that the two tests are both already constrained to Tcl 8.5 only, that makes fixing it trivial, no need to create separate test cases for 8.4/8.5.


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

  Also, the error message begins with a different string: "unknown or ambiguous subcommand" as opposed to "bad option".


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Well, the error message tells, that there is no method "config" within a SpinBox.
  This is correct. It is called "configure".
  And the "cursor" package uses "config" which might be a bug there.

  I am not the person to clarify this. Jeff or Andreas, may you enlight me, where to fix this best ?

  I would favor to patch the cursor package which is clearer IMHO.

  While waiting, please replace "config" be "configure" in line 63 of cursor.tcl

  Regards,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  By E-Mail:
  Andreas Kupries:
  My opinion: tklib::cursor. It should not use shorthands.
  Extending bwidgets to support shorthands can/may come later. 
  Jeffrey Hobbs:
  Both.  BWidgets doesn't actually support subcommand shorthand, which is
  IMO a misfeature because all Tk widgets do support it.  However,
  strictly speaking, shorthand shouldn't be used for "permanent" code, so
  tklib::cursor is what needs to be updated first.

  Harald:
  Ok, subcommand shorthand is an enhancement request for BWidget.
  It is not in my implementation plans at the moment, patches welcome.

  I will reassign the bug report to TkLib


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



  File Added - 260327: poisson.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  I'm submitting a collection of files as a zip archive. These include:
   * poisson.tcl
      - pdf-poisson
      - cdf-poisson
      - random-poisson
      - Definitions of tests & helper procs
   * possion_test.tcl
      - The code that runs the tests, including a visual comparison of a histogram produced by random-poisson and the pdf
   * simpletest.tcl
      - The code to run the non-visual tests
   * incgamma.tcl
      - Implementation of the incomplete gamma function

  This code is more explicit about the tests.

  Also, it includes one bug fix: the cdf should have been evaluated at floor(x), rather than at x. This is now corrected.

  Eric

  File Added: poisson.zip


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

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


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

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


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

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

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

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

  Michael


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

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

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

  Michael


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

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

  package require logger

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

  namespace eval ::foo {

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

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

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

  ::foo::x

  When I execute the above, it used to print:

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

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

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

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

  Hemang.


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

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

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

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

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

  Michael


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

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

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


  package require logger

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

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

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

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

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

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

  Hemang.


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

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


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

  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: techentin
username: techentin
mimetype: text/plain
icomment:
  Good call.  I implemented a fix a little differently from the patch, by moving the floating point conversion (and octal leading zero issue) into units::reduce.


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

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


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

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

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

  Please reply in case of other opinions.


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

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


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

  Fixed. The procedure "commIncoming" used a blocking "gets" to read the line of versions offered by the connecting side. Replaced with non-blocking gets, and event-handling, splitting "commIncoming" into two parts.

  I believe that this affected all versions of comm since the first version made.

  comm version 4.6.2.


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

  I'll learn to make a bug/patch report right the first time
  sometimes, promised. (forgot the diff -c file) 


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

  However internal results can still be larger than int, right ?

  Should we care ?

  How much performance do we lose for pre-8.5 Tcl because of
  the additional conversions ?


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


  After TIP 237, you do not want
  to allow the computed numbers
  to grow without bound.

  Whether you limit them to 32-bits
  or 64-bits doesn't really matter, IMHO.
  (That's why I suggest int(.) as the 
  fix, without regard to what length that means)
  At either range you'll stick to computation
  that can be done with native types, either
  long or Tcl_WideInt.

  But without some limit, pretty soon
  you're chugging away on values literally
  thousands of digits long, just to keep the
  last 10 or so.  The small test suite literally
  runs for hours.

  Dunno about performace cost to 8.4 and
  earlier.  It's something that can be dealt
  with if needed though.


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

  Adding some extra ops to truncate seems to make it a bit
  slower with both 8.4 and the current 8.5 head. Using int()
  or &0xffffffff seem to be equally slow. 

  I'm going to rig it to switch on the interpreter version and
  try and get the fastest implementation that will remain correct.


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

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


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

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

  Updated in cvs.


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

  Yes. I'm seeing this too -- on FreeBSD-6.0/amd64. Please, 
  advise. 


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

  I think, I found a fix. For some reason, attachments seem  
  disabled on this page, so here is the patch inline (be careful  
  of the white-space mangling):  
    
  --- modules/dns/ipMore.tcl      Fri Sep 30 14:03:58 2005  
  +++ modules/dns/ipMore.tcl      Tue Oct 18 01:15:38 2005  
  @@ -400,8 +400,9 @@  
   proc ::ip::maskToInt {mask} {  
       if {[string is integer -strict $mask]} {  
  -        set maskInt [expr {(0xFFFFFFFF << (32 - $mask)) &  
  0xFFFFFFFF}]  
  +        set maskInt [expr {(0xFFFFFFFF << (32 - $mask))}]  
       } else {  
           binary scan [Normalize4 $mask] I maskInt  
       }  
  +    set maskInt [expr $maskInt & 0xFFFFFFFF]  
       return [expr wide([format "0x%08x" $maskInt])]  
   }  
   
  This seems to work for me... 


login: aakhter
username: aakhter
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=736414

  The bug is currently assigned to me, but I don't have a 64 bit 
  system to work on this. Do I have write access to CVS to 
  commit this fix?


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

  Aamer, I have a 64bit system (linux/amd64) and have verified
  the patch as well. I will commit it in a few minutes,
  currently doing the admin work for it.

  Beyond that, yes, you do have write access to the Tcllib CVS
  at SF. It enabled that at the time I added you as a developer.


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

  Committed to CVS head. Only one change to the patch: The
  masking expression got braced.


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

  If only you did a PRE-release testing on a single 64-bit 
  platform :-( 


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

  Dude, I did plenty of pre-release
  testing, but you sneaked this module
  in just days before release, missing
  all the testing that was done.

  The closer to the deadline you make
  code changes, the less testing you
  can reasonably expect them to get.


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

  I have nothing to do with Bwidgets and its internals. DamonC
  and JeffH are the maintainers. Possibly Daniel South
  (wildcard_25) as well. As it was with Damon already it now
  goes to Jeff.


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

  I didn't see that bug anymore, but I saw it in the past.
  IIRC, check in:

  Wed Jan 26 01:01:24 2005 UTC (16 months, 2 weeks ago) by hobbs
  Branch: MAIN
  Changes since 1.145: +5 -0 lines
  Diff to previous 1.145

  * notebook.tcl: reverted lester patch - too many bugs
  related to
  deleting and reinsertion of tabs.

  fixed the problem. 

  At least something like


  package require BWidget

  wm geometry . 200x200
  NoteBook .nb
  pack .nb -fill both -expand yes
  foreach page {zero one two three four five} {
      .nb insert end $page -text $page
  }
  after 2000
  foreach page {two three four five} {
      .nb delete $page
  }

  works for me as expected, with a almost recent BWidget cvs
  version.


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

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


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

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


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  File Added - 242147: patch_v2

  Logged In: YES 
  user_id=13222
  Originator: YES

  After email feedback by Andreas Kupries, I updated the patch. Minor changes, the propose still stands as outlined in the feature request.

  Patch is still bare implementation.
  File Added: patch_v2


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

  Committed a modified patch, with slightly different option processing (-pkgdir (singular)) and defaults. All the wanted functionlaity is still present.


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

  The attached changed implementation fails the testsuite.
  As the testsuite as is does not use the new functionality,
  the new code is breaking existing functionality.


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

  Accepted, with small change in join, fixing the testsuite
  breakage. Extended testsuite and docs to cover the new
  functionality.


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

  Extra scenario:
  Installed apache ftp server from
  http://incubator.apache.org/ftpserver/ on win-xp (all default).

  And the output is (as you can see even other behaviour,
  nothing is prefixed now):
  % package require ftp
  2.4.4
  %
  % set h_ftp [ftp::Open 10.17.101.53 anonymous myPwd -port 21
  -mode active]
  0
  % # Case 1
  % ftp::NList $h_ftp  edidata/Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 2
  % ftp::NList $h_ftp  edidata/Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML
  % ftp::Cd $h_ftp edidata
  1
  % # Case 3
  % ftp::NList $h_ftp  Catalog
  einpr45012023322_I.XML einpr47121440651_I.XML
  % # Case 4
  % ftp::NList $h_ftp  Catalog/
  einpr45012023322_I.XML einpr47121440651_I.XML


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

  The ftp packages NList command basically just passes through
  whatever it receives from the FTP server, without
  postprocessing, so you directly see the server differences
  (similar to what you would see if you used a typical command
  line ftp client).

  The RFC does not make any real assumptions how the returned
  filenames have to look like:

           NAME LIST (NLST)

              This command causes a directory listing to be
  sent from
              server to user site.  The pathname should specify a
              directory or other system-specific file group
  descriptor; a
              null argument implies the current directory. 
  The server
              will return a stream of names of files and no other
              information.  The data will be transferred in
  ASCII or
              EBCDIC type over the data connection as valid
  pathname
              strings separated by <CRLF> or <NL>.  (Again the
  user must
              ensure that the TYPE is correct.)  This command
  is intended
              to return information that can be used by a
  program to
              further process the files automatically.  For
  example, in
              the implementation of a "multiple get" function.

  It talks about 'valid pathname', if the results you see do
  not match the description in the RFC the server is buggy.
  The exact specification for 'pathname' is vague at best:

        pathname

           Pathname is defined to be the character string
  which must be
           input to a file system by a user in order to
  identify a file.
           Pathname normally contains device and/or directory
  names, and
           file name specification.  FTP does not yet specify
  a standard
           pathname convention.  Each user must follow the
  file naming
           conventions of the file systems involved in the
  transfer.

  The only 'safe' way i see is to CD to the working directory
  your interested in an invoke the NLIST command there, as
  that excludes all directory name prefix issues.


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

  I did some extra testing and I now convinced this is a
  ftp-server problem, not a tlclib problem. (thanks mic42 for
  the remark)
  * If you want to Use set directory listing to UNIX (to solve
  backslash problem)
  * Always add a slash to the end of a directory when using
  NList (solves directory prefixing)

  Is this something to add to the doc. as a remark ?


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

  Fixed in the CVS head. This was problem with the doctools core, not just dtplite. The layer doing syntax checking generated the warnings in all passes. For HTML, a two-pass backend, that caused two warnings per actual problem. Modified to suppress generation of warnings in a ll but the first pass. Errors were no problem, as they stopped execution, i.e. in the first pass.


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

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



  File Added - 133295: tkchat.NickListv2.diff

  Logged In: YES 
  user_id=596509

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


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

  Logged In: YES 
  user_id=596509

  updated for current head. v1.287


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

  The userinfo dialog has been in for a while.
  I don't think I'm ever likely to deal with images though.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Can you please test this against older versions of the Tcl core (8.5, 8.4) and/or on other platforms ?

  I am asking because when I tried to reproduce the problem, using Tcl 8.4.15 and 8.5.3, both on Linux, I do not have any trouble. I used fileutil 1.13.6 (CVS Head). The only difference to 1.13.5 is the fix to make stripPath case-insensitive on Windows.

  I have a feeling that this is exposing a bug in the handling of paths by the Tcl core.

  My session logs

  andreask@gila:~/workbench/u/tcllib/modules/fileutil> tclsh
  % source fileutil.tcl
  % package provide fileutil
  1.13.6
  % info patchlevel
  8.4.15
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  % fileutil::jail /temp /a
  /temp/a
  %

  andreask@gila:~/workbench/u/tcllib/modules/fileutil> ~/Abuild/bin/tclsh8.5
  % source fileutil.tcl
  % package provide fileutil
  1.13.6
  % info patchlevel
  8.5.3
  %  fileutil::jail /temp /a
  /temp/a
  %  fileutil::jail /temp /a
  /temp/a
  %  fileutil::jail /temp /a
  /temp/a
  %


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Looks like you might be right.  filutil 1.13.4 on Tcl 8.4.19 does not exhibit this behaviour. fileutil 1.13.5 on Tcl 8.6b1 does. Both on XP SP2. I'll load the same tcllib on the 8.4 installation and try it there. That should confirm it.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  I just verified that Tcl 8.4.19 does not exhibit this bug using the same fileutil version (1.13.5) that was being used with Tcl 8.6b1. So it does appear something has changed in the core.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  I've added a bug for this to the Tcl SF bugtracker - 2571597

  (woof) 1 % file pathtype /a
  volumerelative
  (woof) 2 % file normalize /a
  C:/a
  (woof) 3 % file pathtype /a
  relative

  /Ashok


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

  Maybe duplicate existing underscores to quote them ?

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


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

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

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


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

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

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

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

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

      return [string map $subs $name]
  }

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


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

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


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

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

  What I'd like is a solution that:

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

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

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

     Snit_hmethod_4_a_b_c
     Snit_hmethod_5_a_b_c

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

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


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

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

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

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

  Now lets try this

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

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

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

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

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

  It looks relatively readable as well.


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Not a bug. The puts statements are already commented out in the CVS head.
  However, this action doesn't seem to have been added to the ChangeLog.
  It is therefore unknown who has done the work.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Is it possible to provide us with a small script demonstrating how to cause the problem, i.e. crash ?


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  I uploaded a small script which reflects a very minimalized version of what is going on in my program. The program runs in a infinite while loop pausing for 60 seconds then rechecking for new files. The program runs continuously. I had a log with the error in it and unfortunately deleted it. It's actually not hard crashing but instead throws a "error" msg with a trace back to the close statement. Since this trace is really not helpful, as it's not really an error in my code, it seems more reasonable to catch this event and pass a more appropriate error msg and not dump a code trace.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. The script looks ok. I will try to reproduce this with some fake ftp server and files.

  (Note: I am uncomfortable with simply putting in a catch without understanding why the close threw an error. It feels too much like simply plastering over hole without killing the termite which created it).

  A pity that you deleted the log already, or I would have asked for the relevant part of it.
  Do you remember what the error message was ? (close has several conditions where it can throw an error, with distinctive messages).


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Ya, I don't remember what the exact error was. I will change things back to the original state and see if it will fail again. Once I have a log I will upload it.


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

  I'm closing this. I think the following was happening: The connection was open, files being transferred, connection was broken by external forces, my app then tried to close the connection but it was already close. This triggered an error. The catch on your close included dumping the error info and we got an odd dump of stuff from a different catch being done in my app that made it look like my app was crashing. I have now utilized your -output option to redirect your output to a proc and I also added clearing the ::errorInfo var to my app so the odd dump is not longer involved. I think this is basically a false alarm. Sorry about that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  No problem, and glad to hear that you figured it out.
  A bug where I have not to do anything is the best kind of bug ;)


login: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=410366

  Here is the patch which seems to fix the bug:

  --- /usr/lib/tcllib1.8/sasl/sasl.tcl    2005-09-19
  16:12:39.000000000 +0400
  +++ /usr/local/lib/sasl1.0.0/sasl.tcl   2006-03-18
  21:24:10.736909032 +0300
  @@ -76,7 +76,7 @@
       set context [namespace current]::[uid]
       variable $context
       upvar #0 $context ctx
  -    array set ctx [list mech {} callback {} proc {} service
  {} server {} \
  +    array set ctx [list mech {} callback {} proc {} service
  smtp server {} \
                          step 0 response "" valid false type
  client]
       eval [linsert $args 0 [namespace origin configure]
  $context]
       return $context
  @@ -401,7 +401,7 @@
                   set realm [eval $ctx(callback) [list
  $context realm]]
               }

  -            set uri "smtp/$realm"
  +            set uri "$ctx(service)/$realm"

               set A1 [md5_bin "$username:$realm:$password"]
               set A2 "AUTHENTICATE:$uri"


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

  Added to CVS Head. Added documentation, which was missing,
  and a tiny testsuite for nl2br.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  First step, made tests in 7 files properly independent, using tcltest v2 abilities.

  ./graph/tests/ops/componentof.test
  ./graph/tests/ops/tarjan.test
  ./graph/tests/ops/components.test
  ./graph/tests/ops/adjmatrix.test
  ./graph/tests/ops/prim.test
  ./graph/tests/ops/kruskal.test
  ./graph/tests/ops/bipartite.test

  This covers all tests coming before bipartite, and a number coming after. Not all. Conversion of the remaining files will be an incremental effort.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Well, first tests are not able to replicate the problem.
      Linux + Tcl 8.5.7 + TclOO 0.6.1
  Ditto for a second system:
      Linux + Tcl 8.6b1.2 + TclOO 0.6.2

  I am suspecting a TclOO bug now, for your particular revision. It would have to be in variable resolution.

  qret is an instance variable declared in line 19 of queue_oo.tcl, initialized in line 27 (constructor), and is accessed in nearly all methods, including 'size'. In our context (op::isBipartite?) there is only one queue method run before 'size', namely 'put', which is one of the few methods not using that variable. The test in question is also the first test where the graph is not empty, thus actually arriving at the code using the queue and loop.

  So, class def looks fine to my eyes. Should possibly ask DKF for his opinion on that too.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Would it explain the symptoms if
  "TclOO 0.3" was getting used?

  Can probably classify this as PEBKAC,
  since such old "alphas" should be uninstalled.

  Possibly there's an improvement here for
  tcllib code using TclOO to demand something
  more recent, but I'll leave that to the maintainers.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks Pietro. I will work on getting this into the code in the next days.
  And I am glad to hear that the %D formatting is a fix too.

  (I guess that the %D formatting is also affected by the TZ, in the inverse manner to the iso parser, thus canceling the TZ).


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

  Basically the url is invalid according to:
  http://www.ietf.org/rfc/rfc1738.txt (Section 3.3), the ? is reserved inside the searchpart of an URL and would have to be escaped.
  http://www.ietf.org/rfc/rfc2396.txt (Section 3.4) agrees with this.

  This appears a lot in the real world (especially due to PHPs crappy and incorrect url and form handling), so perhaps the URI package should deal with such broken urls.


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

  I agree that we should try to handle this, at least if it can be done in a simple manner. Like looking for the first ? instead of the last. as we are using regexes this may require higher versions of Tcl and Advanced RE stuff (non-greedy ops) ...


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

  Fixed using 'string first' instead of RE's. Extended testsuite. Version now is 1.2.1.


login: 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:
  moved the destroy command to the per-connection section of the manual. this is consistent with the code.


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

  Thanks Michael. This has been fixed now in the CVS.

  2007-01-22  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * mime.tcl (word_encode): Ensured the return of the empty string
    when given the empty string.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I did not really check your bug report because it is so time intensive to build up a test environment and try to find out what is happening.

  Instead, I want to ask you:
  - is the bug still an issue ?
  - does it still arise with the current cvs of bwidget ?
  - if yes, could you please simplify your code to just the usage of the ComboBox in question.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue is reproductible on windows and on linux.

  I think the following point might be the issue:
  - Dialog sets a global grab on its own
  - The Listbox of the ComboBox gets a global grab if it is posted.
  - There is normally a focusOut binding on the listbox, that when there is a click anywhere else, it is closed and the grab is released (and returned to dialog).
  The (highly risky) issue of grabs has troubble here.

  I do not want to go here any further.
  For me, it is ok at the moment, that it works in the normal case when the normal interface is used.
  Maybe, I will come later to the issue.
  Could you post the simplified version on the web site ?
  It shows the issue on linux and windows and does not have the installation system included.

  Thank you,
  Harald


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

  This problem is not Tablelist-specific.  Replace the tablelist with another widget, e.g., a Tk listbox or text widget, and you will see exactly the same behavior.

  I am no [incr Tk] expert, but apparently it is the

      itk_component add table {
          tablelist::tablelist $itk_component(sf).table
      } {}

  command in your script that causes the trouble (probably because $itk_component(sf) is a scrolledframe widget).  Replace it with

      set cs [$itk_component(sf) childsite]
      tablelist::tablelist $cs.table

  and update the pack command accordingly.  After these changes, the script will work as expected.


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

  >% ::struct::set include myset A <- non initialized set but there is no constructor!
  >can't read "myset": no such variable

  This looks to be a bug.

  > % ::struct::set size myset
  > 1 <- must be 3

  This is operator error. The 'size' method takes a set, not the name of a set variable. I.e. call this as

      ::struct::set size $myset

  Note the $

  Ditto for the 'empty' method.


login: sjeanjean
username: sjeanjean
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2028198
  Originator: YES

  Thanks for the very quick response.
  It's one of the (very few) drawback of Tcl. The commands can take a variable or the name of a variable without a whole coherency.

  For info, the bug of the undeclared set occurs in my test report but not in my code.


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

  Ok. I will see if I can replicate it. If not I will close the bug, otherwise the testsuite will have to be extended and a bug fixed.


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

  Some experimentation shows that the error is shown only for the critcl implementation of struct::set.
  The Tcl implementation of the package is free of it.


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

  Fixed in head. A related problem, the method 'add' did not behave like 'include' just for a set vs item to include, it was not creating a non-existent variable. This was for both Tcl and critcl.implementations, has been fixed as well now. Package version is 2.2.3 now (tcllibc/critcl version unchanged however).


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

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


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed. I will talk to the original author (Donal Fellows) about this.
  It might be that he simply wrote the example wrong. Especially as the
  following code does work, using 'singleton' in place of 'class'. 

  ooutil::singleton create example {
      method foo {} {self}
  }

  puts [[example new] foo]
  puts [[example new] foo]

  Note: Given that the package is named "oo::util" (with ::) I will rename
     ooutil::singleton
  to oo::util::singleton
  shortly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Better quoting would be

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

  in case proc name contains spaces.


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


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


login: mic42
username: mic42
mimetype: text/plain
icomment:
  The results of an ldap search are not autoconverted, because they might be binary data and not utf-8 encoded, for example jpegPhoto attributes or similar things.

  Please check if you get the correct result if you apply [encoding convertfrom utf-8 $data] to the results you get. If that is the case this is the expected behaviour, if not its really a bug.

  The ldapx package has some helpers to do this automatically, see the documentation at:
  http://tcllib.sourceforge.net/doc/ldapx.html especially the -utf8 option.


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

  Thanks for your support. I could not understand it but the fix does work for me (using encoding convertfrom utf-8).

  Reason I could not understand it: I used to code in php and from there the data obtained from ldap search is UTF-8. I especially don't know what sense it make to convert from utf-8 when current locale is utf-8, which means converting from utf-8 to utf-8 solves the problem! But anyway thanks for quick respons, two days later we have big problem delaying the business.


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: cwjolly
username: cwjolly
mimetype: text/plain
icomment:
  Looked at the new code and modified it to work like what I had done with the 1.0 version with some minor changes. The value quoting is optional and rather than using args to json2dict I use defaults 
  so instead of   "json2dict jsontxt -indexlists 1 "   you have "json2dict jsontxt true true "  where first true is for indexlists and 2nd true is for quotevalues.  I also attach the modified driver script.


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

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

  I will take action to improve this.


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

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


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

  Adding the lines below (diff with 1.339) allows the proxy 
  password to be saved. 

  C:\Program Files\tkChat>diff -u tkchat-
  torsten.vfs\bin\tkchat.tcl tkchat-
  torsten.vfs.proxypw\bin\tkchat.tcl
  --- tkchat-torsten.vfs\bin\tkchat.tcl   Tue Jun 27 15:16:38 
  2006
  +++ tkchat-torsten.vfs.proxypw\bin\tkchat.tcl   Tue Jun 27 
  16:38:11 2006
  @@ -3437,6 +3437,10 @@
          ${NS}::label .logon.lpap -text "Proxy Auth 
  Password" -underline 13
          ${NS}::entry .logon.epan -textvariable 
  Options(ProxyUsername)
          ${NS}::entry .logon.epap -textvariable 
  Options(ProxyPassword) -show {*}
  +       ${NS}::checkbutton .logon.rprxpw \
  +               -text "Remember Proxy Password" \
  +               -variable Options(SaveProxyPW) \
  +               -underline 0
          ${NS}::label .logon.lnm -text "Chat Username" -
  underline 9
          ${NS}::label .logon.lpw -text "Chat Password" -
  underline 6
          ${NS}::entry .logon.enm -textvariable 
  Options(Username)
  @@ -3529,6 +3533,7 @@
          grid x          .logon.lph    .logon.fpx   -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpan   .logon.epan  -in $lf -
  sticky w  -pady 3
          grid x          .logon.lpap   .logon.epap  -in $lf -
  sticky w  -pady 3
  +       grid x          .logon.rprxpw    -                 -
  in $lf -sticky w  -pady 3
          grid .logon.lnm .logon.enm    -            -in $lf -
  sticky ew -pady 5
          grid .logon.lpw .logon.epw    -            -in $lf -
  sticky ew
          grid x          .logon.rpw    -            -in $lf -
  sticky w  -pady 3
  @@ -4251,7 +4256,7 @@
          Emoticons EnableWhiteboard EntryMessageColor errLog 
  ExitMessageColor
          Font,* Fullname Geometry HistoryLines 
  JabberConference JabberPort
          JabberResource JabberServer LogFile LogLevel 
  LogStderr MyColor Nickname
  -       OneToOne Pane Password ProxyHost ProxyPort 
  ProxyUsername SavePW
  +       OneToOne Pane ProxyPassword Password ProxyHost 
  ProxyPort ProxyUsername SaveProxyPW SavePW
          ServerLogging Style Theme Transparency UseBabelfish 
  UseJabberSSL
          UseProxy Username Visibility,*
       }
  @@ -4298,6 +4303,9 @@
       if { !$Options(SavePW) } {
          unset -nocomplain tmp(Password)
       }
  +    if { !$Options(SaveProxyPW) } {
  +       unset -nocomplain tmp(ProxyPassword)
  +    }

       # Save original Nickname
       if { [info exists ::tkjabber::baseNick] } {
  @@ -5145,6 +5153,7 @@
          ProxyPort               ""
          ProxyUsername           ""
          SavePW                  0
  +       SaveProxyPW                     0
          ServerLogging           all
          Style                   any
          Theme                   ""


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

  This is intentional - partly to avoid storing your network password in a plaintext file and partly to avoid having your account locked because of tkchat retrying too many times after a password change.


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

  Yes, it should be [info level 0].
  And yes, throwing an error for 
      ::json::write::indented 1 1
  is the correct thing, because only a single argument is allowed.

  Note that [info level 0] returns not just the arguments, but the command name itself as well.
  Fixed in CVS head.
  Bumped to version 1.0.1.


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

  thanks for pointing out my mistake. I fixed this problem in
  removeComments and also in removeExif


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=757679

  Please increase the version number of the package after this
  change.

  If package would have version 0.3, scripts which need
  working removeComments/removeExif may

  package require jpeg 0.3

  and fail immediately if user have buggy version of package
  instead of destroying user images.

  It is that very kind of changes which should be reflected in
  the minor version number, because it is even more than new
  functionality added - functionality which was destructive
  for user data, became useful.


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

  Added the "package require" statements. I noticed that the chemical structure example needs fixing though.


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

  Tcllib 1.9 ... Can you try Tcllib 1.10, or even the CVS head, fileutil 1.13.3 ?

  If the problem is still there please attach a script which creates a directory hierarchy which with it is possible to demo the problem.

  The traverser has code to avoid following circular symlinks, however the symlinks themselves should appear in the output.

  Note that we also have 'fileutil::traverse' which might be different, or not. It would be interesting to know, for comparison.


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

  Further analysis shows that the [glob] used in GLOBF and GLOBD for tcl8.5 doesn't return a reference to a symlink which has a non-existent target.

  Thus, it's impossible to use fileutil::find to locate and resolve such symlinks (which is what I was trying to do :)

  I'm not sure if this is a bug or not, anymore.  It's unexpected though.


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

  On further reflection, it's clear that [glob -type XXX] can't return a broken symlink no matter what XXX is, unless it's 'l' for link, because after all it can't determine the type of a loose link.

  It may be worth noting in the docs that such links won't be returned by find.


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

  OTOH, it should be possible to ask for '-types l' and then filter out those which are file/dir and thus not dangling, leaving us with dangling symlinks we can add to the result. We have 'file type' for an easy check.

  I think I will add a testcase first, if we don't have it already.


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

  Changed sak, reverted changes to package provide.
  Comitted to CVS head.


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

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


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

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


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

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


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

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


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

  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: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 260432: patch.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

  I am attaching a patch and a tcltest to fix this issue.
  File Added: patch.diffs


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

  Patch accepted and applied to head. comm version bumped to 4.5.7.


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. I have started looking into this.

  Can you give me the exact unicode code point you used for theweird chars, i.e. in \uXXXX notation, where XXXX is a 4-digit hex-value ?

  They don't seem to have survived the copying out of the bug report. (Which is another reason we ask that such things (scripts, input files, result files), are attached to the report, the chances of getting it back unmangled are significantly better.

  Running with Tcl 8.5.7 I also get an error back for the last example, however the location is two characters further in (12 instead of 10), and a different set of symbols is expected. Alternatively this might be because I used the PEG interpreter instead of converting the PEG into a hardwired snit-based parser.

  I will now compare to a snit parser and also try to thin the PEG, i.e. remove parts not needed for the example. As part of figuring my way through it.


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

  Ok. It was me misunderstanding the quoting rules of Tcl for a moment.
  Look at the following 4 commands, and their output (after running), and you should be able to see the problem and fix:

  (1)    #puts {Structure='}'}
  (2)    puts {Structure='{}'}
  (3)    puts {Structure='\}'}
  (4)    puts {Structure='\{\}'}
  (5)    puts "Structure='\}'"

  The first one you already know, and I explained why it is wrong. The second one fixes the issue, by balancing the nested braces. If that always happens in your case you are now fine. If you allow for unbalanced braces I said to use (3) in my post to comp.lang.tcl. I was wrong. The \ before } protects the Tcl parser from miscounting, true.

  What I thought was that it would also collapse the \} sequence into a single } internally. It doesn't, and re-reading rule [6] the Tcl interpreter is right, and me wrong.

  So your parser sees \} and that is a bad backslash sequence per your grammar, and so it bails out with an error.

  Item (4) in the list is the same as (3).
  Item (5) shows the proper quoting. Use "...", and the \} is indeed collapsed into a single }, which your parser then accepts. "..." quoting does backslash substitution. {...} doesn't. My fault.

  Note that all of this applies _only_ to the parsing of examples you specify directly in Tcl code. If you read your input from a file into a Tcl variable then all this quoting of braces is not necessary at all.

  Final conclusions:
  * ParseTools work correctly.
  * Your parser works.
  * My advice on comp.lang.tcl was faulty. And later in the evening I will post a correction there as well.

  Closing this no as 'invalid' == 'no bug' (except in my brain).


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted, and committed to CVS head.

  However, please provide me with a small script demonstrating the before/after behaviour, so that I can extend the testsuite

  Side note: In the future, please provide patches in the 'uified diff' format (generated by 'diff -u'). This easier to read, and easier to apply.


login: cnassau
username: cnassau
mimetype: text/plain
icomment:
  Here is a test that verifies that the base64-encoded "message/*" is parsed. Previously that code raised an error.

  test mime-12.0 {Bug 3483716} {
      set token [mime::initialize -string {Content-Type: message/delivery-status; name="deliverystatus.txt"
  Content-Disposition: attachment; filename="deliverystatus.txt"; size=138;
  creation-date="Thu, 02 Feb 2012 13:50:05 GMT";
  modification-date="Thu, 02 Feb 2012 13:50:05 GMT"
  Content-Description: deliverystatus.txt
  Content-Transfer-Encoding: base64

  T3JpZ2luYWwtUmVjaXBpZW50OiA8L2ZheD1ibHViYkBndW1taS5ib290PgpBY3Rpb246IGZhaWxl
  ZApEaWFnbm9zdGljLUNvZGU6IHNtdHA7IDU1MCAjNS4xLjAgQWRkcmVzcyByZWplY3RlZC4KUmVt
  b3RlLU1UQTogNTMuMjQuMjgyLjE1MA==
  }]
      set parts [mime::getproperty $token parts]
      mime::getheader [lindex $parts end] Remote-MTA
  } 53.24.282.150

  Side note: I believe the test message does not follow the respective RFC 1894 because that states that 7bit encoding "MUST" be used for message/delivery-status types. The base64-encoded version that broke the previous package was observed in the wild, however, so it seems wise to accept it noentheless.  


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you very much. The test has been added now. Confirmed that with your patch disabled an error is thrown, and with it the data is properly decoded.

  I agree regarding the reasoning about accepting the base64 encoded form.


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

  jlib is a jabber library depending on TclXML...

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


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

  Where is the source for jlib?

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

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

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


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

  jlib is part of coccinella.

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

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

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

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

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

  Re-assigning to pascal about that.


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

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


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

  Good or bad is of course a matter of taste.

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

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

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

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

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


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

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

  I'll have to think more about this.


login: 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:
  File Added - 11352: 465210.diff

  Logged In: YES 
  user_id=75003

  Enclosed the patch containing the full fix.


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

  See also "[ 1563137 ] NList fails for files with spaces".
  This report contains a fix as well.
  The fix was applied and committed.


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

  oh damn, forgot to experiment a bit, found just add a .0 to
  the end to make it work with decimals.

  please delete this feature request, sorry to waste your
  time. feel free to slap me about with a trout :/


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

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

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


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

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

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


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

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

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


login: 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: 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: arjenmarkus
mimetype: text/plain
icomment:
  I have applied the patch that was provided and written a small test program. This worked as intended.


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

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

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


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

  I have implemented logging to a file with an entry in the
  Options dialog to specify the file name. The filename is
  saved along with the other options and will be reopened for
  appending upon restarting tkchat.

  I think the logging to a window is handled by the show
  console menu item. At least this deals with it for Window
  platform.

  Yes, andreas - I have used tcllib log to accommodate levels.
  option menu is on the dialog too.


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

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

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

  Comments?


mimetype: text/plain
icomment:
  there are 3 adendums i made regarding to key generation, kay parse and key convert2pem
  how should i submit them?


mimetype: text/plain
icomment:
  following the bug ID: 3439693, looks like replacing ::asn::asnPrintableString to ::asn::asnString in ::pki::x509::_list_to_dn solves the problem too.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed in cvs by hard-coding a 0 padx value.
  I don't know why this happens but anyway, why are the other values hard-coded here?


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

  Fixed, now reporting the actual name of the missing variable, not the name used internally.


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

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


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

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

  modules/math/linalg.test

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

  Both smtp and mime package come from Marshall T. Rose and he
  developement this way, i.e. in the same directory. They also
  depend on each other.

  As about the category list, I guess it was forgotten to
  extend this.


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

  Ok, I now know why smtp is not part of the list of packages
  in the full package index: It is a consequence that mime and
  smtp are in the same directory. The main Makefile.in in
  just  assumes that the list of directories below modules is
  equal to the list of packages in tcllib.

  For now I madee a patch which adds smtp explicitly to the
  list of packages to list in the main package index.


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

  See patch #411422.
  Also added categories for the missing and new packages in
  tcllib.


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

  Fixed, v0.2 of pluginmgr committed to head. Cause was bogus space between a * and its backslash, i.e. the code read '\ *' instead of '\*'. This prevented the conversion of the * into (.*), so the resulting RE pattern had no capturing parentheses, and so the 'plugin' variable was not set to the plugin name part of the package name, but left empty.


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

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

  Patch for this is https://sourceforge.net/tracker/?func=detail&atid=312883&aid=1693491&group_id=12883
  Was accepted.


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193325: ntlm.patch

  Logged In: YES 
  user_id=1463011

  Attached patch allows me to successfully bypass our
  corperate proxy server. Via: 1.1 hostname (NetCache
  NetApp/6.0.2P2D2)


login: mpc_janssen
username: mpc_janssen
mimetype: text/plain
icomment:
  File Added - 193343: ntlm.test.patch

  Logged In: YES 
  user_id=1463011

  Test SASL-NTLM-1.1 now fails because of additional changes
  in the way of including the flags and session keys fields in
  the type-3 message.
  Attached a patch on the ntml.test file. 


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

  Applied patches plus a little reconfiguring. Tests ok on my
  unicode using systems.


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

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

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

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

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

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


login: vbwagner
username: vbwagner
mimetype: text/plain
icomment:
  File Added - 213235: asn.tcl.diff

  Logged In: YES 
  user_id=757679
  Originator: YES

  File Added: asn.tcl.diff


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

  Agreed, that there is a problem with too strict checks in some places, there is also a RFE talking about a similar issue. I'll give it a bit more thought, as there are other issues like decoding CHOICE and SET structures, which is currently quite cumbersome, which would also need relaxed tag type checking and tag introspection to select the correct decoding (similar to the current string decoder).


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

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

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


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

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


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

  Confirmed. Fixed. Committed to the head. Now 'struct::list 1.6.2'. Thanks.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10222: namespace.cdiff

  Logged In: YES 
  user_id=81875

  Hmm ... this has happened second time that no patch file was
  uploaded. I guess it has to do with some bug in netscape
  browser.
  Hopefully it will upload this time.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10224: namespace.cdiff

  Logged In: YES 
  user_id=81875

  I just realized that my earlier patch had some unwanted
  changes for profiler.n file. So, I am re-submitting the
  patch after deleting that part.


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

  Looks good to me too, but I'm gonna leave acceptance up
  to each maintainer.  Assigning to the first package.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Deleted - 10222: 

  Logged In: YES 
  user_id=75003

  We currently have here no exact maintainer structure as the 
  one for Tcl itself. Taking the item.


login: haneef
username: haneef
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=109670

  I am not sure what has happened but I thought I had a few 
  comments when I submitted the patch. In any case, the 
  submitted patch contains enahncements to the tabbed 
  notebook widget such that the tabs now support a bevel. The 
  patch also includes the doc changes, change to the demo.

  If there is something wrong with the patch please let me 
  know. My registered email address with SF was broken. It 
  should be fixed now.

  Regards,
  Haneef


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

  Extended testsuite, problem confirmed.
  lassign is unfortunately Tcl 8.5+ and this package is Tcl 8.2+.
  Going with direct check for empty input.
  Extended testsuite passes.
  Committed: https://core.tcl.tk/tcllib/info/0a9faf2cbe
  Pushed.
  Version 1.2.1 of package 'ip'.
  Thank you.


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 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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  The current implementation has the advantage of looping over the list of values
  only once and it could be made to _update_ the current statistics. 

  You are right though, that the computation is not robust against such relatively 
  small variations. I am not sure compensated summation is of any help here, but
  what is easy to do is: add the difference between each number and the first one.
  If all numbers are close, then that will have the same effect as first calculating
  the mean, and adding the difference from the mean. If they are not all close, there
  will be enough difference for the summation to yield a sensible number.

  Both methods are worth looking into ....


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

  Implemented a more stable version: subtract the first value from each value and compute
  the variance from that modified series. The result is the same, but the numbers that are
  squared show more relative variation.


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

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

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

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

      4.  Examples

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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12769: 472009_mime.diff

  Logged In: YES 
  user_id=75003

  The following patch should fix this bug and also #477088


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The newly attached file is an extended testsuite where I tried to reproduce the reported problem. See the test cases 3.0 to 3.2 at the bottom.

  Sadly these tests all pass (*), so I was not successful.
  Is it possible for you to attach a script which reproduces the issue exactly ?
  That way I can not only see the problem you have, but also have a piece of code ready to become a test case.

  ~~~~~~~~~~~~~~~~~~~~
  (*) I used Tcl 8.5 head (8.5.11+), and Tcl 8.6 head (8.6b2+) from the core source repository.


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

  Fixed the message used for SNTP - as TIME servers don't care
  what message they get we will send the SNTP request to TIME
  servers too.

  The module is for network time protocols (hence the
  directory name) and the first one implemented was for the
  TIME (RFC 868) protocol. It turns out that there are
  insignificant differences between the implementation for
  TIME and for SNTP (RFC 2030) so I left the package as 'time'
  and just added a 'getsntp' api.

  I don't see any good reason to restrict the SNTP usage to
  UDP - but I have added comments into the man page to point
  out the likely requirement for UDP. In theory SNTP could be
  operated over TCP and I note that the services file reserves
  port 123/tcp and 123/udp for ntp.

  Added support for ceptcl in addition to tcludp for UDP support.
  I've checked the new implementation against ntp2a.mcc.ac.uk
  and ntp.blueyonder.co.uk for SNTP access along with a local
  server running OpenBSDs minimal NTP server.


login: 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: quantifier
username: quantifier
mimetype: text/plain
icomment:
  Additionally, if there should protection from overlong forms, the second one could say:
  {%([CDcd][A-Fa-f2-9]|[Dd][01])%([89ABab][A-Fa-f0-9])}


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Quantifier, do you have test cases which demonstrate which characters the original regexes are not covering, and test cases demonstrating which illegal sequences are accepted ?

  If yes, please attach here.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Tried the changes and they pass the existing test suite, so we should not be worse off than we were before. Put them into the repository, on a branch --> "bug-3601995-ncgi". The moment we have test cases it should be ready for merging.


login: quantifier
username: quantifier
mimetype: text/plain
icomment:
  Correct utf-8 characters that are not accepted by original regexps, are any sequences that have continuation byte in range 0x80-0x9F:
  % http::formatQuery ą ;# a with ogonek, \u0105
  %C4%85
  % ncgi::decode %C4%85
  %C4%85
  % http::formatQuery † ;# dagger, \u2020
  %E2%80%A0
  % ncgi::decode %E2%80%A0
  %E2%80%A0
  %http::formatQuery \u2810 ;# a braille pattern
  %E2%A0%90
  %ncgi::decode %E2%A0%90 ;# accepted as two-byte sequence, third byte left hanging
  â %90

  Legal sequence that are erroneously accepted as utf-8 character can be for example two consecutive characters (regexp converts 'ó' and half of 'ę', leaving naked continuation byte):
  % http::formatQuery óę ;# o with acute, e with ogonek, \u00F3\u0119
  %C3%B3%C4%99
  % ncgi::decode %C3%B3%C4%99
  óÄ%99

  Illegal sequence accepted could be three-byte with last byte missing:
  % http::formatQuery Ⱡ
  %E2%B1%A0
  % ncgi::decode %E2%B1 ;# not a two byte sequence, but accepted as one.
  â±


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

  Test cases made, and verified that they fail before the change, and pass after.
  Commit [b6632970f6] @ bug-3601995-ncgi branch.
  Commit [66adc26a8b] @ tcllib-1-15-rc (merged to release work).
  bug-3601995-ncgi branch closed.


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

  Nuts. Fixed the fault. Should really ensure that both critcl
  and non-critcl paths are tested with windows.


login: stwo
username: stwo
mimetype: text/plain
icomment:
  That information should be in the documentation, I guess.
  I found them like this:
  $ cd /dir/which/contains/tklib
  $ ./sak.tcl doc validate


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Which commands are these ?
  I replaced [nl] today with [para].

  Revision [6205def19e5f9a12f1ea7e896d578ae695efb6aa].
  Pushed.

  If these were all we can close as fixed.
  This is also in the newly made tklib-0-6-rc branch.


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

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


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

  Done. However only for the schemes which are actually known
  to the uri::split command.


login: jxmercog
username: jxmercog
mimetype: text/plain
icomment:
  One additional comment.  We had an unpatched version of 1.8 tcllib mime.tcl, so we were still using the %e but it appears Novell Groupwise did not accept future dates. We never noticed them until we just recently migrated over to Exchange server. 


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

  Found revision 1.49 fixed it. Just didn't implement it properly.  To much cold medicine not enough sleep.


login: tomk
username: tomk
mimetype: text/plain
icomment:
  It was suggested to me that I submit the files using the SF patch feature but I now see that "Feature Request" also accepts files so that would have been a better place for this communication. If an administrator can convert this to a feature, great, otherwise sorry of the noise on this channel.
  tomk


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  data_type - 312883

  Hi Tom,
  I have shortly tested your extension and it looked useful to me.
  My personal comments:
  - Well documented
  - I would not call it menubar_new - choose another name
  - many issues in the module are of more general interest like
    callbacks with namespaces etc.
    Is it intelligent, to put this into a menu-only module ?
  - IMHO there will not be a sponsor for a new module because someone have to
    maintain it.
    To not loose potential good work, I suggest to
    - coordinate with one of the TkLib guys (Jeff? Andreas?) if it is senseful to include it, if it is ok in this form etc.
    - get a tcllib maintainer and include and maintain it on your own.

  I have changed the tracker to "Patches" and the category to "tklib".
  In addition, I have assigned it to Andreas.
  Andreas seams to be heavily active and busy with the TclLib release.
  Nevertheless, this seamed to me the most appropriate.

  Thank you,
  Harald


login: tomk
username: tomk
mimetype: text/plain
icomment:
  Harald,
  Thanks for your comments. I asked Andreas to add me as a developer and I will maintain the code. I'm not sure I understand your comment about menubar_new? If you are talking about the creation of a menubar instance then I believe the command new is required by the TclOO implementation and is out of my control.
  tomk


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Tom,
  sorry, while scanning the documentation, I thought the package implements a command "menubutton_new". Propably this was a missread.


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

  I have added a 'menubar' package to the tklib/modules directory at SF. The demo.tcl file can be run with wish to test the code. Please review the code and let me know if anything need to be changed/cleaned-up in order for this package to be included in the next release.
  tomk


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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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


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

  Added option to left justify the label.
  I'm not so sure about adding an option -- I can't really see the utility of centering the text.


login: 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: mic42
username: mic42
mimetype: text/plain
icomment:
  data_type - 112883

  Logged In: YES 
  user_id=302287
  Originator: NO

  Its there. Its just missing in the docs..., so this is really a documentation bug

  Try:

  asn::asnNull

  Michael


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

  This is actually already fixed in the CVS. The application
  manpages are installed in the same location as the package
  manpages.


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

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

  Does the same thing happen in the "counter" module ?
  (One of the two modules supercedes the other, the other
  is deprecated. Brent knows which is which).


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

  Note: stats is definitely deprecated. Please try the 
  counter module and see if it contains the same problem.


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

  The documentation is also out of date, also
  reporting on 1.0 instead of 1.2.


login: aldobu
username: aldobu
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=979524

  Just to push for a quick bug-fixing,
  I suggest an alternative solution:

  # change line 1836  (tree.tcl  v.1.52)
  # from
   set data(dnd,afterid) [after 200 [list Tree::_scroll 
  $path $scroll]]
  # to
   set data(dnd,afterid) [after 200 Tree::_scroll $path 
  $scroll]

  ** Tested with Tcl 8.4.12 **


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

  Bug still present in csv head (1.8 got rolled out, with it).
  The 'quick fix' by aldobu has the problem, that it will fail
  for widget pathes with spaces in it (though, widget names
  with spaces in it aren't best practice and will probably
  break BWidget at other places also). The fix in the original
  bug report looks OK. 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  While this is certainly a bug in ncgi::nvlist the Tcl "bug" is no such.
  Fix committed to CVS Head. 
  Package version bumped to 1.3.3.


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

  How does this sound instead:

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


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

  A few questions, if you don't mind.

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

  What happens if the argument provided doesn't exist?

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


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

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

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

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

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


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

  Well, it seems as if the exact fomrat of the stack trace changed in 8.6.
  The 'if ...' command seems to have been removed from it.
  This should require only updating of the testsuite.
  Very low priority.
  May be defered until at least 8.6b1 is out, i.e. when things are less in flux.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Recent work on struct::tree and its testsuite may have fixed this.

  See ChangeLog entry:


  2008-09-02  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * tree.testsuite: Updated tests based on walk error stack traces
    to handle new differences between 8.4 and 8.5.

  * tree.testsuite.4417b84.txt: Moved the stacktraces to separate files
  * tree.testsuite.4417=84tcl.txt: for better readability of both the
  * tree.testsuite.4417a84tcl.txt: traces and the test using it.
  * tree.testsuite.4417a83critcl.txt:

  Please recheck. If it is not fixed it should however now be easy to add the proper stacktrace, now that the various forms are stored in their own files.


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

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


login: 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: 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: kchansen
username: kchansen
mimetype: text/plain
icomment:
  Posted this as potential bug to TCL sourceforge:

  ID:
  #2848176
  Link:
  https://sourceforge.net/tracker/?func=detail&aid=2848176&group_id=10894&atid=110894

  Response is that since V8.2 this is designed behavior.

  CRC Tcl implementations need to be rewritten to behave correctly with new wide support.

  If no one has the time let me know and I'll submit a proposed fix.

  I elevated the priority to 9 because the current code generates incorrect 32-bit results with the Tcl implementations.


login: kchansen
username: kchansen
mimetype: text/plain
icomment:
  Believe this can be fixed by simply changing the initial value for "v" when originally computing signmask from "1" to "-1":

  Change from:
          for {set v 1} {int($v) != 0} {set signbit $v; set v [expr {$v<<1}]} {}

  To:
          for {set v -1} {int($v) != 0} {set signbit $v; set v [expr {$v<<1}]} {}

  This guarantees that signmask will always be negative and that "~signmask" will always be a non-negative low-order bitmask.


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

  We have to wrap the read script into an 'uplevel #0' to simulate the -global option of invokehidden.
  Fixed, is in CVS, tie::file version 1.0.3.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  This is wrong usage. Please try:

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


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

  I concur, that is a var name typo. Fixed in CVS head.
  Side note: modules/pt is the successor to the grammar_peg and grammar_me modules.


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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Already fixed by Andreas Kupries on Oct 26 2010:
  http://tcllib.cvs.sourceforge.net/viewvc/tcllib/tcllib/modules/http/autoproxy.man?r1=1.10&r2=1.11


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

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


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

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

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


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

  Logged In: YES 
  user_id=75003

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


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

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


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

  Logged In: YES 
  user_id=75003

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


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

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


login: kakaroto
username: kakaroto
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=686750
  Originator: NO

  oups.. submitted as nobody. should be submitted as 'kakaroto'. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hello KaKaRoTo,

  thank you for the report.
  I have tried to emulate the situation with the following script.
  Unfortunately, I could not reproduce the situation.
  May you:
  - check if the issue is still there with the current implementation
  - provide a demo script.

  Thank you,
  Harald

  #-- Test script ---
  wm geometry . 500x500
  pack [ScrolledWindow .w -bg red] -fill both -expand true
  ScrollableFrame .w.f -constrainedwidth 1 -bg green -height 500 -width 500
  .w setwidget .w.f
  set f [.w.f getframe]
  pack [frame $f.f -bg yellow -width 100 -height 100]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  By direct mail, KaKaRoTo provided the following test script:

  Anyways, the latest release is from 2006 and is 1.8.0 which is the same that we have in aMSN.. I just tried again to reproduce it (removing our workaround) and the issue is still there.. I wrote a small test program to reproduce it :
  #!/usr/bin/wish
  package require BWidget
  wm geometry . 500x500
  ScrolledWindow .sw
  ScrollableFrame .sw.sf -constrainedwidth 1
  .sw setwidget .sw.sf
  pack .sw -anchor n -side top -expand true -fill both
  set frm [.sw.sf getframe]
  canvas $frm.c -width 100 -height 100 -bg white
  pack $frm.c -expand false  
  All you have to do is *slowly* resize the window to a smaller size and you'll see the scrollbar appearing..If you only resize the height (without modifying the width), then the scrollbar will become smaller and you can move it.. as soon as you click on it, it will disappear...
  If you add these lines to the end of the script, the issue will disappear :
  proc ::ScrollableFrame::_frameConfigure {canvas frame width height} {
     $canvas:cmd configure -scrollregion [$canvas:cmd bbox all]
  }
  I hope this was helpful and I hope you can fix it upstream soon!
  Thank you,
  KaKaRoTo

  I have checked it:
  - Release 1.8.0: issue is there
  - current cvs: issue is not there (I don't know why but I don't bother
  at the moment).

  So if you allow, I will close the ticket without modifications on the current code.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Looking this over it seems that this is caused by the latest changes to the semantics of lassign/lrepeat in 8.6 ... TIP 323 (Do Nothing Gracefully) - http://tip.tcl.tk/323

  Background: Tcllib provides its own implementations if and only if the commands are not provided by the core. This means that for 8.5 and 8.6 these test check the behaviour of the core command, and not Tcllib's implementation.

  A question is, should Tcllib's implementation follow 8.6's lead ?
  Right now we have Tcllib code behaving identical for 8.4/8.5, but not 8.6
  If we follow 8.6's lead it would behave identical for 8.4/8.6, but not 8.5.

  IMHO we should stay with 8.5 behaviour. That way transition is easier. If you use 8.6isms do not expect it to work for 8.5 or 8.4+tcllib.

  So, the main alternative would be to disable these tests for 8.6, knowing that they test the core command and not Tcllib. With that reasoning disabling testing for 8.5 might make sense as well, despite currently behaving identical.


login: cbascom
username: cbascom
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1600284
  Originator: YES

  The above description did indeed fix the out of scope variables issue, but I hadn't realized until now that the event hooks were getting evaluated twice.  The first time they are evaluated is inside the if/else clause that checks to see whether another interpreter is in use or not.  In this case, the uplevel 1 was used when evaluating in the current interpreter so variables were indeed in scope.  The same event hook is then evaluated a second time by the eval command just below that if/else clause and at that point the variables are out of scope.  I believe the fix is simply to remove that eval.


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

  This is fixed in the CVS. See the ChangeLog, entry below.

  2006-11-29  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * comm.tcl (commRunHook): Fixed double execution of the hook
    script. Thanks to Will Duquette for the report.


login: flatworm
username: flatworm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1350198
  Originator: YES

  After reading bug 1178045 I fear I might overuse conversion to LDAPString in my code. Let me check and re-upload the fixed patch.


login: flatworm
username: flatworm
mimetype: text/plain
icomment:
  File Added - 284706: ldap.diff

  Logged In: YES 
  user_id=1350198
  Originator: YES

  Attached an updated patch with the logic regarding encoding of attribute descriptions and assertion values made more consistent on the source level.

  Also added more tests, comments made more clear and some procs renamed to better mirror their purpose.
  File Added: ldap.diff


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

  Accepted the patch with some minor changes to the test suit organisation.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I confirm this bug.

  Patch:
  entry.tcl Line 266:
  Original:
      if {[string equal $cmd "configure"] || [string equal $cmd "cget"]} {
  New:
      if {[string equal $cmd "configure"] || [string equal $cmd "cget"] || [string equal $cmd "invoke"]} {

  (this is not a standard option in tcl8.5 and thus must be treated by the BWidget mechanism)

  Thank you,
  Harald


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

  Yes. The uuid::uuid command gives the interactive interface. So [uuid::uuid generate] produces a nice string suitable for human eyes. The internal command [uiuid::generate] is the programming api and returns the raw binary version. This is to avoid people dehexing the hexified version when they want to reformat it or check it or whatever.


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

  Accepted and committed the patch. I also added an "unset v"
  statement after the loop, as the variable is not really
  needed after the initialization.


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

  I have a case where my filesystem is local, there are no symlinks, and I also get invalid results. I am uploading a ksh that creates a directory subtree that models the above description, then runs the tcl script (in my environment, it uses the latest tcllib and tcl). The resulting tar file will also be uploaded.


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

  hmm - guess not - stupid web app won't let me upload here!

  Here's the text of the script:
  #! /bin/ksh

  mkdir /tmp/tartest
  cd /tmp/tartest
  cat >tartest.tcl <<EOF
  #!/projects/sprs_lwv/tcl85/bin/tclsh
  package require tar
  ::tar::create tarball.tar devdir_4.1
  EOF

  chmod 755 tartest.tcl

  mkdir -p devdir_4.1/subdir1 devdir_4.1/subdir2
  for j in subdir1 subdir2 ; do
    cd /tmp/tartest/devdir_4.1/$j
    mkdir -p exec/bin export server/bin lib
    for i in exec/bin export server/bin lib ; do
          touch $i/file1 $i/file2 $i/file3
    done
  done

  cd /tmp/tartest
  ls -lR /tmp/tartest/devdir_4.1 > ls.output

  /tmp/tartest/tartest.tcl
  ls -l tarball.tar
  gtar tf tarball.tar | sort > tar.tcl.output

  and here's what I see in terms of output:

  cat ls.output

  /tmp/tartest/devdir_4.1:
  total 32
  drwxr-xr-x   6 lwv27    dept27       364 Feb  8 08:04 subdir1
  drwxr-xr-x   6 lwv27    dept27       364 Feb  8 08:04 subdir2

  /tmp/tartest/devdir_4.1/subdir1:
  total 64
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 exec
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 export
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 lib
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 server

  /tmp/tartest/devdir_4.1/subdir1/exec:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir1/exec/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/export:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/lib:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir1/server:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir1/server/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2:
  total 64
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 exec
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 export
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 lib
  drwxr-xr-x   3 lwv27    dept27       177 Feb  8 08:04 server

  /tmp/tartest/devdir_4.1/subdir2/exec:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir2/exec/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/export:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/lib:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  /tmp/tartest/devdir_4.1/subdir2/server:
  total 16
  drwxr-xr-x   2 lwv27    dept27       303 Feb  8 08:04 bin

  /tmp/tartest/devdir_4.1/subdir2/server/bin:
  total 0
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file1
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file2
  -rw-r--r--   1 lwv27    dept27         0 Feb  8 08:04 file3

  and here's the output from the tar file:

  devdir_4.1/subdir1/exec/bin/file1
  devdir_4.1/subdir1/exec/bin/file3
  devdir_4.1/subdir1/export
  devdir_4.1/subdir1/export/file3
  devdir_4.1/subdir1/lib
  devdir_4.1/subdir1/lib/file1
  devdir_4.1/subdir1/lib/file2
  devdir_4.1/subdir1/lib/file3
  devdir_4.1/subdir1/server
  devdir_4.1/subdir1/server/bin/file1
  devdir_4.1/subdir1/server/bin/file3
  devdir_4.1/subdir2
  devdir_4.1/subdir2/exec/bin/file1
  devdir_4.1/subdir2/exec/bin/file3
  devdir_4.1/subdir2/export
  devdir_4.1/subdir2/export/file1
  devdir_4.1/subdir2/export/file3
  devdir_4.1/subdir2/lib
  devdir_4.1/subdir2/lib/file1
  devdir_4.1/subdir2/lib/file2
  devdir_4.1/subdir2/lib/file3
  devdir_4.1/subdir2/server
  devdir_4.1/subdir2/server/bin/file1
  devdir_4.1/subdir2/server/bin/file3

  Notice that file2 is missing in nearly every directory in which it resides. Also note that file1 is missing from export directory.


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

  Would it make sense to use 'fileutil::find' instead of re-implementing directory traversal in 'tar' ?
  The skipping of links (-dereference 0) can be implement via the 'filter command' callback of 'find'.


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

  This seems to have been fixed by Aaron on Feb 8 if I read the ChangeLog right. Can we please get feedback that that fix is working for the submitter ?


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

  Using the latest tcllib, today, Feb 12th, the discrepancies that I saw between files included has been resolved.


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

  submitter has confirmed previously commited changes have fixed the issue.


login: 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: bugant
username: bugant
mimetype: text/plain
icomment:
  File Deleted - 201918: 



  File Added - 202048: ftp.tcl.patch

  Logged In: YES 
  user_id=1391120

  Andreas Kupries suggested to change the -hylafax
  option to a more generic -temp. This is a good idea.
  The patch attached do this (I'm removing the previous one).


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

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

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


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

  One possible fix: Add '-disabledforeground' to the tkinclude
  'remove' list
  in entry.tcl:

      Widget::tkinclude Entry entry :cmd \
              remove [list -state -cursor -foreground
  -textvariable -disabledforeground]

  This avoids the problem under Tk 8.4, and is a no-op under
  earlier Tk versions.

  Probably not an ideal fix -- does anyone have any better
  ideas?

  Is it OK if I commit this change?


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2460

  jenglish asked
  > Probably not an ideal fix -- does anyone have any better
  > ideas?

  Not necessarily better, but I submitted a patch last year
  that fixes the problem. 

  See [ #402776 ] BWidget: support for Tk8.4 entry -state.


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


  Re: patch [ #402776 ] BWidget: support for Tk8.4 entry
  -state --

  am taking a closer look.  One issue: it changes the
  behaviour of the '-disabled'
  state (a -disabled  BWidget::Entry can be programmatically
  modified, 
  whereas a -disabled Tk::entry cannot; I've backed that part
  of the patch out.)


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

  OK, this has been fixed now.
  Files changed:
  entry.tcl : r1.14 -> r1.15
  Tested under Tk 8.3 and Tk 8.4


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

  Oops, didn't I close this when I committed the change?

  Thanks again for the patch!


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

  Oh, I will have to look into that - I do not remember the details of why I made this
  change. 


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

  Yes, the result of matmul_vm (the underlying routine for matmul for the multiplication
  of a row vector and a matrix) actually returned a column vector. 

  (The change from 1.0 to 1.0.1 was meant to solve the issue of row and column vectors,
  there is a natural distintion possible between them. I tried to keep some of the previous, 
  sloppy behaviour, while at the same time being more strict in this distinction. I solved
  the problem by transposing the result - this gives a correct row vector and therefore
  a correct answer with the rest of the computations)

  See the CVS repository (version now: 1.0.2)


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

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


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

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

  Michael


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

  to win :

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


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

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


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

  Fixed some bugs in the handling of the split and join for
  ftp and added some new tests to check the user info and path
  prefix  in future.

  The geturl issue is really a feature request for the ftp
  package so I shall post this as a request.


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

  Actually 'geturl' is FR for uri whose implementation should 
  make use of 'ftp'.


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:
  The valid YAML
      x: [ "a": "b", "c": "d" ]

  is mis-translated as          {x {a b c d}}
  It should be translated as {x {{a b} {c d}}
  I.e. the value x is mapped to is a sequence of pair-mappings, not a plain sequence.


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

  I see only one manpage reference, snitfaq. Agreed that this has to be fixed.
  All other uses I can find are in comments, and the ChangeLogs.
  Fixing the comments is of lesser priority.
  Still, when I come to snitfaq I can do them as well.
  I remember the places.
  I usually put them in when I have a 'eval/linsert etc. combo in the code and write in the comment the more readable 8.5 form.


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

  Fixed snitfaq manpage, and all uses inside of Tcl comments. Committed to CVS Head.


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

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

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


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

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


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

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


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

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


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

  The confusion is that the double-\ is in the output, right ?
  In the input I am likely needing the double-\ to prevent interpretation as continuation line.
  That is a doctools problem, in the generator for HTML output.


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

  Examples to check out

  [example {
      a \
      b
  }]

  [example {
      a \\
      b
  }]

  [example_begin]
      a \
      b
  [example_end]

  [example_begin]
      a \\
      b
  [example_end]


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

  I'm not bothered what the origin of the problem is; I'm bothered that the output is misleading users of the documentation. How you resolve it is your business. :-)


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

  Donal, not sure why you seem to think that I am bothered about something. I added the examples as a reminder to myself of the test cases I should use to investigate the problem, i.e. trace it through the layers of processing, and later for the test suite.


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

  I have partial code that does this. I'll see if i can beat
  it into usable shape. 


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

  Integrated with CVS head. some shuffling, utilities are in
  their own namespace, not "::logger".


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

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


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

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


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

  Patch applied in CVS, in asn 0.8.4. and some tests added.

  Sorry it took soo long (guess the copy of your patch in the pki module can go now).


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  while that change isn't incorrect, note that tcl allows its commands like info (and so forth) to be abbreviated at the point in the subcommand that it is unique.


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

  Excellent.  I had tested it out before reporting it and didn't notice any change.  That explains why.  thanks for the response!


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

  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

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

  Thanks. Committed the fix to the CVS head. Bumped package version to 2.0.7.


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

  Went with my idea and used 'format' to get results with a
  deterministic precision across all versions. Committed.


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

  Confirmed the inconsistency.
  I see the same doc error in the code itself.
  Now fixed in the CVS head.


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

  These br's are gone if you write [list_begin definitions compact].
  Not documented tough. And I do not remember why it was added.
  Ah ... ChangeLog:

  2002-04-01  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * Committed changes to list generation (better generation of
    whitespace for HTML, allowing hints). Only the HTML formatter
    currently acknowledges hints. This fixes SF Bug #535382.

  Link to that report:

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

  Do you have additional comments regarding this and the old report ? Is that something we could fix by using proper classes for list begin/end and items, so that a CSS can then influence the spacing instead ?


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

  Well, the br's have been yanked out, ditto the undocumented 'compact' hint. The argument is still accepted from manpages using it, but ignored. Any spacing has to be done through CSS now.


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

  Fixed: http://core.tcl.tk/tcllib/info/f42362cde9
  Version of struct::queue bumped to 1.4.5.
  Merged: http://core.tcl.tk/tcllib/info/97d8e58276
  Pushed.


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

  Something in just this test ... I am not sure about that. The test framework in sak uses Ctrl-M, aka CR, aka \r, aka 0x0D to move the cursor to the beginning of the current line without advancing a line, before printing the next line. To me it looks a bit like the terminal or other is gobbling this character, or transforming into linefeed (LF, \n).

  Well, I am running now on a solaris box too, will see if I can see the same problem. Setup is similar, xterm, Exceed server on WinXP. No gnome tough.


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

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


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

  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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Did you possibly mean 'Keywords should _not_ be always required' ?

  The error is indirect. In the multi-file modes (like when processing a directory) dtplite will generate TOC and INDEX pages, using doctoc and docidx formats. The docidx format doesn't allow an empty index, so, if no page has keywords this error is triggered. If even one of the pages to be processed has keywords nothing happens.

  If dtplite is ordered to process only a single page then neither TOC nor INDEX are made, so the problem cannot occur then either.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed in CVS head. doctools::idx now accepts an empty index (only index_begin and index_end keywords). dtplite will pick that up automatically when the new version of this package is installed.


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

  Followup: a thread on clt gave this workaround (I've put a
  feature request
  at the bottom):

  On Thu, 28 Jun 2001 09:17:19 GMT, Jos Decoster
  <decoster@retarget.com> wrote:   
  >The ListBox and Tree are drawn in a canvas. In the 1.2.1
  release, this canvas  
  >was create with the path-name you supplied. In the current
  CVS release, first a
  >frame is created with class ListBox or Tree (to better
  handle option database  
  >stuff) and in this frame a canvas is
  packed:                                   
  >[...]                                                                          
  >You could try to
  use:                                                          
  >                                                                               
  >       bind .t.c <ButtonPress-3>
  {foo}                                         
  >       bind .l.c <ButtonPress-3>
  {bar}                                         

  This works, put I'd prefer not to use BWidget internal
  naming schemes.
  So I'll request a new command for tree.tcl and listbox.tcl:

        .t getCanvas
        .l getCanvas

  like the 'getFrame' command from panedwindow.tcl.

  Salut,
          Bastien


login: norganos
username: norganos
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=418919

  perhaps bind them to .tree.c or .list.c, the canvas itself? 
  i just know, that i had something similar, that worked 
  after i binded it to the canvas...


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

  Its probably not a good idea to mask an error (and feeding junk into the decoder is clearly an error) by simply returning an empty string.  


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

  You have [catch] for dealing with errors raised. Garbage in should be considered an error. 


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

  Maybe this is naive, but why not just use the clock
  functions' '%b' format option, which outputs the abbreviated
  month name?


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

  This is already fixed in the CVS Head.

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

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

  * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

  * (parsedatetime): For month index, use "%m" +
  scan instead of wrong "%e".


login: ricardoj
username: ricardoj
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=388133

  Ok, sorry not to double check on CVS. :(

  The problem using %b, is that command is locale specific, so
  if your system is in english then you get the correct answer
  for the month, otherwise not !


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Tweaked the documentation as proposed.

  Note: For Prim's algorithm I only stated the range of complexities, but not the exact complexity of our implementation. The problem is, I do not exactly know where our implementation lives, complexity-wise. The main influence is likely the struct::prioqueue implementation, and I have no exact idea about its complexity. On quick glance it seems to maintain a sorted list, I do not believe that it is a binary heap, fibonacci heap, or other similar structure.


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

  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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Documentation updated on CVS.
  Thank you for reporting!

  Technically, it would not be a big issue to make -selectfill r/w but IMHO this is not very important.


login: wkechel
username: wkechel
mimetype: text/plain
icomment:
  Agreed, I also checked for it when looking for the reason why selectfill did not work, so I already added code to configure to handle it properly, but I decided as well that setting the options during creation is fine.


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

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


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

  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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hello valli, thank you for your report.

  Is it possible for you to attach a snippet of Tcl code which demonstrates the problem ?
  Right now I am not fully clear on what you are doing, making it it difficult to reproduce what you are seeing.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed and tested with:
   Widget::theme 1
   pack [Label .l -text ABC]
   .l configure -foreground yellow


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10420: tcllib.458011.diff

  Logged In: YES 
  user_id=75003

  Requirement of Tcl 8.2 is documented in the 'tree.n' 
  manpage. Added to requirement now to the code too.
  Documented limitations. Added verififcation.

  See enclosed patch.


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

  I wish I could set multiple resolution. This is out of date,
  and fixed in the CVS head. See also the items 

  https://sourceforge.net/tracker/index.php?func=detail&aid=1403452&group_id=12883&atid=112883
  https://sourceforge.net/tracker/index.php?func=detail&aid=1425947&group_id=12883&atid=112883

  Changelog:

  This is already fixed in the CVS Head.

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

  * mime.tcl: Applied patch by Benjamin Riefenstahl fixing
  bugs in his patch for [SF Tcllib Bug 1276561], see
  2005-10-04 entry.
    * (MONTHS_SHORT, MONTHS_LONG): Add a dummy entry at index 0.

    * (parsedatetime): For month index, use "%m" + scan
  instead of wrong "%e".


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

  Yes, AFAIK S3 depends on 'xsxp', which in turn depends on TclXML.
  The testsuite doesn't really check that.


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

  Previous version used to pad keys to 64 bits so the key because "SeCrEt\0\0"
  Added an improved error message for short keys.
  If using the old command options, enable key padding with nulls.
  Added test.


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

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

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


login: mic42
username: mic42
mimetype: text/plain
icomment:
  This could be an effect of TLS/Tcl bug.
   http://sourceforge.net/tracker/index.php?func=detail&aid=1945538&group_id=10894&atid=110894

  I'll look at the other suggestions.


login: zbynek-hubinka
username: zbynek-hubinka
mimetype: text/plain
icomment:
  This works quite well for me:

  Before line 627, which contains "vwait [namespace which -variable $handle](message,$messageId)" in ldap.tcl insert some timeout, e. g. "after 50" or so. It helps when the server is significantly delayed, doesn't matter why. Should be incorporated to next patchlevel of tcllib (the current version is 1.14 recently). 


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: tmmenezes
username: tmmenezes
mimetype: text/plain
icomment:
  The bug is located at:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF]\
                  $args]
  }

  and can be fixed by appending '--' at the end of all the options, and before $args:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF --]\
                  $args]
  }


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

  Typically tcl commands use "--" to indicate the end of option processing. If you always add this before the data parameter then you can avoid this problem in many commands that accept options (for instance, switch is best used as 'switch -exact -- $option { .... }').
  However, it is also quite simple to handle a final data parameter that happens to have a leading hyphen. This was fixed previously for crc32 and other tcllib functions. I've applied the same fix here. In the meantime - use '--'.


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

  I made a fix to the dialog module and also to the pop3
  testsuite. This is in the head. Can you check if your
  problem still happens ?

  Note: The fixes I made were because the tests pop3-2.8 and
  pop3-5.0 were failing consistently on Solaris. Not on Linux.
  I never saw pop3-6.1 failing on solaris. And my failures
  were not dependent on running the whole tcllib testsuite,
  pop3 alone was sufficient. So, there are quite few
  differences. I am however not excluding that it is the same
  problem, just appearing in different places due to different
  system speed.

  In previous incarnations of the testsuite driver it was
  possible that a testsuite coming before pop3 forgot to kill
  a timer and it fired during the later test, smashing
  something. However in the current setup each module is
  tested using a new sub-process. So it should not be possible
  to leak stuff between modules. The only thing I can think
  off is timing differences between pop3 alone vs the whole
  testsuite.


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

  I can't repro the failure
  today, so either your changes
  fixed it, or it's not a real
  reproducible bug in the first
  place.


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

  Hm. Making it low-priority then. If a repro comes good,
  otherwise closing in a month or so.


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

  Hm. In my setup I get errors for 'touch',
  but not for 'find'. The touch thing might
  be a linux issue.

  In which directory did you execute 'configure' and 
  then 'make test' ? I usually create a build directory
  outside of tcllib and configure and test from there.


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

  Ok, I get the same errors for find when I configure and 
  test from the top directory of tcllib. So the tests as 
  written are much to dependent on the actual contents of the 
  tcllib directory, thus thrown off by (m)any changes, like 
  new modules, examples, whatever.

  Oh, the touch errors are still there so my belief that this 
  is linux dependent is even stronger.


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:
  The cause of the change is, I suspect, a change in textutil:

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

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


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

  I guess your camera likes to record a MaxAperture of 0. fixed in version 0.3.2


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Thanks for reporting.

  I fixed the problem, at huddle-0.1.5 .
  I committed this at the tcllib repository.

  enjoy! :)


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

  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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  It is true, the current value is replaced by the value of the bwidget configuration value
  buttonwidth.
  So, one may use the correct option index:
  option add *MessageDlg.buttonwidth 10 100

  Unfortunately, this was not documented jet.
  (but is now in cvs)


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

  This is documented behaviour. The manpage for the smtp
  package says:

  * Note  that  the  header key/values supplied by
  * the -header option (not those present in the MIME
  * part) are consulted.

  This information is also present in the original XML/HTML
  documentation.

  Damit es keine Missverstaendnisse aufgrund von
  Uebersetzungschwierigkeiten gibt: Das als Fehler angemerkte
  Verhalten von 'smtp::sendmessage' ist das dokumentierte
  Verhalten. In der Manualseite zu SMTP steht

  * Beachten sie, dass die Funktion die Header-Daten
  * (Schluesselworte und zugeordnete Werte) aus den
  * mit der Option -header uebergebenen Informationen
  * entnimmt (und nicht aus den Informationen im
  * uebergebenen MIME-part).

  Diese Information befindet sich auch in der
  Original-Dokumentation, i.e. README.xml, README.html.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I am unable to confirm this. Using a self-build Tcl 8.5.11 with memory debugging (--enable-symbols=all) and the attached modified test script I see the current and maximum allocations rock solid at their values, without any increase.

  I tried this with pure-Tcl md5crypt, and md5crypt accelerated via tcllibc. The latter I ran to the full million, the former only to 1000 rounds, gives that it is much slower.

  Output after completions:
  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *
  1009:   m703050 834514^C

  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *       /home/aku/Projects/Tcllib/0.Releases/1.14/Base/modules/tcllibc/linux-x86_64/tcllibc.so Tcllibc
  999999: m683191 750032


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

  Thanks. Fix committed to CVS head. Version bumped to 0.3.1.


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: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Well, given that the other app in tklib is called 'bitmap-editor', I'd choose something like 'diagram-processor'.


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

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


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

  The culprits for this are logger.test 3.0 and 3.1.

  Those basically should test if the default logprocs are
  called, which print to stdout, but do not really do it.
  Should probably be rewritten with the newer tcltest -output
  option, to check whats printed to stdout.


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

  Confirmed.

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


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

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

  What are you after here? It already persists the user
  settings. Recent versions can log the chat but there is not
  much point (IMO) in reloading the old loggged chat.

  ??


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

  I believe it did not at the time I submitted this. Yes, I 
  believe I was after persistence of user preferences. We can 
  close this request.


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


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

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


login: 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: nemethi
username: nemethi
mimetype: text/plain
icomment:
  As reported by Helmut both in private mail and on c.l.t., the bug was in his code, not in Tablelist.  The widget .__helpLabel, created by Tablelist, was destroyed by his script.


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

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

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

  Thanks for the fix.


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

  The ugliness seems to be due to the wish interpreter
  invoked.  Using wish from /usr/bin/wish8.4 (OS X 10.4.7) I
  get the black background as per your screenshot.  However
  when I invoked wish from fink, the notebook's
  -activebackground seems to be set correctly.


login: 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: 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:
  The patch contains a number of other changes beyond what is described in this bug.
  Can you explain ? (Changes to binary scan, file handling, int/float differences).


login: a_kovalenko
username: a_kovalenko
mimetype: text/plain
icomment:
  Umm, sorry, almost all of them are safely ignored, many are redundant and many depends on newer Tcl than ico.tcl itself. Sorry again, I should have prepared a cleaner patch. 

  Float->int replacement doesn't alter semantics for icon dimensions that are multiples of 8. It was added during a vain attempt to track down the size calculation problem. The same can be said about [open] flags ("b" is redundant as soon as -encoding and -translation are set in a later code) and [binary scan] ("u" flag is more convenient than format %u and &0xFFFF, but, alas, it increases required Tcl version).

  The only thing making sense, of those other changes, is commenting out a check for [file exists] in writeIcon: ICO backend is able to create files from scratch, so the file doesn't _have_ to exist (I should report it as a separate bug and attach a separate patch, of course). 

  As of other changes, please drop them out.


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

  Ok. Done. Version is 1.0.5. See my attachment for the final patch I committed to CVS head. Please check that it works for you. If not, reopen the bug.


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

  Side note regarding Ns_Sls.html ... "Ns_Sls} - Socket local storage" shows me that there is a closing brace to many somewhere in the documentation sources.

  Regarding parentheses and argument types: When doctools was written it was with the intent of documenting Tcl commands. C functions were not on my mind and so are not really supported. You can document them, but a number of things have to be done manually, like adding parentheses around the whole set of arguments to a function, and adding type names to arguments. We currently do not have any markup commands to highlight types.

  Would you be willing to write up a concrete proposal of the extensions (= markup command) needed for clean support on C functions ?


  Regarding "How do do you ... arrange", that is completely out of the scope of doctools. It is intended for the conversion of the manpages to HTML, nroff, and the like, however it has no truck with installing the results. That is left to the Makefile (or equivalent buildsystem) of the package being documented.


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


  Regarding command/function aliases, this seems part of what building a set of man pages is about. Ideally I would point doctools at a directory full of *.man sources and it would output the nroff (as it does now). But also, it would recognise that Ns_Sls.man actually documents half a dozen related functions and would create sym-links: Ns_SlsAlloc.man -> Ns_Sls.man etc. This allows a user to type 'man Ns_SlsAlloc' and have the right man page appear.

  I think you need the database of which commands are documented on which pages anyway, for the cross referencing to work.


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


  With your feedback, I took another go at it and it's looking a lot better:

    http://naviserver.sourceforge.net/3/naviserver/files/Ns_Sls.html


  That's completely not the mental model I had of how the macros worked.

    [call [fun Ns_SlsAlloc]([type Ns_Sls] *[arg sls], [type Ns_Callback] *[arg cleanup])]

  After marking up Tcl commands, I imagined each arg to 'call' was a significant element: func name, arg, option, type, etc. But it's actually just a blob of text..(?).

  The documentation for doctools doesn't really help. There are no examples. It doesn't tell you when or why you might use a particular macro. It doesn't tell you which macros go together.


  How do I handle return values? Do I just add type and arg in front of fun?


  (I haven't got as far as structures and other types yet. I'll have to think about it...)


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

  Thanks for the patch. Applied it to the current CVS Head,
  its in logger version 0.7. I needed to fix some minor
  failures in the testsuite (to specific pathes to the
  logger.tcl file, wrongNumArgs which were not prepared for
  running with Tcl 8.5).


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

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


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

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


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

  I find that ftp, ftpd and nntp contain examples in the 
  individual module directories. Does that match your 
  findings ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 12276: 466746_ftp.diff

  Logged In: YES 
  user_id=75003

  The fix is correct. Enclosed a patch containing the official
  change.


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

  Accepted. Command is 'uevent::list'. Advanced package version to 0.2. This command was also needed for a proper testsuite, to allow us to check that bind/unbind work as expected.


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

  Fixed the description of the basic layer and messages.
  The SYNOPSIS section is currently always generated, even if not needed. This would be an RFE for doctools, not comm.
  EOL shown as whitespace fixed. I guess that doctools handled the \n in the text incorrectly. This could be a doctools bug, either general, or in specific backends.
  Added comm as keyword.
  Leaving 'communication' as keyword. The keywords describe the general topic of the document, and communication is certainly fitting.

  Committed.


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

  Hm. There are a number of packages which can use tcllibc,
  and IIRC none of them look for and use an installed critcl
  to compile the acceleration codes dynamically.

  Yes, extending the installer should be possible, to have it
  look for critcl, and build tcllibc if it is present. That
  should alleviate most concerns I think. Otherwise we have go
  deeper into the code of all the packages loading their
  various accelerators and have it check for critcl alone as well.

  The other stuff are documentation issues I will address
  after we have consensus regarding tcllibc/critcl. I have
  notified Pat Thoyts directly, as he wrote most of the
  packages using critcl in general, and uuid in particular.


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

  Sorry, realized I could be a little more specific:
  In proc ::ftp::StateHandler on line 284 the following was added:
  if {$ftp(State) ne "quit_sent"}

  for this version. Should be changed to:

  if { ! [ string equal $ftp(State) "quit_sent" ] }

  to maintain compatability with tcl versions earlier the 8.4.

  Thanks,

  John Mercogliano III
  Contractor, TekSystems
  Systems Integration
  Sentara Health Care
  jxmercog@sentara.com


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

  This problem is fixed in the CVS.

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

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


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

  would you please do

      diff -c oldfile newfile

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

  thanks,

  /mtr


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

  I would like this added as well plus a way to add a
  javascript script. I have coded the following and tested
  using TclHttpd server.

  # ::html::css
  #Create the text/css tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the css file to include the filename
  and path
  #
  # Results:
  #HTML for the  section

  proc ::html::css {href} {
      variable page
      ::set html ""
      append html "<link rel=\"stylesheet\" type=\"text/css\"
  href=\"[quoteFormValue $href]\">\n"
      lappend page(css) $html
      return ""
  }

  # ::html::js
  #   Create the text/javascript tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the javascript file to include the
  filename and path
  #
  # Results:
  #HTML for the  section

  proc ::html::js {href} {
      variable page
      ::set html ""
      append html "<script language=\"javascript\"
  type=\"text/javascript\" src=\"[quoteFormValue
  $href]\"></script>\n"
      lappend page(js) $html
      return ""
  }

  I then changed the ::html::head section to include these
  like meta tags:

  # ::html::head
  #
  #Generate the <head> section.  There are a number of
  #optional calls you make *before* this to inject
  #meta tags - see everything between here and the bodyTag proc.
  #
  # Arguments:
  #titleThe page title
  #
  # Results:
  #HTML for the <head> section

  proc ::html::head {title} {
      variable page
      ::set html "[openTag html][openTag head]\n"
      append html "\t[title $title]"
      ::if {[info exists page(author)]} {
  append html "\t$page(author)"
      }
      ::if {[info exists page(meta)]} {
  ::foreach line $page(meta) {
      append html "\t$line\n"
  }
      }
      ::if {[info exists page(css)]} {
      ::foreach style $page(css) {
          append html "\t$style\n"
      }
      }
      ::if {[info exists page(js)]} {
      ::foreach script $page(js) {
          append html "\t$script\n"
      }
      }
      append html "[closeTag]\n"
  }


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Addendum: For the html::js (and I am not sure how) it needs to know whether it 
  is in the <head> section or the <body> section I am thinking. You don't embed 
  a .css file in the body of the html but you *can* with .js files.


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

  Committed the implementations, after reworking them to be a
  bit simpler. I am bailing out on the javascript-in-body issue.


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

  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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Some questions after reading the code:

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

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

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


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

  Yes, you are right.

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

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

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

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

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


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

  also:

  modules/tie/tie_rarray_comm.test
  - tcllib::testutils 1.0
  - comm 4.3
  - snit 1.1
  - cmdline 1.2.4
  - tie 1.0.1
  * tie::std::rarray 1.0
  WARNING: cleanupTests deleting /local/src/tcllib/spawn...


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

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

  Maybe we might avoid this for that platform.

  hmmm


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

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


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

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

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


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

  Done - several other extensions as well: legend, background 


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  You are absolutely right. The use of that particular variable is deprecated (there is no need for such a table anymore). The procedure must be revised. I will look into this.


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

  Fixed in version 0.6.2 (in CVS repository). 

  Instead of a table for the Student's t distribution use the inverse Toms-322 algorithm.


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

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


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

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


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

  The tests check these branches. The if branches seem  to not
  trigger correctly and the value is formatted by the next
  larger range with the wrong extra padding.

      if {($number >= -8388608) && ($number < 8388608)} {
          set numberb [expr {$number & 0xFFFF}]
          set numbera [expr {($number >> 16) & 0xFF}]
          return [binary format H2H2cS $tag 03 $numbera $numberb]
      }
      if {($number >= -2147483648) && ($number < 2147483648)} {
          return [binary format H2H2I $tag 04 $number]
      }
      if {($number >= -549755813888) && ($number <
  549755813888)}     {
          set numberb [expr {$number & 0xFFFFFFFF}]
          set numbera [expr {($number >> 32) & 0xFF}]
          return [binary format H2H2cI $tag 05 $numbera $numberb]
      }

  This is entirely strange..., kann someone please check that
  if is sane on solaris..., basically this check fails:
   
      set number 8388608
      if {($number >= -2147483648) && ($number < 2147483648)} {
             puts "ok"
      } else {
            puts "bad"
      }

  I do not have a solaris box to test on...


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


  Thanks for looking into it.  The
  bug is in Tcl 8.5a4, now reported
  as 1274287.  You'll want to keep
  an eye on it.


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

  dups 429384.  Thoyts notes that it uses the TclX pipe 
  command, so an alternative implementation is needed.


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

  Side note regarding use of this tracker: Pretty please _attach_ files in the future. Copy/pasting them out of the browser through windows and the X server to the editor is ... inconvenient. Downloading to the right location is much easier. Will conserve formatting (indentation, line breaks, etc.) too.


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

  Was able to confirm demonstrated behaviour.
  Commenting the load of the 'tie' package makes it go away.
  Changing the order of loading has no influence, the problem remains.
  Starting to partially load tie.tcl to see how much is needed to trigger the problem.


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

  'tie' is not problem.
  Just loading 'snit' (used by tie) triggers the problem.
  Continuing the investigation ...
  It is the new library of validation commands (validate.tcl) ...
  Defining the first validation snit::type (boolean) does it.
  Which reflects us back to snit itself. Rather, the actual use
  of snit, versus just loading its code.
  Disabling Comp.Define setting the type definition ...
  Not enough ... Comp.Compile is enough to trigger.
  Yes, disabling the snit type compiler makes it go away.
  Comp.Init is enough.

  Ah, ah. This creates a sub interpreter, via [interp create]. Bets that this is the problem. std channels are shared between interpreters, and I guess that there is osmething in there which messes TclX up.

  Confirmed ... 

  Replace the 'puts [package require tie]'
  with 'puts [interp create]'
  and you get your bug.

  Tie only exposes this, the root cause is somewhere in the core, its handling of std channels, and interaction with Tclx.

  I am closing this bug here, please report this in Tcl's bug tracker.

  (And while I am nominally responsible for Tcl's I/O system, and thus the std channels, the sharing of them between interpreters is not something I fully understand. And how this could influence TclX. Actually not fully true ... A first guess would be that TclX dup's the channel at OS level, making a new channel at Tcl level and somehow Tcl then gets confused.)


  Another question to consider ... When you went back to Tcllib 1.8, did you also change Tcl intepreters ? I.e. an older revision of the Tcl core itself ? Because I am quite sure that 'tie' in Tcllib 1.8 ... Ah, ok. Yes, tie in tcllib 1.8 uses snit already, however snit did not have the validation stuff ... Despite this tcllib 1.8 should exhibit the bug you see as well, the moment a snit::type is defined ... Was not dependent on snit in 1.8 ? You can try and remove thesnit dependency from tie ... I see nothing immediate why it is present ... Ah. While the tie core is not dependent on snit the standard data sources all are. However they are not loaded immediately, so not snit type is defined when tie is loaded and things go okay. For a while. When you get a sub interp later on by the first snit definition, or something else TclX will likely blow too. It is just delayed a bit.

  For now I consider the bug report as 'Rejected' here, because it is only a sympton for a Core/TclX bug.


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

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

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

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

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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  a) Visual representation:
  A line from the top of the tree widget window downwards to the first node was removed with the following log entry:

  2004-04-21  Jeff Hobbs  <jeffh@ActiveState.com>
      * tree.tcl (_draw_subnodes): Adjust the drawing of the line to the
      first root node to start at the vertical point (not go up). 

  Jeff explained further by E-Mail:
  The reason I made that change was to be visually compatible with Windows (older style, as new style is no lines) when you actually have sub-nodes (the [+] and [-] indicators).  The line to the top is then inconsistent with the way others draw.
  You could try and make that check contingent on whether subnodes exist, but I think that may seem odd. 

  b) tree -helpcmd patch
  Patch is ok, integrated in cvs, command added to docs.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Koen answered on tcl-devel:

  Ok, I already thought that the Windows style you were referring to always had exactly one top node, which is not the case for BWidget (where the real "root" node is actually invisible).

  I propose to make the line dependent on whether there are multiple top nodes. (Harald, the patch for that is below.) It seems we could agree on that, and I prefer it to an extra option (= extra documentation, which will probably difficult to understand without trying out.)

  --Koen


  Index: tree.tcl
  ===================================================================
  RCS file: /cvsroot/tcllib/bwidget/tree.tcl,v
  retrieving revision 1.59
  diff -b -u -r1.59 tree.tcl
  --- tree.tcl30 Jun 2009 16:17:37 -00001.59
  +++ tree.tcl24 Jul 2009 13:26:22 -0000
  @@ -1369,12 +1369,9 @@
           set yp $y1
           set y1 [_draw_node $path $node $x0 [expr {$y1+$deltay}] $deltax $deltay $padx $showlines]
       }
  -    if { $showlines && [llength $nodes] } {
  -if {$y0 < 0} {
  -    # Adjust the drawing of the line to the first root node
  -    # to start at the vertical point (not go up).
  -    incr y0 $deltay
  -}
  +    # Only draw a line to the virtual root node when there are multiple top nodes.
  +    set len [llength $nodes]
  +    if { $showlines && $len && !($y0 < 0 && $len < 2) } {
           set id [$path.c create line $x0 $y0 $x0 [expr {$yp+$deltay}] \
                       -fill    [Widget::getoption $path -linesfill]   \
                       -stipple [Widget::getoption $path -linestipple] \
  ---

  Jeff answered: Agreed.

  ---

  The upper patch is applied and committed.

  Thanks to all.


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

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


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

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

  exerpt:

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

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

  [call [arg net] [method logname]]

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


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

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


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

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


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

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


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

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


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

  Check ... Is the -type feature supported by Tcl 8.3 ? The 'file join' can be replaced '-directory $dir *' as well. Also a feature not likely present in 8.3. Work on that.


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

  The given result is correct. The canonical CSV
  representation of the lists [list f1 {} f2]
  and [list f1 {"} f2] are

  csv::join [list f1 {} f2]   =>  f1,,f2
  csv::join [list f1 {"} f2]  =>  f1,"""",f2

  Notice the following sentences in the CSV manpage:

  1) If a value contains itself the separator ",",
     then it (the value) is put between "".

  2) If a value contains ", it is replaced by "".

  There is no ',' between the two "" in {f1,"",f2},
  so rule (1) did not apply, but (2) does. This
  causes the given result.


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

  Assigned to Joe as we talked about this a bit and I am 
  going into vacation now.


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

  Added [example_begin] and [example_end] hooks to all current
  output formatters.  (The LaTeX implementation is slightly
  incorrect -- character escaping issues haven't been properly
  accounted for).

  Section cross-references have not been implemented.


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

  Used [format] to get a deterministic precision of the result
  across versions. Committed to head.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Added guard commands to the read2 and split2 procedures, extended testsuite. Bumped to version 0.7.1. Committed to head.


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

  This is definitely not the right place.
  Please go to SF project
      http://sourceforge.net/projects/tktable
  and (re)submit the bug there.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  IMHO, this issue was fixed by [Bug 1842346], so I close it.
  Complain, if the current cvs does not solve the issue.


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

  This is because the type *is* a namespace.  In your example, the ::ns::myObj 
  constructor runs in the ::ns::myObj:: namespace, not the ::ns:: namespace.  
  This is extremely unlikely to change.

  I do agree, I would often find it convenient if ::ns::myObj's code could use any 
  command from ::ns:: without having to import it or qualify it.  I believe there's
  a TIP in progress which would allow me to tell Tcl that when it's in the 
  ::ns::myObj:: namespace it should look for unqualified command names in
  ::ns::myObj, and then in ::ns::, and then in ::, instead of just in ::ns::myObj::
  and ::.  If that pans out, it would be an obvious enhancement--and one that
  I'd welcome.


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

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


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

  The latest edition of listbox.n correctly documents the
  option as "-listvariable" (as of 2000/08/25).  The BWidget
  code is OK.

  I added a bwidget category for bugs in the tcllib project.

  Eric Melski
  The Other Tcl Guy


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

  Confirmed, will fix.

  I really need to add more tests to the testsuite for this
  package...

  Please assign further bugs you find directly to mic42, so i
  get notified.

  Michael


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

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

  Fixed. The string internally (seen by the receiver) is "{puts \\}" and not handling \\ on its own caused misdetection of a "\}" at the end, instead of the proper end of the word.

  comm version 4.6.2.


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


login: canadianjeans
username: canadianjeans
mimetype: text/plain
icomment:
  Whoops. I hit enter by accident :-)

  Returns an unexpected result for any value of "count" other than 1.
  eg: 
  nextNet 1.1.1.1 24 3 
  ...returns "1.1.2.3", not "1.1.4.1", which is what I was expecting.

  The following proc contains my fix:

  proc ::ip::nextNet {prefix mask args} {
      set count 1
      while {[llength $args]} {
      switch -- [lindex $args 0] {
          -ipv4 {set args [lrange $args 1 end]}
          default {
          set count [lindex $args 0]
          set args [lrange $args 1 end]
          }
      }
      }
      if {![string is integer -strict $prefix]} {
      set prefix [toInteger $prefix]
      }
      if {![string is integer -strict $mask] || ($mask < 33 && $mask > 0)} {
      set mask [maskToInt $mask]
      }

     # This is the fix for the issue with "count".
      set prefix [expr $prefix + ((($mask ^ 0xFFffFFff) + 1) * $count) ]
      #set prefix [expr $prefix + ($mask ^ 0xFFffFFff) + $count ]

      return [format "0x%08x" $prefix]
  }


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: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Yes, this needs fixing - for the moment you can set the left margin for 
  the xy-plots via:

  plotconfig xyplot margin left $width_in_pixels


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Oops, try:

  plotconfig xyplot margin bottom $height_in_pixels

  The plotconfig command sets configuration options for the class of plots.
  So all subsequent XY-plots use that option.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Hm, I will definitely have to solve this one by querying the font metrics instead of 
  assuming some size.


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

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

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

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


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

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

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

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

  tcllib-1-15-rc

  branch and work in that.


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

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


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

  fixed html doc in 1.4.0cvs.  This was noted in the 
  ChangeLog, but for some reason never got removed from the 
  docs.


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

  Fixed in CVS.


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

  I am guessing that this the same as RFE [892318], just more detailed.


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

  I believe these were addressed by Jos' patch 483838 applied 
  to 1.4.0cvs.


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

  Oh dear, this is an unexpected side effect of that stuff.
  I have checked the other modules too - there may be a
  similar effect in stooop, but I have no experience with that.

  Other modules seem unlikely to cause trouble (cmdline and
  doctools)

  I have committed the changes to CVS 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  >> Unable to locate or load plugin "docidx" (ERROR for slave interp 1 : can not find channel named
  >> "stdout")

  Hm. This hints at changes to the handling of std channels in 8.6. It may affect all users of tcllib's pluginmgr package. Will have to determine exactly where the failing command comes from (The error message thinks that it is inside of the docidx_import.tcl plugin).


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

  Ah, I missed that this was not only on the wiki, but also
  submitted here. This was fixed in the CVS head on Sep 26.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed. Thanks for the report. The docs at tcllib.sf.net are updated manually and happen when I remember to ping Joe English about this. I'll ping him.


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

  Accepted the reasoning, extended set of named entities with apos.
  Committed to CVS head.
  This is now version 1.1.3.


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

  Logged In: YES 
  user_id=75003
  Originator: YES

  Original submitter of patch is gustaf neuman.

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


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

  An example script was submitted, but cannot be attached here, SF rejects it as too large even when max compressed (bzip2).


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

  Notes from further correspondence.
  (1) We can special maxlen 76 with different wrapchar, that case allows full-speed string map
  (2) RFC 2045, RFC 3548 section 2.1 state that MIME uses 76 by default, the 60 char default in tcllib is non-optimal.

  => Change default maxlen to 76 per mime.
  (4) As wrapchar default is \n this change will cause us to hit the zero-time special case (no reflow needed at all) most of the time, and for the remainder we get fast linear-time algorithms with this patch and per (1). No square-time at all.


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

  Negative -maxlen values ...
  Tcl implementation => The wrapchar sequence is added after _every_ regular coding character.
  Trf => The Reflow algorithm (current) will enter an infinite loop (string length can be reduced to at most 0, and will always be > maxlen, causing the loop to not terminate). The generated result will further not contain anything from the regular output, but only wrapchars. The commands extracting the regular result will return the empty string.

  The new reflow algorithm will not loop indefinitely, howver the result will be as bogus as before, only wrapchars, and nothing else.

  Definitely has to be checked. maxlen 0 is already bad. maxlen 1 is the smallest value we can work with.


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

  Ah, maxlen 0 is special, it means: Do not wrap at all. ... The new reflow code should special case that, the loop can be skipped entirely, only 'string map' to remove \n is needed.


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

  This turns out to be due to a RE bug in Tcl with the 
  handling of \A vs. ^ (see Tcl bug 471101).  I've replace 
  the \A with ^, which is the same when no other options are 
  used and things work.

  I've fixed this for cvs 0.2.


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


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

  You are clobbering the built-in label command with the one from tile. A ttk::label has no option "-highlightthickness". Remove the "namespace import -force ttk::*" and it will work.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Yes, the namespace import ttk::* will break more than just tooltip, and is considered a non-portable operation now.


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  The contents of the history pane stops after the second line of these lines taken from the history in the main tkchat window:

  [03:23]<[Azbo]>test
  [03:24]<}>test2
  [03:24]<µ>3


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

  This is caused by the text widget cloning code using [append] to build strings when it should be using lists.
  Fixed in version 1.424


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

  Thanks for pointing this out - I will repair it asap


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

  Done - the pkgIndex.tcl file in the CVS repository now lists Plotchart as 1.4.0 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hi Stefan.
  Thank you for your report.
  Please note that the "jpeg" package in Tcllib has exif functionality as well.
  Can you check if that also fails on your image ?


login: stwitt
username: stwitt
mimetype: text/plain
icomment:
  Hello Andreas!

  The jpeg package works just fine on this foto,
  I got the EXIF info I wanted,

  That was a very helpful comment, thanks a lot!

  Best regards,

  Stefan


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. I will then assign this to me and close as won't fix.

  Fact is, the 'exif' package has already been put on life-support, is being phased out.
  The next release of Tcllib will not install it by default (It can still be forced to be installed).
  And some time after that we will drop it entirely.


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

  Surprisingly, I don't have a test case for this--but in fact it's perfectly OK for an object to destroy itself.

  Of course, it shouldn't try to do anything else after calling "$self destroy".... 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The 'jpeg' module has exif retrieval functionality as well.
  Does that work ?

  The 'exif' package has not been updated for anything in a long time, as there is no maintainer for it. The jpeg package on the other hand does have a maintainer (afaupell), should it not work with your images either.


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

  duplicate of 939532. also exif has been superseded by jpeg which does not suffer from this problem


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: takatsuki
username: takatsuki
mimetype: text/plain
icomment:
  Sorry, I just found a copy-paste error in my patch. In:

  proc ListBox::_init_drag_cmd { path X Y top } {
   set path [winfo parent $path]
    set ltags [$path.c gettags current]
   set item [lindex $ltags 0]
   if { [string equal $item "item"] ||
      [string equal $item "img"] ||
      [string equal $item "win"] } {
          set item [ListBox::_get_node_name $path $id]

  $id is not defined, it should be 

  set item [ListBox::_get_node_name $path]

  Or 

  set item [ListBox::_get_node_name $path current]

  Sorry for that.


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: 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: mic42
username: mic42
mimetype: text/plain
icomment:
  data_type - 362883

  Logged In: YES 
  user_id=302287

  This is more of a feature request than a bug.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Good catch. The default loglevel wasn't propagated for the lowest level loggers.
  Fixed with 0.9.2 (in cvs).


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Aha!

  uri::split and uri::join are presuming that the fragment *precedes* the query.  But it can't, I think, because the fragment is handled by the user agent, and isn't properly part of the URI at all, whereas the query most certainly is.


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

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


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

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


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

  Well, the given example will barf if a list element contains
  spaces. The split command in the script will get the wrong
  number of arguments. In other words, this type of
  substitution is an easy way to create subtle errors, and to
  quoting hell when trying to fix such errors.

  For what is wanted here it is much better to place the code
  into a proper procedure. Also note that "Lmap" is an
  internal command name. The proper and documented entry is
  the "::struct list" command. "Lmap" is allowed to change
  from version to version in incompatible ways.

  proc varset {varval} {uplevel 1 set [split $varval =]}
  ::struct::list map {name=vogel ...} varset

  No quoting hell, spaces in the parameter are properly
  handled too.


login: svogel
username: svogel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=250752

  Oooops. Damn spaces :-)
  Yes, you're definitely right.
  Best regards
     Stefan

  ... closing this item ...


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

  Fixed in CVS head, as part of the fix for 3312880 (where it was in the inlined patch).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed. Looking at the larger stacktrace this seems to be happening while the string channel is constructed. Looking further I find that the events constructor is not called. It seems that I have to chain them manually with 'next', 'oo' is not doing it for me. This may affect all the classes.

  Continuing...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes, "tcl::chan::memchan" was also affected, as was "tcl::chan::variable". The other classes did the proper chaining. Very likely a copy-pasta error during development.


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Well, I also stumbled over 2treeCallback some days ago. And thought: that whole proc isn't an example for good code.

  That starts with unusual coding style:

      if {"$slash" == "/"} {

  The quotes around $slash aren't wrong in the sense of being a bug, sure. But the experienced tcl programmer get disturbed for an eye blink and unexperienced tcl programmers may get confused and may assume some special magic.

  And goes on with superfluous code, within the first non-comment lines of the proc:

      if {$textBehindTheTag != {}} {
          set text [mapEscapes $textBehindTheTag]
      }

  Too sad, $text isn't used anywhere later on in the proc.

  This all is harmless for the question "is the result of the proc
  correct", sure.

  The code cited by the originial poster is not, but not only in the case of the PRE element.

  An example is pretty easy (here done with an other element, to show that we talk about a more general problem):


  package require struct::tree
  package require htmlparse

  struct::tree resultTree1
  htmlparse::2tree "<p>foo <b>bar</b> baz</p>" resultTree1

  struct::tree resultTree2
  htmlparse::2tree "<p>foo<b>bar</b>baz</p>" resultTree2

  if {[resultTree1 serialize] eq [resultTree2 serialize]} {
      puts "Identical HTML fragments"
  } else {
      puts "HTML fragments differ."
  }

  This script returns "Identical HTML fragments", which doesn't look quit right. 

  Well, sure, the proc does what it does. In the words of the manual: "[It] takes an HTML string and converts it into a tree containing the logical structure of the parsed document." This is a vague description of what should happen (or, otherwise around, what one should expect to get out, if used).

  But as it is now, the user get neither the whole unmodified PCDATA content of the html input string nor the PCDATA with white space condensed in the ususal way by an HTML browser (css white-space value "normal") nor the PCDATA with white space handled in any other of the ways the css attribute white-space knows ("pre", "nowrap").

  That result my be meant by "logical structure of the parsed document" but it at least makes 2tree useless for everyone which want to parse an html document to render it in so way (to pdf, rtf, ...).

  At a minium a word about the strange white space handling of the current proc within the documentation is necessary.

  Adding a special case for the PRE element into this weird white space handling - as the originial poster proposes - may help for a small range of real word problems but in general makes things even worser, in my opinion.

  The easiest would be, to remove the whole line: no white space stripping at all of the PCDATA contents. Sure, this burden the consumer of the result tree with the white space handling, but at least it then has a chance to get it right, while it now hasn't any chance to get it right because it gets it already mangled. If nobody will be do more, I would for sure at least do that: remove the line.

  A more elaborated white space handling would for sure be convenient in a lot of cases. If someone writes one, it would still be a good feature, to be able to get the whole unmodified PCDATA, if needed (by an option).

  A natural candidate for how an elaborated white space handling should work is the css white-space attribute value "normal", that means, all white spaces (spaces, tabs, line breaks) condensed into a single space.

  Beside all that, the special handling of some auto-closing HTML tags does just work by accident, if ever.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Thanks to Rolf Ade going into details.

  I would prefer that the htmlparse package would preserve all whitespaces, not modifying the content to return really only the logical structure of the given document!

  I as user of HTML data have to care for this, knowing that some tags have a special whitespace behavior, knowing that CSS rules modify the whitespace behavior, but NOT the logical structure of the document.

  So my proposed change would be to remove all whitespace handling (replacing several whitespaces by a space and trimming trailing whitespaces) and to document this in the man page, to make sure, that the package user knows, that the contents are really not changed!

  Regards,

  Martin


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

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

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


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

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

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


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

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


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

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

  Also added a few tests to fileutil.test.


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

  Okay, I will look into this - it should be easy to fix :)


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

  I have corrected the man page. Thanks for noticing this


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Very good initiative.
  I caused that (by a bwidget release), but don't know how to fix it.

  Any clues welcome,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Unfortunately I do not know either. As far as I know SourceForge automatically takes the last release of anything as the download link, and that it can't be overridden, except by another release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I recently added the Tcllib 1.15 release, yet SF still displays bwidget 1.9.6 as the latest.
  I have no idea what is going on here with SF.


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

  This is the same problem already mentioned in Bug 1645333 (for asnGetContext), which is fixed in CVS HEAD (since Version 0.8.1).


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

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


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

  I believe the problem is that the makefile target
  install-libraries does not define the option -app-path, and
  so takes a default directly from the executing tcl shell.
  This was fixed in the CVS Head at March 25.


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

  The crc32 algorithm includes a finalization step where the result of the algorithm is xor'd. To use it for chaining segments as you are trying to do you would need to undo the xor to feed the result from one step into the seed for the next.
  eg: crc32 -seed [expr {[crc32 $data] ^ 0xffffffff}] $moredata

  This is presented already in a more usable form using the Crc32Init/Crc32Update/Crc32Final methods which have been written for this kind of incremental checksum.


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

  Logged In: YES 
  user_id=75003

  The attached patch should fix the problem. Please check.


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

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


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Themes will be included in BWidget 2.0. This is IMHO not a bug but a feature request.
  So I will close the bug report here.


login: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Gregor,
  thank you for the report. It is now fixed with the assumption, that:
  - all screens have the same size
  - all screens are directly one beside the other
  Unfortunately, both are not true in general, but the current solution is a step forward.

  I have read that there is no way to find the screen geometries of the other screens with tk, so this seams the best possible solution.

  The fix in cvs also includes your solution.


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


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

  What version of mime is this ?
  If it is not from Tcllib 1.8, can you try with Tcllib 1.8 too ?

  Also note: As you your are sourcing the files directly, in
  what namespace are your source commands ?

  Reason for my question: mime.tcl provides a package, and the
  package management _always_ sources such a file from within
  the global namespace. Because of this it is quite possible
  that mime.tcl contains tcl code which will only work for
  that environment, and not when the file is sourced within a
  different namespace.


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

  Done. The new file is 'mime.bench'. The unstructured
  benchmarks have been removed now.


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

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

  Committed fix to both 1-6 branch and Head.


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

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


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

  I've fixed the alert mechanism to raise the alert for the window concerned now. This is fixed in 1.415.


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

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

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


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

  Actually using it in http://wiki.tcl.tk/16631 suggest that for the asnTLV proc the following semantics are more useful:

       proc asnGetTLV { data_var tlv_var } {
   # gets a tag/length/value from the start of the data.
   # return false if no data available, true if succesful
    upvar $data_var data $tlv_var tlv
    dputs "Getting the first element from: [util::string2hex $data]"
  if {[string length $data] < 2} {
      return false
  }
    asnGetByte data tag
    asnGetLength data length
    asnGetBytes data $length temp
  set tlv [asnTLV $tag $temp]
  return true
  }


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

  Thanks that you haven't forget to raise package version when
  fixed this bug. Now I can package require asn 0.4.1 and be
  sure that my code would throw an error rather than silently
  produce incorrect data.

  Happy New Year


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

  for the missing variable the code would seem to preclude this error:

      variable RES
      set file [file normalize $file]
      FindResources $file
      if {![info exists RES($file,group,$name,members)]} { return -code error "no icon \"$name\"" }


  for the 3 element list or vista icon please reopen this bug or a new one and attach files which demonstrate the problems. this bug was submitted anonymously so I have no one to contact for more information. thanks


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

  I have implemented a first version - it can do only one 
  series of data per histogram, but that ought to be enough.

  I have ideas on how to extend it: stacking the bar on top of
  each other. Other options: cumulative plots in stead of each
  bar on its own... Just let me know.


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

  Closed the request - Plotchart has the possibility to dispaly histograms


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

  Ok, the .gz file was the only file which was short, and I have re-uploaded it now.
  NOTE: It may still be necessary to download it multiple times, as it seems that even now, about 20 hours after re-upload, some of the mirrors still have short files. At least one mirror is ok tough, returning the full file (5319952 bytes, md5 5bc9567b3a61884716a908d5295d7105).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  A bit more info, the checksums:

  a5133b5380e5ae71faf1c6712a3b11ba  tcllib/1.13/README-1.13.txt
  f2553e4834555b206726461e4600813e  tcllib/1.13/tcllib-1.13.kit
  4625574b88a65031ecf0a0fd7e33764d  tcllib/1.13/tcllib-1.13.tar.bz2
  5bc9567b3a61884716a908d5295d7105  tcllib/1.13/tcllib-1.13.tar.gz
  272f91778ba43e43abe6dea3531062b2  tcllib/1.13/tcllib-1.13.zip

  The Files manager shows this data as well, behind the (I) button of each file.


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

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


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

  Added this to the ldap module as ldapx.tcl based on the last
  version i received by email and some minor stylistic changes
  (unset -> array unset where appropriate, added some missing
  --, changed some string equals to eq, and so on)


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


  A second look make it look like
  Tcl is at fault here, not aes.

  still looking...


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

  Note: The newest revision of dtplite in the Tcllib CVS is able to link to a document by its title (per [titledesc]), when said title is marked up via [term]. This is hackish. It also does not support references to specific sections. This might need the RFE for explicit labels on (sub)sections (to get around problems with non-unique section titles) so that we can use these labels in the external references.


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

  Changed code to detect the situation and throw a more properly looking error ('Not enough data to process padding'). This is now version 2.4.2 of base64.


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



  File Added - 189517: ldap.patch

  Logged In: YES 
  user_id=1268042

  New patch (which supersedes the first one) with a small 
  bug corrected in the attrsOnly option handling.


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

  Just do it again if you get an error. However, you are using this wrong and will leak arrays if you run this alot. Re-read the manual page and pay attention to 
  "Once you have finished, you should use [cmd cleanup] to release all resources. The default port is [const 37]."

  See the example too. You get a token and you should use that to check for errors before trying to use the time value.
  if {[time::status $tok] ne "ok"} {
    puts "something bad: [time::error $tok]"
    ...retry with next server...
  }


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: ericm
username: ericm
mimetype: text/plain
icomment:
  I replaced the aclocal.m4 file with tcl.m4 from the former config module, so
  the config directory is not requird.  This is not the best solution probably, but it will do for now.  A better solution would be to figure out how to make
  all the Tcl packages on SF reference the config module, just as they did
  when they all lived at Scriptics CVS.

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


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

  This is a nice bug in ListBox::_mouse_select.

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


  The return value is required in ListBox::_multiple_select


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

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


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

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


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

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


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

  After reviewing, I've decided to doc note that synchronous dialogs will always withdraw.  Otherwise trying to get the feedback that a -command wanted to not withdraw looks icky.


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

  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:
  Ad 1. Cloning is essentially a serialize+deserialize operation. Using snit introspection it should be possible to automate basic support for this, maybe even in a snit::macro. Note, this implies that currently there is no such support in snit, AFAIK. Now further, if the object to clone is more complex, like using timers, sockets, files, i.e. any type of state which is not stored directly in the object, the basic clone will not be enough. For these cloning will need custom written support code which handles all the complex parts.

  Ad 1. The struct::{graph,tree} structures in Tcllib, while not based on snit, contain '(de)serialize' methods, fully custom written, and assignment/copy methods on top, even with support for copy during construction.

  Ad 2. No idea, defering to Will for that.

  Ad 3. No idea, defering to Will for that.


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

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


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

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


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

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

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


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

  Yes, those docs will be coming.  I'm holding back
  in hopes that someone will dream up a better name
  for this command than [rswitch].

  It will be a bug if any version of control gets
  released without docs for all its commands.  The
  HEAD version of control, however, is not in releasable
  condition.  I think that's OK.  There should be someplace
  in the CVS repos where developers can share code that's
  "in progress".  Traditionally that place is the HEAD
  branch.  It's not reasonable to expect every 
  commit to produce a HEAD in releasable condition.

  That said, we do need to have a branch in the tcllib CVS
  repository where the code is guaranteed to be in releasable
  condition, so the packagers/releasers of tcllib know where
  to get that code at any time they want to make another
  tcllib release.  This is the discussion on branching and
  tagging in tcllib, that I need to start on the tcllib-dev
  mailing list as I suggested a few weeks back.


login: tomk
username: tomk
mimetype: text/plain
icomment:
  Andreas,
  A trigger on ::argv would be a simple solution and I wouldn't think there would be bad side effects. I've modified ::argv in several applications and followed it with an update of ::argc. I don't think a trigger on ::argv would break mine or similar code. My personal feeling is I don't care if the change is made or not.
  tomk


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

  This is handled by the new magic(5) based recognizer, new
  module fumagic aka fileutil::magic. Therefore done.


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

  Fixed up the manual with this plus comments for all the commands.


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

  Tested with Tcllib 1.15, Tcl 8.5.11, on Linux (Ubuntu 11.04, 64bit).
  I am unable to reproduce the problem.


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

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

  next time, provide a complete description of what you are doing.


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

  I dealt with the userinfo bugs yesterday as part of another
  bug notice. The uri::geturl ftp support I have raised as a
  feature request.


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

  Fixed. Found three places where 'subtract' was wrong, replaced by 'exclude'. One use of 'subtract' was ok, and left unchanged. Version bumped to 0.9.1.


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

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

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


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

  You get the message about 'no benchmarks' when specifying
  "-verbose". I have chnaged the default level now to 'warn'
  (from 'critical', and elevated the message itself from
  'info' to 'warn' as well.

  Regarding the splitting it might be better to simply make
  all keys fully fledged lists. That way we get correct
  quoting all the way.


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

  However, using lists as keys requires a full-blown rewrite
  of the internals, as that requires changes everywhere.


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

  Ok, did the rewrite of the internals, all keys are lists now.
  With that all issues have been addressed.


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

  This seems to be an issue with Tcl 8.5 or higher, where errorCode will be left unset until the first actual error, caught or not.

  Committed revision  [ea86982e87].


login: jepler
username: jepler
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2772

  I'm using bwidget with tcl/tk8.4.10.  There are still
  N-squared behaviors with "-selectfill 1".


login: 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: 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: lvirden
username: lvirden
mimetype: text/plain
icomment:
  My mind is bouncing around quite a bit over this idea, for several reasons. For instance, my initial thought was "yes - but having a persistent storage "data structure" that could be layered over any data structure would be better than just having a stack that had persistent storage".

  Thought two was "even neater - having a tcllib module that could be plugged in and that would maintain persistent storage for nearly all of a program would be neater - a checkpoint facility so that a program's state was maintained and when you opened it, things could be reset just as you left them" (understanding that there may be some things within an average program which could not maintain persistence).

  Then I thought "but couldn't you just create instead a mechanism that creates a "tie" between a database (such as sqlite) and an application, so that the information in the database appeared within the program as some sort of data structure, able to be read or written like a data structure instead of using select/update/delete sql statements".


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

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


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Stephen,
  this option is documented and implemented as readonly.

  Unfortunately, I first fixed it and then read the manual. So I fixed the manual too.
  Please check, if current cvs works for you.


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

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

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

  The example smtpd code will reject such mails.


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

  Thats because your DNS server is handing out a CNAME for the first response. You might try 
   foreach answer [dns::result $token] {
      array set A $answer
      puts [list $A(type) $A(name) $A(rdata)]
   }
  Now RFC974 which covers MX records say "There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias  for some other domain name. The query should be repeated with the canonical domain name." which seems to me that you need to go and do a lookup on the CNAME from the application layer.


login: anonymous
mimetype: text/plain
icomment:
  Sorry. This is my problem with understanding how Theme machinery works.
  Pat Thoyts explain this problem in post: 
  https://groups.google.com/forum/#!topic/comp.lang.tcl/RmbiFrTFCdw/discussion


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

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

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

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


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


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

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


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


login: stwo
mimetype: text/plain
icomment:
  The version in TkLib is newer and has more features.
  The version on the wiki is an older version with changes that aren't important, imo.
  Recommend leaving things as they are, just apply this little patch/fix.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Commit [2446bda270].
  Pushed.

  This is on branch "dia-pdf".

  Implemented a package "canvas::pdf" which encapsulates the above code in a form usable to "diagram::application", i.e. the apps/diagram-viewer.

  After installing the extended tklib the dia-viewer should automatically accept "pdf" as a new output format.

  Please test.


login: arjenmarkus
mimetype: text/plain
icomment:
  I found a small bug in canvas_pdf.tcl -- .canvas should have been $canvas.

  (Something unexpected happening with fossil - to be reported separately - prevents me from applying it directly).

  Also, a small problem on Windows with the application submodule: errors are not shown when using wish (there is no proper terminal to show the error message in). Also to be reported separately.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Fixed canvas_pdf.tcl  - Version bumped to 1.0.1.

  Fixed application.tcl - Version bumped to 1.3.

  NOTE: Fixed your application patch, was not working as indented.
  'package present' throws an error when the package is not present.
  You have to catch it, not [llength] on the error message you see in an interactive tclsh.

  Revision [04b7108ed8].
  Committed.
  Pushed. Note: This is on branch "dia-pdf".


login: arjenmarkus
mimetype: text/plain
icomment:
  Implemented in version 2.3.3:

  barcharts with vertical bars now accept an option -xlabelangle angle, which shows the labels with the given angle. Defaults to zero - horizontal labels.


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  Thank you, Thomas, for the contribution.
  Proposed for testing in branch [5634c2dfd1].

  Could another user please test the new version ?

  Thank you,
  Harald


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Unfortunately, up to now I haven't been aware of this ticket.

  The repeated behavior happens only with Tablelist_tile, if the current theme is "aqua" and the first column is right-aligned.  Under these circumstances the procedure tablelist::seeCell, implemented in the file tablelistWidget.tcl, triggers an endless while loop.  To eliminate it, we have to take into account some internal details related to the way the header labels for the "aqua" theme are placed in their parent frame.

  Here is the bug-fix: Locate the line starting with "set rX":

          set rX [expr {$lX + [winfo width $data(hdrTxtFrmLbl)$col] - 1}]

  Just below this line insert the following code:

          if {[string compare [getCurrentTheme] "aqua"] == 0} {
              incr lX
              if {$col == 0} {
                  incr lX
              }
          }

  This patch will be contained in the next Tablelist release 6.4.


