# ticketchng

login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  Almost Free Text (http://www.maplefish.com/todd/aft.html),
  txt2html
  (http://txt2html.sourceforge.net/txt2html.html#input_file_format),
  and txt2tags (http://txt2tags.sourceforge.net/rules.html)
  have methods of supporting table output based on character
  markup coming in.

  Just to show some examples of how other processors handle
  the task.


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

  Thanks for the examples, David.  I see that from these, and
  the others with which I am familiar, just about everything
  requires some sort of delimiter between column entries.  And
  I've also looked at how the formatting engines handle lists
  and examples.  

  It appears that for the "plain" formats I suggested, using
  line delimters for rows and word delimiters for columns, it
  would be necessary to have fmt_plain_text change modes of
  operation in a table environment.  This is presently only
  done for latex examples (as far as I looked).  So it would
  take a global (i.e., _in_table) and a switch inside of
  fmt_plain_text to make it work.

  It would also be possible to only support a single-command
  format for a  table, much like the short form of example. 
  So your table would be created with something like:

  [table -align left -title "Units Abbreviations" {
  Quantity      "Unit Name"  Abbr.
  Length        meter        m
  Mass          kilogram     kg
  Time          second       s
  }

  This has the advantage of having all the table data in once
  piece, so you can compute column widths for text formats. 
  Your choice as to using Tcl words or a special delimiter
  character to deliniate column entries, but I think I still
  prefer words, just because it seems tclish.


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

  This is already fixed in the CVS Head.

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

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

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


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

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


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

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


login: ferrieux
username: ferrieux
mimetype: text/plain
icomment:
  Why stop halfway ? Comments and settings line would benefit from the same tolerance.
  The simpler patch below does that.

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


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


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [c443dd347c].
  Committed.
  Pushed.
  Version bumped to 0.2.6.
  Extended testsuite.

  Tweak to patch: 'set' must be '::set', package has a local 'set' in its namespace.


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

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


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

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

  Closing.


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

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


login: egavilan
username: egavilan
mimetype: text/plain
icomment:
  While I've tried to write 8.4 compatible code, is untested with this Tcl version. The first problem noted: ascii85::checkrange contains a [return -level] command, which is an 8.5 feature.
  Solution is either to remove it, or make the package dependant on 8.5, in which case some code could be simplified using newer features ( unsingned [binary scan]s, "in" operator, etc)


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

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


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

  Accepted the patch, committed to CVS head.

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

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


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

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

  Thank you,
  Harald


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


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

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


login: cleverly
username: cleverly
mimetype: text/plain
icomment:
  File Added - 56581: list.tcl.patch

  Logged In: YES 
  user_id=22080

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


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

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


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


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

  Note that this is just one specific instance of
  a general problem with the packages in tcllib:
  they fail to declare and manage their package
  dependencies.  This report is about a failure
  to declare dependence on "Tcl 8.2", but all
  dependencies need to be declared and checked.


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

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

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


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


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


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

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

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

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

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


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

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

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

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


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


login: keithv
username: keithv
mimetype: text/plain
icomment:
  the crash is caused by a missing line:
      upvar #0 ::ftpd::$sock data

  But a bigger problem is that permission logic in authFileCmd is wrong for renaming. It returns not ok if the file doesn't exist and okay if the file does exists.


login: martinao
username: martinao
mimetype: text/plain
icomment:
  I noticed incorrect return values of Rename also. I did not mention this, as I did not want to "overload" the above bug report.
  Also, I did not see any easy correction possibility like above- this needs a deeper insight into ftpd.tcl. Therefore I currently use the workaround (client side):
  1) Check, if a file with the target name already exists. If yes, delete that file.
  2) Call Rename.
  3) Check on the target file.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed the missing upvar in CVS head. Thanks.

  Regarding the authentication ... The high-level rename is apparently implemented in ftp via 2 commands, RNFR, and RNTO, to specify source and destination path ... Currently both these commands auth-check their path for "write" ... Seems that we need new modes, for "rename-src" and "rename-dst" ?

  Reading "fileAuth" I am unable to understand it any longer. Should rewrite it to separate the handling of the modes, instead of having the mode and file checks mixed with each other.


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

  OK. It is modified as suggested.

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

  Jean-Luc


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

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


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

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

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

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

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


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

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


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

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


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

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


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

  Added patch containing manpages for base64, cmdline and 
  fileutil. ftp is not done yet.


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

  Just saw that ftp has documentation, HTML based.
  See "modules/ftp/docs" ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10710: ftp.n

  Logged In: YES 
  user_id=75003

  Here is manpage for ftp. I used the HTML documentation as 
  template for the first sketch and then reworded it to make 
  it sound better, less stilted and more clear.


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

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

  This is in cvs now.

  Test cases:

  PasswdDlg .p -passwdstate disabled
  PasswdDlg .p


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

  Logged In: YES 
  user_id=75003

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


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

  Logged In: YES 
  user_id=152318

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


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

  Here you go:

  package require Tk
  package require BWidget

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

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


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

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


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

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


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

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

  Thus modify your deletion loop like that:

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

  Thank you and sorry for the inconvenience.

  Harald


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

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


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Please show me the code which cause the problem again.

  I tested yaml/huddle by Tcl-8.4.4(Windows)+dict-8.5.3, and all test are green.


login: al_chou
username: al_chou
mimetype: text/plain
icomment:
  Here's the transcript of my wish session:

  (albertc) 1 % package require yaml
  0.3.3
  (albertc) 2 % set y {bar: 
  >  fruit: apple 
  >  name: steve 
  >  sport: baseball
  > }
  bar: 
   fruit: apple 
   name: steve 
   sport: baseball

  (albertc) 3 % ::yaml::yaml2dict $y
  can't read "data(current)": no such element in array
  (albertc) 4 % puts $tcl_version
  8.4


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  OK.
  I found yaml::data(current) may not be initiailzed.
  Speaking concretely, this problem's arising, when there is not empty line or "---" at the beginning of yaml.


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

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

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

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

  No eval required, no quoting hell.


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

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

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


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

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


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

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

  Fixed, and committed to head.


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

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

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

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

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

  How would this work for you?


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

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


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

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

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


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

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


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

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

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


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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes, that is intentional. The code doing this is in the last 6 lines of the file "log.tcl".
  This was done because (we believe that) in most situations debugging output is not wanted.
  Most wish to have such output only when actually debugging an application.


login: jxmercog
username: jxmercog
mimetype: text/plain
icomment:
  Ah, I see it now.  Should add the default settings to the man pages.  It was not obvious in the code as the initialization of the array had everything set to '0'.  Plus, should not have to look in the code to figure out the default settings. Probably in the Levels section where you list all the log levels.  
  Let me know if you want me to open up a new tracker item for the doc change.

  Thanks,


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  No need too. I have now updated the docs in the CVS, and also made a comment in the code to cross-reference the two relevant places. Changing state to 'fixed'.


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

  I'm currently looking into coding a c version to reduce
  memory consumption and speed (i like the tcllib interface,
  but it is a bit slow using 150 000 + Nodes...), perhaps
  there are some ideas how this could be done. Any help
  appreciated.


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

  Whow, there do you use 150 000+ nodes ?

  Seriously. We have a command per graph. The implementation 
  (= C function) of this command should be shared, and be 
  given a reference to the actual graph structure during 
  registration as true tcl command (ClientData of tcl 
  commands!). In the shared implementation cast the incoming 
  clientdata into the correct pointer to the graph structure 
  and then just use it.

  nodes, arcs. Use hashtables to map from node and arc names 
  to the structures hold information about them. Interlink 
  these structure. For example an arc structure should 
  contain references to the two nodes the arc is connected 
  too. Same for node structures, should have references to 
  all incoming and outgoing arcs. Possibilities here are 
  dynamically allocated arrays, linked lists, hash tables, 
  Tcl_Obj => list functionality.

  A C implementation would be great.


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

  I have finished a c coded version of the tcllib 1.3 version.
  It can be found at:

  http://purl.oclc.org/NET/schlenk/tcl/cgraph

  Michael


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

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


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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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


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



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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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


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



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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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

  File Added: yaml-0.2.1.tar.gz


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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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

  File Added: yaml-0.2.2.tar.gz


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

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

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


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

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


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

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


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

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

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


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

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


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

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


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

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

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

  Regards,
  Stéphane Arnold


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


  Thanks for the renumbering.

  The failing tests are 2.6c and
  2.6e.

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


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

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

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


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


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

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


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

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


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

  Patch applied.

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

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

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


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

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


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

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


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


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


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


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

  PT=pt

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


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

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

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

  Continuing...


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

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


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

  Logged In: YES 
  user_id=65359

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


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

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


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

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

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

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

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

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

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


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

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

          file mtime $filename [clock seconds]

  that part of the script appears to work.

  There are other problems which I have documented elsewhere.


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

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


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

  Logged In: YES 
  user_id=1852298
  Originator: YES

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


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

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


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

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

  And egavilan confirms on the Tcler's chat:

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


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

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


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

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

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

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

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

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

      $p plot data $x $y
  }

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

  Clearly this must be checked


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

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


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  I think that those test failure is caused not by json module but by dict comparison.

  I might recommend to use proc dictsort2 in yaml.test for the tests.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

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


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

  I got 

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

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


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

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


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

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

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

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


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

  modified these "switch"es.

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


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

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

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


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

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

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

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

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

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


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

  Renamed 'stooop.html' to 'stooop_man.html' and updated the 
  doctools manpage. I did not deprecate the .n file yet.

  The problem with full urls is of course that it ties the 
  documentation to a particular location. This is bad for self-
  contained documentation packages (like for example 
  Windows CHM files - I am thinking of the ActiveTcl 
  documentation here).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes. They are out of order.

  The fact that this always failed however had no influence on the result. It simply defered to [IPv4?] and that did the right thing.

  It seems that this was some attempt at a speed optimization, with [IPv4?] defering to the (presumably) expensive [Normalize4] and catching its ok/error.

  We can either drop thisd check entirely, or maybe make it a part of IPv4?, suitable corrected.
  I am currently leaning towards the latter.


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

  mime::initialize -canonical text/plain -string message \
   -header [list Content-Disposition "attachment;
  filename=\"qqq\"]
  will do the trick fine.
  I've not found any reference in RFC2046 that excludes
  MIME-Version from the parts. I shall look into Content-ID in
  the main part but I suspect it is permitted (how else might
  one refer to that part if necessary).


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

  Accepted into CVS head, with modifications. (Put the common checking code into a procedure, calling it at all the modified places).


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

  Oh, oh, the profiler is using clock internally, and in 8.5
  they are procedures and thus show up in the trace. Hm. I am
  not sure if we can exclude them, as they may _also_ come in
  due to the profiled code.

  So maybe just using a version dependent test result to fix
  this ?


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


  simplest thing would be a more
  forgiving match like -match glob
  or -match regexp.


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

  Duplicated the test. Original constrained to 8.4-, new
  variant for 8.5+ with changed result. Committed.


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

  nyademo, do you have a png file with which we can demo the problem and fix ? I am currently extending the testsuite to show problem and fix, and found that the 2 images which have comments we have here are not triggering the problem. Therefore unsuitable for testing.


login: nyademo
username: nyademo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=932722
  Originator: YES

  Hi.
  I had to write my environment first, sorry.
  It seems to me that the problem is not exists on the png file.
  It is on my japanese environment. cp932 is default encoding 
  on windows. Maybe other languages have their own default encodings...
  It is a reason what output endoding must be binary.

  encoding system cp932
  png::removeComments $file

  This code may enable you to find the bug.


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

  Updated testsuite now too. Won't fail for bug on unix, but does on win32, which is good enough for me. No need to fiddle with the system encoding.


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

  I'm revoking this patch in favour of a new one because the
  CVS source has been changed which this has been here in such
  a way as to cause a conflict. The patch is merged into my
  HTTP redirect following patch.


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, Andreas, for the hint.
  The CVS starter crew on this side of the ocean was propably not aware of this possibility...


login: oehhar
mimetype: text/plain
icomment:
  As there is no active development any more on this branch of BWidget, I allowed to set the state to "pending".

  Harald


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

  I used a slightly different fix that will accept normal or 
  enabled (actually only worries if "disabled" is passed 
  in).  This is in 1.3.1.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13229: 481023.diff

  Logged In: YES 
  user_id=75003

  Attaching an implementation of the FR as unified diff 
  agaisnt the current code/behaviour.


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

  We have different implementations for 8.[23] and 8.4+, and
  the implementation for 8.4+ seems to be buggy. It tries to
  use local vars for the set elements, to avoid an additional
  hash lookup, or such. Perf opt, goes through an 'eval'. It
  is not the eval. The '()' cause the code to think that the
  local is an array element. Bah. I will simply disable this
  special branch and use the 8.[23] implementation for all
  versions.


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

  Should be fixed now (mpformats/fmt.tmml revision 1.12).

  However, I don't think 'make doc' should be invoking 'make
  tmml-doc' in the first place: at present, most users won't
  be able to do anything useful with the TMML renditions, and
  those that do want them can easily build it themselves.


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

  Better use the official IANA list at:
  http://www.iana.org/assignments/uri-schemes


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

  In the dns module I've implemented the dns scheme as a uri
  module extension. Therefore:

  package require dns
  dns::split dns://nameserver.here.bogus/remote.host.com?type=MX

  can do the expected thing. I followed the internet draft for
  this (draft-josefsson-dns-url).


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

  The two supplied examples appear the same, but perhaps the 
  user meant to type something else in.  I also don't see an 
  attached patch.  This needs to be better defined to be 
  fixed.


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

  Enclosed a new patch which corrects two problems:

  - Reset of textcmd to "" is now possible.
  - Code checking for the textcmd made more robust
    against odd macro names (like '5')


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

  With the possible exception of instance creation, this has been 
  implemented in Snit V0.95.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed in CVS head. doctools::paths was a plain version mismatch. doctools::nroff::man.macros required a rename of the package. The '.' (dot) is not allowed for Tcl Module names. man.macros became man_macros. The packages in doctools2{base,idx,toc} using it were updated too, with proper version bumps.


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

  Confirmed. Difficult to solve. We have to protect special
  characters in the string we try to flatten while stripping
  out a listlevel. The latter _requires_ eval, not using it is
  not an option.


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

  A fix has been committed to the CVS head. The testsuite has
  been expanded to cover this, and similar cases.


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

  This can be a bug. The code we inherited is so convoluted 
  that it is difficult to say. 

  I was thinking that this could also be a DNS resolution 
  problem as the DNS resolver will also wait quite long for a 
  responses, uninteruptible, however I see that you are using 
  an explicit IP address.

  You can activate more verbose logging, maybe this will give 
  us some hints. From the docs:

  The output of the package is controlled by two state 
  variables, ::ftp::VERBOSE and ::ftp::DEBUG. 
  Setting ::ftp::VERBOSE to "1" forces the package to show all 
  responses from a remote server. The default value is "0". 
  Setting ::ftp::DEBUG to "1" enables debugging and forces the 
  package to show all return codes, states, state changes 
  and "real" ftp commands. The default value is "0".


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

  Note that the current internal architecture of
  mpexpand (with its two slave interps) was chosen
  to expressly allow the definition and usage of
  [proc]s inside of doctools manpages without
  disturbing neither the high-level control in
  mpexpand nor the loaded formatting engine. The
  procecedures may use only the declared doctools
  commands and also have limited access to the
  expander object itself (so that they can push/pop
  contexts etc). With this it is possible to create
  higher-level constructs which capture more complex
  documentation structures without giving up the
  separation between structure and visual appearance.

  If wanted I can provide alpha code for a tcllib
  module handling the FIG vector format where one
  of its doctools manpages actually sources part
  of the module and thus extracts documentation
  directly out of the code itself.


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

  Joe, I believe that this can be handled as
  described below, i.e. with a [proc] in the
  manpage, or better, by defining a subpackage
  of doctools which can be required by manpages
  which want to use this highlevel construct.

  IMHO this will give Bryan what he wants without
  having to extend the language or having to add
  a macro facility.


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

  I don't quite understand this. In the feature request for 
  the "macro" macro it was argued that allowing one to code 
  macros within a document was a Bad Thing. And yet this 
  discussion explicitly encourages it (via proc rather than 
  macro, but that's splitting a fine hair).

  I guess having a subpackage with the behavior would work, 
  but I don't see the point. What's the argument against 
  adding this feature to the toplevel doctools package?

  I guess my biggest concern is that someone down the line 
  might change the format of a definition list. Maybe add 
  blank lines between the list items, or add a bullet or 
  different coloring. That change will affect this sort of 
  markup when (arguably) it shouldn't. After all, this isn't 
  quite a bona fide definition list, IMHO. It's a specific, 
  unique construct that's been in tk man pages probably since 
  day one.

  What about instead of calling this a tk-specific feature we 
  add another type of list -- compact (eg: [list begin 
  compact]). This type would guarantee that each line is a 
  single physical line with no blank lines between items.


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

  Actually the hair is not that fine.

  The macro facility you would like to have
  places styles information (= translation
  of data into the output format, like HTML)
  into the manpage.

  Defining proc's in a manpage OTOH allows
  you to write format independent macros
  by using the doctools commands inside of
  the proc.

  I have to admit that I cannot prevent you
  from directly generating HTML statements,
  etc. but this is strongly discouraged. This
  is luckily also difficult to get right because
  the interpreter running the code for the
  manpage does _not_ know to which formatting
  engine it is currently connected to. IOW you
  don't know whether to generate HTML or NROFF
  in your proc.

  Node aside: Please attach the hacked fmt.html
  to this item. I would like to see if I can
  rewrite this using just doctools commands.


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

  After some out-of-band discussion by email we (Bryan,
  Joe and I) have come to the conclusion (at least I
  believe so) that this or a similar command should be
  added to doctolls, as part of the special option lists
  provided by TMML. This will bring doctools one step
  nearer to TMML.


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

  Ok, all the formats are now done and committed.
  Documentation is uptodate too.


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

  This is more of a documentation bug: The cwd is passed in,
  just not as an explicit argument. Just use [pwd] to get the
  cwd and you will see that the CWD is the cwd.


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

  Updated the documentation in the head, explaining how the
  cwd is passed in implicitly.


login: aku
mimetype: text/plain
icomment:
  Applied in revision [5e9d8b632f].
  Committed.
  Pushed.
  Thank you.
  And apologies for the long delay.

  Better fixes to consider:
  - Modify the S3::debug to subst its arguments only when debugging is active.
  - Replace S3::debug with use of the 'debug' package in Tcllib (which does defer argument expansion to when it is active).

  These might be moot, depending on the overall fate of the S3 module and packages.


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

  This patch is incomplete. The testcase profiler-5.1 fails, 
  because it expects a scalar 'enabled' and not an array.

  Working on this now. Always adapt and extend the testsuite 
  for new features too!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9808: p.diff

  Logged In: YES 
  user_id=75003

  Here is the new patch. It changes the version from 0.1 to 
  0.2 too.


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

  Historical note: The pages which have a struct_ prefix are the pages whose names without the prefix clash with manpages of either the core, or previously existing packages.

  I agree regarding the confusion. Given the clashes I noted I would propose to simply go forward with all manpages in the module having the 'struct_' prefix to eliminate the confusion.


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

  The fix has been committed to the head, two new tests have 
  been added to cover these cases.


login: wart
username: wart
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=244388

  Now that I take a closer look, this isn't entirely correct.

  aclocal.m4 contains a pointer to config/tcl.m4, which is not
  in the source tarball.  However, configure.in doesn't
  reference any macros that would be in tcl.m4, so aclocal.m4
  isn't even necessary and should be removed.

  configure.in does reference a 'config' subdirectory which
  does not exist.  This directory should either be added or
  configure.in should be modified so that it doesn't look for it.


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

  BWidget no longer uses autoconf, therefore there is no need
  for tcl.m4.


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


  P.S. OK... I could have sworn I tested my fix correctly, 
  but Wish now complains about the (obviously) missing curly 
  braces. The workaround should read:

      fconfigure $chan -translation { binary crlf }

  -- AH.


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

  Actually I cannot see a reason for the binary on the input 
  side either. It should be auto. I.e. lenient if the server 
  doesn't do the EOLs correctly. I'll have to query Scott 
  Redman about this, I guess.


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

  Scott's answer is that MS Exchange will not work without 
  the translation binary. Maybe this server expects LF only 
  for commands. Is there a way to identify MS Exchange 
  server, maybe through some string in their greeting ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9182: tcllib.3.diff

  Logged In: YES 
  user_id=75003

  Added a patch to fix this problem and also [443619] and 
  [443645]. The patch also fixes some unreported bugs 
  introduced by the change to a faster RETR: The fast code 
  does not EOL-translation on the incoming data and also does 
  not unstuff .-stuffed lines. Both is done now, courtesy of 
  [string map].

  Side note: Translation "binary" _is_ required, or we will 
  miscount the number of bytes read and try to read more than 
  the server is sending, hanging the command and thus the 
  calling script.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Wojciech, dear George,
  thank you for the bug report, patch, and succesful test (all on c.l.t).
  Unfortunately, here are no test cases (I would like to have easy demo scripts).

  I have sent two questions about the patch to Wojciech by private mail.
  He replayed, that he is not at home at the moment and it will take one week.
  It is the same for me, I will be on holiday the next week.

  Here are the questions and the preliminary answers:

  -- Q1 --
  > Sorry, question about your patch for BWidget Entry themed:
  >
  > Patch line 82:
  >
  > -    if { $chstate || $chfg || $chdfg || $chbg || $chdbg } {
  > +    if { [Widget::theme] && ($chstate || $chfg || $chdfg || $chbg ||
  > $chdbg) } {
  >
  > Isn't an inverted logic more appropriate ?
  > Thus:
  > +    if { ![Widget::theme] && ($chstate || $chfg || $chdfg || $chbg ||
  > $chdbg) } {
  >
  > Otherwise, "Widget::cget $path -disabledforeground" is executed two rows
  > below which should IMHO fail...

  -- A1 --
  It is a good point.

  I think I converted all the code without testing all possible paths -
  I originally did this for a product I am working on and I guess we
  never came across this issue.

  ---Q2---
  > Sorry, another question about your patch for BWidget Entry themed:
  >
  > Patch line 90:
  >
  > -            return [eval [linsert $larg 0 $path:cmd $cmd]]
  > +            return [uplevel 2 [linsert $larg 0 $path:cmd $cmd]]
  >
  > This should be a general optimisation, to evaluate the command in the
  > caller space. May you make any comments on this ?
  > Is this for error message purposes or what ?

  --A2--
  The issue was ttk specific I think - from what I remember ttk bindings call:

  $widget instate {...} {some script}

  which fails since instate is not invoked in proper level - i.e. you can do
  set bg [$widget cget -something]
  $widget instate {!background} {$widget configure -background $bg}
  (this is just a quick sample, but ttk events used instate, which crashed)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Answer from Wojciech by E-Mail:

  I found some time to doublecheck it today - you were right - it should
  be ![Widget::theme]. In my case it crashes if theme is set and state
  is set to disabled.


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

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


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

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

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

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


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

  Logged In: YES 
  user_id=75003

  Extended patch containing additional test.


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

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

  I guess this is possible, but requires support by the
  packages which look for accelerator packages. They basically
  need code looking for some magic signal which tells them not
  to look for accelerators, and then the testsuite can raise
  this magic signal.

  Otherwise the testsuite has to poke into the tested code,
  and modify it in some way. Dangerous. Difficult to Impossible.


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

  An idea in the same vein, actually more concrete than my
  last comment. And more general, hopefully. Have a small
  tcllib package containing runtime configuration options for
  all tcllib. The only configuration right now would be if
  'accelerator' packages are allowed or not, default is that
  they are allowed. The relevant packages using accelerators
  load the package and query this information before trying to
  an accelerator. The relevant testsuites load the package
  first, disallow accelerators and the packages under test
  then see this and don't load them.


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

  For packages which can use a compiled extension, the test
  suite should be testing all available implementations. The
  message digest packages (md4, md5, ripemd) all do this
  currently. So does uuencode and I need to check some others.
  So there is no option required I think.


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

  I believe we can close this, as we are testing all impl. for
  at least 90% of the users of accel pkgsby now.


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

  andreas - go ahead and make this change...

  thanks!

  /mtr

  ps: Beat - in future, a patch is always appreciated...


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

  The proposed fix is certainly the easy fix. So I will do it that way.
  Committed revision [b3b52828b9].


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

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

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


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

  The issue turns out to be this:

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

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

  Fixed by masking off the exposed bits.


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

  I've fixed this to make the '--' optional as an end of args
  marker and arranged the code to cope with data that has a
  leading hyphen. 
  So now both examples will be OK. Also
   md5::md5 -hex -- --  will hash the last --  too.

  Also done for md4.

  I havn't added it to the documentation as the -- is rather
  redundant now.


login: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The md5 package in Tcllib can use the binary package 'Trf' to accelerate its operations. For correct diagnosis of the problem it is necessary to know if the accelerator is used or not. To determine this please report the output of the each of the following commands:

     info loaded
     package ifneeded Trf [package present Trf]


login: mstrhh
username: mstrhh
mimetype: text/plain
icomment:
  % info loaded
  {/usr/share/tcl/lib/teapot/package/linux-glibc2.3-x86_64/lib/tcllibc0.3.4/Linux-x86_64/tcllibc.so Tcllibc}
  % package ifneeded Trf [package present Trf]
  package Trf is not present
  %


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Max, thank you for your help.

  The loaded tcllibc indicates that md5 is using the critcl-based md5c accelerator to perform all calculations. Which is also in Tcllib.

  The accelerator is written by Jean-Claude Wippler (JCW) per the notes in the comments. However overall author (integrating all pieces) is Pat Thoyts.

  I am re-assigning to Pat now for comments from him, and will also send a mail to JCW as well, to see how far his involvement went.


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

  We can now search within the text in the chat by entering
  "/?<regexp>"


login: 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: anonymous
mimetype: text/x-fossil-wiki
icomment:
  Search in the history exists and is documented as:

  <verbatim>
  Searching
  /?<text>	Search the chat buffer for matching text. Repeating the command will progress to the previous match
  /!	Clear the previous search result
  </verbatim>

  However I didn't find how to split the chat window, if the feature exists (which is apparently the case, see below comment from treincke)


login: ferrieux
username: ferrieux
mimetype: text/plain
icomment:
  The attached patch does two things:
  (1) completely remove the -peername since it is redundant with the given remote host and port. The behavior is now to always return an IP address instead of a name, but that also happens when rDNS fails, so it's not breaking compat.
  (2) move the -sockname on control connection, which is needed to get the IP of the proper network interface, inside the part specific to active mode. Thus, passive mode is now DNS-free.


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

  Hm. I just tried the current tcllib HEAD, tclsh 8.4.2, win 2k, 
  and have no errors at all (59 tests, all passed).

  I.e. I am unable to repro this


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

  Nothing will/can be done the 1.4 release except if we get a 
  reproducible test case. Modding down.


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

  Well something strange is going on then because with Windows
  2k and tcl 8.4.2 and tcl 8.3.5 I get 4 errors in ncgi-14.3 -
  ncgi-14.6

  I'm using "tclshXX.exe sak.tcl test ncgi" to run the tests.
  I have also tried this using two different machines with
  Win2K (although these have pretty much identical installations).

  With tclkitsh (tcl version 8.4.1) I get 15 failures but some
  of these are  to do with child tclkit's not picking up my
  extended auto_path.


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

  I tried again and I simply do not get these errors in my Win 
  2K box. Used a tclsh 8.4.2, and a tclsh 8.3.4, and ran the 
  tests via sak.tcl, like you. No errors.

  Pat, may I ask you to investigate deeper into this ? As you 
  get the failures and I don't you seem to be in the best place 
  to find the problem. ... This seems to be something in the 
  multipart scanner. Maybe EOL differences ? 


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

  Latest discussion was on the Tcl'ers chat.

  The file 'formdata.txt' is stored in the CVS with DOS line 
  endings, but not declared as binary. This is ok for a unix 
  client, as I used, but a Windows client (as used by Pat) will 
  convert the CR LF to CR CR LF, and that trips the tests 
  because the line endings are now bogus.

  The file has now been declared binary (-kb) and things are ok 
  on both unix and windows, the latter tested by Pat.


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

  Note: We do not seem to have test cases for asnTag/asnPeekTag regarding PRIVAT, nor CONTEXT either. Only UNIVERSAL and APPLICATION.


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

  I guess that this applies to graph and tree, but not the 
  others (queue, stack), right ?


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

  Note that the 'exists' method is currently used to check
  the existence of nodes (tree, graph) and arcs (graph).

  We have to find a different name.


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

  Yes, how about:

         graphName arc get arc ?-exists key?

  or -keyexists or something of that ilk.  I think 'get' is a
  reasonable place to put these subcommands.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10793: 460230.diff

  Logged In: YES 
  user_id=75003

  Ok, I created a new submethod 'keyexists' for tree nodes, 
  graph nodes and graph arcs. Attached the patch implementing 
  them, their documentation and additional testcases.


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

  You should use the newer statistics submodule instead.
  (Though it does not - yet - compute the coefficient of 
  variation ...)

  The situation you sketch is one where the coefficient is not 
  defined. The procedure should return a more descriptive 
  message ...


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

  Has something happened here ?
  The reference to 'statistics' seems to indicate that we can
  close this entry, no ? Maybe as 'out-of-date' ?


login: 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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you !
  Theming support in BWidget is only for migration purposes anyway.
  I have not tested this as I suppose, that ttk::combobox will be used instead.
  But anyway it is a bug to fix.
  I will come into this on monday.
  - Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed in csv by removing many options from Entry.
  In addition, disabled state is now visible in themed Entry

  Please update files entry.tcl and combobox.tcl

  I fear, the removal of so many options from Entry will cause many other things to break in themed mode. I did not check this to deeply.


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

  Fixed the 1.4 reference. The README will be done just before 
  release. The contents are such that a continuous update, i.e. 
  keeping in sync with the reality of the code is difficult.


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

   looked again and you need Trfcrypt, not Trf, I got confused
  by a switch-label. Trfcrypt does not come with ActiveTcl, so
  you are using the pure Tcl impl. of blowfish.
   
  I also note on further reading that the mode you are using
  is CBC aka Cipher Block Chaining. IIRC my crypto right this
  mode always operates on whole blocks, which are 64bit, aka 8
  byte
  for blowfish
  (http://en.wikipedia.org/wiki/Blowfish_%28cipher%29).
   
  This means that the padding done is correct. It likely
  actually is done to the input to make it a set of full blocks.
   
  Found some references:
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29
   
  And
  http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
  for methods padding which can be done before CBC is invoked
  and is exactly reversible. I do not know if the code in
  Tcllib uses any of these block padding schemes or is leaving
  that to the caller. I guess that it is the latter.
   
  Pat, I think we should add these wikipedia entries as
  references.
   
  I also grepped the manpage for information regarding padding
  and found none. IMHO this is a doc bug we should correct.
  This is one area where people can trip.
   


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

  Documented the padding a bit more explictly. Also added a
  -pad option to the blowfish command which can be used to
  turn off this padding feature (in which case you get an
  error if the data is not a multiple of the block size) + tests.


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

  Applying this patch to 1.4.0cvs fails with:

  lorax [~/cvs/tcllib/bwidget] 47 > wish8.3 demo/demo.tcl
  Error in startup script: invalid command 
  name ".mainframe.status.prg"
      while executing
  "$path cget $realopt"
      (procedure "Widget::cget" line 20)
      invoked from within
  "Widget::cget $path $option"
      (procedure "Widget::getoption" line 6)
      invoked from within
  "Widget::getoption $path -textvariable"
      (procedure "MainFrame::create" line 49)
      invoked from within
  "MainFrame::create .mainframe -menu {
          "&File" all file 0 {
              {command "E&xit" {} "Exit BWidget demo" {} -
  command exit}
          }
      ..."
      ("eval" body line 1)
      invoked from within
  "eval MainFrame::create $path $args"
      (procedure "MainFrame" line 1)
      invoked from within
  "MainFrame .mainframe -menu {
          "&File" all file 0 {
              {command "E&xit" {} "Exit BWidget demo" {} -
  command exit}
      invoked from within
  "MainFrame .mainframe  -menu         $descmenu  -
  textvariable Demo::status  -progressvar  Demo::prgindic"
      (procedure "Demo::create" line 35)
      invoked from within
  "Demo::create"
      (procedure "Demo::main" line 12)
      invoked from within
  "Demo::main"
      (file "demo/demo.tcl" line 209)

  Since there is already a -variable option for the 
  ProgressBar, it would seem easiest to just link to that 
  with an additional label.


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

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


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

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

  counter::histHtmlDisplayRow

  The package ncgi isn't required.


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

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

  Fixed in CVS head. Albeit after the 1.13 release. Missed this or saw and then forgot again. My apologies.


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

  Restrictions on node names: I am not aware of any. The testsuite actually uses node names which have spaces in them. 

  Instead 'elements ("strings")' I would prefer to say 'named elements', and the 'named' implies that strings are involved.

  Added a paragraph 'The element names can be arbitrary strings'. This should also enforce the information you wanted about elements and strings.

  I have taken and added your comparison to the documentation as is.


  Side question: Was the new section in the struct::tree manpage about where and how to give feedback useful for you ? 


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

  Is it intentional that the new Bugs section of the man pages do not show up in the generated (nroff at least) reference pages?


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

  Are you sure ? I did a 'sak doc nroff' on a small sample right now and I see the feedback sections. Are you looking at the right directory ? Please put  this into a new bug report. It has nothing to do with Lars' doc improvement of struct::tree. (Despite my side question).


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

  I think you can disregard that last comment. I'm seeing peculiar behavior by my man command here - I suspect the problem is bigger than tcllib man pages.

  What I am seeing in Sun's man command is occasionally missing sections, or parts of sections.

  No error msgs generated - stuff just isnt there _sometimes_ and is there later.

  Not fun.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  Re: Bug reporting section

  This hadn't (and still hasn't, I think) shown up on tcllib.sourceforge.net/doc, so I didn't use it. The info doesn't feel new to me, but I suppose the direct link might sometimes be useful (saving some clicks). OTOH, that's easily dwarfed by looking around the list of reported bugs to see if the one one has had already been reported.

  Re: Node name restrictions

  On lines 382-383 (description of [$tree insert]) it says:
  If names are specified they must neither contain whitespace nor colons (":").

  I can see the technical reason for the colon restriction (namespace hickups), but not for the spaces.


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

  Bug reporting: Yes, the doc thing is updated only every once in a while.

  Name restriction. Thanks for the reminder and reference. The limits should be gone, the comment might be old and out of date. The node names are keys into arrays, there should be no namespace interaction at all. I will check. I am quite sure that whitespace in node names is fine.


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

  Ok. Have checked. I believe you are using an older revision of "tree_tcl.tcl". The file found in the CVS head does not have 'neither whitespace nor colon' anywhere in it. The restriction may apply to the revision you have, but head revision definitely does not have it.


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

  Committed the changes I made. Just reopen this RFE if you have more comments.


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

  Wrong tracker. The tcltutorial is in the Tcl project, not in Tcllib.


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

  Is the tutorial part of this SF project, or part of the Tcl SF project? If the latter, then this bug report should be made over there.

  I agree that a category for the tutorial should be created where ever the tutorial is being maintained.


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

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


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

  http://support.microsoft.com/?id=819961 suggests it will be
  of the form http://servername:port/
  Elsewhere MS documentation says "ProxyServer  This entry
  specifies the URL and port number for the proxy server."

  However, if you fill in different servers for each proxy
  type in the Internet explorer settings you indeed get the
  above string. This is with IE6. Probably the same for other
  versions.

  I think it is safe to split the string using ; and we will
  want the proxy for the protocol desired - that may be http
  or https for autoproxy purposes.


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

  Added support for this to the autoproxy package. At this
  time we do not have sufficient information to differentiate
  between https and http at the point where we hook into the
  http package - therefore we always use the http proxy setting.

  The http package should be enhanced to support this -- but
  then the http package needs many enhancements and a general
  support for proxies is one part of that.


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

  Committed fix to CVS head (Using double() to explicitly cast the value).
  Bumped package version to 0.3.


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

  The "Diagrams" package was obsoleted by "diagram" (lowercase, no trailing 's').


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

  I have just checked CVS version 1.12 (15/Oct/2001) and under
  Windows I can copy text from the main chat window and paste
  it into the posting window.

  If this is still a problem, what platform? Or are you just
  after adding the menu items for these operations?


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

  ... This was some trouble I had with transfer of selection 
  between Win* and the X-server and then to the app. Closing 
  this request now.


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

  Yes, this is a bug: the problem is that the data are
  identical numbers. That becomes a problem in the
  determination of the variance (all basic statistical
  parameters are calculated, even with the mean proc):
  sometimes the result is a very small negative number and
  then taking the square root causes a domain error.

  The solution is to add the following lines:
        if { $var < 0.0 } {
           set var 0.0
        }
  in the if-block where the variance is determined (proc
  BasicStats).
  This is the corrected fragment:

  if { $number > 1 } {
        set var    [expr
  {($sumsq-$mean*$sum)/double($number-1)}]
        #
        # Take care of a rare situation: uniform data might
        # cause a tiny negative difference
        #
        if { $var < 0.0 } {
           set var 0.0
        }
        set stdev  [expr {sqrt($var)}]
     }

  I will submit an updated version plus an updated test script
  later


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

  Just committed the patches. 

  Can you let me know that this is indeed working? Then we can
  close the bug report 


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

  No response for nearly a month. Considering this as closed.
  Set to auto-close if no further response within 7 days.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  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: 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 have a tclsh 8.5 and can see what this is about. In the
  meantime use Tcl 8.4 to run sak and specify the shell to use
  for the testsuite itself using "test run -s SHELL ...".


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

  Uh. This seems to a something with the new 8.5 ensemble
  and/or namespace path stuff snit v2 uses.

  The constructor of tie::std::file has a call

       [file normalize $thepath]

  and this seems to be interpreted as call into the class or
  constructed instance now. In snit v1 this resolves to the
  global command.

  For now I will fix this using ::file, however I wonder if
  that is something which is a snit problem and not of the
  defined class.

  It is an incompat for sure.


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

  hm... perhaps i need to think before i type,
  the regexp should be more complicated to allow for cases of 
  %%W and %%%W which this one would break...


login: matzek
username: matzek
mimetype: text/plain
icomment:
  File Deleted - 200000: 



  File Added - 200122: new_conf_option.patch

  Logged In: YES 
  user_id=330806

  I am sorry. Had to replace the patch again, as the usage of
  AC_ARG_ENABLE was just wrong. Now triple checked...

  kind regards -- Matthias Kraft


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

  Hm, I will have to look into this one, but the result should indeed be a list of three long.


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

  There were several bugs in that piece of code - hidden because there was
  a bug in the boundaryValueSecondOrder procedure that used it in the 
  test too.

  It should be okay now (extended the test script with this example,
  but I realised later that I should include an example with varying
  numbers too)


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

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


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

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

  Fixed the problem - a missing factor "$factor" when
  adjusting the raw ranges. 

  Could you confirm that the values returned by determineScale
  are now correct?


login: bwallner
username: bwallner
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=318308

  The return values of determineScale seem to be correct.

  But the display of the scale in createBarchart seems to have
  a rounding problem. Instead of 0.0 I get ...1512313e-17.
  Example:
  package require Plotchart
  pack [canvas .c -background white]
  set dimScale [Plotchart::determineScale -1.07 -0.01]
  puts $dimScale
  set bc [Plotchart::createBarchart .c {f3d2 d3c2 h2h4}
  $dimScale 3]
  $bc plot 0 {-0.62 -0.67 -1.07} #000000
  $bc plot 1 {-0.64 -0.71 -1.01} #FFFFCC
  $bc plot 2 {-0.01 -0.01 -0.88} #00CCCC


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

  I will check this - it is simple to circumvent that problem
  and I thought I had done that ...


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

  Done, the code for drawing the numerical axes now treats
  labels near zero as a special case


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

  A pattern match on the attribute keys of a particular node is 
  now in the CVS head. Note: Due to other changes to the 
  attribute interfaces the version of struct jumped to the next 
  major version, i.e. "2.0".


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


  IMHO...

  Nothing to repair; this is
  not a bug.

  [namespace import] the
  ::math::linearalgebra::scale
  command into your namespace,
  not the global one.

  If you insist that you must
  import both commands into
  the same namespace then
  [rename] one of them.  This
  is name conflict resolution 101.


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

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

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


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

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


login: 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: 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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  A more standard way would be, I believe, to use [subst] internally, not [format]. That way we just have to change "..."-quoting to {...}-quoting  (and, of course, change the name of the log command).
  Alternatively, keep the name, i.e. "log", then this is a major API  change, forcing a major version change, i.e. 1.3 -> 2.

  The subst is certainly what wub's Debug package does. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Indeed, subst gives more power than format.

  format would be similar how the msgcat package handles things.


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

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


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

  Analyzing the problem ...
  The detection of incomplete data at the end of a string is
  ok.

  However a stored incomplete tag is never used in the next
  iteration. That is bad.

  Fixed in head.


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

  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: aku
mimetype: text/plain
icomment:
  From the description and location of the error this seems to be a duplicate of bug [eb0b15d598].

  Should be fixed now. See the above bug for the details.


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

  Please make it an "update idletasks" as opposed to just plain "update" -- it's safer


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed, but acceptable by design.

  It is better when updates are coded manually than within the BWidget library.
  Nevertheless update is necessary to evaluate the required widget sizes.

  It would be possible to add a hint in the scrollwindow documentation.


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

  Fixed in cvs head. Not sure if I got everything. One of the other bugs you reported seems to suggesst (implicitly) that we should add classes to list start/item/end as well. That I have not touched. Not yet done either is documentation for the class names in use in the output.


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

  This seems to cover at least the markup I've used so far. Great, thanks.

  I did notice that the [opt ...] macro doesn't output any HTML tags, just surrounds
  it's argument with ?...? pairs. Can this also have an HTML tag?

  So, this code:

    [opt [option "-maxrun [arg n]"]]


  Which results in this HTML:

    ?<b class='option'>-maxrun <i class='arg'>n</i></b>?


  Should instead produce this:

    <span class="opt">?<b class='option'>-maxrun <i class='arg'>n</i></b>?</span>


  i.e. wrap the whole thing in a span with CSS class opt.


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

  Re [opt]. Yeah, could be done. Question. Rockshox asked to add <div>'s around things. Now here you are saying <span>. What is the difference between both ? Or, in the concrete case of [opt], could a <div> be used instead of <span> ? how interchangeable are they ?


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

  A <div> is a block-level element. Like a <p> or <ul>, it begins a new line, and
  the content following it begins on a new line. A <span> is an inline element, like
  <b> and <i>.

  So in this case you need a span, because it needs to appear inline with the rest of
  the arguments and options.


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

  The cvs head of tcllib doctools should have class names for all the semantic markup now, and span where classes where not possible, so I am closing this one. If there are classes/ids/spans/divs missing please open a new bug for them specifically, or put the notice into http://sourceforge.net/tracker/index.php?func=detail&aid=1798427&group_id=12883&atid=112883, the general bug about HTML output and its styling (while it is open).


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: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok, I have to look into this. I am using safe slave interpreters to contain the plugins for the formatting backends, and maybe the setup of their package paths (*) is going haywire.

  (*) I am using the SafeBase for that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Note to self: Bisect using
  TCLTEST_OPTIONS='-match doctools-idx-50.0.1' ./sak.tcl test run -s /path/to/shell -l Y modules/doctools2idx

  Reason: Confirmed that 8.6b1.2 fails. Also found that 8.6b1.1 is ok. Some change in the core has caused this. Some change to the SafeBase most likely.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This is fixed in the Tcl 8.5 and 8.6 CVS head. An issue with the emulation of the [glob] command by the safe base. I.e. not a tcllib bug, just exposed by it.


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

  fileutil::findByPattern is based on fileutil::find and this command likely exhibits the same behavior. IIRC the basedir is 'normalized' and you get that back in the results. I.e. [file normalize /net/<machine>/export/disk1/...] is '/export/disk1/...'. IIRC (again) this is cross-platform behavior.

  There are efforts underway to redo fileutil::find to be more maintainable (currently we have about 3 or 4 variant implementations for win vs unix, Tcl 8.4+ vs Tcl 8.3- etc.). This report could be addressed as part of that work.


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

  Ok. Fixed with the recent rewrite of fileutil::find, and committed to CVS head.


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

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


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

  Logged In: YES 
  user_id=75003

  Patch updated to current tcllib, also changed to unix EOL 
  convention.


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

  Committed revision [214655747d]. Different varname however (SAK instead of xx).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 14680: latex.tgz

  Logged In: YES 
  user_id=75003

  Additional archive containing the changes for LaTeX output.


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

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

  Marshall ?

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

  Sorry that this did not get into the 1.6 release.


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

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


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

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

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

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


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

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


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

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


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

  Done. The new file is 'mime.bench'. The unstructured
  benchmarks have been removed now.


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

  How does this look, as a patch, in setValue?


  @@ -503,7 +503,15 @@
       if {![info exist value($key)]} {
          lappend varlist $key
       }
  -    set value($key) $valuelist
  +
  +    # This if statement is a workaround for another hack in
  +    # ncgi::value that treats multipart form data
  +    # differently.
  +    if {[string match multipart/* [ncgi::type]]} {
  +       set value($key) [list [list {} [join $valuelist]]]
  +    } else {
  +       set value($key) $valuelist
  +    }
       return ""
   }

  If I don't hear back shortly, I will commit.  This makes it
  pass the tests.


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

  kanryu6 applied this patch on 2009/04/17:

  @@ -194,7 +194,7 @@
              # but it may be 0.xxx
              string is double -failindex last $txt
              if {$last > 0} {
  -               set num [string range $txt 0 [expr {$last - 1}]]
  +        regexp -- {-?[\d\.]+([eE][\+-]?\d+)?} $txt num
                  set txt [string range $txt $last end]

                  switch -- $state {


login: aku
mimetype: text/plain
icomment:
  An early design choice by Ajuba.
  A weird one, given that they also created prodebug.

  A possible change would be to

    html::foreach -> each
    html::for     -> iter  (iterate)
    html::while   -> cloop (conditional loop)
    html::if      -> on    (on <condition> <body> ...)
    html::set     -> assign
    html::eval    -> do

  where `->` stands for `becomes`.

  Going that way is a major API change, requires version bump to 2.x.
  At that point we should go to Tcl 8.6 as well, I believe.


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

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


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


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

  V.Wartelle.


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

  You are quite right. I have corrected the procedure angle 
  and I have added a procedure crossproduct.

  Thanks for reporting this.

  The new files are in CVS


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

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


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

  passing along to rmax.

  You must be testing with Tcl 8.4.  This is a side-effect
  of the changing default usage message from Tcl 8.3 -> 8.4.

  I think there's some facility in the Tcl test suite for
  dealing with this.


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

  Note that testing against the Feb 19, 2002 version adds a
  new error:


  Module: sha1
  modules/sha1/sha1.test
  sha1 1.0.2 (pure Tcl)

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

          ::sha1::sha1 $msg
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-2.1 FAILED

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

          ::sha1::sha1 $msg
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-2.2 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.1 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.2 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.4 FAILED
  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.5 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.6 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.7 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.8 FAILED

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

          ::sha1::hmac $key $text
      
  ---- Result was:
  integer value too large to represent
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== sha1-3.9 FAILED


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

  Bugs in the sha1 package belong in another
  category.  Open another report.

  Actually, don't open another report.  This
  problem is already noted as Bug 446997.
  It's just that TIP 72 made all platforms
  into "64-bit platforms" so the bugginess of
  the sha1 package is now clear to all.

  Followups on this issue directed to Bug 446997.


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

  The line in question is an artifact of the udp support. It
  should have been removed. For tcp/37 connections we are not
  supposed to send anything but just await an answer. For
  udp/37 we have to send an empty packet first. Evidently
  FreeBSD's service is a bit on the strict side.

  I'll fix this so an empty packet is only sent if UDP is in use.


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

  With some testing it seems that the webpub server only
  responds to tcp connections. If you do a 
  set tok [time::gettime -protocol udp ntp.webpub.net]
  time::status $tok
  it returns 'error' and ::time::error $tok tells you it timed
  out.
  If you set the protocol to tcp then it's happy.

  UDP is used if you have tcludp installed. You can opt for
  tcp by using the -protocol switch.


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

  This got added /after/ today's declaration of a CVS being frozen? Still, it's good that it got in; I've been thinking about this the last couple of weeks, but also been too busy to get around to it.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The declaration also said 'If changes are needed before 1.12 is released coordinate with me.'.

  Which Aaron did, pinging me on the chat. I reviewed and decided to apply, i.e. decided hat I want to have this in 1.12. It was not Aaron going over my declaration.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This type of putting up an RC and freezing CVS before actually doing the release is mainly there to flush out all the people who have such last-minute stuff and sort of forgot that we are working on making a release. A last wakeup call. I definitely expected for stuff like this come out of the woodwork with my declaration.


login: 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: kjnash
username: kjnash
mimetype: text/plain
icomment:
  This bug was fixed at 1.2.5 or possibly earlier.  The results also show another bug, that in some cases uri::split interpreted the host as a path.  This bug is also fixed.


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


  I believe we can correct this problem with
  a substantial revision to mkIndex.tcl.


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

  Done. The new all-tcl installer handles this now correctly. See 
  devdoc/indexing.txt for discussion of options and chosen 
  solution.


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

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


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

  Notes, thoughts:

  The 'graph' structure has selection/filtering functionality => 
  See methods 'arcs' and 'nodes'.  Is limited to 'exact value of a 
  key' however.

  So this FR is actually two: Get filtering into tree at all, and 
  extend the filtering on exact value into other areas: glob, 
  regexp matching, arithmetic-relational matching (>, <, ...).
  Maybe easier to allow user-specified 'filter command' called 
  per node and decides what nodes to return ... Hm, this is 
  covered through walking ... Less efficient. Walk also does 
  specific order, filtering has no need for order ... so a special 
  filter method still makes sense. ...

  Complex filters (and, or, not conditions): Can be done through 
  set intersection, set union, set difference operations.


login: davidhbigelow
username: davidhbigelow
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=664837

  Whoops - I accidently re-requested this.  But as I read this, I 
  think it is still a worthy idea; please see the new example of 
  how this might work.

  Dave


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

  The new 'filter' extension to the 'children' command
  provides the desired functionality.


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

  Yes, this was enough info for me. The problem happened when
  I tried to extend the result, either by extending the last
  element, or adding a new chunk, for the case of chunks of
  type 'unchanged'. This was done incorrectly when this
  extension happened at the very beginning, i.e. for a still
  empty result.

  Committed a fix.


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

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

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


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

  This seems to be a duplicate of

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

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


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


  With Tcl 8.5 HEAD, these now fail
  in a different way:

  syntax error in expression " $msg == Infinity ": extra
  tokens at end of expression


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 242204: tsrsplit.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  Attaching a quick hack I made quite some time ago for regular tcltest logfiles, 'tsrsplit.tcl'. That one was for getting expected/is output for use with tkdiff.
  File Added: tsrsplit.tcl


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

  Are there log files generated when I do a normal make test? If so, where? All I was aware of was the "fancy" output that was displayed.

  Would the attached script be appropriate to add in the tcllib distribution?


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

  Attached script in tcllib - not yet. It was a quick hack, not very polished, and only useful in combination with other commands, like tkdiff or eskil, i.e. lots of manual work still. It is semi-related, as it also processes test output.

  log files via 'make test'. The CVS head got some changes to 'make test': 'make test_interactive' -> fancy output, 'make test_batch' -> detailed output. 'make test' now chooses automatically. Fancy normally, and when redirected to a file it does the detailed log.


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

  Fixed in cvs head. Note that IMHO The * belongs to the Ns_Sls, not the 'sls'. I.e. it should be part of the type, not the function.


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

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


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

  Converted and committed (See bottom of tests/faop_regex.test). Note: T'was a bit difficult to copy the code out the report, well, and then fixing the broken lines to get back usable Tcl. Please _attach_ examples and such as a file next time.


login: kjnash
username: kjnash
mimetype: text/plain
icomment:
  This bug was fixed a while ago.

  % info patchlevel
  8.5.19
  % package require uri
  1.2.6
  % uri::split host.td
  fragment {} port {} path {} scheme http host host.td query {} pwd {} user {}
  % uri::split http://host.td
  fragment {} port {} path {} scheme http host host.td query {} pwd {} user {}
  % uri::split host.td ftp
  port {} path {} scheme ftp host host.td type {} user {} pwd {}
  % uri::split ftp://host.td
  port {} path {} scheme ftp host host.td type {} user {} pwd {}


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

  1. Fixed
  2. Fixed
  3. The problem is the . starting the '.btn'. Having this as first character on the line causes the roff formatter to interpret it as a command. A command it does not understand. It apparently simply drops the whole line. Fixed by indenting the example, i.e. working around the problem. Better would be to fix the doctools nroff formatter to somehow quote a leading '.' in plain text to prevent interpretation as a roff-command.
  4. Fixed.
  5. See explanation for 3. Same fix.
  6. Actually the two examples are different. The first one demonstrates instance destruction (spot destroy), the second type-destruction (dog destroy). It might be beneficial to put both examples together into at the end of the block.

  I am leaving the decision regarding item 6 to Will. The others the pure typos and such and have been fixed in the CVS head now.


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

  Thanks. I have to ask 'how quick' ? The testsuite is failure
  free for 8.4, the main release of the core, and the plan was
  to go final this evening (Monday Oct 2). I could move that
  one, at most two days, but no longer, as I want to have GA
  well before the conference.


login: jfontain
username: jfontain
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=376942

  I don't think I'll be done in 2 days, maybe, but not for
  sure... Sorry.


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

  I expected that answer ... Ok, if you manage we can put into
  the release, otherwise it has to wait for the next, and I
  hope that you will not min that. As it affects only the 8.5
  alpha it can be considered as relatively low-priority. On
  the other hand, several tcllib math failures uncovered bugs
  in the rewritten Tcl 8.5 number handling, so we should not
  leave it uninvestigated.


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

  Thanks Jean-Luc for the quick investigation and work. I saw
  your commit and tested it, the testcase is not failing
  anymore. I will now close the report.


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

  Note that for HTML the CVS head contains a revamp of the backend which marks all the pieces in the output with lots of class/id tags keeping the semantic information. Making it possible to change the visual style of the lot via CSS. Output contain an embedded default CSS style I mainly lifted from the TMML/HTML output. The embedded style is suppressed if you define your own via engine parameters (-style option of dtplite, or -meta option of dtp).

  For LaTeX it might more sense to allow the specification of a latex-style through an engine parameter and have it define the formatting of examples. With default formatting embedded as definitions at the top if no style is specified.

  Would that serve?


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=938835
  Originator: YES

  No, I don't see how that would serve. I'm not after changing the formatting of existing markup commands, but want an additional markup command, for expressing a variation not covered by the existing ones.

  The concrete example which made me file this RFE is that I wanted to document the default for an option as being the regular expression [[:graph:] ]. No markup for the RE at all looks wrong (at least in HTML, and probably also in LaTeX), but this is not an [arg], [class], [cmd], [file], [fun], [method], [namespace], [option], [package], [syscmd], [type], [uri], [var], or [widget]. It /might/ be considered a [const], but I don't think it fits well under that heading either. It's simply a string, which happens to have very technical interpretation.

  Making an [example] out of it would be to overemphasize it.

  If you insist on all markup being semantic, then some kind of generic markup command might be the way to go, e.g.

    [string regexp {[[:graph:] ]}]

  so that [cmd whatever] is equivalent to [string command whatever], [option whatever] is equivalent to [string option whatever], [arg whatever] is equivalent to [string variable whatever], etc. Then there wouldn't be an immediate need to request another markup command as soon as someone encounters an object that doesn't match the standard set.


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

  > I [...] want an additional markup command,
  > for expressing a variation not covered by
  > the existing ones.

  Ok. Now I understand the request.
  It is orthogonal to the 'macro' request. The macro request is extending the markup language by composing existing stuff into larger pieces and naming these, and this request is for extending the language by adding a new semantic category specifically, or allowing the writer to extend the language by defining new categories (generic markup command). Where the problem with the latter is that it is not at all clear how backends can treat such a generic markup.

  Thank you for the clarification, and I will mediate more about this and your other requests in the next days.


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

  Per the ChangeLog this was fixed in CVS on March 9, 2008 by Michael Schlenker.
  Package version (since Mar 22, 2008) is 0.2, containing this fix.


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

  This can be done with the logger package with a custom logproc that uplevels, look at the examples at the end of the manpage:
  http://tcllib.sourceforge.net/doc/logger.html


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

  I got very troubled from the response. the pervious bug 
  mentioned was fixed in the days of the tcllib1.3 we are now 
  in tcllib1.8 and the bug is still there!!!! this means that 
  the bug fix is not in the head version and therfore is 
  still open


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

  The bug was closed in July 2006, so the fix is only inside
  CVS currently, not in a released version. CVS HEAD is not
  equivalent to the latest released version...

  Take a look at ncgi.tcl in CVS and the nvlist proc, it does
  not contain a regexp anymore.... 

  So this is really closed.


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

  I checked as well and can confirm Michael's findings. The
  unreleased code we have in the CVS really is without RE's in
  nvlist.


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

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

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


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

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


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

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

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

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

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


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

  This is a bug in the ftpd package: it's generating an
  incorrectly formatted multi-line reply.

  I've update ftpd.tcl (r1.11 -> r1.12) as above to generate a
  single-line reply.
  (This may not be entirely correct, as '$f' may itself
  contain newlines, but it fixes the immediate problem.)

  According to RFC959 section 4.2 "FTP Replies", multi-line
  replies must be indicated with a hyphen after the status
  code, and the last line of the reply must begin with the
  status code followed by a space, e.g.:

  puts $sock "500-Copy failed:\n$path\n$f\n500 blah."


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

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

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


login: dejavo
username: dejavo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=57232

  If you want a temp work arround
  I use ::List and get lindex 7 which is the time thingy just
  before
  the filename/dirname starts then i do split to the whole line
  and use lsearch to find its new place then i do lrange from
  its place+1
  to the end of the line and use the join command.
  Now I have the filename / dirname only without the other params.
  I also do string range to the first char if its "d" then its
  a directory.


login: oliversix
username: oliversix
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1091745

  Hi,

  the reason for this behaviour is the line
  return [ lsort $ftp(List) ]
  near the end of ::ftp::NList. I changed this to
  return [ lsort [ split $ftp(List) \n ] ]
  an it works perfectly.

  Bye Oliver


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

  Urgh. 3yrs old, and a solution for a year as well.
  See also 1553919, and 1563137. The latter has
  basically the same solution.
  Accepted, and committed.


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

  I have asked Salvatore Sanfilippo, who wrote this package to
  look into these problems


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

  I ought to add the proposed tests (mind you: bit operations 
  are not my cup-of-tea - I will need some help on the 
  correct outcome or can I rely on the bit operations in Tcl 
  for ordinary integers?


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

  Rely on the ordinary operations how ?
  They do work correctly assuming that the Tcl integers are
  limited-precision (32 or 64 bit). In 8.5 they are themselves
  extended for bignums. ... That may mean that you can use 8.5
  regular ops to determine what results the tests should
  expect. Kevin might be able to help you with that.


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

  I made a correction to the rshift proc (not the rshiftBits 
  proc that it uses, as that is used in more than one place). 
  The idea for the test cases is to reproduce the results of 
  Tcl's expr for those integers that can be represented by 
  ordinary integers and by bignum.


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  I was looking for something more limited, but a subset of
  this. I find the width of the log's lines more than
  necessary.  I would like to be able to set the time format
  to be "%D %T" instead of the current default clock format.

  This can currently be done by using logproc to overwrite
  existing logprocs, or by cheating and replacing stdoutcmd
  and stderrcmd (which look to me like they should be
  refactored, since they do the same thing except for the
  channel).


login: escargo
username: escargo
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=69099

  One other element that I forgot; right now the log file is
  actually determined by the standard handles for stdout and
  stderr. It would nice if the file handles for different
  levels could be configured. Again, the logproc is sufficient
  to override this, but that's something that must be customized.

  The current definition of logproc does not say what
  namespace the command to execute must exist in.  While there
  is a sample replacement proc, there is no example  logproc
  command to use it. So, would it be ${log}::logproc notice
  ::logtoserver
  ?


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

  I have started the integration into the uri module.

  Currently I miss examples I could use to extend the
  testsuite.


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

  I have integrated the new code into the uri module.
  I would like to extend the testsuite as well, but
  lack examples I could use to so.

  Are the qoute, unqote commands URN specific or
  could they be used to un/quote ftp/http/file urls
  as well ?

  If not, what about a generic un/quote command
  which dispatches to to schema-specific routines
  (like we already do for split/join) ?


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

  I made small change to your code to make it work correctly. 
  I moved the uri code to compute schemePattern and various 
  maps into a procedure and have your code call that 
  procedure so that this information in the overall package 
  stays uptodate.

  Future: Introduce an official command to register new 
  schemas and have that command recompute this information. 
  This would also allow us to move the various predefined 
  schemas into their own files and thus make the central 
  package lighter.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  File Added - 11986: urn.test

  Logged In: YES 
  user_id=202636

  OK Here is a test suite as per the RFC (I hope). I noticed
  that some of the tests fail my original code so I'm
  uploading a new version of the urn extension so that you can
  examine the differences.

  The quote/unquote code just implements the quoting rules
  described in the RFC. How relevant this might be to other
  URL schemes I am not sure but I imagine the only differences
  are in the characters that are required to be quoted or not
  quoted.


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

  New code added to head. Also base module rewritten to make
  addition of future sub-packages easier. See new exported
  command "uri::register". New code rewritten to use
  "uri::register".


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

  This is actually a little bit more complicated than adding a
  foreach - what needs to be decided is how tclish this
  command should be, as opposed to behaving exactly like cat.
   For instance, the real cat, even if it is fed a
  non-existant file, cats all the preceding files, and then
  errors out.  Since tcl can only return once... you can't
  really distinguish like that.

  I think the best thing is probably the simple, foreach
  implementation, but it's worth thinking about for a minute
  or two.


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

  David committed changes to head on 2003-11-15 after a short
  conversation on the chat.


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

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


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

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


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

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


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

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

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


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

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


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

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


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

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


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=128673

  I double-submitted by mistake.  Please close this record and
  refer to previous.  Sorry.


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

  This is not a bug, but a request for enhancement. I am
  rejecting this request as featuritis we should avoid. It is
  easier and simpler, IMHO to simply negate the condition in
  the used filter command. I should also mention that I
  believe that the number of options lsearch has is already
  way to high, i.e. it makes a bad example to convince me.


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

  tcllib 1.4 was released 2003-05-06 and inifile was not added
  until 2003-06-01. it will be in the next version. until then
  it is available from the cvs repository.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I printed the values of ln_Gamma(a+1), ln_Gamma(a), ln_Gamma(b) and the constituent terms term1 and term2 (on Windows XP). The problem is very likely caused in the case:

  a, b = 1000, 1

  a very uncommon distribution, however the test case should be dealt with properly.

  The terms term1 and term2 turn out to be 6.216 and -803.11. So the script is trying
  to take the exponent of -797 (approximately). We should change the expression
  to:

  set t [expr {$term1+$term2}]
  if { abs($t) < 200 } {
     return [expr {exp($t)}]
  } else {
    return 0.0
  }

  (This is a rather safe limit: exp(-200) is roughly 1.0e-87 - and the smallest number that
  can be represented is exp(-744) = 5.0e-324)

  I will fix this


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks. Please do not forget to bump the version number of the package as well. Bugfix => patchlevel.


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

  This is a problem for Pat. He maintains the md5 critcl
  stuff, and has possibly integrated it into smtp. It might
  also be a problem in the md5 package itself.


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

  Does this still happen with the current CVS head of Tcllib ?

  The only place I can think of where this can happend is the
  procedure "md5_init" in smtp.tcl. Can you check that this
  procedure is executed ? It does a regular "package require
  md5". Was md5 loaded before ? If yes, what version. If not,
  then we are likely getting v2, which is in md5/md5x.tcl, and
  it tries to load md5c in md5::LoadAccelerator. However this
  procedure catches any error from that, so you should never
  see the 'no package md5c' error.

  This part is however something which was rewritten some time
  ago, so maybe the old way of looking for md5c did fail.

  Hence my question at the beginning.


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

  I'm going to junk this. I've never seen this occur and there
  have been no other similar reports
  Also, I'm just removing all the authentication code from
  smtp.tcl and replacing it with code that delegates to the
  SASL package for this purpose.


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

  Sorry forgot to include version number.

  tcllib-1.7

  I believe the solution should/would be to have the Makefile
  install target pass the ${prefix} and ${exec-prefix} to the
  install.tcl script

  Instead, it appears to be taking the name of the tclsh program.

  Thanks.


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

  Reassigning to Michael Schlenker, AFAIK he was the last to
  touch this code as part of his ASN work.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the feed-back.
  The version with the wrong version number was around one hour online, sorry for that. I suppose, it is already fixed so no action needed here.
  Andreas wrote, that the correct version is on teapot.

  Sorry,
  Harald


login: aku
mimetype: text/plain
icomment:
  Added 303 to the set of status codes returning a location error.
  Revision: [f5f8b6a8ec]
  If a different error is wanted, or a different way of handling
  please re-open and specify 'understand' more exactly.


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

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


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

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

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

      mime::finalize $tok
   }

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

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


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

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

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


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

  I have tried the following on a windows computer with two screens on tcl 8.4.18 and 8.5.7:

  pack [ComboBox .c -values {1 2}]

  Move the window (with the mouse) on screen one or two and open the drop-down box.

  It worked as it should.

  I will set the state to pending. I have no Mac and I suppose it is a Mac issue of Tcl (and not BWidget).
  I would appreciate if someone could check further.

  Thank you,
  Harald


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

  Applied to the cvs head, and committed. Updated the
  documentation for getbody as well.


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

  Fixed this issue - scalars were treated separately so that [dim] could report the correct dimension, but that special casing was used for row vecotrs as well.


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

  This is still true today for question mark (mime version 1.5.2). Since question mark is part of the delimiter used in the subject content (=? and ?=) of a mime message, it causes error at decode time on client side.


login: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  Fixed in [339212df6ab5a86b], except that an encoded word is still limited to 75 characters because that's what [https://tools.ietf.org/html/rfc2047|RFC 2047] specifies.


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

  The console show/puts commands are already gone - they were indeed way out of place, 
  except for debugging purposes ;).

  The -scale option is more serious: I will look into this. Thanks for reporting it.


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

  I have been looking into this:
  - The fix you suggest solves the immediate syntactical problem
  - The scale values for the axis remain unchanged though - you get the same axis back.
  - When I fixed that bit, I got strange results (the wrong range, only a part of the labels I 
    expected drawn).
  - The code as it is is too naive: I need to change a few private variables in the scaling array 
    as well (they hold the transformation from world coordinates to pixels)


login: arjenmarkus
mimetype: text/plain
icomment:
  The error has been solved, but the effect is not quite what one would expect: the axis is not completely redefined. This needs to be investigated.


login: aku
mimetype: text/html
icomment:
  Please follow the same bug in the tklib tracker.
  See https://core.tcl.tk/tklib/tktview?name=1903306fff


login: cwjolly
username: cwjolly
mimetype: text/plain
icomment:
  Sorry I should have included the prior Bug # searching for it was not as obvious as I had thought. 
  Here it is : 3147481


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

  Thank you. I am closing this one as a duplicate then, and handle the changes under the original report.


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

  CVS version of configure.in was updated a while ago.  No
  idea why this case hasn't been closed yet.


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

  This is also fixed in the CVS Head of Tcllib. installer.tcl,
  line 167ff


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

  It's an endian-ness thing. Have to find a way to determine
  the byte order in the pre-processor.


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

  Added code to set the byte order macro. Tested with gcc and
  msvc on Windows and gcc on SunOS-sparc, OpenBSD-x86 and
  Linux-x86. Should be ok everywhere as we use tcl's idea of
  the byte order.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 16294: mdist.diff

  Logged In: YES 
  user_id=75003

  The problem is that the release process as documented in 
  the DOC section of this project is currently not in sync 
  with what is done by 'make dist' as misses some important 
  parts. But the script "mkInstallScripts.tcl" generates 
  installation scripts for use with an archive generated 
  by 'make dist' and not the release process.

  Unfortunately 'make dist' is not without problems either 
  (it does not take the examples into account).

  Enlosed is now a patch which reworks the target 'make dist' 
  so that it generates archives which contains both modules 
  and examples (= where the directory structure is 
  essentially a reduced variant of the raw directory 
  structure instead of something completely different as 
  currently, i.e. before this patch), wehere the generated 
  install scripts are updated to deal with the new directory 
  structure.

  After application of this patch the release process is much 
  simpler:

  * Get tcllib from the tcllib CVS
  * Get config from the tclpro CVS
  * configure tcllib
  * make dist
  * Upload the generated archives.

  Asssigned for Bob Techentin for review.

  Bob, if this patch is ok IMHO we should regenerate the 1.1 
  archives too to fix the problem they currently have. Maybe 
  even only the installation scripts in them.


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

  Is adding a [catch] around the failing unset statement 
  sufficient to make the problem go away ?

  (The ftp code we have inherited here is very convoluted and I 
  am trying to get away with a change as minimal as possible).


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

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


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

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


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

  Hm. I am quite sure that I would not use a report object to
  convert a matrix to csv. That can be done much more
  directly. Get all cells of the matrix, which is a list of
  lists, then iterate over the outer list and use csv::join to
  generate the csv lines, [join] them. ... I better pack that
  into a utility procedure.

  Are there any other use cases there a report with a
  right-ragged column makes sense ?


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

  proc ::csv::joinmatrix {matrix} {
      set csv {}
      foreach line [$matrix get rect 0 0 end end] {
  lappend csv [joinlist $line]
      }
      return [join $csv \n]
  }


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

  Oops. I was to quick, buggy. It is much simpler.

  proc ::csv::joinmatrix {matrix} {
      return [joinlist [$matrix get rect 0 0 end end]]
  }


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Does  a good usecase exist for an empty servicename?

  If not, i would simply document that servicename may not be empty and add a check for that. Otherwise some more work is needed to enable empty names.


login: heinrichmartin
username: heinrichmartin
mimetype: text/plain
icomment:
  I would have considered the root service the default for all other ones. This seems easier than many non-empty roots...
  A message usecase might be during cmdline param checks.
  Any workaround like "logger::init _" does not provide inheritance.

  But I see, that it might be much more work.
  Preventing the infinite loop should be the primary goal :-)


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

  Added some new tests and a new error code for this.

  Empty names or names that are just : or ::: etc. now raise an error on init.

  The idea of a global logger to ease the setup is surely a good thing, but using the empty logger for that would be a little difficult with the current style.


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

  This looks like Tcl bug #1220058.  It has to do with having a rename trace 
  on a namespace ensemble that gets renamed out of existence.  This 
  should be transferred over to the Tcl bug tracker rather than the Tcllib bug 
  tracker.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  The problem is not that the extra points introduced for an already closed polygon get in the way, but the specific choice of the "point far away". The round coordinates I chose for my
  test case make the point intersect two sides at the vertices. 

  This is a corner case that needs to be solved!


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

  Apart from a bug in this script ($b}] should be $b]), there
  was a genuine error in the leastSquaresSVD routine. This has
  been solved - see the CVS repository.

  Added this as a test case


login: aku
mimetype: text/plain
icomment:
  I agree that \n\r is a typo for \r\n.
  There is no EOL format using \n\r I am ware of.
  \r\n = Windows
  \n = Unix
  \r = MacOS 9

  The fix looks good as well.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [3bc09ccbec].
  Bumped package version 1.4.1
  Committed.
  Pushed.
  Thanks for the ping and the patch.


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

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

  Here's the entry in the changelog

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

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


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

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


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

  The math::bigfloat::todouble procedure made use of tcl_precision to compute the number of significant digits.
  It used to be 12 or more in Tcl 8.4, but Tcl 8.5 made it invalid and defaults to 0, which I knew.
  I simply added a test to make use of 16 when tcl_precision is 0, and it will work fine.


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

  Please attach the result of package require ldap, so i know
  which ldap version your working with (must be a recent CVS
  checkout).


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

  Do other large searches work? The search interface and the
  underlying structures changed quite a bit, so there may be
  some more bugs lurking...


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

  Ok, i can reproduce the error.

  The ldap code had a wrong calculation for missing length
  bytes and broke when it got a long response like the
  subschema query.


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

  This is fixed in CVS now, get package version 1.6.2 , along
  with some other bugs in the info subcommand.


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

  Since there is no -disabledbackground option for tablelist widgets, a disabled tablelist uses the normal background color at widget, column, row, and cell levels.  This is implemented with the aid of a text widget tag.  Under some circumstances, parts of the body text widget might lose this tag, thus giving rise to the erroneous behavior reported by Ralf.

  I have checked in a corrected version of the distribution file tablelistUtil.tcl.  This should fix the bug.


login: mrose
username: mrose
mimetype: text/plain
icomment:
  File Added - 21740: diff-u

  Logged In: YES 
  user_id=24077

  andreas - apply this "diff -u" to resolve this.


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

  Rewrote the README to describe the new way of adding 
  modules. Committed to CVS head.


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

  I don't believe this is a bug. Headers are allowed to be repeated, such as for "Received" headers. Putting "Received" in a list and other headers not in a list would require the mime package and the user to know every possible header, and it would require everyone knowing that a header that appears only once might in other messages appear multiple times. If you expect only one instance of a header in your message, just access the zero'th element of the list returned.


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

  I do still think, that this is a bug!

  The Content-Id inside a "header" of a message part must be a real identifier!
  There is only one Content-Id per message part, or the message is mal formed!

  So the Content-ID should not be a list.

  I think from my own experience, that there is some addition quoting/bracing because of the "$" inside the Content-ID.
  If this is needed during parsing the message part ... ok.
  But returning the additionally braced value is ... not ok and unexpected, because of the intention of this value, the Content-ID.

  Good morning from Berlin/Germany,

  Marti


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

  There are many headers that are only supposed to appear once, and many that may appear multiple times. There's no easy way to provide a list of all headers that should only appear once and all headers that may appear multiple times. Now that you know why it happens, why not simply take [lindex ... 0] of any header that your code expects to appear only once? Or, alternately, check that the list length is indeed only 1, and provide an error message if you are given a malformed message?


login: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  As of [5006be5e6a3d2ccd] <code>::mime::getheader</code>  returns a dictionary of headers, where keys may be redundant.  This eliminates the list behaviour described in this ticket.  By the same token, when a key is provided, a list of matching headers is still returned.  This variety of behaviours should be enough to satisfy both needs while remaining sufficiently convenient to use.


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

  I found the reason for the behaviour. csv::split internally uses 
  regular expressions for its parsing, and | is a special 
  character for the regex engine. So is + for example, or *. 
  These characters fail too (extended the testsuite and tried 
  many separator characters). The sep char has to be 
  protected from special interpretation.

  Fixed in CVS head.


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

  This is a problem with BWidget itself and not the ActiveTcl 
  distribution. The procedure is missing in 'color.tcl' as 
  downloaded from SourceForge.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9384: bwidget.449276.diff

  Logged In: YES 
  user_id=75003

  Added patch fixing the problem.


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: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  According to the specification, addresses are separated by "," (comma).  An MUA would be well-advised to do the same.


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

  Its the various set statements. If the given variable exists
  in the global namespace then that is set. Remember that
  namespace name resolution looks at the current namespace and
  the global namespace only.

  The fix is to use variable everywhere -- this passes the
  test suite and doesn't affect existing global variables.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  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: aku
mimetype: text/plain
icomment:
  Definitely out of date.

  The problem on the wiki page was for aes 1.0.0 and
  Larry's code showed that it was already fixed with 1.0.1

  By now we are at 1.2.1.


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

  This demonstrates the problem:

  % package require struct::tree
  2.0

  % struct::tree
  ::tree1

  % tree1 children root filter puts
  invalid command name "::struct::list"


  Whereas this works:

  % package require struct::tree
  2.0

  % package require struct::list
  1.4

  % struct::tree
  ::tree1

  % tree1 children root filter puts
  % 


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

  Note: If you use the option to get _all_ children, i.e.
  -all, you will also need struct::list.

  Ditto for method "descendants".

  Another alternative is to simply make all of struct::tree
  dependent on struct::list ?


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

  More: Graph has the same problem, for the methods "arcs",
  and "nodes".


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

  Yes, sure, package require in global scope would work.

  It'd make the dependency clear at the top, too, which is good.

  Putting it close to the use point is probably an unwarranted
  micro-optimisation, wouldn't save much, and isn't very
  idiomatic from what I've seen of tcl common usage.

  So by all means, package require struct::list at the top.


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

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


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

  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: 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: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Could you please provide the exact Tablelist version?  The official tklib5.0 release includes Tablelist 10.0.1, but I am not sure you refer to the *initial* tklib version 5.0, because that is already nearly two years old.

  This bug was present in some earlier Tablelist releases, but was fixed in version 4.7.  Unfortunately, it appeared again in Tablelist 5.0, but was fixed in the most recent version 5.2.  For this reason, please run your script with Tablelist 5.2 and let me know whether it still exhibits the problem (it shouldn't).


login: tombert
username: tombert
mimetype: text/plain
icomment:
  The package index tells 4.10.1
  I've checked the CVS sources now ... there have been a lot of changes. My problem was only that I wanted to get a tagged version. So my question: Is it safe to take the latest CVS source?
  thx


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  The latest CVS source is identical to the one contained in the most recent Tablelist version 5.2 (see www.nemethi.de).

  I am somewhat surprised to hear that you found this bug in Tablelist 4.10.1.  Could you provide a simple script helping me to reproduce the problem?

  Also: Does your script behave as expected when using Tablelist 5.2?


login: tombert
username: tombert
mimetype: text/plain
icomment:
  I was adding a second row to my table while hovering with the mouse over it ... maybe it's related to the tooltip I'am using ... I'am using it without a problem for a year now and can't reproduce - so I only had a look into the code and made a few assumptions ...


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  A closer look at the body of the tablelist::addActiveTag proc in the distribution file tablelistBind.tcl reveals that in this case findTabs does assign a valid value to both arguments tabIdx1 and tabIdx2.  Actually, the additional condition making this sure is that data(dispId) doesn't exist (i.e., that all newly inserted rows have already been displayed).  This is, however, checked in tablelistWidget.tcl, before invoking the addActiveTag procedure.


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

  I just checked:

  duron:~/src/xfermail:306> tclsh
  % package require pop3
  1.2
  % 

  This looks like the old bug you referenced.


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

  Yep. 1.2 is old. The current version is pop 1.5
  in tcllib 1.1. Please check if this version exhibits
  the same error.


login: edesio
username: edesio
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=147018

  Where can I download tcllib 1.1? I couldn't find it in
  sourceforge nor in activestate.


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

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


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

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

  You may want to pull and validate the fix.


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

  Tcllib does not contain an "http" package.
  There are "html" and "htmlparse".

  And the "autoproxy" package in the http subdirectory.

  ... Ok. The 'Bugs' Tracker had category 'http :: autoproxy', but none of the others.
  This is now fixed.


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

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


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: 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: 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: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  The functionality to suppert upper or lower case accelerators was added in BWidget 1.9.7. I am not shure, if it was this patch which was accepted.

  Thank you,
  Harald


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

  Minimum Tcl version 8.3 (we require the mime package and
  it's minimum version is 8.3).


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

  Thanks, and that's fine for now.

  For future reference, though, you should
  use [package require Tcl $version] to 
  record the Tcl needs of the code in your
  package only.  Trying to chase down the
  needs of the packages you depend on
  (and the packages those pacakges depend on...)
  is an unsustainable maintenance nightmare.
  Let each package take care of its own
  requirements for itself.  That's the
  modular solution.

  Indeed that's the reason I've regsitered these
  bugs in the first place, so that smtpd will
  take care of its own dependencies, so that
  every user of the smtpd package out there
  will not have to.


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

  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:
  The issue was the see method, which showed only the text and not an eventual present icon or window.
  The attached fix resolves the issue.


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

  DES operates on 64 bit blocks -- your 6 bytes of data has
  been padded with nulls to 64 bits. If this matters to you
  you will have to handle the padding protocol yourself.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed
  variable  - modules/virtchannel_base
  string    - modules/virtchannel_base
  zlib      - modules/virtchannel_transform
  coroutine - modules/coroutine

  The standard way of fixing things is add the prefix "tcllib_" to the manpages in question.
  (We already have several others so fixed).


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

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

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

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

  I strongly advise against this feature.

  Reassigning to Joe English for a second opinion.


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

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

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

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

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

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

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


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

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

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


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

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

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


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

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

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


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

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


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

  I have fixed this by modifying the NoteBook::_draw_page 
  procedure in the notebook.tcl file.

  Instead of this:

      if { $data(select) != $page } {
  # Non-selected pages have tabs 2 pixels lower than 
  the selected one
  incr top 2
  if { $pos == 0 } {
      # The leftmost page is a special case -- it is 
  drawn with its
      # tab a little indented.  To achieve this, we 
  incr xd.  We also
      # decr textOffsetX, so that the text doesn't 
  move left/right.
      incr xd 2

      incr textOffsetX -2
  }
      } 

  Do this:

      if { $data(select) != $page } {
  if { $pos == 0 } {
      # The leftmost page is a special case -- it is 
  drawn with its
      # tab a little indented.  To achieve this, we 
  incr xd.  We also
      # decr textOffsetX, so that the text doesn't 
  move left/right.
      incr xd 2

      incr textOffsetX -2
  }
      } else {
          # The selected page's text is raised higher than 
  the others.
  incr top -2
      }

  Can you please update the source with this fix?


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

  Change accepted, committed to head.
  Note for future: Please use the 'diff' tool to generate a 
  patch file. Unified diff's (See option -u) are prefered.


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

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


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

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

  I just found the project "Tk Toolkit" and believe this is
  probably supposed to go there (and posted it there). However
  I will leave it here as well just in case this was the
  correct place.

  If it is the wrong place dont hesitate to delete this thread.

  Lio.


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

  "Tk Toolkit" is the correct place.

  Note that the resolution rejected means just that it is not
  valid here in tcllib. It does not mean that the report is
  invalid and such. I haven't actually read more than required
  to know that it doesn't belong here.


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: 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:
  Thanks Thomas.

  I have now run this code against the json.test testsuite in Tcllib, and it reports one failure, for the 'menu' test case. The others all pass.

  The JSON it fails on is

  {"menu": {
      "id": "file",
      "value": "File:",
      "unival": "\u6021:",
      "popup": {
          "menuitem": [
                       {"value": "Open", "onclick": "OpenDoc()"},
                       {"value": "Close", "onclick": "CloseDoc()"}
                      ]
      }
  }
  }

  See the attached file X.log for the stacktrace and error message. It basically expected ',' or '}', and got a ':'. I do not know if the test input is wrong, or your code missing something.

  Please check.


login: thomasmaeder
username: thomasmaeder
mimetype: text/plain
icomment:
  Thanks for testing! I had forgotten the 'u' in Unicode character literals ('\u6021').

  I have just (2009-12-10 09:48) attached the fixed json.tcl


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

  The revised json.tcl passes the test suite. Committed to head with slight modifications (changed a few '==' to 'eq' because they were string, well character, comparisons, and 'eq' is better for that, as it doesn't check if the arguments are numeric or not, as '==' does).

  The new version number is 1.1.


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

  Hello,

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


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

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


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

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

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

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


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

  This was handled by having a header added by the website that returns a list of current bridge names. This is requested when you first login and fetches the current tkchat version and the lolcatz message and so on.


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

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

  Closing this, moved the attachment to the bug entry, where
  it truly belongs IMHO.


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

  I was able to recreate the problem and fixed it using your
  suggestion.  Thanks.


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

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

  For future reference, please create patches in unidiff
  format. They have infomration about which file they apply
  the regular plain patch you provided does not have. They
  also have context information which allows the patch to to
  find the location even if in the presen of slight changes in
  other parts of the file, shifting the locations around a bit.


  Also: Please specify exactly which images from the exif site
  you used. I.e. links to the pages containing the image(s),
  liks to the images themselves.

  If possible, can you please attach test images as well, if
  they are not too large ?

  All of the above is required by me so that I can extend the
  testsuite  to cover the new code. Test cases covering when
  encountering an unknown tag should be provided as well, but
  I am willing to drop this part.

  As you said "most 2.2 tags" I would like to know which of
  the tags  are _not_ handled by your code.


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

  same problem in tklib:

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


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

  Workaround:  
    
  ----------------------------------------------  
  puts [encoding convertfrom utf-8 $t(cn)]  
  ----------------------------------------------  
   
  Why UTF-8 strings resulting from a LDAP search are not 
  automagically converted into Unicode to be handled like 
  normal strings? 


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

  The ldap package probably just returns the ASN OctetString
  type and does not interpret it in any further, but the
  application is free to interpret it in the way it likes to.
  I need to check the LDAP RFC what is expected to happen with
  the search result encodingwise.


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

  According to RFC 2253 the string should probably be
  converted to the UTF-8 encoding.
  http://www.ietf.org/rfc/rfc2253.txt
  and
  http://www.ietf.org/rfc/rfc2251.txt
  (Section 4.1.2).
  So yes, this is a bug und output should be converted to
  utf-8 or the encoding given in RFC 2253. Direct access to
  the ASN.1 values should be optionally possible.


login: pdav
username: pdav
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1268042

  This is not a bug in the LDAP module.  
     
  According to RFC 2251, paragraph 4.1.2, only "LDAPString" types are  
  encoded in UTF8. Decoding depends on the schema used. 
   
  This should be made clear in the documentation. 
   


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

  The simple approach to fix the bug proposed here is
  incorrect. The variable "request_uri" does not contain the
  same information as "env(REQUEST_URI)". Perform the change,
  execute the testsuite and see testcase ncgi-11.2 fail.

  The correct fix is to check again for the existence of
  "env(REQUEST_URI)" and use "env(SERVER_NAME)" if it doesn't
  (exist).

  See attached the patch.


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

  This seems to be a duplicate of bug
  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1724818&group_id=12883

  That bug has been fixed in the CVS head and is slated for release with Tcllib 1.14 (next week).


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

  Possibly true. The Wiki mentions that this was a string 
  match before and was changed regexp. Better be sure.
  Applied change to head now.


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

  Ah, you want a script, like used by 'foreach', instead of a
  command prefix. And the script has access to a variable
  containing the current element.

  Specialized foreach commands, both of them. Called them
  'mapfor' and 'filterfor'.

  Committed, with test cases, and documentation.

  Administriva: Please put tcl code into a files and attach
  them. Inlined code is unreadable.


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

  You can see which version of pop3 you have by looking at the
  'package provide' statement in the file, either at the top,
  or the bottom. There should also be a line like 'RCS: @(#)
  ...' This line contains an internal revision number, just
  before the modification date.

  I cannot look at what you have done because you did not
  attach a file with your changes to this report.

  However if I understand your description correctly you are
  using 'vwait' to enter a new/nested event loop to both wait
  for the response from the server and to process events at
  the same time.

  Having a reference back to tcllib is ok (An url would be
  very good, not clear from description :)

  I have some ideas myself, so I don't know if I will use your
  stuff. It is definitely something which I want to do,
  however not right now. Maybe over X-mas.


login: lio_lion
username: lio_lion
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=971615

  You can see my code in the sf cvs at:
  http://cvs.sourceforge.net/viewcvs.py/amsn/amsn-extras/plugins/pop3/
  Lio.


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

  I am attaching a patch to attempt a fix for this problem,
  along with fixing a series of misspelled words, etc. 


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  File Added - 24883: pat.tcllib.docs

  Logged In: YES 
  user_id=15949

  second try to attaching a patch file.


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

  From the chat

  akuJust looked at the comment problem and patch. 
  what is the correct formatting of an nroff comment ?

  lvirdenThe first line of a man page consists of either a 
  nroff directory, or a specially formatted comment line that 
  indicates that man should invoke additional programs for 
  formatting the text

  lvirden(at least on Solaris)

  akuSo the first line should not have a "normal" 
  comment, right ?

  akuWe can enforce that in the mpexpand processor.


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  Another race condition happened after switching to passive mode in an attempt to avoid the problem mentioned here. In that case the ftp package frequently throws an uncatchable error if the file does not exist:

  can't read "ftp(Start_Time)": no such variable
      while executing
  "if {$ftp(Start_Time) == -1} {
          set ftp(Start_Time) [clock seconds]
      }"
      (procedure "::ftp::HandleVar" line 5)
      invoked from within
  "::ftp::HandleVar 0 sock24"

  This happens when the control connection is closed, which cleans up the ftp array, before the data connection is closed. Then when the event handler for the data connection fires due to an eof situation it tries to access ftp(Start_Time), which no longer exists.

  It looks like some kind of mechanism is needed that can wait for certain events on the data connection before proceeding.


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

  This is partially done already. All the manpages in the CVS should by now have a section abouts Bugs, and Feedback, and pointing to the SF Bug tracker for Tcllib.


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

  That's sounds very useful. Adding it to a README in either the top, src, or devdoc directory seems like another useful location.


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

  RFC2045 says in section 6.7 
  "A good strategy is to choose a boundary that includes
   a character sequence such as "=_" which can never appear in a
   quoted-printable body"
  and so indeed this is what we do. RFC2046 ( the multipart
  one ) explicitly includes '=' in the BNF description of
  permitted boundary chars in section 5.1.1.
  The uniqueID proc is used to generate Content-ID data and uses 
    <[pid].[clock seconds].[incr mime(cid)]@[info hostname]>
  which is as good as we can reasonably manage. This field is
  often useful in multipart MIME documents where it allows one
  part to refer to another within the same document - for
  instance in multipart/related MIME documents.
  So far I cannot find any explicit reference for denying
  MIME-Version in the sub-parts.


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

  Hide users menu should now fit on-screen due to the 
  NickList being trimmed.
  Bridge users can be hidden.


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

  Fixed. pop3d used md5, but was not able to use both v1 and
  v2. Added switching at runtime, like for all other modules.


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

  Note that this will not prevent the limitation that everything for 
  a macro has to be on one line when not using lists (comes 
  from expand).


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

  Addendum to last comment: Continuation lines are processed
  properly when doing macros. So line breaks in macros are
  possible.


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

  I believe we should make an exact list for which commands
  this is wanted before jumping into an implementation. We
  will also have to determine if the output of, for example,
  [arg a b c] is equivalent to either "[arg {a b c}]", or
  "[arg a] [arg b] [arg c]". This are differences in the
  formatted output, and also semantic differences. The first
  means: The text is one argument, named "a b c"; and the
  other means: The command was called to makr three arguments,
  named "a", "b", and "c". And this equivalence can be
  different from command to command. This definitely has to be
  specified.
  Note: The whole implementation, including which equivalence
  applies, can be done in "checker.tcl", i.e. the input
  validation layer. There is no need at all to change the
  formatting engines. A good thing actually. No change in that
  API required.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The use of "string equal" makes this version of tcllib dependent on Tcl 8.4.
  Do we want this (already) ? 


login: ericm
username: ericm
mimetype: text/plain
icomment:
  [string equal] has been around since 8.2.  I think it's fine to require at least 8.2.  In the future, tcllib may require the latest stable release, which is fine too.  Users who need an older version can get an older version.

  We might want to make the dependence explicit, however, with a [package require Tcl 8.2].

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc
  ericm at interwoven.com


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

  Yes, this is noted in a different report here too, see
  #232017.
  I would accept the patch and add it to the CVS, but it is
  currently assigned to Scott Redman (It doesn't show here,
  but in the list of Bugs).


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

  Accepted. Changes committed to CVS. I am not sure if my code is correct for nroff. If not, just open a bug.


login: arjenmarkus
mimetype: text/plain
icomment:
  The zip-file seems to be corrupt. I checked the statistics package though, no proper support for the log-normal distribution.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Patch looks ok.
  Would be helpful if a demonstation script would be provided.

  Committed to csv.

  Thank you, Wolfgang !
  Harald


login: droll
username: droll
mimetype: text/plain
icomment:
  It is right that some tests of the TEPAM module require Tk. I understand that there may be targets on which Tk is not available. I will modifiy next week the relevant tests in a way that they are only executed when Tk is available.


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

  I have added a category 'comm'. I believe that any 
  documentation bugs falls into the category of the affected 
  module.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 13440: 480227.diff

  Logged In: YES 
  user_id=75003

  The enclosed patch adds the namespace information in all 
  relevant places and also changes the formatting of examples 
  so that they are formatted correctly by nroff. Changed 
  references to myself to uptodate values (redirecting SF 
  email, and PURL to pool).

  Also fixed two buggy places in the comm code.


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

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


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

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

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

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


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

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


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

  Ye, it is in the CVS. Yes, using '--' will stop this. Made the 
  change now. Thanks for the report.


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

  Thanks for reporting. These links are repaired by replacing tug.org with ctan.org; they probably predate the registration of the ctan.org domain.


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

  See also Tcllib FR #531531 for an FR regarding the 
  architecture of the server.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 19658: doc.tar.gz

  Logged In: YES 
  user_id=75003

  Attaching documentation of server and adjunct packages.


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

  Well I _do_ have a console on windows - raised from a menu
  item. However these lines should either be tk_messageBox or
  log::log so will fix.


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

  The removal of the 'unset' is not required if the variables are initialized with 'variable'.
  Another instance of what is known as the 'creative writing' problem.
  See http://wiki.tcl.tk/1030

  Fixed in CVS head.


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

  Committed the updated patch (test fix, additional test case,
  qp_encode fix).


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

  Does this happen for the current CVS head as well ? I just checked and the installer code in the CVS head does not contain 'package require fileutil', so the problem might be gone.

  If not note that the Makefile calls on 'installer.tcl' as well, with a series of arguments for non-gui operation. So, when you call the installer directly, using them same arguments, does the error then happen ?


login: anonymous
username: A few details.
mimetype: text/plain
icomment:
  >>> set tcl_version
  8.5

  >>> uname -a

  CYGWIN_NT-6.3-WOW64 username_t_w0 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin

  >>> ./configure --prefix=/cygdrive/c/Users/username/Software/Bin/TclTk --exec-prefix=/cygdrive/c/Users/username/Software/Bin/TclTk

  checking executable extension based on host type... .exe
  checking for tclsh... /../bin/tclsh8.5.exe
  configure: creating ./config.status
  config.status: creating Makefile

  >>> make install

  /../bin/tclsh8.5.exe `cygpath -w ./installer.tcl` \
  	-no-examples -no-html \
  	-pkg-path   `cygpath -w /cygdrive/c/Users/username/Software/Bin/TclTk/lib/tcllib1.16` \
  	-app-path   `cygpath -w /cygdrive/c/Users/username/Software/Bin/TclTk/bin` \
  	-nroff-path `cygpath -w /cygdrive/c/Users/username/Software/Bin/TclTk/man/mann` \
  	-no-wait -no-gui
  Installing Tcllib 1.16
  You have chosen the following configuration ...

  Packages:      C:\Users\username\Software\Bin\TclTk\lib\tcllib1.16
  Applications:  C:\Users\username\Software\Bin\TclTk\bin
  Examples:      Not installed.
  Documentation:

  	NROFF:  C:\Users\username\Software\Bin\TclTk\man\mann
  	HTML:   Not installed.

  Install error:
   can't create directory "C:\Users\username\Software\Bin\TclTk\lib\tcllib1.16": no such file or directory
      while executing
  "run file mkdir $dest"
      (procedure "xcopy" line 3)
      invoked from within
  "xcopy  [file join $distribution modules $module]  [file join $libdir $module]  0 *.tcl"
      (procedure "_tcl" line 3)
      invoked from within
  "_tcl aes {C:\Users\username\Software\Bin\TclTk\lib\tcllib1.16}"
      ("eval" body line 1)
      invoked from within
  "eval $guide($m,$type) $m $args"
      (procedure "xinstall" line 4)
      invoked from within
  "xinstall   pkg $config(pkg,path)"
      (procedure "doinstall" line 16)
      invoked from within
  "doinstall"
      (procedure "main" line 11)
      invoked from within
  "main"


login: aku
mimetype: text/plain
icomment:
  (1) Please put a valid email address into the 'Contact' field to get notification email when this ticket is edited.

  (2) What does happen if you remove the `cypath -w ...` construct from the Makefile and simply use the paths as they are ?


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

  Commiitted a fix to CVS head. Package version 2.4.9.


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

  Yes, a duplicate of [ 1774302 ] error in CommRunHook error handling, @ https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1774302&group_id=12883

  Already fixed in the CVS Head.


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

  Committed the fix to head. Had to move a namespace eval
  before the condition so that the namespace would exist
  before trying to put a variable into it.


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

  Fixed. Used the second proposal. I.e. check for the required 
  number of conversions.


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  i dont believe the first 2 lines are needed since the example is static html, not ncgi output. I have fixed the ncgi::value call not matching the html name.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  I am unable to find the line/command

      "expr {($v << 2) | (($w & 0x30) >> 4)}"

  in the current code. This ticket may be out of date.

  Notes
    *  Unclear if it is the $email which provokes this, or
    *  If it is the (random) key.

  Ah! Found the offending line in the base64! package, ::base64::decode, Tcl implementation, $bits == -1 branch.

  Code contains reference to: Bug [2976290].

  Yes, that looks to be the same.
  And as it was fixed in 2010 I have to assume that an old version of Tcllib was used (pre Tcllib 1.12, pre aes 1.0.2).

  Closing this as a duplicate of bug [2976290].
  Out of date would have worked too.


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

  This seems to be a dict'ionary ordering thing. The tcllib testsuite support provides a 'dictsort' command to generate a canonical representation, whatever the ordering returned by Tcl. This is not as important any longer now that dicts are keeping insertion order. It was originally made because Tcl 8.4 and 8.5 returned dicts and arrays in differing orders due to changes in the underlying hash(table).


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

  Committed updated tests to CVS. Note: The tests can run with a Tcl 8.4 using the backported dict package. This combination will now fail as the backported dict does not have the ordering changes of the Tcl 8.5 dict. either the backport has to be updated, or the testsuite has to get two tests per actual test, one per variant.


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

  Fixed. Also fixed a syntax error in an example uncovered by
  emacs syntax highlighting. A closing double-apostroph was
  missing.


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

  Accepted, and committed to head. A list of free ids may come
  later. However even with 32-bit ints we have around 4
  billion numbers before we get into trouble. Ignoring this
  issue for now.


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

  Thank you for the report ...
  Fixed in CVS head now.
  ChangeLog:

          * memchan.tcl: Fixed missing initialization of 'content' instance
            variable. Bumped to version 1.0.2.

          * variable.tcl: Fixed missing invokation of superclass
            constructor. Fixed missing initialization of linked 'content'
            variable, if not existing. Fixed missing import of linked
            variable into the event handling. Bumped to version 1.0.2.

          * cat.tcl: Removed bogus invokation of superclass constructor,
            there is no such. Bumped to version 1.0.1.

          * facade.tcl: Added missing logger requirements, dropped bogus
            call to superclass constructor. Bumped to version 1.0.1.

          * std.tcl: Fixed command scoping issues, and dropped bogus call to
            superclass constructor. Bumped to version 1.0.1.


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

  I have been able to trace this problem down to 
  the ::ftp::CopyNext routine and the StateHandler routine. 

  The CopyNext routine will always unset ftp(state.data) 
  once the transfer is complete or there is an error.  Then 
  the StateHandler routine in the put_sent switch arm, will 
  try to unset it again if the return code is not 1 or 2, 
  and it's passive mode.  

  All that's needed to fix this is either a catch, or a 
  cleaner way would be something like:

  if [info exists ftp(state.data)] {unset ftp(state.data)} 
  in the StateHandler routine.


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

  The non-Trf versions use ` as this is the 0 byte
  representation and this follows other uuencode
  implementations (notably perl's pack('u', ' ');) The tilde
  character is invalid which makes it helpful in recognising
  excess bytes but may cause interoperability problems for
  other decoders. In standard usage each line is prefixed by a
  byte the gives the length in bytes of the relevant data so
  the choice of padding should not be too important.

  Interestingly I looked for a standard and found IEEE Std
  1003.1-2001 gives a specification for uuencode which
  specifies = as the padding character! Solaris'
  implementation is using a space.


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

  In other words, this area is even more of a mess than I thought.
  :(
  Ok,  I will consider this a low-prio thing then.
  Get to unconfuse the testsuite first/only.

  Hm. Might make sense to choose a padding character we can
  easily detect later and then convert into whatever is needed
  for compatibility when the result is used in specific tools,
  like uuencode.


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

  Ok, I committed a change which deconfuses the testsuite's
  belief about which accelerator is loaded and active. Keeping
  this open for dealing with the padding mess, retitled entry
  for that.


login: 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:
  Hm. Will have to search where the code comes from. 
  "configure" is a generated file.
  Patches to it make no sense because the next time it is generated from configure.in (and tclconfig.m4, etc.) the change will be gone. Will have to grep where the sources for this line are.


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

  Very likely.
  What version of snit was this ?
  IIRC Will made some changes to the option command and I might use the newer features.


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

  Made the dependency more strict, now requesting snit 1.3 or higher (incl. v2+, if using Tcl 8.5).


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: 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: 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: 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: aku
mimetype: text/x-fossil-wiki
icomment:
  Done with commit [6a75d04948].

  html bumped to version 1.5. (EF)

  See also ticket [1076403fff], and [a4680273cf].


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

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

  Accepted the reasoning, extended set of named entities with apos.
  Committed to CVS head.
  This is now version 1.1.3.


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

  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

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


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

  Grrr. The RFC does not tell us here.  The 'nlst' style did
  not print ., nor .. Copied the code from that part ot
  'list'. Committed.


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

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


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

  This is handled by the new magic(5) based recognizer, new
  module fumagic aka fileutil::magic. Therefore done.


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

  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

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


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: 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: 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: 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: 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:
  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: anonymous
username: tclbliss
mimetype: text/plain
icomment:
  Please take a look at the original description of the issue here:

  http://sourceforge.net/p/tcl/bugs/5221/

  The problem is with the tcllibc package.


login: aku
mimetype: text/plain
icomment:
  Investigating a bug report of the same nature for sha1 and Windows revealed that the sha* bindings made use of undocumented behaviour of the "critcl::cheaders" command to deliver a -D... flag to the C code. Between critcl2 and critcl3 this internal behaviour changed and building the 32bit tcllibc with critcl3 generated a shared library using the code-paths for big-endian. As x86 is little-endian things flubbed. The -Dflag became -Iflag and thus ineffective.

  Revision [e5180e9f92] has changes to the sha* code fixing the issue by using the proper command "critcl::cflags" instead. Additionally checks were added to the C code to #error out when the expected TCL_BYTE_ORDER macro is not defined, to fail the build instead of generating something which may not work.

  An audit of the other critcl-based parts of tcllib showed no other places doing the same API abuse.

  Merged with revision [ad20454023].
  Committed.
  Pushed.


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: 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: 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: aku
mimetype: text/x-fossil-wiki
icomment:
  The other ticket has a patch attached, and branch to review.
  Closing this one as duplicate and continuing review of the other,
  i.e. [cb043ecc70e0e90bff93535d1d371a78b94f5d44]


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: 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: 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: 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: 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: aku
mimetype: text/plain
icomment:
  Closing as duplicate of the re-submission [659631d1f4].
  Fixed now.
  Revision [27f9dbf374].
  Committed.
  Pushed.


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

  Confirming. I noticed the very same thing during the xmas
  vacation when using htmlparse, and added it to my todo list.


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

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

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

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


login: 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: aku
mimetype: text/plain
icomment:
  Interesting. Apparently this bug got fixed, as per ChangeLog

  2008-09-03  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  	* S3.test: Added guards to protect testsuite against a
  	* xsxp.test: missing xml package.

  but the ticket never closed. Doing it now.
  Also updated the contact information for notifications.


login: arjenmarkus
mimetype: text/plain
icomment:
  Fixed this bug - the original implementation simply checked if it was a single string, nothing more.

  To avoid the overhead of converting a number to a string, I have chosen the following implementation:

  proc ::math::bigfloat::isInt {n} {
      set rc [catch {
          expr {$n%2}
      }]
      return [expr {$rc == 0}]
  }


login: arjenmarkus
mimetype: text/plain
icomment:
  "Confidence" is not the correct word indeed, it is not about confidence intervals. I have tried to get a clearer idea about how to perform the test, but it is confusing :(.

  To be continued.


login: arjenmarkus
mimetype: text/plain
icomment:
  I have adjusted the documentation and the implementation to use significance (as the complement to the original parameter). The new implementation is actually compatible with the old one, but emphasis is put on the new one.


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

  Fully agreed on both bug and fix.
  The fix is now in the CVS head.
  Package version bumped to 1.3.3.
  Testsuite extended.


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: 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: 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: 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: anonymous
mimetype: text/plain
icomment:
  I think this ticket can be closed, as both of these succeed on 1.2.4:

  % pack req uri
  1.2.4
  % uri::split "http://a.b.c/idx?path=/idx"
  fragment {} port {} path idx scheme http host a.b.c query path=/idx pwd {} user {}
  % uri::split "http://host/path1/path2?param=value#fragment"
  fragment fragment port {} path path1/path2 scheme http host host query param=value pwd {} user {}


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

  Reassigning to me as David is out of reach for a while given 
  his move to Italy.


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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Wolfgang,
  thank you for the bug report.
  I am sorry, IMHO the report is not adequate because it uses the widget not the way it is documented.
  You should use the frame returned by "getframe" to place any childs in.

  Please do:

  set sw [ScrolledWindow .t.s -auto none]
  set cw [$sw getframe]
  text $cw.t -width 10 -height 4

  ---
  Or am I missing something?
  Regards,
  Harald


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: 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: pooryorick
mimetype: text/x-fossil-wiki
icomment:
  When provided a key, <code>::mime::getheader</code> returns a list of headers whose names matched the key, without regard for character case.


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

  Done - several other extensions as well: legend, background 


login: anonymous
username: Ryan Fox
mimetype: text/plain
icomment:
  I think this can be fixed by calling join on the key in all calls into dict within huddle. ie:

  return [dict get $src [join $key]]
  dict set src [join $key] $value


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

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


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

  Applied the patch, extended testsuite. Bumped version to 1.8.2.
  Committed. Pushed. (Fossil repository setup working).


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: 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:
  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:
  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:
  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: 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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Thomas,

  Thank you reporting the bug.

  For me, it does not freeze. It just does not display. But a console window is still responsive. Actually, it is moved out of the screen.
  > winfo geometry .tst
  290x1035+695+-6007

  I will try to fix it.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was, that "winfo reqheight" was used as real height.
  The real height is not jet known, because the window is not jet mapped.
  When mapped, the size is bound on the screen size which highly reduces the height in this case (reqheight was around 16000).

  The estimated value is now bound on the screen size.

  The patch was committed to utils.tcl in cvs.

  Thank you,
  Harald


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: 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: aku
mimetype: text/plain
icomment:
  I can confirm for head of Tcllib.

  I do note something for the case not using the -in option, something you may have overlooked. The result of decrypting is terminated with a \000 character. When using the -in option the garbage comes after the same \000 character.

  I am not sure if that is intentional or not. Because of that the output is not identical to the original input even when not using the -in option.

  Investigation in progress.

  ---

  Ok, we are in ECB mode, which always pads input to 16 bytes.
  And the issue in Chunk was, if nothing was read, it still generated a padded chunk of 16 \0's from that and then decrypted it. The result was the garbage seen.
  Short-circuiting on length 0 fixes the error.

  ---

  Fixed. Committed. Pushed.
  Revision: [eb0e6a2524]


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

  Fixed in the CVS head now. Although I used 'fconfigure' to make it more explicit that this requires binary settings.

  Regarding 'A Category Is Missing', the category 'jpeg' is quite present.


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

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


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

  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: arjenmarkus
mimetype: text/plain
icomment:
  I have been trying to fully understand the issue, but the description has one flaw at least: the matrix U as returned by the procedure is actually square (mxm). This is in accordance with the definition in http://mathworld.wolfram.com/SingularValueDecomposition.html, but this page also mentions a different convention.

  The S matrix is in fact returned as a vector, whose first m values are meaningful, and the remaining (if any) are essentially zero.

  The V matrix is square too, nxn.

  Here is a small script to verify this behaviour:

  set A {{1 1 1 1}
         {1 1 1 2}}
  lassign [::math::linearalgebra::determineSVD $A] U S V

  puts U:
  puts [join $U \n]
  puts S:
  puts $S
  puts V:
  puts [join $V]

  I have put this ticket on "pending".


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: aku
mimetype: text/plain
icomment:
  Applied in revision [7904002443]. Version bumped to 1.0.1.
  Committed.
  Pushed.
  Thank you.
  And apologies for the long delay.


login: aku
mimetype: text/plain
icomment:
  Are you on a unix system ?

  From the description it seems as if you have permission to write to the directory the file is created in, but not permission to write to the file itself, after it was created.

  On a unix system I would suspect that the 'umask' settings are too strict.

  Side note: writeFile and AppendFile do not add \n to the end of the data they write. As written your code produces (if not for your trouble) a file with the contents:

      "Line Number 1Line Number 2"


login: aku
mimetype: text/plain
icomment:
  A bit of back and forth in email indicates that is an issue with the submitters system, and not a bug in fileutil. On other machines the snippet works as expected. Suspicion lies with the OS not being fast enough to release internal locks after creation the file, or external tools like anti-virus, disk indexers, and the like grabbing and locking the file after creation while they perform their work. Nothing Tcllib/fileutil can do anything about.

  Closing.


login: aku
mimetype: text/plain
icomment:
  Some discussion in email points to the code implementing the 'classmethod' utility, which adds a special mixin into the main oo::class structure.

  An 'uplevel' might have been forgotten. Under test.


login: anonymous
mimetype: text/plain
icomment:
  Seems to be fixed by changing line 100 of ooutil.tcl:

  -       oo::define $cls $script
  +       uplevel 1 [list oo::define $cls $script]

  This is not related to http://core.tcl.tk/tcllib/tktview/fe7a0e0a3a though that bug is stymied by the same line of code.


login: aku
mimetype: text/plain
icomment:
  Fix committed to revision [14faa92003].
  Pushed.
  Version bumped to 1.2.1.

  Thank you for the report, and apologies for the oh so long delay in making the fix.


login: aku
mimetype: text/plain
icomment:
  A review of the GLOB* procedures shows that GLOBD can in principle suffer from the same issue.

  The general fix is to use 'lsort -unique' to collapse duplicates.

  "General" as in "independent of the underlying filesystem and without knowledge about".


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [4afba263b2].
  Committed to branch "bug-8b317b4a63-fileutil" for testing.
  Pushed.
  Leaving open until test results have come back.


login: aku
mimetype: text/plain
icomment:
  No response from submitter.
  Closing with merge to trunk.
  Merge result revision [1298908cdd].
  Pushed.


login: anonymous
mimetype: text/plain
icomment:
  Edit: sorry, one more line needs changing as follows:

  	if { $found == 0 } {
  	 ##   incr buckets($last) NO ##
           set buckets($last) [expr $buckets($last)+$weight]
  	}


login: aku
username: aku
mimetype: text/plain
icomment:
  Removed (non)terminal methods in pt::ast documentation, and replaced with documentation for new, new0. Fixed typo of "pt::peg::interpreter", to "pt::peg::interp", in pt::peg::interp documentation. Regenerated documentation.

  Fixed.
  Revision [e6e940297a].
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Fixed in revision [f082bc61b7].
  Committed.
  Pushed.

  Online docs regenerated in revision [c1d83bd48d].
  Committed.
  Pushed.

  With thanks.

  See also ticket [e65df22e92].
  Was a later duplicate, seen first.


login: anonymous
username: ente
mimetype: text/plain
icomment:
  Hello,

  I updated and tested it, the version you uploaded still has a few bugs.
  While I was add it, I also put it in the public domain so feel free to do whatever you want with it.

  Best,

  Moritz


login: anonymous
username: Olivier
mimetype: text/plain
icomment:
  > This does mean an incompatibility with the previous version. How can we best communicate this?

  It means that 

  "set xvalues [lrange [$table get column 0] 1 end]" is a bug

  but 

  "set xvalues [lrange [$table get column 0] 2 end]" works 

  PS : I always login as anonymous, because I don't know how to do differently, it seems not possible to have an account.


login: arjenmarkus
mimetype: text/plain
icomment:
  Changed the code as proposed. Expanded the documentation with an example to make the interpretation clearer.

  Note that this introduced an incompatibility between the previous version (1.0.3) and the new one (1.1).


login: arjenmarkus
mimetype: text/plain
icomment:
  Changes made to the code and the documentation. Bumped the version to 1.1 to reflect that there is an incompatible change in the API that is due to this bug fix.


login: aku
mimetype: text/plain
icomment:
  Fixed in revision [f082bc61b7].
  Committed.
  Pushed.

  Online docs regenerated in revision [c1d83bd48d].
  Committed.
  Pushed.

  With thanks.


login: aku
mimetype: text/plain
icomment:
  Another difference of note:
  With a schema present the fields "user" and "pwd" are set.
  Without they are not.

  The underlying difference seem to be in how SplitHttp is called.
  With a schema the call is  SplitHttp //www.test.de
  And without the Schema its SplitHttp www.test.de

  The leading // characters tell the code that host information is present. Without the data is a path.

  Simply prepending the // characters when the default scheme is used (and in the set http, https, ftp) however breaks 'uri::resolve'. This might be an issue in resolve ... Yes, sort of. It uses split on the _relative url_ to be rebased. This may also explain how split came to treat things without scheme as path instead of host.

  Adding the scheme from the base to the relative url to split, without host information ... Works.

  Still broken test case uri-8.0 about illegal characters in the scheme.
  The system does not really distinguishes a missing scheme prefix from a bad scheme prefix containing bad characters :( ... Updated the test-case.


login: aku
mimetype: text/plain
icomment:
  Are you sure that "\%" and "\." are valid json ?
  They are not listed as escapable characters at json.org.

  Also, I am currently working on ticket [6efa4f571a], integrating a binding for the json-c parser (found at https://github.com/json-c/json-c/wiki) to speed things up.

  Extending the testsuite with your case, i.e. "\%", etc. this parser rejects the input as well.

  This does not seem to be valid json as you claim, and the rejection by the package not a bug.

  Maybe you can point us to whichever (online) JSON validators/parser claim that your input is valid?


login: aku
mimetype: text/plain
icomment:
  Added test cases which some of the problems (Differences in the Tcl vs C implementations, and issue in the Tcl implementation).

  Revision [622bbdc254].
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Revision [6de2cf7d3f].
  Committed.
  Pushed.

  Modified the C implementation to reject improper escapes via additional validation before calling on Tcl_UtfBackslash. Further tweaked the code a bit so that it will not show an uninformative 'syntax error' when it has a more detailed/nicer message from the lexer.

  Tcl implementation still to fix.


login: aku
mimetype: text/plain
icomment:
  Ok. The issue with the Tcl implementation is in both the tokenizer (i.e. lexer), and the interaction of tokenizer and parser ...

  The two cases with are wrongly accepted are escape3 and escape4,

      ["\%"], and ["\."]

  Their token sequences are:

  T:      [
  T:      ]

  IOW the tokenizer strips the bad strings out of the input and passes only the good tokens. The good tokens represent an empty array and that is accepted.

  In the case of {"a":"\%"} the tokens are
  T:      {
  T:      "a"
  T:      :
  T:      }

  which, with the bad string stripped represent a broken json-object and the parser bails with its own (syntax) error on that.

  A possible fix might be to have the tokenizer replace bad input with an ERROR token which will unconditional choke the parser layer.

  The non-trivial part is how to express that in the tokenizer regexp.

  The tokenizer is a 'regexp -all -inline <pattern> <input>' ...
  The pattern contains all legal input.
  And the illegal input is simply ignored and missing in the output of that
  command.

  This needs more thought ... I would like to keep the regexp one-liner.
  Because it is fast even for Tcl. Having to use a Tcl loop to process the string token by token to find the non-token parts, that would be quite a slow-down.


login: aku
mimetype: text/plain
icomment:
  Tweaked the tokenizer and split the validation RE from the tokenization RE.

  The tokenizer now accepts all strings, i.e. all possible backslash escapes, regardless of (in)validity. It is in the parser layer where the code retrieving the unescaped string from its token now does a check against the strict set of allowed escapes and throws an error if that fails.

  Bumped version to 1.3.3.
  Revision [8e0ee4f384].
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  In the second example we have two different expander instances.
  In the first we have only one instance.

  It might be a scope issue, i.e. the instance not available in the scope where text substitution happens. Not sure if [cget BAR] would work, i.e. the instance implicit in the context.

  Will try to convert the example into a test case and then debug.


login: aku
mimetype: text/plain
icomment:
  The behaviour is actually ok.

  expanderName cset varname value
      Sets variable varname to value in the __current__ context.

  And the 'expand' method does a 'cpush expand' as the first action, i.e. it creates a __new context__ which has no variables. The BAR variable is in the context outside of this new one, and thus not accessible. Something like

    exp expand {[exp cset BAR FOO][exp cget BAR]}

  Should work, as it creates the BAR variable in the expand context before accessing it from the same context.

  With the second example a separate expander is accessed with its own stack of contexts, which is not influenced by the 'exp expand ...' operation.

  I will make a note in the expander documentation about 'expand' pushing a new context.


login: aku
mimetype: text/plain
icomment:
  Fixed in revision [498c380fbb].
  Committed.
  Pushed.

  Testsuite not updated yet.

  With thanks.

  Underlying issue was a bug introduced when refactoring getExif into getExif and getExifFromChannel, and not thinking through who has the responsibility to close the channel. This lead to a double-close when trying to read the exif data of a non-existing thumbnail image.


login: aku
mimetype: text/plain
icomment:
  Revision [d1adb3c859]. Some followup work.

  Made the testsuite 8.4+ and converted it to tcltest 2 format.
  Extended testsuite with an example image missing any embedded exif information
  This is not triggering the issue, actually.
  Still a good test case.

  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Revision [80e9a2006f], another followup.

  Test suite extended with the image which started it all, with permission from the ticket originator.


login: aku
mimetype: text/plain
icomment:
  We have a few other tickets open regarding yaml and its problems.
  See [3434579fff]
  and [3475081fff]

  I had a go at the internals myself for the latter, and gave up. While there seems to be a recursive-descent parser in the spaghetti somewhere, I was unable to detangle it.

  For bugs like the above and references I ask for patches.

  If use of C-based packages is allowed in your context, please see http://core.tcl.tk/akupries/tclyaml/index

  That is the package I wrote myself, and use, after giving up on the yaml package in Tcllib. It is a binding to a proven yaml parsing library. The binding comes with the sources of that library, making it easy to build. The site has detailed instructions on how to build.


login: anonymous
mimetype: text/plain
icomment:
  Hi,
  I tried to parse the file with the new huddle and yaml version, and it seems that it works. I don't see an error. Could you please confirm?

  I downloaded the file:
  http://slexy.org/view/s21SOIImVi

  and I executed:

  set channelId [open "s21BwGvY4m.yaml" ]
  set data [read $channelId]

  yaml::yaml2dict $data


login: aku
mimetype: text/plain
icomment:
  The command and the url refer to different files, it seems.
  Note: set channelId [open "s21BwGvY4m.yaml" ]
  vs   http://slexy.org/view/s21SOIImVi
  ..............................^^^^^^^


login: aku
mimetype: text/plain
icomment:
  I have now pulled the referenced file and attached it to the ticket.
  Also good in case the paste-bin reference goes lost in the future.
  The attachment will not.


login: aku
mimetype: text/plain
icomment:
  Hrrm.

  This is actually a regression going back to when I switched to using the pre-generated the manpages for the distributions.

  I.e. the files under embedded/, as produced by "sak.tcl localdoc". The code in the installer was aware of Exclude and skipped the manpage generation. "localdoc" is not, so it builds the exif manpages :( And the changed installer (a) simply copies the files under embedded/, and (b) has no idea which of these files fall under exclusions.

  So, seems that I have to make localdoc aware of the exclusions.
  That will also remove exif from the documentation on the repository website, not just from distributions to install.

  Side note: The other excluded package 'calendar' was no issue here because it has no documentation anyway.

  Onward...


login: aku
mimetype: text/plain
icomment:
  Questions:
  - What license is the package under ?
  - What are your plans regarding supporting this package?
  - May I have some basic documentation ?
  (outline of the externally visible API, how to use it, small code example, that kind of thing)


login: aku
mimetype: text/plain
icomment:
  Answers in mail.
  - BSD
  - Yes (pointed to tcllib-bugs for notifications).
  - Document in sasl.man, mechanisms, RFC 5802.

  Revision [38a2ed086c].
  Committed.
  Pushed.
  With thanks.


login: aku
mimetype: text/plain
icomment:
  Can we go to

    #!/usr/bin/env tclsh8.5 
    # -*- tcl -*-

  instead ?

  Gets rid of a whole lot of magic, i.e.
    the continuation line syntax tricks, exec
    and the "$0" ${1+"$@"} noise.


login: aku
mimetype: text/plain
icomment:
  [16:42]	stu	#!/usr/bin/env tclsh
  [16:42]	stu	Works for me.
  [16:43]	stu	The other way is fine, too, but please use /bin/sh
  [16:43]	stu	I'm ok with, and the obsd ports system takes into account, both ways.
  [16:44]	emiliano	note that, on fbsd, tclsh is a dummy entry; you need to specify the precise interpreter version you want (tclsh8.X)
  [16:45]	stu	obsd also has tclsh8.x
  [16:45]	stu	But what's normal is 'tclsh'
  [16:45]	stu	And that's what I expect to find in other peoples' programs.
  [16:46]	stu	So just 'tclsh' is fine ... ports systems expect to have to, and have tools for, adjusting that stuff.
  [16:51]	aku	stu - thanks, and ok.
  [16:52]	stu	Thank you! More like this means less patches for me.


login: aku
mimetype: text/plain
icomment:
  Fixed in revision [4a2f75b5da].
  All synced up at  [2917507b22].
  Committed.
  Pushed.

  The work done on branch pyk-tar, mostly by the submitter (pooryorick), with me straightening a few things a bit after.

  The issue was actually not the limit itself, but how the code mishandled read results and short reads after that. The bug is fixed with the per-round limit reinstated. The limit is present to keep the memory usage within reasonable bounds, as the code has to read the data into memory to skip over it without seeking. Without limits we may run into memory issues, be it swapping, or just running out.


login: aku
mimetype: text/plain
icomment:
  Confirmed. This is like with regular files which also fire readable events when at eof, until the handler script deigns to handle the condition and closes the channel.

  This also affected the channels 'string' and 'variable' (derivations of 'memchan').

  Fixed all affected channels.
  Committed in Revision [fc756af785]
  Pushed.
  Thanks.


login: aku
mimetype: text/plain
icomment:
  As far as I can tell we lost the original author and maintainer of the yaml/huddle packages in our move to the Fossil repository. I had asked people (i.e. developers) in the tcllib-devel mailing list to ping me with whatever user names they want for their fossil accounts, and he never responded.

  I have
      Kato Kanryu: kanryu6@users.sourceforge.net
  for his email address, i.e. the SF forwarder.

  The one time I tried to fix a bug in the package I got lost in the code as it is, and gave up.
  The result was me making a binding to the libyaml C parser instead, and using that from then on.
  That package can be found at
      http://core.tcl.tk/akupries/tclyaml/index
  and https://chiselapp.com/user/andreas_kupries/repository/tclyaml/index

  Given this experience with the code I will not try to fix further bugs unless they come with a patch (and test).

  So, yes, at the moment the yaml and huddle packages look to be unsupported.

  Regarding reliance on Tcllib it might be easier to convince people to rely on specific packages in Tcllib instead of it as a whole.
  It is a very large bundle (400 packages in 110 modules), quality and support is uneven across the packages.


login: aku
mimetype: text/plain
icomment:
  That looks nice. And the json-c is under MIT/BSD license as well.
  I may have to convert your example into a critcl-based form for integration with Tcllib. I will also have to think about how to refer to the json-c code. I might simply include it directly, plus README and such where to find the original and updates.


login: aku
mimetype: text/plain
icomment:
  Started working on this, on a branch.
  Branch is "ak-bug-6efa4f571af052-jsonc".
  Starting revision [c51875a02a].
  Reviews welcome.

  Known issues with the current work:
  - The *2dict commands are still implemented in Tcl.
    Might stay that way.
    Or be removed in favor of the separate json::write package.
    Which can get its own critcl based implementation.

  - many-json2dict not implemented yet.
    That one is important.

  - testsuite boolean differences: 0|1 vs true|false
    (custom matcher?)


login: aku
mimetype: text/plain
icomment:
  Revision [8fc03c91fd] integrates json2.c features.

  Notes
  - Modified the Tcl parser to return 0|1 for boolean values,
    to match the new C parser. Updated testsuite.
  - Supplied my own definition of assert to fit in with Tcl
    (Tcl_Panic).
  - Modified the C conversion of json null to match the Tcl
    parser, is now 'null', not the empty string.
  - Changed Tcl_Dict* uses to equivalent Tcl_List* to keep
    the code usable for Tcl 8.4
  - Moved the code handling the deferal/laziness into
    lazy_value2obj and applied it to array elements as well,
    not just object fields.
  - Moved the variables in value2obj into the switch
    branches.
  - Changed the Tcl_ObjType structure initialization to
    regular C. Code as provided (see attachment json2.c)
    looked like some GCC-ism.

  Open question
  - Why does the json2string function not just generate
    the string rep, but takes the int.rep as well,
    shimmering the Tcl_Obj*. Seems to presume that the
    string generation is immediately followed by Tcl
    code forcing a shimmer anyway ?!


login: aku
mimetype: text/plain
icomment:
  A first implementation based on json-c has been committed, with json-c sources (release 0.11) embedded in Tcllib.

  Revision [df814df3ab].
  Committed.
  Pushed.

  Note: An alternate implementation based on a bison/yacc grammar and custom lexer is waiting in the wings, directly constructing Tcl_Obj* structures instead of json-c structures requiring further conversion to Tcl_Obj* structures. This is apparently faster than we currently have here.

  Keeping the bug open until this alternative has been integrated and tested.

  For now however we have something which is already faster than the pure Tcl implementation, even if not perfect, and in working order.


login: aku
mimetype: text/plain
icomment:
  Attention.

  The json-c implementation has a large drawback.
  By converting all incoming integer values to C values it limits itself to the system's word size. Like 2G unsigned on a 32bit system.

  Noticed this with the stackato cli getting disk usage limits reported in bytes, and these can be above 2G (2147483648), at which point the json-c delivers a negative number due to its limits. The Tcl implementation was ok with that.

  This makes a difference to the Tcl implementation which simply takes and remembers the digit string without any conversion. Only when the field is actually used, and used as a number will a conversion happen, possibly limiting the range and wrapping around. However for 8.5+ we have mp-ints, i.e. arbitrary precision integers.

  The bison/yacc code is unfortunately similar, directly generating either a double or wideint from the digit string, through a C double or long-long. Because of the latter it automatically limits itself to the capabilities of the build system.

  It is better to generate a StringObj from the input and leave any conversion to whatever integer to the Tcl runtime, when the value is actually used as a number. This fits better with EIAS.

  NOTE: Replace json-c with a fixed bison/yacc implementation before making Tcllib release 1.16. This is (IMHO) effectively a bug in the current json-c.


login: aku
mimetype: text/plain
icomment:
  Switched to yacc/bison-based parser (see attached), with modifications to address the issue of eager int/double generation.

  See revisions [11390a7baa], [2d0b61da55], and [09ed31fbfc].
  Done.


login: aku
mimetype: text/plain
icomment:
  With all the attachments I hate to say this.
  This belongs into the tklib tracker over at 
  http://core.tcl.tk/tklib/


login: aku
mimetype: text/plain
icomment:
  Thank you for the report.
  Removed the use of ::errorInfo, and simplified a bit.
  Fixed in revision [3b14767f50].
  Committed.
  Pushed.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Consolidated `doctools::paths`, `paths` (pt) as `fileutil::paths`.

  Commit [d843b2df15] begins branch `ak-31868eeaff`.


login: aku
mimetype: text/plain
icomment:
  Rejecting consolidation of 
  - doctools::text   / text::write   --> text generation utils --> textutil

  While both packages are text writer support each is very much geared towards the context in which they are used (doctools, pt), with pretty much no commonalities in API and internals.


login: aku
mimetype: text/x-fossil-wiki
icomment:
   Consolidated `doctools::config`, `configuration` (pt) as `struct::map`.

  Commit [d7c72d4825] continues branch `ak-31868eeaff`.


login: aku
mimetype: text/plain
icomment:
  Still mulling over moving `char`.

  Also mulling over compatibility handling:

  (1) Create chain packages under the old names which provide the old interface using the new packages.

  (2) Or create placeholder packages under the old names which error on use and refer the user to the new names.

  (3) Staged deprecation: Start with option 1 (next release), release after that switch to option 2, release beyond that remove the old packages entirely.

  Liking option (3) best so far.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Implemented compat handling in commit [5186a0f24b].

  Not moving `char`.

  This completes the work on this ticket, except for merging back into trunk.


login: aku
mimetype: text/plain
icomment:
  Yes, that looks right.
  Will apply.
  (Should add tests for CreateNonce, if that is a public command).


login: aku
username: Andreas Kupries
mimetype: text/plain
icomment:
  > It is not straightforward to construct a grammar with a node
  > accepting the empty string. [...] We want the parser to consume
  > the either the "a" if there, or accept without consuming otherwise.

  To rephrase, your "a" is _optional_.
  And rephrase again, it is _repeated zero or once_.

  Under the expression docs of the PEG language tutorial (*) you can see that this is achieved with the ?-operator, a suffix.

  (Ad *) http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/pt/pt_peg_language.html#subsection4

  So you have to write

      start <- "a"? ;

  to get what you want.

  The example at

    http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/pt/pt_peg_language.html#subsection7

  demonstrates this as well, for the definition of the Number symbol, and its optional Sign part.

  That being said (and solving your original issue), the PT code should not crash on your input, so there is still a bug to be fixed somewhere.


login: anonymous
mimetype: text/plain
icomment:
  The example I provided might be deficient, and there are certainly ways to express the same grammar or, at least, to have them consume the desired inputs. My point is that it is sometimes easier to define the grammar by using the /epsilon/ parsing expression directly. Our original case was more similar to the following:

      Type <- Abstract / Concrete ;
          Abstract <- "abstract" ;
          Concrete <- "" ;

  Where we wanted to obtain the Concrete non-terminal if nothing was specified in the input.

  The (excellent) documentation says that "[Strings...] They can be empty as well."; see:

  http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/pt/pt_peg_language.html#subsection4

  Best regards,
  Adrián Medraño Calvo.


login: aku
mimetype: text/plain
icomment:
  A bit more discussion in mail ... Consolidating here ...
  aku ====================================================
  ... Thinking ... More thinking ... You are right, I can't think of a
  way representing this type of structure in PEG syntax as it currently
  is. ... Looking at your doc ref ... Yep ... Should be allowed to be
  empty, and in that case ... Yes, that is (should be) <epsilon>.

  Ok, time to bump the priority of this issue and get cracking ...

  I will add this response to the comments in the ticket as well, later.

  I believe I will use the above and/or the original grammar as test
  cases, if you do not mind.

  adrian==================================================
  That is fine, of course. Thank you very much for the support.

  ========================================================


login: aku
mimetype: text/plain
icomment:
  Started to work on this.
  Branch "pt-bug-7665c3532c-epsilon".
  Commit [bce28f8438] has the bugfix, I believe, and updated testsuite.
  The testsuite seems to expose more issues.
  Has only partially run yet, not complete.


login: aku
mimetype: text/plain
icomment:
  Revision [8c541ca76f]. Package version bumps.
  Revision [66707cafa9]. Testsuite finalized.

  Committed.
  Pushed.

  This looks to be ok now.
  Waiting on feedback by submitter now.


login: anonymous
username: dgood`
mimetype: text/plain
icomment:
  I'm testing against two instances of MS FTP server, one on a physical server, and on on Amazon EC2.  The trace was using an Active FTP connection, port 21.  Passive connections blow up as well, but I have tested this far less, so I don't want to say too much about it right now.


login: aku
mimetype: text/plain
icomment:
  Most of the interaction directly by mail.

  Generally this was a race condition.
  The main sequencer for the control connection (MSCC) stepped independently of the code handling the data connection (DC).

  In this case the server opened the DC very late, at a time where the MSCC had stepped already beyond the last state of the sequence dealing with the data command (here NLST, state 'list_close'). InitDataConn thus encountered a main state it had no idea what to do with.

  Solution was an additional marker field in the state array of the connection, managed by OpenActiveConn, InitDataConn, and a new procedure WaitDataConn to have the MSCC wait in the last state of any sequence (*_close) for the arrival of the DC before stepping further.

  The new procedure is added to all these states.

  Work on branch "ftp-bug-eb0b15d598"
  Final fix in revision [6474b535bb] of the branch.
  Trunk merge done with revision [863ac2e0d8].
  Package bumped to version 2.4.13.
  Committed.
  Pushed.

  Whew.


login: arjenmarkus
mimetype: text/plain
icomment:
  This is an interesting corner case (literally as well as figuratively):
  One of the vertices of the polygon lies on the line that is used to determine if the number of crossings is even or not. I will have to figure out a way around this.


login: arjenmarkus
mimetype: text/plain
icomment:
  Solved this - tracked the cause to edge cases in the lineSegmentsIntersect procedure. This now first checks if end points of one segment is on the other segment.


login: arjenmarkus
mimetype: text/plain
icomment:
  I could reproduce this behaviour, but the problem is that the procedure calculates the distance to a _polyline_, not a polygon. The implied line segment that the point is on is (2.0,-2.0) to (2.0,2.0) and that is NOT part of the polyline. 

  The procedure should get a companion instead, calculateDistanceToPolygon, that does close the polyline to get a polygon.


login: arjenmarkus
mimetype: text/plain
icomment:
  Solved this by introducing a new procedure calculateDistanceToPolygon - this assumes that the second argument is meant to be interpreted as a closed polygon


login: aku
mimetype: text/plain
icomment:
  Fix is possibly easier than shown, no need to go through the hex.
  A plain %u formatting on the $out looks to be ok.
  (For Tcl 8.5 at least, have to check against Tcl 8.{4,6} as well).

  -    return $out
  +    return [format %u $out]

  Revision [ea88434604].
  Committed.
  Pushed.
  Not closing yet, still to check against 8.{4,6}.


login: aku
mimetype: text/plain
icomment:
  Followup revision [cfd881b6f8]. Restrict $out to 32bits for proper formatting.
  Now it passes the extended testsuite against Tcl 8.{4,5,6}.
  Closing.


login: aku
mimetype: text/plain
icomment:
  Revision [27f9dbf374].
  Committed.
  Pushed.
  With Thanks.
  This was a duplicate of [2875035fff], i.e. a re-submission.


login: aku
mimetype: text/plain
icomment:
  Nit: The proper reference is http://wiki.tcl.tk/13489
  Please supply a patch implementing the feature.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  Fixed in latest version, this had to do with the use of the -handler option of the http library, an option that would force HTTP/1.0, meaning that the server at echo.websocket.org would close the connection at once. Since this behaviour is believed to be widespread, the current version does not use -handler anymore and forces 1.1 and keepalive connections instead.


login: aku
mimetype: text/plain
icomment:
  My understanding of your description is that you believe that json::write should encode (for example), the \r (ASCII 13) control character as \u000D instead of \r, is that correct ?

  Please note that according to the syntax specification at

      http://www.json.org/

  encoding \r as "\r" is allowed. See the diagram for 'string', or the rule for 'char' in the right-hand side-bar

  The set of control characters json::write encodes with plain backslash (\r \n \t \f \b) instead of via \uxxxx is exactly the set allowed by the syntax to be encoded that way, minus the solidus.

  Given that json::write follows the official syntax I am currently more of the belief that whatever code is processing json::write output accepts only a subset of proper json syntax.


login: anonymous
username: Hermitifier
mimetype: text/plain
icomment:
  It isn't a problem with those five control characters which have backslash-letter escape, but with the rest from ranges \u0000-\u001F and \u007F-\u009F. Currently they are just inserted into string.

  Simply building full map for substitutions solves the problem:

      variable quotes \
  	[list "\"" "\\\"" \\ \\\\ \b \\b \f \\f \n \\n \r \\r \t \\t \
  	    \x00 \\u0000 \x01 \\u0001 \x02 \\u0002 \x03 \\u0003 \
  	    \x04 \\u0004 \x05 \\u0005 \x06 \\u0006 \x07 \\u0007 \
  	    \x0b \\u000b \x0e \\u000e \x0f \\u000f \x10 \\u0010 \
  	    \x11 \\u0011 \x12 \\u0012 \x13 \\u0013 \x14 \\u0014 \
  	    \x15 \\u0015 \x16 \\u0016 \x17 \\u0017 \x18 \\u0018 \
  	    \x19 \\u0019 \x1a \\u001a \x1b \\u001b \x1c \\u001c \
  	    \x1d \\u001d \x1e \\u001e \x1f \\u001f \x7f \\u007f \
  	    \x80 \\u0080 \x81 \\u0081 \x82 \\u0082 \x83 \\u0083 \
  	    \x84 \\u0084 \x85 \\u0085 \x86 \\u0086 \x87 \\u0087 \
  	    \x88 \\u0088 \x89 \\u0089 \x8a \\u008a \x8b \\u008b \
  	    \x8c \\u008c \x8d \\u008d \x8e \\u008e \x8f \\u008f \
  	    \x90 \\u0090 \x91 \\u0091 \x92 \\u0092 \x93 \\u0093 \
  	    \x94 \\u0094 \x95 \\u0095 \x96 \\u0096 \x97 \\u0097 \
  	    \x98 \\u0098 \x99 \\u0099 \x9a \\u009a \x9b \\u009b \
  	    \x9c \\u009c \x9d \\u009d \x9e \\u009e \x9f \\u009f ]


login: aku
mimetype: text/plain
icomment:
  Thank you for the clarification, and the patch to fix the issue.
  You are correct, the json::write code currently does not quote any of the other control characters, and it should.
  The fix looks ok as well.

  Fix in revision [20725ca43d].
  Committed.
  Pushed.
  Package bumped to version 1.0.3.


login: anonymous
mimetype: text/plain
icomment:
  Question.  According to the ECMA document, the control characters are U+0000 to U+001F.  Why map characters \x7f through \x9f also?


login: aku
mimetype: text/plain
icomment:
  Modified the installer to use a new special action for PT, which copies the rde_critcl directory.

  Not addressing the installer design issue. (Nicer design might be to have declaration of actions stored in each module directory instead of central in modules.tcl)

  Fixed with [6c12f6b8ce].
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Another question, which unfortunately did not come to me yesterday (With apologies, I currently have a cold it seems and am a bit slow in my thinking).

  To know that the checksum is incorrect you likely have (access to) some other code and/or tool which also generates these types of checksums.

  If this tool/code is public, please provide a link to it so that I can use it to make test vectors plus expected results with which to check the current and later fixed package.

  If the code is not public, or embedded in something which is not public then I would like to ask you to add test vector examples plus expected results to this bug.

  The test vectors do not have to complex, I think. Examples:

  set v [string repeat a 1280]
  set v [string repeat fx 640]
  set v [string repeat \xfe 1280]

  etc. Without having such a set of TVs + the expected results it is impossible for me to know if a fix I make is correct or not.


